Prozessanalyse vor der Software-Auswahl
Die meisten Auswahlfehler entstehen nicht bei der Auswahl, sondern davor. Wer seine Prozesse nicht kennt, kann keine Software danach aussuchen. Diese Seite zeigt, warum die Prozessanalyse über den Erfolg entscheidet, wie sie Schritt für Schritt abläuft, und mit welchen Hebeln aus ihr eine belastbare, nachvollziehbare Auswahl wird.
Erst die Prozesse, dann die Software
Die Prozessanalyse ist die zweite Stufe der IT-Transformation, zwischen Strategie und Auswahl. Sie übersetzt das strategische Zielbild in konkrete Soll-Prozesse und Anforderungen. Ohne diese Übersetzung beruht jede Auswahl auf Bauchgefühl und Anbieterpräsentation, nicht auf dem tatsächlichen Bedarf.
Was passiert, wenn man ohne Prozessanalyse auswählt
- Auswahl nach Demo-Eindruck. Die beste Präsentation gewinnt, nicht die beste Passung.
- Anforderungen wandern. Was fehlt, fällt erst mitten in der Einführung auf, unter Zeitdruck.
- Exzessive Anpassung. Die Software wird teuer an ungeklärte Sonderwege angepasst.
- Keine Nachvollziehbarkeit. Die Entscheidung lässt sich im Nachhinein nicht begründen.
Was die Prozessanalyse davor leistet
- Klarer Maßstab. Jede Lösung wird an dokumentierten Soll-Prozessen gemessen.
- Stabile Anforderungen. Muss und Kann sind vor der Marktsichtung getrennt und gewichtet.
- Standard vor Anpassung. Bewusst gestaltete Soll-Prozesse senken den Anpassungsbedarf.
- Begründbare Wahl. Ein Lastenheft macht die Entscheidung transparent und verteidigbar.
Anbieterneutral, ohne Provision. Eine saubere Prozessanalyse ist die Grundlage jeder neutralen Auswahl, weil sie den Bedarf definiert, bevor ein Anbieter ins Spiel kommt.
Mehr zur NeutralitätFünf Schritte von den Abläufen zum Anforderungskatalog
Jeder Schritt erzeugt ein Ergebnis, das den nächsten trägt. Am Ende steht ein Lastenheft, das die spätere Auswahl messbar und die Einführung planbar macht.
Ist-Prozesse aufnehmen
Die tatsächlichen Abläufe werden mit den Menschen erhoben, die sie täglich ausführen, inklusive Ausnahmen, Umgehungen und Medienbrüchen. Nicht wie es im Handbuch steht, sondern wie wirklich gearbeitet wird.
Ergebnis: Ist-ProzesslandkarteSchwachstellen und Ziele identifizieren
Brüche, Doppelarbeit, manuelle Nacharbeit und Medienwechsel werden sichtbar gemacht und den Geschäftszielen gegenübergestellt. So wird klar, welche Probleme die neue Software wirklich lösen soll.
Ergebnis: Schwachstellen und ZielbildSoll-Prozesse entwerfen
Die künftigen Abläufe werden bewusst gestaltet, orientiert an bewährten Standards statt an gewachsenen Gewohnheiten. Leitfrage: Wie sollte der Prozess aussehen, wenn wir ihn heute neu erfänden?
Ergebnis: Soll-ProzesseAnforderungen priorisieren
Aus den Soll-Prozessen werden konkrete Anforderungen abgeleitet und klar in Muss und Kann getrennt und gewichtet. Diese Priorisierung verhindert, dass Nebensächliches die Auswahl dominiert.
Ergebnis: priorisierte AnforderungenAnforderungskatalog erstellen
Die priorisierten Anforderungen werden in einem Lastenheft dokumentiert. Es macht die spätere Auswahl messbar, dient als Grundlage der Anbieteransprache und ist der Maßstab, an dem sich jede Demo beweisen muss.
Ergebnis: LastenheftDie Ergebnisse und wohin sie wirken
Jedes Ergebnis der Prozessanalyse speist eine spätere Stufe der Transformation. Genau das macht die Prozessanalyse zum Bindeglied zwischen Strategie und Auswahl.
| Ergebnis | Zweck | Wirkt auf Stufe |
|---|---|---|
| Ist-Prozesslandkarte | Schafft ein gemeinsames, ehrliches Bild der heutigen Abläufe als Ausgangspunkt | Prozesse |
| Schwachstellenliste | Benennt die konkreten Probleme, die die neue Software lösen soll | Prozesse |
| Soll-Prozesse | Definieren den angestrebten Zielzustand, an bewährten Standards orientiert | Prozesse |
| Priorisierte Anforderungen | Trennen Muss von Kann und geben der Auswahl ihre Gewichte | Auswahl |
| Lastenheft | Macht die Auswahl messbar und dient als Maßstab für jede Anbieter-Demo | Auswahl |
| Soll-Prozess-Dokumentation | Liefert die Vorlage für Konfiguration, Test und Schulung in der Einführung | Einführung |
Software an kaputte Prozesse anpassen
Wenn eine Anforderung erst mitten in der Einführung auffällt, wird die Standardsoftware daran angepasst. Diese exzessive Individualisierung gilt als die schädlichste Folge fehlender Prozessanalyse, weil sie Kosten und Komplexität dauerhaft erhöht und künftige Updates erschwert.
Wie teuer das werden kann, zeigt ein öffentlich dokumentierter Fall. Bei einer britischen Großverwaltung stiegen die Kosten eines neuen Systems von anfänglich rund 19 Millionen auf ein geplantes Vielfaches, ein Faktor, der später sogar mit der Insolvenz der Verwaltung in Verbindung gebracht wurde. Warum IT-Projekte scheitern ordnet dieses Muster ein.
Werden Anforderungen nicht sauber erhoben, entsteht ein System, das an den realen Abläufen vorbeigeht, egal wie gut die Software an sich ist.
Sonderanpassungen kosten in der Einführung, und erneut bei jedem Update, das an ihnen vorbei geplant werden muss.
Soll-Prozesse an bewährten Standards auszurichten senkt Anpassungsbedarf, Kosten und Risiko zugleich.
Sechs Hebel für eine wirksame Prozessanalyse
Jeder Hebel macht die Analyse belastbarer und die spätere Auswahl robuster. Zusammen verhindern sie die häufigsten Fehler dieser Stufe.
Richtige Menschen einbinden
Die Anwender, die die Prozesse täglich ausführen, sind von Anfang an beteiligt.
Ist vor Soll erheben
Zuerst den tatsächlichen Zustand aufnehmen, dann den Zielzustand entwerfen.
Standard vor Anpassung
Soll-Prozesse an bewährten Standards ausrichten, statt Sonderwege zu zementieren.
Muss und Kann trennen
Jede Anforderung priorisieren und gewichten, damit die Auswahl fokussiert bleibt.
Ergebnisse dokumentieren
Anforderungen im Lastenheft festhalten, um die Auswahl begründbar zu machen.
Anbieter am Soll testen
Lösungen an realen Soll-Prozessen und echten Daten vorführen lassen, nicht an Standard-Demos.
Häufige Fragen zur Prozessanalyse
Kompakte, eigenständige Antworten zu Vorgehen, Ergebnissen, Beteiligten und Einordnung.
Was ist eine Prozessanalyse im Kontext der Software-Auswahl?
Eine Prozessanalyse ist die systematische Erhebung und Bewertung der bestehenden Geschäftsabläufe mit dem Ziel, die künftigen Soll-Prozesse und die daraus abgeleiteten Anforderungen an eine Software zu bestimmen. Sie beantwortet die Frage, was die Software leisten muss, bevor überhaupt Anbieter betrachtet werden. Damit ist sie die Grundlage einer nachvollziehbaren und robusten Auswahl.
Warum sollte die Prozessanalyse vor der Software-Auswahl stattfinden?
Weil ohne klare Soll-Prozesse und Anforderungen die Auswahl auf Bauchgefühl und Anbieterpräsentationen beruht. Untersuchungen zeigen, dass ein erheblicher Teil der Softwareprojekte an unklaren oder unvollständigen Anforderungen scheitert. Wer die Prozesse erst während oder nach der Auswahl klärt, riskiert wandernde Anforderungen, teure Nachbesserungen und eine Software, die am tatsächlichen Bedarf vorbeigeht.
Was ist der Unterschied zwischen Ist-Prozess und Soll-Prozess?
Der Ist-Prozess beschreibt, wie ein Ablauf heute tatsächlich funktioniert, inklusive aller Ausnahmen, Umgehungen und Medienbrüche. Der Soll-Prozess beschreibt, wie der Ablauf künftig gestaltet werden soll, bewusst optimiert und an bewährten Standards orientiert. Die Prozessanalyse macht beide sichtbar und leitet aus dem Soll-Zustand die Anforderungen an die Software ab.
Was ist das Ergebnis einer Prozessanalyse?
Das zentrale Ergebnis ist ein dokumentierter Anforderungskatalog oder ein Lastenheft, in dem die Soll-Prozesse und die daraus abgeleiteten, priorisierten Anforderungen festgehalten sind. Ergänzend entstehen eine Übersicht der Ist-Prozesse, eine Liste der Schwachstellen und eine klare Trennung von Muss- und Kann-Anforderungen. Diese Ergebnisse speisen direkt die Software-Auswahl und später die Einführung.
Was passiert, wenn man die Prozessanalyse überspringt?
Ohne Prozessanalyse fehlt der Maßstab für die Auswahl. Häufige Folgen sind eine Software, die nicht zu den realen Abläufen passt, teure nachträgliche Anpassungen und eine ausufernde Individualisierung. Diese exzessive Anpassung gilt als eine der schädlichsten Folgen fehlender Anforderungserhebung, weil sie Kosten, Komplexität und die spätere Update-Fähigkeit dauerhaft belastet.
Wie lange dauert eine Prozessanalyse?
Die Dauer hängt von Umfang und Komplexität der betrachteten Prozesse ab. Für einen abgegrenzten Bereich im Mittelstand sind wenige Wochen realistisch, für eine unternehmensweite Analyse über mehrere Abteilungen entsprechend länger. Wichtiger als die reine Dauer ist die Vollständigkeit, denn eine gründliche Analyse spart in der Auswahl und Einführung ein Vielfaches der investierten Zeit.
Sollte man Prozesse an die Software anpassen oder umgekehrt?
In der Regel ist es besser, die eigenen Soll-Prozesse an bewährten Standards auszurichten und eine Software zu wählen, die diese Standards gut abbildet, statt die Software umfangreich an gewachsene Sonderwege anzupassen. Jede tiefe Anpassung erhöht Kosten und Komplexität und erschwert künftige Updates. Echte Wettbewerbsvorteile im Prozess können eine Anpassung rechtfertigen, reine Gewohnheiten dagegen selten.
Wer sollte an der Prozessanalyse beteiligt sein?
Entscheidend ist die Einbindung der Menschen, die die Prozesse täglich ausführen, denn sie kennen die realen Abläufe und Ausnahmen. Ergänzt werden sie durch Prozessverantwortliche, die IT und eine Person aus der Führung, die Prioritäten setzt und Entscheidungen absichert. Diese frühe Beteiligung ist zugleich der Beginn des Change Managements, weil die späteren Nutzer von Anfang an mitgestalten.
Wie hängt die Prozessanalyse mit dem Lastenheft zusammen?
Das Lastenheft ist das dokumentierte Ergebnis der Prozessanalyse. In ihm werden die Soll-Prozesse und die daraus abgeleiteten Anforderungen strukturiert und priorisiert festgehalten. Es dient als Grundlage für die Anbieteransprache, für den Vergleich der Lösungen und als Maßstab, an dem sich jede Demo messen lassen muss. Ohne vorherige Prozessanalyse bleibt ein Lastenheft eine bloße Funktionsliste ohne Bezug zu den realen Abläufen.
Wo steht die Prozessanalyse in der IT-Transformation?
Die Prozessanalyse ist die zweite Stufe der IT-Transformation, zwischen der Strategie und der eigentlichen Software-Auswahl. Sie übersetzt das strategische Zielbild in konkrete Soll-Prozesse und Anforderungen und bildet damit das Bindeglied, ohne das die Auswahl kein belastbares Fundament hätte. Sie ist zugleich die Stufe, deren Vernachlässigung besonders häufig zu gescheiterten Projekten führt.
Klären Sie die Prozesse, bevor Sie auswählen
Eine saubere Prozessanalyse macht die Auswahl messbar und die Einführung planbar. Starten Sie mit einer neutralen Standortbestimmung oder gehen Sie direkt in die strukturierte Auswahl auf Basis realer Projekte.