The warm-up is that part of the workout where your body negotiates with you to go back home.
It begins almost immediately. The intention is sincere, the schedule has been blocked, you have worn the right shoes, carried the water bottle, and declared to yourself that today you will be disciplined — and within five minutes your hamstrings file objections, your shoulders remember old grievances, and your knees suddenly develop a philosophical opposition to effort. Nothing heavy has started yet. No serious work has begun. And still, this is when resistance is at its peak.
Not during the lift. Before it.
My trainer has this habit of telling me stuff that I just don’t like, especially at that specific moment when he is — the warm-up isn’t conditioning your muscles, it’s testing your commitment. Your body is quietly asking whether you truly intend to do what you confidently declared at the entrance. And some days I strongly dislike my trainer. It’s a very particular irritation reserved for the person who is absolutely right, sees what you are avoiding, refuses to indulge your explanations — and is also the person you are literally paying to make you uncomfortable.
And this is exactly what the client begins to feel about us when we start Business Process Mapping.
The project has already had a confident beginning. Leadership has attended the kick-off. Timelines have been discussed. Everyone agrees the organisation needs structure. The vendor presentation was clear. There is relief that “a system” is finally coming. Then the first real working session happens.
Business Process Mapping.
And suddenly enthusiasm develops a calendar conflict.
“Do we need all departments present?”
“Can we shorten these workshops?”
“Can you just configure the system and show us?”
“Users will learn once they see the screens.”
“We will clean up processes after go-live.”
This is not resistance to software. This is the organisation negotiating to go back home.
Because BPM is the moment the project stops being about technology and starts being about behaviour.
During BPM sessions no one is learning SAP, or any ERP for that matter. Instead something far more uncomfortable happens. Sales realises delivery commitments are made without checking capacity. Production explains plans change depending on who escalates the loudest. Finance quietly admits reports are manually corrected before management sees them. Operations discovers three different departments maintain the same master data in three different spreadsheets and each one believes theirs is the correct version. Leadership notices decisions depend on individuals, not processes.
This is why BPM feels exhausting. It is not documentation. It is organisational self-awareness.
In the gym the warm-up exposes stiffness you didn’t know you had. In organisations BPM exposes dependencies you didn’t know you relied on. And in both places the instinct is identical — skip it and get to the “real work.”
Companies often want training quickly. “Let users see the screens, they will understand.” But training without process clarity creates a predictable outcome. Users learn transactions but not flow. Approvals continue on calls. Updates continue on WhatsApp. Spreadsheets quietly survive in the background. Data is entered at the end of the month just before review meetings. And then leadership concludes the software is good but adoption is poor.
Adoption is not poor. Preparation was skipped.
We assume change management begins after the system arrives. It does not. Change management begins when people participate in deciding how work will happen. A warehouse supervisor who helps design the goods receipt process rarely resists the system later, because the system is no longer management’s imposition — it is his workflow. People do not resist change as much as they resist loss of control.
A kick-off meeting therefore is not the beginning of implementation. It is the beginning of alignment. If the first question after kick-off is “when is go-live,” the project is already in danger. The more important question is quieter — “how do we actually work right now, truthfully?”
ERP systems rarely fail because the software cannot handle complexity. They fail because organisations try to automate assumptions. BPM is where those assumptions surface. And just like a warm-up, it feels unnecessary only until the consequences of skipping it arrive.
In the gym, the warm-up feels like delay. In reality, it is what allows you to train tomorrow.
In organisations, BPM feels like lost time. In reality, it is what allows the system to survive go-live.
The strongest lifters respect the warm-up the most. The most successful implementations respect the beginning the most.
Because speed without preparation is not efficiency.
It is damage… simply scheduled in advance.
