Blog

  • ERP vs MRP: The Difference Every Manufacturer Should Understand

    ERP vs MRP: The Difference Every Manufacturer Should Understand

    ERP and MRP are used interchangeably in conversation and they are not the same thing. The confusion is understandable — ERP grew directly out of MRP, most ERP systems contain an MRP engine, and vendors on both sides use whichever term the buyer used first.

    The distinction matters commercially. A manufacturer who needs MRP and buys ERP pays for capability they will not use. A manufacturer who needs ERP and buys standalone MRP ends up running the rest of the business on spreadsheets. This article explains exactly what each does, how they relate, and how to tell which you actually need.

    The Short Answer

    • MRP calculates what materials to buy and make, in what quantity, and by when, in order to meet a production plan.

    • ERP runs the whole business — finance, sales, purchasing, inventory, production, HR — on one shared database, and contains MRP as one of its planning functions.

    Put another way: MRP is a calculation engine with a specific job. ERP is the system that engine usually lives inside. Every credible manufacturing ERP includes MRP; not every product with MRP is an ERP.

    What MRP Actually Does

    Material requirements planning answers one question with precision: given what we intend to produce, what do we need, how much, and when must it arrive or start?

    The three inputs

    24. The master production schedule — what finished goods you plan to make and when, derived from sales orders, forecasts and stock policy.

    25. Bills of materials — what each product is made from, level by level, including scrap and yield allowances.

    26. Inventory records — what you hold now, what is already on order from suppliers, and what is already committed to existing work orders.

    The calculation

    MRP explodes the production schedule through the bills of materials to establish gross requirements at every level. It nets those against available stock, open purchase orders and existing work orders to find what is genuinely still needed. It then applies lead times to work backwards from the required date to the date each order must be placed or each job must start.

    The output

    • Purchase recommendations — buy this quantity of this component, order by this date.

    • Production recommendations — start this work order for this quantity by this date.

    • Rescheduling messages — an existing order needs to move earlier or later.

    • Exception alerts — a requirement cannot be met within the available lead time.

    That is the whole job, and it is more valuable than it sounds. Done well by hand for a product with four BOM levels and two hundred components, this calculation is essentially impossible to keep current.

    How the Terminology Evolved

    EraTermWhat it added
    1960s–70sMRPMaterial requirements planning — what to buy and make, and when
    1980sMRP IIManufacturing resource planning — added capacity, labour, machines and financial integration
    1990sERPExtended the same logic beyond manufacturing into finance, HR, sales and procurement
    2000s–10sCloud ERPSame functional scope, delivered as a subscription service
    CurrentAI-assisted ERPMachine learning layered on the same foundation for forecasting and automation

    The step from MRP to MRP II is the one people forget, and it is the important one. MRP alone assumes you have unlimited capacity to execute its plan. MRP II added the question of whether the plan is physically achievable — do you have the machine hours, the labour, the tooling? That distinction still causes trouble today, because some systems marketed as MRP perform the material calculation without any capacity check at all.

    ERP vs MRP: Side by Side

    FactorMRPERP
    Core purposePlan materials to meet productionRun the whole business on shared data
    ScopeMaterials, quantities, timingFinance, sales, purchasing, inventory, production, HR
    Primary usersProduction planners, buyersEveryone across the business
    Key inputsProduction schedule, BOMs, inventoryAll business transactions
    Financial capabilityLittle or none in standalone formFull accounting and reporting
    Typical costLowerHigher
    Implementation effortWeeks to a few monthsMonths
    Data prerequisiteAccurate BOMs and inventoryAccurate data across every function

    When Standalone MRP Is Enough

    Standalone MRP is a legitimate choice, and buying ERP when MRP would do is a real and expensive mistake.

    • Your accounting is already handled well by software you are satisfied with.

    • Your problem is specifically production planning — not finance, not sales, not reporting.

    • You have one site and a straightforward organisational structure.

    • You want a solution live in weeks rather than months.

    • Budget is tight and the planning problem is the one costing you money.

    The trade-off is integration. Standalone MRP must exchange data with your accounting and inventory systems, and every such interface is something to build, monitor and maintain. If that exchange is manual, you have reintroduced the re-keying problem that ERP exists to remove.

    When You Need Full ERP

    • Departments regularly report different numbers and reconciling them is somebody’s job.

    • Financial close is slow because production and inventory data arrive late or in a different format.

    • You operate multiple sites, entities or currencies.

    • You need accurate product costing that reflects real material and labour consumption.

    • Traceability requirements demand an unbroken chain from supplier through production to customer.

    • Staff spend meaningful time moving data between systems.

    • You cannot answer basic questions about margin by product or customer without a manual exercise.

    The distinguishing signal is whether your pain is confined to planning or spread across the business. Planning pain alone points to MRP. Pain that appears in finance, in reporting and in operations simultaneously points to ERP.

    The question that usually settles it“If material planning were solved tomorrow, would our other problems disappear?”If yes, buy MRP. If the finance, reporting and coordination problems would remain, you have an ERP-shaped problem and MRP will not fix it.

    What to Check in Any MRP Engine

    Whether standalone or inside an ERP, MRP quality varies enormously. These are the questions that separate a usable engine from one your planner will override into irrelevance.

    27. Does it handle multi-level BOMs with phantom assemblies, alternates and effectivity dates?

    28. Does it perform any capacity check, or does it assume infinite capacity? Confirm whether finite scheduling is included or a paid add-on.

    29. Does it respect minimum order quantities, order multiples and lot-sizing rules?

    30. How often can it run, and can it run on the full data set rather than a subset?

    31. Can the planner see why each recommendation was made, and trace it back to the demand that caused it?

    32. Can recommendations be overridden with a recorded reason, so the override is visible and auditable?

    33. How does it handle rescheduling when a supplier slips or an order changes after production has started?

    34. Does it distinguish firm from planned orders, so the schedule does not churn every time it runs?

    Question five deserves particular attention. An engine whose logic is opaque gets overridden, then distrusted, then ignored — at which point you have paid for a planning system and are still planning in spreadsheets.

    The Data Requirement Both Share

    MRP and ERP fail on the same foundation, and no amount of software quality compensates for it.

    • BOM accuracy. The bill of materials must reflect what is actually consumed on the floor, including scrap and packaging — not what the engineering drawing says. Wrong BOMs produce wrong purchasing, wrong costing and wrong stock simultaneously.

    • Inventory accuracy. MRP nets requirements against what the system believes you hold. If the records disagree with the warehouse, every recommendation is built on a false position.

    • Lead time accuracy. Lead times that were true five years ago produce plans that arrive late. Review them against actual supplier performance.

    • Routing data, where capacity planning is involved. Setup and run times must be validated against reality by the people who run the machines.

    This is why manufacturers are routinely advised to fix inventory accuracy through cycle counting before implementing either. It is unglamorous, it takes months, and it is the highest-return preparation available.

    Related Terms Worth Knowing

    TermWhat it means
    MPSMaster production schedule — what finished goods you plan to produce, and when. The input MRP works from
    MRP IIManufacturing resource planning — MRP plus capacity, labour and financial integration
    CRPCapacity requirements planning — detailed check of whether the plan fits available machine and labour hours
    RCCPRough-cut capacity planning — a high-level capacity check on the master schedule before detailed planning
    DRPDistribution requirements planning — the same netting logic applied across warehouses and distribution centres
    APSAdvanced planning and scheduling — optimisation-based scheduling, usually finite, often sold as an add-on
    MESManufacturing execution system — real-time shop floor execution and monitoring, distinct from planning

    Frequently Asked Questions

    What is the main difference between ERP and MRP?

    MRP calculates what materials to buy and make, in what quantities and by when, to meet a production plan. ERP runs the entire business — finance, sales, purchasing, inventory, production and HR — on one shared database, and includes MRP as one planning function within it.

    Does ERP include MRP?

    Every credible manufacturing ERP includes an MRP engine. Quality varies substantially, so evaluate the engine specifically rather than assuming its presence is sufficient — particularly on capacity checking and whether the planner can see the reasoning behind each recommendation.

    Can I use MRP without ERP?

    Yes. Standalone MRP is a legitimate choice when your accounting is already handled well and your problem is specifically production planning. The trade-off is integration: MRP needs current inventory and BOM data, so it must exchange information with your other systems reliably.

    What is MRP II?

    Manufacturing resource planning, the 1980s extension of MRP. It added capacity planning, labour and machine resources, and integration with financial data — moving beyond “what materials do we need” to “can we actually execute this plan, and what will it cost”.

    Is MRP cheaper than ERP?

    Generally yes, on both software and implementation, because the scope is narrower and fewer departments are affected. Factor in the cost of integrating it with your other systems, which can erode the difference substantially if several interfaces are needed.

    Which should a small manufacturer choose?

    If your accounting works and your pain is confined to planning, MRP addresses the problem directly at lower cost and risk. If you also struggle with costing, reporting, multi-site coordination or reconciling departments, ERP addresses the wider set and MRP alone will disappoint you.

    Does MRP require accurate inventory data?

    Absolutely, and this is where most implementations struggle. MRP nets requirements against what the system believes you hold, so inaccurate records produce confidently wrong recommendations. Fix inventory accuracy through cycle counting before implementing, not afterwards.

    What is the difference between MRP and APS?

    MRP calculates material requirements and typically assumes capacity is available. Advanced planning and scheduling adds optimisation against real constraints — machine availability, labour, sequencing and changeover time — to produce an executable schedule. APS is frequently sold as a separate module, so confirm whether it is included.

    Conclusion

    MRP is a planning calculation; ERP is the system that calculation usually lives inside. The commercial mistake in both directions is real: buying ERP when planning was the only problem wastes money, and buying MRP when the business needs coordination across finance, sales and operations leaves you running everything else on spreadsheets.

    Diagnose the pain before shopping. If solving material planning alone would fix your business, buy MRP. If the problems appear in finance, reporting and operations at the same time, you need ERP — and either way, fix your BOM and inventory accuracy first, because neither system produces a useful answer from data that is wrong.

  • NetSuite vs SAP Business One: Features, Pricing and Best Fit

    NetSuite vs SAP Business One: Features, Pricing and Best Fit

    NetSuite and SAP Business One compete for the same buyers surprisingly often, and they are built on genuinely different assumptions. One is a cloud-only suite designed from the outset to be delivered as a service. The other is a product with a long history in small and mid-sized distribution and manufacturing, delivered almost entirely through a partner channel and available in more than one deployment model.

    Neither of those descriptions is a criticism. They produce different buying experiences, different cost structures and different risk profiles. This guide covers what each actually is, where they diverge, and which business profile each genuinely suits.

    What Each Product Is

    Oracle NetSuite

    NetSuite launched in 1998 as a web-based business application and is widely described as the first ERP built for the cloud. Oracle acquired it in 2016 and continues to operate it as a distinct business unit, separate from Oracle Fusion Cloud ERP.

    It is a single multi-tenant cloud suite covering financials, inventory, order management, CRM and e-commerce, with a multi-subsidiary capability — marketed as OneWorld — for organisations operating across multiple entities, currencies and tax jurisdictions. It is cloud-only; there is no on-premise deployment.

    SAP Business One

    SAP Business One is SAP’s product for smaller companies, entirely separate from S/4HANA. It has a long history in distribution, wholesale and light manufacturing, and is sold and implemented almost exclusively through SAP’s partner channel rather than by SAP directly.

    Unlike NetSuite it offers deployment choice — it can run on-premise or hosted, and has been available on more than one database platform. That flexibility matters to businesses with connectivity constraints or data-residency requirements that a cloud-only product cannot accommodate.

    Side-by-Side Comparison

    FactorNetSuiteSAP Business One
    DeploymentCloud only, multi-tenant SaaSOn-premise, partner-hosted or cloud
    Sales modelDirect from Oracle NetSuite plus a partner networkAlmost entirely through SAP partners
    Pricing modelPer-user subscription plus platform feePer-user, historically with perpetual and subscription options
    UpgradesAutomatic on the vendor’s scheduleYou or your partner control timing
    Multi-entityOneWorld built for multi-subsidiary consolidationCapable, often supported by partner add-ons for complex cases
    ManufacturingSuits light manufacturing wellLong heritage in distribution and light manufacturing
    Built-in CRMIncluded in the suiteIncluded, with add-ons available
    E-commerceNative capability within the suiteTypically via partner or third-party integration
    CustomisationSuiteScript and platform tooling within SaaS limitsBroader modification scope, especially on-premise
    Implementation routeDirect or partnerPartner, always

    Where the Real Differences Lie

    1. Deployment choice

    This is the clearest divergence. NetSuite is cloud-only by design, which removes infrastructure work entirely and means the vendor controls when your version changes. SAP Business One gives you a choice, including running it on your own infrastructure.

    For most small and mid-sized companies, cloud is the better default — no servers, no patching, no disaster recovery to fund. The genuine exceptions are narrow but real: sites with unreliable connectivity that cannot stop working, and regulatory requirements about where data physically resides. If either applies to you, Business One’s deployment flexibility is a substantive advantage rather than a legacy artefact.

    2. The partner question

    Business One is a partner-delivered product. Your entire experience — implementation quality, localisation, support responsiveness, add-ons — depends on which partner you choose. Partner quality varies considerably, and this is the single most important variable in a Business One evaluation.

    NetSuite also uses partners extensively but maintains a direct relationship as well. That changes the escalation path when something goes badly wrong, which some buyers value highly.

    The practical implication for Business One buyers: evaluate two or three partners as rigorously as you evaluate the software, ask for references at your size in your industry, and get named consultants written into the contract. A strong partner makes Business One an excellent choice; a weak one makes it a difficult project.

    3. Multi-entity operations

    If you operate several legal entities across countries and currencies, this is likely to be your deciding factor. NetSuite’s OneWorld capability was designed for multi-subsidiary consolidation, and buyers consistently cite it as a strength for global operations.

    Business One handles multi-company scenarios, though complex consolidation requirements are more often addressed with partner add-ons. That is not automatically worse — a well-chosen add-on may fit your requirement precisely — but it means more moving parts, more vendors, and more to test at every upgrade.

    If you are a single-entity business, this difference is irrelevant to you and should carry no weight in the decision.

    4. Breadth versus focus

    NetSuite includes CRM and e-commerce natively in one suite, which appeals to companies wanting to consolidate several subscriptions into one platform. Business One focuses on core ERP — financials, inventory, purchasing, production — with front-end capability typically added through integrations.

    Breadth is not always the advantage it appears. A native module you do not need is complexity you configure around, and a specialist integrated tool sometimes serves better than a bundled one. Judge this against the systems you already run and would want to retire.

    5. Upgrade control

    NetSuite updates on Oracle’s schedule, which removes upgrade projects from your workload and removes your control over timing. Business One lets you or your partner decide when to move, which suits businesses with heavy customisation or strong seasonal constraints — and which also means somebody has to actually do the upgrade, and pay for it.

    Neither model is better in the abstract. The question is whether you would rather never manage an upgrade, or never have one imposed on you during your busiest month.

    Cost Structure

    Published pricing for both is indicative and heavily negotiated, particularly for Business One where the partner sets much of the commercial arrangement. Compare the shape rather than the headline.

    Cost elementWhat to establish for each
    Licence or subscriptionPer user, per module, or bundled — and what a limited user genuinely costs
    Platform or base feeWhether there is a fixed platform charge on top of user fees
    ImplementationFrequently equals or exceeds first-year software cost for both
    Add-onsEspecially relevant for Business One, where partner add-ons fill specific gaps
    InfrastructureZero for NetSuite; real for on-premise Business One
    UpgradesIncluded for NetSuite; a periodic project cost for Business One
    Renewal increasesNegotiate a cap in writing for either, before signing
    Exit termsData export format, completeness and cost

    The most common comparison error is matching NetSuite’s all-in subscription against a Business One licence quote that excludes hosting, add-ons and upgrade projects. Normalise both to total three-year cost including implementation, at your projected user count.

    Which Should You Choose?

    NetSuite tends to fit when…

    • You operate multiple legal entities, currencies or countries and need genuine consolidation.

    • You want cloud with no infrastructure responsibility whatsoever.

    • You want native CRM and e-commerce in the same suite rather than integrated separately.

    • You are growing fast and cannot forecast user numbers reliably.

    • You prefer a direct vendor relationship alongside partner support.

    • Your processes are close enough to standard that SaaS customisation limits are not a constraint.

    SAP Business One tends to fit when…

    • You need deployment flexibility — on-premise or hosted — for connectivity or data-residency reasons.

    • You are a distributor or light manufacturer, where the product has long-established strength.

    • You want control over when your system version changes.

    • You have identified an excellent local partner with references in your industry.

    • You need deeper modification than a multi-tenant SaaS platform permits.

    • A single-entity structure means multi-subsidiary consolidation is not a requirement.

    Consider other options if…

    • You are very small with simple needs — capable accounting software plus an inventory tool may serve you at a fraction of the cost.

    • You have complex manufacturing requirements — evaluate dedicated manufacturing ERP alongside these two.

    • You have strong technical capability and tight budgets — open-source platforms deserve a look.

    • You are large enough for genuinely complex global consolidation, where enterprise-tier products may be the honest answer.

    How to Evaluate These Two Properly

    16. Establish your entity structure first. Single entity or multi-entity changes the weighting of this comparison more than any other factor.

    17. Decide whether deployment flexibility genuinely matters, based on connectivity and regulation rather than preference.

    18. Evaluate Business One partners as rigorously as the software. Interview two or three; the partner determines your outcome.

    19. Run scripted demos on your own scenarios, including your awkward exceptions, with data resembling yours.

    20. List the systems you want to retire and confirm each product genuinely replaces them, rather than requiring another integration.

    21. Check localisation for every country you operate in. Tax and statutory reporting quality varies by market for both.

    22. Model three years of total cost at projected user numbers, including implementation, add-ons, infrastructure and upgrades.

    23. Call references at your size in your industry and ask what took longer than expected.

    Frequently Asked Questions

    Is NetSuite better than SAP Business One?

    Neither is universally better. NetSuite is generally stronger for multi-entity, multi-currency operations wanting a broad cloud suite with no infrastructure responsibility. Business One is generally stronger where deployment flexibility, upgrade control or deeper modification matters, and it has long-established strength in distribution and light manufacturing.

    Can SAP Business One run in the cloud?

    Yes, through hosted and cloud options, though its architecture originates from an on-premise product rather than being cloud-native like NetSuite. The practical difference is who controls upgrades and who carries infrastructure responsibility — confirm the current deployment options with an SAP partner.

    Which is better for multiple companies or countries?

    NetSuite is generally regarded as stronger here, with multi-subsidiary consolidation built into the product through its OneWorld capability. Business One handles multi-company scenarios but complex consolidation is more often addressed with partner add-ons, which means more components to maintain.

    Which is cheaper?

    It depends on deployment, user count and scope, and both are negotiated. Business One can appear cheaper on licence alone and then carry infrastructure, add-on and upgrade costs that NetSuite includes. Compare total three-year cost for identical scope rather than headline figures.

    Do I have to use a partner for SAP Business One?

    In practice yes — it is sold and implemented through SAP’s partner channel. This makes partner selection the most important decision in a Business One evaluation, and it deserves the same rigour you apply to the software itself.

    Which is better for manufacturing?

    Both suit light manufacturing. Business One has a long heritage in this segment among smaller companies. NetSuite supports light manufacturing well and is often chosen when multi-entity requirements dominate. If your manufacturing is complex — finite scheduling, deep process requirements, heavy traceability — evaluate dedicated manufacturing ERP alongside both.

    How long does implementation take for each?

    Both commonly run a few months for a straightforward single-entity deployment with clean data, extending considerably for multi-entity structures, manufacturing complexity or significant integration work. Data quality and internal decision-making speed influence this more than the choice of product.

    Can I move from one to the other later?

    It would be a full re-implementation rather than a migration — different data models, different customisation approaches, complete retraining. Treat this as a long-term decision and check exit terms, including data export format and cost, before signing either contract.

    Conclusion

    NetSuite and SAP Business One serve overlapping buyers with different architectures. NetSuite offers a cloud-only, broad, multi-entity-capable suite with no infrastructure burden and no upgrade control. Business One offers deployment flexibility, upgrade control and deeper modification, delivered through a partner whose quality will largely determine your experience.

    Start by establishing your entity structure and whether deployment flexibility is a genuine requirement or a preference — those two answers usually settle most of the decision. Then evaluate the partner as carefully as the product, model three years of total cost at projected user numbers, and call references at your size before committing.

  • Odoo vs ERPNext: Which Open-Source ERP Is Right for a Small Business?

    Odoo vs ERPNext: Which Open-Source ERP Is Right for a Small Business?

    Odoo and ERPNext are the two open-source ERP platforms most small businesses end up comparing, and the comparison is genuinely close on capability. Where they differ sharply is philosophy — and that difference shows up in your invoice as you grow, not on the feature list you evaluate today.

    This guide covers how each is licensed, what “free” actually costs, how they compare on functionality and customisation, which ecosystem risks apply to each, and which kind of business should choose which.

    The Core Difference: Open Core Versus Fully Open

    This single distinction explains most of what follows.

    Odoo: an open-core model

    Odoo, developed by Odoo S.A. in Belgium, ships in two editions. Community Edition is free and open source. Enterprise Edition is a paid subscription that adds functionality on top — historically including capabilities such as the Studio low-code customisation tool, full accounting features, mobile applications and official support.

    Community Edition is genuinely usable for some businesses. But the features that most companies eventually want tend to sit in Enterprise, and the practical experience of many adopters is that Community is a starting point rather than a destination. Verify the current edition split against Odoo’s own site before deciding — the boundary moves between releases.

    ERPNext: fully open source

    ERPNext, built by Frappe on the Frappe Framework, is released under GPLv3 with no paid tier gating features. Whether you self-host for free or pay Frappe for hosting, you get the same software. Accounting, manufacturing, HR, CRM and the rest are all in the core repository.

    This matters most for licensing economics as you scale. Odoo’s commercial model is per user; ERPNext’s self-hosted model has no per-user licence cost at all. For a business planning to add many light users — shop floor staff, warehouse operatives, employees submitting leave requests — that difference compounds.

    Side-by-Side Comparison

    FactorOdooERPNext
    Licence modelOpen core — free Community, paid EnterpriseFully open source (GPLv3), no feature gating
    Commercial pricingPer user, per month for EnterpriseFree self-hosted; hosted plans priced by server or plan
    Technology stackPython, PostgreSQL, custom JavaScript frameworkPython, MariaDB, Frappe Framework
    Architecture styleModular app-based, loosely coupledCohesive monolith maintained by one core team
    CustomisationLow-code via Studio (Enterprise) plus Python modulesMetadata-driven DocType system, plus Python
    Module breadthVery broad, including CMS, e-commerce and marketing appsFocused core covering standard ERP functions
    Third-party ecosystemVery large app marketplaceSmaller, more curated set of apps
    InterfacePolished, consumer-grade, strong mobile appsClean and functional, more database-like in feel
    Partner networkLarge global network of official partnersSmaller network, strong in some regions
    Best-known strengthBreadth, usability, ecosystemCost predictability, coherence, unrestricted access

    What “Free” Actually Costs

    Both platforms remove the licence line. Neither removes the cost of running an ERP, and this is where small businesses miscalculate most often.

    • Hosting and infrastructure. A server, backups, monitoring and enough capacity for your transaction volume.

    • Implementation. Configuration, chart of accounts, workflows, permissions. This is the same work regardless of licence model, and it is usually the largest cost.

    • Data migration. Extraction, cleaning, mapping, loading and reconciliation. Priced by how messy your source data is.

    • Customisation and integration. Developer time, in-house or contracted.

    • Upgrades. Somebody must test and apply them. On self-hosted deployments that somebody is you.

    • Security patching. Your responsibility on a self-hosted system, and not optional.

    • Support. Community forums are genuinely helpful and are not a service level agreement. When production is down at month-end, an SLA has value.

    The honest framing of open-source ERPFree to licence is not free to run. It shifts cost from a subscription to your own capability or to a partner.For a business with technical skill in-house, that trade is often excellent. For one without, total cost frequently lands close to a commercial subscription — with more risk attached.

    Functionality: Where Each Is Stronger

    Odoo’s advantages

    • Breadth beyond ERP. Website builder, e-commerce, point of sale, marketing automation and more, in one platform. For a small retailer or online seller, this can genuinely replace several separate subscriptions.

    • Interface polish. The user experience is consistently rated stronger, which matters more than buyers expect — adoption is where ERP projects fail.

    • Low-code customisation. Studio allows non-developers to add fields, adjust forms and build automations without writing code, which reduces dependence on developer time.

    • Ecosystem size. A very large marketplace of third-party apps means someone has probably already built something close to your niche requirement.

    • Partner availability. More implementation partners in more countries, which matters when you need local support and local tax compliance.

    ERPNext’s advantages

    • No feature paywall. Everything is available regardless of what you pay, which removes a whole category of unpleasant discovery mid-project.

    • Cost predictability at scale. No per-user licence on self-hosted deployments, so adding casual users costs nothing beyond infrastructure.

    • Architectural coherence. A single core team maintains the main modules, so data flows between sales, stock and accounting without connectors and upgrades are less likely to break interactions between them.

    • Rapid customisation model. The DocType system generates database structures and APIs from metadata defined in the interface, which makes structural changes fast for teams with Python skills.

    • Manufacturing in the core. Bills of materials, workstations and job cards are native rather than added, which suits small manufacturers well.

    The Ecosystem Trade-Off

    This is the most consequential practical difference and it cuts both ways.

    Odoo’s large third-party marketplace means you can often find an existing app for a specialised need. The risk is dependency: a community app that is not actively maintained can break when you upgrade to a new major version, and an ERP built on several such apps becomes difficult to move forward. Buyers frequently report upgrade friction from accumulated third-party modules.

    ERPNext’s smaller ecosystem means fewer ready-made options for niche requirements — you may need to build what Odoo users would install. The compensating benefit is that upgrades involve fewer moving parts maintained by fewer people.

    The practical rule: for every third-party app you plan to depend on, check when it was last updated, whether it supports the current major version, and who maintains it. An unmaintained module is a future migration project you have not budgeted for.

    Customisation Compared

    NeedOdoo approachERPNext approach
    Add a field to a formStudio, drag and drop (Enterprise edition)Define in the DocType interface, no code
    Change a workflowStudio automations, or Python for complex logicWorkflow builder, or Python for complex logic
    Build a new modulePython and XML custom moduleNew DocType plus Python controller logic
    Custom reportReport builder, or QWeb templatesReport builder, or query and script reports
    External integrationREST and XML-RPC APIsAuto-generated REST APIs per DocType

    Odoo is generally easier for non-technical customisation, provided you are on Enterprise. ERPNext is generally faster for structural change if you have Python capability, because the metadata model generates the database schema and API endpoints automatically. Which is better depends entirely on whether your customisation will be done by a business analyst or a developer.

    Which Should You Choose?

    Choose Odoo if…

    • You want breadth beyond core ERP — website, e-commerce, point of sale, marketing — in one platform.

    • Interface quality and user adoption are primary concerns, particularly with less technical staff.

    • You want non-developers to be able to customise the system themselves.

    • You need a local implementation partner and ERPNext coverage is thin in your country.

    • Your user count will stay modest enough that per-user pricing remains comfortable.

    • You value a large third-party marketplace and will manage the maintenance risk deliberately.

    Choose ERPNext if…

    • You expect many light users and per-user pricing would become punishing.

    • You have Python capability in-house or a reliable Frappe partner.

    • You want every feature available without a paid tier, permanently.

    • You value architectural coherence and predictable upgrades over ecosystem breadth.

    • You are a small manufacturer wanting native BOM and job card functionality without add-ons.

    • Long-term cost predictability matters more than interface polish.

    Choose neither if…

    • You have no technical capability and no budget for a partner. Open source shifts work to you; if you cannot absorb it, a commercial cloud ERP with vendor support is the lower-risk choice.

    • You need heavy statutory or industry-specific compliance functionality that neither covers natively in your jurisdiction.

    • You are large enough that complex multi-entity consolidation is a core requirement — both are strongest in the small and mid-sized range.

    How to Test Them Properly

    9. Install both. Free trials and self-hosted community versions exist. A day with each teaches you more than a month of comparison articles.

    10. Run your three most awkward real processes through each, not the tidy ones.

    11. Have the people who will use it daily try it, not just whoever is technical.

    12. Check local partner availability in your country, and ask for references at your size.

    13. Check your tax and statutory compliance requirements specifically — localisation quality varies significantly by country on both platforms.

    14. Model three years of cost including hosting, implementation, customisation and support, at your projected user count rather than today’s.

    15. Examine every third-party app you would depend on for maintenance history and current-version support.

    Frequently Asked Questions

    Is ERPNext really completely free?

    The software is, under GPLv3, with no features held back for paying customers. Running it is not free — you pay for hosting, implementation, customisation, upgrades and any support you want. The distinction is between licence cost and total cost, and only the first is zero.

    Is Odoo Community Edition enough for a small business?

    For some, yes. For many, the capabilities they eventually want sit in Enterprise, so Community functions as a starting point rather than a permanent home. Check the current edition split on Odoo’s own site against your specific must-have features before committing, because the boundary changes between releases.

    Which is better for manufacturing?

    Both handle small-manufacturer requirements. ERPNext includes bills of materials, workstations and job cards natively in the core, which many small manufacturers find sufficient and coherent. Odoo’s manufacturing capability is strong but the fuller functionality typically requires Enterprise. Test both against your actual production model.

    Which is cheaper over five years?

    It depends heavily on user count. ERPNext self-hosted has no per-user licence cost, so it scales cheaply as you add light users. Odoo’s per-user Enterprise pricing grows with headcount. Against that, Odoo may need less custom development for some requirements. Model both at your projected user count, not today’s.

    Which has better support?

    Odoo has a larger official partner network in more countries, which usually means easier access to local implementation help and localisation. ERPNext has a smaller network that is strong in particular regions. Check availability in your own country specifically — global figures tell you little about whether anyone near you can help.

    Can I migrate from one to the other later?

    Technically possible, practically expensive. You would re-implement rather than migrate: different data models, different customisation approaches, full retraining. Treat this as a five-to-ten-year decision and evaluate accordingly.

    Do I need a developer to run either?

    For self-hosted deployments of either, you need technical capability for hosting, upgrades, backups and security patching. Odoo Enterprise with Studio reduces the need for a developer for customisation specifically. ERPNext’s DocType model is accessible but still assumes comfort with technical concepts. Managed hosting from either vendor reduces, but does not eliminate, this requirement.

    Which is more future-proof?

    Both are actively developed with substantial communities. Odoo has greater commercial scale and a larger ecosystem. ERPNext’s full open-source licence means the code remains available regardless of any commercial decision by its maintainer, which some organisations weight heavily. Neither carries obvious abandonment risk today.

    Conclusion

    Odoo and ERPNext are both credible platforms, and the choice is less about capability than about what you optimise for. Odoo trades licence cost for polish, breadth and ecosystem. ERPNext trades ecosystem breadth for cost predictability, coherence and unrestricted access to every feature.

    The decisive questions are practical: how many users will you have in three years, do you have Python capability or a reliable local partner, and does your country have implementation and localisation support for the platform you prefer? Install both, run your awkward processes through each, model three years of real cost, and choose on that rather than on the licence headline.

  • SAP vs Oracle ERP: An Honest Comparison for Enterprise Buyers

    SAP vs Oracle ERP: An Honest Comparison for Enterprise Buyers

    SAP and Oracle have been the two names at the top of enterprise ERP for three decades, and most comparisons between them are useless for the same reason: they compare companies rather than products. SAP sells several distinct ERP products aimed at different segments. So does Oracle. Asking which company is better is not a question with an answer; asking which product fits your operating model is.

    This comparison sets out what each vendor actually sells today, how their deployment and customisation philosophies differ, where the cost really sits, and which kind of organisation each genuinely suits. It avoids naming prices, because enterprise ERP is negotiated and any published figure would mislead you.

    First, Know What You Are Actually Comparing

    The SAP lineup

    • SAP S/4HANA Cloud, Public Edition — a multi-tenant SaaS product built on a cloud-native code base. Shared application and hosting, isolated data, standardised processes, updates on SAP’s schedule.

    • SAP S/4HANA Cloud, Private Edition — the on-premise S/4HANA code base delivered as a single-tenant managed service on a hyperscaler. Retains the full customisation model.

    • SAP S/4HANA (on-premise) — the traditional licensed deployment on infrastructure you run.

    • SAP Business One — a separate product for smaller companies, sold and implemented through partners.

    • SAP Business Technology Platform (BTP) — not ERP itself, but the platform SAP expects you to use for integration and extensions so you avoid modifying the core.

    SAP wraps these in two commercial programmes that buyers routinely confuse. RISE with SAP targets existing SAP customers migrating an established landscape — typically ECC users moving to S/4HANA, usually landing on Private Edition. GROW with SAP targets customers new to SAP starting fresh on Public Edition. If you have never run SAP, GROW is your entry point; if you are migrating an existing SAP estate, RISE almost certainly is.

    The Oracle lineup

    • Oracle Fusion Cloud ERP — Oracle’s enterprise cloud ERP, formerly Oracle ERP Cloud, built on the Fusion Applications suite alongside Oracle’s HCM, SCM and CX products.

    • Oracle NetSuite — a separate cloud ERP acquired in 2016 and still operated as a distinct business unit, aimed at mid-market and fast-growing companies.

    • Oracle E-Business Suite, JD Edwards, PeopleSoft — established on-premise product lines that remain supported and in wide use.

    The important structural point: Oracle has not merged NetSuite into Fusion, and there is no public roadmap to do so. They serve different segments and rarely compete for the same deal. If a mid-market company is comparing “SAP versus Oracle”, the honest comparison is usually S/4HANA Public Edition or Business One against NetSuite — not against Fusion, which is scoped for a much larger organisation.

    The single most useful clarifying question“Which specific product are you proposing, in which edition, under which commercial programme?”A surprising number of enterprise ERP evaluations run for weeks before both sides establish this, and the answer changes the entire cost and timeline picture.

    Comparing Like With Like

    For an enterprise-scale evaluation, the realistic head-to-head is SAP S/4HANA Cloud versus Oracle Fusion Cloud ERP.

    FactorSAP S/4HANA CloudOracle Fusion Cloud ERP
    ArchitectureTwo distinct editions — multi-tenant Public and single-tenant PrivateSingle multi-tenant cloud application suite
    Extension modelExtensions built on BTP, kept outside the coreExtensions through Oracle’s own cloud platform tooling
    Upgrade controlPublic edition on SAP’s schedule; Private edition offers more controlRegular scheduled updates for all customers
    Traditional strengthManufacturing, supply chain, complex discrete and process industriesFinancials, consolidation, multi-GAAP reporting
    On-premise pathYes, a full on-premise S/4HANA deployment existsLegacy lines only; Fusion is cloud-only
    Mid-market routeBusiness One, or S/4HANA Public Edition via GROWNetSuite, as a separate product
    Ecosystem shapeVery large global partner and consultant baseVery large partner base, with deep specialisation in financials

    Where the Genuine Differences Lie

    1. Product structure and the migration question

    SAP’s structure is shaped by its installed base. An enormous number of organisations run older SAP systems, and a large part of SAP’s product and commercial design addresses how those customers move to S/4HANA. That gives SAP customers a clear continuity path — and it also means a migration project, with legacy custom code to assess and often years of accumulated configuration to rationalise.

    Oracle’s cloud ERP was rebuilt rather than migrated forward, which is cleaner architecturally and means customers on Oracle’s older on-premise lines face a re-implementation rather than an upgrade. Neither approach is inherently better; they produce different projects. If you already run one vendor’s legacy product, that fact usually weighs more heavily than any feature comparison.

    2. Customisation philosophy

    This is the difference that shapes daily life with the system. SAP’s public edition and Oracle Fusion both follow the modern SaaS logic: the core is standard and shared, and you extend around it rather than modify it. SAP’s private edition is the notable exception, deliberately preserving the deep customisation model that large, complex organisations often depend on.

    The practical implication: if your business genuinely requires processes that no standard product supports — and this is rarer than most organisations believe — the private single-tenant route gives you somewhere to put them. If your processes are closer to standard than you think, the multi-tenant route is faster, cheaper and far less painful at every upgrade.

    3. Functional centre of gravity

    Reputations here reflect genuine history. SAP grew from manufacturing and supply chain, and that heritage still shows in the depth of its production, planning and industry-specific functionality. Oracle grew from the database and financial applications, and its strength in consolidation, multi-book accounting and statutory reporting reflects that.

    Both have invested heavily to close the gap in the other’s territory, and for most requirements either will do the job. The distinction matters at the extremes: highly complex process manufacturing tends to favour SAP; a financial-services or multi-GAAP-heavy group tends to favour Oracle. Test this against your own requirements rather than accepting the reputation.

    4. Ecosystem and available skills

    Both have very large partner networks, which matters more than it sounds. Your implementation partner usually determines whether the project succeeds, and the availability of experienced consultants in your country, your industry and your specific product edition varies far more than the vendors’ global figures suggest.

    Check this directly. Search job listings for skills in the specific product you are considering. Ask each vendor how many certified partners operate in your region with references at your scale. A world-leading product with no local expertise is a difficult project.

    The Cost Picture

    Enterprise ERP pricing is negotiated, varies enormously by scope and region, and published figures are indicative at best. What you can compare reliably is the shape of the cost.

    Cost elementWhat to establish before comparing
    Subscription structurePriced by user, by revenue band, by transaction volume, or a mix — and how each scales as you grow
    Bundled componentsWhat the programme includes beyond the ERP core — platform credits, tooling, managed services
    ImplementationAlmost always the largest first-phase cost at enterprise scale; scope it precisely
    Extension platformWhether extensions consume separately charged platform capacity
    Migration of legacy custom codeFor existing customers, frequently the single largest variable
    Renewal mechanicsUplift caps, what happens when you cross a band, and the cost of adding entities
    Exit provisionsData export format, completeness, timeframe and cost

    The comparison error to avoid: matching a bundled programme against an unbundled quote. If one vendor’s package includes platform capacity and managed services and the other’s does not, the headline figures are not comparable. Normalise everything to total three-year cost for a defined scope, user count and workload.

    Which Should You Choose?

    SAP tends to fit when…

    • You already run SAP and have a substantial existing landscape and skills base.

    • You are a complex discrete or process manufacturer with demanding production and supply chain requirements.

    • You need deep industry-specific functionality that SAP has built for your sector.

    • You genuinely require heavy customisation and are prepared to take the single-tenant private route to get it.

    • You operate in regions where SAP partner depth is strongest for your industry.

    Oracle tends to fit when…

    • Financial complexity dominates — multi-GAAP reporting, intricate consolidation, sophisticated revenue recognition.

    • You want a single-architecture cloud suite spanning ERP, HCM and supply chain from one vendor.

    • You are comfortable adopting standard processes and prefer a uniform update cadence.

    • You already run Oracle technology and want to consolidate the vendor relationship.

    • You are mid-market — in which case the honest recommendation is usually NetSuite rather than Fusion.

    Neither, if…

    • You are a mid-market company being sold an enterprise product. Implementation complexity and total cost are frequently disproportionate below a certain scale, and both vendors have mid-market products for exactly this reason.

    • Your requirements are straightforward and a mid-market platform would serve you at a fraction of the cost and timeline.

    • You lack the internal capacity for a programme of this size. Enterprise ERP is a multi-year organisational commitment, not a software purchase.

    How to Run This Evaluation Properly

    1. Establish which specific products are in scope. Product, edition and commercial programme, in writing, from both sides.

    2. Document your requirements with consequences attached. A must-have has a consequence if missing; everything else is a preference.

    3. Demand scripted demos on your scenarios, including your awkward edge cases, using data resembling yours.

    4. Evaluate the implementation partner separately and just as rigorously. At this scale, partner quality is usually the dominant variable.

    5. Assess local skills availability, not global partner counts.

    6. Call at least three references at your scale in your industry, and ask what took longer than expected.

    7. Normalise the commercials to three-year total cost for identical scope, then negotiate renewal caps before signing.

    8. Model the customisation you truly need, honestly. This decision drives edition choice, cost and every future upgrade.

    Frequently Asked Questions

    Is SAP or Oracle better for ERP?

    Neither is universally better, and the framing hides the real question. Both are mature enterprise platforms used successfully by very large organisations. What differs is product structure, customisation philosophy, functional heritage and local partner availability. The right question is which specific product fits your operating model, industry and scale.

    What is the difference between RISE with SAP and GROW with SAP?

    RISE targets existing SAP customers migrating an established landscape, typically onto S/4HANA Cloud Private Edition, which preserves the customisation model. GROW targets customers new to SAP starting fresh on S/4HANA Cloud Public Edition, the standardised multi-tenant product. Verify the current structure with SAP, as these programmes are periodically revised.

    What is the difference between Oracle Fusion Cloud ERP and NetSuite?

    They are separate Oracle products serving different segments. Fusion Cloud ERP is Oracle’s enterprise platform, built alongside its HCM and supply chain suites. NetSuite is a mid-market cloud ERP acquired in 2016 and still run as a distinct business unit. Oracle has not merged them and has published no plan to.

    Which is more expensive, SAP or Oracle?

    Neither answer holds generally. Enterprise ERP pricing is negotiated and depends on scope, modules, user count, region and implementation complexity. Comparisons are only meaningful when normalised to identical scope over the same period — and implementation, not licensing, is usually the larger figure in the first phase.

    Can a mid-sized company use SAP or Oracle?

    Yes, but usually via their mid-market products rather than their enterprise ones. SAP offers Business One and S/4HANA Cloud Public Edition; Oracle offers NetSuite. Deploying an enterprise-scale product in a mid-sized company frequently produces implementation complexity and cost out of proportion to the benefit.

    Which has better manufacturing functionality?

    SAP’s heritage is in manufacturing and supply chain and that depth is still evident, particularly in complex process and discrete environments. Oracle has invested substantially in this area and serves many manufacturers well. Test against your own production model rather than relying on reputation — the difference at the extremes is real, but most requirements are met by both.

    How long does an implementation take with either?

    Enterprise implementations commonly run a year or more, and multi-entity global programmes considerably longer. Standardised public-cloud deployments with limited customisation can be materially faster. The variables that matter most are scope, data quality, decision-making speed and partner capability — not the choice of vendor.

    Conclusion

    The SAP versus Oracle question dissolves once you name the specific products. Both vendors sell several ERP products across different segments, and comparing a bundled enterprise programme against an unbundled mid-market quote produces a conclusion that is simply wrong.

    Establish which products are genuinely in scope. Be honest about how much customisation you truly require, because that decision drives edition, cost and every future upgrade. Weight local partner quality heavily, since it usually determines the outcome more than the software does. And if you are a mid-market company, ask both vendors directly whether their enterprise product is really the right recommendation — the good ones will tell you it is not.

  • ERP ROI: How to Calculate Real Return Before You Buy

    ERP ROI: How to Calculate Real Return Before You Buy

    Most ERP business cases are built backwards. Someone decides the company needs a new system, then assembles benefits until the numbers justify the decision that was already made. The board approves it, nobody revisits the figures afterwards, and two years later there is no honest answer to the question of whether it worked.

    A credible ROI model does the opposite. It measures the current state before anything changes, quantifies benefits conservatively, tests whether the case survives pessimistic assumptions, and commits to tracking the results afterwards. This guide covers how to build one — including the benefits people consistently overstate, and the largest benefit that most models leave out entirely.

    Why Most ERP Business Cases Are Weak

    • No baseline. You cannot prove improvement without measuring the starting point. Very few companies measure their current close duration, inventory accuracy or order cycle time before the project.

    • Optimistic benefit estimates taken from vendor case studies rather than from your own operation.

    • Understated costs, particularly internal staff time, integration work and the post-go-live productivity dip.

    • Soft benefits presented as hard numbers. “Better decision making” assigned a value nobody can defend undermines the credibility of the entire model.

    • No sensitivity analysis. A case that only works under best-case assumptions is not a case; it is a hope.

    • No tracking commitment. If nobody will check afterwards, the numbers were never intended to be accurate.

    Measure the Baseline First

    This step takes two or three weeks and transforms the quality of everything that follows. Measure these before the project starts.

    MetricHow to capture itWhy it matters
    Month-end close durationDays from period end to signed-off accountsDirectly converts to finance capacity
    Inventory value and turnsAverage inventory divided into cost of salesThe largest single cash release in most cases
    Inventory record accuracyCycle count variance against physicalPredicts how much benefit is achievable
    Order-to-cash cycle timeOrder received to invoice issuedWorking capital impact
    Order error rateCredit notes and re-shipments as a share of ordersDirect cost, plus customer retention
    Manual re-keying hoursTime study across affected roles for one weekThe most defensible admin saving
    On-time deliveryOrders shipped by promised dateRevenue protection
    Admin headcount per unit of revenueAdministrative staff relative to turnoverUnderpins the avoided-headcount case
    Days sales outstandingAverage collection periodCash flow

    Capture these in a document that is timestamped and signed off. When someone asks in eighteen months whether the investment worked, this baseline is the only thing that makes the question answerable.

    The Cost Side

    The cost model must cover the full life, not the first invoice. Build five years across these lines: software subscription or licence, implementation services, data migration, integrations, customisation, training, internal staff time, infrastructure where applicable, annual maintenance and support, ongoing administration, and the productivity dip during transition.

    Two lines are habitually omitted and both are large. Internal staff time — your people’s hours on the project at loaded cost — is real money that never appears on an invoice. The productivity dip of two to six weeks after go-live is a genuine cost and it is normal; excluding it makes the model look better and the actual outcome look worse than it was.

    Model user growth in line with your hiring plan rather than freezing headcount at today’s level, and assume realistic annual increases at renewal. A model that assumes flat pricing for five years will be wrong in year two.

    The Benefit Side: Three Categories

    Category 1: Hard benefits (put these in the model)

    BenefitHow to quantify it
    Inventory reductionPercentage reduction × average inventory value × (cost of capital + storage and obsolescence rate)
    Admin time recoveredHours per week saved × 52 × loaded hourly cost × number of affected staff
    Faster closeDays saved per month × 12 × daily cost of the finance team involved
    Error reductionErrors per month × average cost per error × expected reduction rate
    Software consolidationAnnual cost of point systems retired
    Purchasing improvementAddressable spend × realistic negotiated saving from consolidated visibility
    Reduced expedited freightHistorical expedite cost × expected reduction
    Lower days sales outstandingDays reduced × daily sales × cost of capital
    Avoided headcountRoles you would otherwise hire as volume grows × loaded annual cost

    Avoided headcount is usually the largest single item and the most commonly omitted.ERP rarely lets you reduce existing staff; it lets you absorb growth without adding administrators. If you would otherwise hire two more people over three years to handle rising volume, that is a quantifiable benefit — provided you commit to it honestly and do not later hire them anyway.

    Category 2: Soft benefits (state them, do not price them)

    • Better decision-making from trusted, timely data.

    • Improved customer experience from accurate promising and fewer errors.

    • Higher staff satisfaction where tedious re-keying disappears.

    • Greater agility when adding a location, entity, currency or channel.

    • Improved supplier relationships from reliable forecasting and on-time payment.

    These are real and they matter. Assigning them a contrived monetary value does not strengthen the case — it weakens it, because the reader stops trusting the numbers that were defensible. List them separately as qualitative support.

    Category 3: Risk avoidance (quantify as exposure, not as saving)

    • Compliance failures and the associated penalties.

    • Audit findings and the remediation cost they trigger.

    • Business continuity risk from unsupported legacy software.

    • Key-person dependency where one individual understands the spreadsheet that runs a critical process.

    • Inability to satisfy a customer’s traceability or reporting requirement, and the contract loss that follows.

    Express these as probability multiplied by impact, and label the estimate clearly as such. It is intellectually honest and boards respond better to it than to a confident number with no basis.

    The Calculations

    Return on investment

    ROI = (total benefit − total cost) ÷ total cost. Use the same period for both — five years is standard for ERP. A five-year ROI expressed as a percentage is the headline figure most boards expect.

    Payback period

    Payback = total first-year cost ÷ monthly net benefit once steady state is reached.Payback is often more persuasive than ROI because it answers the question executives actually ask: how long before this stops costing us money. One to three years is a commonly targeted range.

    Net present value

    NPV discounts future cash flows back to today’s value using your cost of capital. It matters for ERP because the costs land early and the benefits arrive later, so an undiscounted model overstates the case. If your finance team uses NPV for other capital decisions, use it here — inconsistency between methods invites the wrong kind of scrutiny.

    Internal rate of return

    IRR is the discount rate at which NPV equals zero, which allows the project to be compared against other investments competing for the same capital. Useful in organisations that rank projects; unnecessary in smaller businesses.

    The discipline that makes a case credibleUse the low end of every benefit estimate and the high end of every cost estimate.If the case still works, you can defend it. If it only works on optimistic assumptions, you have found that out before spending the money rather than after.

    Sensitivity Analysis

    Run the model at least three ways and present all three. A single number invites the reader to test it themselves; three scenarios show you already did.

    ScenarioAssumptionsQuestion it answers
    ConservativeLow benefits, high costs, delayed go-liveDoes this still make sense if things go badly?
    ExpectedRealistic benefits and costsWhat do we actually anticipate?
    OptimisticFull benefit realisation on scheduleWhat is the upside if it goes well?

    Then test the individual variables. Which single assumption, if wrong by twenty percent, damages the case most? That variable is your principal project risk, and it deserves specific mitigation in the plan rather than a line in a spreadsheet.

    Benefits People Consistently Overstate

    21. Headcount reduction. ERP rarely lets you remove existing staff. Promising redundancies that never happen destroys credibility and poisons adoption, because staff hear it too.

    22. Inventory reduction achieved immediately. It takes twelve to eighteen months of accurate data before you can safely reduce buffer stock. Phase this benefit in.

    23. Full elimination of manual work. Some manual handling always remains. Model a realistic reduction, not zero.

    24. Revenue growth attributed to ERP. Very hard to isolate from market conditions and sales effort. Leave it out or state it qualitatively.

    25. Instant benefit realisation. Benefits ramp over months. A model that starts full benefits at go-live overstates the early years, which is where NPV is most sensitive.

    26. Vendor case study percentages. Those figures came from another company’s starting point. Your baseline determines your achievable improvement.

    Tracking Benefits After Go-Live

    A business case nobody revisits was never a forecast; it was a persuasion document. Commit to measurement in the approval itself.

    • Assign each benefit an owner. Inventory reduction belongs to operations, close duration to finance, error rates to customer service.

    • Re-measure the baseline metrics at three, six and twelve months using exactly the same method as the original measurement.

    • Expect worse results at three months. The productivity dip is real; a dip at the first review is normal and should be anticipated in the plan.

    • Report honestly, including the misses. A review that reports only successes teaches everyone that the numbers are decorative.

    • Act on shortfalls. A benefit that has not materialised usually points to an adoption gap or a process that was never changed — both fixable, but only if noticed.

    Companies that track benefits get more of them, for an unglamorous reason: measurement creates attention, and attention creates the follow-through that turns a working system into an improved business.

    Presenting the Case

    • Lead with the problem, quantified. What the current situation costs each year, using your baseline measurements.

    • State the recommendation early, then support it. Executives read the first page.

    • Show three scenarios, not one number.

    • Separate hard benefits from soft ones visibly. This is what signals rigour more than any figure in the model.

    • State the risks and the mitigations. A case with no acknowledged risk reads as naive and gets scrutinised harder.

    • Include the do-nothing option with its own cost. Doing nothing is never free, and quantifying it is often the strongest argument you have.

    • Commit to the review dates in the paper itself.

    A Worked Structure

    Use this skeleton with your own figures. The structure matters more than any illustrative number, and inventing numbers here would only mislead.

    27. Baseline metrics table, measured and dated.

    28. Annual cost of the current state, derived from those metrics.

    29. Five-year cost model for the proposed system, all twelve cost lines.

    30. Hard benefits, each with its formula and its source assumption stated.

    31. Benefit ramp schedule — what percentage of each benefit is achieved in years one, two and three.

    32. Net cash flow by year.

    33. ROI, payback, and NPV at your cost of capital.

    34. Three scenarios plus a sensitivity table on the two or three most influential assumptions.

    35. Soft benefits and risk exposure, stated separately and qualitatively.

    36. Review commitments with named owners and dates.

    Frequently Asked Questions

    What is a good ROI for an ERP project?

    There is no universal benchmark, and figures quoted in vendor material usually come from unrepresentative case studies. What matters more is whether your model is built on measured baselines, conservative assumptions and costs that include internal time — a modest, defensible return is worth more than an impressive, unverifiable one.

    How long is a typical ERP payback period?

    One to three years is commonly targeted, though outcomes vary widely with adoption quality. Projects that fail to pay back rarely fail on price; they fail because staff worked around the system and the operational changes that generate the benefits never happened.

    Should soft benefits be included in the ROI calculation?

    State them, but do not price them. Assigning a contrived value to “better decision-making” weakens the whole model because it invites scepticism about the numbers that were actually defensible. Present them separately as qualitative support.

    What is the biggest benefit companies forget to include?

    Avoided headcount — the administrative roles you would otherwise hire as volume grows. ERP seldom removes existing staff but frequently allows growth to be absorbed without adding them, and this is usually the largest quantifiable line in the model.

    How do I measure the baseline if we do not track anything?

    Take two or three weeks and measure directly: time the month-end close, run a time study on re-keying for one week, pull inventory value and cycle count variances, count credit notes. Rough measurement beats no measurement, and it makes the post-implementation review possible.

    Should the ROI model include the productivity dip after go-live?

    Yes. It is a genuine cost of two to six weeks and it is entirely normal. Excluding it makes the model look better and makes the actual outcome look like an underperformance when it is not.

    What if the business case does not justify the investment?

    That is a valuable result, not a failed exercise. It usually means either the scope is too large for the problem, or the real issue is process and discipline rather than software. Both are cheaper discoveries now than in month eight of an implementation.

    How often should benefits be reviewed after go-live?

    At three, six and twelve months, using the same measurement method as the original baseline. Expect the three-month review to look poor because of the transition dip, and say so in advance so the result is interpreted correctly.

    Conclusion

    A credible ERP business case is not the one with the highest return. It is the one built on measured baselines, conservative assumptions, honest costs including internal time, and a commitment to check the results afterwards.

    Measure before you change anything. Quantify the hard benefits with stated formulas and leave the soft ones qualitative. Run three scenarios and identify which assumption carries the most risk. Include the cost of doing nothing. Then assign owners to each benefit and actually review them — because the model does not create the return, the follow-through does.

    ARTICLE 13

    AI in ERP: What Is Genuinely Useful and What Is Still Marketing

    SEO fieldValue
    Focus keywordAI in ERP
    Secondary keywordsartificial intelligence ERP, machine learning ERP, AI ERP use cases, predictive analytics ERP, AI ERP risks
    Search intentInformational — buyers and leaders assessing AI claims in ERP
    SEO title (meta title)AI in ERP: What Is Genuinely Useful and What Is Marketing
    Meta descriptionA clear-eyed look at AI in ERP: which use cases actually deliver, what data you need first, the real risks, and how to evaluate a vendor’s AI claims.
    URL slugerpdetail.com/ai-in-erp
    Approx. word countApprox. 3,600
    Suggested internal linksLink to: what is ERP, ERP selection criteria, ERP data migration, ERP for manufacturing, ERP software cost
    Suggested image alt textDashboard showing AI-generated demand forecasts and anomaly alerts inside an ERP system

    Every ERP vendor now has an AI story, and the gap between the demonstration and the deployed reality is wider in this area than anywhere else in the product. Some of what is being sold genuinely works and has for years under a less exciting name. Some of it works only on data most companies do not have. And some of it is a roadmap slide with a launch date attached.

    This article separates the three. It covers what AI in ERP actually means, which use cases deliver reliably today, what data you need before any of it works, the risks that matter — particularly around auditability — and the questions that reveal whether a vendor’s AI claim is substantial.

    A note on specifics: this area changes faster than any other part of the ERP market. Features are renamed, rebundled and repriced constantly. Rather than list vendor products that will be inaccurate within months, this guide teaches you how to evaluate a claim. Verify current capability against the vendor’s own documentation on the day you evaluate.

    What “AI in ERP” Actually Refers To

    The label covers at least four distinct technologies with very different maturity and risk profiles. Vendors rarely distinguish between them, and you should.

    TechnologyWhat it doesMaturity in ERP
    Rules and thresholdsAutomates decisions against predefined logicFully mature — often marketed as AI, and is not
    Classical machine learningLearns patterns from historical data to predict or classifyMature and reliable where data exists
    Computer visionReads documents, inspects images, recognises defectsMature for documents, improving for inspection
    Large language modelsUnderstands and generates natural language; drives assistants and agentsRapidly evolving; capability outpacing governance

    The first row deserves attention. A material amount of what is presented as AI in ERP demonstrations is conditional logic that has existed for two decades. It is genuinely useful — but if you are paying an AI premium for automated approval routing, you are paying for a rebrand.

    What Genuinely Works Today

    Document processing

    Reading supplier invoices, purchase orders, delivery notes and remittance advices, extracting the fields, and matching them against system records. This is the most mature and highest-return application in ERP. It works because the task is narrow, the training data is abundant, and errors are catchable at the matching stage.

    Realistic expectation: a large majority of straightforward documents processed without human touch, with the remainder routed for review. That is a substantial saving in accounts payable, and it is verifiable within weeks rather than promised for later.

    Anomaly detection

    Flagging transactions that deviate from established patterns — duplicate payments, unusual journal entries, prices outside normal ranges, expense claims that look wrong. Machine learning is well suited to this because it does not need to know what fraud looks like, only what normal looks like.

    The value is in catching things that rule-based checks miss, and the risk is alert fatigue. A system generating too many false positives gets ignored within a month, which is worse than not having it.

    Demand forecasting

    Predicting future demand from sales history, seasonality, promotions and external signals. Machine learning genuinely outperforms simple moving averages — when there is enough clean history. Typically that means two to three years of consistent data and reasonably stable products.

    It performs poorly on new products, highly volatile demand, and businesses where a handful of large customers drive most volume. In those cases the honest answer is that a good planner with good data beats a model with insufficient data.

    Predictive maintenance

    Using machine sensor data to predict failures before they occur. This works well in practice and is one of the clearer ROI stories in manufacturing — but it requires instrumented equipment, historical failure data and an integration between the machines and the ERP or MES. Without those, it is a capability you own and cannot use.

    Natural language querying and assistants

    Asking questions in plain language instead of building a report, or having an assistant draft a purchase order from a description. This is improving quickly and it lowers the barrier for occasional users who would never learn the reporting tool.

    The caution is that a language model can produce a confident, fluent, wrong answer. For exploratory questions this is acceptable. For anything feeding a decision or a filing, the underlying figures must be verifiable — and the interface should show you where the number came from.

    Cash collection prioritisation

    Predicting which invoices are likely to be paid late and prioritising collection effort accordingly. Reliable, low-risk, and it uses data you already have. One of the better first AI projects for a finance team.

    What Is Still Mostly Marketing

    • Fully autonomous processes. Agents that run procurement or close the books without human oversight. The technology is moving, the governance and auditability are not, and no auditor will currently accept an unreviewable decision chain in a financial process.

    • Prescriptive optimisation across the whole supply chain. Demonstrations look extraordinary. Deployments require data quality and integration breadth that very few companies possess.

    • AI that fixes bad data. A recurring and dangerous claim. Machine learning trained on inconsistent data produces confident, consistent nonsense. Data quality is a prerequisite, not an output.

    • Instant value with no configuration. Every genuinely useful model needs your history, your definitions and a tuning period. “Switch it on and it works” describes a rules engine, not a model.

    • AI as a headline reason to change ERP. If the underlying platform does not fit your processes, embedded AI will not compensate. Select on fit; treat AI as a tiebreaker.

    The Prerequisite Nobody Wants to Hear

    Every credible AI application in ERP depends on the same foundation, and it is the least exciting part of the subject.

    • Sufficient history. Most predictive applications need two to three years of consistent data. A company that migrated ERP last year does not have it yet, whatever the vendor demonstrates.

    • Consistency. If your item categorisation changed twice in three years, the model is learning noise. Structural changes in how you record things break the pattern the model depends on.

    • Completeness. Missing costs, blank customer categories and unrecorded reason codes limit what any model can learn.

    • Accuracy. Inventory records that disagree with the warehouse produce forecasts that confidently plan around stock you do not have.

    • Volume. Small transaction counts do not support reliable learning. Some businesses are genuinely too small for machine learning to beat an experienced person, and that is an acceptable answer.

    The honest sequencingClean data first, then automation, then prediction.Companies that skip to prediction get outputs that look authoritative and are not, which is more dangerous than having no prediction at all.

    Risks That Deserve Real Attention

    Auditability

    The most serious issue for ERP specifically. Financial processes must be explainable to auditors and regulators. If a system approved a payment, someone must be able to reconstruct why. Many machine learning models cannot fully explain individual decisions, and language-model-driven outputs are harder still.

    Practical response: keep AI in an advisory role for anything with financial or compliance consequence, log every AI-influenced decision with its inputs, and ensure a human approval step remains in the record. Ask vendors directly what audit trail their AI features produce — the quality of that answer is highly informative.

    Confidently wrong output

    Language models generate fluent text regardless of whether it is correct. In an ERP context that means a summary containing a figure that appears nowhere in your data, delivered in the same tone as an accurate one. Users trust system output by default, which makes this more dangerous here than in a chat interface.

    Automation bias

    The documented human tendency to accept machine recommendations more readily than our own judgement. A planner who overrides the model in month one may stop questioning it by month six — including when it is wrong. Preserve the expectation that recommendations are challenged, and track override rates as a health indicator rather than as a problem.

    Learned bias

    Models trained on historical decisions reproduce the patterns in those decisions, including the ones you would not defend. A credit-scoring or supplier-selection model learns your past behaviour, not your policy. In some jurisdictions this carries legal exposure as well as ethical weight.

    Data privacy and confidentiality

    Establish where processing happens, whether your data trains shared models, which jurisdiction governs it, and what subprocessors are involved. These questions matter for regulatory compliance and for commercially sensitive information. Get the answers in the contract rather than in a sales conversation.

    Concentration and lock-in

    AI features increase switching costs, because tuned models and accumulated behavioural data do not transfer to a competitor. Understand what happens to model configuration and derived data if you leave, and price that into the decision.

    Governance: Keeping a Human in the Loop

    A workable framework scales oversight to consequence rather than applying one rule everywhere.

    Decision consequenceAppropriate oversightExamples
    Low — easily reversedAutomate, monitor in aggregateCategorising documents, suggesting a report
    Medium — costly to reverseAI recommends, human approvesPurchase suggestions, collection prioritisation
    High — financial or compliance impactAI assists analysis, human decides and signsJournal entries, credit limits, payment release
    Critical — safety or legalAI advisory only, full audit trail requiredQuality release, regulatory reporting, hiring

    Alongside the framework, maintain a register of where AI is used, who owns each use, what data it touches and how its performance is monitored. When a regulator, auditor or customer asks — and increasingly they do — that register is the difference between a short conversation and a long one.

    How to Evaluate a Vendor’s AI Claims

    37. “Is this generally available today, or on the roadmap?” Treat roadmap functionality as absent. Buy what exists.

    38. “Which of your customers has this in production, and may we speak to them?”The single most revealing question. Hesitation is the answer.

    39. “What data does it need, and how much history?” If they cannot state a requirement, the feature has not been deployed at scale.

    40. “Show it running on data resembling ours.” Curated demonstration data conceals exactly the problems you will encounter.

    41. “What accuracy do customers actually achieve, and how is it measured?” A specific figure with a measurement method beats an adjective.

    42. “What audit trail does an AI-influenced decision produce?” Critical for anything financial. Ask to see an example record.

    43. “Is this included, or priced separately?” AI features are frequently a higher tier or a per-transaction charge.

    44. “Where is the data processed, and does it train shared models?” Get the answer in the contract.

    45. “What happens when it is wrong?” How errors surface, how they are corrected, and who is accountable.

    46. “Can we turn it off?” Reversibility matters when a feature underperforms or when a regulator asks.

    A Realistic Adoption Path

    47. Fix data quality first. Nothing here works without it, and the work benefits every other part of the system regardless.

    48. Start with document processing. Narrow, measurable, quick payback, low risk, errors caught at matching.

    49. Add anomaly detection in finance. Uses existing data, low downside, immediate audit value.

    50. Introduce forecasting once you have two to three years of consistent history — and run it alongside your current method for a full cycle before trusting it.

    51. Extend to operations — predictive maintenance, quality inspection — where you have the sensor data and integration to support it.

    52. Evaluate assistants and agents last, in low-consequence areas, with logging and human approval retained for anything that matters.

    53. Measure everything. Accuracy, override rates, time saved, errors introduced. Without measurement you cannot tell whether the feature is working or merely present.

    Should AI Influence Your ERP Selection?

    As a tiebreaker, yes. As a primary criterion, no. Functional fit, usability, implementation partner quality and total cost determine whether an ERP project succeeds. A platform that does not match your processes will not be rescued by an embedded assistant.

    The one AI-related factor genuinely worth weighting during selection is data architecture: whether the platform makes your data accessible and well structured. Good data foundations let you adopt AI capabilities as they mature, from the vendor or elsewhere. Poor ones limit you regardless of what the vendor ships.

    Frequently Asked Questions

    What does AI actually do in an ERP system?

    The reliable applications are document processing, anomaly detection, demand forecasting, predictive maintenance, collection prioritisation and natural language querying. Much of what is labelled AI in demonstrations is conditional logic that has existed for years — useful, but not worth an AI premium.

    Do I need AI features in my ERP?

    Not to run a business well. Treat AI as an efficiency layer on top of a system that already fits your processes. If the underlying platform is a poor match, embedded AI will not compensate for it.

    How much data do I need for AI forecasting to work?

    Typically two to three years of consistent history, with reasonably stable products and adequate transaction volume. New products, highly volatile demand and businesses dominated by a few large customers all reduce accuracy substantially, sometimes below what an experienced planner achieves.

    Can AI fix bad data?

    No, and this claim should be treated as a warning sign. Models trained on inconsistent data produce confident, consistent errors. Some tools help identify duplicates and anomalies, which is genuinely useful — but data quality is a prerequisite for AI, not a product of it.

    Is it safe to let AI approve transactions?

    Scale oversight to consequence. Low-impact, easily reversed decisions can be automated with aggregate monitoring. Anything with financial or compliance impact should keep a human approval step with a full audit trail, because auditors and regulators will ask how the decision was reached.

    Will AI replace ERP users?

    The consistent pattern so far is task displacement rather than role replacement — data entry and matching shrink while exception handling, judgement and oversight grow. Roles change substantially; the realistic planning assumption is retraining rather than reduction.

    Do AI features cost extra?

    Frequently yes — as a higher subscription tier, a per-transaction charge, or a consumption-based fee. Establish this during evaluation and include it in your total cost model, since it is a line that tends to grow with usage rather than staying fixed.

    How do I know if a vendor’s AI is real?

    Ask to speak to a customer running it in production, ask what data and history it requires, ask for accuracy figures with a measurement method, and ask to see it on data resembling yours. A vendor with genuine deployments answers all four readily. Hesitation on the first is usually the whole answer.

    Conclusion

    AI in ERP is neither hype nor transformation — it is a set of specific capabilities with specific data requirements, some of which are mature and valuable today and some of which are demonstrations with a roadmap attached. The distinction is learnable, and the questions that reveal it are straightforward.

    Fix your data first, because everything here depends on it. Start with narrow, measurable applications like document processing. Keep humans accountable for anything with financial or compliance consequence, and log the decisions. Select your ERP on fit, not on AI. And ask every vendor which customer is running the feature in production today — that question, more than any other, separates the working from the promised.

  • ERP User Training: How to Get Your Team to Actually Use the System

    ERP User Training: How to Get Your Team to Actually Use the System

    ERP User Training

    Training is the cheapest line in an ERP budget and the one most often cut when the schedule slips. It is also the single largest determinant of whether the rest of the spending returns anything. A perfectly configured system that staff quietly work around delivers nothing — and worse, it delivers nothing while management believes it is working.

    This guide covers why ERP training usually fails, how to design it around roles rather than modules, when to deliver it, how to build a super user network that outlasts the consultants, how to measure whether people are actually competent, and what support must exist in the first weeks after go-live.

    Why ERP Training Usually Fails

    • It is scheduled as an event rather than designed as a programme. Two days of instruction, delivered once, weeks before anyone can practise.

    • It is delivered on demo data. People learn which buttons exist but not how to do their own job, because nothing on screen resembles their work.

    • It is organised by module instead of by role. A warehouse supervisor sits through general ledger configuration and learns nothing they will use.

    • It teaches clicks, not process. Staff learn the sequence without understanding why it matters, so when something unusual happens they have no basis for judgement.

    • It ignores the emotional reality. Experienced people who were expert in the old system become beginners overnight. That is uncomfortable, and unacknowledged discomfort turns into resistance.

    • It ends at go-live, exactly when the real questions start.

    The underlying error is treating training as knowledge transfer. It is actually behaviour change, and behaviour change needs practice, reinforcement and support — not a session.

    Design Around Roles, Not Modules

    Nobody needs to learn the ERP. They need to learn their job in the ERP. Start by listing the roles in your business and, for each, the specific tasks that person performs in a normal week.

    RoleWhat their training should coverTypical depth
    Sales order entryQuotes, orders, availability checks, pricing, customer records, returnsDeep, narrow
    Warehouse operativeReceiving, put-away, picking, packing, stock transfers, cycle countsDeep, narrow, mostly scanner-based
    Production operatorClocking on and off operations, reporting output and scrap, material issuesVery narrow, high repetition
    PurchasingRequisitions, purchase orders, receiving, supplier records, three-way matchDeep, narrow
    Accounts payable / receivableInvoice processing, matching, payments, collections, reconciliationDeep, with exception handling
    Financial controllerPeriod close, reporting, journals, controls, variance analysisBroad and deep
    Production plannerMRP output, work orders, scheduling, capacity, reschedulingBroad and deep
    Manager / approverApprovals, dashboards, exception reportsShallow but must be confident
    ExecutiveDashboards and key reports onlyVery shallow

    Two consequences follow from this. First, most people need far less training than a module-based plan assumes — but it must be precisely the right training. Second, a small number of people need much more, and those are your super users.

    The Super User Network

    Super users are respected practitioners from each department who learn the system deeply, help test it, and become the first line of support for their colleagues. Building this network is the highest-return training investment available, for a reason that is often missed: people ask a colleague sitting near them long before they raise a support ticket.

    Choosing them

    • Pick people whose colleagues already go to them with questions. Informal authority matters more than job title.

    • Choose practitioners, not managers. Credibility comes from doing the work.

    • Cover every shift and every site. A super user network that only exists on days is not a network.

    • Accept that you are choosing busy people. That is precisely why it works, and precisely why their workload must be adjusted.

    Developing them

    • Involve them in design workshops and in user acceptance testing, so they understand why the system works as it does.

    • Give them sandbox access early and encourage them to break things.

    • Train them a level deeper than they strictly need, including the error messages and how to correct mistakes.

    • Have them deliver part of the end-user training. People trust a colleague who does the job more than an external consultant.

    • Give them a direct escalation path to the project team, so questions they cannot answer get resolved quickly.

    The mistake that undermines super usersAppointing them and not adjusting their workload.A super user with a full-time job and no allocated time will help colleagues for two weeks and then stop, exactly when the questions peak.

    Timing: The Window Is Narrower Than You Think

    Train too early and it is forgotten before go-live. Train too late and there is no time to practise. The workable pattern is a sequence rather than a single event.

    WhenWhat happensPurpose
    Project startAwareness communication to all staffExplain why, address job security fears early
    Design phaseSuper users involved in workshopsBuild understanding and ownership
    Testing phaseSuper users run user acceptance testingDeep learning through real scenarios
    2–4 weeks before go-liveRole-based end-user training on migrated dataCore skill building, close enough to remember
    1 week before go-liveSandbox practice time with support availableConsolidation; the step most often skipped
    Go-live weekFloor walking and on-the-spot helpConfidence at the moment of highest anxiety
    Weeks 2–6Refresher sessions on what people are struggling withCorrect bad habits before they set
    Month 3+Advanced and exception-handling trainingMove from surviving to competent

    The sandbox practice week is the one that gets cut, and it is arguably the most valuable. People learn a system by using it badly in a place where mistakes do not matter.

    Train on Your Own Data

    This single change improves training outcomes more than any other. Use a training environment loaded with migrated data — your customers, your items, your document formats, your workflows.

    • People recognise the records, so they engage with the process instead of decoding unfamiliar examples.

    • Real data exposes real edge cases during training rather than after go-live.

    • It builds confidence that the system will handle their actual work, which is the underlying anxiety.

    • It surfaces migration errors early, while there is still time to fix them.

    The objection is that migrated data is not ready in time. That is usually a symptom of migration starting too late, and it is worth solving for this reason alone.

    Materials That People Actually Use

    Comprehensive manuals are written, filed and never opened. What gets used is short, task-specific and available at the moment of need.

    • One-page job aids per task: how to enter a sales order, how to receive a purchase order, how to report production. Screenshots, numbered steps, nothing else.

    • Short screen recordings, two to four minutes each, one task per video. People re-watch these; they do not re-read manuals.

    • A quick-reference card per role, laminated and physically present at the workstation. Warehouses and shop floors are not places where people open PDFs.

    • An error-message guide — what the common messages mean and what to do. This single document removes a large share of support tickets.

    • A searchable internal FAQ that grows from real questions asked during and after go-live.

    Assign someone to keep these current after every system change. Materials that show an interface nobody recognises are worse than none, because they teach staff that documentation is unreliable.

    Measuring Whether Training Worked

    Attendance is not competence. Test whether people can actually perform their tasks.

    • Scenario-based assessment. Ask each person to complete three realistic tasks in the training environment unaided. Watching where they hesitate tells you what to reinforce.

    • Competence sign-off per role. A short checklist confirming each person can perform their core tasks, signed by their manager or super user.

    • Self-rated confidence, before and after. Low confidence predicts workarounds even when competence is adequate.

    • Post-go-live indicators: volume and type of support tickets, transaction error rates, time to complete common tasks, and how many people are still using the old process.

    The most revealing metric is the last one. If a shadow spreadsheet reappears in a department, that department’s training did not work, whatever the assessment scores said.

    The Situations That Complicate Training

    Multiple shifts

    Night and weekend shifts need the same training, delivered at hours that suit them, with super users on those shifts. Training only the day shift and expecting knowledge to transfer across handovers does not work, and the affected staff correctly interpret it as being deprioritised.

    Multiple sites

    Remote sites need local super users. Video training helps with consistency but does not replace someone physically present in the first week. Budget the travel or accept a slower ramp at those locations.

    Multiple languages

    Confirm which interface languages the system supports and whether your training materials need translating. Job aids matter more than the interface language here — people can navigate an unfamiliar interface if the instructions are in their own language.

    Low digital confidence

    Some experienced, highly capable staff are not comfortable with software. Smaller groups, more practice time, more patience, and paper job aids. Treating this as a performance problem rather than a training design problem loses good people.

    Seasonal and temporary staff

    If your workforce expands seasonally, you need a repeatable onboarding package that a super user can deliver in a couple of hours. Design it during the project rather than improvising it at the first peak.

    Support in the First Weeks

    Hypercare is where training either lands or unravels. Plan two to six weeks of intensified support.

    • Floor walking. Super users and project team physically present, visible, and approachable. This is worth more than any helpdesk.

    • A single, visible issue list. One place where problems are logged and their status is public. Silence about a known issue produces rumours.

    • Daily stand-ups in the first week, moving to twice weekly. Fifteen minutes, focused on what is blocking people.

    • Fast triage. Distinguish system defects from training gaps immediately, because they route to different fixes and confusing them wastes both.

    • Explicit permission to be slow. Tell staff productivity will dip and that this is expected. Unspoken pressure to keep pace is what pushes people back to the old process.

    Expect a productivity dip of two to six weeks. It is normal, it is temporary, and pretending it will not happen is how a normal transition gets labelled a failure.

    Training Never Actually Ends

    • New starters need the same role-based training, not a colleague’s rushed explanation. Keep the onboarding package current.

    • After every significant update, retrain on what changed. Cloud systems update on the vendor’s schedule, so build this into your operating rhythm.

    • Refresher sessions at three and six months, targeted at the tasks generating the most errors.

    • Advanced training once people are competent — reporting, exception handling, the features nobody had capacity to absorb at go-live. This is where the second wave of benefit comes from.

    Budgeting for Training

    Training costs are mostly internal time rather than external fees, which is precisely why they get understated in business cases. Include:

    • Trainer fees or internal trainer time.

    • Super user time for preparation, testing and delivery — allocated, not assumed.

    • End-user time away from their normal job.

    • Materials development and ongoing maintenance.

    • Training environment costs, if the sandbox is charged separately.

    • Floor-walking support during hypercare.

    • The productivity dip itself, which is a real cost even though no invoice arrives for it.

    When the schedule tightens and something must give, remove a module from the first phase rather than removing training. Deferring functionality costs less than going live with staff who cannot use what you deployed.

    Frequently Asked Questions

    How long before go-live should ERP training happen?

    Core role-based training two to four weeks before go-live, followed by supervised practice time in a sandbox during the final week. Earlier than a month and it fades; later and there is no time to consolidate. Super users should be learning much earlier, through design workshops and testing.

    How much training does each user need?

    It varies enormously by role. Occasional approvers may need under an hour; order entry, warehouse and finance staff typically need several hours of focused, role-specific training plus practice time; super users need considerably more. Plan by role and task, not by a uniform number of days.

    What is a super user?

    A respected practitioner from each department who learns the system deeply, participates in testing, and becomes the first line of support for colleagues. They are the highest-return training investment because people ask a nearby colleague long before they raise a ticket.

    Should we train on real data or demo data?

    Real migrated data, in a dedicated training environment. People engage far better with records they recognise, real data exposes real edge cases during training rather than after go-live, and it surfaces migration errors while there is still time to fix them.

    How do we measure whether training worked?

    Scenario-based assessment where people complete realistic tasks unaided, competence sign-off per role, and post-go-live indicators such as support ticket volume, transaction error rates and task completion times. The clearest signal is whether shadow spreadsheets reappear.

    What if staff resist the new system?

    Resistance is usually a symptom rather than the problem. Common causes are fear about job security, being excluded from design decisions, insufficient practice time, or a genuine step backwards in their daily workflow that nobody acknowledged. Diagnose the cause before treating it as an attitude problem — the last cause in that list is frequently real and fixable.

    Who should deliver the training?

    A combination works best. The implementation partner brings product depth, super users bring credibility and process context, and internal trainers handle scale and consistency. Sessions delivered entirely by external consultants tend to be product tours rather than job training.

    How much should we budget for training?

    Most of the cost is internal time rather than external fees, so budget the hours as well as the invoices. The more useful discipline is protecting it: when the schedule slips, cut scope rather than training, because deferring a module costs far less than deploying one nobody can use.

    Conclusion

    ERP training fails when it is treated as an event to be attended rather than a behaviour change to be supported. The system does not deliver value when it is configured; it delivers value when people use it correctly, consistently, and in preference to the workaround they used before.

    Design by role, build a super user network and give them real time to do the job, train on your own data close to go-live with practice time afterwards, produce short materials people will actually open, measure competence rather than attendance, and staff the first weeks properly. Training is the cheapest thing in the project and the thing that decides whether the rest of it worked.

  • ERP Data Migration: A Practical Guide to Getting Your Data Across Cleanly

    ERP Data Migration: A Practical Guide to Getting Your Data Across Cleanly

    Data migration is scheduled as a technical task near the end of the project and then becomes the reason the project is late. The pattern is consistent enough to be predictable: nobody owns the data, cleanup starts six weeks before go-live, and the team discovers a decade of duplicate customers, items with no cost and inventory records that disagree with the warehouse — all after the go-live date has been announced to the board.

    This guide covers what actually needs to move, how to profile and clean data before anyone touches a mapping document, how to run trial loads properly, how to reconcile in a way that would satisfy an auditor, and how to structure cutover so it takes a weekend rather than a fortnight.

    Why Migration Deserves More Attention Than It Gets

    Three things make data migration disproportionately dangerous.

    • Errors become permanent and invisible. A wrong cost on an item in a spreadsheet is an annoyance. The same wrong cost inside an ERP flows into margin reports, valuation, pricing decisions and financial statements, and everyone trusts it because it came from the system.

    • The scale is unknowable until you start. No one can estimate how dirty their data is from memory. It always turns out to be worse, and the difference between expectation and reality is where the schedule goes.

    • It sits on the critical path with nothing after it. Every other task can be deferred or descoped. Migration cannot — you cannot go live without data.

    The practical consequence: data cleanup is a prerequisite, not a project deliverable.Starting the ERP project before addressing it does not fix it faster; it just moves the discovery of the problem to a more expensive moment.

    What Actually Needs to Move

    The instinct is to bring everything. Resist it. Migrating twenty years of history multiplies effort, extends testing and imports every historical error into a system people are supposed to trust.

    Data categoryExamplesUsual decision
    Master dataCustomers, suppliers, items, chart of accounts, employees, price listsMigrate — this is essential
    Structural dataBills of materials, routings, warehouse locations, tax codesMigrate — required for the system to function
    Open transactionsUnpaid invoices, open purchase and sales orders, work in progressMigrate — the business depends on them
    Opening balancesTrial balance, inventory quantities and values, fixed asset registersMigrate — reconciled to the last closed period
    Recent historyLast one to two years of closed transactionsMigrate selectively, if there is a genuine operational need
    Deep historyOlder closed transactions, superseded recordsArchive — keep the legacy system readable instead
    DocumentsAttachments, contracts, drawings, certificatesMigrate selectively, or link to a document store

    The test for historical data is simple: what specific business process breaks if this is not in the new system? “We might want to look at it” is answered by archiving and read-only access to the legacy system, which costs a fraction of migration and testing.

    The archiving decision people regret skippingKeep the legacy system, or a full export of it, in a readable state for as long as your record-retention obligations require.It is far cheaper than migrating history, and it answers the audit question that will eventually be asked.

    The Migration Process, Stage by Stage

    Stage 1: Profile before you plan

    Data profiling means measuring the actual state of your data rather than assuming it. Run these counts early — in the first month of the project, not the last.

    • Total records per entity, and how many are genuinely active in the last twelve months.

    • Duplicate rate on customers, suppliers and items, tested on more than exact name matches.

    • Completeness: percentage of records missing tax identifiers, addresses, costs, units of measure.

    • Consistency: how many different formats exist for the same field — phone numbers, country names, units.

    • Referential integrity: transactions pointing at records that no longer exist.

    • Outliers: negative quantities, zero costs, future-dated records, absurd values.

    Profiling converts a vague worry into a number. “We have 14,200 customer records, 6,800 active in the last year, and an estimated 11% duplicate rate” is a plan. “Our customer data is a bit messy” is not.

    Stage 2: Decide the cleansing rules

    Cleansing is a business decision, not a technical one. Someone with authority must decide what a duplicate is, which record survives, and what happens to records that cannot be repaired.

    • Deduplication rules. Which fields determine a match, how close is close enough, and which record is the survivor when two conflict.

    • Standardisation rules. One format per field — country codes, units of measure, address structure, naming conventions for items.

    • Completion rules. What to do when a mandatory field in the new system is empty in the old one: derive it, default it, or exclude the record.

    • Exclusion rules. Which records simply do not come across — inactive customers with no balance, obsolete items with no stock.

    • Ownership. Who signs off each entity. Finance owns the chart of accounts and balances; operations owns items and BOMs; sales owns customers.

    Clean at source wherever possible. Fixing records in the legacy system means the improvement is real for as long as you still operate it, and it prevents the same errors being re-created during the final weeks.

    Stage 3: Map every field explicitly

    The mapping document is the contract between old and new. For every field it should record: source system and field, target system and field, transformation applied, default when empty, validation rule, and who approved it.

    Mapping surfaces the awkward questions early, which is its real value. Old system has one address field and the new system has five. Old item codes are twelve characters and the new system allows twenty — do you renumber now or preserve the legacy codes forever? These decisions are cheap in month two and expensive in month eight.

    Stage 4: Trial load, repeatedly

    Load into a test environment early, while there is still time to fix what breaks. Expect to run this three to five times, each iteration finding fewer problems than the last.

    1. First load: deliberately small. One hundred customers, one hundred items. Find the structural problems fast.

    2. Second load: full volume of one or two entities. Find the performance issues and the edge cases hiding in the long tail.

    3. Third load: everything, into the environment used for user acceptance testing. Users must test against realistic data, not invented data.

    4. Dress rehearsal: the full cutover procedure, timed end to end, against a recent copy of production. This is the load that tells you whether your cutover window is realistic.

    Automate the load scripts. Manual loading cannot be repeated reliably, and you will need to repeat it. Scripted loads also mean the final production run is an execution of something already proven rather than a first attempt under time pressure.

    Stage 5: Validate and reconcile

    Eyeballing a few records is not validation. Three layers are needed.

    LayerWhat it checksMethod
    Technical reconciliationNothing was lost or duplicated in transitRecord counts and control totals per entity, source versus target
    Financial reconciliationBalances agree exactlyTrial balance, AR and AP ageing, inventory value tied to the last closed period
    Business validationThe data is actually correct, not merely presentProcess owners open records they know well and confirm them

    The third layer is the one most often skipped and the one that catches the errors that matter. Ask each process owner to open ten customers, ten items and ten open orders they know intimately, and confirm the detail is right. A count that matches proves nothing if every record is wrong in the same way.

    The Areas That Cause the Most Trouble

    Opening balances

    Finance data must reconcile exactly, not approximately. Migrate the trial balance as at a clean cut-off, usually the last closed period. Bring across open receivables and payables at document level rather than as a single balance, because customers pay against invoices and you will need the detail for collections and remittance matching. Fixed assets need cost, accumulated depreciation and remaining life, or the depreciation charge will be wrong from the first month.

    Inventory

    Quantities must match the physical warehouse, not the old system’s opinion of it. Do a full physical count immediately before cutover. Migrating stock records that disagree with reality destroys confidence in the system in the first week, and it is a very hard reputation to recover.

    Valuation is the second half of the problem. Confirm which costing method the new system uses and ensure the migrated values are consistent with it. A mismatch between migrated cost and the new system’s costing logic produces variances that nobody can explain later.

    Bills of materials and routings

    For manufacturers, this is the highest-risk data of all. BOMs must reflect what is actually consumed on the floor, including scrap and packaging, not what the engineering drawing says. Errors propagate into material planning, costing and backflushing simultaneously, and they compound silently.

    Lot and serial history

    Regulated industries need traceability across the cutover boundary. Decide before migration how a recall investigation will work when the batch was produced in the old system and shipped from the new one. Usually this means migrating lot genealogy for material still in stock, and keeping the legacy system accessible for anything already shipped.

    Open orders and work in progress

    Partly completed transactions are awkward because they exist in a state neither system was designed to receive. Decide the policy early: close as much as possible in the legacy system before cutover, and migrate only what genuinely cannot be closed. Partly delivered sales orders, partly received purchase orders and partly completed work orders each need an explicit rule.

    Cutover: The Weekend Itself

    Cutover is the sequence that moves you from old to new. It should be a rehearsed procedure, not an improvisation.

    5. Freeze the legacy system at an agreed moment. Communicate it widely — every department, plus customers and suppliers if document formats change.

    6. Complete outstanding transactions in the old system where possible: post invoices, receive goods, close what can be closed.

    7. Run the final physical inventory count and adjust the legacy records to match.

    8. Extract, transform and load using the scripts already proven in the dress rehearsal.

    9. Reconcile. Counts, control totals and financial balances. Do not proceed past this point on partial reconciliation.

    10. Business validation sign-off. Named process owners confirm their area, in writing.

    11. Open the new system to users, with support staff physically present or immediately reachable.

    12. Keep the legacy system available read-only for reference and audit.

    Agree rollback criteria in advance — the specific conditions under which you would stop and return to the legacy system. Deciding this under pressure at three in the morning produces bad judgement. Written criteria produce a decision.

    Who Owns What

    RoleResponsibility
    Data ownerAccountable for overall data quality and readiness; escalates blockers; the single most commonly omitted role
    Process ownersDefine cleansing rules for their area, validate loaded records, sign off before go-live
    Technical leadBuilds extraction and load scripts, manages transformations, runs the loads
    Finance leadReconciles opening balances; the only person who can sign off financial data
    Project managerSchedules the load iterations, tracks defects, protects the timeline
    Implementation partnerAdvises on target structures and known pitfalls; cannot decide your business rules

    Mistakes That Cost the Most

    13. Starting too late. The most expensive and the most common. Profiling should happen in month one.

    14. Migrating everything. Effort, testing and risk all scale with volume, and most historical data is never queried.

    15. Cleaning after loading. Fixing data inside the new system is slower, and dirty records get used before they are corrected.

    16. Manual loads. Cannot be repeated reliably, cannot be rehearsed, and cannot be audited.

    17. Reconciling only counts. Matching totals with uniformly wrong detail is worse than an obvious failure, because nobody catches it.

    18. Skipping the physical count. Inventory that disagrees with the warehouse on day one destroys trust in the whole system.

    19. No named data owner. Data quality becomes everyone’s responsibility, which means nobody’s.

    20. Assuming the partner will handle it. They can build the scripts. They cannot decide which of your two customer records is the real one.

    How Long It Takes

    ActivityTypical share of migration effort
    Profiling and analysis10–15%
    Cleansing and deduplication30–40%
    Mapping and transformation design15–20%
    Building and testing load routines15–20%
    Trial loads and defect resolution10–15%
    Final cutover and reconciliation5–10%

    Cleansing dominates, and it is the part that cannot be compressed by adding technical resource, because it requires business decisions from people who have other jobs. That is the real reason migration timelines slip.

    Frequently Asked Questions

    How much historical data should we migrate?

    As little as the business genuinely needs. Master data, structural data, open transactions and opening balances are essential. Beyond that, migrate history only where a specific process would break without it — and archive the rest with read-only access to the legacy system.

    When should data cleansing start?

    In the first month of the project, ideally before it. Cleansing is the largest component of migration effort and depends on business decisions from busy people, so it cannot be compressed by adding technical resource later.

    Should we clean data in the old system or the new one?

    In the old system wherever possible. The improvement is real for as long as you still operate it, it prevents new errors being created during the final weeks, and it means the load routine carries clean data rather than correcting it in flight.

    How do we know the migration was successful?

    Three tests must all pass: record counts and control totals match between source and target; financial balances reconcile exactly to the last closed period; and named process owners have opened records they know well and confirmed the detail is correct. Passing only the first two is a common and dangerous false positive.

    Can we go live with imperfect data?

    You will, because perfect data does not exist. The distinction that matters is between known and unknown imperfection. Documented gaps with a remediation plan are manageable. Undiscovered errors that surface as wrong invoices and wrong stock in week one are not.

    What happens to the old system after go-live?

    Keep it running read-only for as long as your record-retention obligations require, or take a complete, verifiable export in a format you can still open. Decommissioning it before an audit cycle has passed is a decision that gets regretted.

    Who should own data migration?

    A named internal data owner with authority to make decisions, supported by process owners per functional area. The implementation partner builds and runs the technical process, but only your people can decide which duplicate record is correct or how an incomplete item should be classified.

    Do we need a physical inventory count before cutover?

    If you hold stock, yes. Migrating inventory records that disagree with the physical warehouse undermines confidence in the system from the first day, and once staff stop trusting the stock figures they revert to checking manually — which removes most of the benefit you paid for.

    Conclusion

    Data migration is not a technical exercise appended to the end of an ERP project. It is a business exercise that determines whether anyone trusts the system afterwards, and it needs an owner, a start date in month one, and business decisions made by people with authority to make them.

    Profile early so the scale is a number rather than a worry. Move less than you think you need and archive the rest. Automate the loads so they can be rehearsed. Reconcile financially and validate with the people who know the records. Do that and cutover becomes a controlled weekend rather than the crisis that defines the project.

  • Why ERP Projects Fail: 12 Real Causes and How to Avoid Each One

    Why ERP Projects Fail: 12 Real Causes and How to Avoid Each One

    ERP failures are usually described as software problems and almost never are. The system that a company blames in year two is generally the same system running successfully at a competitor down the road. What differed was scope discipline, data quality, sponsorship, and whether anyone seriously addressed the fact that people would have to change how they work.

    This article covers twelve causes of failure, what each looks like from the inside, the early warning signs that appear months before anyone admits there is a problem, and what to do if you are already in one.

    What “Failure” Actually Means

    Very few ERP projects are abandoned outright. Failure is usually quieter and takes one of four forms:

    • Budget failure — the system works, and it cost far more than approved.

    • Schedule failure — go-live slipped repeatedly, and the delay cost more than the overrun on fees.

    • Benefit failure — the system went live on time and on budget, and none of the promised improvements materialised. This is the most common and the least reported.

    • Adoption failure — the system runs, and staff maintain shadow spreadsheets alongside it. Technically live, practically abandoned.

    Benefit and adoption failures are the ones worth worrying about, because they pass every project management checkpoint and only become visible when someone asks, a year later, whether anything actually improved.

    Cause 1: Scope That Was Never Really Defined

    What it looks like: the project charter says “modernise our systems” or “improve efficiency”. Every department assumes their priority is included. Nobody wrote down what is excluded, so nothing can be refused.

    Why it happens: defining scope requires saying no to colleagues before the project has any credibility. It is easier to defer the argument, and the argument then happens repeatedly, at higher cost, for the rest of the project.

    How to prevent it: write scope as measurable outcomes, and write an explicit out-of-scope list that is as long as the in-scope list. Establish a change-control process on day one, with a named approver and a cost estimate attached to every request. Requests that survive that process are usually genuine.

    Early warning: the phrase “while we’re in there, can we also…” appears in more than two meetings.

    Cause 2: Executive Sponsorship in Name Only

    What it looks like: a senior leader is listed as sponsor, attends the kickoff, and is not seen again. Cross-departmental disputes escalate to a project manager with no authority to settle them, so they do not get settled.

    Why it happens: sponsorship is treated as a title rather than a workload. Executives underestimate how many decisions an ERP project generates that only they can make.

    How to prevent it: define what the sponsor is actually committing to — attendance at steering meetings, decision turnaround within a defined period, visible communication to staff, and willingness to overrule a department head. If no executive will commit to that, the project is not ready to start.

    Early warning: steering committee meetings are cancelled or repeatedly rescheduled; decisions sit unresolved for weeks.

    Cause 3: Data Nobody Cleaned

    What it looks like: migration is scheduled for the final six weeks. It begins, and the team discovers thousands of duplicate customers, items with no cost, suppliers with wrong tax details, and inventory records that do not match the warehouse. The go-live date is already announced.

    Why it happens: data cleanup is unglamorous, nobody owns it, and its scale is invisible until someone starts. Every project underestimates it, including the ones that have been warned.

    How to prevent it: name a data owner at kickoff, not at migration. Start cleaning in the first month. Profile the data early — count duplicates, blanks and outliers — so the scale of the work is a number rather than a feeling. Migrate master data and opening balances; archive transaction history instead of carrying it forward.

    Early warning: nobody can tell you how many customer records you have, or how many are active.

    Cause 4: Over-Customisation

    What it looks like: every process gap is closed with custom development. The system matches the old way of working perfectly. The first upgrade takes four months and breaks three modifications nobody remembers requesting.

    Why it happens: customising is easier than change management. Telling a department to adapt is a political cost; writing code is a line item. The bill arrives later, permanently, at every upgrade.

    How to prevent it: default to standard functionality. Require a written business justification for each customisation, approved by the sponsor, stating what competitive advantage it protects. Most requests do not survive that question. Keep customisation for genuine differentiators and adapt everywhere else.

    Early warning: the customisation list grows during design instead of shrinking.

    Cause 5: Testing That Was Compressed

    What it looks like: the project runs late. Testing is the last phase before go-live, so testing absorbs the delay. User acceptance testing becomes a two-day demonstration rather than genuine scenario testing. Defects are discovered by customers in week one.

    Why it happens: testing is the only phase that can be shortened without an obvious immediate consequence. That is precisely why it should be protected.

    How to prevent it: protect testing in the plan and treat cutting it as a scope decision requiring sponsor approval. Run three layers — unit, integration, and user acceptance with real staff, real scenarios and migrated data. If the schedule must give, remove a module from the first phase rather than removing testing.

    Early warning: the test plan has fewer scenarios each time it is revised.

    Cause 6: Training Treated as an Event

    What it looks like: one training session, two weeks before go-live, delivered by a consultant on demo data. Staff go live having seen the system once, on records that bear no resemblance to their own.

    Why it happens: training is budgeted as a fixed number of days and scheduled where it fits, rather than designed around what people need to do.

    How to prevent it: train by role, on your own migrated data, in the environment people will actually use. Deliver close enough to go-live that it is fresh but with time to practise. Provide short task-based reference guides. Identify super users in each department and train them more deeply so support exists on the floor, not only on a ticket queue.

    Early warning: the training plan is described in days rather than in roles and tasks.

    Cause 7: The Team Was Never Backfilled

    What it looks like: your best operational people are assigned to the project on top of their existing full-time jobs. They attend design workshops between crises, make decisions while distracted, and burn out by month five.

    Why it happens: backfilling costs money that is visible in a budget, whereas exhausting your key staff costs money that is not.

    How to prevent it: cost project participation honestly in the business case. Either backfill the roles, reduce operational duties formally, or reduce project scope to match the capacity that genuinely exists. Assigning people without adjusting their workload is a decision to under-resource the project while pretending otherwise.

    Early warning: project workshops are repeatedly rescheduled because key people are firefighting.

    Cause 8: Nobody Managed the Change

    What it looks like: staff first hear about the new system when they are invited to training. Rumours about job losses circulate. On go-live day, resistance appears as a thousand small refusals — data entered incorrectly, workarounds preserved, the old spreadsheet quietly maintained.

    Why it happens: change management sounds soft, is easy to cut, and its absence produces no visible symptom until the system is live.

    How to prevent it: communicate early and repeatedly. Explain what improves for each team, not only what improves for management, and be honest about what gets harder. Involve staff in design so the system reflects their reality. Address job security questions directly rather than allowing the vacuum to fill itself.

    Early warning: people refer to it as “the finance system” or “IT’s project” rather than as the company’s system.

    Cause 9: The Wrong System Was Chosen

    What it looks like: six months in, a fundamental capability is missing — finite scheduling, a costing method, a compliance report — and the only routes forward are a bolt-on, a heavy customisation, or a manual process.

    Why it happens: selection was decided on demo quality rather than verified fit. Must-have requirements were never tested against real scenarios, and “that can be customised” was accepted as a yes.

    How to prevent it: score against scripted scenarios drawn from your own business, mark must-haves as pass or fail independently of the total score, and treat roadmap functionality as absent. Call references at your size in your industry and ask what they discovered after go-live.

    Early warning: during selection, more than a couple of your requirements were answered with a plan rather than a demonstration.

    Cause 10: The Partner Was Wrong for You

    What it looks like: consultants who know the software but not your industry. Advice that produces a technically correct configuration nobody can operate. Named senior consultants replaced by juniors after the contract is signed.

    Why it happens: partners are selected on price or on vendor recommendation rather than on verified comparable experience, and staffing is not contractually protected.

    How to prevent it: ask for three references of your size in your industry and call all three. Ask who specifically will work on your project and get key personnel written into the contract. Confirm knowledge transfer is planned so you are not permanently dependent.

    Early warning: the people in the sales meetings are not the people who appear at the first workshop.

    Cause 11: A Timeline Nobody Believed

    What it looks like: the date was set by a board meeting, a financial year end, or a contract expiry rather than by the work required. Everyone involved privately knows it is not achievable, and nobody says so until it is missed.

    Why it happens: optimistic dates get approved and honest dates get challenged, so honest estimates are quietly adjusted upward until they fit.

    How to prevent it: plan to the honest estimate. Build in contingency explicitly rather than hiding it inside task estimates. Use stage gates with defined criteria, so slippage is visible early rather than announced at the end. Create an environment where raising a risk is rewarded rather than treated as negativity.

    Early warning: the plan has no contingency, and every task is estimated at exactly the time available.

    Cause 12: No Ownership After Go-Live

    What it looks like: the partner leaves at the end of hypercare. Nobody internally owns the system. Configuration drifts, reports stop matching, permissions are granted ad hoc, and within eighteen months people are building spreadsheets again.

    Why it happens: the project budget ends at go-live, and ongoing ownership was never established as a role.

    How to prevent it: name an internal system owner during the project, not after it. Give them time allocated to the role. Plan knowledge transfer from the partner deliberately. Schedule a formal benefits review at six and twelve months to check whether the improvements you bought have actually appeared.

    Early warning: nobody can answer the question “who owns this system after go-live?”

    Warning Signs, Ranked by How Early They Appear

    When it appearsWarning signWhat it usually predicts
    Before kickoffNo named sponsor with real authorityDecisions will stall from month two
    Before kickoffScope described in adjectives, not outcomesScope creep and budget overrun
    Month 1–2Nobody owns data qualityMigration crisis in the final weeks
    Month 2–4Customisation list growing during designPainful, expensive upgrades forever
    Month 2–4Key staff missing workshops due to day jobsDesign decisions made without the people who know
    Month 4–6Test plan shrinking with each revisionDefects discovered by customers after go-live
    Month 4–6Staff still calling it “IT’s project”Adoption failure regardless of configuration quality
    Near go-liveTraining compressed into a single sessionProductivity dip that never fully recovers
    After go-liveShadow spreadsheets reappearingBenefits will not materialise

    If You Are Already In Trouble

    Most struggling projects are recoverable. The recovery is rarely comfortable.

    39. Stop and assess honestly. Pausing for two weeks to establish the real position costs less than three more months of pushing toward an impossible date.

    40. Get an independent view. Internal teams cannot easily report that a project they are running is failing. An outside assessment gives people permission to say what they already know.

    41. Cut scope before cutting quality. Deferring a module costs far less than going live untested and untrained.

    42. Re-baseline the plan publicly. A revised, credible date restores confidence faster than repeated small slips.

    43. Fix data before anything else. No configuration decision improves a system loaded with wrong data.

    44. Reset sponsorship. If the sponsor has disengaged, replace them or formally escalate. The project cannot proceed without someone who can settle disputes.

    45. Decide about the partner deliberately. Changing partners mid-project is expensive and disruptive, and sometimes it is still the cheapest remaining option.

    46. Consider a phased fallback. Going live with finance only, properly, beats going live with everything, badly.

    The decision most companies avoid too longIf the system genuinely cannot meet a must-have requirement, no amount of additional effort will change that.Stopping is expensive. Continuing toward a system that cannot do the job is more expensive, and the cost compounds for years.

    Frequently Asked Questions

    What is the most common cause of ERP failure?

    Poor data quality and inadequate change management are the two that appear most consistently, usually together. Both share the same underlying pattern: they are unglamorous, easy to defer, and produce no visible symptom until the point at which fixing them is expensive.

    Is ERP failure the software’s fault?

    Rarely. The same systems that produce disasters at one company run successfully at comparable companies elsewhere. Genuine software mismatch does happen, but it almost always traces back to a selection process that accepted claims without verifying them against real scenarios.

    How do I know if my project is failing?

    Look for shrinking test plans, a growing customisation list, cancelled steering meetings, key staff missing workshops, and staff referring to the system as somebody else’s project. These appear months before a missed go-live date and are far easier to address early.

    Can a failing ERP project be recovered?

    Usually, yes. Recovery typically requires reducing scope, re-baselining the timeline publicly, fixing data properly, and restoring active sponsorship. The main obstacle is organisational reluctance to acknowledge the position early enough for those actions to still be cheap.

    Should we go live if we are not ready?

    No. Going live untested and untrained converts a schedule problem into an operational one, and operational problems damage customer relationships that outlast the project. Reduce scope and go live with less, properly, instead.

    How much contingency should an ERP project carry?

    Ten to twenty percent is a common range, weighted higher for manufacturing, multi-entity structures, or projects with known data quality issues. Contingency should be explicit rather than hidden inside task estimates, so that consuming it is a visible decision.

    What is the single highest-return preventive action?

    Naming a data owner at kickoff and starting data cleanup in month one. It is the cheapest intervention available and it removes the most common cause of late-stage crisis.

    Conclusion

    ERP projects fail for organisational reasons dressed up as technical ones. Undefined scope, absent sponsorship, dirty data, reflexive customisation, compressed testing, token training and unmanaged change account for the overwhelming majority of disappointing outcomes — and every one of them is visible months before the consequences arrive.

    Name a sponsor who will actually decide things. Own your data from day one. Adapt to the software rather than rebuilding it. Protect testing and training when the schedule tightens. And appoint someone to own the system after go-live, because a system nobody owns quietly reverts to spreadsheets within two years.

  • ERP for Manufacturing: Features That Actually Matter on the Shop Floor

    ERP for Manufacturing: Features That Actually Matter on the Shop Floor

    Generic ERP handles manufacturers badly, and it usually fails in the same predictable place: the system can record that you made something, but it cannot help you decide what to make, when to start it, whether you have the capacity, or what it truly cost. Those four questions are the entire job of manufacturing ERP.

    This guide covers what manufacturing ERP must do, how the requirements differ by production type, the modules that matter and the ones that only sound impressive, the data you must fix before implementing, and how to run a selection process that does not end with a system your production planner refuses to use.

    Why Generic ERP Fails Manufacturers

    A distribution-oriented ERP treats an item as something you buy and sell. A manufacturing ERP treats an item as something that may be bought, made, or assembled from other items which themselves may be bought or made — recursively, several levels deep, each with lead times, scrap allowances and capacity requirements.

    That difference produces concrete gaps. Generic systems typically lack:

    • Multi-level bills of materials with phantom assemblies, alternates and effectivity dates.

    • Routings — the sequence of operations, the work centres they run on, and the setup and run times for each.

    • A real MRP engine that explodes demand through the BOM and nets it against stock, open purchase orders and existing work orders.

    • Capacity planning that tells you whether the plan is physically achievable on the machines and shifts you have.

    • Work-in-progress accounting that values partly finished goods correctly at period end.

    • Actual costing that captures real material consumption, labour and overhead rather than assuming the standard.

    • Lot and serial traceability in both directions, from raw material to customer and back.

    Manufacturers who buy a generic system usually discover this three months in, then spend the next year building spreadsheets alongside it — which is the situation they bought ERP to escape.

    Your Manufacturing Type Determines Your Requirements

    Before evaluating anything, identify which of these describes you. Most companies are one primary type with elements of another, and the mix matters.

    TypeWhat it meansWhat the ERP must handle well
    DiscreteCountable, assembled products — machinery, electronics, furnitureMulti-level BOMs, routings, serial tracking, work orders
    ProcessFormulations and recipes — food, chemicals, pharmaceuticals, cosmeticsRecipes with variable yields, batch tracking, potency, co-products and by-products, units of measure conversion
    Make-to-stockProduced to forecast and held in inventoryDemand forecasting, safety stock, master production scheduling
    Make-to-orderProduction starts when an order arrivesOrder-linked work orders, promise dates, available-to-promise logic
    Engineer-to-orderEach order requires design work firstProject accounting, engineering change control, quoting from partial BOMs
    RepetitiveHigh-volume, continuous line productionRate-based scheduling, backflushing, minimal transaction overhead
    Mixed modeSeveral of the above in one plantAbility to run different production models side by side without workarounds

    The mixed-mode case deserves attention because it is common and frequently under-specified. A company that makes standard products to stock and also takes custom orders needs a system that supports both without forcing the custom work into a shape it does not fit.

    The Modules That Genuinely Matter

    Bill of materials

    The BOM defines what goes into a product. A capable manufacturing BOM supports multiple levels, alternate components, phantom assemblies that exist only in the structure, scrap and yield percentages per component, effectivity dates so a change applies from a given date forward, and revision control with history.

    The question to ask in a demo: how does the system handle an engineering change on a component that is already inside three open work orders? The answer tells you more about the product than an hour of feature slides.

    Routings and work centres

    The routing defines how a product is made: the operation sequence, which work centre or machine performs each, setup time, run time per unit, and any queue or move time between operations. Work centres carry capacity — available hours by shift, efficiency factors, and often a cost rate for labour and overhead absorption.

    Without accurate routings you cannot schedule realistically, cannot cost accurately, and cannot answer whether a promised delivery date is achievable. Routings are also the data most manufacturers have never formally documented, which makes this a project in itself.

    Material requirements planning

    MRP takes demand — sales orders, forecasts, safety stock targets — explodes it through the BOM, nets it against available inventory, open purchase orders and existing work orders, applies lead times, and produces recommendations: purchase this, make that, start on this date.

    Things to verify: how often it can run, whether it runs on the full data set or a subset, whether it handles minimum order quantities and multiples, how it treats lot sizing rules, and whether the planner can see clearly why a recommendation was made. An MRP engine whose logic is opaque will be overridden and eventually ignored.

    Capacity planning and scheduling

    MRP answers what and when in terms of material. Capacity planning answers whether the plan is physically possible. Two levels exist: rough-cut capacity planning against key resources for the master schedule, and detailed capacity requirements planning at operation level.

    The critical distinction is infinite versus finite scheduling. Infinite scheduling assumes unlimited capacity and produces a plan that looks fine and is not achievable. Finite scheduling respects real capacity constraints and produces a plan you can execute. Many ERP systems offer only infinite scheduling in the core product and sell finite scheduling as an add-on. Ask explicitly, because this is one of the most common post-purchase disappointments.

    Shop floor control

    How work gets recorded as it happens: operators clocking on and off operations, reporting quantities completed and scrapped, consuming materials, and flagging problems. The practical requirements are usually about the interface — touchscreen-friendly, barcode-driven, fast, and usable by someone wearing gloves in a noisy environment.

    Also consider backflushing, where material consumption is recorded automatically when production is reported rather than transaction by transaction. It reduces data entry substantially and depends entirely on BOM accuracy, which is a reason to fix your BOMs before go-live rather than after.

    Quality management

    Inspection plans, sampling rules, non-conformance records, corrective and preventive action workflows, supplier quality tracking, certificates of analysis and calibration records. In regulated sectors this is not optional and often drives the whole selection.

    Traceability

    Lot and serial tracking in both directions. Forward: this batch of raw material went into these work orders and shipped to these customers. Backward: this customer complaint traces to this batch, from this supplier, received on this date. In food, pharmaceutical, aerospace and automotive contexts, the speed of that query during a recall is a business-survival question, not a reporting convenience.

    Costing

    Manufacturing costing is where finance and operations meet and frequently disagree. Understand which methods the system supports:

    MethodHow it worksSuits
    Standard costingPredetermined cost per item; variances analysed against actualsStable, repetitive production
    Actual costingReal material, labour and overhead captured per work orderVariable or custom production
    Average costingWeighted average across receiptsCommodity-like items with fluctuating prices
    Job costingCosts accumulated per job or projectMake-to-order and engineer-to-order

    Also confirm how overhead is absorbed, how work-in-progress is valued at period end, and whether variances can be analysed by cause — material price, material usage, labour rate, labour efficiency. Aggregate variance with no explanation is a number nobody can act on.

    ERP and MES: Where the Line Sits

    Manufacturing execution systems overlap with ERP and are frequently confused with it. A workable distinction:

    • ERP plans and accounts. What to make, when to start, what materials to buy, what it cost, what to invoice.

    • MES executes and monitors. Real-time machine data, operator instructions at the station, in-process quality checks, detailed downtime reasons, second-by-second production status.

    Smaller manufacturers usually run ERP shop floor control alone and do not need MES. Complex or highly automated operations run both, integrated. The failure mode to avoid is buying both and not integrating them, which produces two versions of production reality and an argument every morning.

    Industry-Specific Requirements

    SectorRequirements that commonly drive the selection
    Food and beverageLot traceability, shelf life and expiry, allergen management, catch weight, recall simulation, quality holds
    Pharmaceutical and life sciencesValidation documentation, electronic records and signatures, batch genealogy, deviation management, full audit trails
    AutomotiveEDI with customers, release schedules, container and label standards, supplier quality requirements, serial traceability
    Aerospace and defenceCertification and airworthiness records, full component genealogy, engineering change control, export-control handling
    ElectronicsComponent substitution and approved vendor lists, serial and firmware tracking, rapid engineering change cycles
    Metal fabricationNesting and remnant tracking, heat and mill certificates, secondary operations, outside processing

    If you operate in one of these, an ERP with genuine pre-built industry functionality will usually beat a general platform that has to be configured toward the same result. The industry version has already learned the lessons your consultant would otherwise learn on your budget.

    Fix This Data Before You Implement

    Manufacturing implementations fail on data more than on software. Three data sets determine the outcome.

    Bills of materials

    Every BOM must reflect what is actually consumed, including scrap rates, packaging and any component the shop floor quietly adds. If the BOM is wrong, MRP orders the wrong materials, costing is wrong, and backflushing corrupts inventory. Aim to verify BOMs against real production, not against the engineering drawing, before go-live.

    Routings

    Most manufacturers have never formally documented setup and run times. Estimating them is acceptable to start with, provided you plan to refine them from actuals in the first six months. Treating a rough estimate as permanent truth is how scheduling loses credibility with the people who use it.

    Inventory accuracy

    MRP built on inaccurate stock records produces confident nonsense. If your physical inventory accuracy is materially below the high nineties, fix that first through cycle counting and location discipline. This is unglamorous, takes months, and is the single highest-return preparation activity available to you.

    The uncomfortable sequencing pointBOM accuracy, routing data and inventory accuracy are prerequisites, not deliverables of the ERP project.Starting the implementation before they are addressed does not fix them faster. It just moves the discovery of the problem to a more expensive moment.

    Integrations Manufacturers Usually Need

    • CAD and PLM — so engineering changes and new part numbers flow into the BOM without manual re-entry.

    • Barcode and RFID scanning — for receiving, picking, work-order transactions and finished-goods putaway.

    • Machine and IoT data — run hours, counts, downtime reasons feeding back into ERP or MES.

    • EDI — mandatory in automotive and much of retail supply.

    • Shipping and freight systems — label generation, carrier rates, tracking.

    • Quality instruments — measurement data captured directly rather than transcribed.

    • Payroll and time systems — where shop floor clocking also drives wages.

    For each integration decide direction, frequency, which system owns each field, and what happens when the connection fails. A silent integration failure that nobody notices for a week is more damaging than an outage that stops everything immediately.

    Selection Criteria for Manufacturers

    24. Does it natively support your production type? Not “can it be configured to” — natively.

    25. Is scheduling finite or infinite, and is finite included or an add-on? Get this in writing.

    26. How does it handle engineering changes on in-progress work orders? Demo it with your own scenario.

    27. Which costing methods are supported, and how is WIP valued at period end? Have your accountant in the room.

    28. How fast can you complete a full traceability query in both directions? Time it during the demo.

    29. How usable is the shop floor interface for someone in gloves, standing, in a noisy plant? Have an operator try it.

    30. Does the partner have manufacturing references in your sector and at your size?Call them.

    31. What does the mobile and offline experience look like when the network drops in the far corner of the plant?

    32. Can the planner see why MRP made each recommendation, and override it with a recorded reason?

    33. What is the realistic implementation timeline for a manufacturer of your complexity, from someone who has done it?

    Implementation Pitfalls Specific to Manufacturing

    • Going live during peak season. Manufacturing go-lives cause a temporary throughput dip. Choose a quiet period or accept the consequence deliberately.

    • Ignoring the shop floor during design. Operators will find a workaround for any interface that slows them down, and the data will silently degrade.

    • Loading unverified BOMs. Everything downstream inherits the error, and it compounds.

    • Skipping finite scheduling because it costs extra, then discovering the plan is unachievable in month two.

    • Treating routings as an engineering task. They are, but the times must be validated against reality by the people who run the machines.

    • Underestimating training for shift workers. Multiple shifts mean multiple training sessions, including the ones at inconvenient hours.

    • Cutting over inventory without a physical count. Opening balances that do not match the floor undermine trust in the system from day one.

    What Good Looks Like After Go-Live

    Track these, and expect them to worsen briefly before improving:

    MetricWhat ERP should improve
    On-time deliveryBetter promising and realistic scheduling
    Inventory turnsLess material held because visibility improved
    Inventory accuracyTransaction discipline and cycle counting
    Schedule adherenceAchievable plans that the floor believes
    Scrap and rework rateEarlier detection through quality integration
    Quote-to-order cycle timeFaster costing and availability checks
    Month-end close durationWIP and consumption posted as they happen
    Traceability query timeFrom days of paperwork to minutes

    Frequently Asked Questions

    What is the difference between ERP and MRP?

    MRP calculates the materials and components needed to meet a production schedule. ERP includes MRP as one module and extends across finance, sales, purchasing, quality and HR. Every credible manufacturing ERP contains an MRP engine; not every system with MRP is an ERP.

    Do I need ERP or MES?

    ERP plans and accounts; MES executes and monitors in real time. Most small and mid-sized manufacturers manage with ERP shop floor control alone. Highly automated or complex operations run both, integrated. Buying both without integrating them creates two versions of production reality.

    What is finite versus infinite scheduling?

    Infinite scheduling assumes unlimited capacity and produces plans that look achievable but are not. Finite scheduling respects real machine and labour capacity and produces executable plans. Many systems include only infinite scheduling by default and charge extra for finite — confirm this before you sign.

    How accurate do my BOMs need to be before implementing?

    As close to fully accurate as you can get. BOM errors propagate into material planning, costing, backflushing and inventory. Verify BOMs against what is actually consumed on the floor rather than against the engineering drawing, because the two frequently differ.

    How long does a manufacturing ERP implementation take?

    A single-site light manufacturer with clean data might go live in three to five months. More typical mid-market manufacturing projects run six to twelve months. Multi-site or regulated operations run longer. BOM and routing preparation is usually the critical path, not the software configuration.

    Should I choose an industry-specific ERP?

    If you operate in food, pharmaceutical, automotive, aerospace or another sector with heavy compliance requirements, usually yes. Pre-built industry functionality means less configuration and fewer expensive discoveries. Verify that the industry version is genuinely maintained rather than a legacy edition kept alive for existing customers.

    Can ERP handle both make-to-stock and make-to-order?

    Good manufacturing ERP supports mixed-mode production natively. Weaker systems force one model and require workarounds for the other. If you run both, make it an explicit must-have requirement and demand a demo of both flows in the same environment.

    What is backflushing?

    Automatically deducting component materials from inventory when production is reported, based on the BOM, rather than recording each consumption transaction individually. It substantially reduces data entry and depends entirely on BOM accuracy — with inaccurate BOMs it corrupts inventory quietly and continuously.

    Conclusion

    Manufacturing ERP succeeds or fails on three things that have nothing to do with the vendor’s feature list: whether your BOMs are true, whether your routings reflect reality, and whether the shop floor finds the system fast enough to use honestly.

    Select on native support for your production type, insist on scheduling that respects real capacity, get your data right before the project rather than during it, and involve the people who run the machines in the design. The manufacturers who do this get a planning system. The ones who do not get an expensive transaction recorder with spreadsheets running alongside it.

    ARTICLE 8

    ERP Selection Criteria: A 40-Point Checklist for Shortlisting Vendors

    SEO fieldValue
    Focus keywordERP selection criteria
    Secondary keywordsERP evaluation checklist, how to choose ERP software, ERP RFP, ERP vendor comparison, ERP scorecard
    Search intentCommercial investigation — buyers running a structured evaluation
    SEO title (meta title)ERP Selection Criteria: A 40-Point Checklist for Buyers
    Meta descriptionA complete ERP selection checklist: 40 evaluation criteria across eight categories, a weighted scorecard method, demo scripts and contract red flags.
    URL slugerpdetail.com/erp-selection-criteria
    Approx. word countApprox. 3,700
    Suggested internal linksLink to: what is ERP, ERP software cost, ERP implementation, why ERP projects fail, cloud ERP vs on-premise
    Suggested image alt textERP selection scorecard comparing vendors across functional, technical and cost criteria

    Most ERP selections are decided by the third demo, before anyone has verified a single claim. The vendor with the best sales engineer wins, the requirements document becomes a formality, and the real evaluation happens eight months later during implementation — when it is expensive.

    A structured selection is not bureaucracy. It is the mechanism that stops you from being persuaded by presentation quality. This guide gives you forty evaluation criteria across eight categories, a scoring method that produces a defensible decision, demo scripts that reveal what feature lists hide, and the contract terms worth arguing about before you sign.

    Before You Evaluate Anything

    Selection without requirements is shopping. Three things must exist first.

    1. Documented current processes

    How your business actually runs, including every workaround. Interview the people doing the work, not the managers describing it, because those are different documents. This is tedious and it is the step that most determines whether the eventual system fits.

    2. Requirements with consequences attached

    Split into must-have and nice-to-have. A genuine must-have has a consequence if missing — a compliance breach, an unservable customer, a process that cannot function. If nothing bad happens when it is absent, it belongs in nice-to-have. Most requirement lists are eighty percent nice-to-have pretending otherwise, which is why they fail to discriminate between vendors.

    3. Agreed decision rights

    Who scores, who shortlists, who signs, and who breaks a tie. Decide this before opinions form. Selections that stall almost always stall because nobody established in advance who decides.

    The 40 Criteria

    Category 1: Functional fit (criteria 1–8)

    #CriterionHow to verify it
    1Covers your must-have processes nativelyScripted demo using your own scenarios, not their script
    2Supports your industry’s specific requirementsAsk for a customer reference in your exact sector
    3Handles your transaction volumeAsk for the volume profile of their largest comparable customer
    4Supports your entity, currency and tax structureDemo a multi-entity or multi-currency transaction if relevant
    5Reporting meets your management and statutory needsAsk them to build one of your real reports live
    6Handles your edge cases without customisationBring your three most awkward real-world scenarios
    7Room to grow into planned future requirementsAsk what breaks at three times your current size
    8Standard functionality avoids the need for custom codeCount how often they answer “that can be customised”

    Category 2: Usability and adoption (criteria 9–14)

    #CriterionHow to verify it
    9Daily users find the interface tolerableHave actual end users score it, not just management
    10Common tasks take few clicksTime a routine order entry from start to finish
    11Mobile experience is genuinely usableTest on a real phone, not a tablet demo
    12Search and navigation are fast at real data volumesAsk about performance with a populated database
    13Learning curve is realistic for your workforceAsk referees how long staff took to become productive
    14Accessibility and language needs are metConfirm interface language and localisation coverage

    Category 3: Technical (criteria 15–20)

    #CriterionHow to verify it
    15Deployment model fits your constraintsConfirm cloud, on-premise or hybrid options and their limits
    16Upgrade process and frequency are acceptableAsk how much notice you get and whether you can defer
    17Sandbox and test environments are availableConfirm whether they are included or charged separately
    18Performance and uptime commitments are contractualAsk for the SLA document, not the marketing figure
    19Backup, recovery and continuity are definedAsk for the recovery time and recovery point objectives
    20Customisation survives upgradesAsk how extensions are handled when the core version changes

    Category 4: Integration (criteria 21–25)

    #CriterionHow to verify it
    21Native connectors exist for your key systemsGet the list; confirm each is supported, not merely possible
    22API is documented, stable and openly accessibleAsk to see the developer documentation before signing
    23API usage limits suit your volumeConfirm call limits and what exceeding them costs
    24Integration failures are visible and alertableAsk what happens when a sync fails silently
    25Data can be exported completely and in usable formatsAsk exactly what you get back if you leave

    Category 5: Vendor viability (criteria 26–30)

    #CriterionHow to verify it
    26Financially stable and likely to exist in ten yearsCheck ownership, funding and public filings where available
    27Active product development, not maintenance modeAsk for the release history and published roadmap
    28Meaningful customer base in your region and size bandAsk how many customers resemble you, specifically
    29Support model matches your operating hoursConfirm coverage hours, escalation path and response targets
    30User community and available skills in the marketSearch job listings for people with that system’s skills

    Category 6: Implementation partner (criteria 31–35)

    #CriterionHow to verify it
    31Proven experience at your size and in your industryAsk for three comparable references and call all three
    32Named consultants, not just a company logoAsk who specifically will work on your project
    33Methodology is documented and realisticAsk to see the project plan template and stage gates
    34Knowledge transfer is planned, not assumedConfirm how your team becomes self-sufficient
    35Post-go-live support is contractedConfirm hypercare duration, staffing and response times

    Category 7: Cost and commercials (criteria 36–38)

    #CriterionHow to verify it
    36Three-year total cost is quoted, not year-one licenceDemand a written quote covering all components
    37Renewal increases are capped in writingNegotiate this before signing; it is rarely offered
    38Exclusions are explicitly listedAsk what is not included, and get the answer in the contract

    Category 8: Compliance and risk (criteria 39–40)

    #CriterionHow to verify it
    39Security certifications and audit reports availableAsk for current SOC 2, ISO 27001 or regional equivalents
    40Data residency and privacy obligations satisfiedConfirm hosting jurisdiction and applicable data protection terms

    Turning Criteria Into a Decision

    Forty criteria scored equally produce mush. Weighting is what makes a scorecard useful.

    34. Assign a weight to each category totalling 100. A manufacturer might weight functional fit at 30 and integration at 15; a services firm might reverse that.

    35. Score each criterion 1 to 5 based on verified evidence, not on the vendor’s claim.

    36. Mark must-haves as pass or fail separately. A failed must-have eliminates the vendor regardless of total score. Do not let a strong overall number talk you out of a hard requirement.

    37. Have three or four people score independently, then discuss the divergences. The disagreements are where the real information is.

    38. Record the evidence behind each score. Six months later, when someone asks why you chose this system, you will want the reasoning written down.

    CategorySuggested weight rangeWeight higher when…
    Functional fit20–35Your processes are unusual or industry-specific
    Usability and adoption10–20You have many casual users or high staff turnover
    Technical10–15You have specific infrastructure or upgrade constraints
    Integration10–20You run several systems that must talk to each other
    Vendor viability5–15This is a long-term platform decision
    Implementation partner10–20Your internal project capacity is limited
    Cost10–20Budget is genuinely constrained
    Compliance and risk5–20You operate in a regulated sector

    Running Demos That Reveal Something

    A standard vendor demo is a rehearsed performance of the software’s best features. Replace it.

    Send scenarios in advance

    Give every finalist the same three or four scenarios drawn from your real business. Include at least one that is genuinely awkward — the rush order that changes after production has started, the customer with unusual pricing, the return that involves a partial credit and restocking.

    Insist on your data shape

    Not necessarily your live data, but data resembling yours: your item structure, your customer types, your document volumes. Demos on clean fictional data hide performance and usability problems.

    Put end users in the room

    The people who will use the system daily should score it. Management evaluates strategy; users evaluate whether Tuesday’s job is faster or slower. Both scores matter and they frequently disagree.

    Watch for these answers

    • “That can be customised.” Ask what it costs, who maintains it, and what happens at the next upgrade.

    • “That’s on the roadmap.” Treat roadmap functionality as absent. Buy what exists today.

    • “Our partner handles that.” Find out which partner, at what cost, and whether it is in the quote.

    • “Nobody has ever asked for that.” Either your requirement is unusual, or their customer base does not resemble you. Both are worth knowing.

    • A confident answer with no demonstration. Ask them to show it. Now.

    The single most revealing demo request“Show us what happens when something goes wrong — a mis-picked order, a returned batch, a posting made to the wrong period.”Vendors rehearse the happy path. How gracefully a system handles correction and reversal tells you far more about daily life with it.

    Reference Calls: The Highest-Value Hour

    Twenty minutes with a comparable customer is worth more than a day of demos, and most buyers skip it. Ask for references matching your size and industry, and be suspicious if none can be produced.

    • What took longer than you expected, and by how much?

    • What did you discover after go-live that you wish you had known during selection?

    • How much customisation did you end up doing, and would you do it again?

    • How responsive is support when something is genuinely broken, not just inconvenient?

    • What does your team complain about most?

    • If you were starting again, would you choose the same system and the same partner?

    The most useful question is the first one, because every project overruns somewhere and the answer reveals where this particular combination of software and partner tends to slip.

    Contract Terms Worth Arguing About

    • Renewal increase cap. Without one, introductory pricing ends and year two arrives with a number nobody budgeted.

    • User reclassification. Define what constitutes each user type in writing, so a light user does not become a full licence because of one task.

    • Scope definition and change control. What is included, what triggers a change request, and how change requests are priced.

    • Acceptance criteria. What conditions must be met before a phase is signed off and payment released.

    • Data ownership and exit. Format, completeness, timeframe and cost of getting your data back, plus retention period after termination.

    • Service levels with remedies. An uptime figure with no consequence attached is marketing, not a commitment.

    • Key personnel clause. The consultants you evaluated should be the consultants who work on your project.

    • Assignment on acquisition. What happens to your terms if the vendor is bought.

    Biases That Distort Selections

    BiasHow it shows upCounter
    Demo haloThe smoothest presentation winsScore against scripted scenarios only
    Brand comfortChoosing the famous name to avoid blameWeight fit and partner quality above brand
    Feature countingLongest feature list winsScore only must-haves and verified capabilities
    Sunk evaluationReluctance to eliminate a vendor after long effortApply must-have pass/fail before deep evaluation
    Anchoring on priceFirst quote frames everything after itCollect all quotes before comparing any
    Single-department captureFinance or operations decides aloneCross-functional scoring panel
    Roadmap optimismBuying the promised versionScore what exists today, at zero for the rest

    A Realistic Selection Timeline

    StageTypical durationOutput
    Requirements and process documentation3–6 weeksSigned-off requirements with must-haves marked
    Market scan and long list1–2 weeksSix to eight candidates
    Initial screening and pricing2–3 weeksThree finalists
    Scripted demos2–4 weeksScored scorecards from all panel members
    References and due diligence1–2 weeksVerified evidence behind the scores
    Negotiation and contracting2–6 weeksSigned agreement with defined scope

    Three to five months end to end is normal for a mid-market selection. Compressing it below that usually means skipping verification, which is exactly the work that prevents the expensive discovery later.

    Frequently Asked Questions

    How many vendors should I evaluate?

    Six to eight on the long list, three finalists for scripted demos. Fewer than three gives you no comparison; more than three exhausts your evaluation panel and produces shallower scoring across the board.

    Should I write a formal RFP?

    For larger or regulated organisations, usually yes — it creates a defensible audit trail. For smaller companies a structured requirements summary plus scripted demos achieves the same result with far less effort. What matters is that every vendor answers the same questions against the same scenarios.

    How long should ERP selection take?

    Three to five months for a mid-market selection, from requirements documentation to signed contract. Faster is possible when requirements are simple and decision rights are clear. Much faster usually means verification steps were skipped.

    Should I choose the software or the partner first?

    Together. The partner frequently determines the outcome more than the software does, so evaluate both in parallel and treat a weak partner as a reason to reconsider the software, not something to fix afterwards.

    What if two finalists score nearly identically?

    Break the tie on implementation partner quality and on reference-call findings, not on price. A small price difference is trivial compared with the cost of a difficult implementation.

    Is it worth hiring an independent selection consultant?

    It can be, particularly for complex or high-value decisions, because they bring comparison data you do not have. Verify that they are genuinely independent — that they take no vendor commissions — and agree their deliverables in writing before engaging.

    How much should we weight price?

    Enough to eliminate genuinely unaffordable options, rarely enough to decide between viable ones. The cost difference between finalists is usually smaller than the cost variance introduced by implementation quality and user adoption.

    Conclusion

    A good ERP selection is mostly an exercise in resisting persuasion. The forty criteria above exist to force verification: not what the vendor says the system does, but what you watched it do with your scenarios, and what a comparable customer told you happened afterwards.

    Document requirements with consequences attached, eliminate on failed must-haves before you fall in love with anything, weight the categories that matter for your business, put end users on the scoring panel, call every reference, and negotiate renewal terms before signing. The decision that emerges will be one you can still explain in two years.

  • Best ERP Software for Small Business: How to Choose Without Overspending

    Best ERP Software for Small Business: How to Choose Without Overspending

    Most articles about small business ERP are written by people selling ERP. This one starts from a less comfortable question: do you actually need it yet? A significant number of small businesses that buy ERP would have been better served by tidying up their accounting software and fixing two broken processes. A significant number of others waited three years too long and paid for it in stockouts, missed invoices and staff hired purely to move data between systems.

    This guide covers how to tell which group you are in, what small business ERP genuinely needs to do, how the money actually works, how to shortlist properly in about thirty days, and the mistakes that turn a sensible purchase into an expensive one.

    What “Small Business ERP” Actually Means

    The label is loose, and vendors stretch it. In practice, small business ERP describes systems designed for companies roughly between five and two hundred employees, with these characteristics:

    • Preconfigured defaults — a working chart of accounts, standard workflows and sensible permissions out of the box, so you configure rather than build.

    • Subscription pricing — monthly or annual per-user fees instead of a large capital purchase.

    • Fast deployment — weeks rather than quarters, assuming your data is reasonable.

    • Modular growth — start with finance and inventory, add manufacturing or projects later without changing platforms.

    • Low IT overhead — no servers to maintain, no database administrator required.

    What it does not mean is a cut-down toy. Several systems in this category run genuine multi-entity accounting, multi-currency, manufacturing and warehouse management. The difference from enterprise ERP is less about capability ceiling and more about how much configuration work stands between you and a working system.

    Do You Actually Need ERP Yet?

    This is the section vendors skip. Answer it honestly before you look at a single demo.

    Signs you have genuinely outgrown your current setup

    • Two departments regularly report different numbers for the same period, and reconciling them is somebody’s recurring job.

    • You cannot answer “how many of this item do we have right now” without someone physically checking.

    • Staff maintain private spreadsheets because the official system does not do what they need — and the business quietly depends on those spreadsheets.

    • Month-end close takes longer every quarter rather than shorter.

    • You are hiring administrative staff mainly to re-key data between systems.

    • Orders get promised that operations cannot fulfil, and the sales team has no way to know in advance.

    • You have added a second location, a second entity, a second currency, or a second sales channel and everything got harder.

    • You cannot produce a reliable gross margin by product or by customer without a manual exercise.

    Three or more of those and ERP will likely pay for itself. One or two and you may have a process problem wearing a software costume.

    When accounting software is still the right answer

    • You hold little or no physical inventory.

    • You have one location, one currency and one legal entity.

    • Your order volume is low enough that manual handling is not straining anyone.

    • Your existing tools work and the complaints are about habits, not capability.

    • You are growing, but the growth is linear and predictable.

    Modern cloud accounting platforms with a good inventory add-on cover a surprising amount of ground. If a well-configured accounting package plus one specialist tool solves your problem, that is a cheaper, faster and lower-risk answer than ERP, and choosing it is not a failure of ambition.

    The test that cuts through itWrite down the three problems costing you the most money right now, with a number attached to each.If ERP does not directly address at least two of them, you are buying software to feel organised rather than to solve something.

    Features That Actually Matter for a Small Business

    Feature lists are long and mostly irrelevant. These are the capabilities that determine whether the system works for a company your size.

    CapabilityWhy it matters at small scalePriority
    Core financialsGeneral ledger, AP, AR, bank reconciliation, tax handling for your jurisdictionEssential
    Inventory managementReal-time stock by location, reorder points, batch or serial tracking if you need itEssential if you hold stock
    Order managementQuotes to sales orders to fulfilment to invoice, without re-entryEssential
    PurchasingRequisitions, purchase orders, receiving, three-way matching against invoicesHigh
    ReportingDashboards and drill-down without needing a consultant to build each reportHigh
    Multi-channel supportNative connectors to your e-commerce and marketplace channelsHigh for retail
    Bank feeds and paymentsAutomatic bank imports and payment file generationHigh
    Multi-currencyOnly if you buy or sell abroad — otherwise ignore itSituational
    ManufacturingBills of materials, work orders, production costingSituational
    Project accountingTimesheets, project budgets, work-in-progress, milestone billingSituational
    Mobile accessWarehouse scanning, approvals and field data entryMedium
    User permissionsRole-based access so a small team can still enforce separation of dutiesMedium

    Features small businesses overpay for

    • Advanced demand forecasting when you have neither the data history nor the volume for it to be meaningful.

    • Complex approval hierarchies in a company where four people approve everything anyway.

    • Enterprise consolidation for a single legal entity.

    • Heavy customisation of processes you have not yet stabilised.

    • Modules bought “for later” — you can add them later, and later you will know what you actually need.

    Deployment: Cloud Is Almost Always the Answer Here

    For a small business the deployment debate is largely settled. Cloud ERP removes server purchase, patching, backup management and disaster recovery — all of which are disproportionately expensive when spread across a small headcount. It also gives you remote and mobile access without configuring a VPN.

    The genuine exceptions are narrow: unreliable internet at a site that cannot stop working, a regulatory requirement about where data physically resides, or existing recent hardware plus IT staff you already employ. “We would rather own our data” is a preference, not a business case, and it should be tested against what acting on it costs.

    The one cloud trade-off worth planning for is upgrade timing. Your vendor decides when the version changes. Confirm how much notice you get, whether you can test in a sandbox first, and what happens if an update breaks a workflow you depend on.

    How the Money Actually Works

    The subscription is the visible cost and rarely the largest one in year one. Budget for all of these:

    Cost lineTypical treatment for a small business
    SubscriptionPer user per month, often with different rates for full and limited users
    ImplementationFrequently equals or exceeds the first-year subscription
    Data migrationPriced partly on how messy your source data is
    IntegrationsEach connector to e-commerce, banking or shipping is usually separate
    TrainingThe line most often cut, and the one that most determines success
    Internal staff timeReal money, almost never costed, usually the biggest hidden item
    Ongoing adminSomebody internally must own the system afterwards

    A workable planning assumption for a straightforward small business deployment: budget roughly two to three times the first-year subscription for total first-year cost. If a partner quotes implementation at a tiny fraction of the licence cost, ask precisely what has been excluded — it is usually data migration, integrations, or training.

    Where small businesses can genuinely save

    • Match user types carefully. Many staff need only limited access — inquiry, time entry, approvals — which costs far less on most platforms.

    • Phase the rollout. Finance and inventory first. Add manufacturing or projects once the core is stable.

    • Clean your data before quoting, not after signing. Migration cost drops when the source is tidy.

    • Use standard functionality. Every customisation is paid for twice: once to build, then forever to maintain.

    • Negotiate multi-year terms with a capped renewal increase. Introductory pricing ending is a common unpleasant surprise in year two.

    • Buy sandbox access if it is optional. It sounds like a saving to skip. It is not.

    The Main Options, Honestly Described

    A map of the landscape rather than a ranking, because the right answer depends entirely on your industry and complexity. Verify current features and pricing directly with each vendor — this market changes constantly.

    SystemGenuine strengthHonest limitation
    OdooModular, broad functional coverage, strong price-to-capability ratioSome modules are shallower than they appear in demos; often needs partner work
    ERPNextOpen source, no licence fee, capable coreRequires technical capability or a paid partner; smaller ecosystem
    Microsoft Dynamics 365 Business CentralDeep financials, strong fit if you already run Microsoft 365Partner-led pricing varies widely; costs rise with add-ons
    Oracle NetSuiteMature multi-entity and multi-currency, scales well as you growPriced and scoped toward mid-market; can be heavy for very small firms
    AcumaticaResource-based licensing suits many occasional usersFewer implementation partners in some regions
    Zoho suiteVery low entry cost, wide app ecosystemDepth in manufacturing and complex inventory is limited
    Sage IntacctStrong core accounting and reportingOperational and manufacturing coverage often needs third-party add-ons
    SAP Business OneSolid SME manufacturing and distribution functionalityInterface feels dated to some users; partner quality varies significantly

    The open-source question

    Free to licence is not free to run. Open-source ERP genuinely removes the subscription line, which matters. It replaces it with hosting costs, an implementation partner or internal technical capability, and responsibility for upgrades and security patching. For a business with in-house technical skill and modest requirements, it is a legitimate and sometimes excellent choice. For a business with no technical staff, the total cost frequently lands close to a commercial subscription, with more risk attached.

    Which System Suits Which Kind of Small Business

    Business typeWhat to prioritise in evaluation
    E-commerce and retailNative marketplace and storefront connectors, real-time stock sync, returns handling, landed-cost tracking
    Wholesale and distributionWarehouse management, pricing tiers and customer-specific pricing, backorder handling, batch or lot tracking
    Light manufacturingBills of materials, work orders, production costing, material requirements planning, scrap tracking
    Professional servicesProject accounting, timesheets, work-in-progress, milestone and retainer billing, utilisation reporting
    Construction and tradesJob costing, progress billing, subcontractor management, retention handling, equipment tracking
    Food and beverageLot traceability, expiry and shelf-life management, catch-weight handling, recall reporting

    How to Shortlist in 30 Days

    Week 1 — Define the problem

    1. Write down your top five requirements as measurable outcomes. “Cut month-end close from 15 days to 5” is testable. “Improve efficiency” is not.

    2. Document how your key processes actually run today, including the workarounds people use. Interview the staff doing the work, not just their managers.

    3. Separate must-have from nice-to-have, honestly. Everything on the must-have list should have a consequence attached if it is missing.

    4. Agree a realistic budget range internally before you speak to vendors, and agree who signs off.

    Week 2 — Build the shortlist

    5. Identify five to seven candidates that serve your size and your industry, not just the most advertised names.

    6. Send each the same one-page requirements summary and ask for indicative pricing for your user count.

    7. Eliminate anything that cannot meet a genuine must-have. Do not let a strong demo talk you out of a hard requirement.

    8. Narrow to three for serious evaluation.

    Week 3 — Scripted demos

    9. Send each finalist the same three scenarios drawn from your real business, including the awkward edge cases.

    10. Insist they demo those scenarios, using sample data resembling yours — not their polished standard script.

    11. Have the people who will use the system daily attend and score it, not only management.

    12. Note every time a vendor answers “that can be customised”. Ask what it costs and who maintains it.

    Week 4 — Verify and decide

    13. Ask each finalist for two references of similar size in your industry, and actually call them.

    14. Ask referees what went wrong, not what went well. The useful information is in the answer to the first question.

    15. Get a written quote covering three years including implementation, migration, integrations, training and expected renewal increases.

    16. Evaluate the implementation partner as carefully as the software. The partner usually determines the outcome.

    Reference call questions that get honest answersWhat took longer than you expected, and by how much?What did you discover after go-live that you wish you had known during selection?How responsive is support when something is genuinely broken?If you were starting again, what would you do differently — and would you choose the same system?

    Implementation on a Small Budget

    Small businesses cannot absorb a failed implementation, so the discipline matters more, not less.

    • Name one internal owner with authority to make decisions. Committees stall small projects fastest.

    • Clean data before migration. Duplicate customers and wrong item codes become permanent once they are inside a system everyone trusts.

    • Migrate master data and opening balances only. Archive transaction history and keep the old system readable for reference.

    • Test end to end with real staff and real scenarios before go-live, not after.

    • Go live in a quiet period. Never your busiest month, never immediately before a statutory deadline.

    • Plan for a productivity dip of two to six weeks. It is normal, it is temporary, and pretending it will not happen is how projects get labelled failures.

    • Protect training when the schedule slips. Cutting training to save the date is the most expensive saving available.

    Mistakes That Cost Small Businesses the Most

    17. Buying on demo quality. The best-demoing product is often the one with the best sales engineer, not the best fit.

    18. Choosing the cheapest implementation quote. Low quotes are usually narrow quotes, and the difference reappears as change requests.

    19. Customising before stabilising. Run standard for a few months. Half the customisations you thought you needed turn out to be habits.

    20. Skipping the reference calls. Twenty minutes on the phone with a comparable company is the highest-value hour in the whole process.

    21. Letting one department choose. If finance selects it alone, operations will work around it — and vice versa.

    22. Underestimating internal time. Assigning your best people on top of their existing full-time jobs produces a system designed by exhausted people.

    23. Ignoring the exit terms. Check how you get your data out, in what format, and at what cost, before you sign rather than when you want to leave.

    Calculating Whether It Pays

    Small business ROI cases are usually stronger than owners expect, because the biggest benefit is rarely cost cutting — it is growth absorbed without adding administrative headcount.

    • Admin hours recovered — hours per week of re-keying and reconciliation, times loaded salary cost.

    • Inventory reduction — better visibility usually allows lower stock at the same service level. That is cash released immediately.

    • Faster close — days saved each month converted into finance capacity.

    • Errors avoided — cost of wrong shipments, credit notes and expedited freight.

    • Software consolidated — subscriptions retired when the ERP replaces point tools.

    • Headcount avoided — the next administrator you do not need to hire is usually the single largest line.

    Use the low end of every estimate. A business case that survives pessimistic assumptions is one you can still defend eighteen months later when someone asks whether it worked.

    Frequently Asked Questions

    What is the best ERP for a small business?

    There is no single best system, and any article that names one is usually selling it. The right choice depends on whether you hold inventory, whether you manufacture, how many entities and currencies you operate, your industry’s compliance requirements and your internal technical capability. Shortlist on fit with those factors, then decide on total cost and partner quality.

    How much does ERP cost for a small business?

    Costs vary widely by user count, modules and deployment, so a single figure would mislead. A more reliable planning approach is the ratio: assume total first-year cost of roughly two to three times the first-year subscription once implementation, migration, integration and training are included, and build a five-year model from current vendor quotes.

    Can a business with ten employees use ERP?

    Yes. Cloud subscription pricing has brought entry costs down substantially, and plenty of ten-person companies run ERP successfully. The realistic constraint is not the subscription but the internal time required to implement it properly, which is harder to find in a small team.

    Is open-source ERP a good idea for a small business?

    It can be, if you have technical capability in-house or a reliable partner. You remove the licence fee and take on hosting, upgrades and security patching. Without technical capability the total cost often lands close to a commercial subscription, with more risk. Judge it on total cost and support availability, not on the absence of a licence fee.

    How long does implementation take for a small business?

    Six to twelve weeks is realistic for a straightforward cloud deployment with clean data and standard processes. Add time for manufacturing, multiple entities, non-trivial integrations, or poor data quality — which is the most common cause of overrun at this size.

    Should I move from accounting software to ERP?

    Move when the accounting software has stopped being the constraint and your operations have. If your problems are stock accuracy, order promising, production costing or reconciling departments, ERP addresses those. If your problems are bookkeeping habits, better use of your existing tool is cheaper and faster.

    Do I need a consultant?

    For simple cloud deployments with modest requirements, some small businesses self-implement successfully. Anything involving manufacturing, multiple entities or real integrations is difficult to do well without help, and configuration mistakes are expensive to unwind later. A short paid discovery engagement is often worth it even if you implement the rest yourself.

    What happens if we outgrow the system?

    Ask each vendor directly what their largest customers look like and where the platform starts to strain. Also check the exit terms — data export format, retention period and any charges. A system you can leave cleanly is worth more than one you are locked into, however good the initial price.

    Conclusion

    The best ERP for a small business is the one that solves your two most expensive problems, that your staff will actually use, and that you can implement without exhausting the people who run the company. That is a much narrower target than the feature comparisons suggest.

    Define the problem with numbers attached, shortlist on genuine fit rather than demo polish, call the references, model three years of cost rather than one, and choose the implementation partner as carefully as the software. Do that and the decision is usually clearer than it looks at the start.