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.
| Type | What it means | What the ERP must handle well |
| Discrete | Countable, assembled products — machinery, electronics, furniture | Multi-level BOMs, routings, serial tracking, work orders |
| Process | Formulations and recipes — food, chemicals, pharmaceuticals, cosmetics | Recipes with variable yields, batch tracking, potency, co-products and by-products, units of measure conversion |
| Make-to-stock | Produced to forecast and held in inventory | Demand forecasting, safety stock, master production scheduling |
| Make-to-order | Production starts when an order arrives | Order-linked work orders, promise dates, available-to-promise logic |
| Engineer-to-order | Each order requires design work first | Project accounting, engineering change control, quoting from partial BOMs |
| Repetitive | High-volume, continuous line production | Rate-based scheduling, backflushing, minimal transaction overhead |
| Mixed mode | Several of the above in one plant | Ability 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:
| Method | How it works | Suits |
| Standard costing | Predetermined cost per item; variances analysed against actuals | Stable, repetitive production |
| Actual costing | Real material, labour and overhead captured per work order | Variable or custom production |
| Average costing | Weighted average across receipts | Commodity-like items with fluctuating prices |
| Job costing | Costs accumulated per job or project | Make-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
| Sector | Requirements that commonly drive the selection |
| Food and beverage | Lot traceability, shelf life and expiry, allergen management, catch weight, recall simulation, quality holds |
| Pharmaceutical and life sciences | Validation documentation, electronic records and signatures, batch genealogy, deviation management, full audit trails |
| Automotive | EDI with customers, release schedules, container and label standards, supplier quality requirements, serial traceability |
| Aerospace and defence | Certification and airworthiness records, full component genealogy, engineering change control, export-control handling |
| Electronics | Component substitution and approved vendor lists, serial and firmware tracking, rapid engineering change cycles |
| Metal fabrication | Nesting 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:
| Metric | What ERP should improve |
| On-time delivery | Better promising and realistic scheduling |
| Inventory turns | Less material held because visibility improved |
| Inventory accuracy | Transaction discipline and cycle counting |
| Schedule adherence | Achievable plans that the floor believes |
| Scrap and rework rate | Earlier detection through quality integration |
| Quote-to-order cycle time | Faster costing and availability checks |
| Month-end close duration | WIP and consumption posted as they happen |
| Traceability query time | From 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 field | Value |
| Focus keyword | ERP selection criteria |
| Secondary keywords | ERP evaluation checklist, how to choose ERP software, ERP RFP, ERP vendor comparison, ERP scorecard |
| Search intent | Commercial investigation — buyers running a structured evaluation |
| SEO title (meta title) | ERP Selection Criteria: A 40-Point Checklist for Buyers |
| Meta description | A complete ERP selection checklist: 40 evaluation criteria across eight categories, a weighted scorecard method, demo scripts and contract red flags. |
| URL slug | erpdetail.com/erp-selection-criteria |
| Approx. word count | Approx. 3,700 |
| Suggested internal links | Link to: what is ERP, ERP software cost, ERP implementation, why ERP projects fail, cloud ERP vs on-premise |
| Suggested image alt text | ERP 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)
| # | Criterion | How to verify it |
| 1 | Covers your must-have processes natively | Scripted demo using your own scenarios, not their script |
| 2 | Supports your industry’s specific requirements | Ask for a customer reference in your exact sector |
| 3 | Handles your transaction volume | Ask for the volume profile of their largest comparable customer |
| 4 | Supports your entity, currency and tax structure | Demo a multi-entity or multi-currency transaction if relevant |
| 5 | Reporting meets your management and statutory needs | Ask them to build one of your real reports live |
| 6 | Handles your edge cases without customisation | Bring your three most awkward real-world scenarios |
| 7 | Room to grow into planned future requirements | Ask what breaks at three times your current size |
| 8 | Standard functionality avoids the need for custom code | Count how often they answer “that can be customised” |
Category 2: Usability and adoption (criteria 9–14)
| # | Criterion | How to verify it |
| 9 | Daily users find the interface tolerable | Have actual end users score it, not just management |
| 10 | Common tasks take few clicks | Time a routine order entry from start to finish |
| 11 | Mobile experience is genuinely usable | Test on a real phone, not a tablet demo |
| 12 | Search and navigation are fast at real data volumes | Ask about performance with a populated database |
| 13 | Learning curve is realistic for your workforce | Ask referees how long staff took to become productive |
| 14 | Accessibility and language needs are met | Confirm interface language and localisation coverage |
Category 3: Technical (criteria 15–20)
| # | Criterion | How to verify it |
| 15 | Deployment model fits your constraints | Confirm cloud, on-premise or hybrid options and their limits |
| 16 | Upgrade process and frequency are acceptable | Ask how much notice you get and whether you can defer |
| 17 | Sandbox and test environments are available | Confirm whether they are included or charged separately |
| 18 | Performance and uptime commitments are contractual | Ask for the SLA document, not the marketing figure |
| 19 | Backup, recovery and continuity are defined | Ask for the recovery time and recovery point objectives |
| 20 | Customisation survives upgrades | Ask how extensions are handled when the core version changes |
Category 4: Integration (criteria 21–25)
| # | Criterion | How to verify it |
| 21 | Native connectors exist for your key systems | Get the list; confirm each is supported, not merely possible |
| 22 | API is documented, stable and openly accessible | Ask to see the developer documentation before signing |
| 23 | API usage limits suit your volume | Confirm call limits and what exceeding them costs |
| 24 | Integration failures are visible and alertable | Ask what happens when a sync fails silently |
| 25 | Data can be exported completely and in usable formats | Ask exactly what you get back if you leave |
Category 5: Vendor viability (criteria 26–30)
| # | Criterion | How to verify it |
| 26 | Financially stable and likely to exist in ten years | Check ownership, funding and public filings where available |
| 27 | Active product development, not maintenance mode | Ask for the release history and published roadmap |
| 28 | Meaningful customer base in your region and size band | Ask how many customers resemble you, specifically |
| 29 | Support model matches your operating hours | Confirm coverage hours, escalation path and response targets |
| 30 | User community and available skills in the market | Search job listings for people with that system’s skills |
Category 6: Implementation partner (criteria 31–35)
| # | Criterion | How to verify it |
| 31 | Proven experience at your size and in your industry | Ask for three comparable references and call all three |
| 32 | Named consultants, not just a company logo | Ask who specifically will work on your project |
| 33 | Methodology is documented and realistic | Ask to see the project plan template and stage gates |
| 34 | Knowledge transfer is planned, not assumed | Confirm how your team becomes self-sufficient |
| 35 | Post-go-live support is contracted | Confirm hypercare duration, staffing and response times |
Category 7: Cost and commercials (criteria 36–38)
| # | Criterion | How to verify it |
| 36 | Three-year total cost is quoted, not year-one licence | Demand a written quote covering all components |
| 37 | Renewal increases are capped in writing | Negotiate this before signing; it is rarely offered |
| 38 | Exclusions are explicitly listed | Ask what is not included, and get the answer in the contract |
Category 8: Compliance and risk (criteria 39–40)
| # | Criterion | How to verify it |
| 39 | Security certifications and audit reports available | Ask for current SOC 2, ISO 27001 or regional equivalents |
| 40 | Data residency and privacy obligations satisfied | Confirm 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.
| Category | Suggested weight range | Weight higher when… |
| Functional fit | 20–35 | Your processes are unusual or industry-specific |
| Usability and adoption | 10–20 | You have many casual users or high staff turnover |
| Technical | 10–15 | You have specific infrastructure or upgrade constraints |
| Integration | 10–20 | You run several systems that must talk to each other |
| Vendor viability | 5–15 | This is a long-term platform decision |
| Implementation partner | 10–20 | Your internal project capacity is limited |
| Cost | 10–20 | Budget is genuinely constrained |
| Compliance and risk | 5–20 | You 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
| Bias | How it shows up | Counter |
| Demo halo | The smoothest presentation wins | Score against scripted scenarios only |
| Brand comfort | Choosing the famous name to avoid blame | Weight fit and partner quality above brand |
| Feature counting | Longest feature list wins | Score only must-haves and verified capabilities |
| Sunk evaluation | Reluctance to eliminate a vendor after long effort | Apply must-have pass/fail before deep evaluation |
| Anchoring on price | First quote frames everything after it | Collect all quotes before comparing any |
| Single-department capture | Finance or operations decides alone | Cross-functional scoring panel |
| Roadmap optimism | Buying the promised version | Score what exists today, at zero for the rest |
A Realistic Selection Timeline
| Stage | Typical duration | Output |
| Requirements and process documentation | 3–6 weeks | Signed-off requirements with must-haves marked |
| Market scan and long list | 1–2 weeks | Six to eight candidates |
| Initial screening and pricing | 2–3 weeks | Three finalists |
| Scripted demos | 2–4 weeks | Scored scorecards from all panel members |
| References and due diligence | 1–2 weeks | Verified evidence behind the scores |
| Negotiation and contracting | 2–6 weeks | Signed 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.
Leave a Reply