Der ERP Ausfall – Alle Berichten was es kostet, (fast) niemand sagt wie es verhindert wird

Die GIA Informatik aus Oftringen hat eine gute Studie erstellt, was ein ERP Ausfall kostet. Der ERP Blog von ERP Selection hat das Thema gleich aufgegriffen und seine Sicht dazu dargelegt.

Auf Linkedin empfiehlt ein Marketing Manager eines Schweizer ERP Hersteller den Link zur Studie mit den Worten „Ein wichtiges Argument, mit dem richtige ERP-System und Partner zu arbeiten.

Inside IT greift das Thema ebenfalls auf und berichtet über die Studie.

Die Ergebnisse scheinen also auf grosses Interesse zu stossen.

Das Thema wie man die Ausfälle verhindern kann wird jedoch meistens aussen vor gelassen. Einzig der Blog von ERP Selection geht in einigen Zeilen auf das Thema ein. Mir persönlich gefällt der Blog von ERP Selection zu diesem Thema sehr gut. So zeigt er auf, welche Gedanken man sich machen muss und wo es überall Auswirkung haben könnte.

Wie erlebe ich die Praxis?

In den vergangen Jahren habe ich ab und zu Systemausfälle oder Unterbrüche mitbekommen. Und hier möchte ich ansetzen und aufzeigen, wie es zu solchen Ausfällen gekommen ist. Die Liste ist nicht abschliessend und auch keine Rangliste, es zeigt aber die Fälle auf, welche ich am meisten erlebt habe.

Ausfallgrund 1: Hardware / Infrastruktur

Die Infrastruktur gibt den Geist auf. Sei es eine Harddisk vom Server oder Netzwerkkomponenten. – Dies kann mittels verschiedenen Massnahmen umgangen werden. Von redundanten Serverlandschaften bis zur Auslagerung der Infrastruktur an ein RZ ist hier vieles möglich. Da kann und will ich nicht weiter darauf eingehen, da ich definitiv nicht der Spezialist in diesem Bereich bin.

Ausfallgrund 2: Software / Konfigurationen

Mehr als einmal habe ich erlebt , dass eine Änderung am produktiven System vorgenommen wurde, welche dazu führte, dass das System oder Bereiche vom ERP System nicht mehr funktionierten. Im besten Fall stellt man dies direkt nach der Umstellung fest und kann es sogleich Rückgängig machen. Schlimmer ist es, wenn man erst Tage nach einer solchen Umstellung feststellt, dass etwas falsch läuft und das System nun fehlerhafte Daten hat. Oder wenn eben das System nicht mehr läuft und man Backups zurückspielen muss.

Ausfallgrund 3: Veraltete, nicht mehr gewartete Systeme

Es gibt Firmen die sehr lange mit dem aktualisieren von Systemen warten. Sie betreiben ihre Lösungen auf Plattformen, welche vom Hersteller nicht mehr gewartet werden. Ich hatte noch im Jahr 2014 eine Installation angetroffen, welche auf einem (virtualisierten) Windows NT betrieben wurde. Fällt eine solche Lösung aus, so kann dies zu sehr langer Ausfallzeit führen. – Dies kann man verhindern, in dem man mit aktuellen, gewarteten Lösungen arbeitet.

Was tun?

In meiner Vergangenheit hab ich den Ausfallgrund 2 am häufigsten angetroffen. Vielfach führten „Verschlimmbesserungen“ dazu, dass das System nicht mehr nutzbar war. Die Konfiguration wurde geändert, das System lief nicht mehr wie gewünscht.

Glücklicherweise kommen solche Ausfälle eher selten vor. Wenn sie jedoch vorkommen, so ärgert sich der Anwender, dass man dies nicht vorher getestet hat. So hätte man die Ausfallkosten vermeiden können.

Um diese Art von Ausfällen zu verhindern setzt man sehr häufig auf ein Testsystem. Eine autonome Installation des ERP Systems sorgt dafür, dass man allfällige Änderungen zuerst dort testen kann. Bei grösseren oder komplexen ERP Landschaften kann es auch sinnvoll sein, noch weitere Systeme (z.B. Schulungssystem oder Entwicklungssystem) im Einsatz zu haben.

Dies bringt den grossen Vorteil, dass man die gewünschten Änderungen zuerst testen kann, allfällige Auswirkungen auf Umsysteme und Schnittstellen oder andere Module werden erkannt und können ohne Zeitdruck korrigiert werden. Die Einspielungen in die produktive Umgebung kann man einplanen und die User vorgängig informieren oder schulen.

Es bringt jedoch einen gewissen Mehraufwand mit sich. Die Anpassungen müssen vom Testsystem auf das Produktive übertragen werden. Dadurch erhöht sich die Durchlaufzeit von Änderungen. Gewisse Arbeiten müssen doppelt gemacht werden.

Meiner Meinung nach ist es für KMU’s mindestens bei einem Versionswechsel zwingend notwendig, dass eine Testinstallation gemacht wird. Zu Schulungs- und Testzwecken, um Individualisierungen zu verifizieren, etc.

Ob für den laufenden Betrieb mehrere Systeme (Test-, Schulungs-, Entwicklungssystem) bei KMU notwendig sind, muss man von Fall zu Fall anschauen. Wenn eine Firma einige Tage auf ein System verzichten kann, so kann man über den Sinn dieser Systeme nachdenken.

Ich habe es schon erlebt, dass Kunden sagten, ein Systemausfall von einigen Tagen wäre kein Problem. Im Nachhinein hat sich dann herausgestellt, dass dies doch nicht ganz so einfach war.

Wichtig finde ich, wie auch schon auf dem Blog von ERP Selection zu lesen ist, dass ein Notfallkonzept vorhanden ist. Was tun wir, wenn das System ausfällt? Welche Umsysteme sind davon betroffen? Wie kann man ohne das System arbeiten?

Was hat bei Euch zu Systemausfällen geführt? Wie hätte man diese verhindern können? Habt Ihr ein solches Konzept?

 

Was macht eine ERP Einführung teuer – Welche sind die Kostentreiber einer Implementierung ?

In der Prozesskostenrechnung versucht man die Faktoren zu finden und zu verkleiner, welche den Prozess teuer machen. Die sogenannten Kostentreiber.

Ich bin der Meinung, dass es solche Kostentreiber auch in einem ERP Projekt gibt. Und diese Kostentreiber möchte ich in diesem Blog benennen. Und versuchen aufzuzeigen, wie man diese reduzieren kann. Meine Auflistung ist dabei weder abschliessend noch allgemein gültig. Es sind jedoch Punkte, welche bei meinen Projekten immer wieder aufgetaucht sind.

Ich gehe bei meinen Überlegungen davon aus, dass der Anbieter seine Hausaufgaben gemacht hat und eine korrekte Projektplanung / Projektofferte gemacht hat. Ist dies nicht der Fall, so sind die Mehrkosten sicher auch dort zu finden. Schwierig wird es vor allem dann, wenn der Anbieter davon spricht, dass er in eine neue Branche möchte und dadurch ein unschlagbares Angebot macht. Oder dass er ein Pilot für die neue Version benötigt. Oder der Anbieter verspricht Funktionen in den Gesprächen, welche dann in der Offerte nicht wieder zu finden sind. -> Das sind die Kostentreiber, welche der Anbieter verursacht, denn kein Anbieter kann Gratis arbeiten.

Im Projekt selber sind es die vermeintlich „unvorhersehbaren“ Punkte, welche zu eine ERP Einführung teuer machen. Diese Punkte kann der Anbieter trotz Pflichtenheft, Anbieterworkshop und Kostendach nur eingeschränkt abschätzen. Folgende Punkte sind als besondere Kostentreiber in einem Projekt zu betrachten:

– Datenmigration
– Selbstverwirklichung
– Terminverschiebungen
– Tests

Datenmigration – zu viel, zu oft, zu komplex, zu schlechte Altdaten, immer mehr Daten

Oft wird zu Beginn eines Projektes definiert, dass man nur die Stammdaten übernehmen möchte. Meistens war es bei mir 3-mal. Einmal zum Testen, ein zweites Mal zum Testen nach den Korrekturen und dann ins produktive System.
Die erste Schwierigkeit beginnt schon bei der Definition von Stammdaten. Jeder versteht da etwas anderes darunter. – Seien Sie bei der Definition des Pflichtenheftes oder als Anbieter bei der Erstellung der Offerte sehr genau.

Bewegungsdaten sind schwieriger zu übernehmen, da diese Daten einen Einfluss auf die ERP Funktionalitäten haben können (Durchschnittspreis, Bedarfsberechnung, Lagerbestand, etc.).

Ich mache ein Beispiel: Ein Kunde wollte für den Vorjahresvergleich in der Buchhaltung die Bewegungen des Hauptbuches des Vorjahres übernehmen. Das Altsystem konnte diese Bewegungen nicht ohne Aufwand exportieren. So musste dort der Export speziell entwickelt werden. Aufgrund von fehlerhaften Exporten wurde dieser noch drei Mal angepasst. Der Import in das neue System brauchte ebenfalls einigen Aufwand.  – Genutzt hat man diese Zahlen dann während einem Jahr. Und zwar einmal pro Monat beim Ausdrucken der Erfolgsrechnung.
Ich weiss nicht, wer diese Zahle alles benötigte. Aber ich kann abschätzen, was eine manuelle Erfassung der Kontensaldi für die vergangenen 12 Monate bedeutet hätte. Dies wäre wohl in einem Bruchteil des Aufwandes möglich gewesen. Notabene mit demselben Ergebnis. Oder man hätte die Empfänger der Zahlen auch Fragen können, ob ein Jahr lang mit einem Vergleich auf Papier gearbeitet werden kann.

Ein weiteres Beispiel von Adressdaten: Definiert war die Übernahme von Firmen und Kontaktpersonen. Die alten Daten wurden mehrfach exportiert, bis alles drin war. Danach hatte die Aussendienstmitarbeiter die Aufgabe, ihre Kunden zu prüfen und zu bereinigen. Einige Aussendienstmitarbeiter hatten leider keine Zeit die Daten zu prüfen. Oder sie wollten keine Zeit haben…. Das Ergebnis: Alter Wein in neuen Schläuchen. Dies führte zu Korrekturaufwand, Fehllieferungen, falschen Rechnungen, etc.

Beispiel Bewegungsdaten: Oft werden offene Bestellungen automatisiert übernommen. – Mit erheblichem Aufwand für den Export und den Import der Daten.

Generell: Definieren Sie im Voraus, welche Daten sie wirklich benötigen, welche Daten aktuell sind und welche Daten besser neu erfasst werden. Manchmal ist es günstiger und man hat die qualitativ besseren Daten, wenn man diese manuell erfasst.
Definieren sie, ab wann Bestellungen im neuen System erfasst werden sollen. So müssen Sie nicht unbedingt die Bestellungen übernehmen.

Dabei gilt generell zu beachten: Ich schreibe hier nicht von Grosskonzernen mit Millionen-IT-Budget. Es geht mir um KMU Betriebe, welche alle 8-10 Jahre ein neues System einführen.

Selbstverwirklichung

Es kommt immer wieder vor, dass Mitarbeiter- und / oder Consultants des Implementationspartner sich selbst verwirklichen. Jede noch so kleine Idee wird sofort umgesetzt, da sie als unternehmerisch überlebenswichtig betrachtet wird. Sei es eine Liste, ein Abfrage, eine Auswertung, eine Eingabeprüfung oder Individualisierungen. Schwierig wird es dann, wenn vor allem nicht bekannt ist, was wirklich benötigt wird.

Spätestens bei der nächsten Rechnung des Implementationspartner kommt das grosse erwachen. Wer bezahlt das nun alles?

Um das zu verhindern braucht es auf der einen Seite eine straffe Projektführung. Und auf der anderen Seite das Vertrauen in die Mitarbeiter, dass diese unternehmerisch handeln.

Gerade bei Listen, Abfragen und Individualisierungen kann man viel Zeit aufwenden. Meine Empfehlung: Nehmen Sie die Anpassungswünsche der User auf. Notieren Sie diese und arbeiten Sie danach trotzdem mit den Standardlisten, -suchen und -abfragen. Nach 3 Monaten im produktiven Betrieb kann man dann verifizieren, ob die Wünsche notwendigen sind und die Anpassungen wirklich benötigt werden. Und dann kann man diese Umsetzen. Meistens sind dann schon viele Wünsche obsolet geworden.

Verschiebungen von Terminen

Das ist relativ einfach: Aus welchen Gründen Sie auch immer das Projekt verschieben. Es kommt zu Mehrkosten. Wenn der Projektleiter 4 Stunden pro Woche für das Projekt aufwendet um es zu leiten, so kann er dies nicht plötzlich nicht mehr machen, nur weil der Go-Live ein Monat verschoben wird. Die Datenmigration muss eventuell noch einmal gemacht werden, da die Daten nicht mehr aktuell sind.

Keine Tests

Testen tun alle. Die einen vor – die anderen nach dem Start. Hier gilt es zu beachten, dass die Kosten nach dem Start extrem hoch sein können. – Testen ist nicht nur für die Prüfung der Funktionen nötig. Es gibt den User auch Sicherheit im Umgang mit dem System.
Allerdings ist es manchmal eine Gratwanderung. Ist das System zu wenig reif, so sind die User frustriert und verunsichert. Ist das System bereit, so kann es schon zu spät sein, da der Go Live kurz bevor steht. Ein Key-User System hilft. – Wie man diese Key-User am besten auswählt werde ich in einem der nächsten Blogs erörtern.

Welche Erfahrung hast Du gemacht? Was waren Deine Kostentreiber?