Die digitale Innovation hat sich längst von Produktlebenszyklen für industrielle Anlagen abgekoppelt. Trotzdem beschaffen viele Unternehmen ERP-Systeme als wären sie physische Güter. Das führt zu Problemen, die weit über den Beschaffungsprozess hinausgehen. Denn Beschaffung eines ERP-Systems unterscheidet sich grundlegend von der Beschaffung von Maschinen, Anlagen oder Häusern. Wer die Unterschiede versteht und berücksichtigt, leistet einen wichtigen Beitrag für den Erfolg der eigenen ERP-Einführung
Eine ERP-Einführung ist kein Hausbau
Jedem ist klar, dass die Entwicklung von Software anderen Gesetzen folgt als die von Maschinen. Anders wären das hohe Entwicklungstempo und die hohe Zahl an Innovationen in der Software-Branche nicht möglich. Trotzdem basiert die Beschaffung von Software in vielen Unternehmen heute noch auf der Wahrnehmung und der Methodik der Beschaffung von physischen Gütern. Selbst auf die ERP-Evaluation spezialisierte Berater setzen auf Methoden, die aus der Zeit stammen, als Software als ein Paket auf CD geliefert wurde.
ERP-Einführungen werden dabei implizit mit dem Bau eines Hauses verglichen: Es gibt einen Plan (Spezifikation), Rahmenbedingungen (Projektanforderungen), ein Fundament (Software-Architektur), Heizung, Elektrik (Businesslogik), Anforderungen an Design und Funktionalität usw. In diesem Bild wäre die Neuentwicklung einer ERP-Software ein individuelles Gebäude. Und die Einführung eines Software-Produkts, entspräche einem Fertighaus mit Anpassungen.
Software-Projekte, wie die Einführung eines neuen ERP-Systems, funktionieren grundlegend anders als ein Hausbau. ERP-Systeme werden i. d. R. in bestehend «Software-Landschaften» gebaut. Dabei stellt sich die Frage, was brauchen wir noch, was können wir ersetzen und was weglassen. ERP-Einführung sind Change zu vereinfachen und nicht benötigtes loszulassen um Platz für neue, kreative Lösungen zu schaffen. ERP-Einführung sind daher keine Bauprojekte.
Die folgende Tabelle zeigt einige wichtige Unterschiede zwischen Bauprojekten und ERP-Einführungen.
| Haus | Software |
|---|---|
| Erfordert wenig Engineering und viel Umsetzung (10% / 90%) | Erfordert viel Engineering und wenig Umsetzung (80% / 20%) |
| Die Anforderungen ändern sich selten | Die Anforderungen ändern sich häufig |
| Bleibt nach dem Bau weitgehend unverändert | Wird stetig weiterentwickelt |
| Funktioniert ohne Kooperation mit dem Architekten | Funktioniert nur in Kooperation mit dem Anbieter |
| Die Bauordnung und die Eigentümer stellen Anforderungen an ihr Haus | Eigentümer, Anwender, Kunden, IT-Abteilung, Rechtsabteilung uvm. stellen Anforderungenan an die Software |
| Statisches Umfeld | Dynamisches Umfeld |
Eine ERP-Einführung muss mit Dynamik umgehen können
Veränderungen sind nicht die Ausnahme sondern die Regel
Die agile Software-Entwicklung entstand auch, weil offensichtlich wurde, dass das Veränderungen in Software-Projekten die Regel und nicht die Ausnahme sind. Das hat mehrere Gründe.
Organisationen verändern sich laufend
Vor einiger Zeit durfte ich eine ERP-Evaluation in einem mittleren Industriebetrieb begleiten. Das Projekt hatte sich bereits über zehn Monate hingezogen. In dieser Zeit hatten die drei grössten Kunden des Unternehmens die Anforderungen im Bestell- und Lieferprozess zusammen fünfmal grundlegend geändert oder ergänzt. Das Projektteam musste die Änderungen in der Spezifikation jedesmal bis ins Detail nachführen und neu verteilen. Und das ist nur ein Beispiel.
Der Wandel ist der «Normalzustand». Das ändert sich auch dann nicht, wenn eine ERP-Software evaluiert oder eingeführt wird.
Neue Technologien erlauben Anbietern, ERP-Software schneller bereitzustellen
Früher stellten ERP-Softwareanbieter ihren Kunden pro Jahr in der Regel ein neues Major-Release und einige kleine Updates zur Verfügung. Heute können sie ihren Kunden in wesentlich kürzeren Abständen neue Versionen ihrer ERP-Lösung bereitstellen (kumulative Updates). Gleichzeitig wird es für Kunden einfacher, neue Funktionen zu testen und auszurollen. Was hilft es dem Kunden, wenn der System-Anbieter zwar neue Funkionen entwickelt, diese jedoch erst in neun Monaten bereitstellt? Eine schnelle Entwicklung und Bereitstellung ist sowohl im Interesse der Kunden als auch der Systemanbieter. Die ERP-Softwart unterliegt somit ebenfalls einem permanenten Wandel.
Wie Sie mit Veränderung umgehen, entscheidet sich in der ERP-Evaluation und der Vertragsgestaltung
Wer Software, wie beim Hausbau, als Werk versteht, das einmal fertiggestellt und kaum mehr angepasst wird, wird es mit Veränderungen immer schwer haben. Wer einen Software-Pflege-Vertrag abschliesst, der sich am ursprünglich spezifizierten ERP-System orientiert, fährt einen Ansatz für statische Organisationen mit statischer Software. Es mündet in den Versuch, «Moving Targets» durch Change Requests zu treffen. Change Requests sind eine langsame, aufwendige und teuere Art, mit Veränderungen umzugehen.
Wer sein ERP-Projekte als Kooperation betrachtet, in der es darum geht, Veränderungen zu gestalten und Risiken zu bearbeiten, erspart sich viel Geld, Schweiss und Tränen.
6 Tipps für moderne ERP-Einführung
In der modernen Software-Beschaffung werden Software-Partner früh in dem Projekt involviert. Dadurch wird neben der Spezifikation der ERP-Software (was wollen wir erreichen?) die Zusammenarbeit (wie erreichen wir es?) stärker ins Zentrum gerückt. Der Software-Partner erhält ein klares Bild ihres Vorhabens und der dahinterliegenden Bedürfnisse. Er kann seine Leistungen besser an den erwarteten Wertbeiträgen ausrichten und übernimmt wichtige Rollen im Umgang mit den Risiken.
Hier die sechs wichtigsten Schritte zu einer modernen Software-Beschaffung:
- Richten Sie das gesamte Software-Projekt an ihren Geschäftszielen aus (Was sind die Wertbeiträge?)
- Priorisieren Sie fortlaufend und konsequent (anhand des Nutzens für Ihre Geschäftsziele)
- Spezifizieren Sie in der ERP-Evaluation soviel, wie sie für die Auswahl des Systempartners brauchen. Die Details spezifizieren Sie wesentlich besser, wenn sie Konzepte und Technologien Ihres Softwarepartners kennen
- Definieren Sie die Art der Zusammenarbeit mit dem Systempartner durch Werte, Prinzipien und Praktiken
- Regeln Sie im Vertrag den Umgang mit Veränderungen und Risiken
- Etablieren Sie ein wirksames Framework mit Rollen, Prozessen, Phasen, Inspektionen und Abnahmen
