Prozessanalyse vor dem Softwarekauf: Engpass finden
Prozessanalyse vor dem Softwarekauf: Mit Beobachtung, Übergabe-Karte und Engpass-Check findest du heraus, was wirklich fehlt.
Hinweis zu KI-Inhalten: Bilder und Blogbeiträge auf dieser Website können ganz oder teilweise mit künstlicher Intelligenz erstellt oder bearbeitet sein.
Was bringt eine Prozessanalyse vor dem Softwarekauf?
Eine Prozessanalyse vor dem Softwarekauf zeigt dir, an welcher Stelle ein Vorgang tatsächlich liegen bleibt, bevor du eine Funktionsliste vergleichst. Ohne sie kaufst du oft ein Werkzeug für ein Symptom und nicht für die Ursache. Die Analyse braucht keine teure Beratung. Sie braucht eine echte Beobachtung des Ablaufs, eine Übergabe-Karte und eine klare Antwort auf die Frage, wo die Arbeit wartet.
Dieser Beitrag zeigt eine praktische Methode dafür: den Ablauf beobachten, Übergaben aufzeichnen, den Engpass benennen und erst danach entscheiden, ob Standardsoftware reicht oder mehr nötig ist.
Den Ablauf beobachten, bevor du irgendetwas vergleichst
Der häufigste Fehler vor einem Softwarekauf ist, direkt mit Demos zu starten. Eine Demo zeigt, was ein Produkt kann. Sie zeigt nicht, ob dein Betrieb dieses Können überhaupt braucht. Beobachte deshalb zuerst einen echten, wiederkehrenden Vorgang von Anfang bis Ende, am besten an einem normalen Arbeitstag und nicht an einem ruhigen.
Frag dabei nicht „Wie würden wir das gerne machen?“, sondern „Wie läuft es heute tatsächlich ab, mit allen Umwegen?“ Notiere jeden Schritt, jede Person, jedes Programm und jede Wartezeit. Eine einfache Tabelle reicht: Schritt, ausführende Person, genutztes Programm, Dauer, Wartezeit bis zum nächsten Schritt. Schon diese Liste macht sichtbar, wo eine Aufgabe zwischen zwei Zuständigkeiten hin- und herwandert.
Beobachte mindestens drei bis fünf konkrete Fälle, nicht nur den Idealfall. Ein Vorgang mit einer fehlenden Angabe, einer Rückfrage oder einer Änderung zeigt oft mehr über den echten Engpass als ein reibungsloser Durchlauf.
Übergaben sichtbar machen: die Landkarte des Vorgangs
Ein Vorgang bricht selten mitten in einem Programm. Er bricht an der Übergabe zwischen zwei Programmen oder zwei Personen. Deshalb lohnt sich eine einfache Übergabe-Karte, die genau diese Punkte zeigt.
| Übergabe | Von | An | Woran es hakt |
|---|---|---|---|
| Anfrage → Erfassung | Postfach | Tabelle oder Programm | Angaben fehlen, Zweitablage entsteht |
| Erfassung → Zuständigkeit | Tabelle | Person oder Team | Unklar, wer den Fall übernimmt |
| Zuständigkeit → Ergebnis | Person | Kunde oder Auftragsprogramm | Status wird nicht zurückgemeldet |
| Ergebnis → Abschluss | Auftragsprogramm | Rechnung oder Archiv | Doppelte Erfassung derselben Daten |
Trage für deinen eigenen Ablauf ein, wo eine Information das System wechselt. An jeder Übergabe lohnt sich die Frage: Wird hier etwas erneut eingetippt? Wartet der Vorgang hier auf eine Person, die gerade woanders beschäftigt ist? Gibt es hier zwei unterschiedliche „Wahrheiten“ über denselben Fall? Diese drei Fragen decken die meisten Engpässe ab, ohne dass du ein einziges Software-Angebot gesehen haben musst.
Den echten Engpass von einem lauten Symptom unterscheiden
Nicht jede Beschwerde zeigt den eigentlichen Engpass. „Wir brauchen ein besseres CRM“ ist ein Symptom. Der Engpass kann stattdessen sein, dass niemand eine Anfrage eindeutig einer Person zuordnet, oder dass eine Information erst nach zwei Tagen im richtigen Programm ankommt. Miss deshalb, wo die Zeit wirklich verloren geht:
- Wie lange liegt ein Vorgang, ohne dass jemand daran arbeitet?
- Wie oft wird dieselbe Angabe an zwei Stellen erfasst?
- Wie oft führt eine fehlende Information zu einer Rückfrage?
- Wie oft entsteht eine Verwechslung, weil zwei Personen gleichzeitig am selben Fall arbeiten?
Der Engpass ist meistens die Stelle mit der höchsten Kombination aus Häufigkeit und Wartezeit, nicht die Stelle, über die am lautesten geklagt wird. Eine seltene, aber immer wieder erwähnte Ausnahme kostet oft weniger als eine leise, aber ständige Verzögerung an einer unscheinbaren Übergabe.
Wann Standardsoftware reicht und wann nicht
Erst wenn der Engpass klar benannt ist, lohnt sich der Blick auf mögliche Lösungen. Häufig deckt eine vorhandene oder neue Standardsoftware den Engpass bereits ab, wenn die Einrichtung und Schulung stimmen. Manchmal fehlt nur eine Schnittstelle zwischen zwei bereits genutzten Programmen. Seltener braucht ein Ablauf eine eigene Anwendung, weil er dauerhaft in kein vorhandenes Werkzeug passt.
Diese Entscheidung mit ihren jeweiligen Prüfpunkten haben wir bereits ausführlich beschrieben, damit sie hier nicht wiederholt werden muss: Standardsoftware, Schnittstelle oder Individualentwicklung? Nimm deine Übergabe-Karte und deinen benannten Engpass mit in diese Entscheidung. Ohne sie bleibt jede Einordnung eine Vermutung.
Typische Fehler, die eine Prozessanalyse verzerren
Auch eine gut gemeinte Analyse kann in die Irre führen. Achte auf diese vier Fallen:
- Nur die Führungsperspektive fragen. Wer den Ablauf beschreibt, ohne ihn selbst zu machen, übersieht oft genau die Umwege, die den Engpass ausmachen. Sprich mit den Personen, die den Vorgang täglich bearbeiten.
- Nur den Idealfall dokumentieren. Der reibungslose Durchlauf sagt wenig über den Engpass. Die Ausnahme mit fehlender Angabe oder Rückfrage zeigt ihn meistens deutlicher.
- Zu früh eine Lösung mitdenken. Wenn du beim Beobachten schon an ein bestimmtes Produkt denkst, filterst du unbewusst nach passenden Symptomen. Trenne Beobachtung und Lösungssuche zeitlich.
- Die Ausnahme verschweigen, weil sie selten ist. Eine Ausnahme, die einmal im Monat auftritt, aber jedes Mal einen ganzen Tag kostet, kann teurer sein als ein tägliches, kleines Ärgernis.
Wenn du diese vier Fallen im Blick behältst, bleibt deine Übergabe-Karte belastbar genug für die nächste Entscheidung.
Die Anfrage vorbereiten, bevor du Angebote holst
Wenn du danach ein Angebot einholst, gib nicht nur einen Wunsch weiter. Gib den beobachteten Ablauf weiter: den Auslöser, die beteiligten Programme, die Übergabe-Karte, den benannten Engpass und mindestens drei konkrete Beispielfälle mit anonymisierten Daten. Ein Anbieter, der diese Angaben bekommt, kann viel gezielter sagen, ob eine Standardlösung, eine Integration oder eine kleine eigene Anwendung passt.
Frag außerdem, wie ein Anbieter dieselben Testfälle behandeln würde, die deine Beobachtung aufgedeckt hat, etwa eine fehlende Pflichtangabe oder eine Änderung nach der ersten Erfassung. Eine überzeugende Demo mit erfundenen Idealdaten sagt wenig darüber, ob dein tatsächlicher Engpass gelöst wird.
Bei n3tz beginnen wir jedes Gespräch über Software, Integration und Prozessoptimierung mit genau dieser Beobachtung. Ein Produktname ersetzt keine Klärung, wo die Arbeit heute tatsächlich hängen bleibt. Wenn eine bestehende Systemlandschaft die Ursache ist, hilft außerdem unser Beitrag zum Verbinden von Systemen im Mittelstand.
Engpass beschreiben, bevor du ein Angebot einholst: Ablauf mit n3tz besprechen →
Tarik Ermis ist Software-Architekt und Gründer von n3tz in Saarbrücken. Er entwickelt Unternehmenssoftware, verbindet bestehende Systeme und begleitet Lösungen bis zum laufenden Betrieb.