ERP implementation cost and timeline: what are you paying for?

Consider a distributor with two warehouses, a field sales team, and an online store. A project covering purchasing, stock, and sales is very different from one that also needs customer-specific prices, credit approvals, shipping integration, and invoices exchanged with another system. Even a single module varies in effort. Is an aggregate stock balance sufficient, or must you track batch numbers, expiry dates, and transfers between locations? State these distinctions in a scope document. A supplier quoting an “ERP price” without them is likely pricing assumptions neither party has agreed.

Separate must-have launch requirements, valuable second-phase work, and optional enhancements. Do not postpone foundations that later phases depend on, such as product identity, customer codes, or branch permissions. Phase one may look cheaper without them, only for the company to pay for another migration when it expands. Ask every bidder which design choices now make future modules easier and which would require substantial rework.

Tie milestones to an approved process map, a working prototype, tested integrations, documented user acceptance, and reconciled migrated data rather than dates alone. Name the person who accepts each stage and the evidence required. Acceptance tests should use your real operations: ordinary orders, exceptional discounts, partial returns, stock shortages, financial reports, and limited-permission users. Discover missing scenarios before a defect becomes expensive in production.

Define a stabilisation period after go-live: incident response times, priority classes, included fixes, and responsibilities of vendor and internal team. Clarify the difference between a defect against agreed scope and a new change request. Written definitions protect both sides and make ongoing operating costs more predictable.

Every stage needs inputs and an exit decision. Do not migrate the full database until a representative sample works; do not open the system to everyone before process owners are trained and failure procedures tested. Leave review time between deliveries, because manager approval may take longer than writing a feature. Account for trading peaks and financial close. If possible, keep a phased launch option. Ask the vendor to identify the critical path: which delayed task delays the whole project, and how will the team know early?

After launch, compare actual cost with the estimate, but also compare outcomes: hours saved, fewer stock discrepancies, faster reporting, and staff adoption. The goal is not the cheapest ERP. It is a system that improves decisions and operations at a sustainable cost.

Suppose the team asks for another approval level for unusually large discounts after design has been signed off. First ask whether the rule was already documented, whether an existing configuration can provide it, and whether it affects open orders or reports. If it is genuinely new, the supplier should describe the effect on price, schedule, and testing. The internal project owner can accept it now or move it to a later phase. If the original scope clearly promised the rule, completing it is a correction rather than an extra feature. Keep decisions in one shared record; verbal approval becomes disputed when team members change.

A mature proposal is clear about unknowns. Integration with an undocumented legacy system, or historical data no one has inspected, may justify a small discovery phase before anyone commits to a fixed delivery price. A quotation that promises precise cost and timing despite these unknowns can conceal risk rather than manage it. Transparent assumptions help you choose confidently and keep the partnership constructive when real-world complexity appears.

Finally, define the unit of value you expect from the project. It might be faster month-end close, fewer backorders, or a reliable profit view by branch. Write the current baseline and target before implementation. If the system is technically delivered but the measure does not improve, the team can investigate adoption, data quality, or process design instead of arguing only about whether a screen was completed.