Blueprint (Target Concept)
A blueprint (target concept) is the central concept document of an ERP implementation that describes how future business processes will be mapped in the new system – the documented target state as the binding basis for configuration, adaptation and realization.
A blueprint – often called a target concept (Sollkonzept) in German-speaking countries – is the central concept document of an ERP implementation that records how a company’s future business processes are to be mapped in the new system. It describes the intended target state: which processes work how in the ERP, which organizational structures, master data, documents and interfaces are needed for this, and where the standard suffices or an adaptation is required. The blueprint is created in the concept phase, after analyzing the current state and before the actual system configuration, and serves the project team as a binding construction plan for realization.
The term was shaped by classic implementation methodologies in which the "business blueprint" forms its own project phase. At its core, the blueprint translates the functional requirements from the requirements specification and functional specification into concrete, system-related solution designs: process by process, it describes how each will run in the ERP in the future. Because an ERP system intervenes deeply in almost all areas of a company, a well-thought-out target concept is one of the most important tools for making the implementation plannable, estimating effort and avoiding later course corrections.
At a glance
- Concept document of the ERP implementation: describes the target state of the processes in the new system
- Created in the concept phase, after the current-state analysis and before configuration
- Connects functional requirements with concrete mapping in processes, data and documents
- Shows where the standard suffices and where customizing or custom development is needed
- Serves as construction plan, effort baseline and reference for realization and acceptance
What a blueprint (target concept) delivers in an ERP project
The blueprint transfers a company’s goals and requirements into a robust, verifiable description of future system operation. It does not answer the question "Which ERP do we buy?" but rather "How exactly will we work with the chosen ERP?" – from quote to order to invoice, from goods receipt through inventory management to shipping. Every relevant process is described in its target flow, including the roles involved, the master data required and the documents generated.
In doing so, the target concept fulfills several tasks at once: it is the basis for configuring the system, the reference for estimating effort and costs, and the yardstick against which it is later measured whether the implementation has achieved its goals. A cleanly developed blueprint approved by the business departments reduces the biggest risk in ERP projects – an unclear target picture that keeps changing over the course of the project – to a manageable level.
Structure and components of a target concept
A blueprint is usually structured along the business processes and the ERP modules that support these processes. This allows requirement, target flow and system mapping to be assigned unambiguously. The level of detail depends on the project size: from lean process descriptions to detailed specifications with flow diagrams.
Typical contents
The usual components include the description of the target processes (such as order-to-cash and purchase-to-pay), the organizational model with clients, company codes and cost centers, the master data concept, the required documents and number ranges, and an authorization and role concept. Added to this are the interfaces to surrounding systems such as the shop, DATEV or shipping service providers, requirements for reporting and key figures, and the outline of the data migration and test concept.
Marking standard, configuration and adaptation
An essential part of the blueprint is the decision on how each requirement is met: through the system standard, through configuration (customizing) or through custom development. This assignment usually emerges within the framework of a fit-gap analysis, which compares where the standard already covers the requirements and where a gap remains. The more consistently the target concept relies on the standard, the lower the effort, maintenance load and risk are for future release updates.
From current state to target state
The blueprint is usually preceded by a current-state assessment: How do the processes run today, which systems and manual steps are involved, where do breaks and duplicate work arise? From this analysis and the project goals, the team derives the intended target state. The blueprint is therefore deliberately not a reproduction of the past, but the opportunity to question grown processes and align them with the possibilities of the new system.
It is precisely here that a frequent success criterion is decided: anyone who forces old processes one-to-one into the new ERP generates expensive customizing and forgoes the optimization potential of the implementation. A good target concept therefore seeks the balance between justified company-specific requirements and mapping that is as close to the standard as possible. This work is part of the core of change management, because it involves users early on and makes new ways of working understandable.
Distinction: blueprint vs. requirements and functional specification
Blueprint, requirements specification (Lastenheft) and functional specification (Pflichtenheft) are easily confused but fulfill different tasks. The requirements specification describes from the customer’s perspective what the system should deliver and is created early in the ERP selection. The functional specification is the vendor’s answer to it and defines how and with what the requirements are implemented. The blueprint comes in later: it is the worked-out, system-related conception of the target processes with the specifically chosen ERP – that is, the detailed bridge between requirement and realization.
In practice, these documents overlap depending on the methodology and project size. In larger implementations, the business blueprint bundles the results of the concept phase together and replaces or supplements the classic functional specification. In smaller projects, target concept contents often flow directly into a combined concept document. What matters is not the name, but that a documented, approved target picture of the processes exists before realization.
Why the blueprint is important for ERP success
Many failed or escalated ERP projects can be traced back to a blurred or missing target concept. Without a blueprint, configuration begins without a shared target picture, requirements are only discovered over the course of the project, and the scope grows uncontrollably – a pattern known as scope creep. The blueprint counteracts this because it forces business departments and the project team to think through future working before implementation and to record it in writing.
At the same time, the blueprint is economically central: it is the basis for a robust effort estimate, for prioritizing requirements and for later acceptance. Through it, one can control which requests fall within the agreed scope and which are treated as a chargeable extension. In this way, a precise target concept prevents the typical spiral of change orders, schedule delays and budget overruns and makes the path to go-live plannable.
Characteristics of a good blueprint
A good target concept is complete, free of contradictions and oriented toward the real processes rather than technical details. It describes flows concretely enough that they can be configured and tested, yet remains readable for the business department that has to approve it. Important are a deliberate standard orientation, a comprehensible justification for every adaptation and formal approval by the process owners – only this makes the blueprint the binding basis of realization.
Example
Example: a wholesaler creates a target concept for its new ERP
A wholesaler with 80 employees introduces a new ERP system. In several workshops, the project team first records today’s processes and develops the blueprint from them. For the sales process, the target flow is described: quote, order, partial delivery, collective invoice – each with the responsible roles, the required master data and the documents generated. According to the blueprint, the shop connection runs via the existing API, and the accounting handover via the DATEV standard interface.
In the accompanying fit-gap analysis, it turns out that 90 percent of the requirements are covered by the standard or through configuration. Only the individual commission process of the field sales staff requires an adaptation – clearly marked in the blueprint as custom development and backed with an effort estimate. At the later go-live, the approved target concept serves as a checklist for acceptance: process by process, it is compared whether the system actually maps the documented target flows.
Frequently asked questions
Matching ERP systems
Related services
Questions about Blueprint (Target Concept) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.