Why readiness matters more than the software
When an SAP rollout in a plant goes wrong, the software is rarely the real problem. The usual causes are more ordinary: processes that work differently on each shift, master data that nobody trusts, and teams who were never asked what they actually need.
SAP is a powerful system, but it is also a strict one. It takes the way your business works and makes it faster, more connected and more visible. That is excellent news if your processes are clear. If they are not, SAP simply makes the confusion more expensive.
That is why the most useful work in an SAP programme happens before configuration starts. A short readiness check, built around five questions, tells you where you stand.
The 5W readiness check
The 5W lens
- Who
- Who will own each part of SAP in the business, and who will use it every day on the shop floor and in the office?
- What
- What exactly must change, and how will you measure that it has?
- When
- When can you go live without disrupting production or the financial close?
- Where
- Where should you start: which plant, line or function will pay back first?
- Why
- Why are you doing this, in business terms that the whole leadership team agrees on?
Who: owners and users
Every SAP area, from production planning to procurement and finance, needs a named owner from the business, with the authority to make decisions. IT can run the system, but only the business can decide how work should be done. Equally important are the people who will use it daily: supervisors, storekeepers and accountants. Involve them early, and adoption becomes much easier later.
What: the change you want to see
“Implement SAP” is not a goal. “Know our real inventory every morning” or “close the books in five days instead of fifteen” is. Write down three to five outcomes, each with a number, before you talk to any implementation partner. They become the yardstick for every decision that follows.
When: timing around operations
In manufacturing, timing is everything. Avoid going live during peak production, a major customer order or the financial year end. Plan training before go-live, and keep experienced users available for the first few weeks afterwards.
Where: the first place to start
You don’t have to change everything at once. Many manufacturers start with the area where the pain is most visible and the payback is clearest, often production planning, inventory or finance, then extend to other plants once the first rollout is stable.
Why: the business case
Leadership needs one shared answer to “why are we doing this?” Better margins, reliable numbers, less wastage and the ability to grow without adding chaos are all good answers. A vague answer leads to vague decisions, and to a project that drifts.
Warning signs that you are not ready yet
- Different shifts or plants do the same job in different ways, and nobody has written down the right one.
- Item codes, bills of materials or vendor lists are duplicated, outdated or kept in personal spreadsheets.
- The project is described as an “IT project” and the business heads are not involved.
- There are no measurable goals, only a deadline.
- Training is planned for the week before go-live.
Spotting one or two of these is normal. Spotting most of them means it is worth pausing to prepare, because every week of preparation saves far more during implementation.
What to fix first
- Agree the outcomes. Three to five measurable goals, signed off by leadership.
- Name the owners. One business owner for each SAP area, with time set aside for the project.
- Map the key processes. Document how work should flow, not just how it flows today.
- Clean the master data. Items, bills of materials, vendors and customers, before migration, not during it.
- Plan adoption from day one. Training, support and new routines are part of the project, not an afterthought.
A realistic timeline
Timelines vary with scope, number of plants and data quality. As a guide, a well-prepared single-business rollout of core areas can go live and be adopted in around six months. The work usually falls into these stages:
| Stage | What happens |
|---|---|
| Discover | The five questions answered, goals agreed, owners named |
| Design | Target processes, requirements and partner selection |
| Build | Configuration by the implementation partner, data cleaning and migration |
| Test and train | Real scenarios tested by real users, training for every role |
| Go live and adopt | Cut-over at a quiet time, close support, results tracked against goals |
The stage most often rushed is the first one. It is also the one that decides whether the rest goes smoothly.