Warum ganzheitlich vernetzte Systeme trotz Integration an Übergaben scheitern

ERP, CRM, Projektmanagement und Buchhaltung sind miteinander verbunden. Trotzdem bleiben Aufträge liegen, Rückfragen wandern zwischen Abteilungen und Rechnungen werden verspätet gestellt. Das Problem liegt häufig nicht an fehlenden Schnittstellen, sondern an unklaren Verantwortlichkeiten zwischen den beteiligten Teams.

Ganzheitlich vernetzte Systeme funktionieren erst dann als End-to-End-Prozess, wenn neben dem Datenaustausch auch Übergaben, Entscheidungen und Eskalationen verbindlich geregelt sind. Technische Integration stellt Informationen bereit. Sie entscheidet jedoch nicht automatisch, wer einen unvollständigen Auftrag korrigiert, eine blockierte Übergabe freigibt oder widersprüchliche Prioritäten auflöst.

Für Geschäftsleitungen und IT-Verantwortliche in Schweizer KMU bedeutet das: Der nächste Integrationsschritt muss nicht zwingend eine weitere Softwareverbindung sein. Oft bringt es mehr, den gesamten Wertstrom sichtbar zu machen, einen Process Owner mit Entscheidungsrechten auszustatten und die Qualität jeder Übergabe messbar zu gestalten. Erst auf dieser Grundlage lassen sich digitale Workflows wirksam automatisieren.

Warum Integration nichts bringt, wenn niemand den Prozess von Angebot bis Zahlung besitzt

Technische Integration sorgt dafür, dass Daten zwischen Anwendungen ausgetauscht werden. Sie garantiert aber nicht, dass ein Auftrag vollständig, rechtzeitig und korrekt abgeschlossen wird. Fehlt eine Person mit übergreifender Prozessverantwortung, optimiert jede Abteilung ihren eigenen Abschnitt, während Verzögerungen an den Übergängen organisatorisch ungeklärt bleiben.

Betrachten Sie den Wertstrom von der Angebotserstellung bis zum Zahlungseingang: Der Vertrieb erfasst eine Kundenbestellung im CRM. Das ERP übernimmt die Auftragsdaten, das Projektteam meldet die Leistungserbringung und die Buchhaltung erstellt die Rechnung. Jede Anwendung kann technisch korrekt funktionieren, obwohl die Rechnung erst deutlich später verschickt wird.

Der Grund kann eine fehlende Freigabe, ein nicht übermittelter Leistungsnachweis oder ein uneinheitliches Verständnis von «Auftrag abgeschlossen» sein. Die Systeme transportieren Daten, übernehmen aber keine organisatorische Gesamtverantwortung.

In abteilungsorientierten Organisationen besteht genau hier ein struktureller Konflikt: Führungskräfte verantworten Vertrieb, Leistungserbringung oder Finanzen. Der Kundenauftrag durchläuft jedoch alle diese Bereiche. Ob ein Unternehmen bereits eine wirksame übergreifende Prozessverantwortung besitzt, muss deshalb anhand seiner tatsächlichen Entscheidungswege geprüft werden.

Ein End-to-End Process Owner schliesst diese Lücke. Er verantwortet Prozessregeln, Leistungsziele und Verbesserungen über Funktionsgrenzen hinweg, ohne sämtliche beteiligten Mitarbeitenden disziplinarisch führen zu müssen.

Der APQC-Fachbeitrag zu Prozessverantwortung und Entscheidungsrechten beschreibt diese Rolle als zentrale Verantwortungsinstanz für funktionsübergreifende Prozesse. Entscheidungsrechte, Abstimmungen und Eskalationswege müssen dabei ausdrücklich dokumentiert werden.

Ein praktisches Prüfzeichen ist die Frage: Wer muss handeln, wenn ein Auftrag in keiner Abteilung offiziell fehlerhaft ist, der Kunde aber trotzdem keine Rechnung erhält? Kann niemand diese Frage eindeutig beantworten, fehlt möglicherweise End-to-End-Verantwortung.

Eine wirksame Prozessorganisation braucht nicht nur einen Namen für diese Verantwortung, sondern eine Rolle, die Entscheidungen über Abteilungsgrenzen hinweg tatsächlich herbeiführen kann.

Wie etablieren Sie 1 Process Owner pro Wertstrom, ohne Machtkämpfe

Ein Process Owner lässt sich ohne unnötige Kompetenzkonflikte etablieren, wenn seine Rolle ausdrücklich auf den gesamten Wertstrom ausgerichtet wird. Er führt nicht automatisch die beteiligten Abteilungen, sondern entscheidet über gemeinsame Prozessregeln, Übergabeanforderungen und Eskalationen. Voraussetzung sind klar abgegrenzte Entscheidungsrechte und eine sichtbare Unterstützung durch die Geschäftsleitung.

Der häufigste Einführungsfehler besteht darin, einen Process Owner als zusätzliche Führungsebene darzustellen. Abteilungsleitungen befürchten daraufhin, operative Kontrolle abzugeben, während Mitarbeitende eine neue Instanz für Freigaben und Berichte erwarten.

Tatsächlich muss die Rolle anders zugeschnitten sein: Die Fachabteilungen behalten ihre Personalführung und operative Umsetzung. Der Process Owner sorgt dafür, dass die Zusammenarbeit entlang des Wertstroms verbindlich funktioniert.

Für die Einführung eignet sich ein schrittweises Vorgehen:

1. Wertstrom erfassen: Den vollständigen Ablauf vom auslösenden Kundenbedarf bis zum definierten Prozessergebnis dokumentieren.
2. Übergaben identifizieren: Festhalten, wo Informationen, Aufgaben oder Entscheidungen zwischen Organisationseinheiten wechseln.
3. Entscheidungsrechte festlegen: Definieren, welche Standards und Prioritäten der Process Owner eigenständig bestimmen darf und wann eine gemeinsame Entscheidung erforderlich ist.
4. Mandat kommunizieren: Die Geschäftsleitung erläutert die Rolle gegenüber allen beteiligten Abteilungen und bestätigt die Eskalationswege.

Besonders wichtig ist die Ressourcenfrage. Ein Process Owner, der zwar Probleme erkennt, aber weder verbindliche Priorisierungsentscheidungen herbeiführen noch über vereinbarte Verbesserungsressourcen verfügen kann, bleibt eine Koordinationsstelle ohne ausreichende Wirkung.

Die Entscheidungsbefugnisse müssen deshalb realistisch sein. Für grössere Investitionen können weiterhin Geschäftsleitung oder Bereichsleitungen zuständig bleiben. Der Process Owner benötigt aber einen festgelegten Weg, um Konflikte rechtzeitig zur Entscheidung zu bringen.

Auch seine organisatorische Herkunft verdient Aufmerksamkeit. Eine Person aus der IT bringt häufig Systemkenntnisse mit, wird von Fachabteilungen jedoch möglicherweise als technische Kontrollinstanz wahrgenommen. Eine fachliche Führungskraft versteht die operative Wertschöpfung, benötigt aber gegebenenfalls Unterstützung bei Datenflüssen und Systemabhängigkeiten.

Prozessnähe, bereichsübergreifende Glaubwürdigkeit und Entscheidungskompetenz sind daher zweckmässigere Auswahlkriterien als die Zugehörigkeit zu einer bestimmten Abteilung.

Eine kompakte Rollenbeschreibung sollte mindestens Ziel und Grenzen des Wertstroms, Entscheidungsrechte, beteiligte Funktionen, Leistungskennzahlen sowie Budget- und Eskalationsverfahren enthalten. Eine RACI-Matrix kann ergänzend dokumentieren, wer verantwortlich, entscheidungsbefugt, beratend beteiligt oder zu informieren ist.

Ob diese Verantwortung anschliessend zentral oder dezentral organisiert wird, hängt vor allem von der Ähnlichkeit der Wertströme und den Anforderungen der Geschäftsbereiche ab.

Shared Service oder dezentrale Teams: Was passt bei 2 Business Units

Bei zwei Business Units ist ein Shared Service besonders für ähnliche, wiederkehrende Tätigkeiten prüfenswert. Dezentrale Teams eignen sich eher, wenn Kundenanforderungen, Fachentscheidungen oder regulatorische Bedingungen stark voneinander abweichen. Häufig bietet sich ein Hybridmodell an: gemeinsame Prozessstandards und Kennzahlen, kombiniert mit einer geschäftsbereichsnahen Ausführung.

Die Organisationsentscheidung wirkt unmittelbar auf die Übergabequalität. Ein zentraler Shared Service kann Datenformate vereinheitlichen, Prozessvarianten reduzieren und Zuständigkeiten bündeln. Gleichzeitig entsteht eine zusätzliche organisatorische Schnittstelle, wenn die beiden Business Units ihre Aufträge an eine zentrale Einheit übergeben müssen.

Ohne definierte Annahmekriterien, Bearbeitungsprioritäten und Service Levels kann diese Zentralisierung zu neuen Warteschlangen führen. Dann verschwinden Prozessprobleme nicht, sondern verlagern sich an die Grenze zum Shared Service.

Die APQC-Analyse zu Finance Shared Services und Betriebsmodellen beschreibt die Kombination gemeinsamer Unternehmensstandards mit einer angepassten Ausführung in Geschäftsbereichen. Wiederholbare Transaktionen eignen sich besonders für Shared Services, während Aufgaben mit hohem lokalem Abstimmungsbedarf dezentral bleiben können.

Für eine Entscheidung zwischen den Organisationsformen hilft ein Kriterienraster. Die folgende Gegenüberstellung ist eine praktische Entscheidungshilfe und kein allgemeingültiger Wirtschaftlichkeitsnachweis.

Ein hypothetisches Beispiel verdeutlicht die Abwägung: Zwei Geschäftsbereiche bearbeiten ähnliche Kundenaufträge, unterscheiden sich aber in der technischen Projektabwicklung. Die Stammdatenprüfung und Rechnungsverarbeitung könnten gemeinsamen Regeln folgen, während die fachliche Leistungsfreigabe bei den jeweiligen Business Units bleibt.

Der Process Owner definiert in diesem Modell die übergreifenden Übergabekriterien. Beide Einheiten verpflichten sich auf dieselben Statusdefinitionen, obwohl sie bestimmte Schritte unterschiedlich ausführen.

Ein Hybridmodell ist jedoch nicht automatisch überlegen. Wenn Daten, Verantwortlichkeiten oder Prioritäten uneinheitlich bleiben, kann es die organisatorische Komplexität sogar erhöhen. Die endgültige Wahl sollte daher anhand des tatsächlichen Prozessvolumens, der regulatorischen Anforderungen und der gemessenen Übergabeprobleme erfolgen.

Unabhängig vom Organisationsmodell bleibt eine zentrale Frage bestehen: Wann darf ein Team eine Aufgabe als abgeschlossen übergeben, und unter welchen Bedingungen muss das nächste Team sie übernehmen?

Der End-to-End-Fehler, der 3 Abteilungen zu Ticket-Pingpong zwingt

Ticket-Pingpong entsteht, wenn Abteilungen ihre eigenen Arbeitsschritte korrekt abschliessen, aber keine gemeinsamen Regeln für die Übergabe existieren. Ein Ticket gilt im sendenden Team als erledigt und im empfangenden Team als unvollständig. Ohne einheitliche Annahmekriterien, gemeinsamen Prozessstatus und geregelte Eskalation wandert der Vorgang zwischen Zuständigkeiten hin und her.

Stellen Sie sich einen hypothetischen Kundenauftrag vor, an dem Vertrieb, Projektabwicklung und Buchhaltung beteiligt sind. Der Vertrieb markiert den Auftrag als abgeschlossen. Die Projektabwicklung vermisst eine technische Spezifikation und schickt ihn zurück. Nach einer Ergänzung wird der Auftrag erneut weitergegeben, doch später fehlt der Buchhaltung ein eindeutig zugeordneter Leistungsnachweis.

Alle drei Abteilungen können sich auf ihren jeweiligen Systemstand berufen. Trotzdem ist der Gesamtprozess blockiert, weil niemand verbindlich festgelegt hat, welche Informationen an welchem Übergabepunkt vollständig vorliegen müssen.

Drei Ursachen sind besonders relevant:

• Fehlende Übergabekriterien: Das empfangende Team erkennt erst nach der Übernahme, welche Informationen fehlen. Rückfragen und Nacharbeit verlängern den Vorgang.
• Fehlende gemeinsame Statussicht: Jede Abteilung sieht ihren lokalen Bearbeitungsstand, aber niemand erkennt zuverlässig den Zustand des gesamten Auftrags.
• Fehlende Eskalationsregeln: Bei widersprüchlichen Anforderungen wird das Ticket wiederholt zurückgeschickt, statt eine verbindliche Entscheidung einzuholen.

Die Korrektur beginnt mit einer Definition of Done für jede relevante Übergabe. Diese legt fest, welche Ergebnisse, Nachweise und Daten vorhanden sein müssen, damit das nächste Team den Prozessschritt übernehmen kann.

Für die Übergabe vom Vertrieb an die Projektabwicklung könnten beispielsweise eine bestätigte Bestellung, der vereinbarte Leistungsumfang, ein zugeordneter Kundenkontakt und offene Ausnahmen dokumentiert sein. Welche Felder erforderlich sind, muss das Unternehmen anhand seines tatsächlichen Prozesses bestimmen.

Ein zusätzlicher Akzeptanztest kann die Übergabe absichern: Das empfangende Team bestätigt die definierten Kriterien oder dokumentiert konkret, welches Kriterium nicht erfüllt ist. Eine Ablehnung ohne nachvollziehbare Begründung sollte durch die vereinbarten Prozessregeln ausgeschlossen werden. Bei Uneinigkeit greift der festgelegte Eskalationsweg.

Die britische Behördenanleitung zu Übergaben zwischen digitalen Diensten betont vereinbarte Übergabepunkte, eindeutige Zuständigkeiten, einheitliche Begriffe und Statusmeldungen. Die Grundsätze stammen aus der Gestaltung öffentlicher digitaler Dienste, lassen sich jedoch als Orientierung für betriebliche Schnittstellen verwenden.

Zusätzlich benötigt jeder Auftrag eine gemeinsam zugängliche Statusinformation. Eine durchgängige Auftrags-ID ermöglicht die Zuordnung zwischen Systemen; der Prozessstatus muss erkennen lassen, welches Team gerade verantwortlich ist, was als Nächstes geschieht und ob eine Blockade vorliegt.

Die dafür notwendigen Daten können weiterhin in verschiedenen Anwendungen liegen. Entscheidend ist, dass der abgestimmte Prozesszustand nicht nur in einer privaten Ticketansicht oder persönlichen E-Mail-Korrespondenz existiert.

Ob diese Regeln tatsächlich wirken, zeigt sich anschliessend nicht an der Anzahl geschlossener Tickets, sondern an den Wartezeiten, Rückläufen und der gesamten Prozessdauer.

Welche 3 Übergabe-Metriken zeigen, wo Ihr Prozess wirklich reisst

Drei Kennzahlen machen kritische Übergabepunkte sichtbar: die Wartezeit bis zum Bearbeitungsbeginn, die Rücklaufquote abgelehnter Übergaben und die Durchlaufzeit einzelner Prozessabschnitte im Verhältnis zur Gesamtdauer. Zusammen zeigen sie, ob Verzögerungen durch fehlende Kapazität, unklare Annahmekriterien oder ungünstige Prozessstrukturen entstehen können.

Die Kennzahlen sollten auf Ebene konkreter Auftragsarten erhoben werden. Eine einfache Bestellung und ein komplexes Kundenprojekt unterscheiden sich in ihren Abläufen. Ihre Zeiten unbereinigt miteinander zu vergleichen, kann zu falschen Schlussfolgerungen führen.

1. Wartezeit nach der Übergabe

Diese Kennzahl misst die Zeit zwischen der Bereitstellung eines Auftrags für das nächste Team und dessen tatsächlichem Bearbeitungsbeginn. Sie hilft zu erkennen, ob Aufgaben in Warteschlangen liegen bleiben.

Für die Erfassung werden mindestens zwei Zeitstempel benötigt: «Zur Übernahme bereit» und «Bearbeitung begonnen». Liegen diese Ereignisse bereits im Ticket- oder ERP-System vor, lassen sich historische Fälle auswerten.

Eine auffällige Wartezeit weist auf einen möglichen Engpass hin. Sie beweist für sich allein jedoch noch kein Kapazitätsproblem: Auch unklare Prioritäten, geplante Bearbeitungsfenster oder fehlende Freigaben können eine Rolle spielen.

2. Rücklaufquote bei Übergaben

Die Rücklaufquote beschreibt, welcher Anteil der übergebenen Vorgänge wegen nicht erfüllter Annahmekriterien zurückgegeben wird.

Rücklaufquote = Anzahl zurückgewiesener Übergaben / Anzahl aller geprüften Übergaben × 100.

Vor der Berechnung muss feststehen, ob die Kennzahl einzelne Übergabeversuche oder eindeutige Aufträge betrachtet. Wiederholte Rückgaben desselben Auftrags beeinflussen diese beiden Betrachtungen unterschiedlich.

Zusätzlich sollten Rückgabegründe dokumentiert werden. Eine hohe Quote kann auf unklare Übergabekriterien, fehlende Daten oder tatsächliche Qualitätsmängel hinweisen. Die Zahl allein erlaubt keine eindeutige Schuldzuweisung.

3. Durchlaufzeit pro Prozessabschnitt

Die abschnittsbezogene Durchlaufzeit misst die Zeit vom definierten Beginn bis zum Ende eines Prozessschritts. Wird sie der gesamten Durchlaufzeit gegenübergestellt, lässt sich erkennen, welche Schritte besonders stark zum Zeitbedarf beitragen.

Wichtig ist die Trennung von aktiver Bearbeitungszeit und Wartezeit. Ein Abschnitt kann lange dauern, obwohl die tatsächliche Arbeit nur einen kleinen Teil davon ausmacht. Bei parallelen Aktivitäten dürfen Abschnittszeiten zudem nicht unkritisch addiert werden.

Für eine belastbare Ausgangsbasis sollten mehrere vergleichbare Aufträge mit einheitlichen Start- und Endereignissen ausgewertet werden. Neben dem Durchschnitt kann der Median helfen, typische Verläufe von einzelnen stark verzögerten Fällen zu unterscheiden. Starre Grenzwerte sind ohne Kenntnis der Auftragsarten und Kapazitäten nicht sinnvoll.

Die Messung sollte regelmässig mit den beteiligten Teams besprochen werden. Der Process Owner nutzt die Ergebnisse zur Priorisierung, nicht zur isolierten Leistungsbewertung einzelner Abteilungen.

Ein besonders wichtiger Analysebereich sind Medienbrüche, bei denen Informationen nicht nur übergeben, sondern zwischen Werkzeugen manuell übertragen oder erneut gesucht werden müssen.

Warum Medienbrüche pro Auftrag Ihre Durchlaufzeit belasten können

Medienbrüche können die Durchlaufzeit verlängern, weil Informationen zwischen Anwendungen oder Kommunikationskanälen manuell übertragen, geprüft und gegebenenfalls korrigiert werden müssen. Zusätzlich entstehen Wartezeiten, wenn Angaben fehlen oder Rückfragen nötig werden. Wie gross der Effekt ist, hängt von der Auftragskomplexität, der Fehleranfälligkeit und den tatsächlichen Abläufen ab.

Ein typischer Ablauf in einem KMU könnte so aussehen: Das Angebot wird in Word erstellt, der bestätigte Auftrag im ERP erfasst, projektbezogene Änderungen per E-Mail abgestimmt und die Rechnung in einer separaten Buchhaltungslösung vorbereitet.

Diese Werkzeuglandschaft muss nicht grundsätzlich ungeeignet sein. Kritisch wird sie, wenn dieselben Informationen mehrfach eingegeben werden oder der gültige Datenstand nicht eindeutig erkennbar ist.

Beispielsweise kann eine nachträglich vereinbarte Leistungsänderung im E-Mail-Verkehr dokumentiert sein, während ERP und Rechnungsstellung weiterhin auf ursprüngliche Angaben zugreifen. Die Korrektur erfolgt dann erst, wenn jemand den Widerspruch entdeckt.

Ein Medienbruch verursacht dabei nicht nur zusätzlichen Erfassungsaufwand. Auch die Nachvollziehbarkeit leidet, wenn Entscheidungen, Datenänderungen und Freigaben über mehrere Dokumente und Nachrichten verteilt sind.

Das Schweizer KMU-Portal zur schrittweisen Digitalisierung empfiehlt, vor der Einführung neuer Programme die digitale Reife sowie bestehende Prozesse, Daten und organisatorische Voraussetzungen zu analysieren. Die Quelle liefert jedoch keinen allgemeingültigen Multiplikator für die Verlängerung von Durchlaufzeiten durch Medienbrüche.

Statt von einer pauschalen Verdoppelung der Durchlaufzeit auszugehen, empfiehlt sich eine konkrete Untersuchung:

1. Einen realen, abgeschlossenen Kundenauftrag auswählen.
2. Alle dabei verwendeten Anwendungen, Dateien und Kommunikationskanäle erfassen.
3. Jede erneute Eingabe, Kopie, Suche und manuelle Prüfung markieren.
4. Die dadurch entstandenen Bearbeitungszeiten, Rückfragen und Verzögerungen möglichst anhand vorhandener Zeitstempel nachvollziehen.
5. Die Ergebnisse in einer Medienbruch-Karte mit den jeweiligen Verantwortlichen dokumentieren.

Die Auswertung zeigt, ob eine technische Schnittstelle, eine gemeinsame Datenquelle oder lediglich eine bessere Übergaberegel erforderlich ist.

Nicht jeder Medienbruch erfordert sofort eine vollständige Systemintegration. Wenn beispielsweise eine Freigabeentscheidung fehlt, behebt ein automatisierter Datentransfer die organisatorische Ursache nicht.

Damit Informationen nach ihrer Übertragung auch richtig interpretiert werden, benötigen alle beteiligten Teams zusätzlich ein gemeinsames Verständnis des Prozessstatus.

Wie definieren Sie Statusstufen, die jeder im Team gleich versteht

Verständliche Statusstufen beschreiben überprüfbare Prozesszustände statt subjektiver Arbeitseinschätzungen. Jede Stufe benötigt klare Eintrittskriterien, eine verantwortliche Rolle und eine definierte Konsequenz für den nächsten Schritt. Die Anzahl der Stufen ergibt sich aus den tatsächlichen Übergaben und Kontrollpunkten, nicht aus einer allgemeingültigen Vorgabe.

Bezeichnungen wie «in Arbeit», «abgeklärt» oder «erledigt» erscheinen zunächst eindeutig. In der Praxis kann der Vertrieb unter «erledigt» eine angenommene Bestellung verstehen, während die Projektabwicklung erst nach einer vollständigen technischen Prüfung von einem abgeschlossenen Schritt spricht.

Solche Unterschiede erzeugen Prozessbrüche, selbst wenn alle Systeme denselben Statuswert anzeigen.

Ein guter Status beschreibt deshalb, was nachweislich erreicht wurde und welche Handlung dadurch erlaubt wird. «Kundenauftrag bestätigt, Projektvorbereitung freigegeben» ist aussagekräftiger als «Auftrag bearbeitet».

Als Ausgangspunkt kann das Unternehmen beispielsweise folgende sieben Statusstufen diskutieren. Sie sind ein mögliches Modell, keine normierte Vorgabe:

Das Modell muss an die tatsächliche Leistungserbringung angepasst werden. Nicht jeder Auftrag benötigt beispielsweise eine formale Abnahme. Bei anderen Geschäftsmodellen sind zusätzliche Prüf-, Liefer- oder Teilabrechnungszustände erforderlich.

Wesentlich ist die Unterscheidung zwischen technischer Fertigstellung und prozessualem Abschluss. Ein Datensatz kann erfolgreich übertragen worden sein, obwohl die nächste Abteilung den Auftrag noch nicht vollständig übernehmen kann.

Deshalb sollten Fachabteilungen und IT die Statusdefinitionen gemeinsam erarbeiten. Für jede Stufe wird festgelegt, welche Informationen vorhanden sein müssen, wer den Wechsel auslösen darf und welche Folgeaktionen automatisch oder manuell beginnen.

Zu viele Statusstufen erhöhen den Pflegeaufwand und können dazu führen, dass Mitarbeitende Zustände überspringen. Zu wenige Stufen verdecken hingegen wichtige Übergaben. Eine geeignete Zahl ergibt sich aus den notwendigen Entscheidungen und nicht aus dem Wunsch nach möglichst detailliertem Reporting.

Auch Ausnahmen müssen geregelt sein. Wird eine Übergabe abgelehnt, sollte der Auftrag nicht kommentarlos in einem abgeschlossenen Zustand bleiben. Ein dokumentierter Klärungs- oder Rückgabemechanismus ist erforderlich, ohne dass dafür zwingend eine eigene Statusstufe entstehen muss.

Erst wenn diese Zustände von allen beteiligten Teams einheitlich interpretiert werden, lässt sich ein digitaler Workflow zuverlässig über mehrere Organisationseinheiten hinweg steuern.

Wie optimieren Sie digitale Workflows, wenn 5 Teams an einem Auftrag arbeiten

Wenn fünf Teams an einem Auftrag beteiligt sind, liegt das grösste organisatorische Verbesserungspotenzial häufig an ihren Übergaben. Ein wirksamer digitaler Workflow verbindet klare Zuständigkeiten, überprüfbare Annahmekriterien, gemeinsame Statusinformationen und messbare Prozesszeiten. Erst nach dieser fachlichen Klärung sollten Anwendungen angepasst, Schnittstellen erweitert oder Aufgaben automatisiert werden.

Ein beispielhafter Wertstrom könnte Vertrieb, Auftragsmanagement, Projektabwicklung, Qualitätssicherung und Buchhaltung umfassen. Jedes Team erfüllt eine bestimmte Aufgabe. Das Kundenergebnis entsteht jedoch erst durch den vollständigen Ablauf.

Bei einer einfachen linearen Abfolge von fünf Teams bestehen bereits vier direkte Übergaben. Kommen Rückfragen, Freigaben oder parallele Bearbeitungsschritte hinzu, wächst die Zahl der relevanten Abstimmungspunkte. Genau deshalb reicht es nicht aus, nur die Effizienz einzelner Teams zu erhöhen.

Die Optimierung sollte entlang des Auftragsverlaufs erfolgen:

1. Gesamtprozess visualisieren: Alle beteiligten Teams, Systeme, Aufgaben und Entscheidungen in einer gemeinsamen Prozessdarstellung abbilden. Der Start- und Endpunkt des Wertstroms muss eindeutig sein.
2. Übergaben überprüfen: Für jede Schnittstelle festlegen, welches Team übergibt, welches übernimmt und welche Informationen oder Ergebnisse vorliegen müssen.
3. Verantwortlichkeiten verbindlich machen: Einen Process Owner für den Gesamtprozess bestimmen und lokale Zuständigkeiten sowie Eskalationswege dokumentieren.
4. Status und Messpunkte harmonisieren: Gemeinsam verständliche Prozesszustände und relevante Zeitstempel definieren. Rückgaben und Ausnahmen müssen nachvollziehbar bleiben.
5. Technologie gezielt anpassen: Erst danach entscheiden, welche Daten automatisch synchronisiert, welche Freigaben systemgestützt geprüft und welche manuellen Tätigkeiten vereinfacht werden sollen.

Ein wichtiger Unterschied besteht zwischen Aufgabenautomatisierung und Koordinationsautomatisierung. Eine automatisch erzeugte Folgeaufgabe verbessert den Prozess nur dann, wenn die dafür erforderlichen Informationen vollständig und die Zuständigkeiten eindeutig sind.

Andernfalls wird ein unklarer Übergabeprozess lediglich schneller ausgelöst. Das nächste Team erhält zwar sofort ein Ticket, muss aber weiterhin fehlende Informationen anfordern.

Ebenso sollte die technische Architektur nicht mit der Prozessarchitektur verwechselt werden. Unterschiedliche Systeme können einen funktionierenden End-to-End-Prozess unterstützen, sofern gemeinsame Identifikatoren, Statusinformationen, Verantwortlichkeiten und Datenqualitätsregeln vorhanden sind.

Umgekehrt kann selbst eine einheitliche Plattform an unklaren Verantwortungsgrenzen scheitern.

Für die Umsetzung empfiehlt sich ein begrenzter Pilot mit einem wiederkehrenden Auftragstyp. Der Process Owner wählt anhand der vorhandenen Übergabekennzahlen eine kritische Schnittstelle aus, vereinbart mit den Teams neue Annahmeregeln und lässt diese zunächst im laufenden Betrieb erproben.

Erst wenn die neuen Regeln im Alltag funktionieren, sollten sie im Workflow-System verbindlich abgebildet werden. Anschliessend kann anhand vergleichbarer Aufträge geprüft werden, ob Rückläufe und Wartezeiten tatsächlich zurückgegangen sind.

Die Verbesserung wird dadurch nicht als einmaliges IT-Projekt behandelt, sondern als fortlaufende Aufgabe der Prozessführung. Neue Kundenanforderungen, organisatorische Veränderungen und zusätzliche Anwendungen können spätere Anpassungen erforderlich machen.

Die zuvor beschriebenen Elemente greifen dabei ineinander: Der Process Owner verantwortet den Wertstrom, die Übergabekriterien sichern die Qualität, gemeinsame Statusstufen schaffen Transparenz und Kennzahlen zeigen den tatsächlichen Handlungsbedarf.

Wählen Sie als nächsten Schritt einen häufig durchlaufenen Kundenauftrag aus und zeichnen Sie seinen Weg vom Angebot bis zum Zahlungseingang auf. Markieren Sie jede Abteilungsgrenze, prüfen Sie dort Verantwortlichkeiten und Annahmekriterien und messen Sie die bestehenden Wartezeiten. Daraus entsteht eine konkrete Prioritätenliste für organisatorische und technische Verbesserungen – bevor weitere Integrationen geplant werden.