LN-Projekte für Entscheider, Teil 1: Sie haben ein Projekt gekauft, kein Auto
Das ist Teil 1 der Serie: 10 Punkte für Entscheider, die Infor LN einführen:
1. Sie haben ein Projekt gekauft, kein Auto
Und wenn Ihre Anwälte und Auswahlberater noch so sehr darauf gedrungen haben, dass sie einen Werksvertrag und keinen Dienstleistungsvertrag mit Ihrem Implementierungspartner abschließen: ERP-Einführungen sind trotzdem Projekte. Punkt. Sie können nicht einfach in den Laden gehen und sich eins’s kaufen. Es sind Projekte, mit all dem, was klassisch zu einem Projekt dazugehört. Sie sind einmalig, sie sind aufwendig, sie sind risikobehaftet.
Ihr Implementierungspartner und dessen Berater können Ihnen da durch helfen. Aber glauben Sie denen, wenn sie Sie auf die Komplexität des Unterfangens hinweisen und tun sie das nicht als Ausrede oder Inkompetenz ab. Erwarten Sie nicht, dass Sie ein fertiges Produkt kriegen, das von ein paar Beratern, die da jetzt rumschwirren werden, einfach nur eingestellt werden muss.
Ein ERP-System ist kein Auto. Kein Serienprodukt, bei dem es nur darum geht, innerhalb eines definierten Rahmens ein paar Optionen an- und auszuschalten und sich die Farbe und das Sitzleder rauszusuchen.
Wir werden später noch darauf zurück kommen: Sie, als Organisation, wissen zum Projektbeginn noch nicht, was sie brauchen. Sie werden das erst im Laufe des Projektes erarbeiten. Um beim Autobeispiel zu bleiben: Sie wissen zwar, dass Sie einen PKW haben wollen, keinen Bus und keinen Laster. Vielleicht noch, ob Sie fünf Türen brauchen oder nur drei, und ob Sie eine Sitzheizung wollen. Nur im Vergleich zum Autokauf müssen Sie im ERP-Projekt die Fahrwerksabstimmung mit Ihren Beratern selbst vornehmen. Sie müssen die Steuerungsparameter für das ABS festlegen. Sie müssen vielleicht andere Stoßdämpfer einbauen. Erst beim Einparken-Üben merken Sie, dass Sie eine elektronische Einparkhilfe brauchen, weil Sie hinten nicht raussehen, weil sie eben doch etwas kleiner sind. Oder Sie entscheiden, dass Sie stattdessen den Kofferraum verkleinern wollen und dafür eine Anhängerkupplung brauchen. Und dann kündigt sich auf einmal das dritte Kind an und das Auto muss doch wieder größer werden. Im Unterschied zum Autokauf können und müssen Sie all das im ERP-Projekt erst während des Einführungsprozesses besprechen, überlegen, entscheiden und nach nochmaligem Ausprobieren vielleicht auch umentscheiden.
Das kostet Energie und Zeit. Vergleichen Sie Ihr ERP-Projekt nicht mit dem Kauf eines Autos. Noch nichtmal mit dem Bau eines Hauses. Denken Sie lieber an sowas wie die Planung und den Bau einer Eisenbahnlinie über die Rocky Mountains.
Sind Sie der Meinung, das sollte anders sein? Diskutieren Sie mit! Und Sie dürfen den Artikel auch gerne liken oder was immer sonst man in sozialen Netzwerken mit sowas macht:
English
Sehr geehrter Herr Fuchs,
erstmal toll das Sie so ein Blog / Forum anbieten.
[… Ein ERP-System ist kein Auto. Kein Serienprodukt, …] dem möchte ich doch gerne widersprechen.
Infor LN ist eine Standardsoftware und damit vgl. zu einem Serienprodukt.
Leider gibt es so gut wie keine Berater auf dem Markt die das verstanden haben, verstehen wollen oder ansprechen dürfen.
Was will ich damit ausdrücken:
1. Die sogenannten ERP Berater leben davon Dienstleistung zu generieren. Also aus … einem Problem = eine Funktion = eine Schulung / Workshop = ein Teilprojekt … zu machen oder zu generieren … damit gezielt das Budget zu erweitern oder die Laufzeit in die Länge zu ziehen. (Mehrwert für das Beratungsunternehmen)
2. Die IT / Software ist vielfach zum Selbstzweck geworden. Weniger ist mehr. Kaum ein sog. ERP Berater wird dem Bergriff gerecht und kann das Potential der Standardsoftware in einen Mehrwert für den Kunden (Rationalisierung, Transparenz, …) umsetzten oder als messbare Kennziffer ausdrücken. … diesem Phänomen verucht man dann mit komplexen Verträgen und noch komplexeren Funktionen entgegenzuwirken.
3. Der Kunde lässt sich nicht auf das ERP System ein und vergisst das es sich ja um eine sog. Standardsoftware handelt. Nicht das ERP System sollte sich an dem Kunden ausrichten / an die Kundeprozesse angepasst werden, sondern der Kunde sollte sich nach dem ERP System richten. Das geht … verlangt aber auf allen Seiten sehr viel Abstraktionsvermögen … und klare Funktionen/Positionen bei den Protagonisten.
4. Es werden leider immer wieder die falschen Fragen gestellt und/oder die Kommunikation wird wissentlich manipuliert.
5. … u.s.w.
Grüße von einem Wegbegleiter
M. Meynen
Hallo Herr Meynen,
erstmal vielen Dank für das Lob. Mal schauen, ich hoffe, ich halte die Bloggerei (und einen Podcast soll’s ja auch noch mal geben) neben der eigentlichen Beratungsarbeit und der Familie zeitlich durch.
Inhaltlich muss ich Ihnen leider in fast allen Punkten widersprechen. Ich fürchte, Sie sitzen da einer Marketingstrategie der Beratungs- und Softwarehäuser auf. Dem schönen Schein. Diese Serie, denke ich, wird Ihnen daher noch an der einen oder anderen Stelle sauer aufstoßen. Die Wirklichkeit in den Projekten ist leider eine andere als dieser schöne Schein, an dem ich jetzt die nächsten Wochen über ein bisschen zu kratzen gedenke.
Zunächst mal, ich glaube nicht, dass ERP-Berater Interesse daran haben, auf Teufel komm raus Dienstleistung zu generieren. Die Softwarehersteller mit ihren angeschlossenen Beratungs-Businesslines sowieso nicht: Die wollen und können Software bauen und verkaufen. Das skaliert deutlich besser als Beratung. Beratung ist notwendiges Übel, weil sonst die Software keiner zum Laufen kriegt und damit auch keiner kauft. Aber Softwarehäuser wollen eigentlich keine Beratungsabteilungen. Die Beratungshäuser wollen das auch nicht. Denn erstensmal sind unsere Projektlaufzeiten viel zu lang gegenüber den Markterwartungen (und speziell auf Infor bezogen ist die Konkurrenz bei kleinen Implementierungen tatsächlich schneller). Nicht umsonst werden ERP-Projekte ja permanent im Budget überzogen. Und zweitensmal weiß doch momentan keiner, wo all die Berater herkommen sollen, für die vielen Projekte. Berater, die Kundenanforderungen aufnehmen, und in die Nutzung einer Standardsoftware mappen können, sind außerdem viel schwerer aufzutreiben und auszubilden als Softwareerklärer, die die Standardfunktionen zeigen und dann den Kunden mit der Software alleine lassen. Auch ein Beratungshaus will kurze knackige Projekte, eine Provision für den Softwareumsatz und dann lange Zeit von einem Wartungsvertag profitieren.
Die Software im Standard zu betreiben, im Optimalfall zu vermieten, nützt vor allem einem: Dem Anbieter bzw. dem Beratungshaus.
Es nützt eventuell auch EDV-Leitern, die ihre eigentliche Aufgabe, die Organisation IT-technisch bestmöglich zu unterstützen, recht bequem auf den Anbieter abwälzen können: “Wir haben hier best-of-breed-Prozesse gekauft, liebe Fachabteilungen haltet Euch einfach dran, alles ist prima (und lasst mich mit Euren konkreten Anforderungen gefälligst zufrieden).” Spart internes Knowhow, was Business-Software angeht. Am besten kauft man dann gleich SAP, das kann dann bestimmt alles. Und wenn dann die Abläufe überall hakeln und die Anwender massiv unzufrieden sind, ist’s halt wahlweise ne miese Software oder man wurde schlecht beraten. Schuld sind dann jedenfalls andere.
Verkauft wird dann gerne, dass diese tolle Software dann ja einen so immensen Mehwert, Rationalisierungseffekt etc. gegenüber dem Altsystem böte. Meiner Erfahrung nach ist dieser unmittelbare Mehrwert eher gering. Die Rechenverfahren eines ERP-Systems sind jetzt nicht unbedingt Raktentechnik. Für so ziemlich jede Funktionalität eines ERP-Systems gibt es heute Spezialsoftware, die diese Funktion besser abdeckt und vermutlich einen deutlich höheren Rationalisierungseffekt hat.
Nein, der Nutzen eines ERP-Systems liegt heute nicht mehr in der Rationalisierung von Einzelfunktionen oder von Prozessen. Er liegt darin, das “Business Control Model” softwareunterstützt zu manifestieren, und zwar bereichsübergreifend. Er liegt darin, eine durchgängige Logik und durchgängige Konzepte zu etablieren, wie der Order-to-Cash-Prozess durch die Abteilungen läuft. Und er liegt darin, als Rückgrat die diversen Spezialanwendungen (Lagersystem, BDE, APS etc.) in einen Rahmen zu zwingen, damit die nicht komplett frei drehen.
Und genau deshalb muss sich das ERP-System nach dem Business richten und nicht anders herum. Es muss genau diesen zentralen Kontrollfluss abbilden, und zwar exakt so, wie das Kundenunternehmen diesen Kontrollfluss lebt. Dagegen kann und darf man im Projekt nicht anarbeiten. Denn dieser Kontrollfluss, so wie er existiert, ist das, was das Kundenunternehmen am Markt hält. Man sollte als Berater nicht in die Hybris verfallen, zu glauben, man könne die Kundenorganisation in diesem Punkt irgendwie deutlich verbessern. Organisationen wachsen organisch/evolutionär um ihre Marktanforderungen herum, und da entstehen in der Regel passgenauere Prozesse, als man die sich auf dem grünen Tisch ausdenken könnte. Vielleicht kann man punktuelle Verbesserungen erreichen (z.B. eine Hauptplanung etablieren), aber man darf nie mit der Haltung drangehen, dass man mit der tollen Software das Geschäft grundsätzlich viel besser abbildet als das mit dem Altsystem der Fall ist, wenn sich nur einfach alles nach der Software richten würde.
In diesem Punkt widerspreche ich also ganz energisch: Nein, nicht der Kunde sollte sich nach dem ERP-System richten, sondern genau anderes herum. Denn nur dann, wenn man erwartet, dass der Kunde das tut, was die Software halt zufälligerweise kann, wird die Software zum Selbstzweck.