A major aspect of any ERP initiative is ensuring the change management aspect of it is right and that employees are ready and know what they are getting. Here are five challenges you’ll probably face in an ERP project – and advice for how to tackle them.
Note: This article was originally written by Alyn Bailey and published on Pcubed.com
When an organisation intends to switch out its enterprise resource planning (ERP) solution, the potential problems are many. The new system is frequently intended to be used across numerous functions – accounting, marketing, sales, production, human resources – and by operations in multiple regions or countries. It may be a replacement for local applications and processes that have been in use for years.
A lot of emphasis is put on the technical nature of ERP projects; but managing the change aspects of a large and complex ERP implementation poses a number of challenges. As any change can involve uncertainty, anxiety, and fear; this is where a lot of these projects fail. In this article I share five challenges that tend to crop up in change management, and I offer guidance for ensuring that the approach is effective.
If the benefits to an organisation for undertaking an ERP transformation are vaguely or too broadly stated, it’s difficult to bring users along on the journey. The company leaders may spend a lot of time proclaiming that the new ERP system “will simplify operations across multiple divisions or regions.” That may look impressive on a PowerPoint slide, but individual users may be sitting in the audience thinking, “That’s all great, but I have this one supplier that I work with, and I’ve got a pretty good system set up, so why are we changing?”
Their quiet resistance can prove fatal to the success of the project. Furthermore, if the reason for changing systems is around cost reduction, this is an organisational benefit that is difficult to translate into an individual benefit for end users.
So what can you do? First, be honest. Don’t lie to the workforce. If it is a cost reduction exercise (e.g., a swap from one system to another), then say it is. However, look at the benefits the new system may bring – and focus on the day to day aspects that they will care about.
For example, highlight the simplified billing, better knowledge and access to customers, shared processes, easier data entry, and – probably as part of the data transformation process – you’ve cleaned and tidied up their data too. It may also help in moving task-oriented employees into more process-oriented ones – so they can see the efficiency in the focus on processes.
Let’s count the variety of people who may be affected by an ERP deployment and for whom the impact of change and the change journey needs to be considered. Internally, there are the end users – people in the business who will be using the new system. In any ERP implementation there is the balance of the importance of time and quality – rushing to get things finished to meet deadlines (or incur expensive and reputation sapping delays), balanced against the quality of what you will actually deliver to the end user.
Sometimes it is the quality that suffers, and this affects the end user experience. Also, the project itself will disrupt their day to day work. All of a sudden, there will be dozens or hundreds of project people rushing around their offices looking very busy and stressed whom they’ve never seen before and who are using up all of their meeting rooms and asking them questions about their work (often the same questions 10 times a day from 10 different people). That can make a big dent in business productivity – and on project reputation.
You’ll have people outside of the business groups who won’t directly use the new system but who may experience disruption during the transition. They too need to understand what’s happening and why. Then there are the various management teams with different reporting levels and governance structures. On top of those, there’s also the project team itself, which could have hundreds of people in it working across borders; they too need consideration.
Managing different stakeholder groups requires understanding where their heads are at, what ERP project success means to them, how it will really benefit them, understanding what keeps them up at night worrying about the project impact (if anything), how best to tell them what you need to communicate, and when to do it.
Doing effective and regular change readiness assessments is vital, to understand where the different parts of the business are and how ready they are for change. A Change Readiness Assessment is one of the key tools in the change manager’s toolkit.
These can be formal and take the form of surveys. They can also be less formal and take the form of focus groups. My teams tend to use focus groups because you can cover a number of key areas in just a short amount of time and get a flavor for the language they use and what really matters to them.
You can also be clear on any advocates or “blockers” – then use the advocates as “change champions,” and work to turn the blockers into advocates. In my experience, the change work in ERP projects takes a clear second place in importance to the technical side. You may be pressed for time in carrying out effective change readiness assessments; for this reason, see if you can use existing cross-organisational forums, focus groups or existing electronic survey tools.
While you’re developing that, don’t forget about the stakeholders outside of the organisation, including suppliers, distributors, partners, customers, and – depending on the segment – others such as government agencies, unions, and the media. Their sudden appearance in unexpected ways can derail ERP progress. At the same time, be aware of the limits of our roles and sensitive to existing channels. For example, there may be people within the organisation who have relationships with external stakeholders, such as the ultimate customers (your “customer’s customer”).
Don’t duplicate work they are already doing and thereby annoy them or their customers, and also if possible don’t increase risk by getting your change team to undertake this. Take a step back and figure out how to provide guidance to the corporate communications team accustomed to working with those groups, figure out what they’ll need, and let them be responsible for distribution of messages as they deem it appropriate.
Because of the variety of stakeholders, there’s no single most effective mechanism for communications. For example, email is great for broadcast; but when you really want to target a specific group, you need to understand how best to reach them and what they already use that works. The change team will have a limited number of people, which means we can’t cater to everybody.
So effective communication is also about making the most of the channels available. Besides email, there’s face to face, conference calls, existing meetings and forums, standard training, websites, intranet portals, country-specific portals with local language translation, and the central channel: piggybacking on other standing communications.
That requires aligning communications to make sure a) that a dozen project people aren’t separately asking the same questions of the business people; and b) that a dozen project people aren’t separately sending out a communication with similar information – or, worse, slightly different information. There’s nothing more confusing to a user than to receive the same email message seconds apart from two different people.
Need to rethink your return to work? Read more: Organizational Change Management and the Return to Work
Also, as in any project environment, ERP initiatives require developing tailored communications for specific audiences that take into account the culture of the organisations they’re in and their perceptions about what’s going on. As well as client organisational culture to be aware of, you’ve also got the cultures of any organisations within the project team and – in a multinational environment – country and regional cultures. If you don’t research these and tailor appropriately, it’s to your own peril!
At the same time, because it’s an IT project, you also have plenty that’s thrown into the mix that’s highly technical. It’s easy to slip into technical jargon, leaving your audience to wonder what you’re talking about. You can quickly alienate people by your language when all you’re trying to do is bring them on board and share the journey they’re now part of.
This is where the role of a “buffer” comes into play for the change management team. As well as being a key liaison with the end users controlling the flow of information, part of the role of the change management team is to act as a buffer between the normal company people who will be using the new ERP functions and the technical people who are excellent at what they do but may not be the best at relating to the end users.
Appraise your communications from the perspective of the recipient: How will they interpret what you’re about to share? Is there a way to explain the benefits or impacts of what’s about to happen in their terms, without resorting to talking about “migrating master data objects to the XYZ environment”?
One of the most basic and effective tools to engage end users and manage their expectations is by training them in the new ERP system. On any ERP project, a lot of the initial period is taken up with mapping the current situation, understanding the desired technical goal, and planning the project around this. For an end user, this can be frustrating. For months after a new ERP project has begun – and with all the fanfare, promises and pretty PowerPoint slides – they can’t actually see or feel what they will be using.
Training gives an opportunity for them to really interact with the new system. It helps them understand their role in the new system (and potential organisational changes), and training is a very effective way to work with the “blockers,” the employees who are resistant to the new system because they don’t understand it.
Effective training using a variety of methods (again, tailored to the audience) will help gain acceptance of the new system – including classroom based training, e-learning, trained “super users,” guidance materials and user guides, on-the-job coaching, and drop-in training sessions.
At the same time, with all the time pressures and technical focus, training can be seen as a tactical tool to just train users in the parts of the new system they’ll need to use. This is a mistake. It can also be used strategically for more far reaching organisational aims. The underlying question driving the training should be along the lines of “What competencies must fit for the future?”
Alongside the system knowledge, ERP training can be used to improve end users’ overall business process knowledge and better understanding of the new organisation and their roles in it, which will help in managing and running the organisation effectively.
Given the complexity of the typical ERP project, it’s no wonder there are delays – over half of ERP projects exceed their original budget and/or timescale. But it’s still tough to be part of the change team in charge of going back to people and saying, “Hey, listen, remember in May when we said everything was going well and you’d finally have your new software to try out in June? Well, actually, ummm, there’s a delay and it’s going to happen in August. But listen, this is why that’s actually a good thing.”
That can really dent your reputation. After all, you’re trying to build up advocacy and empathy in the end users so they understand and support what you’re doing even as you’re not necessarily delivering on your promises.
At the same time, often the change management team just won’t have all the answers it needs to address participants’ concerns. When you get questions you can’t answer, you have to be able to tell them when you will have answers, and then you have to follow up.
But I’ve found that the best way to maintain a trustworthy reputation is to continue to advocate for the end users. ERP projects tend to have very compressed timelines. Those involved in the implementation of the project tend to be highly focused on making sure that the schedule or budget status doesn’t move from green to red.
But the users don’t care about that; it’s far more important to them to have quality, since they’re the ones who will be stuck with it after the project goes live. While the project people are patting themselves on the back because the schedule was met or the budget was maintained, the users are turning on their computers and discovering where the corners were cut or where the quality has been sacrificed.
Being empathetic to the end user is a crucial role of the change management team. At the same time we’re being advocates, we also have to manage their expectations. People aren’t stupid; honesty and empathy are two essential ingredients required to tell them what they need to know.
The role of the change management team evolves as the ERP project evolves. Critical to the success of any ERP program is establishing the relationships with the key people within the project team and the key people within the business and acting as a portal for keeping those two groups apprised; feeding business concerns back to the project team, and translating what the project team is up to in terms that the business understands.
You’ll know you have found success as a change management team because you’re incredibly clear up front in terms of your strategy, your deliverables, the resources, the processes, and what you’re responsible for and not responsible for in terms of the change management team.
You’ll understand how the end users are feeling, what their major concerns are, and how the concerns will be addressed. Ultimately, your team’s job is to make the work of the ERP project clear and worthwhile to the users by preparing and taking them through the ERP journey and to help them embrace, rather than resist or be afraid of, the changes this will bring.
A monthly digest of our best articles on all things Project Management.