ERP rollouts that stay on course

An enterprise resource planning system touches finance, purchasing, inventory, sales and often much more. It changes how people do their jobs every day. That is why rollouts that treat the project as an IT installation tend to struggle, while those that treat it as a business change have a better chance. The software matters, but it is rarely the main risk.

Be clear about why you are doing it

Write down the business reasons in plain language: fewer manual reconciliations, one view of stock, faster closing of the books, support for growth. These reasons become the test for countless decisions during the project. When someone asks for a special feature, you can ask whether it helps the stated goals.

Set up governance that can decide

Appoint an executive sponsor who can resolve disputes and a project lead who can run the work day to day. Include leaders from the main business areas, not just IT. Agree how decisions are made and escalated, and who can approve changes to scope. Delays often come from decisions that wait for a meeting that never happens.

Take data seriously

Data migration is where many projects lose time. Customer, supplier, product and account records collected over years contain duplicates, gaps and inconsistent coding. Assign owners for each data set, clean it before loading and rehearse the migration more than once, checking totals against the old system. The new system is only as reliable as what you put into it.

Keep scope under control

• Start with standard processes and customize only where there is a clear competitive or legal reason.
• Record every change request, its cost and its effect on the schedule.
• Phase the rollout when the organization is large, so you learn from the first group.
• Plan for integration with the systems that will remain, and test those links early.
• Test with real scenarios, using the people who will use the system, not only the project team.

Think about reporting early. Ask each department what decisions it makes and what information it needs, then check that the system can provide it. Reports are often left to the end, and a project that goes live without the numbers managers rely on quickly loses their support. Agree the key reports during design, build them during testing and have users check them against known figures before go-live.

Invest in people and plan the go-live

Training is more effective when it follows the actual work: how to enter an order, approve an invoice or check stock. Offer it close to go-live, support it with guides and name local champions who can help colleagues. Expect productivity to dip for a while, and plan staffing for it. Listen to the frustrations that surface, since they often point to a missed requirement.

Decide in advance what must be true before you switch, and who makes the call. Have a support team ready, with a fast way to log and prioritize problems. After go-live, keep the project team together long enough to stabilize the system, capture lessons and plan the next improvements.

A rollout succeeds when people can do their work with the new system and the business gets the benefits it set out to achieve. Everything else is detail.