Dear Collabie: My large, global organization is planning to deploy Workday. Should we consider a phased approach?
– Phased and Confused
Dear Phased and Confused:
You're not alone! This is a great question and one that Collaborative Solutions sees often from our growing network of global customers. Each Workday deployment is inherently different based on the unique needs of the individual customer. Collaborative Solutions is well-versed in both single deployments and multi-phased approaches.
With a large, global organization, there can be many reasons to choose a phased approach. Below are some of the most common.
- Contracts with Other Vendors
If certain countries within your organization outsource business processing areas such as payroll or time keeping, for example, it’s possible that those external interfaces may not interface with Workday. If those countries are not yet ready to update the external interfaces, a phased approach would allow you the flexibility to update those services at a later date without delaying the overall Workday deployment effort.
- ROI or Cost Benefit
If your organization has employees or operations in a country with a small population, deployment costs may not be a financially reasonable investment or may pose a risk to the initial deployment go-live. In this case, a phased approach is the most cost-effective.
- Timing of Fiscal Processes
Depending on the scheduling of your organization’s fiscal processes (including Performance Planning, Compensation Planning, Absence, etc.), certain countries may have different schedules for some of these similar functionalities that may not line up with the primary country’s deployment schedule. In this case, a phased approach enables you to begin the Workday deployment without interrupting any existing schedules that would conflict. There are additional options to consider in this instance, such as deploying for all countries in Phase 1, but not rolling out the functionality to users until the timing is ready.
- Decentralized Functions
In your organization, other countries may operate autonomously from the US and/or may not be ready to adopt the new system. They may also anticipate that business processes will be so different due to country laws and policies that the organization needs to align the other countries before they are able to put the entire organization on one system. For instance, if certain countries in your organization have all of their HR data stored with their local payroll provider, they may not be able to access that information in time to meet Phase 1 deployment deadlines. In this case, a phased deployment would be more effective.
Mergers and acquisitions are another common reason to consider using a phased approach. If your organization engages in an acquisition or merger during or after a deployment, depending on the timing, it may not be possible to align all the business requirements, integration impacts, and data extraction processes with the initial deployment timeline and scope, making a single deployment challenging.
At Collaborative Solutions, we’ve seen it all. So, if you are considering deploying Workday and using a phased approach due to the reasons above or other business reasons, there are a several factors we’d urge you to consider for both the initial or ‘Phase 1’ deployment and the subsequent phases that would occur once in Production.
- Supervisory Organization Structure
This organization structure is the backbone of Workday’s HCM functionality. Your goal in creating the Supervisory Organization structure is to create organizations for employees based on ‘who reports to whom’ (i.e., employees belong to the organization managed by their manager). If your organization decided to deploy in only certain countries or organizations in Phase 1, there may be gaps in your supervisory organization structure if you have employees in your in-phase country that report to managers in the out-of-scope countries. These gaps may impact the initial design of the organization structure as well as any future business process events that route to the manager. Collaborative Solutions can help you analyze the multiple options to address this issue and select the best option based on your business requirements.
- Change Control of Production Environment
The general practice in a phased deployment is to take a copy of the Production environment into an Implementation environment, enabling all configurations, conversions, and testing to be performed without any risk of impacting Production data. This is a one-time copy, so any changes made to the Production environment will not be reflected in the Implementation environment unless the two environments are updated separately and simultaneously. It’s important to keep this in mind because it can be a risk when you ultimately do move configuration or changes from Implementation to Production. If a change was made in Production that was not made in the Implementation environment, it could be reversed when the conversion to Production occurs. For example, if a Job Profile title is changed from “Analyst II” to “Senior Analyst,” and all available options in the job catalog are part of the phased deployment, this will result in the change being reversed in Production to equal the value that was in the Implementation environment.
- Workday’s Conversion Tool (iLoad) Capabilities
Workday uses its iLoad tool to migrate and convert data from legacy systems. This tool utilizes different webservices to import or extract data from Workday environments into XML format. iLoad is a powerful tool when building a new Workday environment; however, some webservices do not allow for configuration to be updated. Since the tool also extracts ALL configuration or data, it’s important to realize that without reviewing the output in detail and identifying the configuration to move to the target tenant, there is risk of overwriting or duplicating configuration values.
- Security Configuration
Security configuration, like all other functional configuration, will likely be a big part of the additional deployment phases. If there are changes made to security configuration in the Implementation environment to accommodate testing, then it is important to reverse any of these changes prior to migrating the configuration to Production.
- Disabling Notifications During Production Loads
Once the configuration and data conversion process is finalized, tested, and approved in your Implementation environment and you begin to migrate configuration and convert employee data, it is important to disable any notifications in your Production environment to avoid having your workforce inundated with system notifications that are a result of conversion activities. Trust us – they’ll thank you for this!
I hope that Dear Collabie has helped clear up your confusion around phased approaches – why many organizations choose them and what to be aware of when you’re in the process of completing one.