Workday is an on-demand platform used for financial management and human capital management (HCM), as well as enterprise-wide data analytics. In 2017, it seemed as though the software company had hit the big time. Amazon was preparing to sign on as a client, which would thrust Workday into the global spotlight.
However, after a failed HCM implementation effort, Amazon ultimately abandoned the project after just two years. The two companies agreed to part ways, announcing that they may revisit the project at some point in the future.
What happened between Amazon and Workday? How can you avoid the same problems in your own implementation? Today, we’re breaking down all the details you need to know.
The Amazon and Workday Partnership: A Brief Overview
Before partnering with Workday, Amazon relied on a different HCM system to meet its enterprise needs. The new project would enable them to migrate that platform over to Workday, which offered functionality that Amazon needed.
However, Amazon eventually scrapped the deal and returned to its original software vendor. While some of its sectors do currently use Workday, the implementation was nowhere near as widespread as first imagined.
Some experts chalk this up to the fact that Amazon is a monolithic market presence. Its presence is widespread across geographical locations, and any enterprise software project built to that scale would naturally be full of risks.
Plus, Amazon’s IT staff is known for holding its projects closely, preferring to build their own solutions rather than partner with third-party providers.
Still, this isn’t the full extent of the story. Some insiders suggest that the real reason behind the split is that Workday’s business software couldn’t scale fast enough to keep pace with Amazon’s lightning-quick hiring process. That comes as a surprise given Workday’s expertise in cloud-native technology and HR tech. Clearly, the “jury may still be out” because Amazon hasn’t spoken publicly about this claim.
For its part, Workday revealed that the fissure resulted from Amazon’s custom business requirements, which differed significantly from what Workday is built to deliver. As a software-as-a-service (SaaS) provider, Workday operates on a core architecture and process model. It cannot easily or economically alter that approach to accommodate a single customer, even one as large and prolific as Amazon.
We have multiple software expert witnesses available for provision of reports, depositions, and testimonies.
3 Lessons Learned From This Workday Failure
Aside from the nitty-gritty details behind the failed implementation, it’s important to understand the big-picture issues at work. Let’s look at a few of the key lessons learned, and how you can apply those principles to help your own enterprise software project succeed.
1. Begin Data Migration Early so You Can Address Issues
Any time you are tasked with migrating data across a major enterprise, it can be exceedingly difficult to consolidate, clean, and successfully transfer everything. It becomes even more challenging when you’re at the helm of a major global company, like Amazon.
There should be plenty of time, money, and energy devoted to data migration. Make sure you have the right people working on it and they have enough bandwidth to do their job effectively.
If they run into any issues during the migration process, work to address them as soon as possible. Saving migration until the last minute could leave you without the resources required to course-correct if something goes wrong.
2. Communicate Custom Requirements Early
If Workday’s claims are true, then it was Amazon’s unique business requirements that ultimately derailed the implementation. Workday representatives said that these needs were discovered well into the implementation. If that’s the case, then the time and cost required to re-work the project would have been substantial.
In some cases, these personalized requests can be too far outside of the vendor’s realm of expertise. However, breakdowns usually occur because these customizations aren’t fully discussed at the onset of the project.
If you know you need your enterprise software to perform tasks that are outside of its core functionality, then share those requirements with the software vendor before signing onto the partnership. This way, you can be clear on how those customizations will affect your budget and timeline, and there won’t be surprises down the road.
3. Understand Project Risks
(Read our ERP vs HCM blog post to learn more.)
Needs may change halfway through the project. Critical team members might leave the company or switch roles. Business requirements may shift, expand, or shrink.
The project team needs to anticipate as many of these changes ahead of time and put measures in place to prevent the project from backsliding.
Especially in high-growth companies like Amazon, risks like these should always be expected. There will undoubtedly be personnel changes throughout the project, especially if it spans multiple years as this one did.
At the same time, there will also be adjustments to the project scope. If both companies are ill-prepared to navigate the expanded scope, then the effort could go off-course.
By performing a thorough risk analysis at the start of the project, you can anticipate the HCM implementation risks that could undermine your project.
Avoid These Risks in Your Enterprise Software Implementation
The split between Amazon and Workday was high-profile. Yet, separations like these happen on a regular basis between clients and software vendors.
If you’re preparing to implement any type of enterprise software throughout your organization, apply these lessons and avoid making the same mistakes.
Our enterprise software consultants know what it takes to ensure a successful HCM implementation, and we’re here to help you achieve the benefits of digital transformation. Contact us below for a free consultation.