Standard oder massgeschneidert? Die Gretchenfrage bei der ERP-Auswahl

Standard oder massgeschneidert? Die Gretchenfrage bei der ERP-Auswahl

Berthold Wesseler

«Never change a running system», lautet eine uralte CIO-Devise. Dennoch kommt auf Dauer kein Unternehmen um die Modernisierung seines ERP-Systems herum. Sonst türmen sich irgendwann so grosse «technische Schulden» auf, dass als Radikalkur nur der Austausch des kompletten ERP-Systems bleibt – statt einer risikoärmeren und meistens auch kostengünstigeren schrittweisen Ergänzung und/oder Überarbeitung der vorhandenen Software. Technische Schulden entstehen, sobald bewusst oder unbewusst falsche oder suboptimale technische Entscheidungen getroffen werden. Die Gefahr ist gerade dann besonders gross, wenn ein ERP-System «super» läuft. Warum sollte man dann Änderungen vornehmen?

Auf zu neuen Ufern

Werden aber notwendige Änderungen versäumt, führt das später immer zu Mehraufwand, der dann Weiterentwicklungen, Erweiterungen und die normale Wartung teurer macht als eigentlich nötig. Zu dem Zeitpunkt der falschen Entscheidung hat man also technische Schulden aufgenommen, die man mit ihren Zinsen irgendwann abbezahlen muss, falls man nicht irgendwann überschuldet im Chaos enden will. Die technischen Schulden zeigen sich z. B. in schlechtem Programm-Code mit der Folge von Test- und Wartungsproblemen, fehlender Dokumentation, mangelnder Benutzerfreundlichkeit, Skalierbarkeits- und/oder Performance-Problemen sowie in regelmäs-

Berichte über spektakulär gescheiterte ERP-Projekte sorgen regelmässig für Schlagzeilen. Auch im Mittelstand führen ERPUmstellungen oft zu Problemen. Die Metall Zug Gruppe, Revlon, Haribo und Liqui Moly sind nur ein paar eklatante Beispiele von vielen; hier kam es zu Lieferengpässen, Umsatzeinbussen und Riesenstress für alle Mitarbeiter und Kunden. Das muss aber nicht sein, falls im Vorfeld die Gretchenfrage zu ERP-Systemen richtig beantwortet wird: Angepasste Standardsoftware oder massgeschneiderte Individuallösung?

sig wiederkehrenden Hardware-Engpässen. Das Design der Programmpakete, Subsysteme und Module ist uneinheitlich, komplex und passt nicht mehr mit der geplanten Anwendungsarchitektur zusammen.

Keine technischen Schulden auftürmen

Diese technischen Schulden sind durch einfaches Zählen nicht zu ermitteln und deshalb auch nur schwerer zu vermitteln. Diese Schulden können ERP-Hersteller ebenso auftürmen wie Mittelständler, die ihre Anwendungssysteme selbst entwickelt haben und in Eigenregie – vielleicht gemeinsam mit einem Systemhaus – betreiben. Gut geführte IT-Abteilungen bzw. Softwarehäuser vermeiden tunlichst, dass ihre technischen Schulden ausufern, und investieren deshalb regelmässig in die Modernisierung, Weiterentwicklung und Ergänzung ihrer ERP-Software. Allerdings ist selbst dann manchmal ein mehr oder weniger radikaler Schnitt notwendig, wie die Beispiele der Marktführer SAP, Microsoft und Oracle deutlich machen. So entstand bei SAP aus den Anfängen der «Standard-Anwendungs-Programmierung» in den 70er-Jahren über die Systeme R/2 und später R/3 das 2015 vorgestellte aktuelle System S/4 Hana. Microsoft, erst kurz nach der Jahrtausendwende über die Zukäufe von Axapta/Navision und Greatplains/Solomon Software in den ERP-Markt eingestiegen, hatte danach im Jahr 2003 mit dem Projekt «Green» die vollständige Neuentwicklung eines ERP-Systems angekündigt, sich aber später wieder umentschieden und alle vier Systeme weiterentwickelt. Heute bietet Microsoft unter dem Dach der ERP-Produktfamilie mit Dynamics 365 deren cloudbasierte Weiterentwicklungen an. Und auch Oracle will seinen durch zahlreiche Firmenkäufe entstandenen Produkt-Zoo zusammenführen und hat zu diesem Zweck die Oracle ERP Cloud lanciert.

ERP-Oldtimer haben ausgedient

Vergleichbare Initiativen gibt es auch bei den meisten mittelständischen ERP-Herstellern. Abacus, Bison, Comarch oder OPAG bieten ebensowenig «Oldtimer» aus den 80er-Jahren an wie die Gus Group, Opacc oder Soreco. Sie alle haben längst moderne Nachfolger für die Ära von «Cloud Computing», E-Commerce und «Mobile Business» entwickelt. Diese Entwicklungen der ERP-Hersteller werden natürlich nicht nur davon angetrieben, die technischen Schulden zu tilgen bzw. zu vermeiden. Sie investieren ihre Wartungseinnahmen in die Entwicklung völlig neuer Produkte, die der Kunde dann (nicht immer, aber in der Regel) neu erwerben muss; nur in Ausnahmefällen ist ein Umstieg im Rahmen des Wartungsvertrages möglich. Das sorgt immer wieder für Unmut bei den ERPKunden, die vom ERP-Hersteller verlangen, ihre Wartungsgebühren einzig und allein in die Tilgung der technischen Schulden ihrer Anwendungssysteme zu investieren. Nutzt das Unternehmen selbst entwickelte Software, gibt es diese Problematik nicht.

Einzig und allein der IT-Chef entscheidet, wann er technische Schulden aufnimmt und wann und wie er sie tilgt. Gerade Einzel-, Auftrags- und Variantenfertiger nutzen auch heute noch gern individuell programmierte Geschäftssoftware. Sie setzen insbesondere in ihrem Kerngeschäft auf Individuallösungen. Typische Beispiele dafür sind Expertensysteme in der Angebotskalkulation oder Plantafeln in der Produktionssteuerung. Hierzu muss man wissen, dass diese Mittelständler in hoch spezialisierten Nischen tätig sind. Oft fallen sie damit durch das Raster der gängigen ERP-Systeme. Vor allem dann, wenn sich die Geschäftslogik dieser Angebote an den Anforderungen der Serienfertigung orientiert. Da dies in neun von zehn Fällen der Fall ist, ist die Chance sehr hoch, dass Einzel-, Auftrags- und Variantenfertiger auf ERP-Systeme stossen, die ihre dynamischen Geschäftsabläufe allenfalls eingeschränkt abbilden.

Manpower als limitierender Faktor

Dann setzen die Mittelständler gern auf Individualsoftware, um einen allzu hohen Anpassungs- und Erweiterungsaufwand zu vermeiden – auch wenn die Zahl solcher Unternehmen von Jahr zu Jahr sinkt, weil die Manpower zum limitierenden Faktor wird und das Marktangebot an Standardsoftware kontinuierlich besser wird. Fast immer sind es wenige kluge Köpfe, die für die Entwicklung von Software verantwortlich zeichnen. Und zwar ganz gleich, ob es sich dabei um eigene Leute oder um die Mitarbeiter eines Ingenieurbüros oder Herstellers handelt. Somit besteht eine extrem hohe Abhängigkeit von wenigen Wissensträgern, was die Release-Fähigkeit und Weiterentwicklung der Systeme kaum mehr kalkulierbar macht. Gerade mit Blick auf die exponentiell steigenden Integrationsanforderungen von Industrie 4.0-Anwendungen ist dies ein hochriskanter Entwicklungspfad. Dazu kommt die Problematik der Integration vorhandener ERP-Systeme in Beschaffungs- oder Supply-Chain-Netze, denn hier ist in der Ära von E-Commerce und Realtime-Computing eine immer engere Verzahnung mit Fremdsystemen von Kunden und/oder Lieferanten gefordert. Allerdings basieren unterschiedliche ERP-Systeme immer auf unterschiedlichen Sollprozessen und damit auf völlig verschiedenen Datenmodellen. Die Verknüpfung dieser Modelle über eine offene Schnittstelle ist aufgrund der auf der Empfängerseite wegen der Datenintegrität notwendigen Validierungen ausserordentlich komplex. Dazu kommen kann auch eine (teilweise) inkompatible Datenstruktur in den Stammdaten und/oder in den Bewegungsdaten, was eine direkte Anbindung von Fremdsystemen (z. B. CRM, WMS, PIM, Online-Shop) deutlich erschwert oder gar völlig unmöglich macht.

Vielschichtige Komplexität

Daher ist die Komplexität im Zusammenspiel von ERP-Systemen sehr vielschichtig. Zum einen geht es – speziell im Mittelstand – um die sogenannten Legacy-Systeme, deren über die Jahre verwachsene programmtechnische Struktur ein reibungsloses Zusammenspiel mit modernen Systemen oft gar nicht mehr erlaubt. Zum anderen liegt es aber auch an den erwähnten Unterschieden in den Datenstrukturen und -prozessen, die eine tiefergehende Integration verhindern. Dazu kommt: Moderne ERP-Systeme werden heute als «Plattform-Technologie» verstanden, die als Basis für ein regelrechtes «Ökosystem» von Add-On-Produkten, Branchenlösungen oder Spezialanpassungen dienen kann. Solche Plattformen standardisieren dann über Common-Data-Services die Datenstrukturen in einer Art und Weise, dass innerhalb des Ökosystems ein Austausch von beispielsweise Stammdaten gar nicht mehr notwendig ist. Denn solche ERPSysteme und ergänzende CRM-, Shop-, Logistik- oder HR-Systeme, aber auch eigenentwickelte Spezialsysteme nutzen ganz automatisch und einfach allesamt die identischen Daten. Dann stellt sich auch die Gretchenfrage bei der ERP-Auswahl nicht mehr, denn eine Eigenentwicklung ist nicht mehr nötig und die Anpassung an Unternehmensspezifika einfach. ■