ERP Assessment: Framework, Scorecard & Report Guide
How to run an ERP assessment on the system you already have — a weighted health scorecard, a replace-versus-optimize decision framework, and the report it should produce.
ERP Assessment vs ERP Selection: The Distinction That Matters
These two exercises get conflated constantly, and conflating them is expensive. They have different inputs, different participants, different outputs and different failure modes.
| ERP assessment | ERP selection | |
|---|---|---|
| Core question | Is the system we already run still fit for purpose? | Which new system should we buy? |
| Subject | Your incumbent platform, configuration, data and processes | The vendor market |
| Primary input | Internal evidence — process observation, ticket logs, user surveys, run-cost data | Requirements document, vendor RFP responses, scripted demos |
| Who runs it | Internal process owners plus, often, an independent advisor | A cross-functional selection team, usually with procurement |
| Typical duration | 3–8 weeks | 2–6 months |
| Output | Health scores, root-cause findings, an optimize-or-replace recommendation | A ranked shortlist, a preferred vendor, a signed contract |
| Main failure mode | Confirmation bias — assessing to justify a decision already taken | Being led by demos instead of requirements |
| Cost of skipping it | You buy a new system to fix a problem the new system does not fix | You buy the wrong system |
An assessment is the gate in front of a selection. Run it first; run the selection only if the assessment says replacement is warranted.
If your assessment does conclude "replace", the selection work starts from a different set of resources on this site rather than from this page:
- The end-to-end ERP evaluation and selection guide walks the full selection process from long list to contract.
- ERP selection criteria supplies the weighted scoring model and MoSCoW prioritization for comparing new vendors.
- ERP software selection mistakes covers the traps that derail selection projects once they are underway.
Everything below assumes you are still at the earlier question: is the incumbent worth keeping?
Trigger Points: Signals That Warrant an ERP Assessment
Assessments get commissioned reactively, usually after something breaks. The better trigger points are structural, and most organizations pass several of them before anyone raises the question.
Operational signals
- Core processes run outside the ERP in shadow spreadsheets and standalone databases — the clearest evidence the system stopped fitting, and the volume is measurable.
- Month-end close is lengthening rather than shortening year over year.
- Users log in only to extract data into something else, or avoid the system where they can.
- Reporting requests route through IT because business users cannot self-serve.
Technical signals
- The system is on, or approaching, end of mainstream support, or the vendor has moved active development to a successor product.
- Integrations are point-to-point, undocumented and maintained by one or two people.
- Customizations block upgrades, so the platform is several versions behind.
- Data-quality problems recur despite repeated clean-ups — a structural rather than a hygiene issue.
Strategic signals
- A merger, acquisition, divestiture or new operating country the system cannot absorb without heavy cost.
- A change in business model — direct-to-consumer, servitization, subscription revenue — the data model was never designed for.
- Run costs rising while functional coverage stays flat, or reporting obligations the system cannot meet.
Deployment model is its own trigger worth weighing carefully, because a large share of the installed base is still not on cloud and vendor roadmaps increasingly assume it will be.
Source: ERP Research Benchmark — 8,737 tracked implementations analysed. View the data →
That figure is why deployment model belongs in an assessment rather than being assumed. A stable, well-run on-premise system with years of support left is not automatically a replacement candidate. A system whose vendor has ended new development for the on-premise line is a different matter, and the assessment should distinguish the two.
The Weighted ERP Assessment Scorecard
The scorecard below applies the same weighted-scoring discipline used in ERP selection criteria, but points it at the system you already own rather than at a market of candidates. Six dimensions, each weighted, each scored 1–5.
Weight the dimensions before you score anything. Deciding that process fit matters more than run cost after seeing the scores is how assessments get quietly reverse-engineered toward a predetermined answer.
| Dimension | Weight | What you are scoring | Evidence to gather |
|---|---|---|---|
| Process fit | 30% | Whether core end-to-end processes run in the system as designed, without workarounds | Process walkthroughs, count of spreadsheets and shadow systems, exception volumes |
| Integration & data flow | 20% | Whether data moves cleanly between the ERP and surrounding systems, and whether there is one trusted version of it | Integration inventory, duplicate-record rates, reconciliation effort, master-data ownership |
| User adoption | 15% | Whether the people who are supposed to use it actually do, and can | Active-user rates by module, support ticket themes, user survey, training coverage |
| Total cost of ownership | 15% | What the system costs to run per year against the value it delivers | Licenses, hosting, support contract, internal FTE, customization maintenance, upgrade costs |
| Strategic fit | 10% | Whether the system can support the business the company intends to be in three to five years | Growth plan, M&A pipeline, new markets, new business models, reporting obligations |
| Vendor & roadmap health | 10% | Whether the vendor is investing in this product line and will still support it | Support status, published roadmap, version currency, partner availability in your region |
Scoring Scale
| Score | Label | Definition |
|---|---|---|
| 5 | Strong | Fully fit; no material gap; no remediation needed |
| 4 | Adequate | Minor gaps, addressable through configuration or process change |
| 3 | Strained | Real gaps causing measurable friction; remediation is a project, not a task |
| 2 | Weak | Significant deficiency; workarounds are now embedded in daily operations |
| 1 | Failing | The dimension is not being met; business risk is active today |
Interpreting the Composite Score
Multiply each dimension score by its weight and sum the result to get a composite out of 5. Then apply two rules that stop a single strong dimension from masking a fatal one:
- Any dimension scoring 1 is a standalone finding. A composite of 3.8 with a failing integration layer is not a healthy system; it is a healthy system with an active risk that needs its own remediation plan regardless of the headline number.
- Score each dimension independently before discussing. Where two assessors differ by two points or more, reconcile explicitly and record the reasoning. Those disagreements are usually where the most useful findings hide.
As a rough reading: 4.0 and above points to optimization, 3.0–3.9 to targeted remediation with a re-assessment in twelve months, 2.0–2.9 to a serious replacement business case, and below 2.0 to replacement with urgency.
Build your ERP requirements list
Use our requirements wizard to define what you need from an ERP system — then compare vendors based on your criteria.
Rip-and-Replace vs Optimize: The Decision Framework
A composite score tells you the system's condition. It does not by itself tell you what to do, because the right action also depends on why the system scores badly and on what the organization can realistically absorb.
The single most useful question in the whole assessment is this: is the root cause in the software, or in how the software is being used? Software root causes — a data model that cannot represent your business, a module that does not exist, a vendor that has stopped developing the product — are not fixable by any amount of internal effort. Usage root causes — poor configuration, undocumented processes, skipped training, unowned master data — travel with you to a new system if you do not fix them first.
| Outcome | When it applies | Typical action | Typical elapsed time |
|---|---|---|---|
| Optimize | Composite 4.0+, or lower scores traced to configuration, process or training rather than software capability | Reconfiguration, process redesign, data remediation, targeted retraining, retiring shadow systems | 3–9 months |
| Extend | Core platform is sound but one or two capability gaps are real | Add a module, replace a bolt-on, or integrate a best-of-breed system for the gap | 3–6 months |
| Re-implement | The software fits but the original implementation does not — heavy customization, wrong chart of accounts, obsolete configuration | Re-implement the same product cleanly, moving customization into configuration | 6–15 months |
| Replace | Capability, data-model or vendor-roadmap failures the incumbent cannot resolve | Full selection process, then implementation | 12–30 months end to end |
Two failure modes account for most of the wrong calls. Replacing when you should optimize is the more common and more expensive error, because it converts a fixable internal problem into a multi-year capital project; the tell is a bad process-fit score whose supporting notes are full of "was never configured for" and "nobody owns". Optimizing when you should replace is rarer but compounds — each year of remediation on a platform that fundamentally cannot support the business is money that does not shorten the eventual project, and the tell is repeated cycles that improve the score by fractions then decay back within a year.
Before committing to replacement, price the alternative honestly. Our ERP implementation cost breakdown sets out what replacement costs across licensing, services, data migration, integration and change management, and the ERP TCO calculator models the five-year run cost of a new system against what you spend on the incumbent today.
Pricing the replacement option
Inside an ERP Assessment Report
The deliverable is where most assessments underperform. A slide deck of red-amber-green traffic lights is not a report; it is a summary of a report that was never written. A usable ERP assessment report is a standalone document that someone who was not in the workshops can read, understand and act on twelve months later.
A complete report contains ten sections.
- Executive summary — One page: composite score, recommendation (optimize, extend, re-implement or replace), the three findings that drove it, and the decision being asked for. Written last, read first, often the only part the board reads.
- Scope and method — Which entities, sites, processes and modules were in scope, who was interviewed, what data was pulled and over what period. This is what makes the conclusion defensible when it is challenged.
- Current-state architecture — A diagram and inventory of the ERP, its modules, every integration, every satellite system and every significant shadow system. The shadow-system inventory alone is frequently the most persuasive artifact in the document.
- Dimension-by-dimension scores — Each of the six dimensions with its score, the weight applied, and the evidence behind it. A score without evidence is an opinion.
- Root-cause analysis — For each weak dimension, whether the cause sits in the software, the configuration, the process or the people. This section separates an assessment from an audit.
- Risk register — Active risks with likelihood, business impact and current mitigation: support expiry dates, single points of failure in integration knowledge, compliance exposures.
- Cost baseline — What the incumbent costs to run today, fully loaded: licenses, hosting, support, internal headcount, customization maintenance and the cost of the workarounds. Almost no organization has this number beforehand, and almost every subsequent decision depends on it.
- Options appraisal — Each viable option costed and assessed for risk, benefit and elapsed time, including doing nothing. Doing nothing is a real option with a real cost and should be priced rather than dismissed.
- Recommendation and roadmap — The chosen option, sequenced into phases with dependencies, owners and decision points.
- Appendices — Interview notes, survey results, the scoring worksheet, the integration inventory and the data-quality analysis. These are what make the report auditable.
A report that stops at section 4 tells you the system is unwell. Sections 5 to 8 tell you what to do about it, and they are the sections most commonly missing.
Running the Assessment: A Seven-Stage Approach
- Frame the question and lock the scope. Agree in writing what is in scope, what decision the assessment feeds, and — importantly — that replacement is not a foregone conclusion. Assessments commissioned to justify a decision already taken produce reports nobody trusts.
- Weight the dimensions. Set the six weights with the sponsor before any evidence is gathered. Adjust the defaults above to reflect your context; a business mid-acquisition should weight strategic fit higher than 10%.
- Gather evidence, not opinion. Process walkthroughs, active-user data by module, support-ticket categorization, integration inventory, run-cost data, and a structured user survey. Interviews matter, but they calibrate the data rather than replace it.
- Map the current state. Document the architecture, every integration and every shadow system. Counting the workarounds is the fastest route to an honest process-fit score.
- Score independently, then reconcile. Each assessor scores each dimension alone. Reconcile gaps of two points or more in a structured session and record the reasoning against the score.
- Diagnose root causes. For every weak dimension, classify the cause as software, configuration, process or people. This classification drives the optimize-versus-replace call more directly than the composite score does.
- Cost the options and recommend. Price optimization, extension, re-implementation, replacement and doing nothing. Recommend one, sequence it, and name the owner and the decision date for each phase.
Whether you run this internally or bring in help depends less on capability than on independence — an assessment run by the team that owns the incumbent, or by a firm that also sells the replacement, carries an obvious conflict. Our guide to ERP consultants and advisory firms covers how to engage independent help.
If the recommendation is replacement, the next step is a requirements document rather than a vendor demo. Start from the ERP requirements guide and the requirements gathering process, using the root-cause findings as direct input — every problem classified as "process" or "people" needs an owner in the new program, not a hope that new software absorbs it.
Turn assessment findings into a requirements document
Frequently Asked Questions
What does an ERP assessment actually measure?
It measures six dimensions of the system you already run: process fit, integration and data flow, user adoption, total cost of ownership, strategic fit, and vendor and roadmap health. Each is scored 1–5 against documented evidence and weighted to produce a single composite score, alongside a root-cause analysis explaining whether weak scores stem from the software itself or from how it is configured and used.
How is an ERP assessment different from ERP selection?
An assessment evaluates the system you already have and answers "should we keep it?". A selection evaluates the market and answers "which one should we buy?". The assessment is the gate in front of the selection — you run a selection only if the assessment concludes that the incumbent cannot be made fit. Skipping the assessment is how companies buy new systems to fix problems that a new system does not fix.
When should you run an ERP assessment?
Run one when core processes have migrated into spreadsheets, when month-end close is lengthening, when the system is approaching end of support or has fallen several versions behind, when a merger or new market exposes a capability gap, or when run costs rise while functional coverage stays flat. It should also precede any budget request for replacement, so the business case rests on evidence rather than frustration.
How much does an ERP assessment cost?
An internally run assessment costs mainly in people's time — typically 20 to 40 person-days for a mid-sized single-entity business, more for multi-entity or multi-site organizations. Bringing in independent advisors typically adds a fixed-fee engagement scaled to scope and entity count. Either way it is a small fraction of a replacement program, which is the point: the assessment exists to avoid committing to that spend unnecessarily.
How long does an ERP assessment take?
Three to eight weeks for most mid-market organizations, assuming the evidence-gathering stage is properly resourced. Single-entity businesses with a small module footprint can complete one in three to four weeks. Multi-entity or multi-country groups typically need eight to twelve, largely because the current-state architecture and integration inventory take longer to establish across sites.
How often should you reassess your ERP?
A light annual review of the six dimension scores, and a full assessment every three years or whenever a structural trigger occurs — a major acquisition, a change in business model, a vendor end-of-support announcement, or a version falling out of mainstream support. Tracking the scores over time is more informative than any single reading, because the trend shows whether remediation is working or the system is decaying.
What is an ERP readiness score?
A readiness score measures whether your organization is prepared to run an ERP project successfully — covering executive sponsorship, budget, internal team capacity, data quality and appetite for change. It is distinct from the health score of the incumbent system. A business can have a failing system and still be unready to replace it, in which case building readiness comes before starting a selection. Our free ERP readiness assessment tool scores both dimensions in about two minutes.
What does an ERP assessment report include?
A complete report has ten sections: executive summary, scope and method, current-state architecture, dimension-by-dimension scores with supporting evidence, root-cause analysis, risk register, fully loaded cost baseline for the incumbent, options appraisal including the do-nothing option, the recommendation with a phased roadmap, and appendices containing the raw evidence. Reports that stop at the scores tell you the system is unwell without telling you what to do.
Can you run an ERP assessment internally, or do you need a consultant?
You can run one internally if you have people who understand the processes and are willing to record uncomfortable findings. The risk is independence: a team that owns the incumbent system rarely scores it harshly. The equal and opposite risk is engaging an adviser who also implements the replacement they recommend. Whichever route you take, insist that every score is backed by named evidence, which is what makes the conclusion defensible.
Does a low assessment score always mean replacing the ERP?
No. A low score identifies a problem; the root-cause analysis identifies whether the software caused it. Poor configuration, undocumented processes, skipped training and unowned master data all produce low scores and all survive a migration to a new platform. Only capability gaps, data-model limitations and vendor-roadmap failures genuinely require replacement — the rest are cheaper and faster to fix in place.
Related Resources
- ERP Selection Criteria — weighted scoring model for evaluating new vendors, once replacement is confirmed
- ERP Evaluation & Selection Guide — the full selection process from long list to signed contract
- ERP Software Selection Mistakes — the traps that derail selection projects
- ERP Requirements Guide — define what the business needs before evaluating anything
- ERP Implementation Cost Breakdown — what replacement actually costs
- ERP Readiness Assessment Tool — free two-minute readiness and replacement-need score
- ERP Consultants & Advisory — engaging independent help for an assessment
Related Resources
ADP Payroll: Independent Overview, Features, Pricing
Read our full independent review of ADP GlobalView payroll covering features, pros and cons, alternatives, pricing, user interface and much more.
GuideBambooHR Payroll: Independent Overview, Features, Pros & Cons, Pricing
Read our full independent review of BambooHR payroll covering features and modules, pros and cons, alternatives, pricing, user interface and much more.
GuideBrightpay Payroll: Independent Overview, Features, Pricing
Read our full independent review of Gusto payroll covering features, pros and cons, alternatives, pricing, user interface and much more.
GuideThanks for submitting...
We compare and review the market leading Cloud ERP solutions. Learn about the strengths, weaknesses, costs and risks of each solution in our free report.
GuideThanks for submitting...
We compare and review the market leading Cloud ERP solutions. Learn about the strengths, weaknesses, costs and risks of each solution in our free report.
Have questions about this topic?
Our ERP experts can help you find the right solution for your business.