When evaluating any large ERP project and its go-live strategy, especially an SAP implementation, leaders should be informed there will be some impact on their operations. Since it will happen, it’s not an “if,” so don’t call it a risk. Instead, the right questions to ask are:
- “how much of an impact will there likely be and where?” And,
- “what can we do to minimize the impact and duration of the “J” curve before we’re back to normal or even realizing improved operations?”
This article will address the underappreciated side of implementations, user adoption, which according to ASUG, is the #1 reason implementations succeed or fail. And for the record, user acceptance is not enough. You can accept something you don’t like and still be forced to work with it. User adoption goes beyond acceptance; it occurs when users become advocates, even delighted with the new efficiency, manual work reduction, empowerment, and so forth with the new solution. Just like an organization has project workstreams by process areas like Finance or Sales, the Change Management team leads user adoption. In addition to the classic functions of communications and training, a Change Management team should be present in every project of any material size and scope, especially where end-users or customers are involved.
Simply put, if users are engaged and on your side, you can get through most anything! However, if the users aren’t engaged, consulted for feedback, equipped, and trained, it’s a sign of trouble. Worse, if they are not ready to go through a short transition period where kinks need to get worked out before it gets better, your organization will have significant change management issues to deal with in a short amount of time. Lack of user acceptance (a prerequisite for user adoption) is a recipe for disaster that lands most companies on the front page and sometimes even bleeding on the P&L statement for that quarter.
Where do you start with change management? In the beginning, of course.
Brand the Project and Build Engagement
Companies that like to compete give their “enemy” a name. It could be an internal foe such as complacency or “old ways,” or a true competitor in the marketplace you want to take market share from. For example, Apple chose Microsoft as its “enemy” in the desktop wars as a way to rally the troops and unite under a common cause that could take years of battles to play out before declaring victory in the war. Similarly, commanders know there will be injuries and setbacks along the way, so they strategize to minimize those impacts. When well-equipped armies are also armed with high morale, they rarely fall. Also, troops with high morale and a shared mission to achieve can overcome well-equipped armies. See the common thread there?
Branding your systems integration project serves several purposes:
- Creating a simple internal marketing campaign is an overt statement from leadership that this project is not business as usual. Creating enhanced communications and seeking input from business users – raises organizational awareness that the project is a priority.
- Engaging all levels of the organization in the project’s goals and objectives creates mutual ownership and accountability. Too often, systems enhancements are seen as the property of IT. That impression is often reinforced by IT’s inability to communicate within a given organization effectively. Outreach and effective communication initiate the process of transferring system ownership from IT to business users.
- Branding generates excitement and team cohesion. SI projects are a grind – they are rarely executed perfectly to plan. Teams often face times of stress and conflict. Creating some simple artifacts of the project (inexpensive tee-shirts, coffee mugs, trinkets) builds a sense of unity that the organization is unified and operating as a team.
Call it what it is, a significant change. The project or digital transformation program has a name, so plan and communicate about the go-live accordingly. Do what you can upfront to imagine the weeks leading up to go-live, the first few days, and the first few weeks after go-live until you’ve executed all your recurring business processes a few times, including the first month-end close. For example, from the business side, if you are a manufacturer and can produce more products ahead of a go-live period, consider buying enough materials in advance and planning enough labor and storage to make up for an expected dip in productivity. This pre-planning removes the sourcing and manufacturing delay while having ample stock sitting on shelves ready to ship until prior productivity levels are achieved after go-live.
Involve and engage your team from the beginning, giving them a sense of input and responsibility for ensuring their concerns get heard. For example, if they do something 200 times a day, the project team should know to address that in the design and performance requirements of the new system. Ensure that they walk through every “happy path” scenario (what happens when everything goes right for the 80% use case) as well as every exception scenario (what shouldn’t happen but does happen every so often).
John Kotter, one of the leading scholar-practitioners in the space of managing change, said, “The true purpose of Change Management is not just to communicate, train and support end-users. Indeed, any process of Change Management does all those things. However, a truly effective process of Change Management should have as its goal the transfer of system or process ownership to business end-users. Only through comprehensive user engagement is this goal achievable.”
Next, and I can’t stress this enough, involve them as champions in the project, from the initial planning and blueprint, through development, testing, and cutover preparation if at all possible. Suppose you emulate what marketing focus groups do, giving unfiltered feedback on a product before getting greenlighted to go to development and asking them to do the same on your proposed solution. In that case, you’ll filter out the vast majority of issues lying in wait for the first day of go-live.
The creation of an organized network of superusers is an invaluable tool for long-term project success. A fundamental weakness of many ERP integrations is the failure to engage business users early in the project lifecycle. Business users have a vested interest in the proper configuration of any new system. At launch, system functionality ownership is transferred to business users and will affect commercial success or failure.
In many projects, assumptions about use cases and business needs are incorrect and directly affect the business’s perception of the integration team. By fully integrating select business users in the project and creating power users within the business, course correction on functionality or configuration can be quickly achieved.
Superusers serve as the first line of defense in organizational communications. No project is perfectly executed. Large-scale transformations face periods of conflict and indecision. When frustration peaks, corporate rumors can have a destructive effect on team morale and leadership’s confidence. Influential business users integrated into the team can take leadership in quelling misinformation and provide organizational leadership with a credible perspective on the challenges the team is facing.
During training, superusers are effective class proctors for instructors. Business users who fully understand process design can effectively translate the theoretical to the practical within their given organization. At go-live, they should serve as the first line of support so that when end-users have trouble, they will be supported from the office or cube next door instead of calling a support desk.
Listen and Give Them What They Need
Of course, give them proper training, including in-person training as needed. Videos. Job aids. Visual reminders and signs. Stickers. They will dedicated time away from their day job to complete project activities and training. Give them a sandbox or training system and tools to practice their new and updated processes and transactions.
Communicate and remind them regularly of the upcoming change. Then also accept, no matter how much you’ve prepared and communicated, there will be plenty of reasons why productivity will be down for the first few weeks as they get used to the new ways of working. They will have to adjust to a new pace, processes, tools, terminology, and even people they need to interact with daily.
In any significant go-live, where technology and process changes become real for the first time, mistakes will be made. Orders will be delayed. People will be working more slowly than before and with less confidence. They will probably need refresher training or a job aid. Employees will often get frustrated because they aren’t instantly proficient with the new processes overnight.
Their excellence with the previous process and technologies was a source of pride (and job satisfaction). So, as a leader, what can you do to turn this mountain, whether real or imagined, back into a molehill in your company’s SAP journey?
Change is difficult. People are hard-wired to resist and challenge the uncomfortable. While every change generates a dip in performance of some duration, a well-executed change management process can minimize business disruption.
Once they have recovered productivity to prior levels, the next goal is to achieve the higher level target. Remember to celebrate the win together! Depending on the go-live, this target may be expected quickly out of the gate or take a month or two to see actual numbers after daily, weekly, and monthly metrics are taken into account for comparison purposes. Whatever the horizon is to both recover and see improvement, let your team know it’s okay; you’ll get there together by crossing off problems every day with an attitude of continuous improvement.
An interesting thing will happen: theory will meet practice. Your team will quickly begin providing feedback not only on what doesn’t work so well, but as the users understand it better in the context of their jobs in action every day, they will make intelligent, practical recommendations for how to improve the solution. Something that was designed with good intentions may have a much simpler solution in practice. For example, pre-printing labels for receiving all the units on a pallet was a well-intentioned design point. But based on daily flow and errors made with printing too many labels at scale (especially when they are wrong) when a pallet has dozens of units on it, they simplified the process to print just five labels upfront: one on each side and top of the pallet.
On the one hand, many managers will resist wanting to seriously consider these recommendations for changes because they worry about stabilization. Balance that focus on stabilizing operations with the benefits of implementing said changes. Is it a small change, that if scoped and implemented correctly, can have a considerable impact quickly and doesn’t require significant redesign work or a maintenance window? This analysis is the job of a Change Review Board in the PMO. Listen to your users, and show it by giving them honest, thoughtful, and timely feedback on their issues and requests. Even if you have to say “not yet,” make sure they know they are heard and their suggestions are valued.
Conclusion
Organizations do not invest millions of dollars in an ERP transformation effort to get the same results with the legacy system. They invest this capital in reaching a period of sustained innovation. True transformation is impossible without acknowledging and planning for the impact of change on end-users. Investing in an effective change management process speeds user adoption and enables the rapid achievement of enhanced performance.
By doing the above, you will have minimized your chances of having a failed go-live for the #1 reason cited by ASUG members; lack of user adoption. Not because the technology doesn’t work, but because users rejected it. Because it wasn’t designed well. It wasn’t tested well. They didn’t have representation. They didn’t get timely communication about go-live, so they didn’t want to be there for it. Users didn’t get adequate training. Users might have felt all the responsibility to somehow keep up their previous numbers despite having to transition to a new system, process, device, and an updated web of people they are dependent on to be successful in their own eyes.
Remove all of these reasons for lack of user adoption, and your go-live will be well on its way to our target go-live scenario — quiet and boring. Users will feel empowered. Productivity will recover quickly, and new business performance metrics and benefits will be achieved faster than expected. After the dust settles from go-live, also remember to take a moment and celebrate your go-live after months (or years) of work. Have a party or get-together: your team, including your end-users and partners, have earned it!
American Digital is a steadfast advocate for making implementations successful and go-lives as quiet and boring as possible. Addressing the critical workstream of Change Management in digital transformation and SAP programs is part of the industry best practice to accomplish those objectives. We work with Change Management experts like John Grant, Ph.D., Managing Partner at EmTeeGee Partners, a change management consulting firm (emteegee.org), who we thank for contributing to this article as always.