Lean Into the Impact of Go-Live with User Adoption

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:

1. "how much of an impact will there likely be and where?" And, 
2. "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:

1. 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.
2. 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.
3. 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.