POC-SIP — Die SIPOC-Variante für Prozessverknüpfungen

Wer mit SIPOC arbeitet, kennt das Gefühl: Auf einer Seite stehen Supplier, Input, Process, Output und Customer — und für einen einzelnen Prozess ist sofort klar, woher etwas kommt und wohin es geht. Sobald aber zehn solcher SIPOC-Diagramme nebeneinanderliegen, fängt das Suchen an. Welcher Output landet eigentlich wirklich bei welchem nachgelagerten Prozess? Wo bleibt der Input aus, den jemand erwartet? Genau hier setzt POC-SIP an: Es nimmt SIPOC nicht weg, sondern dreht den Blick und macht die Übergaben zwischen Prozessen sichtbar.

Was POC-SIP von SIPOC unterscheidet

SIPOC schaut auf einen Prozess und beschreibt, was an den Rändern passiert. POC-SIP zerlegt diese Sicht in zwei Hälften und stellt sie nebeneinander: Auf der POC-Seite stehen Process, Output und Customer-Process — also: Was geht aus meinem Prozess heraus und welcher Prozess soll es empfangen? Auf der SIP-Seite stehen Supplier-Process, Input und Process — also: Welcher Prozess liefert mir etwas und welcher Input wird daraus?

Die Reihenfolge ist kein Zufall. Wer einen Prozess für sich modelliert, neigt zur Innenperspektive — Aktivitäten, Verzweigungen, Gateways. POC-SIP zwingt zum Schritt zurück: Welches Geschäftsobjekt verlasse ich, welches erwarte ich, und stimmen meine Annahmen mit denen der angrenzenden Prozesse überein? Das ist ein bewusstes Ablegen der Scheuklappen, weg von der Intra-Prozess-Sicht hin zu einem Verknüpfen von Prozessen.

Schritt für Schritt zum POC-SIP-Graphen

Ein POC-SIP entsteht am besten in vier Schritten — die Wortwahl folgt bewusst der Abbildung:

1. POC-Seite aufbauen. Für jeden Prozess den Ablauf skizzieren, die Outputs aufschreiben und die (erwarteten) Customer-Prozesse notieren. Konkretheit zählt: Statt Vertrieb lieber Auftragsannahme Region Süd, statt Bestätigung lieber freigegebener Auftrag.
2. SIP-Seite aufbauen. Für jeden Prozess den Ablauf skizzieren, die Inputs aufschreiben und die (erwarteten) Supplier-Prozesse notieren. Auch hier zählt das Objekt, nicht die Tätigkeit.
3. Customer-Supplier-Mapping durchführen. Jedes Customer-Output mit dem korrespondierenden Supplier-Input über die Prozessgrenzen hinweg verknüpfen. Ein Pfeil pro Verbindung — nicht mehr, nicht weniger.
4. (Mis-)matches identifizieren. Wo Output und Input zueinanderpassen, ist die Schnittstelle gelebt. Wo Outputs ohne Empfänger bleiben oder Inputs ohne Lieferanten erwartet werden, liegt ein Verbesserungsangriffspunkt offen.

Match oder Mismatch — was die Verknüpfungen erzählen

Ein Match bedeutet: Ein Output ist auf der gegenüberliegenden Seite tatsächlich als Input registriert, und der erwartete Supplier-Prozess ist auch der reale Lieferant. Die Schnittstelle existiert nicht nur in einem Modell, sondern wird zwischen zwei Prozessen verstanden und gelebt.

Ein Mismatch hat zwei Varianten. Im ersten Fall produziert ein Prozess einen Output, den niemand abnimmt: ein toter Output, dessen Erzeugung Aufwand kostet, ohne Wirkung zu entfalten. Im zweiten Fall erwartet ein Prozess einen Input, der nicht geliefert wird oder von einem anderen als dem erwarteten Lieferanten kommt: jemand wartet umsonst, oder die Übergabe geschieht über informelle Wege und entzieht sich der Steuerung.

Im Ergebnis-Diagramm ist der grüne Pfeil ein Match: Die Outputs 1 und 2 von Process 1 landen tatsächlich als Inputs in Process 2, und zwar genau dort, wo Process 2 sie erwartet. Der rote Pfeil markiert einen Mismatch: Process 3 erwartet einen Input aus einem Process 4, doch dieser Output existiert in der gesamten Prozesslandschaft nicht — niemand erzeugt ihn. Solche Lücken sieht man in einzelnen SIPOC-Diagrammen praktisch nie. Sie tauchen erst in der Übergabe-Sicht auf, wenn POC- und SIP-Seite über alle Prozesse hinweg miteinander abgeglichen werden.

Worked Example: Auftragsannahme, Auftragsabwicklung, Rechnungsstellung

Ein klassischer Order-to-Cash-Ausschnitt macht das konkret. Drei Prozesse stehen nebeneinander:

• Auftragsannahme prüft Anfragen, klärt Sonderkonditionen und erzeugt einen freigegebenen Auftrag inkl. Sonderkonditionen-Vermerk. Erwarteter Customer: Auftragsabwicklung — und für die Sonderkonditionen zusätzlich Rechnungsstellung.
• Auftragsabwicklung nimmt den Auftrag an, organisiert Versand und erzeugt einen Lieferschein. Erwarteter Customer: Rechnungsstellung.
• Rechnungsstellung erwartet als Inputs einen Liefernachweis aus Auftragsabwicklung und einen Sonderkonditionen-Vermerk aus Auftragsannahme.

Die ersten beiden Übergaben sind Matches: Der freigegebene Auftrag erscheint als Auftrag zur Bearbeitung in Auftragsabwicklung, der Lieferschein als Liefernachweis in Rechnungsstellung. Der dritte Strang ist der spannende. Rechnungsstellung erwartet den Sonderkonditionen-Vermerk direkt aus Auftragsannahme — doch in der gelebten Prozesslandschaft schickt Auftragsannahme den Vermerk nicht parallel, und Auftragsabwicklung reicht ihn nicht weiter. Ein Mismatch, und zwar einer der teuren Sorte: Er erklärt einen Großteil jener Rechnungsreklamationen, die in solchen Setups regelmäßig auftauchen, weil Rabatte und Sonderpreise auf der Rechnung fehlen.

Ohne POC-SIP würde dieser Mismatch wahrscheinlich erst in einem Beschwerdeprotokoll auftauchen. Mit POC-SIP fällt er beim Mapping auf der Tabellenebene auf — bevor die erste falsche Rechnung verschickt wird.

Abgrenzung zu SIPOC und BPMN

POC-SIP ersetzt SIPOC nicht, es ergänzt es. SIPOC bleibt das Werkzeug der Wahl, um einen einzelnen Prozess auf seinen Rahmen zu reduzieren. POC-SIP nutzt diese Rahmen, um die Beziehungen zwischen mehreren Prozessen zu prüfen. Wer keinen sauberen SIPOC pro Prozess hat, kann auch kein belastbares POC-SIP zeichnen.

Gegenüber BPMN ist der Unterschied größer. BPMN beschreibt vor allem zeitliche und logische Abhängigkeiten — Aktivitäten, Gateways, Events. POC-SIP interessiert sich nicht für die Reihenfolge innerhalb eines Prozesses, sondern für die Geschäftsobjekte, die zwischen Prozessen wandern. Ein Message-Event in BPMN sagt: hier wird etwas empfangen. POC-SIP fragt: was genau wird empfangen, woher kommt es, und passt das zu dem, was der andere Prozess tatsächlich aussendet?

Wann einsetzen?

POC-SIP ist die richtige Wahl, wenn

• eine Prozesslandkarte vorhanden ist, aber niemand sicher sagen kann, ob die Schnittstellen wirklich passen,
• ein Übergabe-Workshop zwischen zwei Teams ansteht und das übliche „Das war doch eure Aufgabe" verhindert werden soll,
• ein Digitalisierungsprojekt vorbereitet wird, dessen Datenflüsse aktuell informell laufen,
• versteckte Schnittstellen-Issues vermutet werden, die in keiner einzelnen Prozessdokumentation auftauchen.

Ein POC-SIP-Workshop dauert je nach Prozesszahl zwei bis vier Stunden. Das Ergebnis ist eine Karte mit grünen und roten Pfeilen — und eine kleine, sehr konkrete Liste an Verbesserungsangriffspunkten, an denen sich Prozessarbeit als nächstes lohnt.

Prozessmodelle erklären, was in einem Prozess passiert. Prozesslandkarten erklären, welche Prozesse es gibt. Was fehlt, ist die Schicht dazwischen: die belastbare Aussage, dass die Objekte, die ein Prozess verlässt, auch dort ankommen, wo sie gebraucht werden. POC-SIP füllt genau diese Lücke — auf einer einzigen Seite, mit einem ehrlichen Blick auf die Übergaben.