Warum Schnittstellenprozesse Rework erzeugen. Rework entsteht selten nur durch schlechte Übergaben. Oft fehlt eine klare Entscheidung darüber, wann etwas wirklich übergabefähig ist.

Rework beginnt oft vor der eigentlichen Arbeit.

Rework wird häufig dort sichtbar, wo nachgearbeitet wird. Im Projekt. In Operations. Im Support. In der Umsetzung. Aber entstanden ist er oft früher: an der Übergabe.

Ein Auftrag wurde angenommen, bevor Machbarkeit geklärt war. Ein Projekt wurde gestartet, bevor Risiken entschieden waren. Ein Bereich hat geliefert, was aus seiner Sicht vollständig war – aber nicht das, was der nächste Bereich wirklich gebraucht hätte.

Dann entsteht ein typisches Muster: Die Arbeit läuft weiter, aber nicht sauber. Die nächste Stelle fragt zurück. Der vorige Bereich verteidigt seine Sicht. Die Geschäftsführung muss schlichten. Das Thema wandert zurück in Meetings.

Rework ist oft kein Qualitätsproblem am Ende. Rework ist ein Entscheidungsproblem am Anfang.

Warum Schnittstellen besonders anfällig sind

Schnittstellen sind anspruchsvoll, weil dort mehrere Logiken aufeinandertreffen. Vertrieb denkt in Kunde, Chance und Abschluss. Projekt denkt in Aufwand, Risiko und Lieferbarkeit. Operations denkt in Kapazität, Standard, Qualität und Stabilität. Geschäftsführung denkt in Marge, Priorität, Reputation und Verantwortung.

Keine dieser Logiken ist falsch. Aber wenn nicht entschieden ist, welche Logik wann Vorrang hat, wird die Schnittstelle zur Reibungszone.

Genau dort entstehen teure Schleifen:

• Der Vertrieb verkauft eine Variante, die operativ schwer lieferbar ist.
• Das Projekt startet mit offenen Annahmen.
• Operations bekommt Anforderungen, die nicht zur Kapazität passen.
• Support übernimmt Fälle, deren Verantwortung vorher nicht geklärt wurde.
• Die Geschäftsführung wird zur letzten Entscheidungsinstanz für operative Zielkonflikte.

Das sind keine reinen Kommunikationsprobleme. Es sind Entscheidungslücken an Prozessübergängen.

Die 6 Rework-Treiber an Schnittstellen

In der Praxis wiederholen sich sechs Muster besonders häufig. Sie erklären, warum Übergaben formal existieren, aber im Alltag trotzdem Rework erzeugen.

RACI allein reicht oft nicht.

RACI ist ein gutes Werkzeug, um Beteiligung sichtbar zu machen: Wer ist verantwortlich, wer entscheidet, wer wird konsultiert, wer informiert?

Aber Schnittstellenprozesse brauchen oft mehr als eine Matrix. Sie brauchen Entscheidungsschwellen, Vetorechte, Eskalationsfenster, Annahmekriterien und eine Schließlogik.

Sonst entsteht eine saubere Tabelle – und trotzdem läuft der Prozess zurück.

Deshalb arbeitet Coachingwerk Berlin an Schnittstellen oft mit RACI oder RASCI, aber nicht isoliert. Die Matrix wird mit realen Entscheidungspunkten verbunden:

• Welche Entscheidung entsteht an dieser Übergabe?
• Wer darf final entscheiden?
• Wer darf zurückweisen?
• Wer muss vorher konsultiert werden?
• Welche Information ist zwingend?
• Ab welcher Schwelle wird eskaliert?
• Wo wird die Entscheidung dokumentiert?

Eine Schnittstelle wird nicht dadurch stabil, dass alle miteinander sprechen. Sie wird stabil, wenn klar ist, wer an der Schnittstelle entscheiden darf.

Was Decision-OS an Schnittstellen klärt

Decision-OS betrachtet Schnittstellen als Entscheidungszonen. Nicht jedes Detail braucht eine große Governance. Aber die kritischen Übergaben brauchen klare Regeln.

Typische Hebel sind:

• RACI/RASCI: Wer arbeitet, wer entscheidet, wer unterstützt, wer wird konsultiert, wer informiert?
• DRI: Wer trägt den nächsten Schritt operativ?
• Decision Rights: Wer darf welche Entscheidung an der Schnittstelle treffen?
• Delegation of Authority: Welche Schwellen gelten für Budget, Risiko, Qualität, Kunde oder Termin?
• Definition of Ready / Done: Wann darf etwas angenommen oder zurückgewiesen werden?
• Eskalationsfenster: Wann muss ein Konflikt wohin?
• Decision Log: Was wurde entschieden, auf welcher Annahme, mit welchem Owner?
• Review-Takt: Welche Übergaben erzeugen weiter Rework und müssen nachgeschärft werden?

Woran Sie erkennen, dass Rework ein Schnittstellenentscheidungsproblem ist

Nicht jedes Rework ist ein Governance-Problem. Manchmal ist schlicht etwas falsch gemacht worden. Aber wenn sich Rework an denselben Übergaben wiederholt, lohnt sich der Blick auf Entscheidungsrechte.

Typische Signale:

• Immer dieselben Bereiche beschuldigen sich gegenseitig.
• Übergaben sind dokumentiert, aber werden unterschiedlich interpretiert.
• Die Geschäftsführung muss operative Grenzfälle entscheiden.
• Meetings drehen sich um Fälle, die eigentlich im Prozess entschieden werden sollten.
• Jeder Bereich hat aus seiner Sicht recht, aber der Gesamtprozess verliert Zeit.
• Entscheidungen werden nachträglich relativiert oder wieder geöffnet.
• Es gibt viele Abstimmungen, aber keinen eindeutigen Owner.

Wenn mehrere dieser Punkte auftreten, ist Rework nicht nur ein Qualitäts- oder Prozessproblem. Dann fehlt dem Schnittstellenprozess eine tragfähige Entscheidungsarchitektur.

Der kleinste wirksame Eingriff

Der kleinste wirksame Eingriff ist selten ein komplett neuer Prozess. Häufig reicht es, eine kritische Schnittstelle sauber zu entscheiden: von der Übergabe über die Annahmekriterien bis zur Eskalation.

Praktisch heißt das:

• eine reale Schnittstelle auswählen, an der Rework sichtbar ist,
• die häufigsten Rückläufe und Eskalationen sammeln,
• die Entscheidungspunkte an der Übergabe markieren,
• RACI/RASCI und Decision Rights dort konkret klären,
• Definition of Ready / Done und Vetorechte festlegen,
• Entscheidungen im Decision Log sichtbar machen,
• nach 14 bis 30 Tagen prüfen, ob Rework und Rückfragen sinken.

So entsteht Prozessverbesserung nicht durch mehr Prozesspapier, sondern durch weniger unentschiedene Übergaben.