Re Di Roma-Verlag - Der ERP

Bibliografische Information durch
Die Deutsche Bibliothek:
Die Deutsche Bibliothek verzeichnet diese Publikation in
der Deutschen Nationalbibliografie; detaillierte
bibliografische Daten sind im Internet über
http://dnb.ddb.de abrufbar.
Christian E. Riethmüller
Kompendium für ERP-System-Auswahl
und !Inbetriebnahme
Band II: Die Inbetriebnahme eines ERPSystems für Produktions- und
Handelsbetriebe
Die Fortsetzung der Leiden der
Anwender
ISBN 978-3-86870-184-5
Copyright (2011) Re Di Roma-Verlag
Alle Rechte beim Autor
www.rediroma-verlag.de
119,00 Euro
Re Di Roma-Verlag
3
4
Vorwort
Motto des Buches:
Nicht das System beherrscht das Unternehmen,
das Unternehmen beherrscht das System.
Oder:
Entscheider und Anwender müssen Verantwortung übernehmen.
Oder:
Anfang des Jahres 2007 wurde der ERP-Doktor (www.der-erpdoktor.com) im Internet eingerichtet, ein Marktplatz für Informationen
rund
um
die
ERP-Systemauswahl
und
inbetriebnahme. Der Besucher dieser Seite kann Informationen
herunterladen, zum Beispiel kompakte Pflichtenhefte oder Anforderungsprofile unterschiedlicher Anwendungsbereiche, auch
im erweiterten ERP-Umfeld, wie Qualitätssicherung (QS) oder
Produktdatenmanagement (PDM). Er kann in einem Forum
Kontakt zu anderen ERP-Anwendern aufnehmen, die sich auch
in einer Systemauswahl oder in einer Inbetriebnahmephase
befinden, die über ihre Erlebnisse in ihren Projekten berichten
wollen, die vielleicht auch nur ihrem Frust über die erlittenen
Erlebnisse, über Anbieter oder Berater freien Lauf lassen möchten.
In der ERP-Einführung stoßen die semantischen Welten von
ERP-Anbietern und Anwendern aufeinander: Hier offenbart sich,
in welchen wichtigen Themen sich die beiden Parteien während
des Auswahlverfahrens nicht verstanden, aneinander vorbeigeredet haben, funktionale Verfügbarkeiten (vollkommen) falsch
interpretiert wurden.
Mit diesem Buch will ich eine Brücke zwischen Systemlieferanten und Anwendern bauen. Es wendet sich vor allem an Unternehmen, die vor oder in einer ERP-System-Einführung/Inbetriebnahme stehen, aber auch an ERP-EinführungsProjektleiter, Beteiligte an einem ERP-Einführungsprozess, ITLeiter, Geschäftsführer, Anbieter von ERP-Systemen; ich würde
mich freuen, wenn das Buch den Charakter eines ERPInbetriebnahme-Breviers erhielte.
Die Anwendung gehört den Anwendern"
Oder:
Wir lassen uns nicht bevormunden.
Das Buch kann keine Erfahrung vermitteln, denn die muss jeder Leser bedauerlicherweise selbst sammeln, aber es ist ein
kernkompetenter Begleiter bei der Inbetriebnahme. Das Buch
vermittelt praxisbewährte Tipps; es ist das Ergebnis vieler Inbetriebnahmeprojekte und damit auch die Voraussetzung für
eine erfolgreiche Systemeinführung.
5
6
Die Vorgehensweise in einer Inbetriebnahme ist in vielen Aktivitäten und Aufgaben systemunabhängig, auch von der Größe
des einführenden Unternehmens. An mehreren Stellen der Ausführungen wird trotzdem Bezug auf Systeme bzw. Systemhersteller genommen und deren Namen genannt. Dies geschieht,
um die Unterschiedlichkeit der Systeme in der Einführung,
unter anderem hervorgerufen durch ihre Datenstrukturen und
das funktionale Angebot, beispielhaft darstellen zu können. Das
bedeutet kein Herausstellen dieser Systeme gegenüber den
vielen nicht genannten.
Ich bedanke mich für die vielfach unbewusste oder unbedachte
Unterstützung durch Systemlieferanten, Berater, Interessenten
und Kunden, die mit ihren Aussagen und markigen Sprüchen
dem Buch den richtigen Realitätsbezug und natürlich auch inhaltliche Ausrichtungen gegeben haben. Die Interessenten und
Kunden haben einen gewissen Anteil an Erfahrung ermöglicht,
weil sie manchmal entgegengesetzt arbeiten und vieles anders
organisieren, als man es sich selbst vorstellt und umsetzen
würde.
Manchmal wird in der Wir-Form geschrieben, was bedeutet,
dass hinter den konzeptionellen Gedanken des ERP-Doktors in
der Ausführung eine Firma, die CERPOS GmbH, steckt. Für die
CERPOS-Mitarbeiter ist dieses Kompendium gleichermaßen die
Arbeitsgrundlage.
Das Buch hätte auch den Titel "Die Jagd nach den Komplexitätsabstellschaltern in ERP-Systemen# tragen können, aber
diese Überschrift würden viele Leser erst nach der Lektüre verstehen. Vielleicht lernen jetzt viele Leser Kippschalter kennen,
die nur eine On-Stellung besitzen (die Off-Stellung wurde einfach vergessen).
Das Buch ist übrigens auch Begleitbuch zu dem Basis-Seminar
"ERP-System!Inbetriebnahme#, das der ERP-Doktor seit 2008
durchführt.
Christian E. Riethmüller
Ich habe mich um Aktualität bemüht und habe viele Aussagen
aus aktuellen Projekten der beiden letzten Jahre auf ihre aktuelle Relevanz geprüft.
Natürlich freue ich mich über jeden Leserkontakt, egal ob Sie
Fragen zu Themen der eigenen Inbetriebnahme haben, eine
schnelle Hilfe in einer anscheinend ausweglosen Situation benötigen oder mit System-Tipps Ihre Arbeiten abrunden möchten.
Als
Mailadresse
steht
Ihnen
hierzu
[email protected] zur Verfügung.
Auch für inhaltliche Anregungen zu diesem Buch ist der ERPDoktor dankbar, wie für die Schilderung der eigenen ERPErlebnisse. In eine Neuauflage würden dann, wenn die geneigte
Leserschaft dieses Werk stärker nachfragen sollte, auch diese
Kommentare als neue Erkenntnisse einfließen.
7
8
Inhalt
Inhalt ............................................................................. 9
Einleitung..................................................................... 15
Der Leitfaden ............................................................... 24
Zur Einstimmung in das Inbetriebnahmeprojekt .......... 28
Was dem Anwender nun bevorsteht und was er auf
seinem Weg alles findet # ........................................... 39
Vorbereitungen für die Verleihung der
Komplexitätsschalter-Zitrone und anderer Zitronen .... 47
Auszeichnungen, Zertifikate, Preise, Awards................ 47
Die Prämierung aus der Anwendersicht ..................... 49
Eine Handvoll Zitronen ........................................ 54
Was ist die Schlussfolgerung? ................................ 76
Argumentationen und Aussagen vor der
Systeminbetriebnahme stehender Anwender ............... 83
Die Entscheidung für die Go-Live-Strategie:
Big Bang oder schrittweise Einführung ...................... 102
Big Bang - Stichtagsumstellung ............................. 107
Die schrittweise Einführung ! der "sanfte# Übergang ..... 108
Mischformen................................................... 109
Ausblick ........................................................ 110
Organisation des Inbetriebnahme-Projektes ............. 111
Das Projektteam .............................................. 111
Lenkungsausschuss........................................... 114
Key-User ....................................................... 115
Kern-User...................................................... 116
Die übrigen Anwender (Info-User) .......................... 117
Das Team nach der Einführung.............................. 117
Weitere Bestandteile der Projektorganisation .............. 118
Die Erkenntnisbasis aus der Systemauswahl ............. 119
Unternehmensziele der Einführung aus der Systemauswahl
................................................................. 119
Aufbereitung der Unternehmensziele ....................... 120
9
Differenzen zwischen Bedarf und Angebot ! die Grenzen des
Systems ....................................................... 130
Die Kommunikationsbasis für alle Projektbeteiligten ..... 131
Datenqualität ................................................. 133
Datenmengen ................................................ 134
Engpässe in den Migrationsmaßnahmen ................... 136
Ohne Systemablösung: Die Datenvorbereitungen ohne
ein ERP-System im herkömmlichen Sinne ................... 137
Die Artikelstammverwaltung mit einem Tool für den
Übergang ..................................................... 140
Die Lagerbestandsverwaltung mit einem Tool für den
Übergang ..................................................... 151
Weitere Daten ................................................ 153
Projektplan für die Inbetriebnahme ........................... 157
Die Projektampel ........................................................ 173
Der erste Inbetriebnahmetermin ! die erste Planung . 175
Realisierungsziele der Inbetriebnahme .................... 176
Kosten der Inbetriebnahme ................................. 180
Die geschickte Wahl des Inbetriebnahmetermins ......... 181
Der Inbetriebnahmetermin .................................. 193
Abstimmung mit dem Betriebsrat .......................... 195
Datenschutz und Datenschutzbeauftragter ................ 197
Grobplanung ............................................................... 199
Beispiel für einen Grobprojektplan ohne
Alt-Systemablösung ......................................... 203
Beispiel für einen Grobprojektplan mit
Alt-Systemablösung ......................................... 210
Abstimmung mit dem Systemlieferanten .................. 213
Die Erstinstallation des neuen Systems ...................... 224
Die Kennenlernphase ! der erste Einstieg in das neue System
................................................................ 224
226
232
234
235
Das Customizing .............................................
Einrichtung von Test- und Schulungssystemen ...........
Regularien für Test- und Schulungs-systeme .............
Klärung der Rettung von Altdaten ..........................
10
Die Ausarbeitung der Feinkonzepte ........................... 237
Feinkonzepte ..................................................238
Mandantenkonzept ! Singlesite ! Multisite ................ 243
Beispiele für Multisite-Strukturen ........................... 246
Der Hilferuf nach dem Komplexitätsabstellschalter........ 252
Besonderheiten in den Konzepten .......................... 259
Standard oder Individualisierung............................ 262
Abstimmung der Anpassungen (Individualisierung) ....... 265
Personalisierung der Anwendung............................ 266
Datensicherungskonzept ..................................... 271
Wartung und Administration ................................. 273
Migration der Daten aus dem alten System ................ 275
Teilschritte der Datenmigration ............................. 277
Unwägbarkeiten der Datenmigration ....................... 282
Migration und Customizing .................................. 286
Artikelstamm-Migration ...................................... 288
Migration aktueller Bewegungsdaten ....................... 291
Migration von Vergangenheitsdaten ........................ 294
Abnahme der Datenmigration ............................... 296
Datenqualität ............................................................. 298
Datenqualität ! ein immer währender Prozess ............ 302
Die Daten-Inventur ........................................... 305
Das Zoomen auf die Daten ! Data-Zooming ............... 312
Die Änderung in der Bewertung des Bestandsvermögens:
Der drohende Bewertungsbruch ................................ 316
Das neue System macht es anders $....................... 316
Die Abkehr von den alten Verfahrensweisen ............... 320
Anforderungen an die Dokumentation des Umstiegs ...... 324
Der Durchschnittspreis ....................................... 328
Und wie soll nun bewertet werden? ......................... 338
Eine Basisauswertung mit Abgleich zur
Finanzbuchhaltung............................................ 342
Der Monatsabschluss ......................................... 344
11
Das Konzept der Kalkulation: Ein weiterer
Bewertungsbruch droht .............................................. 346
Das neue System macht es anders $ ...................... 346
Die Preisbasen................................................ 348
Das neue Kalkulationsschema .............................. 350
Kalkulationsphasen .......................................... 358
Die Abkehr von den alten Verfahrensweisen und die
Anforderungen an die Dokumentation des Umstiegs ..... 360
Verfahrensweise mit der neuen Kalkulation ............... 362
Belege, Schnittstellen und andere Systeme ................ 363
Belegwesen ................................................... 363
Rechungswesen .............................................. 364
Maschinendatenversorgung ................................. 364
und -erfassung (MDE) ....................................... 364
CAD und PDM................................................. 365
BoB-Systeme ................................................. 366
Business Intelligence (BI) ................................... 368
System- und Integrationstests ................................... 371
Die Auslieferungen der Anpassungen ...................... 371
Einzeltests .................................................... 372
Massentests .................................................. 373
Messung der Performance ................................... 374
Die Schulungsplanung ................................................ 379
Schulungs- oder Arbeitsplatzhandbücher ................... 381
Die Outputdellen bei Schulung und Inbetriebnahme .. 383
Schulung und Inbetriebnahme führen zu Arbeitszeitentzug
................................................................ 383
Arbeitszeitentzugsplanung .................................. 384
Die Revision des Inbetriebnahmetermins ................... 389
Die Wahl des Inbetriebnahmetermins...................... 389
Wie häufig darf sich der Termin ändern? .................. 390
Die Inbetriebnahme.................................................... 391
Dokumentationen aus dem Alt-System und der Abgleich
zum neuen System .......................................... 398
Vorbereitungen zum Systemwechsel ....................... 403
12
Und welche Inbetriebnahmehürden treten immer wieder
auf? ............................................................ 406
Der Abbruch der Inbetriebnahme und die
Rückabwicklung ......................................................... 408
Weder dem Unternehmen noch dem Systemhersteller
wird dieser Super-Gau gewünscht. ............................ 408
Der Abbruch ................................................... 409
Die Rückabwicklung .......................................... 410
Was dann?..................................................... 412
Abnahme des Systems ............................................... 414
Vertragliche Regelungen ..................................... 414
Gestaltung der Abnahme..................................... 416
Der Erfolg des Projekts .............................................. 417
Empfehlungen ! Das ERP-Projekt-Audit und das ERPAudit .......................................................................... 431
Der Autor ................................................................... 434
Anlagen ...................................................................... 436
Abbildungsverzeichnis ........................................ 436
Tabellenverzeichnis ........................................... 439
123 Leitsätze zur ERP-Inbetriebnahme ..................... 441
Gedanken zu einem Fehlermanagement-System .......... 455
Organisation der Änderungsanforderungen (Change
Requests) ...................................................... 459
Das ERP-Projekt-Audit ....................................... 464
Das ERP-Audit .................................................468
Diskussionspunkte zur Einrichtung einer eigenen SoftwareEntwicklungsumgebung ...................................... 472
Literaturverzeichnis ................................................... 478
Kurze
Inhaltsangabe
zur
ERP-Systemauswahl
[Band I des Kompendiums] ....................................... 485
13
Einleitung
Was sich in Band I zur Systemauswahl ein wenig spielerisch
las, wird in diesem Band ernsthafte Realität. Nur zu häufig erleben wir, wie nach einer Systemauswahl auf einmal unerkannte Probleme hochkommen, weil
‚ wesentliche Fragen in der Auswahlphase nicht gestellt
wurden,
‚ aufgrund der nicht einheitlichen Semantik Unternehmen
und Anbieter zwar dieselben Begriffe verwendeten, aber
in ihrer Interpretation nahezu zwangsläufig nicht deckungsgleich waren,
‚ präsentierte Funktionalität doch nicht die vermeintlich
erkannten Eigenschaften aufwies,
‚ dem Anbieter ein Vertrauensvorschuss gewährt wurde,
der sich später als nicht gerechtfertigt erweist.
Daraus ergeben sich Durchführungsschwierigkeiten und Mehraufwendungen automatisch.
Im Band I hatte ich begonnen, die "Leiden der Anwender# zu
sammeln, jetzt wird diese Sammlung fortgesetzt ! allerdings
auf einer anderen Beteiligungsebene. Denn von nun an sind alle
Mitarbeiter des Unternehmens direkt betroffen, ohne Ausnahme, von der Geschäftsleitung bis zum Gabelstaplerfahrer. Dieses Buch ist ein Angebot an die verschiedenen Anwenderunternehmen, dem Einführungsmarathon mit geringen Blessuren zu
entkommen.
Ganz nach der Philosophie des ERP-Doktors werden die Einführungsmodalitäten von ERP-Systemen neutral dargestellt, ohne
dass ein Systemvergleich stattfindet. Bei den geschilderten Inbetriebnahmemodalitäten handelt es sich um aktuelle Einführungsprojekte, die vom ERP-Doktor selbst durchgeführt wurden. Dazu kommen aber auch Projekte, die sich in der Durchführung befinden oder nur am Rande begleitet werden, sowie
Projekte, die teilweise auch mehrere Jahre zurückliegen. Die
Fehler, die bei den Inbetriebnahmen von den Einführenden ge-
15
macht werden, sind teilweise so alt wie die Inbetriebnahmeprojekte selbst.
Das Buch ist ein Leitfaden, wie ein Anwender ein neues ERPSystem einführen und in Betrieb nehmen sollte. Bezüge zu Systemen am Markt sind zufällig.
Der eine oder andere Anwender, aber auch Systemlieferant
wird sich direkt oder indirekt vielleicht wiederfinden, was
durchaus beabsichtigt ist. Außerdem dürfen sich Anbieter nicht
beschweren, wenn ihre markigen Marketing-Sprüche entsprechend berücksichtigt und in den Gesamtzusammenhang eingebaut wurden.
Wenn der Leser meint, schmunzeln zu müssen, dann ist dies
durchaus auch bezweckt; so manches Mal wird er Aussagen
finden, die vielleicht von ihm selbst geäußert wurden ! "unvorsichtigerweise#. Das Schmunzeln sollte aber nicht darüber hinwegtäuschen, dass eine Inbetriebnahme keine lässige Angelegenheit sei, sondern eine besonders harte, von Kernkompetenz
getriebene Arbeit ist. Beispiele gescheiterter Inbetriebnahmen
sollten Warnung genug sein, bringen sie doch oft Unternehmen
gehörig in Bedrängnis.
Die ERP-Inbetriebnahme ist nicht mit der Installation eines
Schreib- oder Tabellenkalkulationsprogramms zu vergleichen.
Zur Inbetriebnahme gehören nämlich auch die Organisation,
die neue Datenwelt und die neue Funktionalität, was von den
Anwendern erst einmal verinnerlicht werden muss. Dazu gesellen sich eine Prozesswelt, in die die Anwender hineinwachsen
müssen, vielleicht eine neue Benutzungsoberfläche, eventuell
ein neues Hardwaresystem oder eine virtualisierte Hardware
und vielleicht sogar ein neues Netzwerk.
Die Praxis der Inbetriebnahme bestimmt die Inhalte dieses Buches, und der Anwender wird das, was er an mancher Stelle
ungläubig liest, unweigerlich erleben und leidvoll bestätigen
müssen. Daran wird er den Inhalt des Buches zu würdigen wissen. Die Aussagen der Anwender verdeutlichen die offensichtlichen, bis zuletzt lauernden Probleme in der Inbetriebnahme.
16
Der Leser wird erleben, dass die ERP-Hersteller ihre Welt immer noch als Scheibe verstehen und sehen. Bedauerlicherweise
erreichen wir mit den angebotenen Modellen und Methoden in
den ERP-Systemen eine Trivialitäts- und Einschränkungsstufe,
die mit ihren "Mikro-Kosmen# keineswegs als realitätsnah eingestuft werden kann. Denn die technologischen Ansätze blenden derart, dass die Sicht auf die Anwendung und die Userzentrierung verloren geht.
Das neue System muss zum Unternehmen passen, es hilft
nicht, wenn das System zwar eine faszinierende Oberfläche und
Funktionalität aufweist, aber den Anforderungen des Unternehmens nicht entspricht. In der Inbetriebnahmephase wird
das Unternehmen von allen Fehlern seines Auswahlprojektes
eingeholt.
Wir werden auch sehen, wie die Semantik in dem ausgewählten
ERP-System im Konkurrenzkampf mit der Semantik des Unternehmens, einer Branche oder der wissenschaftlichen Lehre
steht. Die Systeme sind insgesamt weit von einem semantischen ERP entfernt, und man kann sich des Eindruckes nicht
erwehren, dass ERP-Hersteller gezielt auf den semantischen
Unterschied hinarbeiten.
Der Komplexitätsabstellschalter wird die gesamte Inbetriebnahmephase hindurch ein Begleiter sein, und ich wünsche allen, die eine Inbetriebnahme durchführen, dass sie diese Schalter an den Stellen ihrer Systeme finden, an denen wirklich
Komplexität abgeschaltet werden muss. Ohne auf bestimmte
Systeme anzuspielen, werden sich die Anwender häufig schwer
tun, den Kippschalter in ihre Hände zu bekommen, Erschwerend kommt hinzu, dass er manchmal technologiebedingt auch
nur über die On-Stellung verfügt. Trotzdem sollen die Anwender jederzeit den Mut haben, den Komplexitätsabstellschalter
zu fordern.
Die Inbetriebnahmeplanung ist eine besondere Aufgabe des
Projektteams, weil damit die Terminierung und der Aufwand
fixiert wird. Es wird in der Regel Termin- und Kostenabwei17
chungen geben. Doch die Projektleitung muss diese Abweichungen rechtzeitig erkennen und Strategien entwickeln und
diese Abweichungen in Grenzen zu halten. Der erste veröffentlichte Inbetriebnahmetermin sollte in Abstimmung mit dem
ERP-Lieferanten realistisch sein, zu schnell kann sich das Projektteam oder die Geschäftsleitung lächerlich machen, wenn
der pragmatische Realismus bei der Festlegung fehlt.
können bereits zu erheblichen Problemen führen, wenn es sich
beim Zielsystem um ein customizing-getriebenes System handelt. Die Schwierigkeiten, die für die Auftragsdaten abzuleiten
sind, werden sehr ausführlich behandelt, weil die Gefahr des
Datenverlusts erheblich ist. Hierzu benötigt das Unternehmen
unterschiedliche Strategien, um den drohenden Datenverlust in
Grenzen zu halten.
Der Projektplan gerät dann ins Wanken, wenn Konzepte oder
Anpassungen für die Umstellungsmaßnahmen länger als angenommen dauern oder wenn notwendige Individualisierungen
der Basislösung, des sogenannten Standards, unausweichlich
werden. Häufig haben die Anwender Mängel in der Systemauswahl nicht erkannt.
Das Migrationsergebnis bedingt den Erfolg der Inbetriebnahme;
je weniger "erfolgreich# die Daten in das neue System übertragen werden konnten, desto größer der Arbeitsaufwand für die
Mitarbeiter nach Inbetriebnahme des Systems. Sie müssen sich
dann nicht nur im neuen System zurechtfinden, sondern auch
noch die Daten so herrichten, dass sie damit arbeiten können:
Und das, obwohl sie noch längst nicht denselben Kenntnisstand
über das neue System haben, den sie einst über das alte hatten.
Die Verantwortlichen müssen aus dem Verlauf des Projektes
heraus rechtzeitig feststellen, ob es aus den Fugen gerät. Gegebenenfalls ist das Projekt so weit vorangeschritten, dass es
aus Kosten- und Termingründen unmöglich ist, den Anbieter
und damit das System zu wechseln. Unter Umständen kann es
sich aber als hilfreich erweisen, den Einführungspartner zu
wechseln. Wir werden diskutieren, an welcher Stelle die Notbremse noch gezogen werden kann. Schuldzuweisungen im
Unternehmen, aber auch zwischen den Partnern helfen jedoch
in einer derartigen Situation nicht.
Die Kommunikation zwischen allen am Einführungsprojekt Beteiligten, also Projektteam, Systemlieferant, Berater etc., muss
kontinuierlich und partnerschaftlich erfolgen. Von Anbeginn an
müssen alle Projektbeteiligten auf die Semantik achten. Gerade
Systemlieferanten tun sich damit aber oft besonders schwer,
weil ihre Mitarbeiter vollkommen in der Systemsprache verwurzelt sind. Diese entspricht häufig nicht dem Standard, so dass
eine Kommunikation auf gleichem Verständnisniveau ziemlich
schwierig wird und es oft zu gefährlichen Missverständnissen in
der Projektarbeit kommt. Zudem mangelt es auf Lieferantenseite nicht selten an der erforderlichen Einsicht.
Einen Schwerpunkt bildet die Konvertierung und Migration der
Datenbestände aus dem Alt-System. Selbst die Grunddaten
18
Zu jeder Migration gehört natürlich auch Datenqualität; je
schlechter die Daten im Alt-System geführt werden, desto geringer die Datenqualität im neuen System. Die Umsetzung der
Daten ist kein Allheilmittel, das von allein wirkt; die automatisierten Bereinigungseffekte sind in aller Regel sehr begrenzt.
Einen wichtigen Bestandteil bilden die Aktivitäten zur Erhöhung
der Datenqualität bis zur Inbetriebnahme. Hierbei wird diskutiert, wie der Anwender mit eigenen Mitteln Mängel in den
Daten entdecken und nachhaltig beseitigen kann, auch über
den Inbetriebnahmetermin hinaus.
Anwender müssen sich immer mit dem Problem der "privaten#
Daten befassen, ein Grundübel vieler Unternehmen, in denen
jeder Mitarbeiter und jede Abteilung mit einer eigenen Datenwelt von Excel-Tabellen und Access-Abfragen in Diskussionsrunden auftreten. Natürlich gehen die Besitzer dieser Datenbestände zwangsläufig davon aus, dass ihre Daten die einzig richtigen seien. Für das Anwenderunternehmen besteht nunmehr
der Zwang, diese Daten zu entprivatisieren. Dies bedeutet allerdings, dass eine Alternative zu den privaten Daten geschaffen werden muss.
19
In den Inbetriebnahmevorbereitungen sind die Bewertung von
Beständen und der Aufbau der Kalkulation als besondere
Schwerpunkte hervorzuheben. Berater behandeln beide Themen zumeist ziemlich stiefmütterlich. Diese Erkenntnis habe ich
stets in meinen ERP-Reengineering- und !Inbetriebnahmeprojekten machen dürfen. Beide Aspekte sind aber nach meinem Dafürhalten so eminent wichtig, dass ich einige Gestaltungsvorschläge diskutiere, wie man bewerten und wie ausgeprägt die Kalkulation sein sollte. Gerade hier zeigt sich die
Unterschiedlichkeit der Systeme und inwieweit sie variabel modellierbar sind.
Eines der wichtigsten Kriterien bei einer Inbetriebnahme ist der
Erhalt von Performance, nicht mit Blick auf das System, sondern bezogen auf die Mitarbeiter, wenn sie sich in ihrer neuen
Funktionalitäts-, Semantik- und Datenumgebung bewegen. Die
Verantwortlichen ignorieren leistungshemmende Einbrüche
durch die neue Anwendung häufig. Manchmal können wochenlang keine Rechnungen oder keine Lieferscheine gedruckt werden, ohne dass die Mitarbeiter für diesen Zustand verantwortlich sind. Vielmehr benötigen die Mitarbeiter eine gewisse Zeit,
bis sie sich im neuen System zurechtfinden. Die systemtechnischen Probleme, das Tagesgeschäft zu bewältigen, Kundenaufträge zu beliefern und zu fakturieren, überlagern dann gegebenenfalls die Eingewöhnungsphase, wenn wirklich keine Lieferung das Haus verlassen kann.
Wenn die Inbetriebnahme dann endlich vollzogen ist, kommen
nicht nur die Probleme des Tagesgeschäfts hoch, sondern das
Unternehmen wird sich mit den Datenübergängen beschäftigen
müssen. Diese Datenübergänge von Alt nach Neu betreffen
nicht nur den Lagerbestand oder offene Aufträge, sondern auch
die Kalkulationen, vielleicht sogar die Kontierungen, sodass in
Bewertung und Finanzbuchhaltung Brüche entstehen, die es zu
dokumentieren und zu begründen gilt. An dieser Stelle ist auch
der Wirtschaftsprüfer gefragt.
Gleich am ersten Tag der Inbetriebnahme wird es um Auftragseingang und -bestand gehen, also werden Statistiken fortzu20
schreiben sein, damit Vertrieb und Produktmanagement mit
fortgeschriebenen Daten ohne Unterbrechung weiterarbeiten
können. Kunden wollen auch am ersten Tag ihre Waren haben.
Darüber hinaus sind Rechnungen und Lieferscheine auszugeben, und die Finanzbuchhaltung ist mit Buchungen zu versorgen.
Die Inbetriebnahme führt also nicht zum "Durchschnaufen# für
das Unternehmen; man hat eine Hürde überwunden, die nächste aber, die Aufrechterhaltung des Betriebs, wartet bereits.
Natürlich beschäftige ich mich auch mit der schlimmsten Art
von Fehlschlag in einem derartigen Projekt: dem Abbruch der
Inbetriebnahme und der Rückabwicklung. Derartige Maßnahmen sind nicht selten, sie werden nur selten publiziert. Aber
man sollte mit aller Kraft versuchen, diesen Umstand nicht eintreten zu lassen. Zu viel an Glaubwürdigkeit steht auf dem
Spiel, innerhalb und außerhalb des Unternehmens.
ERP-Inbetriebnahmen scheitern zumeist nicht an der Softwarelösung, sondern eher an den mangelnden Inbetriebnahmevorbereitungen und -maßnahmen. Nicht jede Inbetriebnahmeunterstützung, die preiswert oder besonders teuer ist, ist "gut#
und führt zum Erfolg. Die Inbetriebnahme benötigt einen Regisseur, der wie in einem Film alle Drehbücher zusammenhält, die
Schauspieler lobt und zusammenstaucht, je nach Leistung und
Projektsituation. Ohne Regie kommt es zu einem experimentellen Ergebnis. Während die Beteiligten in einem Filmprojekt aber
daraus lernen können, kann es einem Unternehmen die Existenz kosten oder eine temporäre Verschlechterung der wirtschaftlichen Lage bedeuten.
Die Inbetriebnahme scheitert an der Softwarelösung, wenn sie
für den Anwender wie ein Korsett wirkt, indem er technologiebedingt durch organisatorische Modelle reglementiert wird.
Hierzu werden Eigenschaften zusammengetragen, denen man
auf Anbieterseite immer wieder begegnen kann.
Wenn der Anwender sein Projekt endlich erfolgreich in Betrieb
genommen hat, übersieht er gern, dass er den Erfolg des Pro21
jektes auch messen sollte. Vor Beginn der Inbetriebnahme sollten Geschäftsleitung und Projektteam deshalb Vorstellungen
dazu entwickeln, wie sich die Systemumstellung bewerten lässt
und wie das Zielsystem der Bewertungskriterien ausschauen
soll. Hierzu zieht man am besten qualitative und quantitative
Kriterien heran. An diesen Projektbeurteilungskriterien sollten
sich die Projektbeteiligten betriebsintern messen lassen.
Mit dem neuen System sollte das Unternehmen ein regelmäßiges ERP-Audit einführen, das die Anforderungen der Anwender
reflektiert, um funktionale und datentechnische Auswüchse zu
vermeiden. Ferner geht es auch darum, der Gefahr privater
Dateninseln zu begegnen, die Sorgen der Anwender frühzeitig
zu erkennen, Anforderungen an Weiterentwicklungen aufzunehmen und die Betreuung durch den Systemlieferanten zu
bewerten.
Ein Jahr nach der Systemnutzung empfehle ich jedem Unternehmen, sich mit einem ERP-Projekt-Audit auseinanderzusetzen. Das ERP-Projekt-Audit hat die Aufgabe, ein ERP-Projekt in
der Auswahldurchführung hinsichtlich seiner Neutralität, seiner
Budgeteinhaltung, seiner Entscheidungsfindung und -begründung zu analysieren und zu bewerten. Ferner wird die Inbetriebnahmedurchführung untersucht und der Erfolg der Inbetriebnahme geprüft. Dieses Audit findet im direkten Gespräch
mit den an der Durchführung und Entscheidung betroffenen
Fachabteilungen sowie mit der Projekt- und Geschäftsleitung
statt. Basis sind die Ausschreibungs- oder Inbetriebnahmeunterlagen.
Dieses Buch wird selbstverständlich nicht verhindern, dass ein
Projekt unter Umständen weniger erfolgreich eingeführt wird.
Sein Zweck besteht vielmehr darin, Anregungen zu liefern sowie sich mit Gedanken und Lösungsansätzen auseinanderzusetzen, die der Anwender vielleicht vergessen hätte, die er vielleicht als selbstverständlich ansieht oder die er sich gar nicht
vorstellen konnte.
22
Und dennoch: Trotz aller Bemühungen findet das Projektteam
genügend Zeit, wesentliche Fehler in der Inbetriebnahme zu
begehen.
Die Leitgedanken des Buches werden in vielen Fällen nicht eingehalten: Denn das System bestimmt den Takt, und die Mitarbeiter reagieren mechanistisch. Vielleicht resignieren sie, suchen sich Workarounds, um den Unbilden des Systems zu entgehen oder umschiffen das System mit Fantasie und auf Kosten
des Gemeinwohls. Nicht selten bemühen sich die Anwender,
das System "aufs Kreuz zu legen#, häufig machen sich die Mitarbeiter sogar einen Sport daraus.
Eines muss den Verantwortlichen des Systemeinführungsprojektes jedoch klar sein, Mitarbeiter, die resignieren und nur
noch ideenlos arbeiten, sind nicht mehr kreativ im Sinne der
Weiterentwicklung und Absicherung des Unternehmens. Mit
Resignation geht Leistungskraft des Unternehmens verloren.
Wertschaffende Beratung ist in der Inbetriebnahmephase der
wesentliche Faktor für den Gesamterfolg des Projektes. Es geht
nicht um das Einführen eines Systems auf irgendeinem Niveau,
sondern es geht um die Personalisierung des Systems auf
höchstem Niveau.
Als Pflichtlektüre für Mitarbeiter, Manager und Unternehmensleitung, aber auch für die Systemlieferanten und deren Berater
empfehle ich die Dilbert-Prinzipien von Scott Adams. Denn sie
cartoonieren das Alltägliche und bieten den Lesern gleich mehrere Spiegel an, die sie sich vorhalten können.
Das Literaturverzeichnis hat weniger den Charakter eines Zitatennachweises, als vielmehr einer Sammlung von begleitenden
ERP-Texten.
23