kurz gesagt
- Software bildet ab, was da ist. Wer ein ERP einführt, ohne seine Prozesse zu kennen, digitalisiert im besten Fall Chaos, im schlechtesten Fall bringt er den Betrieb ins Wanken.
- Die meisten Einführungen scheitern nicht an der Software. In verschiedenen Studien werden Scheiterquoten zwischen 50 und 70 Prozent für ERP- und CRM-Projekte genannt. Die häufigste Ursache: ungeklärte Ausgangslage.
- Klarheit über den Ist-Prozess ist keine Vorbereitung auf das Projekt. Sie ist das Projekt, der Teil, der über Erfolg oder Fehlschlag entscheidet.
Was passiert, wenn Software zuerst kommt
Aufträge stauen sich, Abstimmungen dauern zu lang, Informationen gehen verloren. Das Gefühl kennen viele Unternehmer. Die naheliegende Reaktion: ein neues ERP, ein neues CRM, ein neues Projektmanagement-Tool. Doch echte Prozessoptimierung fängt nicht mit der Auswahl eines Systems an, sondern mit einer ehrlichen Bestandsaufnahme der Abläufe.
Prozesse sind das Skelett eines Unternehmens. Solange sie unsichtbar bleiben, lässt sich daran nichts verändern. Das gilt im Alltag, und es gilt erst recht, wenn ein System eingeführt wird, das genau diese Abläufe abbilden und beschleunigen soll.
Warum ERP-Einführungen scheitern
In verschiedenen Studien werden Scheiterquoten zwischen 50 und 70 Prozent für ERP- und CRM-Einführungen genannt. Eine einheitliche Datenbasis dafür gibt es nicht, und jedes Projekt ist anders. Aber ein Muster zieht sich durch: Die Ausgangslage war ungeklärt. Das Unternehmen hat ein System eingeführt, ohne zu wissen, wie seine bestehenden Prozesse tatsächlich funktionieren.
Wer ein neues System einführt, ohne seine bestehenden Prozesse zu kennen, digitalisiert im besten Fall Chaos. Im schlechtesten Fall bringt er das gesamte operative Geschäft ins Wanken. Der Fehler liegt nicht in der Software, sondern in der Reihenfolge.
Was Klarheit über den Ist-Prozess bedeutet
Ist-Prozesse kennen heißt nicht, ein dickes Handbuch zu schreiben. Es heißt, die fünf bis sieben Abläufe, die das Geschäft tragen, so aufzuzeichnen, wie sie wirklich laufen, mit den Menschen, die sie täglich ausführen.
Der Unterschied zum Soll-Prozess ist entscheidend. In vielen Unternehmen existieren Prozessbeschreibungen in Handbüchern oder ISO-Dokumenten. Das Problem: Sie beschreiben, wie es sein sollte, nicht wie es ist. Wer ein System auf dem Soll-Prozess aufbaut, baut auf Sand. Denn das System trifft auf die Realität, nicht auf das Handbuch.
Wie du einen Ist-Prozess schnell aufnimmst, zeigt der Beitrag Prozessoptimierung: Abläufe visualisieren und Engpässe lösen.
Woran du erkennst, ob die Ausgangslage klar ist
- Kannst du den Weg vom Kundenauftrag bis zur Rechnung auf einer Seite zeichnen? Wenn nicht, ist die Ausgangslage noch nicht klar.
- Weißt du, wer für jeden Schritt in diesem Weg namentlich verantwortlich ist? Nicht eine Abteilung, ein Name.
- Hast du gemessen, wie lange die einzelnen Schritte heute dauern? Schätzungen reichen für eine erste Orientierung, aber keine Entscheidungsgrundlage.
- Wissen die Menschen, die täglich im Prozess arbeiten, von dem geplanten Projekt? Wer zuerst von der Einführung hört, wenn sie schon im Gange ist, wird zum Widerstand beitragen, nicht zum Erfolg.
Ein Projekt, das mit klaren Prozessen startet, verkürzt sich spürbar. Weniger Workshops zur Prozessfindung im Projekt, weniger Änderungen während der Einführung, schnellere Akzeptanz im Team. Das beschreibt auch der Beitrag Prozessoptimierung im Mittelstand: Warum Systeme nicht schuld sind.
Die core+-Logik dahinter
In core+ gilt: Erst Klarheit, dann Struktur, dann Umsetzung. Das Feld "clarity & diagnostics" steht nicht zufällig an erster Stelle. Ohne Klarheit über den Ist-Zustand führt jede Optimierung an der falschen Stelle an. Software ist dabei immer das Werkzeug, nie der Ausgangspunkt.
Drei Fragen, bevor du eine Systementscheidung triffst
- Kannst du die fünf Prozesse, die dein Geschäft tragen, heute so beschreiben, wie sie wirklich ablaufen, nicht wie sie laut Plan ablaufen sollen?
- Gibt es für jeden dieser Prozesse einen namentlichen Verantwortlichen, der ihn ändern darf?
- Haben die Menschen, die täglich in diesen Prozessen arbeiten, an der Aufnahme mitgewirkt?
Wenn eine dieser Fragen mit Nein beantwortet wird, ist das der Punkt, an dem das Projekt heute steht, nicht bei der Softwareauswahl.
