Rolling out an ERP module by module: which order works and why

Why I never switch an ERP on all at once

An ERP is a set of modules that write into each other. A purchase order becomes a goods receipt. The receipt raises stock and creates a payable. The payable posts to the general ledger. If all of that goes live on the same morning, and the balance sheet looks wrong by the afternoon, nobody can say which module caused it.

Phasing fixes that. Each phase adds a small number of modules, runs them through a real business cycle, and only then hands its data to the next one. Staff learn one new screen set at a time instead of six.

One caveat. I tell clients to start with the module that hurts most, and I stand by that. The order below is about dependencies. If the module that hurts most is stock, we still lay the foundations and the ledger it posts to first, but we keep that groundwork as thin as it can be.

Master data comes before any module

Master data is the list of things every module refers to: the legal companies and branches, the chart of accounts, items and units, warehouses, suppliers, customers, employees, users and their roles. Get it wrong and every module inherits the mistake.

I would not write a single transaction screen until these lists exist in one agreed form, with a named person who owns each one. Duplicate suppliers and three spellings of the same item are a common reason ERP reports disagree with reality. Cleaning them up later means correcting every document that used them.

• Is there one agreed chart of accounts, and who signs it off?
• Is every item coded once, with a unit of measure and a warehouse?
• Are suppliers and customers deduplicated, with one record each?
• Is every employee linked to a company, a branch and a cost centre?
• Is every user mapped to a role, and every role to what it may approve?
• Who owns each list after go-live, and who may add to it?

The order I roll the modules out in

Accounting goes first among the modules because everything else posts to it. On my ERP builds, operations write to the general ledger, so a report reflects what happened rather than what someone typed into a spreadsheet afterwards. Once the ledger is trusted, the operational modules can feed it one at a time.

My rule for running old and new systems in parallel

Run in parallel for one full cycle of the module you are switching, and no longer. For accounting, the cycle is one month-end close. For payroll, one payroll run. For stock, one physical count. Then compare the two outputs line by line.

If they match, the old system becomes read-only on a date agreed in advance. If they do not, we find the difference, fix it and run the cycle again. What I avoid is the open-ended parallel run. Staff typing everything twice for months get tired. They make mistakes in both systems. Eventually they quietly stop using the new one.

Parallel running also applies only to the module going live. Modules already cut over do not go back to double entry because a later phase is being tested.

What I cut from phase one

Phase one should prove that the core records and the ledger are right. Anything that only looks good on top of trusted data can wait until the data is trusted.

• Executive dashboards. They are only as good as the data under them, so they come after the data is proven.
• Multi-company consolidation, unless the group already reports that way and cannot stop.
• Biometric attendance devices and other hardware integrations.
• An employee mobile app for requests and approvals.
• Custom report builders. Start with the handful of reports managers read today.
• Long approval chains. One approver per document type is enough to start; add levels once people use the system.
• Years of history. Opening balances and open documents are usually enough to go live; moving old data is its own piece of work, which I will cover separately.

How this looks in my ERP projects and quotes

The Membership Club and Restaurant ERP in my work shows why order matters. It brings members and subscriptions, rooms and events, restaurant POS and kitchen, recipes and inventory, procurement, warehousing, HRM, payroll and accounting with a general ledger into one system. A restaurant sale that consumes recipe stock touches POS, inventory and the ledger together, so those pieces have to be sequenced, not switched on side by side.

The Enterprise Business ERP is a concept I designed at the product and architecture level. It adds multi-company management, attendance with biometrics, an employee mobile app and an executive command centre. Those are exactly the parts I would place in later phases.

ERP work is custom software, so it is a fixed quote per phase rather than one of my app packages. Complex ERP modules are quoted separately from the packages, and hosting and maintenance are not included. If you send me the modules you need and the tools you use today, I will propose the phase order and quote phase one.