We discussed the importance of dedication to the details of a WFM project. Kronos can be a complex project for any IT department; for example, modules have different installation procedures, care must be taken to ensure the application and web servers have the correct bandwidth and are running compatible software versions, and individual user workstations may need to be adjusted for browser compatibility. Within the organization itself, there may be exempt and non-exempt employees, multiple payrolls, union rules, scheduling issues or OSHA incident tracking requirements. Additionally, most Kronos projects require participation from a blended team of decision makers including HR, Finance, IT, Payroll, Internal Audit, etc., not to mention a very diverse mix of end-users! All of these different factors create potential for implementation mistakes or mishaps. With so many diverse requirements to manage, it is crucial to make sure that no detail is neglected throughout the entire WFM project. Designating a serious Project Manager, creating project teams, and proper documentation were the first three crucial implementation details we discussed last week. The last two major details necessary for a successful implementation or upgrade are the Test Environment and Change Management.
4. Create a Successful Kronos Test Environment
A very significant portion of your implementation budget should be dedicated to testing your WFC application. All configuration and coding for a WFC implementation is driven and proven by adequately testing the application. There are three test environments used for successful testing:
SANDBOX Environment(s)
A common best practice on agile teams is to ensure that developers can work in their own "sandboxes." A Sandbox is basically a technical environment whose scope is well defined and respected. The primary advantage of Sandboxes is that they help to reduce the risk of technical errors adversely affecting a larger group of people than is absolutely necessary at the time.
The purpose of the Sandbox is to provide a Kronos playground to "practice" configuration and development. The Sandbox Database is a copy of production and often times it’s stripped of sensitive data. There isn’t a need for tight controls around what is being created or changed in this environment -- that is not the purpose. Use it to figure out what needs to be done at the individual or small team level. Some companies employ multiple Sandboxes for different teams and those get merged into DEV for integration testing.
Since it is just a playground, you can try different things, different approaches to make it work, until you are satisfied that you know exactly how you want to go about implementing the new pay practice. If you break it and can’t fix it, just refresh the database.
DEVELOPMENT Environment
The purpose of the Development environment, or ‘Project Integration,' is different depending on whether or not your organization is implementing Sandboxes. Without them, all development is done there and promoted to TEST for all testing and training. If you have a Sandbox, DEV is primarily used to integrate development from the other sources and make sure those changes don’t affect other parts of the system. Some might perform all simple changes directly to DEV and create Sandboxes for bigger or more intrusive projects. Integration testing should be done in the development environment because a sandbox cannot adequately reflect the Production system after end-users have practiced the different functions.
Final TEST Environment
The final non-Production test environment is where all formal testing should take place. The final test environment is often controlled by a separate TEST/QA group. Defined as Pre-PROD, TEST, or STAGE, its purpose is to provide an environment that simulates the end product as closely as possible.
The most important part of using the final TEST environment is understanding how it fits in with the other environments. In SANDBOX, the configuration is practiced with until end-users feel it is performing optimally. The end configuration is then plugged into DEV to confirm that it works as expected.
TEST is used for two primary purposes: testing that you can successfully migrate the changes and to run though the full test scenarios required by your Change Control Process.
The final step is to use SDM and move your configuration from DEV or TEST depending on your Change Control process, into the end product. Since you are just moving the configuration and not recreating it, you can control the timing of the move such that it has the least amount of impact on the end product and its users.
5. Plan for Change Management
People resist change – it is a cliché because it is true to the extent that organizations often deal with significant internal resistance during the implementation of major systems, especially a system like Kronos which touches every employee. Therefore, dedicating a significant amount of time, energy, and resources into Kronos Change Management planning is key to overcoming natural resistance. Change Management is how an organization plans to help employees deal with the change and use the new software correctly. Change Management, simply put, is the process creating an effective communication and training plan to eliminate identified potential points of friction. If effective communication and education are implemented during a WFM project, you are much more likely to achieve buy-in from both management and end-users.
For more valuable information on WFM implementation best practices, download our whitepaper Successful WFM Implementation Strategies:
Comments