Original-URL des Artikels: https://www.golem.de/news/enterprise-resource-planning-drei-gruende-fuer-das-scheitern-von-sap-projekten-1902-139065.html    Veröffentlicht: 05.02.2019 12:00    Kurz-URL: https://glm.io/139065

Enterprise Resource Planning

Drei Gründe für das Scheitern von SAP-Projekten

Projekte mit der Software von SAP? Da verdrehen viele IT-Experten die Augen. Prominente Beispiele von Lidl und Haribo aus dem vergangenen Jahr scheinen diese These zu bestätigen: Gerade SAP-Projekte laufen selten in time, in budget und in quality. Dafür gibt es Gründe - und Gegenmaßnahmen.

Gleich zwei große Marken waren 2018 mit ihren SAP-Projekten in der Presse: Bei Lidl wurde ein großes SAP-Logistik-Projekt abgebrochen, weil es zu teuer war und zu wenig Nutzen brachte. Haribo kämpfte nach einer SAP-Umstellung mit Produktionsproblemen. Bei IT-Experten haben SAP-Projekte oft einen schlechten Ruf: zu komplex, häufig teurer und später fertig als erwartet.

Wenn SAP-Projekte schiefgehen, erzeugt das viel Aufmerksamkeit. Das liegt an der zentralen Rolle, die diese Software in Firmen oft spielt. Denn was für einen PC das Betriebssystem ist, liefert SAP mit seiner ERP-Lösung (Enterprise Resource Planning) für Unternehmen. Das Betriebssystem stellt die Plattform für die Verbindung von Anwendungen mit der Hardware dar, die ERP-Lösung verbindet Menschen und Prozesse mit den Produktionsanlagen im Unternehmen. Darunter fallen unternehmenskritische Prozesse wie Produktion, Versand, Finanzen, Controlling und Einkauf. Die meisten mittelständischen und großen Unternehmen setzen SAP-Lösungen ein. Treten Probleme bei der Aktivierung neuer Funktionen oder bei IT-Umstellungen auf, können die Folgen gravierend sein und nach außen spürbar.

Heute liefert SAP natürlich nicht nur ERP-Lösungen für seine Kunden. SAP-Software ist auch die Basis für viele angegliederte Bereiche, wie zum Beispiel CRM (Customer Relationsship Management), SCM (Supply Chain Management) und HCM (Human Capital Management). Viele dieser Lösungen verbindet, dass diese Prozesse ohne sie einfach nicht funktionieren. Denn: Ohne den Lieferschein verlässt kein Paket das Warenlager, ohne Fertigungsauftrag produziert keine Maschine, ohne Bestellung liefert kein Lieferant, ohne Kundendatenbank steht der Webshop. Dass diese Lösungen verfügbar sind, ist für das Unternehmen essenziell.

Dabei sind die einzelnen Teile der Software meist keine vom Rest abgeschnittenen Inseln, sondern miteinander verbunden. Das ERP-System ist sogar oft der Mittelpunkt einer vernetzten Systemlandschaft. Es stellt die Stammdaten bereit, auf die viele andere Systeme zugreifen. So liefert es den Artikelstamm für das Bestellsystem, den Personalstamm für die Zeiterfassung, die Organisationsdaten für das Active Directory. In vielen Unternehmen ist das ERP-System Dreh- und Angelpunkt für IT-Daten.

Probleme mit SAP-Software haben gravierende Auswirkungen

Dass große IT-Projekte scheitern, kommt relativ häufig vor. Laut der Chaos-Studie der Standish Group, die über Jahrzehnte den Erfolg solcher Projekte verfolgt, ist nur ein Drittel von ihnen "in time, in budget" und "in quality". Sie werden also rechtzeitig fertig und sind weder teurer noch schlechter als erwartet. Die Hälfte der Projekte ist zumindest teilweise erfolgreich, jedes fünfte wird abgebrochen.

Man könnte also sagen, SAP-Projekte laufen so wie alle IT-Projekte - nur sind die Auswirkungen von Problemen deutlicher spürbar. Grund dafür ist die schon erwähnte Verflechtung von ERP-Anwendungen mit den betriebswirtschaftlichen Prozessen. Das betrifft - je nach Branche - auch Lagersysteme, Versandsysteme, Verkaufssysteme und jede Software mit Kundenbeteiligung. Stockt die Anwendung, stockt der Prozess. Fällt zum Beispiel die zentrale ERP-Lösung über längere Zeit aus, fehlen Fertigungsaufträge in der Produktion und Rückmeldungen von den Maschinen, die Lieferung stockt und schlussendlich können Kundenaufträge nicht bedient werden.

Klar ist: Die zentrale Software in einem Unternehmen umzustellen, das ist ein komplexes Unterfangen. Allerdings gibt es ein paar immer wiederkehrende Gründe, warum ein SAP-Projekt scheitert. SAP-Projekte sind dabei in einer besonderen Kategorie: Sie betreffen zentrale und kritische IT-Systeme, sind eng mit den Kernprozessen verbunden und Probleme betreffen eine große Anzahl von Anwendern. Im Folgenden betrachten wir drei Gründe für das Scheitern von Projekten in dieser Kategorie und mögliche Gegenmaßnahmen.

Grund 1: andauernd neue Anforderungen

An einer Software-Umstellung sind viele Menschen beteiligt. Da gibt es die Fachabteilungen im Unternehmen selbst, also etwa Mitarbeiter aus der hauseigenen IT, der Produktion, dem Controlling und dem Vertrieb, und dann noch externe Berater. Sie bilden ein Projektteam, das unter anderem dafür sorgen soll, dass die fertige Software das macht, was sie soll (und zwar ungefähr zu dem Preis, den man dafür vorgesehen hat), und dass sie möglichst sofort so funktioniert, dass der Betrieb nicht aufgehalten wird.

Dass zu Beginn eines Projektes nicht alle Eventualitäten vorhergesehen werden können, ist normal. In vielen Projekten steht das Projektteam jedoch bis kurz vor dem Go-Live vor immer neuen Anforderungen. Dadurch kann es sich nie wirklich auf ein Thema konzentrieren und muss ständig den eingeschlagenen Kurs ändern.

Klassische Projektvorgehensweisen versuchen, diesem Problem durch eine klare Trennung von Konzeptphase und Umsetzungsphase zu begegnen. Der Gedanke klingt einleuchtend: In der Konzeptphase werden die Anforderungen gesammelt und die Pläne erarbeitet. Ähnlich wie beim Hausbau: Wenn der Plan steht, rückt der Bagger an. In der Umsetzungsphase werden die Pläne dann realisiert. Am Ende steht das Haus wie geplant auf dem Grundstück.

Jeder, der schon einmal ein Haus gebaut hat, weiß aber, dass das oft Wunschdenken ist: Während der Bauphase treten Probleme auf (Grundwassereinbruch, Verzögerungen, Materialengpässe), die Anforderungen ändern sich ("Ups, wir brauchen ein Kinderzimmer mehr!") oder die Bauherren entscheiden sich um ("So sieht das also aus?"). Tatsächlich besucht ein guter Architekt auch während der Bauphase immer wieder die Baustelle. Mit dem Zeichnen des Plans ist seine Arbeit nicht getan.

Ähnlich ist es bei großen IT-Projekten, die in Komplexität und Dauer gut mit dem Hausbau vergleichbar sind. Es gibt Fluktuation und Verzögerungen, die Anforderungen ändern sich (Akquise von Unternehmen, Fusionen, Reorganisationen) oder die Anwender erkennen neue Anforderungen ("So sieht das also aus?"). Man muss also davon ausgehen, dass sich die Anforderungen in einem komplexen IT-Projekt, das zudem mehrere Monate dauert, ständig ändern. Damit muss das Projektvorgehen umgehen können.

Das Projektteam braucht auch mal eine Pause

In der Software-Entwicklung haben sich dafür agile Vorgehensmodelle etabliert. Eines davon ist Scrum, das mittlerweile zum Standard für die Entwicklung geworden ist. Es garantiert dem Team einen stabilen Rahmen: Innerhalb eines Sprints (einer zeitlich begrenzten Arbeitsphase von mehreren Wochen) werden keine neuen Anforderungen angenommen. Gleichzeitig können die Anwender neue Anforderungen über das Backlog (die Anforderungsliste in Scrum) einsteuern, die bei der kommenden Sprintplanung berücksichtigt werden können.

Scrum kann auch für SAP-Projekte angewendet werden. Im Netz findet man dazu Beispiele und Erfahrungsberichte. In der aktuell empfohlenen Vorgehensweise der SAP, SAP Activate, findet sich eine Kombination aus klassischen Phasenmodellen - wie zum Beispiel das Wasserfall-Modell - und agilen Vorgehensweisen wie Scrum. Klassische Phasenmodelle gehen von stabilen Rahmenbedingungen aus und sind zu statisch für heutige Einführungsprojekte. Agile Vorgehensweisen fokussieren sich auf ein Thema, haben aber mitunter Schwierigkeiten, viele unterschiedliche Themen im Projekt miteinander zu koordinieren.

Beide Philosophien müssen im Projekt geschickt miteinander kombiniert werden. So können die Konzeptphase oder ein Pilot-Projekt durchaus nach einem klaren Wasserfallmodell abgearbeitet werden. In der Realisierung - gerade bei Eigenentwicklungen - bietet sich Scrum als Methodik an. Beim Test und Rollout können agile und klassische Vorgehensweisen kombiniert werden.

In jedem Mix müssen zwei Dinge klar sein:



Dazu muss die Projektkommunikation beitragen: Fachbereiche befürchten oft, dass nach dem Projekt keine Anforderungen mehr nachgereicht werden können. Vorausschauend sollten Projektverantwortliche deswegen bereits vor dem Go-Live ein Budget für nachträgliche Optimierungen einplanen und das auch bekanntgeben. Natürlich will man eigentlich vermeiden, dass nachträglich zu viel geändert werden muss. Manchmal führt das aber dazu, dass Projekte überfrachtet werden - womit wir beim zweiten Grund wären.

Grund 2: zu viel auf einmal

Fachbereiche werden oft mit Innovationen kurzgehalten. Entweder fehlen Budgets für die Optimierung von Prozessen oder es stellt sich eine gewisse Betriebsblindheit im eigenen Haus ein. In manchen Unternehmen werden heute noch Urlaubsanträge auf Blöcken mit Durchschlag herumgereicht.

Der Austausch der ERP-Lösung wird deswegen häufig als "Alles-wird-gut-Projekt" gesehen. Der Innovationsstau von Jahren soll dann in einem einzigen Projekt aufgelöst werden.

ERP-Projekte werden in einem Zyklus von 15 bis 20 Jahren vollständig modernisiert. Das heißt, dass heute die Systeme ausgetauscht werden, die zur Jahrtausendwende eingeführt wurden. Steht eine solche Modernisierung an, wollen viele Fachabteilungen gleich den ganz großen Sprung machen: etwa von Fax-Bestellungen zum Webshop mit automatischem Versand via Drohne.

Kommt dann noch der oben erwähnte Gedanke "Jetzt haben wir endlich mal Budget" ins Spiel, schlägt die Gier nach Features voll zu. Hinzu kommt, dass auch die IT-Berater dazu nicht nein sagen, denn solche Anforderungen sind aufregend und fordernd. So entstehen ambitionierte Lösungsarchitekturen, die jedoch an der Realität vorbei zielen. Technik, Prozesse und Mitarbeiter können diesen großen Schritt nicht mitgehen.

Rom wurde auch nicht an einem Tag erbaut

Hier hilft ein Konzept aus der Lean-Startup-Welt, deren Gedanken vor allem durch das gleichnamige Buch von Eric Ries geprägt sind. Dieses Konzept nennt sich Minimum Viable Product (MVP). Bei der Entwicklung von neuen Produkten oder Geschäftsmodellen wird also zunächst ein "minimal überlebensfähiges Produkt" entwickelt. Es enthält vor allem die Kernfunktionen.

Das MVP eines E-Mail-Clients kann zum Beispiel E-Mails senden, empfangen und anzeigen. Zusatzfunktionen wie automatische Antworten werden bewusst ausgeklammert. Das MVP wird dann der Zielgruppe präsentiert, so dass möglichst schnell das Feedback der Kunden in den weiteren Prozess einfließen kann.

Dieses Vorgehen hat mehrere positive Effekte:



Der Grundgedanke des MVP sollte auch in ERP-Projekten vorkommen. Berater und Fachbereiche sollten sich immer wieder folgende Fragen stellen: Wie kann die minimale Version der Lösung aussehen? Wie können wir den Prozess minimal darstellen? Welche Features sind für den Start essenziell?

Auch für Geschäftsprozesse kann ein MVP entwickelt und bereitgestellt werden. Um das vereinfachte Beispiel von oben noch mal aufzugreifen: Ist die Basis die Fax-Bestellung, wäre zunächst der Aufbau eines einfachen Webshops ein erstes Ziel. Funktionieren die Basisfunktionen, tastet man sich im Projekt gemeinsam weiter voran.

Auf Basis des MVP können die Anwender Erfahrungen sammeln und qualifiziertes Feedback abgeben. Voraussetzung ist lediglich die Bereitschaft, die Rückmeldungen ernst zu nehmen und das MVP konsequent weiterzuentwickeln. Das erfordert eine neue Form von Budgetierung und Projektcontrolling. Anstatt den gesamten Aufwand zu Projektbeginn zu schätzen, erfolgt zunächst der Invest in das MVP. Auf dessen Basis erfolgt eine angepasst Budgetierung für die Verbesserung der ersten Lösungsversion.

Grund 3: Babelfish? Fehlanzeige

Zu viele Änderungswünsche in zu kurzer Zeit und überambitionierte Konzepte sind also zwei Gründe, warum SAP-Projekte häufig scheitern. Der dritte Grund sind die großen Sprachbarrieren in komplexen Projekten. Dabei sind hier nicht Fremdsprachen gemeint, sondern Missverständnisse zwischen den einzelnen Fachbereichen.

Jeder Projektmanager kennt den Comic mit der Schaukel am Baum, der diese Schwierigkeiten beim Absprechen eines Projektes auf lustige Art deutlich macht. So ähnlich läuft es tatsächlich ab, wenn Fachleute aus unterschiedlichen Bereichen gemeinsam diskutieren. Der Vertrieb meint das eine, die Entwicklung hört das andere - und umgesetzt wird etwas ganz anderes. Ein Beispiel: Der Vertrieb spricht von einer Automatisierung der Abläufe, die Entwicklung baut eine Wenn-Dann-Anfrage und der Kunde freut sich auf Abläufe ohne eigene Eingaben.

Der Grund für solche Missverständnisse liegt auf der Hand: Die einzelnen Experten sind zu sehr in ihrem eigenen Kosmos gefangen. Das hat gerade bei übergreifenden Prozessen gravierende Auswirkungen. Es verschlingt viel Zeit und Geld.

Übersetzer gesucht

Um dieses Problem zu lösen oder gar nicht erst entstehen zu lassen, gilt es, zunächst zwei Dinge zu akzeptieren:



Bevor alle Experten an einem Tisch zusammenkommen, sollte zunächst die Art der Herausforderungen geklärt werden: komplex oder kompliziert. Um den Unterschied zu verstehen, hilft ein Beispiel. Der Physiker Harald Lesch hat ein gutes gefunden: Das Straßensystem von Florenz mit seinen vielen Einbahnstraßen ist kompliziert. Hat man einmal die städtische Struktur, die Straßen und ihre Fahrtrichtungen verstanden, gelangt man ohne Probleme von A nach B. Das Straßennetz ist ein Netzwerk - ein kompliziertes zwar, aber eine lösbare Aufgabe. Hängt jedoch die Richtung der Einbahnstraßen jeweils von der Verkehrsdichte ab, wird es komplex. Dann beeinflussen viele unabhängige Faktoren die Lösung.

Die Umsetzung eines Prozesses in einem IT-System ist kompliziert, eine technische Herausforderung. Der Rollout eines Prozesses in einem Unternehmen ist komplex. Hier kommen die vielen menschlichen Akteure hinzu, auf die das Projektteam kaum Einfluss hat. ERP-Projekte müssen mit beiden Dimensionen umgehen können.

Für die Lösung von komplizierten Problemen sind nur wenige Experten nötig, die die Schwierigkeiten intern in ihren Fachabteilungen ausdiskutieren können. Für die Lösung von komplexen Problemen braucht man hingegen interdisziplinäre Teams - und die richtigen Methoden.

Zwei Ansätze hierfür:



In Kombination mit schnellen Feedback-Schleifen und agilen Methoden bekommt der Kunde am Ende den Schaukelreifen am Baum, den er von Anfang an wollte, und keine Holzschaukel, Achterbahn oder den Sessel.

Wird jetzt alles gut?

Die Einführung von großen IT-Systemen - insbesondere von ERP-Systemen - ist und bleibt für Unternehmen eine Herausforderung. Hier treffen die drei Dimensionen Technik, Prozesse und Anwender aufeinander. Diese gilt es in Einklang zu bringen.

Dabei ist wichtig, dass das Projektteam zumindest während bestimmter Phasen mit neuen Anforderungen in Ruhe gelassen wird, dass die Software-Entwickler nicht zu viel wollen und dass die Kommunikation zwischen Fachabteilungen und ITlern funktioniert. Neue Ansätze wie die Scrum-Methode, das MVP und das Design Thinking helfen dabei.

Das "Alles-wird-gut-Projekt" bleibt eine Illusion. Denn gerade bei unternehmenskritischen Anwendungen sollten vor allem zwei Dinge im Vordergrund stehen: Der Betrieb muss weiter laufen und die Anwender müssen mit der neuen Software umgehen können.

Über den Autor: Markus Kammermeier ist Solution Architect Digital HR und Business Lead Digital Transformation. Bei T.CON verantwortet er als Mitglied der Geschäftsführung den Bereich Digitalisierung von IT- und HR-Lösungen. Seine HR-Erfahrung sammelte er als Personalleiter, Berater und Lösungsarchitekt. Sein Schwerpunkt liegt heute auf der Transformation von IT und HR zu innovativen Business-Lösungen. Gemeinsam mit seinem Team unterstützt Kammermeier Kunden bei der Digitalisierung der Prozesse in SAP und SuccessFactors. Zudem ist Markus Kammermeier Lehrbeauftragter an der Technischen Hochschule Deggendorf, Berater für Organisationsentwicklung, Agile Coach und Beiratsmitglied des Gründerzentrums Digitalisierung Niederbayern.  (maka)


Verwandte Artikel:
Warenwirtschaft: Gummibärchen wegen Softwareproblemen in Not   
(15.12.2018, https://glm.io/138266 )
Business Suite on Hana: SAP stellt R4 vor, das nicht so heißt   
(10.01.2013, https://glm.io/96843 )
Business ByDesign: Neue Version von SAPs On-Demand-Lösung   
(03.08.2010, https://glm.io/76943 )
SAP startet On-Demand-Geschäftssoftware   
(19.09.2007, https://glm.io/54870 )

© 1997–2019 Golem.de, https://www.golem.de/