Teil sechs befasste sich mit dem Bericht: wie er aufhört, eine Datei zu sein, die man über zwei Tage zusammenstellt, und zu einer Ansicht wird, die man auf den aktuellen Moment öffnet. Damit ist das Bild vollständig, das wir über sechs Teile aufgebaut haben: wann eine Tabelle nicht mehr die Antwort ist, welche Datei das Unternehmen tatsächlich steuert, die Bereinigung der Daten vor der Migration, die Reihenfolge der Migration, wer was sieht und das Ende des handgebauten Berichts.

Bleibt der Teil, der entscheidet, ob sich all das auszahlt: der erste Monat im Produktivbetrieb. Und hier gilt etwas, das jeder weiß, der ein solches Projekt geleitet hat. Die meisten Migrationen scheitern nicht beim Aufbau. Sie scheitern in den ersten Wochen der Nutzung. Das System funktioniert, die Daten sind da, die Masken stimmen, und trotzdem wandert die eigentliche Arbeit still zurück in die alte Datei. In diesem Teil geht es darum, warum das passiert, und um einen Plan, der es verhindert.

Widerstand ist kein Starrsinn, sondern eine Risikorechnung

Das Erste, worauf man in der ersten Woche trifft, ist Zögern im Team. Der übliche Fehler besteht darin, dass der Inhaber dieses Zögern als Widerstand gegen Veränderung oder als Bequemlichkeit deutet und mit Druck reagiert. Meist ist es weder das eine noch das andere.

Der Mitarbeiter, der früher eine Datei öffnete und die Aufgabe in zwei Minuten erledigte, braucht jetzt zehn, um den Weg durch dieselbe Maske zu lernen. Aus seiner Sicht zahlt er heute die Kosten für einen Nutzen, von dem man ihm erzählt hat, den er aber noch nicht sieht, und er ist seiner Führungskraft für das heutige Ergebnis verantwortlich, nicht für den Projekterfolg. Das Zögern ist vollkommen rational.

Es verstärkt sich, wenn der Eigentümer der alten Datei jemand ist, dessen Stellung im Unternehmen darauf beruht, sie zu kennen. Wer die einzige Anlaufstelle für eine Datei war, fürchtet womöglich, dass das System seine Rolle überflüssig macht. Diese Angst zu ignorieren, beseitigt sie nicht, sondern drängt sie in den Untergrund. Sie direkt anzusprechen, funktioniert besser: Geben Sie dieser Person im neuen Gefüge eine erklärte Rolle als Verantwortliche für die Datenqualität in ihrem Bereich, damit sie vom Hüter einer Datei zur Referenz für die Daten selbst wird.

Die eigentliche Veränderung im ersten Monat ist, dass Arbeit sichtbar geworden ist. Solange die Daten in einer Datei lagen, war ein verspäteter Eintrag unsichtbar. In einem System ist dokumentiert, wer was wann erfasst hat. Das beruhigt jeden, der beständig arbeitet, und ist unangenehm für jeden, der an Flexibilität gewöhnt ist, und es sollte besser in der ersten Besprechung offen gesagt werden, als nach zwei Wochen entdeckt zu werden.

Die stille Rückkehr zur alten Datei

Das Gefährlichste im ersten Monat geschieht nicht lautstark. Niemand widerspricht dem System in der Besprechung, aber eine Kopie der alten Datei bleibt auf dem Rechner von jemandem geöffnet, und er erfasst darin, weil es schneller geht, mit der Absicht, es am Ende der Woche ins System zu übertragen. Meistens tut er es nicht.

Das führt zum schlechtesten möglichen Ergebnis: zwei Quellen der Wahrheit statt einer. Vor dem Projekt hatten Sie eine einzige ungenaue Datei, auf die sich alle als Referenz geeinigt hatten. Jetzt haben Sie ein unvollständiges System und eine unvollständige Datei, und niemand weiß, welche aktueller ist. Sie stehen schlechter da als am Anfang, und genau dieses Muster wird in Warum ERP-Projekte scheitern und wie Ihres gelingt behandelt.

Die Signale zeigen sich früh, wenn man nach ihnen sucht: eine Zahl, die in einer Besprechung genannt wird und im System nicht existiert, eine Datei, die zwei Wochen nach dem Start im Team-Chat geteilt wird, ein Mitarbeiter, der die Daten exportieren will, um extern damit zu arbeiten, und sie nie zurückbringt. Begegnen Sie keinem davon mit Schuldzuweisungen. Stellen Sie eine einzige Frage: Was hat die Datei ihnen gegeben, das das System nicht gibt? Die Antwort ist normalerweise ein fehlender Schritt, ein fehlendes Feld oder ein unnötig langer Weg, und all das lässt sich in Tagen beheben, sobald man davon weiß.

Die Lücken, die nach der Umstellung auftauchen, nicht davor

Wie gründlich Sie die Daten vorher auch bereinigt haben, wie in Teil drei beschrieben, es werden Lücken auftauchen, die sich erst bei der ersten echten Transaktion finden ließen. Die Logik ist einfach: Die Datei duldete Leerstellen, also blieb eine leere Zelle leer, und nichts hinderte Sie daran, die Rechnung auszustellen. Das System verlangt das Feld, weil ein späterer Schritt davon abhängt.

Was in dieser Phase typischerweise auftaucht:

  • Unvollständige Stammdaten von Kunden und Lieferanten. Ein Kunde, der nur mit Namen geführt wird, ohne Steuernummer, Adresse oder dokumentierten Ansprechpartner, Angaben, die früher bei Bedarf mündlich erfragt wurden.
  • Eröffnungssalden, die nicht aufgehen. Der Anfangswert für einen Kunden oder einen Artikel weicht von dem ab, was die alte Datei sagt, und die Differenz zeigt sich beim ersten Kontoauszug.
  • Zustände, die nie klassifiziert wurden. Eine offene Bestellung, eine Teilzahlung, eine Rücksendung, die nie abgeschlossen wurde. In der Datei waren sie eine Randnotiz; in einem System brauchen sie einen definierten Status.
  • Mehrere Einheiten und Preise. Ein Artikel, der im Karton verkauft und als Einzelstück eingekauft wird, mit unterschiedlichen Preisen für verschiedene Kundengruppen, und all das im Kopf des Vertriebsleiters statt schriftlich festgehalten.
  • Ausnahmen ohne Regel dahinter. Ein Kunde, der seit Jahren Sonderkonditionen ohne jedes Dokument hat, sodass niemand weiß, wie man sie im System abbildet oder wer befugt ist, sie zu genehmigen.

Nichts davon beweist, dass die Migration gescheitert ist. Es ist ihr erster echter Nutzen: Das System hat offengelegt, was die Datei verborgen hat. Aber der Umgang damit erfordert Disziplin. Erfassen Sie jeden Punkt auf einer einzigen erklärten Liste, mit der Person, die für die Antwort verantwortlich ist, und einem Datum für den Abschluss. Behandeln Sie jeden Fall einzeln in einem Nebengespräch, kommt er im nächsten Monat in anderer Form zurück.

Eine einmalige Schulung reicht nicht

Das häufigste Muster in Projekten, die ins Straucheln geraten, ist eine Schulung als einzige Sitzung am Starttag, an der alle teilnehmen und in der das gesamte System von Anfang bis Ende durchgegangen wird. Danach kehren alle an ihren Platz zurück und haben das meiste vergessen, weil sie es gehört haben, bevor sie es brauchten.

Die Alternative, die funktioniert, beruht auf drei Grundsätzen:

  • Schulen Sie die Rolle, nicht das System. Der Buchhalter braucht keine Lagermasken, und der Vertriebsleiter braucht keine Berechtigungseinstellungen. Jedes Team lernt den Weg, den es täglich gehen wird, kürzer und weitaus fokussierter.
  • Wiederholen Sie nach einer Woche Nutzung. Die zweite Sitzung ist diejenige, die sich wirklich lohnt, denn die Fragen darin sind echte Fragen aus der täglichen Arbeit statt hypothetischer. Und Fragen, die sich teamübergreifend wiederholen, zeigen Ihnen genau, wo eine Maske unklar ist.
  • Dokumentieren Sie mit Bildern, nicht mit Fließtext. Eine Seite pro Rolle mit den Schritten in der richtigen Reihenfolge und Screenshots, ausgehängt oder verschickt. Die meisten Fragen nach dem Start sind Erinnerungsfragen, keine Verständnisfragen.

Sie brauchen außerdem in jedem Team eine Person, die zuerst gefragt wird, denn ein Mitarbeiter fragt eine Kollegin, bevor er ein Support-Ticket eröffnet. Diese informelle Rolle verkürzt die Reaktionszeit stärker als jeder externe Support-Kanal. Diese Art von Change Management ist nicht nur beim Abschied von Tabellen nötig, und wir haben sie als Teil der Einführungsphasen in So gelingt die ERP-Einführung behandelt.

Die Sicht von Origami

Wir betrachten den Starttag als die Mitte eines Projekts, nicht als sein Ende. Ein System setzt sich in einem Unternehmen nicht allein dadurch durch, dass es funktioniert; es setzt sich durch, wenn es zum kürzesten Weg wird, die Arbeit des Tages zu erledigen. Jeder Tag, an dem der alte Weg schneller bleibt als der neue, ist ein Tag, der still gegen das Projekt arbeitet.

Deshalb führen wir im ersten Monat eine erklärte Liste von Beobachtungen mit Abschlussdaten und messen die tatsächliche Nutzung statt Eindrücken: wer sich anmeldet, welche Transaktionen erfasst werden, während sie geschehen, und an welcher Maske die Leute hängen bleiben. Genau das wenden wir an, wenn wir im Rahmen unserer Leistungen maßgeschneiderte Systeme entwickeln, denn eine kleine Hürde in ihrer ersten Woche zu beheben, kostet eine Stunde, während sie nach zwei Monaten zu beheben das Vertrauen eines ganzen Teams kostet.

Ein Dreißig-Tage-Plan

Dies ist ein Plan, den Sie so umsetzen können, wie er geschrieben ist, und sein wichtigstes Merkmal ist, dass jede Phase ein erklärtes Ende hat:

  • Tage 1 bis 7: befristeter Parallelbetrieb. Die Arbeit wird sowohl im System als auch in der alten Datei erfasst, und zwar aus nur einem Grund: zum Vergleich. Nehmen Sie am Ende der Woche eine kleine Stichprobe, vergleichen Sie die beiden Zahlen und protokollieren Sie jede Abweichung nach ihrer Ursache statt nach ihrer Größe.
  • Tag 8: Die alte Datei wird schreibgeschützt. Das ist der mit Abstand wichtigste Schritt im Plan. Die Datei bleibt zum Nachsehen verfügbar, und niemand schreibt mehr hinein. Ohne ein erklärtes Abschlussdatum läuft der Parallelbetrieb unbegrenzt weiter und endet immer damit, dass die alte Datei gewinnt, weil sie bequemer ist.
  • Tage 8 bis 14: zweite Schulung und Schließen der Lücken. Eine kurze Sitzung pro Team zu den Fragen, die tatsächlich aufgekommen sind, und das Schließen der fünf wichtigsten Punkte auf der Lückenliste.
  • Tage 15 bis 21: Nutzung messen. Prüfen Sie, wer das System wirklich nutzt und wer nicht, und fragen Sie bei jeder verspätet erfassten Transaktion nach dem Grund. Was Sie dabei lernen, ist ein Signal dafür, wie klar der Weg ist, nicht für die Disziplin Einzelner.
  • Tage 22 bis 30: stabilisieren und überprüfen. Schließen Sie die verbleibenden Beobachtungen ab, erstellen Sie den ersten Monatsbericht ausschließlich aus dem System und setzen Sie sich eine halbe Stunde mit den Teamleitern zusammen, um herauszufinden, was noch außerhalb des Systems geschieht und warum.

Der ehrliche Maßstab für Erfolg ist nicht die Zufriedenheit des Teams in einer Umfrage oder die Zahl der genutzten Masken. Es ist ein einziger Moment: Jemand hört auf, die alte Datei zu öffnen, ohne dazu aufgefordert worden zu sein. Ab diesem Punkt ist das System kein Projekt mehr, das Sie managen, sondern die Art, wie das Unternehmen arbeitet.

Abschluss der Reihe

In sieben Teilen sind wir den ganzen Weg gegangen: die Signale, dass eine Tabelle an ihre Grenze gestoßen ist, die Bestandsaufnahme, die Ihnen zeigt, welche Datei eigentlich Ihr System ist, die Bereinigung der Daten, die Reihenfolge der Migration, die Einrichtung von Berechtigungen, die Umwandlung des handgebauten Berichts in eine Live-Ansicht und schließlich das Überstehen des ersten Monats.

Die Erkenntnis, die es zu bewahren lohnt, ist diese: Excel ist ein hervorragendes Werkzeug, und das Problem war nie das Werkzeug, sondern das, was es tragen sollte. Der Wechsel zu einem System ist weniger ein technisches Upgrade als die Entscheidung, dass die Daten des Unternehmens dem Unternehmen gehören und nicht einer Datei oder einer Person. Und es beginnt mit einem kleinen Schritt: Öffnen Sie die Datei, die Ihr Unternehmen heute steuert, und fragen Sie, wer sie aktualisiert, wann und was passiert, wenn diese Person nicht da ist.

Quellen