CRM and ERP Rollouts Need Different Change Approaches

The change plan for the CRM rollout was adapted from the ERP programme two years earlier. Impact assessment, stakeholder map, comms calendar, training curriculum, super users, go-live gate, four weeks of hypercare, project closure.

It is a competent plan and most of it is reusable. But it was built around an assumption that does not hold for CRM, and the parts that fail are the parts nobody thinks to question.

One difference explains most of the others

An ERP go-live is mandatory. On Monday, the old system is off. If a warehouse operative cannot receive goods in the new system, goods are not received. The work physically stops, and everyone finds out within hours.

A CRM go-live is discretionary. On Monday, a salesperson who ignores the CRM entirely can still call customers, run meetings, negotiate and close deals. Nothing stops. Nobody finds out for a quarter, and by then the behaviour has set.

Almost every difference in how the two should be run follows from that single structural fact. An ERP programme is managing a hard cutover with an unforgiving deadline. A CRM programme is managing a long, soft competition against an alternative that remains available indefinitely.

The two decay curves

The academic literature describes two quite different shapes, and knowing which one you are in tells you when to look.

For enterprise systems, Markus and Tanis describe the shakedown phase: the period after go-live in which the errors of prior phases are felt as reduced productivity and business disruption, ending when normal operations are achieved. Performance dips immediately, visibly, and then recovers — or does not.

For sales force automation, the shape is different and worse. In the Journal of Marketing, Cheri Speier and Viswanath Venkatesh found across 454 salespeople in two firms that perceptions were positive immediately after training, and that six months after implementation the technology had been widely rejected — with absenteeism and voluntary turnover significantly increased.

There is no visible dip at go-live in that curve. There is a plateau of apparent success, followed by a slow, quiet collapse that arrives after the programme has closed and the team has been redeployed. A CRM programme that measures at hypercare exit and declares victory has measured the plateau.

What transfers

Most of the machinery is fine, and there is no reason to rebuild it:

• Change impact assessment. Understanding what actually changes for each role is if anything more important for CRM, because the changes are subtler.
• Rehearsal. Watching people attempt real work unaided remains the best readiness evidence available in either case.
• Support model design. Day one still generates confidence checks and blocked tasks rather than defects.
• Readiness criteria written to be falsifiable. The discipline is identical; only the content differs.

What does not

The go-live gate. An ERP gate asks whether the organisation can operate on Monday, and the answer is genuinely binary. A CRM gate asking the same question will always pass, because the organisation can obviously still sell. The equivalent CRM question is different and harder: is the alternative route closed, and is there a reason for an individual to use this? If the monthly review still accepts a spreadsheet, the honest answer is no — and that should hold the date in the same way an unready warehouse would.

Hypercare. Four weeks of intensive support is well matched to a shakedown curve and badly matched to a six-month cliff. The CRM support model should be lighter at launch and extended much further out, with a deliberate check at month three — when the programme has usually gone and the behaviour is actually being decided.

Training design. ERP training teaches a required transaction. CRM training has to answer a question ERP training never faces: why would I do this? A curriculum that covers navigation and field definitions without addressing that has taught the least important part.

Project closure. An ERP programme can close after stabilisation with reasonable confidence. Closing a CRM programme at week six means disbanding the only people paying attention immediately before the period in which adoption is determined.

The thing an ERP plan has no equivalent for

ERP change plans contain nothing about incentives, because they do not need to. Nobody is paid a commission for receiving goods, and no ERP transaction competes with a personally more rewarding alternative.

For CRM, the incentive question is not a supporting workstream. It is close to the whole problem. If commission is computed from closed revenue alone and forecast accuracy carries no weight anywhere, then pipeline discipline is unpaid administration competing with selling time. A change plan that does not address this has left out the mechanism that decides the outcome — which is why CRM adoption problems are behavioural rather than technical in almost every case.

Practically

• Move the readiness question from “can they?” to “will they, repeatedly, when nobody is watching?”
• Add a gate criterion about closing the alternative route, and treat it as non-negotiable.
• Shift support budget from weeks one to four into months two to six.
• Put the incentive conversation before the training design, not after go-live.
• Schedule the real measurement at six months and fund somebody to still be there to take it.

An ERP rollout is a deadline problem. A CRM rollout is a persistence problem, and persistence problems are not solved by anything that ends.

More on rollout readiness in the Adoption Risk Hub, or start with what to assess before a CRM rollout.