Key Points at a Glance
The choice of system is determined by the few requirements that a vendor can meet only with an extension—or not at all. These requirements become apparent only when the level of fulfillment is specified in the protocol for each commitment.
Why Every Provider Meets Your Requirements
Order entry, invoicing, inventory transactions, and accounting are all part of the ERP requirements specification—even for acceptance and the contract. However, they do not help distinguish between vendors, because every established ERP system has included these functions as standard features for years, and every vendor therefore confirms that they are included.
A supplier includes “batch traceability” in its requirements, and all vendors confirm this line. At first glance, they are correct, since batch management is a standard feature of any system for manufacturing and retail.
It is only during the process workshop that it becomes clear what the company actually needs. Traceability must extend beyond purchased parts all the way back to the smelting process. And the documentation must be provided to the customer within 24 hours, because the customer’s own recall process depends on it. A single line in the catalog thus becomes the criterion on which some of the candidate parts fail to meet the requirements.
The difference between the line item and the criterion doesn’t arise at a desk, but rather through conversations with the employees who are responsible for the process on a daily basis. The free ERP analysis narrows down the market in advance to the systems that are a good fit for your company. Work on the catalog then focuses on a manageable number of candidates rather than the entire market.
In what ways do ERP systems differ from one another?
In a single-product operation run by a single company, the decision-making process is very different from that of a holding company with plants in multiple countries. For a pure distributor, the reporting requirements alone can determine the shortlist. Therefore, it becomes clear which requirement is the deciding factor only after reviewing the requirements one by one. These requirements almost always fall into four categories.
Industry Logic
The key factor is the extent to which a system’s standard functionality maps industry-specific processes without requiring modifications to the product: purchasing budget planning in the fashion retail sector, formulas with by-products, and scheduled work steps. If settings alone are sufficient, the system remains updatable. If code is required, you’ll be paying for it indefinitely.
Group and Corporate Structure
Several legal entities have an impact on the data model itself, not just on the reports. Intercompany eliminations, multiple currencies, differing fiscal year-ends, consolidation: Either a system supports these features, or each issue becomes a subproject with its own budget.
System Architecture and Interfaces
A new ERP system always has to integrate into an existing landscape. The number and type of interfaces depend on how many legacy systems remain in place. For the same integration with an online store or warehouse technology, one vendor might provide a ready-made connector, while for another, it becomes a development project.
Obligations and Documentation
E-invoicing, audit-compliant archiving, and the documentation required by an auditor are non-negotiable. Every modern ERP system supports these features. Differences lie in the speed with which a vendor releases the next version and in the number of countries covered.
Of these four areas, the system landscape is most often underestimated. Whether an existing system remains or is phased out is an architectural decision with its own rationale—not a byproduct of system selection. If the target architecture is defined before system selection, the catalog will contain verifiable interface criteria rather than a mere statement of intent.
At what level does a provider meet the requirement?
If a vendor confirms a requirement without specifying how it will be addressed, you’ll end up knowing no more than you did before. That’s because the vendor could fulfill it using the standard software, through configuration, via an extension or industry-specific solution, or only with an additional third-party system. On paper, these four options look the same, but their costs over the system’s lifecycle differ significantly. There’s one answer you’ll hear more often than any other: “The feature will be available in one of the next releases.” As long as the vendor doesn’t provide a release number, a specific date, or a contractual commitment, the feature doesn’t exist at the time you’re making your decision and should be treated as a gap.
The fact that a system needs to be configured is standard practice and not a flaw. Every ERP system is set up before it goes live. Number ranges, posting rules, approval levels, and permissions are settings—not modifications to the product itself. A deduction for configuration effort ultimately only reflects how a vendor has chosen to configure the system at the time of delivery. However, if a system requires so much setup that it is measured in consulting days, this effort should be included in the quote.
With the first upgrade, code is generated that must keep pace with the manufacturer’s release cycle, and in the cloud, this cycle is non-negotiable. The vendor verifies technical compatibility. Whether your process will still function as intended after the update must be determined by your own employees using your own test data. If the legislature changes a requirement, the vendor provides the update for its standard. You must handle the updates for your own extensions. This isn’t an argument against extensions. However, they incur costs over the entire lifecycle, and this expense is often overlooked in most evaluations.
If the standard does not cover a requirement: If it is based on a legal obligation or certification, the solution is purchased because a manufacturer will provide ongoing maintenance. If it relates to what sets your company apart from competitors, it is worth developing the solution in-house.
AI-powered development reduces the cost of writing code. When it comes to integrations and small add-on tools, this actually makes in-house development more attractive. At the core of the ERP system, however, little changes, since that is where the bulk of the effort goes into specification, testing, and release maintenance.
In a vendor-neutral ERP selection consultation, each stage is therefore documented in writing for every individual commitment. This includes the date and the name of the person who made the commitment.
Why a System Can Fail Because of a Single Requirement
A “must-have” requirement is not necessarily a deal-breaker, even though the two terms are often used interchangeably. Most “must-have” requirements can be addressed through an extension, are factored into the pricing, and are regularly included in the evaluation. Only in the case of the few requirements that were explicitly designated as deal-breakers in advance will a candidate be eliminated from the process—and even a high total score will not change that outcome. This regularly sparks controversy during the evaluation round, because a candidate who has been eliminated often scores well in the overall evaluation.
A multichannel fashion retailer with multiple subsidiaries, stores, its own online shop, and a wholesale division for its private labels had its requirements documented. From over 200 requirements, approximately 80 weighted evaluation criteria were identified; of the 44 ERP systems considered, 5 advanced to the detailed evaluation phase.
In the end, a single predefined exclusion criterion eliminated one of these five from the process: The cloud offering lacked purchasing budget planning, which is referred to as “open-to-buy” in the fashion retail industry. This only became apparent during the detailed evaluation because the vendor had previously indicated that this feature was included.
The management establishes such exclusion criteria, providing written justification before the first bid is submitted. Anyone who introduces a deal-breaker only after the results are in is thereby confirming a system that was already in place long ago. What applies to the exclusion criteria applies equally to the weighting. After the vendor presentations, no one can weigh the options impartially anymore, because all parties involved know which candidate stands to benefit from which shift.
If the requirements change—for example, due to a new legal obligation or an acquisition—a criterion may be added, but only if it applies to all candidates and is implemented before the next round of evaluations.
Each of these steps requires effort: identifying the requirements where the systems diverge, describing them in a verifiable manner, and documenting the steps leading up to the initial presentation. Few companies have the capacity to handle this in addition to their day-to-day operations.
How ICB GmbH's SPARK® 2.0 preliminary project evaluates the critical requirements
For you, the SPARK® 2.0 ERP preliminary project begins with facilitated workshops, one for each end-to-end process. Two to three hours per department are sufficient to identify the areas where the current system hinders work. Your involvement is limited to these sessions and occasional follow-up questions.
The work, which would otherwise tie up resources for weeks, runs in the background without requiring your involvement. The market is assessed in a single pass; each requirement is evaluated against every provider using the same criteria and backed by a source you can verify. The criteria for eliminating a candidate are established before the providers make their presentations. AI agents drive the pace, while a consultant oversees every step.
ICB GmbH does not sell licenses and does not receive commissions from ERP providers; billing is based on actual time and effort. The system ultimately recommended does not affect the fee. What remains is a decision that you will still be able to justify two years later. For each requirement, you can see exactly what each provider has committed to.
The choice of system is determined by the few requirements that a vendor can meet only with an extension—or not at all. These requirements become apparent only when the level of fulfillment is specified in the protocol for each commitment.
The cover image was generated by AI. The illustration of the compliance levels is a graphic created by ICB GmbH. The project example describes a real consulting project in anonymized form.
