ProzessunterstützungWie die Automatisierung von Prozessen erfolgreich ist

Was am Beginn der Entscheidung zur Prozessautomatisierung steht

Wer einen betrieblichen Ablauf automatisieren will, sollte nicht mit einer Produktdemo beginnen. Zuerst muss klar sein,

• welches Ergebnis der Prozess liefern soll,
• wo Informationen übergeben werden,
• welche Ausnahmen auftreten und
• welche Fehler nicht passieren dürfen.

Danach lässt sich sinnvoll entscheiden:

• Reicht Standardsoftware,
• braucht es eine individuelle Lösung oder
• ist der Prozess noch nicht entscheidungsreif?

Die folgende Methode verbindet eine kompakte Prozesskarte mit einem Bewertungsraster. Sie ist für einen konkreten Ablauf gedacht, nicht für das gesamte Unternehmen.

Das Ergebnis ist keine mathematische Wahrheit, sondern eine dokumentierte Entscheidung mit sichtbaren Annahmen, offenen Punkten und einem nächsten Prüfschritt.

Mit einem echten Vorgang statt mit einer Wunschliste beginnen

Wählen Sie einen wiederkehrenden Vorgang, der heute Zeit kostet, Rückfragen erzeugt oder vom Wissen einzelner Personen abhängt. Geeignet sind zum Beispiel

• die Bearbeitung einer Kundenanfrage,
• die Freigabe eines Angebots,
• die Übergabe an die Fertigung oder
• die Erfassung eines Serviceeinsatzes.

Beschreiben Sie einen realen Fall vom Auslöser bis zum Ergebnis.

Vermeiden Sie zunächst allgemeine Ziele wie Digitalisierung, mehr KI oder weniger Handarbeit. Solche Ziele geben keine Systemgrenze vor.

Ein prüfbares Ziel lautet beispielsweise: Eine vollständige Anfrage soll innerhalb von zehn Minuten als bearbeitbarer Vorgang vorliegen; unvollständige oder riskante Fälle werden sichtbar an eine verantwortliche Person übergeben.

Damit ist zugleich festgelegt, was nicht zum ersten Schritt gehört. Eine Automatisierung muss nicht sofort den gesamten Angebots-, Auftrags- und Abrechnungsprozess abdecken.

Ein klarer Ausschnitt lässt sich schneller prüfen und schützt davor, ungeklärte Arbeit lediglich in Software zu verlagern.

Die Prozesskarte in sechs Schritten erstellen

Für die Prozesskarte genügt zunächst eine Seite. Arbeiten Sie mit den Personen, die den Ablauf täglich ausführen.

Die offizielle Prozessbeschreibung reicht nicht; entscheidend sind die tatsächlich genutzten Listen, E-Mails, Rückfragen und Umwege.

Ergebnis und Grenze festlegen

Beschreiben Sie das Ergebnis als beobachtbaren Zustand. Ein Datensatz wurde vollständig angelegt, ein Angebot wurde fachlich freigegeben oder ein Einsatzbericht ist abrechenbar.

Ergänzen Sie eine Grenze: Welche Vor- und Nacharbeiten bleiben außerhalb der ersten Entscheidung? So wird aus einem unbestimmten Digitalprojekt ein begrenzbarer Arbeitsauftrag.

Übergaben sichtbar machen

Viele Probleme entstehen nicht innerhalb eines Arbeitsschritts, sondern beim Wechsel zwischen Postfach, Tabelle, Fachsystem und Mitarbeiter. Notieren Sie bei jeder Übergabe:

• Quelle
• Empfänger
• Format
• Wartezeit
• Rückfragen

Wenn dieselben Angaben mehrfach übertragen oder geprüft werden, liegt dort häufig der wirksamste Ansatzpunkt.

Ausnahmen vor dem Normalfall prüfen

Ein Ablauf mit vielen Ausnahmen ist nicht automatisch ungeeignet. Die Ausnahmen müssen jedoch benannt und kontrolliert werden.

Ordnen Sie jeden Sonderfall einer von drei Gruppen zu:

• automatisch bearbeitbar,
• durch das System vorbereitbar oder
• zwingend durch einen Menschen zu entscheiden.

Unbekannte Ausnahmen brauchen einen sicheren Haltepunkt statt einer geratenen Aktion.

Daten und Verantwortung klären

Erfassen Sie nicht nur Datenfelder, sondern auch deren Herkunft und Pflege:

• Welches System führt die Kundennummer?
• Wer darf einen Preis ändern?
• Wie wird eine neue Version erkannt?

Wenn zwei Systeme unterschiedliche Wahrheiten enthalten, löst eine zusätzliche Automatisierung das Problem nicht. Sie beschleunigt allenfalls den Konflikt.

Freigaben und Fehlerfolgen bestimmen

Je höher die Fehlerkosten, desto klarer müssen Freigabe und Rückfallweg sein. Eine falsche interne Kategorie ist anders zu behandeln als eine falsche Lieferzusage, Zahlung oder sicherheitsrelevante Entscheidung.

Legen Sie fest,

• welche Aktion vorbereitet werden darf,
• wer sie auslöst und
• wie ein Vorgang gestoppt oder manuell fortgeführt wird.

Vor der Bewertung Knock-out-Kriterien prüfen

Ein Bewertungsraster ist nutzlos, wenn grundlegende Voraussetzungen fehlen. Unterbrechen Sie die Produktauswahl, sobald einer der folgenden Punkte zutrifft:

• Für den Prozess gibt es kein eindeutig verantwortliches Team oder keine verantwortliche Person.
• Das gewünschte Ergebnis lässt sich nicht an einem realen Fall zeigen.
• Zentrale Eingangsdaten fehlen regelmäßig oder dürfen nicht verwendet werden.
• Die wichtigsten Ausnahmen und Freigaben sind zwischen den Beteiligten strittig.
• Es gibt keine Möglichkeit, Fehler zu erkennen, anzuhalten und manuell zu bearbeiten.
• Der erwartete Nutzen ist kleiner als Einführung, Betrieb und Änderungsaufwand.

In diesen Fällen ist der nächste Schritt keine Softwareentscheidung. Zuerst werden Ziel, Rollen, Daten oder Regeln geklärt. Das kann in einem strukturierten Workshop geschehen, aber auch intern.

Wichtig ist das Ergebnis: eine entscheidbare Prozessbeschreibung, nicht eine Sammlung weiterer Ideen.

Das Bewertungsraster anwenden

Bewerten Sie jede Dimension mit 0, 1 oder 2 Punkten:

• 0 bedeutet ungeklärt oder ungünstig
• 1 bedeutet teilweise geklärt
• 2 bedeutet belastbar oder günstig

Tragen Sie hinter jedem Wert einen Beleg oder eine offene Annahme ein. Ein Punkt ohne Begründung darf die Entscheidung nicht tragen.

Die Punktzahl allein entscheidet nicht. Die Richtung entsteht aus dem Muster der Bewertungen:

Wann Standardsoftware kaufen sinnvoll ist

Kaufen oder konfigurieren Sie Standardsoftware, wenn

• der Prozess marktüblich ist,
• die Besonderheiten gering sind und
• das Produkt die erforderlichen Daten, Rollen und Schnittstellen vorgesehen unterstützt.

Prüfen Sie den Ablauf mit realen Fällen. Eine lange Funktionsliste ist kein Nachweis dafür, dass Übergaben, Freigaben und Betrieb passen.

Wann individuelle Entwicklung sinnvoll ist

Entwickeln Sie individuell, wenn der Ablauf für Leistung, Geschwindigkeit oder Kundenbeziehung wichtig ist und Standardprodukte ihn nur mit dauerhaften Umwegen abbilden würden. Voraussetzung sind

• ein ausreichend klarer Prozess,
• verfügbare Daten,
• ein verantwortlicher Eigentümer und
• ein tragfähiges Betriebsmodell.

Eigener Code ist kein Ersatz für ungeklärte Entscheidungen.

Wann zuerst ein Workshop oder eine Klärungsphase nötig ist

Klären Sie zuerst, wenn Prozessklarheit, Datenreife, Fehlerbeherrschung oder Betriebsfähigkeit niedrig bewertet sind. Die Klärungsphase sollte konkrete Ergebnisse liefern:

• Prozesskarte
• offene Entscheidungen
• Datenbedarf
• Verantwortlichkeiten
• Zielkennzahlen
• einen kleinsten prüfbaren Anwendungsfall

Sie endet mit Buy, Build, Hybrid oder bewusstem Stop.

Wann eine Mischlösung die bessere Grenze zieht

Oft ist weder reines Kaufen noch vollständiges Eigenentwickeln sinnvoll. Standardsoftware übernimmt marktübliche Funktionen wie Kontakte, Benutzerverwaltung oder Buchhaltung.

Eine individuelle Schicht bildet nur den begründeten besonderen Ablauf oder verbindet vorhandene Systeme. Entscheidend ist, welches System für jedes Datenobjekt und jede Regel verantwortlich bleibt.

Wann Nichtstun die richtige Entscheidung ist

Automatisieren Sie nicht, wenn der Vorgang selten ist, sich kurzfristig stark verändert oder der Fehler eines automatisierten Schritts teurer wäre als die heutige Handarbeit.

Auch eine organisatorische Änderung kann ausreichen: Pflichtangaben vereinheitlichen, Verantwortung klären oder eine unnötige Übergabe entfernen.

Ein guter Auswahlprozess darf ausdrücklich ohne Softwareprojekt enden.

Ein Beispiel aus dem Serviceprozess

Ein mittelständisches Unternehmen erhält Serviceanfragen per Telefon, E-Mail und Webformular.

Heute überträgt ein Mitarbeiter Kontaktdaten und Anliegen in eine Tabelle, sucht Vertragsinformationen im Fachsystem und verteilt den Vorgang per E‑Mail. Rückfragen entstehen, weil Seriennummer, Standort oder Dringlichkeit fehlen.

Die Prozesskarte zeigt:

• Das gewünschte Ergebnis ist ein vollständiger, priorisierter Servicevorgang.
• Die Übergaben zwischen Postfach, Tabelle und Fachsystem verursachen Liegezeit.
• Häufige Ausnahmen sind unklare Geräte und Sicherheitsmeldungen.
• Vertragsstatus und Stammdaten liegen im Fachsystem.
• Priorität und Terminzusage müssen freigegeben werden.
• Eine falsche Einstufung kann Kundenstillstand verursachen.

Das Raster führt nicht automatisch zu einer einzigen Lösung:

• Ist das vorhandene Fachsystem konfigurierbar und unterstützt alle Eingangskanäle, spricht viel für Buy.
• Fehlt nur die strukturierte Annahme, kann ein begrenztes eigenes Portal oder eine Integrationsschicht sinnvoll sein.
• Sind Dringlichkeit, Verantwortlichkeit und Pflichtdaten noch strittig, beginnt das Vorhaben mit einer Klärungsphase.

Der besondere Teil kann später individuell umgesetzt werden, während das Fachsystem führend bleibt.

Die Entscheidung mit einem kleinen Piloten absichern

Bevor Sie einen großen Vertrag schließen oder umfangreich entwickeln, prüfen Sie die Entscheidung an einem begrenzten Ausschnitt. Der Pilot umfasst echte Fälle, aber keine unnötig riskanten Aktionen.

Messen Sie vor und nach dem Versuch dieselben Werte:

• Bearbeitungszeit
• gesamte Durchlaufzeit
• Rückfragen
• Fehler
• offene Vorgänge
• manuelle Übergaben

Definieren Sie außerdem ein Stoppsignal. Der Pilot wird beendet oder neu geschnitten, wenn Datenqualität, Fehlerquote, Betriebskosten oder Akzeptanz die vereinbarten Grenzen überschreiten.

Damit ist ein Pilot keine Demo, sondern ein kontrollierter Test der fachlichen und wirtschaftlichen Annahmen.

Dokumentieren Sie am Ende nicht nur die technische Funktion. Halten Sie fest,

• wer Regeln ändern darf,
• wie Störungen erkannt werden,
• wie der manuelle Ersatzprozess funktioniert und
• welche Daten exportiert werden können.

Diese Fragen entscheiden darüber, ob die Lösung nach dem Projekt tragfähig bleibt.

Typische Fehler bei der Auswahl vermeiden

Das Werkzeug steht vor dem Problem fest. Dann wird der Prozess passend zur Demo beschrieben. Vergleichen Sie Optionen erst nach der Prozesskarte.

Der offizielle Ablauf wird mit dem realen Ablauf verwechselt. Beziehen Sie die Personen ein, die Rückfragen, Ausnahmen und Korrekturen täglich bearbeiten.

Jede Besonderheit gilt als Differenzierung. Prüfen Sie, ob ein Sonderweg Kunden oder Ergebnis wirklich verbessert oder nur historisch gewachsen ist.

Nur Einführungskosten werden verglichen. Berücksichtigen Sie Integration, Datenbereinigung, Betrieb, Änderungen, Schulung und einen späteren Ausstieg.

KI wird als eigene Lösungsart behandelt. KI kann Bestandteil von Standardsoftware oder individueller Entwicklung sein. Sie ersetzt weder Prozessgrenze noch Freigabe und Verantwortung.

Fazit

Die Wahl zwischen Standardsoftware, individueller Entwicklung und einer vorgelagerten Klärungsphase beginnt nicht beim Anbieter. Sie beginnt mit einem konkreten Prozess.

Ergebnis, Übergaben, Ausnahmen, Daten, Freigaben und Fehlerkosten machen sichtbar, was überhaupt entschieden werden kann.

Das Bewertungsraster strukturiert anschließend die Diskussion. Ein marktüblicher Ablauf mit passendem Produkt spricht für Buy. Ein wichtiger eigener Ablauf mit klarer Verantwortung kann Build rechtfertigen. Ungeklärte Prozesse brauchen zuerst eine Klärungsphase.

Häufig ist eine Mischlösung richtig. Und manchmal ist die beste Entscheidung, vorerst keine Software zu bauen.