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?

Wie lange lebt ein ERP System ? Und was braucht es, damit es lange lebt?

Wie lange lebt ein ERP System?

Früher ging man davon aus, dass ein ERP System 8 – 10 Jahre im Einsatz ist.

Meine Erfahrung in den letzten 15 Jahren zeigt, dass viele meiner Kunden seit Jahren dieselbe Lösung einsetzen. Also auch nach 12-15 Jahren noch mit demselben System unterwegs sind.

Daneben hab ich gemerkt, dass es Kunden gibt, welche schon nach wenigen Jahren das ERP-System wieder wechseln, trotz des grossen Aufwandes für die Einführung und die Ressourcenbindung.

Ich möchte hier deshalb darauf eingehen, welche Gründe ich für die eine oder andere Variante sehe.

Weshalb sind die Systeme lange im Einsatz?
Ein System kann lang im Einsatz sein, wenn es gut unterhalten ist. Mit unterhalten meine ich, dass ein aktueller Release gefahren wird und dass das System laufend den neuen oder geänderten Anforderungen der Benutzer angepasst wird. Die gesetzlichen Anforderungen werden mit dem aktuellen Release sichergestellt, die Akzeptanz und die Unterstützung des Tagesgeschäftes werden mit der laufenden Anpassung gefördert.
Es kann sein, dass die Einführung harzig gelaufen ist und viel Reibungsverlust entstanden ist. Wenn aber der Ausbau und der Unterhalt nach der Einführung gefördert werden, so kann dies für den Einsatz des ERP Systems sehr förderlich sein. Ein regelmässiger Austausch mit und unter den (Key)User fördert das gegenseitige lernen und erhöht die Akzeptanz. Gerade auch bei Personalwechsel ist ein solcher Austausch zwingend notwendig, damit das System korrekt bedient wird und so länger betrieben werden kann.

Welche Gründe gabe es für einen Systemwechsel nach kurzer Zeit ?
Wenn eine Firma das ERP System nach kurzer Zeit wechselt, so kann die unterschiedliche Gründe haben. Zum einen können dies organisatorische Ursachen sein. Die Firma wird verkauft oder erhält eine neue strategische Ausrichtung, welche vom ERP nicht unterstützt wird.

Oder aber das System wird nicht gepflegt. Es wurde auf der Basis von Papier- oder Standardprozessen eingeführt und liefert keine Unterstützung im Arbeitsalltag. Dann muss man schon fast davon ausgehen, dass entweder bei der Evaluation oder der Einführung geschlammt wurde. Eine schlanke Einführung mit vordefinierten oder Standardprozesse kann sinnvoll sein, es ist jedoch wichtig, dass der Ausbau des Systems anschliessend kontinuierlich gefördert wird. Bei einer Einführung fehlt die Erfahrung mit dem System. Wenn man diese Erfahrung jedoch gemacht hat, so sollte man diese in die Konfiguration des System einfliessen lassen, sonst besteht die Gefahr, dass das System auf das Abstellgleis gerät.

Wurde bei der Evaluation zu wenig genau gearbeitet, so stellt man dies im laufenden Betrieb schnell fest. Das Tagesgeschäft kann mit dem System nicht abgewickelt werden. In den letzten Jahren konnte ich feststellen, dass dies vor allem bei Firmen geschehen ist, welche unstrukturiert arbeiten. Es gibt keine definierten Prozesse und jeder Mitarbeiter arbeitet ein bisschen nach seinem Gusto. Das ERP System soll dann aber bitte schön all diese (nicht definierten) Prozesse unterstützen. – Das führt dann oft zum Projektabbruch oder zu einem Systemwechsel nach kurzer Zeit.

In einem Fall hab ich es sogar erlebt, dass ein externer Berater mit dem Kunden all seine Prozesse definiert hat. Bei der Einführung wurde dann festgestellt, dass diese Prozesse gar nicht die Realität abbilden, sondern mehr oder weniger ein Papiertiger waren.

Empfehlungen daraus kann ich viele abgeben. Macht interne Usergruppen. Definiert eine Key-Userstruktur. Passt das ERP System dann Euren Bedürfnissen an, wenn es Sinn macht. Und überlegt Euch bei der Evaluation schon genau, welche Prozesse vom System unterstützt werden sollen und wie diese Prozesse wirklich aussehen.

Weshalb ein Wechsel aus meiner Sicht nach langer Zeit sinnvoll sein kann, werde in einem späteren Beitrag erläutern.

Ich wünsche Euch eine schöne Woche.

Braucht es noch einen ERP Blog?

Mit der Gründung meiner Firma habe ich beschlossen über Themen ERP Umfeld zu bloggen. Ich werde versuchen dies in regelmässigen Abständen zu tun, damit die Seite aktuell bleibt.

Es geht mir darum, dass ich mein Wissen, welches ich in über 15 Jahren ERP Projekte gewonnen habe, weitergeben kann. Mit dem Aufzeigen von begangenen Fehler sollen solche verhindert werden. Ich möchte über die Vor- und Nachteile von Lösungsansätzen, Projektteams, kritischen Situationen im Projekt, etc. schreiben. Ziel ist es, mit einem wachsamen Blick die Tätigkeiten innerhalb der Projekte zu thematisieren.

Firmen wechseln Ihr ERP-System nicht sehr oft. Und auch für den Anbieter der Lösung ist jedes Projekt einzigartig, da er den Kunden, die Branche, die Mitarbeiter, das Altsystem, die Prozesse, etc. noch nicht kennt. Und so kommen viele Risikofaktoren zusammen, welche es zu berücksichtigen gilt.

So ähnlich wie ein Coach der seine Mannschaft informiert und die Taktik erstellt, möchte ich über ERP Projekte schreiben. Deshalb der Name erpcoach.

Und deshalb: ja es braucht so ein Blog.

Gibt es ein Thema das Euch interessiert? Meldet es mir.