Make the operating system behind your growth reliable.

Start with the operating outcome, not a software shortlist. Agree the business case, first-release scope, measurable improvements, executive sponsor, process owners, country and entity needs, and the investment the business can actually support after go-live.

Compare each route against the work it must control: finance, sales, procurement, inventory, delivery, service, projects, manufacturing, reporting, and integrations. The best fit depends on process complexity, number of entities, internal capability, required controls, change tolerance, and the cost of maintaining custom work—not feature-count alone.

There is no responsible fixed number without scope. Budget for licences, discovery and design, configuration, justified custom work, integrations, data migration, reporting, testing, training, cutover, hypercare, and the internal time required from finance and operational owners. A useful proposal makes these assumptions and exclusions explicit.

Timing follows the scope and the quality of business decisions. A focused first release can move quickly when process owners, source data, integrations, and acceptance criteria are ready; multi-entity or heavily integrated programmes need more deliberate design, testing, and change management. Plan around a usable release rather than an arbitrary go-live date.

Include a complete operational loop that the business can genuinely run: core master data, the priority transaction flow, finance and operational reporting, essential controls, and the few integrations needed to operate safely. Defer nice-to-have exceptions and unproven custom features into a governed backlog.

The programme needs an accountable executive sponsor, a delivery lead with authority to resolve trade-offs, and named owners from finance, operations, commercial teams, IT, and data. The implementation partner can guide and deliver, but the business must own decisions, validation, user acceptance testing, and adoption.

Migrate the data needed to transact, serve customers, manage stock, and close the books on day one: approved masters, opening balances, open items, inventory positions, and any required history. Archive the rest safely. Every migration plan should define mapping, cleansing, test loads, reconciliation, exceptions, and sign-off owners.

Treat them as design inputs, not generic software claims. Confirm the requirements for the legal entities, document flows, reporting, payroll dependencies, and countries in scope with the appropriate tax, legal, and payroll advisers; then configure and test the agreed process and reports.

Often, but the entity model, chart of accounts, tax treatment, currencies, approvals, warehouse ownership, intercompany flows, data access, and local documents must be designed deliberately. Avoid treating multi-country expansion as a simple setting applied after a single-entity build.

Only include integrations that protect a critical handoff or control in the first release, such as payments, POS, e-commerce, warehouse, banking, payroll, BI, or a required industry system. For each one, define the source of truth, data owner, failure handling, security, reconciliation, and operational support before build starts.

Yes, when the recovery begins with evidence rather than another rebuild decision. Audit scope, configuration, code, data, integrations, reports, access, testing, delivery history, and adoption; then choose whether to stabilise, simplify, re-scope, change partners, or rebuild selected components.

Compare the work behind the price: modules, entities, migration, integrations, reports, training, testing, support, assumptions, exclusions, governance, and change control. Ask who owns each dependency and what happens when source data, stakeholder availability, or third-party access is not ready. A lower price is not lower risk when essential work is simply omitted.