When to Run an ERP Proof of Concept

Run an ERP proof of concept when a single, specific risk is expensive enough to sink the whole project if you are wrong about it, and isolated enough that you can test it cheaply before you commit. Skip it when the risk is generic, the buying decision is already settled, or the "proof of concept" is really a vendor demo wearing a lab coat. The mistake teams make is not running PoCs — it is running the wrong ones, or running one when a pilot, a phased rollout, or a reference call would have answered the same question at lower cost.

This is the when, not the how. If you already know you want to run one and need the step-by-step method — scope document, success-criteria template, evaluation rubric — that is a different question, covered in our deeper guide to structuring an ERP proof of concept. Here we are only deciding whether a PoC is the right tool for your situation at all, and what separates a PoC that earns a confident go/no-go decision from one that burns six weeks and tells you nothing.

What an ERP proof of concept actually is (and is not)

The term gets stretched to mean almost any pre-purchase activity, which is why so many "PoCs" disappoint. Three things are constantly conflated, and picking the wrong one is the first waste of money.

• Proof of concept (PoC): a narrow, time-boxed test that answers one technical or capability question — "can this platform actually do X for us?" It is built to retire a single unknown, then throw away.
• Pilot: a small-scale run of the real system with real users and real (usually limited) data, in conditions close to production. It tests the system and the people delivering it.
• Phased rollout: a production deployment strategy that goes live module by module or site by site. It is not evaluation; it is the implementation itself, staged to limit blast radius.

Vendor guidance draws the same lines. SAP's ERP implementation best-practices reference lists pilot implementation as a distinct strategy — "introduce a new system on a small scale, often in a controlled environment or with a limited user group, before a full-scale rollout" — and notes that "a successful pilot can build confidence among stakeholders and serve as a proof of concept for larger-scale ERP adoption." The two are related but not interchangeable: a PoC proves a capability, a pilot proves a working system with a delivery partner.

There is also the conference room pilot (CRP), which SAP's planning guidance calls out as a standard implementation step — a tabletop walk-through of configured processes with end users before go-live. A CRP happens after you have bought and started implementing; a pre-purchase PoC happens before. Calling your CRP a "PoC" does not make it one.

The practical test: a PoC produces a falsifiable answer to a named question. If you cannot finish the sentence "this PoC will tell us whether ________," you do not have a PoC. You have a demo.

The single test that justifies a PoC

A proof of concept earns its cost when one specific unknown is both expensive to be wrong about and cheap to test in isolation. Multiply those two together and you get the value of the PoC. If the unknown is cheap to be wrong about, references will do. If it is expensive to test in isolation, a PoC will balloon into a half-implementation.

Good single questions sound like this:

• Can the platform reproduce our three-way match exception flow without custom code?
• Will Odoo Studio let us rebuild our eight-step purchase approval without touching the ORM?
• Does Business Central post to our multi-entity consolidation structure the way our auditors require?
• Can the MRP engine plan against our actual bill-of-materials depth (11 levels, phantom assemblies) within an overnight window?

Each is narrow, each is something a generic reference call cannot confirm, and each — if the answer is "no" — would change your buying decision or your implementation estimate. That last clause is the whole point. A PoC that cannot change a decision is a PoC you should not run.

Notice what is not on that list: "Is Odoo a good system?" "Is Dynamics easy to use?" "Will our people like it?" Those are real questions, but they are not PoC questions. They are answered by references, demos, total cost analysis, and change-management planning — none of which a PoC will settle better than those tools will.

When a PoC is worth it

Run a proof of concept when most of these are true at once. The more boxes you tick, the clearer the case.

• The cost of being wrong is high. ERP license, implementation services, data migration, and switching costs routinely run into six or seven figures for a mid-market deployment. A PoC is an obvious trade whenever its cost is a small fraction of the implementation it protects — which, because a PoC is by definition narrow and short, it almost always is. The ratio matters more than the absolute dollars: spend single-digit percent of the at-risk implementation budget to retire the one risk that could waste all of it.
• There is genuine technical uncertainty the vendor cannot close with references. If three credible customers in your industry already run the exact process you need, the risk is already retired — call them. A PoC is for the process no one else runs the way you do.
• You have a custom or unusual process the product must replicate. Deep manufacturing routings, regulated workflows, idiosyncratic accounting, or industry-specific compliance are exactly where "standard product" claims meet your reality.
• Integration or data complexity is the real risk. If success depends on the ERP talking to a legacy MES, a 3PL's API, or a data structure nobody has mapped before, build the integration for that one interface and prove it. This is almost always worth a PoC.
• A tangible result would close a stakeholder or board buy-in gap. Sometimes the technical risk is low and the political risk is high. A focused PoC that produces a working artifact (a real report off real data, a working approval on a phone) can settle a skeptical CFO or operating committee faster than any slide.
• Custom process no reference customer runs — Run a PoC?: Yes · Why: References cannot confirm it; only a build can
• Critical integration with undocumented endpoints — Run a PoC?: Yes · Why: The interface is the risk; test the interface
• Stakeholder buy-in blocks the purchase — Run a PoC?: Yes · Why: A tangible result settles politics that slides cannot
• Vendor claims "out of the box" for your edge case — Run a PoC?: Yes · Why: Verify the claim against your data before signing
• Standard process, many reference customers — Run a PoC?: No · Why: References retire this risk cheaper
• "We want to see if people like it" — Run a PoC?: No · Why: That is a pilot or a demo, not a PoC
• Decision is already made, procurement wants a tick-box — Run a PoC?: No · Why: This is theater — see below

When a PoC is theater (skip it)

PoCs fail more often than they should, and the research on pilot programs is blunt about why. Worthwhile's analysis of proof-of-concept success cites IDC data finding that 88% of AI proof of concepts never reach wide-scale deployment, and MIT's 2025 research finding that only about 5% of AI pilots deliver measurable business value; S&P Global separately reported that 42% of companies abandoned most of their AI initiatives in 2025. Those numbers describe AI and software pilots broadly rather than ERP specifically, but the failure pattern is the same and it is organizational, not technical: undefined objectives, no success criteria, and no real decision attached to the result.

That is the signature of PoC theater — activity that looks like diligence but cannot change a decision. Recognize these patterns and refuse them:

• The decision is already made. Procurement has chosen the vendor and the "PoC" exists so the file can say one was done. If no outcome will change the purchase, do not pretend otherwise; spend the money on implementation discovery instead.
• The "free pilot." RateLinx's comparison of PoCs and pilots is explicit here: "if you are offered a free pilot, you're likely not doing a pilot, but rather, a live demonstration." Free usually means you do the work — you invest time implementing software that may be wrong, and the provider can later blame your installation. A real pilot costs roughly the same as a full implementation for the slice being tested, because real work is being done.
• No success criteria. A PoC without a pre-agreed, measurable definition of success ends in opinions, not a decision. "We want to be more productive" is a wish; "we want to cut order-processing time by 20%" is a criterion. If the team cannot state the criterion before the test runs, the test is not designed to produce a decision.
• Testing what references already prove. If the question is "does standard AP invoice entry work," the answer is yes — ten thousand customers do it daily. Spending six weeks to reconfirm a commodity capability is not diligence; it is delay.
• POC purgatory. Endless, unfunded-mandate pilots where the organization keeps "testing" because no one wants to own the go/no-go. The IDC and MIT numbers above are the graveyard of these. A PoC must have a fixed end date and a named decision-maker who will decide at that date.
• No one can spare the people. If your subject-matter experts are "too busy" to participate, the PoC will be run by whoever is available, on bad data, and the result will be worthless. See the next section.

Who has to be in the room (and how much of their week)

The most underestimated cost of a PoC is not the vendor's bill — it is your people's time, and skimping on it is the single most common reason a PoC produces garbage. SAP's implementation guidance is unusually direct about this for a vendor: the make-or-break factor in any ERP project is the team, and key team members should be dedicated to the project full-time (40 available hours) or as close to it as possible — and "no one who is unable to dedicate at least 25% of their weekly time (minimum 10 hours) should be added to the key project team," because anyone below that "will barely be able to catch up on project activities, much less add value."

Apply the same bar to a serious PoC. If the one person who actually understands your costing model cannot give the PoC ten hours a week, you do not have a costing PoC — you have a costing demo. Budget for the people before you budget for the platform.

The other staffing truth worth stealing from the broader research: Worthwhile's analysis notes that external partnerships reach deployment roughly twice as often as internal-only builds (about 67% versus 33%, per MIT's 2025 data). The lesson is not "always hire a partner" — it is that a PoC run by a partner who has executed the same play many times produces a more honest answer, faster, than a team improvising its first one. If you are weighing that, our ERP implementation and customization services cover exactly this kind of scoped, time-boxed validation work.

How small is small enough? Scope, time, and cost

The defining property of a PoC is that it is smaller and cheaper than a pilot, which is in turn smaller than a full implementation. RateLinx frames the cost relationship clearly: a PoC should require a shorter timeframe and cost less than a pilot because of its limited scope, while a pilot — given its depth — should cost roughly the same as a full implementation for the slice being tested, and should be more polished for the end user.

Translated into ERP terms, a sane PoC looks like this:

• Scope: one process, one site, one product line, or one integration. Not "finance," not "manufacturing" — multi-entity month-end close for entities A and B, or MRP for product family X against one real BOM.
• Duration: two to six weeks. Longer than that and you are building, not proving. If a six-week PoC cannot answer your question, the question is too broad.
• Data: a small but real slice — enough to be representative, not so much that migration becomes the project. Clean the slice before you load it; testing on dirty data invalidates the result.
• Cost: a fraction of the implementation estimate for the in-scope area. If the PoC quote approaches the implementation quote, you are being sold a pilot or a build, and the scope needs to come down.

The temptation is always to "just add one more module while we're at it." Resist it. Every addition doubles the variables and halves the clarity of the result. A PoC that tests five things tests nothing well.

Write the success criteria before you start

This is the step everyone agrees is important and nobody does, and it is the difference between a PoC that ends in a decision and one that ends in a meeting. The rule is simple, and Worthwhile states it cleanly: if you cannot measure it, it is not a success criterion.

Before any build happens, get the technical and business stakeholders in a room and agree, in writing, on:

1. The single question the PoC answers (one sentence).
2. The measurable outcome that constitutes a "yes" — a number, a working artifact, a demonstrated capability against your real data, not an impression.
3. The threshold for a "no" — what result would kill or reshape the purchase.
4. The decision and the decider — who will decide, on what date, and what they will decide.
5. The cost of inaction — what happens to the business if you do nothing, so the PoC result is weighed against a real alternative rather than an imagined perfect option.

Write these down and have the executive sponsor sign them. The exercise feels bureaucratic until you reach the end of the PoC and discover that without them, three departments have three different definitions of "success" and no one wants to be the one to call it. Pre-agreed criteria turn the final review from a negotiation into a comparison.

PoC vs pilot vs phased rollout: choosing the right tool

If you have read this far and are unsure whether you want a PoC, a pilot, or a phased rollout, the decision comes down to what you are trying to learn and when in the lifecycle you are.

• Can the product do X at all? — Before purchase: PoC · During implementation: (too late) · At go-live: (too late)
• Does the configured system work with our people and data? — Before purchase: Pilot (rare) · During implementation: Pilot / CRP · At go-live: —
• Can we limit risk as we deploy? — Before purchase: — · During implementation: — · At go-live: Phased rollout

A common error is reaching for a PoC when the honest need is a phased rollout. If you are confident in the product and the partner and your real worry is go-live risk, a PoC will not help you — what you want is to sequence the deployment (finance first, then supply chain, then manufacturing, say) so that each site or module goes live in a controlled, reversible way. SAP lists phased rollout as its own strategy precisely for "complex projects where full-scale ERP deployment carries significant risk," because it lets you "address issues as they arise and learn from each stage." That is a de-risking move, but it is not a PoC, and confusing the two leads to either over-testing before a purchase or under-staging after one.

Equally, do not let a vendor talk you out of a PoC you genuinely need by offering "we can just phase the rollout." Phasing manages deployment risk; it does not manage selection risk. If you are not yet sure the platform can do the one thing that matters, phasing is a commitment to find out in production — the most expensive possible place to discover the answer.

Reading the result: go, no-go, or retest

A well-run PoC has three legitimate outcomes, and only one of them is embarrassing — and it is not "no."

• Go. The criterion was met. Buy (or proceed) with the risk retired.
• No-go. The criterion was not met, and the gap is fundamental. This is a successful PoC — it saved you from a bad purchase. As Worthwhile puts it, "a failed test is not a failed project. It is information." Teams that treat a clean "no" as failure are the teams that stop running PoCs and start buying blind.
• Retest with adjusted scope. The result was ambiguous — usually because the scope or data was off, not because the product is bad. Narrow the question, fix the data, and run it again. One retest is reasonable; two is a signal that the question was never well-defined.

What you must avoid is the sunk-cost drift: the PoC "mostly" worked, the team has already spent the money, so the decision quietly becomes "well, we're this far in." This is how six-week PoCs become eighteen-month half-implementations. The defense is the pre-agreed threshold from the previous section. If the threshold said "X," and the result was "almost X," the honest read is "no," and the honest next step is to renegotiate scope or price — not to declare victory.

What to ask a vendor before you agree to a PoC

Before you commit time and money, pressure-test the PoC itself. Adapted from RateLinx's pre-commit questions, these will surface most theater before it starts:

• What is the resource requirement from our side? Get it in hours, from your people, by role. If the answer is "minimal," you are being offered a demo.
• How quickly can it be live, and what does "done" look like? A real PoC has a fixed end state and date. Open-ended is a red flag.
• Can we see measurable outcomes the system has produced for other customers? This tells you whether the vendor measures success the way you need to.
• What is our shared definition of success, written down? If the vendor will not co-sign success criteria, they are not committed to a decision — they are committed to a sale.
• What outcomes are required to move our internal initiatives forward? Tie the PoC to a real business objective so the result has somewhere to land.

A vendor confident in their product and their fit will welcome all five. A vendor relying on the wow-factor of a polished demo will resist the first and the fourth. That resistance is itself useful information about whether a PoC with them is likely to be honest.

The honest cost-benefit

Strip the jargon and the decision is arithmetic. A PoC is worth running when:

(Probability you are wrong about the risk) × (Cost of being wrong) > (Cost of the PoC) + (Cost of the delay it adds)

If the left side dwarfs the right, run it — and run it properly, with scope, criteria, people, and a decision attached. If the right side is bigger, retire the risk a cheaper way: references, a structured demo, a paid discovery engagement, or a phased rollout that limits exposure at go-live.

The companies that get ERP selection right are not the ones that always run PoCs or the ones that never do. They are the ones that know the difference between a question worth building a test for and a question a phone call could answer — and that refuse to dress the second kind up as the first. If you are staring at a purchase and genuinely unsure which side of that line you are on, that uncertainty itself is worth a conversation with an ERP partner who will tell you whether a PoC is the right call or a waste of your money.