ERP Decision: First the Overall IT Architecture, Then the Vendor, Then the Solution

Key Points at a Glance

‍

The same stations, two directions

Both approaches involve the same three decisions. However, the direction determines who makes the decisions. Those who start with today’s solution ultimately align the architecture with the system that has already been defined. The reverse approach begins with the architecture.

That's how it usually goes these days

SAP users participate in SAP forums, work with SAP consultants, and follow SAP announcements. This is standard practice and not a sign of negligence. In this echo chamber, however, they inevitably orient themselves toward the status quo. In this case, both the vendor and the broader ecosystem recommend the same goal: S/4HANA. Whether processes and architecture are a good fit for this makes no difference. This is legitimate, as that is where their expertise lies. Other vendors pursue different goals, but the pattern remains the same: the starting point is always the solution currently in use.

This perspective gradually narrows the options. Once the system is in place, those in charge adapt the overall IT architecture as best they can to what already exists. Anything that doesn’t fit ends up in the project as a special case, Phase 2, or an in-house development. No one consciously decided to go in this direction; it just happened. When maintenance costs become apparent later on, the mountain of customizations comes into view. Behind every in-house development lies an architectural decision that no one made.

Here's how to proceed

The reverse approach begins outside the system environment. First, the company defines its business model, business processes, and long-term goal. Based on this, it develops the overall IT architecture. From there, it determines which vendor architecture supports the goal and which ERP solution from that ecosystem is the right fit. The three steps follow this exact sequence.

‍

Step 1: The Overall IT Architecture—End-to-End Beyond ERP

The key point—one that is often overlooked—is this: The overall IT architecture extends beyond the ERP system. Business processes do not end there. Quotations, orders, deliveries, and service involve CRM, online stores, product data, and logistics. Those who focus solely on the ERP system are making decisions based on unknown interfaces. It later becomes apparent that the chosen solution covers only part of the chain.

For this reason, the overall IT architecture maps out the application landscape. It assigns processes to systems, determines data ownership, describes integration, and establishes the sequence of migration. ICB GmbH refers to the result of this preliminary work as an “architecture development plan.”

The architectural development plan documents the target state of your application landscape. It specifies which companies, processes, and systems will transition to the target structure, and in what order. It also notes which elements will intentionally follow later.

The plan consists of six components: companies and locations, order of functional areas, ongoing projects, rollout strategy, harmonization by process, and deferred decisions. Three of these are regularly underestimated. When structuring the companies, the first consideration is who is working with the template, not its design. If a unit serves its own customers according to its own manufacturing logic and market rules, it constitutes a separate business model. Any unit that operates essentially like the parent company is considered a variant. This classification determines the client structure, the level of detail in the template, and the rollout effort.

As for the order of the business units, Finance usually comes first because financial statement and reporting requirements do not allow for a “later” start. The benefits determine the investment amount. The requirements determine the timing. The rollout strategy depends on the organization’s readiness—whether it’s a “Big Bang,” “Wave,” or “Phased” approach. A pilot site helps stabilize the template. A “Big Bang” avoids parallel operations but requires an organization capable of handling a single switchover point.

The plan also documents deferred decisions, including the date, rationale, and person responsible. A single sentence distinguishes “deferred” from “forgotten.” The difference becomes apparent two years after the project.

‍

Step 2: The Manufacturer's Architecture—Who Can Carry the Goal?

With a fully developed overall IT architecture in place, the company can specifically address the vendor question: Which vendor architecture supports this goal? The operating model, cloud strategy, ecosystem, and regulatory framework are key factors. Functional lists do not set the standard here.

The choice of vendor establishes framework conditions that cannot be changed later. These include the possibility of on-premises operation, permissible expansion paths, responsibility for update schedules, and billing metrics. These are architectural and contractual issues. Therefore, they must be clarified before the first vendor invitation is issued—not just when discussing features.

After that, the landscape is sufficiently defined to evaluate specific products.

‍

Step 3: The ERP Solution—This Is Where the Product Decision Is Made

In many selection projects , the choice of a specific solution from the vendor’s ecosystem is currently missing . Simply opting for “Microsoft” is not enough. Business Central and Finance & Supply Chain Management are standalone products with different limitations. Since the overall IT architecture is end-to-end, CRM, the online store, and the data platform are also factored into the decision.

The Fit-to-Standard classification is used for evaluation. It assigns each requirement to one of four categories: Fit (covered by the standard), Config (can be resolved through configuration), Custom (extension required), or Gap (decision required). This classification determines whether development costs will be incurred. You have the greatest influence before signing the contract.

The result is a decision with a price tag and a timeline before a single request reaches the market: this solution, this scope, this cost range, this timeframe. This changes the negotiating position. Without their own architecture, companies end up purchasing conceptual work during proposal discussions and pay for it twice—once in the proposal and again in the change requests. With an overall IT architecture, rollout plan, and “fit-to-standard” assessment in place, they negotiate the implementation. The scope of work can be clearly defined, and bids can be compared.

‍

Your Entire IT Architecture in Six to Eight Weeks

ICB GmbH’s SPARK 2.0 ERP pilot project lays the foundation for these three steps. The three stages build on one another and can be commissioned individually or as a package. The work is AI-accelerated and vendor-neutral. It typically takes two to three hours per department. ICB GmbH does not sell licenses and does not maintain sales partnerships with ERP vendors. It provides the plan, not the subsequent contract.

‍

Two preliminary projects, two bases for decision-making

ICB GmbH carried out this preliminary work in two separate projects. Both provided a basis for decision-making prior to implementation. In the second case, the rollout plan was developed after the system decision had already been made.

‍

And after that: we'll help you with the implementation

Once the decision has been made, implementation begins. ICB GmbH is relying on ICB IGNITE for its ERP implementation. The phased approach defines clear milestones and uses a conference room pilot as a stress test prior to go-live. We are responsible for the project and the architecture. The implementing vendor is responsible for implementing the selected solution.

This approach ensures that you retain control over the architecture. At the same time, the level of implementation is determined by the organization that works with the solution on a daily basis. The plan you yourself established in the three steps serves as the benchmark.

‍

Do you want to reverse the order of your ERP project?

In 45 minutes, we'll assess your current situation. To do this, we'll review your business model, application landscape, legacy systems, and deadlines. We'll also determine which decisions you need to make first. Schedule an ERP consultation.

If you're in the early stages of the process, the free online ERP analysis will provide you with a vendor-neutral shortlist of suitable systems within one to two business days.

‍

The cover image and the labeled meeting scene were generated using AI. The scene is for illustrative purposes only and does not depict an actual client meeting. The overview of the two routes and the components of the architectural development plan are based on our own depictions.