Those of you old enough to remember the 1990s and who were involved in the ERP business then might have seen some of the materials that we produced when
our company was founded. Program managers who were implementing the relatively new ERP versions received some very strange marketing materials.
We sent out mock speeding tickets to 200 ERP program managers with the strapline “Are you driving your ERP programs without due care and attention” and when you ripped off the perforated sides, it said, “Follow the Enterprise Code”.
After having gained permission from Her Majesties Stationary Office (not kidding) to develop a booklet that looked like a highway code, we published The Enterprise Code in 1999.
The book covered how to
effectively perform business change management at every stage of an ERP project, and each of the chapters had a driving test set of questions printed on overhead projector acetate to help you conduct reviews to realign your approach to business change management.
Over 24 years later, we came across 5000 copies of it in an archive store. I thought I would see what has changed. Read that again because nothing has changed. No really, nothing has changed!
So I thought about sharing the lessons in the context of ERP in 2024.
Assessment
During the feasibility and sizing stage of the project, we identified three areas of focus – defining clear objectives for the people change; ensuring integration with other people initiatives and quantifying the organizational benefits.
Define clear people objectives
In the ERP world, we are still coming across clients who do not know if they are implementing a business transformation; a technology-driven change or a hybrid. This often leads to an expectation on the business change workstream that they will redesign the whole impacted organization based on the 'to be' system processes they are given. Business transformation programs have a number of components, with technology being an enabler, that so often define an operating model top-down, which is very different from conducting an impact assessment based on technology.
It's important to define which type of journey the program is upfront – operating model; technology or people-driven – this defines if it is top-down or bottom-up in terms of the people objectives and approaches.
Integrating all people initiatives
For back-office programs, integration with other people initiatives is often centered around which comes first debate, the ERP or the shared service center. Again, in the ERP world, we are still seeing programs that try to define a set of system operating principles used to define processes and roles, but which have not been linked to the companies' overall functional initiatives or job families.
Integrating with other people initiatives is still as relevant now as it was then. The types of initiatives may have changed, but the need to integrate has not. It is important to map jobs and roles across to use as a common currency for linking them together.
Quantifying the benefits
Back in 1999, we could not have predicted the financial crisis ten years ahead, but from 2008 onwards, most organizations had to become very good at baselining FTEs, setting targets and tracking against them.
We identified the need to define benefits down to the individual department level. The context back then was that ERP vendors would often quote figures like 30 percent improvement in productivity, without pinning it to specific places and teams in the organization. That 30 percent might be spread across an entire organization, meaning that it was sometimes just absorbed and not tracked.
From our experience with automation, we have methodologies with good tools for identifying benefits, because they are often deployed at a team or department level, and in many cases, the budget for them has to be found from within the area that is deploying them.
If we use these bottom-up practices, the best way to establish a proper benefits model for an enterprise-scale implementation is to build a network of benefits champions who can contribute to a ground-up model which reflects the true summation of all the specific benefits.
Tracking benefits realization down to specific business areas is more important than ever to avoid the disappointment of realizing that your beautiful generic benchmarks don’t stack up in the real organization.
Design
During the design phase of a project, back in 1999, we identified three key areas of focus – scoping out the full set of change management disciplines mapped to a full coverage of stakeholders when assessing them; respecting business unit variations and building a sustainable plan beyond go-live.
Full scope of change management disciplines and stakeholder identification
Back in 1999, the Rubik's cube was still in its teenage years in terms of commercialization, but for us, the cube was a great way of visualizing the dimensions required to assess business change.
Functional and business areas were a typical audience breakdown used back then to identify communication and training requirements. But for us, that was a very linear view of the issues.
We mapped these to a second dimension, called change disciplines, which contained all the possible elements of change impacts including organization structure; job and roles; HR elements including workload; objectives; competencies and behaviors and of course training and communication.
We then mapped to a third dimension called stakeholder groups which contained every possible type of people impacted, from director, middle manager and user, but also customers, suppliers and other non-users.
This was quite revolutionary at the time, but the problems we still have in business change in ERP are still caught up somewhere in those dimensions, so we still use that model.
Defining the business areas; the levels of people within them and the vast range of business change issues into types (organizational structure, HR-related, behaviors, competencies, skills) can provide a more focused approach to identifying change actions.
Business unit variations
Back in 1999, we worked with a lot of projects that took a blanket approach to working with users across all business units – one training approach for all users. We encouraged projects to consider each business differently and to work with local contacts to understand the variations.
Nowadays, we have the concept of superusers and champions who can help us navigate change in every part of the business. ERP technologies also now involve deploying functionality through mobile devices to operational teams, who themselves have very different needs from office-based staff.
For global, multi-business or multi-functional programs, sophisticated methods that take a common design and roll it out using a “fit-gap” approach into each business nowadays have change impacts and actions considered for each business.
But we still see projects where a particular business is dominant in the design, and where each “roll-out” becomes difficult because of lack of involvement from every business impacted. At an early stage of the project, we encourage our clients to do a light “look head” impact assessment across all the impacted scopes to take an early view of the challenges ahead.
For long ERP journeys or with complex geographies or business units, it is good practice to look ahead early at the overall impact on each business unit specifically, so that we don’t underestimate the differences when we finally roll them all out.
Focus on what post-live looks like earlier
Back in 1999, the concept of an ERP competency center was very new and the concept of an ongoing support framework often consisted of a part of the project team and a few of the superusers forming an enhancement and support team.
There was always a mad panic too close to go-live, to figure out what the support model should look like.
Eventually, projects included hypercare /warranty stages at the end of the project to ensure a smooth handover into a business-as-usual state beyond the go-live, and as a result, have had to develop the support model (internal and external) to ensure that there was something at the end of the hypercare to hand over to.
We encouraged our clients to think about the organizational models and processes during the design phase where decisions could be formalized early, and there was time to develop new roles, recruit and even involve the support teams during the project.
But even now, we still work with project teams who have not committed the resources and time early enough to figure out who will support the model and often who will govern the data post-go-live.
Don’t just focus on the “as is” parts of the organization that are impacted when planning the changes – define new parts of the organization which will need to exist post-live as well, and if you don’t know what they are, ask your integrators or reference sites what good looks like.
Develop
Nowadays, the build phase of an ERP project looks very different, with agile methodologies being deployed, and more sophisticated tools for configuring and taking the design into testing. But the people change challenges are still there.
Back then we saw projects which were managing most business change issues proactively, meaning that the loudest business unit often got the attention – process team members and SMEs were often pulled into last-minute panic situations to clarify the design or help resolve issues. We encouraged our clients to use a formal approach to define that impact; create an early resource plan for the time required by all parties; and define practical action plans driven by the local business areas.
Planning for organizational changes and impact
If you look at a job profile for an ERP change manager nowadays, you will probably see business or change impact planning in there somewhere. Back in 1999, the approaches we developed to assess people impacts in a coordinated way, using the dimensions we previously mentioned, were seen as revolutionary. We proactively engaged HR early and filtered out the big impacts that would shape the organizational structure and the big HR impacts that needed policies such as workload, recruitment and retraining. These had a long lead time and could be started before the traditional job and task level impact assessments that could be conducted later, during design.
Most integrators will recommend a business impact assessment that includes an assessment of people impacts.
But despite all of that, even as recently as last year we were still finding projects that do not have a clear plan for managing the people impacts, and at worst have not identified them properly during the development stage.
If you can, conduct an early organizational level impact to flush out major changes and then plan for job impact workshops once the design is starting to lock down, and get buy-in to a set of workshops covering every process and every business – don’t just put “business change” as the last item on the agenda of a process workshop!
Estimating SME and process team involvement
This one sounds quite trivial when you say it, but by the development stage of a project, your process teams or SMEs are probably entering the peak of workload managing outstanding design issues; unit testing and looking ahead to Unit Acceptance Testing and cutover. The last thing they need is some last-minute change team requests.
Back then, we asked a simple question early in the project – how much process team time will you need to support business change? And we estimated it by looking at the number of impact workshops needed across the number of sites and how complex each one was. Not in exact hours but using rules of thumb so that at least the expectation was set early.
So I can confidently say that in 2024, nothing has changed and in every project we come across the process team and SME involvement required is underestimated, particularly in the development phase where they are needed to support educational materials, impact assessments and job and role level information.
Plan for process team/ Business SME involvement required for business change even if you have to use some rules of thumb to estimate time. Best guess estimates are better than not having time planned at all.
Coordinating actions at department level
We mentioned back in design that today's projects are a lot more organized in terms of having the concept of Superusers and champion networks. We worked with Superusers back in 1999 who represented local businesses and departments.
We worked with many of them to agree on a defined list of actions they would need to support to become ready for go-live. That was called a go-live checklist and there was often governance built around it to make sure that everyone delivered.
I blew the dust off one of those go-live checklists from 25 years ago, and guess what, nothing was different from today apart from the technology section, which now has additional technology related to the evolving world we live in with cloud and other technologies.
The rest of it was about coordinating people actions (training, communication, HR, job and role activity); process actions (resolving local issues and updating documents); technology (as discussed) and sometimes facilities.
Use readiness checklists for every impacted business area to track the progress of their local business change actions and put strong governance in to track progress.
Delivery and Go-live
Delivery is where whatever seeds have been sown or not sown earlier for business change will come to fruition. For the process teams, it's often all hands to the pump on UAT; data work; cutover planning and migration, as well as resolving process issues. Things may start to become de-scoped.
Plan beyond the Go-live
Back then, we identified that there was a world beyond Go-live that was either going to run proactively or reactively. But getting the time to talk about it in the chaos of delivery was often too late. So we always approached the support organization or competency center discussion as an impact that needed to be discussed during the design phase, as one of the areas that you need to make an organizational decision about. This includes decisions about who owns support and who will own data quality and governance.
In our current market of FTSE100s, where programs might be upgraded or cloud migration done, there is often a defined process for hypercare and a handover to an already present support organization (in-house or third party).
But for mid-market ERP where the client is implementing for the first time, we often work with the need to transition a local IT application support group into an ERP-enabled support organization. All too often though, this is only thought about during delivery.
Start talking about the foundations that will be required to exit hypercare back in the design phase where you have the time to set up any new roles or third-party support relationships. This might include discussions about ownership of support and data quality.
Cascaded training and comms
Back then, we thought it was quite revolutionary to use a “train the trainer” approach to delivering the training and cascading communications about what was changing through management populations – we used a “stop, start, continue” briefing guide for managers to explain to teams what was changing for them in terms of processes and responsibilities.
Nowadays, a default setting for an ERP project is to engage through a superuser network to get involved in training definition, design and delivery. Some of the ERP learning technologies make it very easy for superusers to get involved with developing training content as authors, and in delivering it.
But in many projects today, we still see gaps in areas of coverage for superusers and it's very rare to have a complete network of superusers covering every part of the impacted business.
Use existing networks of business analysts or superusers, or build up new governance during the early stages of the project. They might not have much of a role in the early stages but often welcome being a part of the early engagement. Once in place, you can then fire them up faster when needed.
Improvement beyond Go-Live
Back in 1999, we started saying “this is the start not the end of your journey”. Back in the 1990s when change management was often just communication and training, go-live was sometimes the start of the chaos. We used to say back in the design phase “you can sort the people issue now, proactively, or later in a more reactive way. And the reactive world some chose included goods not being shipped because everyone thought everyone else was performing a crucial task, or a third party distribution channel which had not been engaged was asking where the old paper forms were. The problem was that the project budget had often evaporated by then, so business people had to take the hit and invest time in improvement.
Today, we see a lot more involvement of Business as Usual improvement and business analyst teams during the project, who naturally get involved after go-live to ensure that upgrades and ongoing maintenance take place. But we still don’t see many projects where a significant amount of the project team will be around post-live to conduct ongoing assessments and reviews and to ensure benefits realization by reviewing quarterly.
Engaging with Business As Usual (BAU) improvement and support groups right from the early stage of a project can often ensure that those people who naturally have a BAU improvement role can take that forward beyond go-live, because they naturally have a budget and a brief post-Go-Live.
A lot has happened for all of us since we published our driving tests in 1999 (some people reading this might even have been born in that timescale!) but every single risk we identified and every recommendation we made is still valid today.
I don’t know if we should be concerned about this, but the good thing about ERP projects today is that there is mostly a recognition that business change management is an important component, even if the spend on it does not quite reflect this!
The overhead projectors that we used for the reviews became projector images and then later LCD displays, so our acetate content is now embedded somewhere in Microsoft Teams in a digital form. Even if they are quite old, I don’t think there is a single principle that doesn't apply today.
We would recommend all of them when deploying an enterprise-wide ERP program, so it's still good practice to “follow the enterprise code” even after all these years. Safe driving everyone!
