Wie Sie eine 3- bis 6-monatige Transformation durchfuehren, ohne Ihr Betriebsteam zu erschoepfen
Ein praxisorientierter Leitfaden zum Change Management digitale Transformation fuer B2B-Dienstleister im DACH-Raum, die einen IT-Rollout neben dem laufenden Betrieb durchfuehren
Table of Contents
Die meisten Change-Management-Leitfaeden fuer die digitale Transformation sind fuer Grossunternehmen geschrieben: dedizierte HR-Change-Teams, zertifizierte Change Manager und das Budget fuer strukturierte Adoptionsprogramme. Ein mittelstaendischer B2B-Dienstleister funktioniert anders. In einem Unternehmen dieser Groesse sind die wenigen Personen, die den operativen Kernprozess verstehen, meist dieselben, die ihn jeden Tag am Laufen halten. Sie zu bitten, das neue System zu entwerfen und gleichzeitig ihre volle Arbeitslast zu tragen, ist die zentrale Schwierigkeit, und die meisten Leitfaeden gehen nie darauf ein.
Das ist die strukturelle Spannung im Zentrum jeder operativen Transformation im Umsatzbereich 10 bis 50 Mio. EUR. Fuer KMU dieser Groesse ist das Change-Management-Problem kein kultureller Widerstand und keine Fuehrungsfrage. Es ist ein Problem der Auslastungsplanung. Das Team kann den Betrieb nicht anhalten, um das neue System einzufuehren, und das System kann nicht ohne das Team eingefuehrt werden. (Warum interne Teams ein operatives Kernsystem oft nicht allein aufbauen koennen, ist eine eigene Frage, die wir im Leitfaden Inhouse Entwicklung vs Agentur behandeln.) Die naechsten Seiten beschreiben, wie eine gut strukturierte Umsetzung diesen Widerspruch in der Praxis aufloest.
Warum Betriebsteams bei einem IT-Rollout schneller erschoepfen als andere Bereiche
Jede Funktion erlebt Unterbrechungen waehrend einer digitalen Transformation. Betriebsteams tragen eine spezifische Kombination aus Anforderungen, die Erschoepfung wahrscheinlicher macht als anderswo, aus zwei strukturellen Gruenden.
Erstens: Operativ gepraegte Unternehmen dieser Groesse haben selten Spielraum in ihren Kernprozessen. Sie arbeiten bewusst schlank, mit wenig personeller Redundanz in den Rollen, die das taegliche Geschaeft am Laufen halten, sodass keine Reserve vorhanden ist, um ein monatelanges Projekt zusaetzlich zur normalen Arbeit aufzufangen. Der weitere Kontext verschaerft das. Die Gartner Workforce Change Survey ergab, dass ein durchschnittlicher Mitarbeiter im Jahr 2022 rund zehn geplante organisatorische Veraenderungen erlebte, gegenueber zwei im Jahr 2016, waehrend die Bereitschaft, Veraenderungen mitzutragen, im selben Zeitraum von 74 Prozent auf 43 Prozent fiel. Eine Transformation trifft kein ausgeruhtes Team. Sie trifft ein Team, das bereits mehr Veraenderung verarbeitet als seit Jahren. Harvard Business Review
Zweitens: Operative Mitarbeiter sind genau die Personen, deren Wissen waehrend der Umsetzung am dringendsten benoetigt wird. Wer versteht, wie Preisausnahmen tatsaechlich funktionieren, welche Kundenvereinbarungen den Standardprozess ausser Kraft setzen und warum bestimmte Auftraege manuell statt systemseitig abgewickelt werden, ist zugleich der wertvollste Input fuer das neue Design und das unersetzlichste Glied, das den aktuellen Prozess am Laufen haelt. Beide Rollen gleichzeitig zu erfuellen ist der schnellste Weg zu Erschoepfung und eine haeufige Ursache fuer Implementierungsversagen in Unternehmen dieser Groesse.
Die drei Entscheidungen, die bestimmen, ob das Team erschoepft
Bevor der erste Workshop angesetzt oder eine Zeile Code geschrieben wird, muss die Geschaeftsfuehrung drei Entscheidungen explizit treffen. Das sind keine Prozessentscheidungen, sondern strukturelle Verbindlichkeiten, die alles Folgende praegen.
Entscheidung 1: Ein interner Verantwortlicher, kein Komitee. Jede Transformation benoetigt eine einzige, namentlich genannte interne Verantwortliche auf Kundenseite: keinen Lenkungsausschuss, keine Projektgruppe, nicht das operative Team kollektiv. Eine Person, die die primaere Ansprechpartnerin fuer den Umsetzungspartner ist, am woechentlichen Abstimmungsgespraech teilnimmt, Designentscheidungen abnimmt und fuer die interne Akzeptanz verantwortlich ist. Geteilte Verantwortung verwandelt jede Entscheidung in eine Koordinationsaufgabe und absorbiert weit mehr Teamzeit als noetig.
Entscheidung 2: Die Zeit dieser Person muss formell geschuetzt werden. Eine interne Verantwortliche zu benennen und sie gleichzeitig fuer ihre volle operative Last verantwortlich zu lassen, ist keine Loesung. Die Geschaeftsfuehrung muss konkrete Aufgaben fuer die Dauer der Umsetzung aus ihrem Arbeitsbereich herausnehmen, und zwar sichtbar, damit das Team erkennt, dass das Unternehmen eine echte Anpassung fuer das Projekt vornimmt und nicht still jemandes Last erhoeht.
Entscheidung 3: Tests finden mit echten Auftraegen statt, nicht mit erfundenen Szenarien. Der Standardansatz besteht darin, hypothetische Testfaelle zu erstellen und das System dagegen laufen zu lassen. Das produziert zuversichtliche Ergebnisse, die bei der ersten echten Ausnahme versagen. Tests muessen echte Auftragstypen aus dem laufenden Betrieb verwenden, einschliesslich der Ausnahmen, die zwei- bis dreimal pro Monat auftreten. Vor Testbeginn definiert die interne Verantwortliche fuenf bis zehn Auftragstypen: Standardfaelle und die haeufigsten Ausnahmen. Das ist eine Zwei-Stunden-Aufgabe, die Wochen an Krisenbewaeltigung nach dem Go-live verhindert.
So sequenzieren Sie die 3 bis 6 Monate: Was das Betriebsteam wann tut
Das schaedlichste Muster in einer digitalen Transformation ist, das Betriebsteam ueber das gesamte Umsetzungsfenster hinweg vollstaendig einzubeziehen. Wenn der Go-live-Termin kommt, ist das Team erschoepft, bevor der schwerste Teil beginnt. Die Alternative ist eine phasenweise Beteiligung: stark am Anfang, wenn Wissen erfasst wird; gering waehrend des Builds; und erneut konzentriert waehrend der Tests.
| Phase | Zeitraum | Beteiligung des Betriebsteams |
|---|---|---|
| Strategic Audit und Prozessdesign | Woche 1 bis 4 | Nur Input. Partner fuehrt. Team gibt Zugang und beantwortet Fragen. Keine Verantwortung fuer das Ergebnis. |
| Build-Phase | Woche 5 bis 14 | Ein interner Verantwortlicher. Woechentlicher 1-Stunden-Austausch. Keine Komitees. Keine Vollteam-Besprechungen. |
| Paralleltests mit echten Auftraegen | Woche 15 bis 18 | Zeitlich begrenzt. 2 bis 4 Stunden pro Woche und Tester. Strukturierte Szenarien aus echten Auftragstypen. |
| Phasenweiser Go-live | Ab Woche 19 | Ein Prozess nach dem anderen. Harter Umstieg mit Fallback-Plan. Kein dauerhafter Parallelbetrieb. |
| Stabilisierung nach Go-live | Woche 20 bis 28 | Team verantwortet das System vollstaendig. Partner fuer Probleme erreichbar. Keine neuen Features fuer mindestens 6 Wochen. |
Das Kernprinzip: Die Beteiligung des Betriebsteams sollte am Anfang am hoechsten sein, wenn sein Wissen ins Design ueberfuehrt wird, und erneut waehrend der Testphase. Waehrend des Builds selbst sollte die Beteiligung minimal und zeitlich begrenzt sein. Die Personen, die den Betrieb am Laufen halten, sollten in dieser Phase keine Projektverpflichtungen haben, die ueber den woechentlichen Abstimmungstermin der internen Verantwortlichen hinausgehen.
Die Parallelbetrieb-Falle: die haeufigste Ursache fuer Erschoepfung
Die haeufigste einzelne Entscheidung, die einen handhabbaren Rollout in ein Erschoepfungsereignis verwandelt, lautet: „Wir betreiben beide Systeme parallel, bis wir dem neuen vertrauen.“ Das klingt umsichtig. In der ERP-Praxis ist es das ressourcenintensivste Umstiegsmodell ueberhaupt, und seine charakteristische Belastung ist gut dokumentiert: Der gleichzeitige Betrieb beider Systeme bedeutet doppelte Dateneingabe und die damit verbundene Ermuedung der Mitarbeiter. Xserpconsulting
In der Praxis bedeutet es, dass das Team jeden Auftrag zweimal bearbeitet. Der erfahrene Disponent erfasst einen Auftrag im alten System, weil er ihm vertraut, und traegt ihn dann erneut ins neue ein, weil er darum gebeten wurde. Wer Angebote bearbeitet, gibt die Angaben erst in die Tabelle ein, dann erneut ins neue System. Innerhalb von zwei Wochen hat der Parallelbetrieb die Last der Personen, die ohnehin am meisten tragen, effektiv verdoppelt.
Nehmen wir einen typischen Fall. Ein B2B-Dienstleister betreibt seinen alten Angebotsprozess und ein neues Angebotssystem mehrere Wochen nach dem Go-live parallel, „bis alle sicher sind.“ Die erfahrenste Dispositionsleiterin, ohnehin die am staerksten ausgelastete Person im Team, erledigt die Arbeit nun doppelt. Unter dieser Last ist das realistische Risiko nicht ein Systemausfall, sondern eine Kuendigung, und das Wissen, das mit dieser Person geht, ist genau das, worauf das Projekt aufbaute. Das ist kein entferntes Szenario: Die ERP-Praxis weist immer wieder auf doppelte Eingabe, Mitarbeiterermuedung und den Verlust einer Schluesselperson mitten im Projekt als typisches Versagensmuster langer Parallelbetriebe hin, weshalb phasenweise Ansaetze das Zeitfenster, in dem eine einzelne Person ueberlastet ist, bewusst verkuerzen. XserpconsultingTechTarget
Die Alternative ist ein harter Umstieg mit einem spezifischen Fallback-Plan. Am Go-live-Tag laeuft das neue System. Wenn es einen bestimmten Auftragstyp nicht bewaeltigen kann, kehrt nur dieser Auftragstyp vorlaeufig zum alten Prozess zurueck; das Problem wird protokolliert und behoben, und alles andere bleibt live. Angenommen, das neue System kann am ersten Tag einen einzelnen Sonderfall noch nicht abbilden. Dieser eine Typ laeuft ein bis zwei Tage ueber den alten Prozess, wird behoben, und der Rest des Betriebs kehrt nie zurueck. Statt wochenlangem Parallelbetrieb ueber saemtliche Auftraege haben Sie ein bis zwei Tage Ausnahmebehandlung fuer einen einzigen. Dieser Ansatz ist in den ersten 72 Stunden belastender und in den folgenden Wochen erheblich weniger.
Woran Sie vor dem Start erkennen, ob Ihr Team die Transformation tragen kann
Bevor Sie einen Termin fuer den ersten Workshop festlegen, pruefen Sie drei Signale. Sie sagen Ihnen, ob das Team die zusaetzliche Last ueberhaupt aufnehmen kann, oder ob Sie zuerst Kapazitaet schaffen muessen.
Erstens: Gibt es fuer die Schluesselrolle im Prozess, meist Disposition oder Angebotswesen, eine dokumentierte Vertretung? Wenn der Prozess nur im Kopf einer einzigen Person existiert, ist diese Person waehrend der Umsetzung doppelt gebunden, und das Projekt ist von Anfang an gefaehrdet.
Zweitens: Arbeitet diese Person bereits regelmaessig ueber ihre regulaere Arbeitszeit hinaus? Ein Team ohne Puffer kann Wissenserfassung und Tests nicht zusaetzlich aufnehmen, ohne dass die Qualitaet des laufenden Betriebs sinkt.
Drittens: Werden Ausnahmen, Sonderpreise und Kundenvereinbarungen heute ueber Zuruf und Erfahrung geloest statt ueber eine dokumentierte Regel? Genau dieses Wissen muss das neue System aufnehmen, und genau diese Personen sind am schwersten freizustellen.
Wenn alle drei auf Belastung deuten, ist der erste Schritt nicht der Projektstart, sondern das Herausnehmen von Last bei der internen Verantwortlichen. In der Praxis heisst das, eine Vertretung zu benennen, die fuer die Projektdauer die Routineaufgaben der Verantwortlichen uebernimmt, etwa die taegliche Disposition oder die Angebotsfreigabe, nicht dauerhaft, sondern fuer das Umsetzungsfenster. Diese Umverteilung kostet kurzfristig Kapazitaet, und genau deshalb ist sie eine Entscheidung der Geschaeftsfuehrung und nicht des Teams. Erst danach beginnt die Transformation.
Was jetzt zu tun ist
Wenn Sie eine operative Transformation neben dem laufenden Betrieb planen, treffen Sie zuerst die drei Entscheidungen: eine namentlich benannte interne Verantwortliche, formell geschuetzte Zeit fuer diese Person und Tests mit echten Auftraegen statt erfundenen Szenarien. Sequenzieren Sie die Beteiligung des Betriebsteams so, dass sie am Anfang und in der Testphase hoch und waehrend des Builds minimal ist. Und vermeiden Sie die Parallelbetrieb-Falle: Ein harter Umstieg mit klarem Fallback-Plan belastet das Team in den ersten 72 Stunden staerker und in den folgenden Wochen deutlich weniger.
Ob sich die Investition ueberhaupt rechnet, ist eine eigene Frage, und sie gehoert vor den Rollout, nicht waehrend des Rollouts. Wie Sie einen belastbaren Investitionsfall aus Ihren eigenen Betriebsdaten aufbauen, bevor ein Partner eine Zeile Code schreibt, behandeln wir im Leitfaden zum ROI von Individualsoftware.
Wenn Sie diese Klarheit vor dem Start wuenschen: Das appleute Strategic Audit erfasst Ihren operativen Prozess, identifiziert, wo sich die Kosten konzentrieren, und liefert eine Kosten-des-Ist-Zustands-Zahl neben einer Umfangsabgrenzung und einer Amortisationsschaetzung. Ein festpreisiges, eigenstaendiges Engagement, das ein Dokument liefert, das Sie Ihrem CFO oder Ihrer Geschaeftsfuehrung mit Ueberzeugung vorlegen koennen. Wenn die Zahlen die Investition nicht stuetzen, sagen wir das ebenfalls.
Vereinbaren Sie einen kostenlosen und unverbindlichen Beratungstermin mit unserem Team.
Vereinbaren Sie einen kostenlosen und unverbindlichen Beratungstermin mit unserem Team.
DE 
EN 
FR 
ES