Mitarbeitende mitnehmen: Einführung, die im Betrieb ankommt

Ein neues System verändert selten nur die Bildschirmmaske. Es verändert, wer wann was erfährt, wer etwas freigibt, in welcher Reihenfolge gearbeitet wird und woran jemand merkt, dass ein Vorgang abgeschlossen ist. Der alte Ablauf war über Jahre eingespielt und enthielt Regeln, die nirgends aufgeschrieben stehen: welcher Auftrag trotz Liste vorgezogen wird, bei welchem Kunden man vor der Lieferung anruft, welche Angabe man lieber zweimal prüft, weil sie erfahrungsgemäß Ärger macht. Wird ein neuer Ablauf eingeführt, ohne diese ungeschriebenen Regeln zu kennen, entsteht kein besserer Prozess, sondern ein zweiter Prozess neben dem alten — und das Team entscheidet in jedem Einzelfall neu, welchem es folgt.

Der zweite Grund ist Zeit. Eine Umstellung fällt in den laufenden Betrieb; die Aufträge werden nicht weniger, weil ein System wechselt. Wer eine Einführung ohne freigestellte Stunden plant, verlagert das Lernen in Randzeiten, in denen ohnehin Rückstand aufgeholt wird. Erhebungen von Bitkom und DIHK nennen fehlende Zeit und fehlendes Personal regelmäßig unter den Hemmnissen der Digitalisierung im Mittelstand — im Alltag zeigt sich das genau an dieser Stelle: Die Technik ist da, die Stunden zum Umlernen sind es nicht. Das ist kein Motivationsproblem, sondern ein Planungsfehler.

Der dritte Grund ist die Herkunft des Entwurfs. Ein Ablauf, der in einer Besprechung entworfen und anschließend verkündet wird, trägt die Sicht derer, die ihn nicht ausführen. Ein Ablauf, der ohne die Ausführenden entstanden ist, wird von ihnen auch nicht getragen — nicht aus Trotz, sondern weil er an Stellen nicht passt, die aus der Entfernung nicht sichtbar sind. Deshalb gehört Beteiligung an den Anfang eines Vorhabens und nicht in die Schulungswoche kurz vor dem Start.

Eine Schlüsselperson ist die Stelle im Betrieb, an die sich Kolleginnen und Kollegen mit einer Frage wenden, ohne dass daraus ein Vorgang wird. Sie kennt den neuen Ablauf früher als die anderen, sie kennt aber vor allem den alten aus eigener Arbeit. Geeignet ist deshalb selten die Führungskraft und selten die Person, die die Systeme betreut, sondern jemand, der den Vorgang täglich ausführt und dem im Team zugehört wird. Zwei Personen je umgestelltem Ablauf haben sich bewährt (Projekterfahrung) — eine allein fällt bei Urlaub oder Krankheit aus, und die Rolle sollte den Start nicht zum Einzelrisiko machen.

Damit die Rolle trägt, braucht sie eine Ausstattung. Dazu gehören ein Zugang zum neuen System vor allen anderen, damit echte Vorgänge vorab durchgespielt werden können, ein festes Zeitbudget im Dienstplan für die ersten Wochen, ein kurzer Weg zu den Umsetzenden ohne Umweg über mehrere Ebenen und das ausdrückliche Recht, einen Start zu verschieben, wenn ein Ablauf erkennbar nicht durchläuft. Wer die Rolle benennt, ohne diese vier Dinge zu geben, hat einen Titel vergeben und keine Funktion geschaffen.

Zwei Fehler treten häufig auf. Der erste: Die Rolle wird zugewiesen, ohne vorher zu fragen. Wer sie nicht will, wird sie auch nicht ausfüllen, und das Team merkt das binnen Tagen. Der zweite: Die Schlüsselperson wird zur Beschwerdestelle. Sie sammelt Unmut, hat aber keine Möglichkeit, etwas zu ändern. Beides lässt sich vermeiden, indem die Rolle angeboten statt verordnet wird und indem Rückfragen nachweislich zu Änderungen führen — auch zu kleinen, sichtbaren.

Zwischen dem letzten Tag des alten Wegs und dem ersten routinierten Tag des neuen liegt eine Phase, in der beides gleichzeitig gilt. Diese Phase braucht ein Enddatum. Ein Parallelbetrieb ohne festen Schlusspunkt ist kein Sicherheitsnetz, sondern doppelte Arbeit mit zwei Datenbeständen, die auseinanderlaufen; nach wenigen Wochen weiß niemand mehr, welcher Stand gilt. Zwei bis vier Wochen sind in den meisten Fällen ausreichend (Projekterfahrung), und das Datum steht vor dem Start fest — nicht als Drohung, sondern als Planungsgröße für alle.

In dieser Zeit hilft eine feste, kurze Runde: zehn Minuten am Morgen, an denen Rückfragen und Auffälligkeiten des Vortags durchgegangen werden. Sie ersetzt die Sammelmail, die niemand liest, und macht sichtbar, ob die Zahl der offenen Punkte sinkt. Wichtig ist der Tonfall: Fehler in dieser Phase sind Hinweise auf Lücken im Ablauf, nicht auf Unfähigkeit. Wer in der Übergangszeit einzelne Personen an Bearbeitungszeiten misst, bekommt saubere Zahlen und keine Rückmeldungen mehr.

Auch die Reihenfolge lässt sich steuern. Ein Start mit einem Team, einer Filiale oder einer Auftragsart ist fast durchweg besser als ein Start mit allen zugleich: Die Zahl gleichzeitiger Rückfragen bleibt beherrschbar, die Schlüsselpersonen sind erreichbar, und die zweite Gruppe profitiert von einer bereits korrigierten Kurzanleitung. Der Preis dafür ist eine längere Gesamtdauer und eine Zeit, in der zwei Wege nebeneinander existieren — das ist meist der günstigere Handel.

Nach dem Start entscheidet sich, ob aus dem neuen Weg Routine wird. Der wichtigste Baustein ist banal: Rückfragen brauchen eine Adresse. Ein benanntes Postfach, eine Sammelnummer oder ein kurzer Eintrag in einer gemeinsamen Liste — verbunden mit einer zugesagten Antwortzeit, etwa bis zum nächsten Werktag. Ohne Adresse landen Fragen bei irgendjemandem, werden unterschiedlich beantwortet und erzeugen die zweite Wahrheit, die man eigentlich abschaffen wollte.

Rückfragen sollten mitgeschrieben und grob eingeordnet werden: Bedienung, fachliche Regel, Zugriffsrechte, Ablage. Diese Einordnung kostet Sekunden und liefert nach vier Wochen ein Bild davon, wo der Ablauf noch nicht sitzt. Kommt dieselbe Frage mehrfach, ist das kein Bedienfehler, sondern ein Hinweis auf eine Lücke in Ablauf oder Kurzanleitung. Ein einfaches Protokoll reicht dafür aus; es muss weder Werkzeug noch Auswertung sein.

Nach etwa vier Wochen folgt eine kurze Auswertung mit den Schlüsselpersonen: Welche Punkte sind erledigt, welche offen, welche Änderung am Ablauf ist nötig? Beschlossene Änderungen bekommen einen Termin, und die Kurzanleitung wird an derselben Stelle fortgeschrieben. Was danach dauerhaft läuft — Störungsannahme, Aktualisierungen, kleine Anpassungen — gehört in den geregelten IT-Betrieb und nicht in die Restzeit einer Projektphase.

Der größere Teil einer gelungenen Einführung liegt beim Betrieb, nicht bei der Technik. Vorbereiten lassen sich Termine, Zuständigkeiten und Beispielfälle — und zwar bevor die Umsetzung beginnt. Wer drei echte Vorgänge je Ablauf, zwei benannte Schlüsselpersonen und ein Enddatum für den alten Weg hat, startet unter deutlich besseren Bedingungen als ein Betrieb, der diese Punkte während der Umstellungswoche klärt. Nichts davon erfordert externe Unterstützung.

Ebenso hilfreich ist eine ehrliche Terminwahl. Inventur, Jahresabschluss, Saisonspitze oder eine Woche mit Urlaubsengpass sind schlechte Startzeitpunkte, und zwar unabhängig davon, wie gut vorbereitet wurde. Eine Verschiebung um zwei Wochen kostet wenig; ein Start in der Hochphase kostet Vertrauen, das sich später schwer zurückholen lässt. Wo eine Automatisierung mehrere Bereiche gleichzeitig betrifft, lohnt zusätzlich die Frage, welcher Bereich beginnen sollte.