Warum der Prozess vor der Systemeinführung repariert wird, nicht währenddessen
Wir haben dreimal ein CRM eingeführt: in einer Agentur, in einer saisonalen Fertigung für Firmengeschenke und auf einer Plattform für Online-Terminbuchung. Drei Unternehmen, drei Branchen, drei Teams. Eines war überall gleich: Die erste Version der Konfiguration war stets der bestehende Arbeitsablauf, unverändert in Felder und Status übertragen.
Genau an diesem Punkt entscheidet sich das Schicksal des Projekts. Enthielt der Prozess vor der Einführung optionale Felder, manuelle Ausnahmen und ein „hier rufen wir normalerweise an und einigen uns telefonisch", zieht das alles in das System um und erhält den Status der Norm. Danach wird eine Korrektur teurer: Das Chaos hat jetzt eine Konfiguration, Schnittstellen und geschulte Anwender.
Ein System bringt keine Ordnung in den Prozess — es schreibt ihn fest. Alles, was vor der Einführung nicht entschieden wurde, wird zu einer Einstellung, zu einer Ausnahme und zu einer Anwendergewohnheit, und die Kosten der Korrektur steigen um ein Vielfaches. Deshalb müssen vor Projektstart drei Dinge geklärt sein: die Liste der Pflichtdaten, die Berechnungsregeln und die Übergabepunkte zwischen den Rollen.
Was ein System im Prozess festschreibt
Die Formulierung „das System schreibt das Chaos fest" klingt nach einer Metapher, solange man sie nicht in konkrete Mechanismen zerlegt. Es sind vier, und jeder davon zeigt sich bereits in den ersten Wochen nach dem Go-live.
Ein optionales Feld bleibt dauerhaft leer. In der Konfigurationsphase setzt sich fast immer das Argument durch: „Machen wir es optional, sonst wird es nicht ausgefüllt." Ein Quartal später zeigt sich, dass das Feld bei 80 % der Datensätze leer ist und sich darauf kein Report aufbauen lässt. Die Entscheidung, welche Daten ein Pflichtfeld sind, ist eine Prozessentscheidung, keine technische — und sie nach dem Go-live zu treffen, ist zu spät: Jetzt muss rückwirkend nachgetragen werden.
Eine Ausnahme wird zu einem Status. „Bei diesem Kunden machen wir es anders" wirkt während der Einführung wie eine Kleinigkeit, wofür ein eigener Status oder ein eigener Deal-Typ angelegt wird. Ein Jahr später gibt es zwölf solcher Status, und kein Mitarbeiter kann den Unterschied zwischen vieren davon erklären. Jeder Status ist ein Zweig im Reporting, in den Zugriffsrechten und in der Einarbeitung neuer Mitarbeiter.
Eine mündliche Absprache wird unsichtbar. Wo früher zwei Kollegen eine Sache am Telefon klärten, zeigt das System jetzt Leere: Der Vorgang hängt im selben Status, während die Arbeit längst läuft. Formal wird der Prozess ausgeführt, faktisch läuft er am System vorbei, und die Daten darin spiegeln die Realität nicht mehr wider. In der Folge trifft die Führungskraft Entscheidungen anhand eines Reports, der nicht beschreibt, was tatsächlich passiert.
Eine Berechnung aus dem Kopf wandert in ein Freitextfeld. Sind die Berechnungsregeln vor der Einführung nicht formalisiert, entsteht im System ein Feld „Betrag", in das der Sachbearbeiter eine Zahl einträgt. Das System wirkt eingeführt, die Arithmetik bleibt jedoch manuell — mit allen Fehlern, die sie schon vorher verursacht hat.
| Was vor der Einführung nicht geklärt wurde | Wozu es wird | Wann es auffällt |
|---|---|---|
| Welche Daten Pflicht sind | Leeres Feld bei den meisten Datensätzen | Beim ersten Versuch, einen Report zu bauen |
| Was als Ausnahme gilt | Ein Dutzend Status ohne erkennbaren Unterschied | Bei der Einarbeitung eines neuen Mitarbeiters |
| Wo der Übergabepunkt zwischen Rollen liegt | Die Arbeit läuft am System vorbei | Wenn der Report von der Realität abweicht |
| Nach welcher Regel der Betrag berechnet wird | Freitextfeld für die manuelle Eingabe | Beim Abgleich mit der Buchhaltung |
| Wer Prozessverantwortlicher ist | Einstellungen ändert, wer am lautesten fordert | Nach zwei bis drei Quartalen, auf einen Schlag |
Allen fünf Zeilen ist der Zeitpunkt der Entdeckung gemeinsam. Keines der Probleme zeigt sich während des Projekts; alle tauchen erst nach dem formalen Projektabschluss auf, wenn das Einführungsteam bereits aufgelöst und das Budget verbraucht ist.
Wie verbreitet ist dieses Problem bei ERP- und CRM-Projekten
Unternehmenssoftware-Einführungen werden regelmäßig untersucht, und das Bild ist stabil: Das Problem liegt weder in der Technologie noch beim Anbieter.
Mehr als ein Viertel der Organisationen, die eine ERP-Einführung durchgeführt haben, berichteten von einer Budgetüberschreitung, fast ein Viertel von einer Überschreitung des geplanten Zeitrahmens.
Ein Vorbehalt ist hier Pflicht, und ich mache ihn selbst: Das ist der Report eines Beratungsunternehmens, das die Begleitung von ERP-Einführungen verkauft. Die Stichprobe ist nicht zufällig — die Befragten haben auf eine Einladung reagiert, ein Bias hin zu Kunden und Abonnenten des Unternehmens selbst ist wahrscheinlich. Die Zahl taugt als Größenordnung, nicht als Marktmessung.
Im Durchschnitt erreichen oder übertreffen nur 48 % der unternehmensweiten digitalen Initiativen die geplanten Geschäftsergebnisse. Bei der Gruppe von Unternehmen, die Analysten als Vorreiter der digitalen Transformation einstufen, liegt derselbe Wert bei 71 %.
Das ist eine Pressemitteilung, kein vollständiger Bericht: Erhebungsinstrument, Erhebungszeitraum und der genaue Wortlaut der Fragen sind öffentlich nicht offengelegt. Wertvoll ist hier nicht der Anteil selbst, sondern die Lücke von 23 Prozentpunkten zwischen den Vorreitern und dem Rest — sie zeigt, dass das Ergebnis nicht davon abhängt, ob ein System vorhanden ist, sondern davon, wie die Arbeit darum herum organisiert ist.
Prozessoptimierung vor Projektstart: was wir zuerst klären
Nach der dritten Einführung hat sich ein fester Satz an Vorabentscheidungen herauskristallisiert. Er ist kurz und erfordert weder einen Analysten noch ein Budget — nur die Zeit des Prozessverantwortlichen.
Die erste Entscheidung ist die unangenehmste, weil es dabei um Verbote geht. Ein Pflichtfeld bedeutet, dass jemand seine Arbeit nicht mehr auf die gewohnte Weise abschließen kann, und das erzeugt Widerstand. Aber genau Pflichtfelder liefern das Reporting, für das das System überhaupt angeschafft wurde — derselbe Mechanismus lag der Wirkung unseres Generators für Angebote zugrunde.
Die zweite Entscheidung entfernt die Freitexteingabe aus dem System überall dort, wo eine Berechnung möglich ist. Solange der Betrag von Hand eingegeben wird, gibt es keine Automatisierung — es gibt nur ein elektronisches Formular für manuelle Arbeit.
Die dritte Entscheidung betrifft die Übergabepunkte zwischen den Rollen. Jede Übergabe muss ein Ereignis im System sein, keine mündliche Absprache. Wird die Arbeit zwischen zwei Personen mündlich übergeben, zeigt das System eine Sache, während in Wirklichkeit etwas anderes passiert.
Gesondert dazu, was auf dieser Liste fehlt. Es fehlt die Ist-Aufnahme des Prozesses als zwanzigseitiges Schaubild. Eine solche Aufnahme wird fast immer erstellt, fast nie gelesen und hilft bei keiner der drei oben genannten Entscheidungen: Sie hält beobachtetes Verhalten fest, während es bei den Entscheidungen um die Norm geht. Bei unserer dritten Einführung haben wir auf die vollständige Ist-Aufnahme verzichtet und die frei gewordene Zeit in zwei Tage Klärung der Pflichtfelder investiert — das erwies sich als der einzige Vorbereitungsschritt, der das Ergebnis tatsächlich beeinflusst hat.
Der zweite Punkt, der auf der Liste fehlt, ist die Plattformwahl. Sie ist nicht sinnlos, aber zweitrangig: Alle drei Entscheidungen lassen sich für jedes gängige System gleich formulieren, und keine davon hängt vom Anbieter ab. Die Reihenfolge, bei der zuerst das System gewählt und danach der Prozess besprochen wird, garantiert, dass das Gespräch über die Norm in den Begriffen der Beschränkungen eines konkreten Produkts geführt wird — nicht in den Begriffen des Geschäfts.
Warum eine Korrektur nach dem Go-live teurer wird
Der Preisunterschied ist kein Gefühl, sondern die Arithmetik von Abhängigkeiten. Vor dem Go-live ändert sich eine Entscheidung in einem Dokument. Nach dem Go-live betrifft dieselbe Entscheidung die Konfiguration, die angesammelten Daten, die Schnittstellen, die Reports und die Gewohnheiten der Anwender, und jede dieser Ebenen erfordert eigenen Aufwand.
Bei einer Stichprobe von 1.471 IT-Projekten lag die durchschnittliche Budgetüberschreitung bei 27 %, doch jedes sechste Projekt erwies sich als „schwarzer Schwan" mit einer Budgetüberschreitung von durchschnittlich 200 %. Das Risiko konzentriert sich im Rand der Verteilung, nicht im Mittelwert.
Dieselbe Studie bespreche ich ausführlicher im Artikel über den Schätzfehler beim Arbeitsaufwand. Hier zählt ein Aspekt: Die Überschreitung ist nicht gleichmäßig verteilt. Projekte, deren Umfang von den Möglichkeiten des Systems bestimmt wurde statt von Prozessentscheidungen, landen genau in diesem Rand der Verteilung — weil jede aufgeschobene Entscheidung als ungeplante Arbeit wieder auftaucht.
Vier Fragen vor Start eines Einführungsprojekts
Ohne welche Daten ein Datensatz keinen Sinn ergibt
Eine Liste von drei bis fünf Feldern. Ist sie länger, beschreiben Sie nicht das Notwendige, sondern das Wünschenswerte.
Was das System hier berechnet
Jeder Betrag, jede Frist und jeder Status, die sich aus anderen Daten ableiten lassen, müssen abgeleitet werden, nicht eingegeben.
Wo die Arbeit den Verantwortlichen wechselt
Listen Sie die Übergabepunkte auf. Jeder muss zu einem Ereignis werden: wer übergeben hat, wer übernommen hat, wann.
Wer die Einstellungen ändern darf
Eine Person mit dem Recht, „nein" zu sagen. Ohne sie spiegelt die Konfiguration nach einem Jahr die Historie der Wünsche wider, nicht die Logik des Prozesses.
Gibt es auf alle vier Fragen noch keine Antwort, hat das Einführungsprojekt noch nicht begonnen — es läuft erst die Beschaffung.
Häufig gestellte Fragen zur Prozessaufnahme vor der Systemeinführung
Muss der Prozess vor einer CRM- oder ERP-Einführung beschrieben werden?
Eine vollständige Beschreibung ist nicht notwendig, drei Entscheidungen dagegen schon: welche Daten Pflicht sind, was das System statt des Menschen berechnet und wo die Übergabepunkte zwischen den Rollen liegen. Diese drei Entscheidungen brauchen ein paar Arbeitssitzungen des Prozessverantwortlichen und bestimmen das Ergebnis stärker als die Plattformwahl. Eine vollständige Prozessbeschreibung ohne sie rettet nichts, und mit ihnen ist sie meist überflüssig.
Lässt sich der Prozess parallel zur Einführung korrigieren?
Ja, aber dann zahlt man zweimal: erst für die Konfiguration nach der alten Ordnung, danach für die Neukonfiguration nach der neuen — samt Migration der angesammelten Daten. Die parallele Variante ist gerechtfertigt, wenn sich der Prozess ohne ein laufendes System nicht verstehen lässt — dann ist es aber ehrlicher, die erste Phase als Pilotprojekt mit von vornherein eingeplanter Überarbeitung zu bezeichnen, nicht als Einführung.
Was tun, wenn das System bereits eingeführt ist, aber die Ordnung fehlt?
Nicht alles auf einmal umkonfigurieren. Nehmen Sie einen Report, den eine Führungskraft tatsächlich nutzt, und gehen Sie ihn von unten nach oben durch: welche Felder darin einfließen, bei wie vielen Datensätzen sie gefüllt sind, woher die Werte stammen. Meist stellt sich heraus, dass es reicht, zwei bis drei Felder zu Pflichtfeldern zu machen und ein Freitextfeld zu entfernen, damit der Report wieder die Realität abbildet.
Wer sollte diese Entscheidungen treffen — die IT oder der Fachbereich?
Der Prozessverantwortliche, also derjenige, der für das Ergebnis verantwortlich ist, nicht für das System. Kennzeichen einer richtigen Aufteilung: Die IT beantwortet die Frage „wie setzen wir das um", der Prozessverantwortliche die Frage „was gilt als Norm". Trifft der Dienstleister die Entscheidung über die Pflichtfelder, wurde die Frage nach der Norm niemandem gestellt.
Die Aussage „drei von drei Einführungen begannen mit der 1:1-Übernahme des bestehenden Prozesses" bezieht sich auf CRM-Einführungen in drei Unternehmen des Autors: einer Digitalagentur (Megaplan als Erfassungssystem), einer saisonalen Fertigung für Firmengeschenke und einer Plattform für Online-Terminbuchung. Die Liste der Vorabentscheidungen und die Prozessstufen stammen aus dem Kundenkontakt-Reglement derselben Periode. Es handelt sich um internes Material des Unternehmens des Autors; es wurde nicht von unabhängiger Seite geprüft und dient als Illustration der Mechanik. Die Liste der fünf aufgeschobenen Entscheidungen und der Zeitpunkt ihrer Entdeckung wurden anhand der Erfahrung aus diesen Einführungen rekonstruiert.
- Panorama Consulting Group. The 2026 ERP Report (Umfrage unter 170 Organisationen, Januar 2025 – Januar 2026). panorama-consulting.com
- Gartner. Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets. Pressemitteilung, 22. Oktober 2024. gartner.com
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, September 2011. hbr.org