Donato BlandolinoSAP-Einführungen scheitern nicht an der Technologie. Sie scheitern an der Art, wie Unternehmen sie aufsetzen. Die drei häufigsten Fehler, und wie es richtig geht.
SAP-Einführungen scheitern nicht an der Technologie. Sie scheitern an der Art, wie Unternehmen sie aufsetzen. Wer SAP als IT-Projekt behandelt, bekommt ein IT-Ergebnis. Wer SAP als operative Transformation begreift, bekommt ein funktionierendes Unternehmen.
Das Muster, das sich wiederholt
In nahezu jedem SAP-Mandat, das wir bei SMART iNTERIM übernehmen, treffen wir auf dasselbe Bild: Das Programm läuft. Die Systemarchitektur ist definiert. Statusberichte sind grün. Auf dem Papier ein Vorzeigeprojekt.
In der Realität: Fachbereiche sind nicht eingebunden. Prozesse sind nicht sauber definiert. Verantwortlichkeiten sind unklar. Und trotzdem läuft das Projekt weiter, weil es ja ein IT-Projekt ist.
Warum SAP kein IT-Projekt ist
SAP S/4HANA bildet keine Prozesse ab. SAP zwingt Unternehmen, ihre Prozesse offenzulegen. Wenn Prozesse nicht klar definiert sind, nicht entschieden sind, nicht gelebt werden, dann baut man kein System. Man baut Chaos in Software.
Im Customizing werden Entscheidungen getroffen, die fachlich nie abgestimmt waren. Weil die Fachbereiche nicht entschieden haben und IT trotzdem liefern musste. Das Ergebnis sind Workarounds, Schattenprozesse und manuelle Korrekturen.
Die drei häufigsten Fehler
1. Prozesse werden nicht vor dem System definiert
Der häufigste und gleichzeitig teuerste Fehler: SAP wird implementiert, bevor die Organisation ihre Prozesse geklärt hat. Das System wird konfiguriert auf Basis von Annahmen, nicht auf Basis von Entscheidungen. Wenn diese Prozesse nicht standardisiert werden, wird SAP zum Spiegel des bestehenden Chaos, nur digital.
2. Fachbereiche werden nicht in die Verantwortung genommen
IT kann das System bauen. Was IT nicht kann: entscheiden, wie ein Unternehmen arbeiten will. Diese Entscheidung liegt bei den Fachbereichen, Produktion, Logistik, Einkauf, Planung, Qualität. Genau diese Entscheidung wird in vielen SAP-Programmen nicht eingefordert.
3. Das Projekt wird isoliert vom operativen Geschäft geführt
SAP-Programme laufen oft in einer Parallelwelt. Die Leute, die das System später nutzen sollen, sind nicht Teil des Projekts. Beim Go-Live trifft ein theoretisch konfiguriertes System auf eine operative Realität, die niemand im Projektteam aus eigener Erfahrung kennt.
Wie SMART iNTERIM SAP-Einführungen anders denkt
Unser Ansatz ist nicht technisch. Unser Ansatz ist operativ. Wir beginnen nicht beim System. Wir beginnen bei der Frage: Wie arbeitet dieses Unternehmen heute? Und wie soll es morgen arbeiten?
- Wir definieren Prozessverantwortliche, nicht Projektverantwortliche.
- Wir gehen auf den Shopfloor, bevor wir ins Customizing gehen.
- Wir fordern Entscheidungen ein, nicht Abstimmungen.
- Wir verbinden SAP mit der operativen Transformation.
Vom Shopfloor zum System, nicht umgekehrt
In einem Automotive-Mandat haben wir die SAP-Einführung bewusst umgedreht. Statt vom System her zu denken, haben wir vom Materialfluss her gedacht. Die Frage war nicht: Wie konfigurieren wir SAP? Die Frage war: Wie muss das Material durch das Werk fliessen, damit wir lieferfähig sind?
Erst als die physischen Flüsse, die Planungslogik und die Verantwortlichkeiten klar waren, haben wir begonnen, das System darauf abzubilden. Das Ergebnis: eine SAP-Konfiguration, die vom ersten Tag an operativ nutzbar war.
SAP als Spiegel der Organisation
Am Ende ist SAP S/4HANA nichts anderes als ein Spiegel. Es zeigt, wie ein Unternehmen tatsächlich arbeitet, nicht, wie es glaubt zu arbeiten.
Wenn SAP als IT-Projekt geführt wird, bekommt man ein IT-Ergebnis. Wenn SAP als Business-Projekt geführt wird, bekommt man ein funktionierendes Unternehmen.
