IT-Transformation · Methodik

Das Soll-Konzept nach der Prozessanalyse

Die Prozessanalyse zeigt, wie es heute läuft. Das Soll-Konzept beschreibt, wie es künftig laufen soll. Es ist das entscheidende Bindeglied zwischen der Analyse und dem Lastenheft, und genau hier entscheidet sich, ob die neue Software die alten Probleme löst oder sie nur digitalisiert.

Soll-Prozess Zielprozess Ist-Analyse Prozessdesign
Der übersprungene Schritt

Warum das Soll-Konzept entscheidend ist

Viele Projekte springen von der Analyse direkt zur Anforderungssammlung. Das ist der Moment, in dem gute Vorhaben unbemerkt entgleisen.

Die Prozessanalyse hat gezeigt, wo es hakt. Doppelte Erfassung, Medienbrüche, Wartezeiten, unklare Verantwortung. Der naheliegende Reflex ist, sofort eine Liste an Wünschen an die neue Software zu schreiben. Doch eine Wunschliste ohne Zielbild führt zu einem Lastenheft, das die alten Abläufe eins zu eins nachbaut, nur eben digital. Die Schwachstellen ziehen mit um.

Das Soll-Konzept schiebt bewusst einen Schritt dazwischen. Es fragt nicht, welche Funktionen brauchen wir, sondern zuerst, wie soll der Prozess künftig idealerweise ablaufen. Erst aus diesem Zielprozess werden die Anforderungen abgeleitet. So entsteht ein Lastenheft, das nicht die Vergangenheit beschreibt, sondern die gewünschte Zukunft.

Methodisch ist das Soll-Konzept die Phase der Systemanalyse, die aufbauend auf der Ist-Analyse den Zielentwurf entwickelt und umsetzungsfähige Lösungen für die gefundenen Schwachstellen erarbeitet. Es ist damit kein Beiwerk, sondern das inhaltliche Herz der Vorbereitung.

Die Abgrenzung

Ist-Zustand und Soll-Zustand

Ein belastbarer Soll-Ist-Vergleich braucht beide Bilder klar getrennt. Das eine ist die Diagnose, das andere der Entwurf der Lösung.

Ist-Zustand · die Diagnose

Wie es heute läuft

Das Ergebnis der Prozessanalyse. Der tatsächlich vorhandene Ablauf mit seinen Schwachstellen.

  • reale Abläufe, so wie sie sind
  • Medienbrüche und Doppelarbeit
  • Engpässe und Wartezeiten
  • unklare Verantwortlichkeiten
Soll-Zustand · der Entwurf

Wie es laufen soll

Das Ergebnis des Soll-Konzepts. Der gewünschte Zielablauf, an dem sich die Auswahl ausrichtet.

  • optimierter, klarer Zielprozess
  • durchgängige Datenflüsse
  • definierte Rollen und Übergaben
  • messbare Ziele je Prozess

Der Schritt davor. Wie die saubere Aufnahme des Ist-Zustands gelingt, zeigt die Seite zur Prozessanalyse vor der Software-Auswahl.

Zur Prozessanalyse
Die Bausteine

Woraus ein Soll-Konzept besteht

Ein gutes Soll-Konzept ist mehr als eine Prozesslandkarte. Es verbindet den Zielprozess mit den Anforderungen, den Rollen und der Systemlandschaft.

Baustein 1

Ziele und Rahmenbedingungen

Die messbaren Ziele aus dem Projektauftrag und die Grenzen des Vorhabens. Jeder Zielprozess wird an einem klaren Zweck ausgerichtet.

Baustein 2

Soll-Prozesse

Die künftigen Abläufe als Kern des Konzepts. Beschrieben als klarer Zielprozess, nicht als Abbild des alten Ablaufs.

Baustein 3

Funktionale Anforderungen

Was das System können muss, abgeleitet aus den Soll-Prozessen. Jede Anforderung lässt sich auf einen Prozessschritt zurückführen.

Baustein 4

Nicht-funktionale Anforderungen

Leistung, Sicherheit, Bedienbarkeit und Compliance. Die Qualitätsmerkmale, die den Betrieb später tragfähig machen.

Baustein 5

Rollen und Verantwortlichkeiten

Wer welchen Schritt verantwortet und wo die Übergaben liegen. Klare Zuständigkeit statt diffuser Zwischenräume.

Baustein 6

Schnittstellen und Systemlandschaft

Wie der Zielprozess in die vorhandene IT passt. Welche Systeme liefern Daten und wo verlaufen die Grenzen.

Begriffe sauber halten. Wer Ist-Prozess, Soll-Prozess und Anforderung präzise trennt, spart später viele Missverständnisse. Das Glossar hilft dabei.

Zum Glossar
Das Vorgehen

In sechs Schritten zum Soll-Konzept

Ein methodischer Weg von den Ergebnissen der Prozessanalyse bis zu einem Zielbild, das direkt in das Lastenheft führt.

1

Ziele und Rahmen festlegen

Aus dem Projektauftrag die messbaren Ziele ableiten und den Rahmen abstecken. Was soll das Vorhaben erreichen, und woran wird der Erfolg gemessen. Ohne Ziel kein sinnvoller Zielprozess.

Ergebnis: abgestimmte Zielliste und klarer Projektrahmen
2

Schwachstellen priorisieren

Die in der Ist-Analyse gefundenen Schwachstellen bewerten und nach Wirkung und Aufwand ordnen. Nicht jeder Missstand ist gleich wichtig. Der Fokus liegt auf den größten Hebeln.

Ergebnis: priorisierte Liste der zu lösenden Probleme
3

Zielprozesse entwerfen

Für die priorisierten Bereiche neue Soll-Prozesse gestalten. Bewusst am fachlich besten Ablauf orientiert und zunächst technologieneutral. Der Prozess folgt dem Ziel, nicht den Grenzen des alten Systems.

Ergebnis: dokumentierte Soll-Prozesse als Zielbild
4

Anforderungen ableiten

Aus den Soll-Prozessen die funktionalen und nicht-funktionalen Anforderungen ableiten. Jede Anforderung wird auf einen konkreten Prozessschritt zurückgeführt. So bleibt jede Anforderung begründet und nachvollziehbar.

Ergebnis: strukturierte, hergeleitete Anforderungsliste
5

Bewerten und abstimmen

Die Soll-Vorschläge mit den Fachbereichen abstimmen, Varianten gegeneinander bewerten und ein klares Votum für den Zielzustand herbeiführen. Frühe Beteiligung schafft Qualität und Akzeptanz.

Ergebnis: abgestimmter, getragener Zielzustand
6

Dokumentieren und übergeben

Das Soll-Konzept nachvollziehbar dokumentieren und als strukturierte Grundlage an die Lastenhefterstellung übergeben. Aus dem Zielbild wird die Vorlage für die verbindlichen Anforderungen.

Ergebnis: fertiges Soll-Konzept als Basis fürs Lastenheft
Werkzeug und Qualität

Wie Soll-Prozesse festgehalten werden

Ein Zielprozess braucht eine Form, die alle verstehen. Die Wahl der Notation richtet sich nach Zweck und Publikum, nicht nach Moden.

Darstellung Eignet sich für Stärke
Einfaches Flussdiagramm Überblick und Abstimmung mit Fachbereichen schnell verständlich, wenig Einarbeitung
Swimlane-Diagramm Prozesse über mehrere Rollen und Abteilungen macht Übergaben und Zuständigkeit sichtbar
BPMN detaillierte, standardisierte Modellierung präzise, werkzeuggestützt, gut für die IT
Steckbrief je Prozess Ziele, Kennzahlen und Verantwortung bündeln verbindet Prozess mit messbaren Zielen
Kriterium 1

Nachvollziehbar

Jede Anforderung lässt sich auf einen Soll-Prozessschritt und ein Ziel zurückführen.

Kriterium 2

Technologieneutral

Der Zielprozess beschreibt den fachlich besten Ablauf, nicht ein bestimmtes Produkt.

Kriterium 3

Getragen

Die Fachbereiche haben mitgewirkt und stehen hinter dem Zielzustand.

Kriterium 4

Priorisiert

Muss, Soll und Kann sind unterschieden, damit später sauber bewertet werden kann.

Kriterium 5

Vollständig

Prozesse, Anforderungen, Rollen und Schnittstellen sind gemeinsam betrachtet.

Kriterium 6

Messbar

Zu jedem Ziel gibt es eine Kennzahl, an der sich der spätere Erfolg prüfen lässt.

Typische Fehler

Sechs Fallen beim Soll-Konzept

Das Soll-Konzept scheitert selten an fehlendem Wissen, sondern an Abkürzungen. Diese sechs Muster kosten später am meisten.

Fehler 1
Den Ist-Prozess nur digitalisieren

Der häufigste Fehler. Wer den alten Ablauf eins zu eins nachbaut, nimmt seine Schwachstellen mit in das neue System.

Fehler 2
Das Soll-Konzept überspringen

Direkt Anforderungen sammeln führt zu einer Wunschliste ohne Zielbild. Das Lastenheft wird beliebig statt hergeleitet.

Fehler 3
Zu früh auf ein Produkt schauen

Wer den Zielprozess an einem bestimmten System ausrichtet, verschenkt die Chance auf den besseren Ablauf.

Fehler 4
Die Fachbereiche außen vor lassen

Ein Soll-Konzept aus der IT allein trifft die Realität nicht und verliert die Akzeptanz derer, die den Prozess leben.

Fehler 5
Alles gleich wichtig nehmen

Ohne Priorisierung von Muss, Soll und Kann wird jede Anforderung gleich behandelt, und das Wesentliche geht unter.

Fehler 6
Ziele ohne Kennzahl formulieren

Ein Ziel ohne messbare Größe lässt sich später nicht prüfen. Der Erfolg bleibt Gefühlssache statt Nachweis.

Der Übergang

Vom Soll-Konzept zum Lastenheft

Das Soll-Konzept ist kein Selbstzweck. Sein Ziel ist ein präzises Lastenheft, das aus dem Zielprozess folgt statt aus einer Wunschliste.

Der rote Faden

Ein durchgängiger Weg

Prozessanalyse Soll-Konzept Lastenheft

Die Analyse liefert den Ist-Zustand, das Soll-Konzept den Zielprozess, das Lastenheft die verbindlichen Anforderungen. In manchen Methoden wird die Soll-Konzeption sogar direkt als Lastenheft verstanden, das aus Prozessbeschreibungen, funktionalen Anforderungen und der Infrastruktur besteht. Praktisch heißt das, wer das Soll-Konzept sauber macht, hat das halbe Lastenheft schon geschrieben.

Der nächste Schritt. Wie aus dem Zielprozess ein strukturiertes, verbindliches Lastenheft wird, zeigt die Vorlage mit über hundert Anforderungen.

Zur Lastenheft-Vorlage

Danach folgt die Bewertung. Mit einem klaren Zielprozess und Lastenheft lässt sich die Auswahl objektiv mit einem Bewertungsraster steuern.

Zur Nutzwertanalyse
FAQ

Häufige Fragen zum Soll-Konzept

Kompakte, eigenständige Antworten zu Definition, Abgrenzung, Methode und Übergang zum Lastenheft.

Was ist ein Soll-Konzept?

Ein Soll-Konzept ist im Phasenmodell der Systemanalyse die Phase, die aufbauend auf der Ist-Analyse den Zielzustand entwirft. Es beschreibt, wie die Prozesse künftig ablaufen sollen, und entwickelt umsetzungsfähige Lösungen für die in der Analyse gefundenen Schwachstellen. Das Soll-Konzept übersetzt damit Probleme in einen konkreten Zielprozess und bildet die inhaltliche Grundlage für das Lastenheft.

Was ist der Unterschied zwischen Ist-Analyse und Soll-Konzept?

Die Ist-Analyse nimmt den heutigen Zustand auf und deckt Schwachstellen auf, sie beschreibt, wie es tatsächlich läuft. Das Soll-Konzept beschreibt den gewünschten Zielzustand, also wie es künftig laufen soll. Die Ist-Analyse ist die Diagnose, das Soll-Konzept der Entwurf der Lösung. Beide zusammen ermöglichen einen belastbaren Soll-Ist-Vergleich.

Wie hängen Soll-Konzept und Lastenheft zusammen?

Das Soll-Konzept liefert die inhaltliche Grundlage für das Lastenheft. In manchen Methoden wird die Soll-Konzeption sogar als Lastenheft verstanden, das aus Prozessbeschreibungen, funktionalen Anforderungen und der Infrastruktur besteht. Praktisch gilt, erst den Zielprozess klären, dann die Anforderungen daraus verbindlich im Lastenheft festhalten. Ohne sauberes Soll-Konzept wird das Lastenheft entweder lückenhaft oder es zementiert die alten Prozesse.

Sollte das Soll-Konzept technologieneutral sein?

Weitgehend ja. Der Zielprozess sollte zunächst am fachlich besten Ablauf ausgerichtet werden, nicht an den Grenzen eines bestimmten Systems. Das hält den Blick für die optimale Lösung offen und verhindert, dass alte Einschränkungen unbewusst übernommen werden. Konkrete Produktentscheidungen fallen erst später in der Auswahl.

Wer sollte am Soll-Konzept mitarbeiten?

Das Soll-Konzept entsteht nicht in der IT allein. Die Fachbereiche, die den Prozess später leben, gehören von Anfang an einbezogen, ergänzt um die Prozessverantwortlichen und bei Bedarf externe Methodenkompetenz. Diese frühe Beteiligung erhöht die Qualität des Zielprozesses und die spätere Akzeptanz der Lösung.

Was ist ein häufiger Fehler beim Soll-Konzept?

Der häufigste Fehler ist, den bestehenden Prozess einfach digital abzubilden, statt ihn zu hinterfragen. Dann werden alte Schwachstellen in das neue System übernommen. Ebenso häufig ist, das Soll-Konzept zu überspringen und direkt Anforderungen zu sammeln, wodurch das Lastenheft zur unsortierten Wunschliste wird, statt aus einem klaren Zielprozess zu folgen.

Vom Zielprozess zur richtigen Software

Ein sauberes Soll-Konzept macht die Auswahl planbar. Aus dem Zielprozess folgt das Lastenheft, aus dem Lastenheft die Bewertung, und am Ende steht eine Lösung, die zu Ihren Prozessen passt. Neutral und auf Basis realer Projekte.