Another server for Kronos? Sure, that's definitely NOT a problem!

We recently assisted a customer with a Workforce Central Timekeeper build for an additional server. After completion we wondered; was it really worth the effort? I would have to say a resounding yes. There could be several environments in addition to production. Several examples include training, development, or testing. Also, having a test system allows the entire organization to implement change on the fly while eliminating any risk to production.  Sometimes it is also referred to as a sandbox. As we enter autumn, I like to think of having at least one additional Kronos server akin to having the first tree from a certain species available for landscape design. Having seen customers with two or even three Kronos systems beyond production, I’d like to focus on how just having even a single “mirror of production” a.k.a. "test server" could be beneficial. 

While consulting on a Kronos project for another customer, we built a secondary Workforce Central application server with Workforce Integration Manager (WIM) for development purposes. The database server was on a separate server. A copy of the production database was made. In Workforce System Settings automated reports, email, WFC (Workforce Central) Event Manager, and clock communications were disabled.

Let's take a very simple scenario (from a company's perspective) for why someone would want a test system. EXAMPLE USE CASE: The latest Kronos service pack has some issues that were resolved and are “must haves”. Additionally, we want to be absolutely sure the service pack fares well against a copy of the production database (before giving a final nod to deploying to production). Now with a test system, the customer can anticipate downtime and get an estimate of how long the service pack will take to apply to a production system. This is a key metric if you are a 24/7 operation where coordination of downtime is important (especially true if there are many managers using the system).

At Improvizations, one of our key themes during a Kronos consulting engagement is the Discovery, Deployment, and Delivery model. You may have heard this term before, The 3 "D"'s. With a test system, having a second system beyond production allows a nice presentation tier before delivery. This deployment tier (test) that I am referring to allows collaboration on any Kronos changes with the entire team. While some would argue maintaining a test system does take more time, I believe it is worth the setup time and the initial hardware investment if you are serious about Kronos. If there are several Kronos configuration changes to be implemented? Having a test system allows an employee or manager to view any proposed changes in test before the changes are rolled out to production.

In summary, while a test or development system might not be a fit for every customer, it allows more flexibility with change and provides a sounding board for Kronos Managers (whether it is Kronos pay rule configuration, customization, or interface testing). Warning: If a production Kronos system is in use, take great care when creating a test system. A basic assessment should be made when creating a test system as to not interfere with any current production processes. The simplest method of doing this is to simply put the copy of production on its own network, but… Stay tuned in to our blog section for more information on how to configure a Kronos test system so that it can coexist in the same network with production peacefully!