Picture the accounting manager at a mid-sized manufacturing company. For years, the same ledger books, the same paper folders, the same routine. Then the owner walks in and says: ‘We are putting in a new system. Everything goes into the computer.’ The manager nods, but the thought running through her mind is: ‘Will I still have a job after this?’ That moment — not the server installation, not the software license — is the real starting point of an ERP project. The technical side of setting up an ERP (Enterprise Resource Planning) system is manageable. The human side is where most projects quietly fall apart.
A change management plan is a written document that spells out how employees will be informed, trained, and supported as the company moves to a new system. Many small and mid-sized businesses skip this step entirely. The assumption is that once the software is live, people will figure it out. In practice, what happens instead is that the accountant avoids opening the program, the warehouse clerk enters data incorrectly, and the sales rep goes back to the notebook. The system runs, but the business does not move. Writing a change management plan before go-live is not bureaucracy — it is the difference between a project that sticks and one that gets quietly abandoned.
The first element is a communication schedule. Every person affected by the new system needs to know what is coming, why it is happening, and what it means for their daily work. This is not a single announcement; it is a series of touchpoints throughout the project. Face-to-face meetings, a notice on the bulletin board, a memo sent by fax — whatever channels the company uses regularly. The first communication should answer four questions plainly: Why are we doing this? Who will use the system? When does it go live? Will anyone lose their job? That last question matters most. Leave it unanswered and rumors will fill the gap faster than any official message can correct them.
The second element is a training plan. Not everyone needs the same training. The accountant learns invoice entry and payment screens. The warehouse supervisor learns stock receipt and dispatch. The sales clerk learns how to enter an order. Training works best in small groups, sitting in front of an actual computer, working through real tasks. What sounds clear on paper becomes concrete only when hands are on the keyboard. The training plan should be written down: who attends, what they cover, when, where, and for how many hours. Without this document, sessions get postponed, some employees arrive at go-live having seen the system only once, and the support load on the implementation team becomes unmanageable.
The third element is a resistance map. In every company, some people will push back against the change. This is not obstruction — it is fear. The resistance map answers one question: who is most likely to resist, and what are they afraid of? The senior accountant may worry about losing authority over the numbers. The warehouse foreman may feel that his years of experience are being dismissed. An older employee may simply feel lost in front of a computer screen. Identifying these individuals before go-live allows the project team to have quiet, direct conversations with them early. A lunch, a one-on-one meeting, an honest explanation of what will change and what will not — these small investments prevent much larger disruptions later.
The fourth element is a key user network. From each department, one person is selected as the key user. This person learns the system before everyone else, takes an active role in training sessions, and becomes the first point of contact for colleagues who have questions. The right key user is not necessarily the most technically minded person in the department. It is the person others trust, someone patient and clear in explaining things. Because key users carry extra responsibility, they also need recognition. A word of thanks from management in front of the team, a formal acknowledgment of their role in the project — small gestures that keep motivation from fading during the long middle stretch of implementation.
The most common mistake with a change management plan is treating it as a document to be written once and filed away. It should be a living record: updated as training sessions are completed, annotated when a resistance conversation takes place, revised when the go-live date shifts. At the end of the project, this document becomes a record of what happened — who was trained, what problems came up, how they were resolved. For a small business owner considering an ERP investment, the question worth asking is this: you have budgeted for the software, the consultant, and the hardware — but how many days have you set aside to prepare your people? The answer to that question will shape the outcome more than any technical specification.
This article was originally written in Turkish by Gökhan MERCANOĞLU on May 20, 2002 and has been automatically translated into English and other languages using machine translation.