Projekt & EinführungZuletzt geprüft: 2026-07-31

Blueprint (Sollkonzept)

Ein Blueprint (Sollkonzept) ist das zentrale Konzeptdokument einer ERP-Einführung, das beschreibt, wie die künftigen Geschäftsprozesse im neuen System abgebildet werden – der dokumentierte Soll-Zustand als verbindliche Grundlage für Konfiguration, Anpassung und Realisierung.

Ein Blueprint – im deutschsprachigen Raum meist als Sollkonzept bezeichnet – ist das zentrale Konzeptdokument einer ERP-Einführung, das festhält, wie die künftigen Geschäftsprozesse eines Unternehmens im neuen System abgebildet werden sollen. Er beschreibt den angestrebten Soll-Zustand: welche Abläufe im ERP wie funktionieren, welche Organisationsstrukturen, Stammdaten, Belege und Schnittstellen dafür nötig sind und an welchen Stellen der Standard genügt oder eine Anpassung erforderlich ist. Der Blueprint entsteht in der Konzeptphase, nach der Analyse des Ist-Zustands und vor der eigentlichen Systemkonfiguration, und dient dem Projektteam als verbindlicher Bauplan für die Realisierung.

Der Begriff wurde durch klassische Einführungsmethodiken geprägt, in denen der „Business Blueprint" eine eigene Projektphase bildet. Im Kern übersetzt der Blueprint die fachlichen Anforderungen aus Lasten- und Pflichtenheft in konkrete, systembezogene Lösungsentwürfe: Prozess für Prozess wird beschrieben, wie er künftig im ERP ablaufen wird. Weil ein ERP-System tief in nahezu alle Unternehmensbereiche eingreift, ist ein durchdachtes Sollkonzept eines der wichtigsten Werkzeuge, um die Einführung planbar zu machen, Aufwände abzuschätzen und spätere Kurskorrekturen zu vermeiden.

Auf einen Blick

  • Konzeptdokument der ERP-Einführung: beschreibt den Soll-Zustand der Prozesse im neuen System
  • Entsteht in der Konzeptphase, nach der Ist-Analyse und vor der Konfiguration
  • Verbindet fachliche Anforderungen mit konkreter Abbildung in Prozessen, Daten und Belegen
  • Zeigt, wo der Standard genügt und wo Customizing oder Individualentwicklung nötig ist
  • Dient als Bauplan, Aufwandsgrundlage und Referenz für Realisierung und Abnahme

Was ein Blueprint (Sollkonzept) im ERP-Projekt leistet

Der Blueprint überführt die Ziele und Anforderungen eines Unternehmens in eine belastbare, prüfbare Beschreibung des künftigen Systembetriebs. Er beantwortet nicht die Frage „Welches ERP kaufen wir?", sondern „Wie werden wir mit dem gewählten ERP konkret arbeiten?" – vom Angebot über den Auftrag bis zur Rechnung, vom Wareneingang über die Bestandsführung bis zum Versand. Jeder relevante Prozess wird in seinem Soll-Ablauf beschrieben, inklusive der beteiligten Rollen, der benötigten Stammdaten und der erzeugten Belege.

Damit erfüllt das Sollkonzept mehrere Aufgaben zugleich: Es ist die Grundlage für die Konfiguration des Systems, die Referenz für die Aufwands- und Kostenschätzung und der Maßstab, an dem später gemessen wird, ob die Einführung ihre Ziele erreicht hat. Ein sauber erarbeiteter und vom Fachbereich freigegebener Blueprint reduziert das größte Risiko in ERP-Projekten – ein unklares, im Projektverlauf ständig wechselndes Zielbild – auf ein beherrschbares Maß.

Aufbau und Bestandteile eines Sollkonzepts

Ein Blueprint gliedert sich in der Regel entlang der Geschäftsprozesse und der ERP-Module, die diese Prozesse tragen. So lassen sich Anforderung, Soll-Ablauf und Systemabbildung eindeutig zuordnen. Der Detaillierungsgrad richtet sich nach der Projektgröße: von schlanken Prozessbeschreibungen bis zu ausführlichen Spezifikationen mit Ablaufdiagrammen.

Typische Inhalte

Zu den üblichen Bestandteilen gehören die Beschreibung der Soll-Prozesse (etwa Order-to-Cash und Purchase-to-Pay), das Organisationsmodell mit Mandanten, Buchungskreisen und Kostenstellen, das Stammdatenkonzept, die benötigten Belege und Nummernkreise sowie ein Berechtigungs- und Rollenkonzept. Hinzu kommen die Schnittstellen zu Umsystemen wie Shop, DATEV oder Versanddienstleistern, Anforderungen an Reporting und Kennzahlen sowie die Grundzüge des Datenmigrations- und Testkonzepts.

Standard, Konfiguration und Anpassung kennzeichnen

Ein wesentlicher Teil des Blueprints ist die Entscheidung, wie jede Anforderung erfüllt wird: durch den Systemstandard, durch Konfiguration (Customizing) oder durch Individualentwicklung. Diese Zuordnung entsteht in der Regel im Rahmen einer Fit-Gap-Analyse, die abgleicht, wo der Standard die Anforderungen bereits abdeckt und wo eine Lücke bleibt. Je konsequenter das Sollkonzept auf den Standard setzt, desto geringer sind Aufwand, Wartungslast und Risiko bei künftigen Release-Updates.

Vom Ist-Zustand zum Soll-Zustand

Dem Blueprint geht üblicherweise eine Ist-Aufnahme voraus: Wie laufen die Prozesse heute, welche Systeme und manuellen Schritte sind beteiligt, wo entstehen Brüche und Doppelarbeit? Aus dieser Analyse und den Projektzielen leitet das Team den angestrebten Soll-Zustand ab. Der Blueprint ist damit bewusst kein Abbild der Vergangenheit, sondern die Chance, gewachsene Abläufe zu hinterfragen und an den Möglichkeiten des neuen Systems auszurichten.

Genau hier entscheidet sich ein häufiges Erfolgskriterium: Wer alte Prozesse eins zu eins ins neue ERP zwingt, erzeugt teures Customizing und verschenkt das Optimierungspotenzial der Einführung. Ein gutes Sollkonzept sucht deshalb die Balance zwischen berechtigten unternehmensspezifischen Anforderungen und einer möglichst standardnahen Abbildung. Diese Arbeit gehört zum Kern des Change-Managements, weil sie Anwenderinnen und Anwender frühzeitig einbindet und neue Arbeitsweisen verständlich macht.

Abgrenzung: Blueprint vs. Lasten- und Pflichtenheft

Blueprint, Lastenheft und Pflichtenheft werden leicht verwechselt, erfüllen aber unterschiedliche Aufgaben. Das Lastenheft beschreibt aus Kundensicht, was das System leisten soll, und entsteht früh in der ERP-Auswahl. Das Pflichtenheft ist die Antwort des Anbieters darauf und legt fest, wie und womit die Anforderungen umgesetzt werden. Der Blueprint setzt später an: Er ist die ausgearbeitete, systembezogene Konzeption der Soll-Prozesse mit dem konkret ausgewählten ERP – also die detaillierte Brücke zwischen Anforderung und Realisierung.

In der Praxis überlappen sich diese Dokumente je nach Methodik und Projektgröße. Bei größeren Einführungen fasst der Business Blueprint die Ergebnisse der Konzeptphase gebündelt zusammen und ersetzt oder ergänzt das klassische Pflichtenheft. Bei kleineren Projekten fließen Sollkonzept-Inhalte oft direkt in ein kombiniertes Konzeptdokument. Entscheidend ist nicht der Name, sondern dass vor der Realisierung ein dokumentiertes, freigegebenes Zielbild der Prozesse existiert.

Warum der Blueprint für den ERP-Erfolg wichtig ist

Viele gescheiterte oder eskalierte ERP-Projekte lassen sich auf ein unscharfes oder fehlendes Sollkonzept zurückführen. Ohne Blueprint beginnt die Konfiguration ohne gemeinsames Zielbild, Anforderungen werden erst im Projektverlauf entdeckt, und der Umfang wächst unkontrolliert – ein Muster, das als Scope-Creep bekannt ist. Der Blueprint wirkt dagegen, weil er Fachbereiche und Projektteam zwingt, das künftige Arbeiten vor der Umsetzung durchzudenken und schriftlich festzuhalten.

Zugleich ist der Blueprint ökonomisch zentral: Er ist die Basis für eine belastbare Aufwandsschätzung, für die Priorisierung von Anforderungen und für die spätere Abnahme. Über ihn lässt sich steuern, welche Wünsche im vereinbarten Umfang liegen und welche als kostenpflichtige Erweiterung behandelt werden. So verhindert ein präzises Sollkonzept die typische Spirale aus Nachträgen, Terminverschiebungen und Budgetüberschreitungen und macht den Weg zum Go-Live planbar.

Merkmale eines guten Blueprints

Ein gutes Sollkonzept ist vollständig, widerspruchsfrei und an den realen Prozessen orientiert statt an technischen Details. Es beschreibt Abläufe so konkret, dass sie sich konfigurieren und testen lassen, bleibt aber lesbar für den Fachbereich, der es freigeben muss. Wichtig sind eine bewusste Standard-orientierung, eine nachvollziehbare Begründung jeder Anpassung und die formale Freigabe durch die Prozessverantwortlichen – erst sie macht den Blueprint zur verbindlichen Grundlage der Realisierung.

Praxisbeispiel

Beispiel: Großhändler erstellt ein Sollkonzept für sein neues ERP

Ein Großhändler mit 80 Mitarbeitern führt ein neues ERP-System ein. In mehreren Workshops nimmt das Projektteam zunächst die heutigen Abläufe auf und erarbeitet daraus den Blueprint. Für den Verkaufsprozess wird der Soll-Ablauf beschrieben: Angebot, Auftrag, Teillieferung, Sammelrechnung – jeweils mit den zuständigen Rollen, den benötigten Stammdaten und den erzeugten Belegen. Die Shop-Anbindung erfolgt laut Blueprint über die vorhandene API, die Fibu-Übergabe über die DATEV-Standardschnittstelle.

In der begleitenden Fit-Gap-Analyse zeigt sich, dass 90 Prozent der Anforderungen mit dem Standard oder durch Konfiguration abgedeckt sind. Nur der individuelle Provisionsprozess der Außendienstler erfordert eine Anpassung – im Blueprint klar als Individualentwicklung gekennzeichnet und mit Aufwand hinterlegt. Beim späteren Go-Live dient das freigegebene Sollkonzept als Prüfliste für die Abnahme: Prozess für Prozess wird verglichen, ob das System die dokumentierten Soll-Abläufe tatsächlich abbildet.

Häufige Fragen

Beide Begriffe meinen dasselbe Dokument. „Blueprint" stammt aus internationalen ERP-Methodiken, „Sollkonzept" ist die verbreitete deutsche Bezeichnung. Es beschreibt jeweils, wie die künftigen Geschäftsprozesse im neuen ERP-System abgebildet werden sollen – den dokumentierten Soll-Zustand als Grundlage der Realisierung.
Der Blueprint entsteht in der Konzeptphase – nach der Auswahl des Systems und der Aufnahme des Ist-Zustands, aber vor der eigentlichen Konfiguration. Er ist damit die Brücke zwischen den fachlichen Anforderungen aus Lasten- und Pflichtenheft und der technischen Umsetzung im System.
Das Pflichtenheft legt grundsätzlich fest, wie ein Anbieter die Anforderungen umsetzt. Der Blueprint arbeitet die Soll-Prozesse mit dem konkret gewählten ERP detailliert aus – inklusive Organisationsmodell, Stammdaten und Belegen. Je nach Methodik ersetzt oder ergänzt der Business Blueprint das klassische Pflichtenheft.
Das Sollkonzept entsteht gemeinsam: Der Implementierungspartner bringt Systemwissen und Methodik ein, die Fachbereiche und Key-User des Unternehmens ihre Prozesskenntnis. Die Prozessverantwortlichen geben den Blueprint anschließend frei, wodurch er zur verbindlichen Grundlage für Konfiguration und Abnahme wird.

Fragen zu Blueprint (Sollkonzept) in deinem ERP-Projekt?

Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.

Kostenloses Erstgespräch