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.
Prozessanalyse
Der Ist-Zustand wird aufgenommen und Schwachstellen werden sichtbar gemacht.
Soll-Konzept
Aus den Schwachstellen entsteht ein konkreter Zielprozess mit klaren Anforderungen.
Lastenheft
Die Anforderungen werden verbindlich dokumentiert und zur Auswahlgrundlage.
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.
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.
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
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 ProzessanalyseWoraus 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.
Ziele und Rahmenbedingungen
Die messbaren Ziele aus dem Projektauftrag und die Grenzen des Vorhabens. Jeder Zielprozess wird an einem klaren Zweck ausgerichtet.
Soll-Prozesse
Die künftigen Abläufe als Kern des Konzepts. Beschrieben als klarer Zielprozess, nicht als Abbild des alten Ablaufs.
Funktionale Anforderungen
Was das System können muss, abgeleitet aus den Soll-Prozessen. Jede Anforderung lässt sich auf einen Prozessschritt zurückführen.
Nicht-funktionale Anforderungen
Leistung, Sicherheit, Bedienbarkeit und Compliance. Die Qualitätsmerkmale, die den Betrieb später tragfähig machen.
Rollen und Verantwortlichkeiten
Wer welchen Schritt verantwortet und wo die Übergaben liegen. Klare Zuständigkeit statt diffuser Zwischenräume.
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 GlossarIn sechs Schritten zum Soll-Konzept
Ein methodischer Weg von den Ergebnissen der Prozessanalyse bis zu einem Zielbild, das direkt in das Lastenheft führt.
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.
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.
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.
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.
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.
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.
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 |
Nachvollziehbar
Jede Anforderung lässt sich auf einen Soll-Prozessschritt und ein Ziel zurückführen.
Technologieneutral
Der Zielprozess beschreibt den fachlich besten Ablauf, nicht ein bestimmtes Produkt.
Getragen
Die Fachbereiche haben mitgewirkt und stehen hinter dem Zielzustand.
Priorisiert
Muss, Soll und Kann sind unterschieden, damit später sauber bewertet werden kann.
Vollständig
Prozesse, Anforderungen, Rollen und Schnittstellen sind gemeinsam betrachtet.
Messbar
Zu jedem Ziel gibt es eine Kennzahl, an der sich der spätere Erfolg prüfen lässt.
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.
Der häufigste Fehler. Wer den alten Ablauf eins zu eins nachbaut, nimmt seine Schwachstellen mit in das neue System.
Direkt Anforderungen sammeln führt zu einer Wunschliste ohne Zielbild. Das Lastenheft wird beliebig statt hergeleitet.
Wer den Zielprozess an einem bestimmten System ausrichtet, verschenkt die Chance auf den besseren Ablauf.
Ein Soll-Konzept aus der IT allein trifft die Realität nicht und verliert die Akzeptanz derer, die den Prozess leben.
Ohne Priorisierung von Muss, Soll und Kann wird jede Anforderung gleich behandelt, und das Wesentliche geht unter.
Ein Ziel ohne messbare Größe lässt sich später nicht prüfen. Der Erfolg bleibt Gefühlssache statt Nachweis.
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.
Ein durchgängiger Weg
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-VorlageDanach folgt die Bewertung. Mit einem klaren Zielprozess und Lastenheft lässt sich die Auswahl objektiv mit einem Bewertungsraster steuern.
Zur NutzwertanalyseHä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.