🎹 Music for this post: https://www.youtube.com/watch?v=XjZgiv2F1QY.

I apologize for the large gap in my writing. I’ve been focused on a large-scale ERP and WMS transformation that has been in the works for the past five years, and which was successfully launched about a month ago. This was neither a phased or parallel deployment; it was a “big bang” approach, and while it had its share of expected issues, we are all justly proud of how it went.

It inspired me to write this piece. I hope you find it useful.

---

There have been countless reflections about what’s important to focus on in ERP & WMS transformations, but after decades being involved in these events, I have my own take: an initiative like this is a lot like major surgery. I’ll do my best to show you what I mean in the paragraphs that follow.

With our most recent transformation, we didn’t do all of these things perfectly. But we did enough of them well enough to make a positive difference.

Part I: Mise En Place — Things You Need Before You Even Start

1. Ensure a Healthy Culture Is in Place.

When you’re having major surgery, you want to do everything possible to keep well in the days and weeks leading up to it, because it will take a toll on your body, both physically and mentally.

I believe all good corporate cultures are built upon the ten foundational values we focus on here:

• Vulnerability
• Humility
• Empathy
• Love
• Patience
• Compassion
• Curiosity
• Commitment
• Willingness

You will not be able to have complete and honest conversations if these values are not practiced. Additionally, culture requires hygiene; you must have pathways in place to review and nurture these values on a regular basis.

2. Why Are You Doing This?

Is your surgery elective? Or do you have a specific illness that requires addressing?

There are many reasons to switch enterprise systems, and too many of those reasons are not terribly sound. You’ve probably met people who want to bring a system from their last position to their new employer, with assurances based upon their “first hand experience.” But one person’s comfort isn’t a foundation for progress.

Senior leaders benefit from exploring this question every once in a while: What does it mean for our business to perform well? It’s good to follow this with: “How do our current systems support that?”

Even if your organization is not actively considering switching systems, teach your organizational leaders the skills to develop well-written user stories. This requires them to nurture their ability to think functionally, rather than technically. The third blank in every user story is the hardest to write…it is the most critical…and it is where you will best discover the answers to the questions we ask ourselves above.

Assemble your user stories into a backlog, and review the backlog often. If you find those stories are achievable with your current systems, it’s a strong indicator that a system change many not be in order.

3. For a Risk Like This, There Has to Be a Big Reward.

Is surgery the only option? Is it the best one?

Apart from familiarity for your newer recruits, another common rationale for a system change involves a hunger for something sexy and new. If your primary concern about your current system is its age, pour some water on yourself and read Things You Should Never Do, Part I by Joel Spolsky. Here’s a teaser:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?

Old software doesn’t rust. It may, however, not be able to handle the volume of business that you currently have. It may run out of memory and resources, and hardware upgrades may not be enough to address that sort of thing. The people who wrote it might have employed languages or technologies that you are hard-pressed to find experts in. The combination of both of these dynamics is a good example of a situation that calls for consideration of a system change.

4. “Buy-In” Is Deeper Than You Think.

Who will take care of you in the days surrounding your surgery?

A lot of writing on ERP implementations focuses on “Executive” or “Top Level” buy-in. That’s critical, but what does it mean? I’ll touch upon that in item 5. But buy-in from the next level of leaders — those who report into senior leadership — is as important, if not more so.

These leaders are the ones who are most actively engaged in moving your business forward on a daily basis. Their need or desire for change is the nucleus of any sort of organizational transformation. These are the folks who should be engaged in recording user stories as a part of their job. If there is a clear blockade in their backlog, they will know it before senior leadership does.

5. What Does Senior-Level Buy-In Really Look Like?

What specific things do you need from the people who will be taking care of you?

In preparing technology teams for ERP transformations, CIOs and other tech leaders are used to spending time helping the technology teams absorb a lot of the anxiety of the organization. After all, they are at or near the top of the support chain, and what is support, if not a friendly and responsive ear?

In our implementation, the president of our organization made clear that it was the senior team’s responsibility to own and manage the day-to-day anxiety of the people within their departments. This means that the senior team members were required to engage their people, to understand their fears, and, more importantly, to help them navigate those fears. In turn, this involved ensuring that each associate’s voice was heard, and that they stayed involved and trained and aware of the current state of things at all times, participating in the ongoing dialog.

In practice, that’s what senior buy-in really means: true ownership of the anxieties surrounding the change.

6. Do You Have Business Analysts?

Who is advocating for you in the days surrounding your surgery? Are they qualified with the right mindset to really look out for you, even if you wind up in critical condition?

Believe it or not, some businesses have never heard of the business analyst role. If yours is one of them, work hard to change that as soon as you can. In many cases, you will find that they exist in practice if not in name, scattered within departments across the organization, and you can create a career path for them by providing the title and career development support that will clarify their work and energize these individuals.

Many ERP implementations take key people out of each department for a period of a few years to temporarily support this function, but those people are typically important to the success of the business in other ways, and this can be quite disruptive. Plus, a good BA is a permanent role, and not a transient one. A good, well-empowered BA who enjoys the role will reduce the burden on individual departments throughout your ERP transformation, and beyond.

The best BAs have a lot in common with another job that is typically only seen at high-tech organizations: the systems engineer. A systems engineer is responsible for the engineering of a system of systems, which, no doubt, your organization is. Good BAs are familiar with all of the inner workings and departmental idiosyncrasies of your organization, and work to mediate organizational process change and compromise. No organization has written with as much passion and experience about the art of systems engineering than NASA, and of you want to know what to look for in a good BA, read Valuable Systems Engineering Traits and Behaviors at NASA’s Marshall Space Flight Center.

Here are some key traits:

• Willingness to work with people with different views, goals, and objectives.
• Sets clear system objectives.
• Holds the vision of what the end product should be, and communicates the objectives by being appropriately directive.
• Patiently makes sure that everyone is heard, including any dissenting opinions, before a decision is made.
• Builds trust by getting out of the way of team members so they can do their jobs.
• Gains professional respect by respecting others and building positive relationships.
• Willing to probe and ask tough questions, even if doing so reveals a lack of knowledge or understanding.
• Remains calm under pressure.
• Doesn’t over-react.
• Patiently listens to each team member or discipline expert in to assure that everyone gets heard and that all diverse opinions are considered.
• Frequent communication — daily, hourly, whatever it takes to keep the project on track.
• Welcomes divergent opinions by creating an atmosphere where team members feel the freedom to openly express their opinions.
• Looks for answers that may not be readily apparent.

7. Strong Leaders Know That Patience and Realism Are the Keys to Success; Lazy Leaders Lean on Deadlines.

Surgery is only a part of the solution. Are you prepared for the pre-op, the post-op, and the physical therapy? Are you OK with the fact that your body is unique…that all of the predictions are guesses…and it may take longer to get to a place where you are comfortable than you had planned?

Getting your organizational culture right — so that there is plenty of user story writing and regular conversation about backlogs — might take as long as two years. The process of selecting a vendor using this information might take another 6-12 months. Your subsequent implementation could take 2-4 years, depending upon a variety of things.

Too often, deadlines are arbitrary, and an easy way for people to set others up for “failure.” Our organizations have no tolerance for these sorts of deadlines. Shooting for a specific deadline on any of this is a fool’s errand, because the lowest common denominator will always be people, and if you have good people, you need to listen to them and honor their concerns.

If you don’t have good people, please go back to point #1. Doing things right is always preferable to doing them within an arbitrary timeframe.

Part II: Finding a Surgeon, and Establishing the Relationship.

8. People Matter

Take plenty of time to find the best surgeon for you. They not only have to be competent; they need to show you that they understand you and what you really need.

Software is more than code. It is the people supporting the code that matter even more. For each of your finalist vendors, make time to visit them to articulate your culture, and make time to have them visit you as well. Make ample time for this step; it matters. People who break bread together get to know each other better.

9. Care for Your Master Agreement & Statement of Work

Understand every aspect of your relationship with your doctors.

There are many things you will want in your Master Agreement with your ERP vendor. Many of those will be dictated by your organization’s vendor management standards, so I won’t spend too much time here. But others may not be so obvious.

One thing that I’ve learned over time is that it’s good to have a defined conflict escalation path in your Master Agreement. Consider three levels:

• Your Project Manager : Project Manager at Vendor
• Your IT Director or CIO : Executive at vendor in charge of delivery
• Your President/CEO : Senior Executive at Vendor

Beyond this, make sure you have a conversation about source code escrow. Depending upon the vendor, this may be off the table. But if your organization’s revenue is larger than your vendor’s, it’s especially wise to put some effort into this.

Also: consider a time & materials approach to your engagement. This is, in my opinion, the best way to ensure transparency in your relationship. There will be customizations that are more complicated than anybody imagined during the proposal phase, and your vendor won’t feel pressured to skimp or otherwise creatively shift resources in order to provide what you ultimately need…which is what happens all too often in fixed price engagements. After all:

If you’re having a tumor removed from your body and the surgeon needs an extra unanticipated hour to do what’s needed, do you want her to stop at the time she planned…or get it right?

10. Make Sure That All Key Resources Agree to Visit Your Business in Person.

In an ERP transformation, bedside manner matters.

While the COVID era proved that distributed teams are incredibly effective and happy, your ERP vendor won’t be effective if their resources don’t see your business operate in person…often. This includes everyone from professional services to software engineers. Watch out for ERP vendors who believe otherwise. They are wrong. See #8. Work this expectation out in your master agreement, or ignore it at your peril.

Part III: Some Things That Aren’t Like Surgery

11. What They You Do Versus What You Do.

One lesson I’ve learned over my years: The big guys (SAP & Oracle) are worthy of consideration for the areas of your business where you simply strive to be industry-standard. But if you have an area of business that is a distinctive innovation, you should plan on internal ownership of the software engineering behind it.

12. APIs.

Speaking of internal software engineering, make sure you carve out significant time to articulate your needs for APIs. Will they simply be access to stored procedures? Or do you want something more modern, like JSON? Make sure you set clear expectations in your master agreement or statements of work.

13. Take Time to Define Time.

You’re over a dozen items into this. Thank you for being a serious reader. Those of you who gave up before this will miss one of the most important points: the temporal aspects of enterprise software are given short shrift all too often.

Between dashboards and mobile software, there are areas of your business where you want your employees to have “real-time” data. Make sure that your vendor has a clear understanding of what that means, because data changes quickly, and it’s easy for the parties on both sides of the table to have completely different ideas of what “real-time” means. Work hard to get it right.

14. Teach it Right.

While your vendor might have some standard documentation that you can use as a basis for training employees, every organization is different. Consider adding an instructional designer to your team, for the long haul. This person can create training that is specifically geared to the idiosyncrasies of your business, including right-sized lessons and quizzes that fit into people’s work schedules. This learning can be programmed into a learning management system as a durable part of each employee’s human resource record, to help track and guide personal growth objectives.

Part IV: The Pre-Op & The Surgery

15. Your New System Will Never Be Like Your Old System.

Surgery has a profound and typically permanent effect on your body. Get ready for that.

Software is codified process, and when you replace your software, you’re replacing your codified processes. Unless you have an entire organization of people with OCD, you will never remember and appreciate all of the hidden codified processes your organization has. If you did have an entire team of people with OCD, you probably would never get anything accomplished anyway.

So remember that your new system will not only be different from your old system, but if you thought sufficiently about #2 and #3, it should underpin some key organizational transformations that you want to take place.

This is why….

16. You Will Experience at Least Some Disruption.

Surgery is not a cakewalk. That’s why we need anesthesia.

When you transform your organization, it will be uncomfortable, and in some places, you will not have thought about everything in advance. That’s perfectly normal, but you must plan for it and talk about it regularly in the years and months leading to your “go-live.”

Be honest with your fellow employees: change stinks. If you sugarcoat this, you will lose credibility. Create a collective understanding that there will be pain, and the more we work together as a team, the higher the chances we can absorb the pain.

If you don’t experience some discomfort, then you probably did something wrong.

Make sure to keep your business partners posted on the changes as early as you can. They may get paperwork and/or data from you, and they need documentation and time to prepare for the change as well. They will appreciate you being proactive.

17. Start Converting Data From Day One, and Do It Often.

There are many things you need to do to be prepared for surgery. Don’t waste a day without doing some of those things. Exercise, if you doctor permits it. Eat appropriately. Listen to your doctor about medications you should be taking and not taking. Get plenty of rest. Keep your doctors informed about any changes you notice.

The best ERP vendors will ask you to work with them to extract your existing data for transformation and loading as early as day one. The more you practice this, the better your vendor will understand your business. Even more importantly, you will maximize the chances of uncovering sporadic business issues that could cause you a lot of grief if you discovered them after going live with your new system.

18. Your End-to-End Tests Are Important, and It’s OK to Do Them More Than Once.

We don’t simply hop on an operating table. The pre-op exam ensures that our blood, heart, and other systems are in good working order to ensure good outcomes. Sometimes we discover that our medications need changing, or that we need some other treatments before surgery. Listen to the results, and make the required changes. Get tested again, and make sure everything looks good before the knife hits your body.

This is where enterprise systems and surgery are identical.

19. How Do You Know You Are Ready for the Operating Table?

I once had a kidney tumor that required that my kidney be removed. On the morning of my surgery, I woke up with an unexpected feeling: the excitement of a child on Christmas morning. I couldn’t wait to have my kidney (well, tumor) removed from my body.

The sure sign your organization is ready is the widespread (cross-departmental) desire to get the change over with. Until you have that feeling, you are not ready. See #7.

Another litmus test: Are your key resources able to take a vacation in the weeks before your go-live event? Or do you still need them there, every minute, to ensure everything goes right?

Hint: your key resources need a vacation before you go live, so that they are refreshed and have renewed energy to confront the challenges they will face. If this can’t happen, then you aren’t ready.

20. The Patient Needs Care, Feeding, and Physical Therapy.

Plan on some intensive care during and after surgery.

Your organization needs food, fuel, and love. They will need lots of round-the-clock care and feeding in the weeks following your transformation, which is why your key resources need a break before your go-live event.

21. It’s Never Really Over.

Your post-surgery body is different from your pre-surgery one. You’ll probably have to make some permanent changes to how you live.

One thing about software is that it’s designed to enable change. Otherwise, we would just build some hardware and be done with it.

Plan on doing a lot of listening to what your employees say in the months after you go live. If you did this for the right reasons (see #2 and #3), you did it because your organization needed to go in a new direction, and the emergent requirements that support that new direction will need evolution and refinement. Be cautious about requests to go back to the old days, unless that’s truly what you need.

But once the dust of your implementation settles, make sure your key resources take some time off. Vacations provide clarity, and the superheroes who got you to where you need to be deserve a break, and perhaps even a glass of their favorite beverage.

Cheers!

Discuss this specific post on Twitter or LinkedIn.