Re Di Roma-Verlag - Der ERP
Transcription
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