Prozesse vor der Migration, nicht danach
Ein S/4HANA-Programm plant das System. Das Prozesswissen, das mit umzieht, plant fast keines. Diese Lücke ist kein Versehen — sie entsteht, weil Prozessdokumentation im Programmplan wie eine Begleitaufgabe aussieht und sich erst im Integrationstest als Voraussetzung herausstellt.
Dieses Dossier beschreibt, was ein Programm konkret verlangt, wann es das verlangt, was der Rückstand kostet und womit man in den nächsten vier Wochen anfängt. Es enthält außerdem zwölf Fragen, mit denen ihr die Antwort eures Integrators auf diesen Punkt prüfen könnt. Es ist so geschrieben, dass es auch dann trägt, wenn ihr nie mit uns sprecht.
Worum es geht
In jedem S/4HANA-Programm gibt es drei Posten, die früh im Budget stehen: Lizenzen, Integrator, Testphase. Es gibt einen vierten, der meist nirgends steht — das Prozesswissen, das neu beschrieben, abgestimmt, freigegeben und im Zweifel belegt werden muss.
Der Posten ist deshalb unsichtbar, weil er sich nicht wie Arbeit anfühlt, solange niemand ihn braucht. Die Prozesse funktionieren ja. Sie laufen im Altsystem, in Custom-Transaktionen, in Ausnahmen, die vor Jahren zur Regel wurden, und in Köpfen, die sie seit zwanzig Jahren mitführen. Solange sich nichts ändert, ist das ein tragfähiger Zustand.
Ein Systemwechsel ändert genau das. Das neue System kennt eure Ausnahmen nicht. Der Integrator kennt sie nicht. Und die Prüfung, die zwölf Monate nach dem Go-live kommt, fragt nicht, ob ihr gute Prozesse habt, sondern welcher wann galt.
Was daraus folgt, ist keine Moral, sondern eine Reihenfolge: Prozessarbeit vor dem Fit-Gap kostet einen Bruchteil derselben Arbeit nach dem Integrationstest. Nicht, weil sie dann schneller ginge — sondern weil sie später unter Termindruck, mit externen Stundensätzen und ohne die Leute stattfindet, die zu Beginn noch Zeit hatten.
Wann was fällig wird
Der häufigste Planungsfehler ist nicht, den Posten zu vergessen. Er ist, ihn als einen Posten zu planen — als Paket, das man irgendwann im Programm abarbeitet. Tatsächlich sind es vier Anforderungen mit vier verschiedenen Fälligkeiten, und drei davon liegen vor dem Punkt, an dem die meisten Programme mit Dokumentation anfangen.
| Programmphase | Was hier fällig ist | Was es kostet, wenn es fehlt |
|---|---|---|
| Vor Programmstart | Belegter Ist-Stand | Das Fit-Gap vergleicht gegen Erinnerung. Was fehlt, taucht als Defect wieder auf |
| Vor der Template-Entscheidung | Varianten je Einheit sichtbar | Es wird stillschweigend harmonisiert, was sich nicht harmonisieren lässt |
| Durchgehend, 12–24 Monate | Fortschreibung des Bestands | Der Stand zum Go-live ist der vom Programmstart — also überholt |
| Zum Cut-over | Datierte Fassung | Eine dauerhafte Lücke im Nachweis. Der einzige Punkt, der sich nicht nachholen lässt |
Die Zeile, auf die es ankommt, ist die dritte. Die anderen drei sind Stichtage — man kann sie verpassen und teuer nachholen. Fortschreibung ist keine Aufgabe mit Termin, sondern ein Zustand über die gesamte Laufzeit. Wer sie als Stichtag plant, plant sie falsch.
Und die vierte Zeile ist die einzige, bei der Nachholen gar nicht geht. Dazu unten mehr.
Vier Anforderungen, die in jedem Programm auftauchen
Unabhängig vom Integrator, vom Template und davon, wer die Dokumentation am Ende macht. Die vier sind keine Best-Practice-Liste, sondern die Punkte, an denen Programme regelmäßig Zeit verlieren.
1 · Ein belegter Ist-Stand, bevor das Fit-Gap beginnt
Das Zielbild steht in den meisten Programmen früh. Es kommt aus dem Template, aus der Branchenlösung, aus der Erfahrung des Integrators. Der Ist-Stand steht selten — und damit vergleicht die Fit-Gap-Analyse ein präzises Zielbild gegen eine ungefähre Erinnerung.
Das Ergebnis ist berechenbar. Was in der Erinnerung fehlt, fehlt in der Gap-Liste. Was in der Gap-Liste fehlt, taucht im Integrationstest wieder auf — nur heißt es dort nicht mehr „Anforderung“, sondern „Defect“, und es wird unter Termindruck geklärt.
Die teuerste Variante ist nicht die undokumentierte. Es ist die, von der alle annahmen, sie sei wie die anderen.
Wie das Artefakt aussieht. Kein Foliensatz und keine Prozesslandkarte auf Flughöhe. Was das Fit-Gap braucht, ist je Kernprozess eine Beschreibung auf der Ebene, auf der Abweichungen sichtbar werden: welche Schritte, welche Systeme, welche Freigaben, welche Ausnahmen, wer entscheidet im Zweifel. Eine Seite pro Prozess und Einheit reicht — mehr wird ohnehin nicht gelesen.
Wem er gehört. Dem Fachbereich, nicht der IT und nicht dem Integrator. Der Integrator kann ihn erheben, aber er kann ihn nicht verantworten — er weiß nicht, welche Ausnahme einen Grund hat. Wenn der Ist-Stand im Programm der IT zugeordnet ist, ist das ein Warnsignal, kein Organisationsdetail.
Woran ihr erkennt, dass der Punkt offen ist. Fragt in der Fit-Gap-Runde, worauf sich eine bestimmte Aussage über den heutigen Ablauf stützt. Wenn die Antwort ein Name ist und kein Dokument, ist der Ist-Stand nicht belegt, sondern erinnert. Das ist kein Vorwurf an die Person — sie hat meistens recht. Es heißt nur, dass ihr Wissen nirgends steht und mit ihr das Haus verlassen kann.
2 · Die Varianten je Einheit sind sichtbar
Im Template wird harmonisiert — das ist der Sinn des Templates. Die Frage ist nicht, ob harmonisiert wird, sondern ob jede Abweichung, die bleiben muss, als bewusste Entscheidung bleibt.
Manche Varianten sind Gewohnheit und gehören weg. Andere haben einen Grund: eine landesrechtliche Vorgabe, eine Zulassung, ein Kundenvertrag, eine Anlage, die anders gebaut ist. Der Unterschied zwischen beiden steht nirgends im System. Er steht bei den Leuten, die den Prozess fahren.
Wenn die Varianten vor der Template-Entscheidung nicht nebeneinanderliegen, passiert das, was in jedem Rollout passiert: Es wird stillschweigend harmonisiert, was sich nicht harmonisieren lässt. Auffallen tut es beim ersten Monatsabschluss in der betroffenen Einheit — und dann ist es eine Change Request.
Wie das Artefakt aussieht. Eine Gegenüberstellung, kein Fließtext: derselbe Prozess, drei bis fünf Einheiten nebeneinander, Abweichung für Abweichung, und je Abweichung genau eine von drei Einordnungen — hat einen Grund, ist Gewohnheit, weiß gerade niemand. Die dritte Kategorie ist die wichtigste und wird am häufigsten weggelassen, weil sie unangenehm aussieht. Sie ist der eigentliche Ertrag der Übung.
Wem es gehört. Den Einheiten gemeinsam, moderiert von der Programmleitung. Nicht der stärksten Einheit allein — sonst entscheidet die Lautstärke im Raum, welcher Prozess der Zielprozess wird, und die Korrektur kommt Jahre später über die Kosten zurück.
Der billigste Test: Nehmt einen Kernprozess und lasst drei Einheiten unabhängig beschreiben, wie sie ihn heute fahren. Wenn die drei Beschreibungen sich unterscheiden und niemand das erwartet hatte, habt ihr die Antwort — und zwar in zwei Tagen statt in einem Workshop-Quartal.
3 · Eine datierte Fassung zum Go-live
In regulierten Bereichen — und das sind in einem Konzern mehr als die, die sich so nennen — muss belegbar sein, welcher Prozess wann galt und wer davon wusste. Nicht: welcher heute gilt. Welcher damals galt.
Ein Systemwechsel ist für diesen Nachweis der ungünstigste denkbare Moment. Der alte Stand verschwindet mit dem alten System. Der neue entsteht während des Cut-overs. Wenn zwischen beiden keine datierte Fassung liegt, gibt es genau dort eine Lücke — und zwar dauerhaft, weil sie sich nachträglich nicht schließen lässt.
Das ist der Punkt, an dem sich später am wenigsten reparieren lässt. Die anderen drei kann man nachholen; einen nicht dokumentierten Stichtag nicht. Man kann später beschreiben, wie ein Prozess heute läuft. Man kann nicht später belegen, wie er an einem Tag lief, an dem niemand hingesehen hat.
Wie das Artefakt aussieht. Ein eingefrorener Stand mit Datum, Freigabe und einer belegten Kenntnisnahme der Betroffenen — nicht bloß eine Ablage mit Zeitstempel. Der Zeitstempel sagt, wann die Datei geschrieben wurde. Gebraucht wird, wann die Fassung galt und wer sie zur Kenntnis genommen hat.
Wem es gehört. Compliance oder Qualitätssicherung, mit einem Termin im Cut-over-Plan. Wenn dieser Punkt nirgends im Cut-over-Plan steht, steht er faktisch nirgends — im Cut-over-Wochenende macht niemand etwas, das nicht auf der Liste steht.
Woran ihr erkennt, dass der Punkt offen ist. Sucht im Cut-over-Plan nach dem Wort „Dokumentation“. Findet ihr es nur als Nachlauf-Position nach dem Go-live, ist die datierte Fassung nicht eingeplant, sondern verschoben — und damit verloren.
4 · Jemand schreibt den Bestand während des Programms fort
Ein S/4HANA-Programm läuft meist zwölf bis vierundzwanzig Monate. Der Prozess bewegt sich in dieser Zeit weiter — nicht als Ausnahme, sondern als Normalfall. Neue Anforderungen, neue Vorschriften, neue Kunden, neue Anlagen.
Was daraus folgt, wird regelmäßig unterschätzt: Ein Bestand, der zum Go-live den Stand vom Programmstart zeigt, ist kein Nachweis, sondern ein Dokumentationsartefakt. Er beschreibt einen Zustand, den es zum Zeitpunkt seiner Verwendung nicht mehr gibt.
Ob das ein Problem ist, hängt an einer einzigen Zahl: wie oft sich bei euch ein Prozess ändert. Die Zahl zählt in den meisten Häusern niemand — und sie entscheidet darüber, ob Dokumentation bei euch ein Projekt ist oder eine Daueraufgabe.
| Änderungsrate im Kerngeschäft | Was das für die Programmlaufzeit heißt |
|---|---|
| mehrmals im Monat | Eine einmalige Erhebung ist schon zum Go-live überholt. Fortschreibung ist Bedingung, nicht Kür. |
| ein paar Mal im Jahr | Über 12–24 Monate summiert sich das spürbar. Fortschreibung einplanen ist billiger als Nacharbeit. |
| selten | Ein einmal erhobener Bestand hält. Prüft, ob das auch fürs Kerngeschäft gilt oder nur im Durchschnitt. |
Die Rechnung dahinter ist simpel und wird trotzdem selten gemacht. Nehmt eure Änderungsrate, multipliziert sie mit der Programmlaufzeit, und ihr habt die Zahl der Prozessänderungen, die zwischen Erhebung und Go-live anfallen. Bei zwei Änderungen im Monat und achtzehn Monaten Laufzeit sind das 36 Stände, die nachgezogen werden müssen — oder eben nicht.
Wem es gehört. Das ist die unbeantwortete Frage in den meisten Programmen. Der Fachbereich hat keine Kapazität, die IT hat kein Mandat, der Integrator hat kein Interesse — sein Vertrag endet mit dem Go-live. Wenn auf die Frage „wer schreibt das während der Laufzeit fort?“ niemand die Hand hebt, ist die Antwort: niemand.
Wer macht was
Die vier Anforderungen scheitern selten am Können. Sie scheitern daran, dass niemand sie besitzt. Deshalb hier explizit, wer welchen Teil verantworten muss, damit er nicht zwischen den Stühlen liegt.
| Rolle | Verantwortet | Typischer Fehler |
|---|---|---|
| Programmleitung | Dass die vier Punkte überhaupt im Plan stehen, mit Termin und Namen | Behandelt Dokumentation als Nachlauf statt als Voraussetzung |
| Fachbereich | Den Ist-Stand und die Einordnung jeder Variante | Wird erst zum Test eingebunden, wenn die Entscheidungen gefallen sind |
| Compliance / QS | Die datierte Fassung und die belegte Kenntnisnahme | Erfährt vom Cut-over-Termin zu spät, um ihn zu nutzen |
| IT / SAP-Lead | Systemseitige Quellen, aus denen sich der Ist-Zustand ziehen lässt | Bekommt den Ist-Stand zugeschoben, den nur der Fachbereich verantworten kann |
| Integrator | Das Zielbild und die Überführung | Wird gefragt, den Ist-Stand mitzuliefern — was er nicht verantworten kann |
Der häufigste Konstruktionsfehler steht in der letzten Zeile. Der Integrator wird beauftragt, den Ist-Stand miterheben zu lassen. Das klingt effizient und ist es nicht: Er kennt eure Ausnahmen nicht, er kann nicht beurteilen, welche einen Grund hat, und er hat kein Interesse daran, den Umfang eures Altbestands zu vergrößern — sein Auftrag ist der Zielzustand.
Das ist kein Vorwurf an Integratoren. Es ist eine Frage der Anreize. Wer den Ist-Stand verantwortet, muss mit den Folgen leben; der Integrator ist zwölf Monate nach dem Go-live nicht mehr da.
Was der Rückstand kostet
„Was kostet Prozessdokumentation?“ ist die falsche Frage, solange nur das Erstellen gerechnet wird. Das Erstellen ist der kleinere Teil. Der Preis, der bleibt, entsteht danach.
Vier Treiber entscheiden — nicht der Stundensatz:
- Zeit bis zum verwendbaren Stand. Ein Programm wartet nicht. Was in Quartalen entsteht, kommt für das Fit-Gap zu spät und wird dann parallel noch einmal gemacht.
- Pflegeaufwand. Jede Fassung, die von Hand gepflegt wird, konkurriert mit dem Tagesgeschäft. Unter Last verliert sie.
- Veralten. Ein statisches Dokument friert einen Stand ein. Ab dem zweiten Tag ist es ein bisschen falsch, nach zwölf Monaten deutlich.
- Abhängigkeit. Die entscheidende Frage ist nicht, was die erste Fassung kostet, sondern wovon die zweite abhängt: von einem Lauf oder von Personen, die wieder Zeit haben müssen.
Die Rechnung, die selten gemacht wird
Rechnet sie mit euren eigenen Zahlen nach — die Größenordnung überrascht die meisten, die es zum ersten Mal aufschreiben.
Der Ausgangswert. In einem globalen Schienentechnik-Konzern standen rund 5.000 verteilte Prozesse an, die aus veralteter, schriftlicher Doku in eine strukturierte Form sollten. Der Aufwand für die Erfassung von Hand lag bei rund 1.000 Personenmonaten. Das sind grob vier Personentage pro Prozess — und dieser Wert ist der brauchbarste Anker, den wir haben, weil er nicht geschätzt, sondern durchgerechnet wurde.
Vier Personentage klingen wenig. Sie sind es auch, pro Prozess. Das Problem ist die Menge:
| Umfang | Aufwand von Hand | Bei 800 €/PT intern | Bei 1.400 €/PT extern |
|---|---|---|---|
| 100 Prozesse | ~400 PT | ~320.000 € | ~560.000 € |
| 500 Prozesse | ~2.000 PT | ~1,6 Mio. € | ~2,8 Mio. € |
| 5.000 Prozesse | ~20.000 PT | ~16 Mio. € | ~28 Mio. € |
Zu den Sätzen: Die 800 € und 1.400 € sind Rechenanker, keine Marktstudie. Setzt euren eigenen internen Verrechnungssatz und den Tagessatz eures Integrators ein — die Struktur der Rechnung ändert sich dadurch nicht, nur die Endsumme.
Was diese Tabelle nicht zeigt, ist der teurere Teil. Sie rechnet die erste Fassung. Bei einer Änderungsrate von zwei Prozessänderungen im Monat und achtzehn Monaten Programmlaufzeit fallen 36 Nachzüge an. Wenn jeder davon dieselbe Handarbeit auslöst, verdoppelt sich der Posten über die Laufzeit — und zwar in der Phase, in der die Leute am wenigsten Zeit haben.
Der andere Weg, es falsch zu machen, ist teurer und weniger sichtbar. Ein Pharma-Hersteller in einer kritischen S/4HANA-Transformation hat den ersten Anlauf über ein Beraterprojekt gefahren. Nach rund 330 Tagen lag nichts Greifbares vor. Das ist kein Ausreißer und kein Vorwurf an die Berater: Es wurde erhoben, während sich der Gegenstand weiterbewegte, und das Ergebnis war beim Vorliegen bereits überholt.
330 Tage sind, bei einem typischen Programmzuschnitt, ungefähr die Zeit zwischen Programmstart und Integrationstest. Der Punkt ist also nicht das Geld allein. Es ist, dass die Anforderung „belegter Ist-Stand vor dem Fit-Gap“ in diesem Anlauf strukturell nicht mehr erfüllbar war.
Die Gegenrechnung. Im Schienentechnik-Fall fiel der Aufwand von ~1.000 auf ~4 Personenmonate — nicht, weil schneller getippt wurde, sondern weil die Rolle wechselte: Das System erfasst, das Team prüft. Bei 5.000 Prozessen ist das der Unterschied zwischen „undenkbar“ und „gemacht“. Bei 200 Prozessen ist er kleiner, aber er zeigt in dieselbe Richtung.
Rechnet für euer Haus die drei Zahlen: Wie viele Prozesse sind betroffen. Wie viele Personentage kostet einer von Hand. Wie viele Änderungen kommen über die Programmlaufzeit dazu. Das Produkt ist der Posten, der in keinem Programmplan steht.
Die drei Wege im Vergleich
| Beraterprojekt | Eigenbau | System | |
|---|---|---|---|
| Zeit bis zum Stand | Quartale | Quartale, oft länger | Tage bis Wochen |
| Pflege | findet nicht statt | konkurriert mit dem Tagesgeschäft | Neubau statt Nachbesserung |
| Veralten | ab Abnahme | ab der ersten Priorisierung | der Kontext bleibt, die Fassung wächst nach |
| Abhängigkeit | dieselben Leute für die nächste Fassung | einzelne Köpfe | ein Lauf |
| Passt, wenn | einmalig, mit klarem Stichtag, Budget vorhanden | wenig Einheiten, stabile Prozesse, freie Kapazität | wiederkehrender Bedarf, viele Einheiten, hoher Altbestand |
Keiner der drei Wege ist grundsätzlich falsch. Aber sie verteilen die Kosten unterschiedlich über die Zeit — und ein Programm mit zwölf bis vierundzwanzig Monaten Laufzeit braucht die zweite Fassung sicher, nicht vielleicht.
Ihr zahlt nie nur für die Dokumentation, die heute entsteht. Ihr zahlt für jede, die danach noch kommen muss.
Der Altbestand ist der Rohstoff, nicht das Hindernis
Der häufigste Satz in dieser Lage lautet: „Bei uns liegt viel — aber das ist alt und unstrukturiert, damit kann man nichts anfangen.“
Das ist die falsche Schlussfolgerung aus einem richtigen Befund. Ein Bestand, der verstreut liegt oder aus früheren Projekten stammt, ist für fast alles, was ein Programm verlangt, die bessere Ausgangslage:
- Alt heißt: es existiert. Jemand hat einmal aufgeschrieben, wie es läuft. Das ist die teure Hälfte der Arbeit, und sie ist erledigt.
- Verstreut heißt: es wurde nicht vorher in ein fremdes Schema gepresst, aus dem man es erst wieder herauslösen müsste.
- Für Anforderung 3 ist Altbestand sogar exakt das Richtige — er beschreibt den Ausgangszustand. Aktualität wäre hier hinderlich.
Der größte Bestand, mit dem wir gearbeitet haben, waren rund 5.000 veraltete Prozesse. Das war der Grund, warum es funktioniert hat, nicht das Hindernis.
Wer euch sagt, ihr müsstet erst aufräumen, bevor etwas gehen kann, verkauft euch das Aufräumen. Das Aufräumen ist die Arbeit, die als Letztes kommt — und in vielen Fällen gar nicht mehr nötig ist, wenn der Bestand einmal lesbar gemacht wurde.
Zwölf Fragen an euren Integrator
Diese Fragen prüfen nicht die Qualität des Integrators. Sie prüfen, ob eine Annahme im Raum steht, die niemand ausgesprochen hat — nämlich dass sich schon jemand um den Ist-Stand kümmert. In den meisten Programmen, in denen dieser Punkt schiefgeht, war die Annahme auf beiden Seiten vorhanden und auf keiner Seite beauftragt.
Stellt sie früh. Nach dem Fit-Gap sind sie nur noch Dokumentation eines Problems.
Zum Ist-Stand
- Auf welcher Grundlage führt ihr die Fit-Gap-Analyse durch — auf beschriebenen Prozessen oder auf Workshop-Aussagen?
- Wer verantwortet den Ist-Stand vertraglich: wir oder ihr? Und wenn wir: bis wann muss er vorliegen, damit euer Plan hält?
- Was passiert in eurem Vorgehen mit einer Anforderung, die im Fit-Gap nicht auftaucht und im Integrationstest sichtbar wird — wie wird die abgerechnet?
Zu den Varianten
- Wie viele Einheiten beschreibt ihr je Kernprozess, bevor das Template entschieden wird?
- Wie unterscheidet ihr eine Variante mit Grund von einer Gewohnheit — und wer trifft diese Entscheidung?
- Was ist eure Annahme über die Zahl der Varianten in unserem Haus, und woher stammt sie?
Zum Nachweis
- Steht die datierte Ist-Fassung im Cut-over-Plan, oder in der Nachlaufliste?
- Wie belegt ihr die Kenntnisnahme der geänderten Prozesse — und skaliert das über Verteilerlisten hinaus?
- Wenn eine Prüfung achtzehn Monate nach Go-live fragt, welcher Prozess zum Stichtag galt: aus welchem Artefakt beantworten wir das?
Zur Fortschreibung
- Wer schreibt den Bestand während der Programmlaufzeit fort, und in wessen Budget steht das?
- Was ist eure Annahme über unsere Änderungsrate? Falls keine: sollten wir sie zählen, bevor der Plan steht?
- Was übergebt ihr am Ende konkret — und in welcher Form, damit wir die nächste Fassung ohne euch erzeugen können?
Frage 12 ist die, an der sich das Vorgehen entscheidet. Wenn die Antwort ein Foliensatz oder ein PDF-Paket ist, habt ihr eine Momentaufnahme gekauft. Wenn sie ein Bestand ist, aus dem sich die nächste Fassung erzeugen lässt, habt ihr eine Grundlage gekauft. Der Preisunterschied ist oft klein, der Unterschied über 24 Monate ist es nicht.
Drei Schritte für die nächsten vier Wochen
Alle drei sind ohne externe Hilfe machbar. Sie kosten zusammen keine zwei Personentage und verändern die Grundlage jeder folgenden Entscheidung.
Woche 1 — Die Fünf-Minuten-Probe
Nehmt einen beliebigen Kernprozess. Bittet jemanden, der ihn nicht selbst geschrieben hat, die geltende Fassung zu suchen. Stoppt die Zeit.
Dauert es länger als fünf Minuten, ist der Bestand praktisch nicht vorhanden — unabhängig davon, wie viel davon existiert. Der Wert der Probe liegt nicht im Ergebnis, das meist absehbar ist, sondern darin, dass jemand es erlebt, der über Budget entscheiden darf.
Zweite Probe, falls die erste zu gut ausging: Sieht man dem gefundenen Dokument an, ob es noch gilt? Wenn nicht, wird im Zweifel gefragt statt gelesen — und dann ist der dokumentierte Prozess nicht der gelebte, sondern der abgelegte.
Woche 2 — Die Variantenaufnahme
Ein Prozess, drei Einheiten, unabhängige Beschreibung, eine Seite pro Einheit. Danach nebeneinanderlegen und jede Abweichung genau einmal einordnen:
- hat einen Grund (Recht, Zulassung, Vertrag, Anlage) → gehört ins Zielbild
- ist Gewohnheit → gehört in die Harmonisierung
- weiß gerade niemand → gehört auf die Klärungsliste, bevor das Template entscheidet
Diese Liste ist der Input, den die Fit-Gap-Runde sonst nicht hat. Sie ist außerdem das billigste Argument, das ihr bekommen könnt: Drei widersprüchliche Beschreibungen desselben Prozesses überzeugen ein Steering Committee schneller als jede Aufwandsschätzung.
Woche 3–4 — Die eine Zahl
Zählt für einen Bereich, wie viele Prozessänderungen es in den letzten zwölf Monaten gab. Freigaben, Arbeitsanweisungs-Updates, Ausnahmegenehmigungen, die dauerhaft wurden.
Die Zahl beantwortet die Frage, die den Rest strukturiert: Ist Dokumentation bei euch ein Projekt oder eine Daueraufgabe? Wer sie hat, kann die Entscheidung zwischen den drei Wegen aus dem Kostenkapitel begründen, statt sie zu verhandeln — und kann Frage 11 aus der Liste oben beantworten, statt sie zurückzugeben.
Woran Programme an dieser Stelle scheitern
Vier Muster, benannt, damit sie auffallen, bevor sie eintreten.
Das Zielbild steht vor dem Ist-Stand. Erkennbar daran, dass die Prozesslandkarte des Programms aus dem Template stammt. Sie beschreibt dann, wie es werden soll, und wird stillschweigend gelesen, als beschriebe sie, wie es ist.
Dokumentation läuft dem Programm hinterher. Sie ist als Nachlauf geplant — dokumentiert wird, was gebaut wurde. Für den Nachweis funktioniert das; für das Fit-Gap kommt es ein Jahr zu spät.
Die Harmonisierung wird nicht entschieden, sondern passiert. Niemand beschließt, eine Variante fallen zu lassen. Sie ist einfach nicht im Template, und das fällt beim ersten Abschluss auf.
Die Kenntnisnahme wird vergessen. Den Prozess zu beschreiben ist die eine Hälfte. Zu belegen, dass die Betroffenen die geänderte Fassung zur Kenntnis genommen haben, ist die andere — und sie skaliert über Verteilerlisten nicht.
Zwei Belege
Der Fall, in dem die Reihenfolge nicht hielt
Ein Pharma-Hersteller in einer kritischen S/4HANA-Transformation: mehrere Value Streams, hunderte streng regulierte Prozesse. Der erste Anlauf lief über ein Beraterprojekt und brachte nach rund 330 Tagen nichts Greifbares.
Das ist kein Ausreißer, sondern die vorhersehbare Folge der Reihenfolge: Es wurde erhoben, während sich der Gegenstand weiterbewegte, und das Ergebnis war beim Vorliegen bereits überholt. Genau der Effekt, den Anforderung 4 beschreibt — nur dass er hier nicht die Fortschreibung traf, sondern schon die Ersterhebung.
Der zweite Anlauf setzte an den vorhandenen Quellen an — SAP, regulierte SOPs, Interviews — statt bei null. Ergebnis war eine sauber strukturierte, auditierbare Prozessgrundlage als Migrationsbasis, erzeugt in Tagen statt Quartalen.
„Nach 330 Tagen Beraterarbeit hatten wir nichts Greifbares. ProcessForge hat unsere regulierten Prozesse sauber strukturiert — auditierbar.“
Leiter SAP-Transformation, Pharma-Hersteller
Der Unterschied lag nicht in der Sorgfalt. Er lag darin, dass die zweite Fassung nicht wieder von Hand entstehen musste.
Der Fall, an dem die Größenordnung sichtbar wird
Ein globaler Schienentechnik-Konzern stand vor rund 5.000 weltweit verteilten Prozessen, die aus veralteter schriftlicher Dokumentation in eine strukturierte Form überführt werden mussten. Der geschätzte Aufwand für die Erfassung von Hand: rund 1.000 Personenmonate.
Das ist die Zahl, an der ein Vorhaben nicht verschoben, sondern beerdigt wird. Nicht weil das Geld fehlt, sondern weil kein Programmplan eine Position dieser Größe trägt, die keinen unmittelbaren Systemnutzen hat.
„5.000 Prozesse weltweit von Hand zu dokumentieren — undenkbar. ProcessForge erfasst, wir prüfen nur noch.“
Head of Global Process Documentation, globaler Schienentechnik-Konzern
Der Aufwand fiel auf rund vier Personenmonate. Entscheidend ist dabei nicht der Faktor, sondern was sich an der Arbeit selbst geändert hat: Das Team erfasst nicht mehr, es prüft. Das ist die Tätigkeit, für die Fachwissen tatsächlich gebraucht wird — und die einzige der beiden, die sich nicht sinnvoll auslagern lässt.
Wo ProcessForge hilft — und wo nicht
Damit die Einordnung nicht am Ende eines Verkaufsgesprächs steht, hier vorab.
Wofür das System gebaut ist: Es zieht den realen Ist-Zustand aus euren vorhandenen Quellen — Systemexporte, Ablagen, Arbeitsanweisungen, Gespräche — und erzeugt daraus die Form, die gebraucht wird: Prozessmodelle, Nachweisdokumentation, Arbeitsanweisungen, einen Automations-Entwurf. Ändert sich der Prozess, entsteht die nächste Fassung aus demselben Kontext. Das ist der Unterschied, auf den es in einem 12- bis 24-monatigen Programm ankommt: nicht die erste Fassung, sondern die zweite.
Wann es sich lohnt: Viele Einheiten mit eigenen Varianten. Großer, gewachsener Altbestand. Wiederkehrender Bedarf statt einmaligem Stichtag. Eigene Hoheit über die Prozessstandards.
Wann es sich nicht lohnt — offen gesagt:
- Wenn es um einen einzelnen Prozess in einer Einheit geht. Dafür ist ein System dieser Art überdimensioniert.
- Wenn eure Prozessstandards vollständig von einer Konzernmutter kommen und ihr nichts entscheiden könnt. Dann liegt die Arbeit dort, nicht bei euch.
- Wenn tatsächlich nichts Schriftliches existiert und auch keine Systeme, aus denen sich etwas ziehen ließe. Dann ist der erste Schritt eine Erhebung, und die ist ein anderes Vorhaben.
- Wenn ihr eine einmalige Momentaufnahme mit festem Stichtag braucht und danach nichts mehr. Dafür ist ein Beraterprojekt ehrlich gesagt das passendere Werkzeug.
Wenn ihr nach diesem Dossier zu dem Schluss kommt, dass es bei euch nicht passt, hat es seinen Zweck trotzdem erfüllt.
Auf einer Seite
- Vier Anforderungen mit vier Fälligkeiten: belegter Ist-Stand vor dem Fit-Gap · Varianten je Einheit vor der Template-Entscheidung · Fortschreibung durchgehend · datierte Fassung zum Cut-over.
- Der einzige Punkt, der sich später nicht reparieren lässt, ist die datierte Fassung zum Stichtag. Alles andere kann man nachholen — teuer, aber möglich.
- Der teuerste Konstruktionsfehler ist, den Ist-Stand beim Integrator zu bestellen. Er kann ihn erheben, aber nicht verantworten — er weiß nicht, welche Ausnahme einen Grund hat, und er ist nach dem Go-live nicht mehr da.
- Die Rechnung: Zahl der Prozesse × Aufwand je Prozess × Änderungen über die Laufzeit. Ein durchgerechneter Anker aus einem realen Fall sind rund vier Personentage je Prozess von Hand.
- Vier Kostentreiber: Zeit bis zum verwendbaren Stand, Pflegeaufwand, Veralten, Abhängigkeit. Der Stundensatz steht nicht darunter.
- Altbestand ist der Rohstoff. Viel und veraltet ist die bessere Ausgangslage als wenig und gepflegt.
- Zwölf Fragen an den Integrator, von denen Frage 12 die entscheidende ist: Was genau wird übergeben — eine Momentaufnahme oder ein Bestand, aus dem die nächste Fassung entsteht?
- Drei Schritte, vier Wochen, ohne uns: Fünf-Minuten-Probe · Variantenaufnahme über drei Einheiten · die Änderungsrate eines Bereichs zählen.
- Die Zahl, die alles strukturiert, ist die Änderungsrate. Sie entscheidet, ob Dokumentation bei euch ein Projekt ist oder eine Daueraufgabe.
Wenn ihr wissen wollt, wo ihr auf diesen vier Anforderungen laut euren eigenen Angaben steht: Das Prozess-Lagebild stellt acht Fragen und zeigt das Ergebnis sofort — ohne E-Mail, ohne Bewertung.