Why Kinaxis implementations stall — and the two-week assessment that saves them

We are often the second call. The first call went to whoever sold the platform or ran the rollout, and by the time we hear about it the programme has a name nobody says out loud in steering committees. The pattern is consistent enough to describe.

Three symptoms

Blown timelines. Go-live has moved twice. Each move was explained by a dependency — data, an interface, a resource — and each explanation was true. The programme plan now describes a project that no longer exists.

Planner rejection. The tool is live, technically. Planners export to Excel, do the real work there, and paste the answer back in. Adoption dashboards show logins; nobody mentions what happens after login.

Data chaos. Master data from SAP arrives late, incomplete or in a shape the data model never anticipated. Every planning run is preceded by a clean-up ritual, and the ritual is growing.

One cause

In almost every case, configuration started before the design was signed — because the plan said configuration started in month three, and month three arrived. Decisions about the data model, the planning hierarchy and the integration pattern were made by whoever was in the room, under schedule pressure, and the consequences compounded.

This is not a people problem. Good consultants make these mistakes when the gate that should have stopped them doesn’t exist.

The two-week assessment

When we take on a rescue, we don’t start by fixing. We run our Assess gate: two weeks, a small senior team, four outputs.

• Current-state review. What is actually configured, versus what the design documents say. These differ more than anyone expects.
• Data readiness. Which master data objects are trustworthy today, which can be made trustworthy in weeks, and which need a decision about scope.
• Stakeholder map. Who the planners listen to, who owns the integration, who can say no. Rescue plans fail when they ignore the informal organisation.
• Honest gap analysis and a recovery plan with sequencing, cost and the measure that will tell you it worked.

The deliverable is a plan you could execute without us. Some clients do. Most, having seen the plan, prefer the people who wrote it to run it.

What recovery looks like

Recovery is rarely a rebuild. It is usually a reset of the design around the three or four decisions that matter, a data programme with named owners, and a sprint cadence that puts a planner in every demo. The first visible win — one planning run that produces a number people believe — tends to arrive within six weeks of the assessment ending. Momentum does the rest.

If your programme has one of the three symptoms, start at Gate 1. No blame, just a route out.

The four decisions that compound

When we run an Assess gate on a stalled programme, the same four decisions turn out to be behind most of the symptoms. They were all made early, quickly, and by someone reasonable.

The planning hierarchy. Somebody chose the levels at which demand and supply are planned — product family, location, customer group — usually by mirroring the ERP’s reporting structure because it was available. Reporting structures are built for finance. Planning at the wrong level produces numbers that are technically correct and operationally useless, and by the time anyone notices, every workbook depends on it.

The data model’s treatment of exceptions. Every business has products that don’t behave: the configured-to-order line, the item with one supplier and a twelve-week lead time, the promotional pack that exists for six weeks a year. If the model has no explicit home for them, planners handle them outside the system — and once they are outside for one reason, they stay outside for all of them.

The integration pattern. Batch or near-real-time, full refresh or delta, master data mastered where. Chosen in a technical conversation, often before anyone has stated how fresh the plan actually needs to be. The wrong choice here is the single most common cause of “the system is slow” complaints that turn out not to be about performance at all.

Who signs off a planning run. Not a technical decision, and often not made at all. Without it, no one is accountable for the plan being wrong, so no one is accountable for it being right.

What the assessment actually does

Two weeks sounds short for a programme that has been struggling for months. It works because we are not diagnosing everything — we are finding which of a small number of decisions is doing the damage, and what it would cost to reverse each one.

The output is deliberately blunt: a list of decisions, the consequence of each, the cost of changing it now, and the cost of living with it. Some are cheap to reverse in month four and ruinous in month fourteen. Knowing which is which is most of the value.

We also do something clients find uncomfortable and later say was the most useful part: we sit with three or four planners, alone, and ask what they do when the system gives them a number they don’t believe. The answer is always specific, always revealing, and never in the programme documentation.

What recovery looks like from the inside

Recovery is rarely a rebuild, and it is never a relaunch event.

It usually looks like this: two or three design decisions reversed with a named owner and a date; a data programme with a short list of objects and a person accountable for each; a sprint cadence with a planner in every demo; and one deliberately small first win — a single planning run, on one product family, that produces a number people believe.

That first believable number does more than anything else in the plan. It changes the conversation from “when will this be fixed” to “what’s next”, and it is usually achievable within six weeks of the assessment ending.

Two things not to do

Don’t add people to a stalled programme before you know which decision is wrong. More hands building on a bad data model produces more to unwind.

Don’t relaunch with a new name. Every planner in the building knows it is the same programme. Renaming it tells them the organisation would rather manage the perception than the problem, and you will spend the credibility you need for the actual fix.