6	Geschäftsprozessorientierte Softwaresysteme – Planung und Anwendung

Norbert Gronau

Fragen, die in diesem Kapitel beantwortet werden:

       Warum beginnt die Suche nach einem neuen Softwaresystem meist viel zu spät?

       Welche Fehler treten bei der Auswahl geschäftsprozessorientierter Softwaresysteme auf und wie werden sie vermieden?

       Warum ist eine Betrachtung des mit dem neuen Softwaresystem verbundenen wirtschaftlichen Nutzens unerlässlich?

       Welche Rolle spielt die Projektorganisation bei der Einführung prozessorientierter Softwaresysteme?

       Wodurch zeichnen sich zukunftsfähige Systeme aus?

       Welche Fehler sind bei der Einstellung der Geschäftsprozessparameter zu vermeiden?

       Wann sind welche Umstellungsstrategien sinnvoll?

       Welche Vorteile bringt eine externe Projektsteuerung?

       Wie sind Wartung und Support für prozessorientierte Softwaresysteme zu organisieren?

       Welche Systeme können in der Cloud betrieben werden?

6.1	A usgangssituation und Herausforderungen

In Unternehmen und öffentlichen Einrichtungen aller Branchen und Größen bestimmen heute geschäftsprozessorientierte Softwaresysteme über Funktion und Flexibilität dieser Organisationen. Die Voraussetzung für einen störungsfreien Betrieb über einen langen Zeitraum – auch bei sich verändernden Anforderungen – werden in den planenden und vorbereitenden Phasen der Auswahl und Einführung dieser Softwaresysteme geschaffen. ERP-Systeme sind heute beispielsweise über einen Zeitraum von zehn bis 15 Jahren im Einsatz, bevor über eine Ablösung nachgedacht wird. Der sich anschließende Prozess erstreckt sich ebenfalls über einige Jahre. Dieses Kapitel definiert zunächst einige wesentliche geschäftsprozessorientierte Softwaresysteme, beschreibt anschließend die Auswahl und Einführung und abschließend den Betrieb prozessorientierter Softwaresysteme. Dabei wird zumeist auf ERP-Systeme Bezug genommen, denn sie stellen den größten Teil der die Geschäftsprozesse abdeckenden Systeme und sind in den allermeisten Organisationen vertreten.

6.2	Geschäftsprozessorientierte Softwaresysteme

Als geschäftsprozessorientierte Softwaresysteme werden solche betrieblichen Anwendungssysteme bezeichnet, die wesentliche Daten und Funktionen von Geschäftsprozessen abbilden. Wesentliche Vertreter dieser Systeme sind Enterprise-Resource-Planning-Systeme, die alle zur Durchführung der Geschäftsprozesse notwendigen Informationen über die Ressourcen Material, Personal, Kapazitäten (Maschinen, Handarbeitsplätze etc.), Finanzen und Information verwalten. In Abgrenzung zu speziellen Anwendungssystemen, etwa für die Fertigung, sollte ein ERP-System die Verwaltung von mindestens drei der oben genannten Ressourcen integrieren. Neben ERP-Systemen können in den Unternehmen noch weitere geschäftsprozessorientierte Softwaresysteme existieren, etwa Customer-Relationship-Ma­nagement-(CRM-)Systeme für Marketing und Vertrieb, Supply-Chain-Management-Systeme für die Logistik oder Manufacturing-Execution-Systeme (MES) bzw. Produktionsplanungs- und Steuerungssysteme (PPS-Systeme) für die Fertigung.

Wesentliches Merkmal von ERP-Systemen ist die Integration verschiedener Funktionen, Aufgaben und Daten in ein Informationssystem. Als minimaler Integrationsumfang ist eine gemeinsame Datenhaltung anzusehen. Zudem wird eine organisatorische Integration über die Software erreicht, indem Geschäftsprozesse über Abteilungsgrenzen hinaus durch das ERP-System abgebildet werden.

Die Aufgabenverteilung zwischen den im Unternehmen eingesetzten betrieblichen Informationssystemen zeigt Bild 6.1. Das ERP-System bildet dabei das Rückgrat der betrieblichen Informationsverarbeitung. Es enthält Stammdaten zu allen wichtigen Ressourcen und verzeichnet den Wertefluss sowie die Veränderungen der Bestände. ERP-Systeme existieren in einer Vielzahl von Konfigurationen, sodass die einzelnen Komponenten in Bild 6.1 je nach Anbieter und Anwendungsfall entweder separate Produkte auch anderer Anbieter sein können oder aber im ERP-System integrierte Funktionen. Daher ist ein Teil der Module stark branchenspezifisch ausgeprägt. So gibt es Laborinformationssysteme nur in der Prozessindustrie, während eine Webshop-Anbindung überwiegend für den Onlinehandel benötigt wird. MES schließlich finden sich ausschließlich in produzierenden Unternehmen.

Dem ERP-System unterlagert sind Systeme der Bürokommunikation (z. B. Groupware, Office-Lösungen) und Dokumentenmanagement- bzw. Archivierungssysteme [TMSL17]. Diese Systeme können ebenfalls Schnittstellen zum ERP-System aufweisen, etwa für die Übernahme einer Kundenanschrift in die Textverarbeitung oder für die Archivierung einer Eingangsrechnung nach erfolgter Verbuchung.

Bild 6.1 Aufgabenverteilung bei betrieblichen Informationssystemen [Gr14]

6.3	Auswahl geschäftsprozessorientierter Softwaresysteme

Immer mehr Probleme treten mit Versprechungen auf, die von den Anbietern in der Auswahlphase gegeben werden und die dann zu erheblichen Kosten- und Zeitüberschreitungen in der Einführungsphase führen, weil sie sich als nicht stichhaltig erwiesen haben.

Gemeinsam mit der Unternehmensberatung Potsdam Consulting, die im Rahmen ihrer Prozess- und Strategieberatung auch zahlreiche ERP-Auswahlprozesse begleitet hat, wurde vom Center for Enterprise Research an der Universität Potsdam ein Auswahlprozess für Business-Software entwickelt, der zahlreiche Fehler der Vergangenheit vermeidet und zu­dem wesentlich besser als früher an die individuellen Bedürfnisse der Unternehmen an­passbar ist, die z. B. ein ERP-System suchen.

6.3.1

Probleme im Auswahlverfahren

Beratungstätigkeiten sollten wertschöpfend für das beauftragende Unternehmen sein, so lautet ein Grundsatz seriöser Unternehmensberatungen. Reines „Zeitabsitzen“ ist dabei ebenso verpönt wie das Generieren möglichst zeitraubender Leistungsumfänge, selbst wenn damit kein Wert für den Auftraggeber verbunden ist. Bei Auswahlprojekten ist der tatsächlich erforderliche Aufwand nur schwer im Vorhinein abzuschätzen, übrigens ebenso wenig wie der betriebswirtschaftliche Nutzen, den das neue ERP-System bringen wird. Von daher kann es vorkommen, dass die Zeit für die Zusammenstellung der unternehmensspezifischen Anforderungen zu knapp angesetzt wurde und daher nicht alle wirklich auswahlrelevanten Anforderungen identifiziert werden konnten.

Praxistipp: Kosten für die Auswahl

Die Kosten eines Auswahlprojekts sollten möglichst zehn Prozent des späteren Einführungsaufwands nicht überschreiten.

Als falsch hat sich erwiesen, bereits ohne Kenntnis des Zielsystems eine Sollprozessgestaltung anzustoßen, ebenso falsch ist es, eine vollständige Modellierung des derzeitigen – und vermutlich bald abzulösenden – Ist-Zustands vorzunehmen. In beiden Fällen wird hoher Aufwand verursacht, obwohl Timing und Ergebnisnutzen nicht stimmen.

Bild 6.2 Probleme im Auswahlverfahren

Um sich ein Bild vom Anbieter und seinem System zu machen, sind Präsentationen in der Auswahlphase unerlässlich. Um nicht in wenig sinnvolle Standardpräsentationen des An­bieters hineinzulaufen („Ich zeig Ihnen mal die schönsten Funktionen meines Systems“), müssen knappe Szenarien aus den wichtigsten Unternehmensbereichen konzipiert werden, die Stammdaten und auswahlentscheidende Funktionen des Systems miteinander verknüpfen. Bei Zeitknappheit im Bereich der Anforderungsanalyse besteht die Gefahr, die falschen Aspekte zu Szenarien zu verdichten.

Da jedes Unternehmen und jede Organisation anders sind, laufen Auswahlverfahren, die ausschließlich auf internetbasierten Merkmalslisten mit Tausenden von Einträgen basieren, häufig in die falsche Richtung: Hier gewinnt meist das funktionsstärkste System, nicht aber das am besten passende. Allerdings erkennen die führenden Mitarbeiter der Kunden diese und andere Probleme der Auswahlphase häufig nicht. Die sogenannte „ERP-Reife“ der Unternehmen bestimmt sehr stark die Notwendigkeit einzelner Schritte im Auswahlprozess. Die ERP-Reife wird auf der Basis mehrerer Aspekte individuell ermittelt, u. a.:

       Gibt es eine (aktuelle) Prozessdokumentation und entsprechen die tatsächlichen Abläufe zumindest grob dieser Dokumentation?

       Wird schon prozessorientiert gearbeitet (abteilungsübergreifend und auf die Erzielung eines Werts für einen Kunden hin)?

       Besteht ein Bewusstsein für die Bedeutung des Stammdatenmanagements und existiert sogar ein Prozess, mit dem die Qualität der Stammdaten sichergestellt wird?

       Existieren Support- und Wartungsstrukturen, sowohl auf Anbieterseite als auch unternehmensintern (Key User)?

       Sind Erfahrungen mit ERP-Systemen vorhanden oder wird bisher überwiegend mit Tabellenkalkulationen und Textverarbeitungsprogrammen gearbeitet?

       Wie qualifiziert sind die beteiligten Mitarbeiter zu ERP-Systemen?

       Gibt es eine IT-Strategie, die ggf. sogar in die Unternehmensstrategie und das Geschäftsmodell eingebettet ist?

Jedes „Nein“ auf eine dieser Fragen führt zu einem anderen Zuschnitt des Auswahlprozesses. Auch die Einschätzung der Kunden zu den präsentierten Systemen ist bei mangelnder Erfahrung mit ERP-Systemen weniger stark zu gewichten als bei ERP-erfahrenen Benutzern. So wird beispielsweise bei mangelnder Erfahrung die Usability eines ERP-Systems nicht sachlich beurteilt, sondern ausschließlich danach, wie sehr die präsentierten Oberflächen bekannten Office-Produkten ähneln. Solche Bewertungen sind kaum für das Treffen einer Auswahlentscheidung verwendbar.

Aus der Praxis: Nicht allen ist der Begriff des ERP-Systems geläufig

Am Rande eines ERP-Auswahlverfahrens erzählt der Geschäftsführer des suchenden Unternehmens beim Mittagessen, dass er gerade auch ein Buchhaltungssystem, ein CRM-System oder eine MES-Lösung gekauft habe. Weil nach seiner Meinung diese Systeme nichts mit der ERP-Auswahl zu tun hätten, hätte er auf den Rat der Berater verzichtet. Die dann offenstehenden Münder seiner Berater interpretiert der Geschäftsführer mit gesundem Appetit und nicht mit Fassungslosigkeit.

Allerdings müssen solche Aspekte natürlich in die Systemauswahl einbezogen werden. Für 70 Kunden wird kein getrenntes CRM-System benötigt, eine integrierte Buchhaltung liefert andere Berichte als eine getrennte und manchmal ist es gut, erst das ERP-Projekt abzuschließen, bevor auch noch ein MES eingeführt wird. Aus diesem Grund sind in der Sondierungsphase eines Auswahlprojekts die IT-Landschaft aufzunehmen und auch weitere geplante IT- und Prozessprojekte zu erkennen.

Gerade bei Unternehmen, die zum ersten Mal ein ERP-System auswählen, lassen sich kaum A-Anforderungen generieren, die zur Differenzierung von Anbietern geeignet sind. Weil noch keine ausgereiften Datenstrukturen oder Prozessabläufe existieren, kommen tatsächlich viele marktverfügbare ERP-Systeme für das suchende Unternehmen infrage. Es muss also neben den differenzierenden A-Anforderungen im Auswahlprojekt unbedingt weitere Kriterien geben, nach denen Anbieter differenziert werden können. Diese können sein:

       Auszeichnungen unabhängiger Gremien,

       unabhängige Informationen über den Anbieter, etwa in seriösen Fachmedien,

       veröffentlichte Anwenderberichte aus der gleichen Branche („Success Stories“),

       Präsenz der Anbieter in der Fachöffentlichkeit.

Gelegentlich kommt es zu Irritationen, weil dem Kunden des Auswahlberaters nicht genau präsent ist, welche Beraterleistungen er tatsächlich eingekauft hat. Insbesondere bei – an sich wünschenswerten – Festpreisangeboten neigen Führungskräfte des ERP-suchenden Unternehmens dazu, weitere Leistungen einzufordern, obwohl diese weder der Sicherstellung des Auswahlziels dienen noch derzeit erforderlich sind. Diese Irritationen müssen im Vorfeld durch ein eindeutiges Angebot, ggf. mit bereits vorher erkennbaren Erweiterungs- und Kürzungsoptionen, ausgeräumt werden.

Einer der wesentlichen Gründe, warum das Center for Enterprise Research an der Universität Potsdam und z. B. die Beratung Potsdam Consulting traditionelle Auswahlverfahren kritisch beurteilen, liegt in der mangelnden Vorbereitung der Anbieter auf Kundenpräsentationen. Obwohl die Beschreibungen der zu präsentierenden Szenarien bereits Antworten auf die wichtigste Vertriebsfrage liefern („Was ist dem Kunden besonders wichtig = Wo hat er derzeit die meisten Probleme“), bereiten sich einige ERP-Anbieter nur unzureichend auf die Kundenpräsentation vor. Offenbar ist den Anbietern nicht klar, dass ein schlechter Eindruck in einer Kundenpräsentation die Chancen, den Auftrag zu gewinnen, nahezu vollständig ruiniert. Woher soll der Kunde seinen Glauben beziehen, dass es im bezahlten Einführungsprojekt besser sein würde, wenn der Anbieter bereits jetzt erhebliche Schwierigkeiten hat, innerhalb von vierzehn Tagen eine dreistündige Präsentation vorzubereiten?

Aus der Praxis: Die Schrotflintentaktik

Die im ERP-Vertrieb offenbar unausrottbare „Schrotflintentaktik“, auf die manche ERP-Vertriebler dann zurückgreifen, macht es nur noch schlimmer. Originalzitat aus einer Präsentation vor Kunden: „Nein, wir haben den im Szenario erwähnten Variantenkonfigurator nicht vorbereitet, aber dafür haben wir ein schönes Kennzahlencockpit für die Buchhaltung, das ich Ihnen jetzt zeige.“

Der mittelalterliche Pranger für ERP-Anbieter, die sich weigern, das Problem ihres Kunden zu verstehen, wäre hier hilfreich.

ERP-Auswahlverfahren werden in der Regel nicht aufgrund langfristiger strategischer Planungen durchgeführt, sondern weil der Schmerz aufgrund der unzureichenden Leistungen der gegenwärtig eingesetzten Systeme unerträglich geworden ist. Nachdem sich der Kunde – endlich – entschieden hat, ein neues ERP-System einzuführen, steht „nur noch“ der Auswahlprozess zwischen ihm und der Erreichung seines Ziels. Daher kommt es vor, dass der Kunde das Auswahlverfahren unter erheblichen Zeitdruck setzt. Beliebte Vorwände für eine enge zeitliche Planung sind ein nahender Jahreswechsel oder eine bevorstehende Gesellschafterversammlung oder Beiratssitzung. Da dieser Zeitdruck die Qualität des Auswahlverfahrens gefährdet, müssen die Auswirkungen einer nur oberflächlich vorgenommenen ERP-Auswahl unbedingt deutlich gemacht werden. Ein guter Berater lässt sich nicht vom Kunden unter Zeitdruck setzen, zumal der Zeitbedarf in der Auswahlphase wesentlich vom Antwortverhalten der Anbieter beeinflusst wird.

Während Auswahlberater den Markt, die Systeme und (hoffentlich) deren Technologie gut kennen und diese Aspekte in die Auswahl einfließen lassen, basiert die Einschätzung des Kunden weitgehend auf seinem Bauchgefühl. Sympathische Vertriebler – vielleicht sogar der gleichen Mundart mächtig – und Startbildschirme, die sonnenbelichtete Birken zeigen, die sich im Wasser spiegeln, führen dazu, dass der Kunde seine Auswahlentscheidung nach anderen Kriterien trifft als der Berater. Ein Auswahlverfahren muss diese Differenzen deutlich machen, aber vor allem auch erklären, wie der Berater zu seiner Einschätzung gelangt ist.

6.3.2

Anforderungen an ein zeitgemäßes Auswahlverfahren für Business-Software

Wichtigstes Ziel des Auswahlverfahrens ist es, das „richtige“, zum suchenden Kunden jetzt und in Zukunft passende System auszuwählen. Bestandteil dieses Ziels ist es auch, den „richtigen“, ebenso passenden Anbieter auszusuchen. Gerade bei Systemhäusern, die Branchenlösungen auf der Basis von Sage, Microsoft oder SAP anbieten, ist dies ein wichtiges Teilziel, denn die Branchenkenntnisse der Systemhäuser unterscheiden sich erheblich.

Die Entscheidung über ein neues ERP-System muss auch wirtschaftliche Erwägungen mitberücksichtigen. Auswahlverfahren, die Betriebskosten oder den betriebswirtschaftlichen Nutzen eines neuen Systems nicht einbeziehen, enthalten dem Kunden wertvolle entscheidungsrelevante Informationen vor.

Bild 6.3 Ziele der ERP-Auswahl

Schon aus ethischen Überlegungen heraus dürfen Auswahlberater nur für den Kunden wertschöpfende Beratungstätigkeiten anbieten. Hier muss auch erwähnt werden, dass sich wie auch immer geartete gleichzeitige Vertragsverhältnisse mit den Anbietern im gleichen Projekt verbieten. Wer gleichzeitig von Kunde und Anbieter Geld nimmt, setzt sich selbst bei honorigsten Absichten dem Verdacht aus, nicht das Wohl des Kunden im Auge zu haben. Wir empfehlen daher, solche Kombinationen vertraglich auszuschließen. Wertschöpfend sind nur solche Beratungstätigkeiten, die die Unsicherheit der Auswahl reduzieren und die notwendigen Informationen erzeugen, die für eine sichere Auswahl erforderlich sind. Monatelange Modellierungen des Istzustands gehören – außer bei völlig fehlender ERP-Reife – nicht dazu. Viele Berater rechnen ihre Leistungen nach zeitlichem Aufwand ab. Braucht der Berater lange, verdient er mehr Geld. Das ist unethisch. Eine Auswahlberatung sollte daher zum Festpreis angeboten werden, nachdem das für den jeweiligen Kunden geeignete Vorgehen festgelegt wurde.

Der Auswahlprozess muss zügig durchgeführt werden, da sich sonst zwischen Festlegung der auswahlrelevanten Anforderungen und deren Umsetzung in einem neuen ERP-System zu viele Veränderungen bei Produktspektrum, Organisation und Prozessen ergeben könnten, die die Einführungsdauer verlängern und verteuern.

Wirtschaftlich ist ein Auswahlprozess, wenn er sich auf die wesentlichen Anforderungen des Kunden an das neue ERP-System beschränkt und nicht alle möglichen und wünschenswerten Analysen voranstellt. Dazu müssen vor allem die individuellen gegenwärtigen und zukünftigen Bedarfe des Kunden erkannt werden. Neben der Abfrage aller Führungskräfte und der Verwendung standardisierter Checklisten sind weitere Instrumente einzusetzen.

Eingangs wurde schon dargestellt, dass die Organisationen stark unterschiedliche Reifegrade in Bezug auf den Einsatz eines ERP-Systems aufweisen. Das Auswahlverfahren muss daher zwingend an den jeweiligen ERP-Reifegrad des Kunden angepasst werden. Erfahrene Berater nutzen dazu eine Checkliste, die eine schnelle Einordnung des Kunden in ein Reifegradmodell ermöglicht.

Um Anforderungen aufzunehmen, Bedenken zu erkennen und die Ergebnisse des Entscheidungsprozesses in der Organisation zu verankern, sind Führungskräfte und Key User unbedingt zu beteiligen. Die Beteiligung kann in Mitentscheidung, Mitwirkung oder Information bestehen, je nach gelebter Kultur im Anwenderunternehmen.

Es ist erforderlich, dass der Kunde das Auswahlergebnis und sein Zustandekommen nachvollziehen kann. Da es sich bei Auswahlverfahren um multikriterielle Mehrpersonenentscheidungen handelt, die im Fall einer Realisierung erhebliche Bindungswirkung für die Organisation entfalten, muss die Nachvollziehbarkeit gegeben sein.

Ein letztes Ziel sei noch genannt, das ein wenig abseits von den oben genannten Zielen steht. Auch wenn die Auswahlentscheidung zwischen Berater und Kunde getroffen wird, ist es sinnvoll, dass die beteiligten Anbieter ebenfalls Vertrauen in die Auswahlentscheidung haben. Daher sollten Anbieter umfassend über das gewählte Verfahren und ihre jeweilige Position darin informiert werden. Unbedingt zu vermeiden ist eine Anbieterauffassung „Wir machen bei Ihrer Ausschreibung gar nicht mit, da Sie uns sowieso nie vorschlagen“, da dies das Spektrum in Frage kommender Anbieter zulasten des Kunden einschränkt.

6.3.3

Vorgehensmodell der ERP-Auswahl

Das auf den vorstehend beschriebenen Überlegungen basierende Auswahlverfahren von Potsdam Consulting und des Center for Enterprise Research an der Universität Potsdam ist in Bild 6.4 dargestellt.

Bild 6.4 Auswahlverfahren (alle Schritte)

In einer der eigentlichen ERP-Auswahl vorgelagerten Phase wird das Vorgehensmodell an die Belange des jeweiligen Kunden angepasst. Dazu wird der ERP-Reifegrad des Kunden ermittelt, die Zielsetzung, die mit dem ERP-Projekt verbunden ist (z. B. problembasiert oder wachstumsorientiert). Es wird ermittelt, welches Prozessverständnis und welche Prozessdokumentation beim Kunden vorhanden sind. Schließlich werden die vorhandene IT-Architektur und andere derzeit laufende oder geplante IT/Prozessprojekte erhoben. Basierend darauf werden diejenigen Schritte vorgeschlagen, die angesichts der ERP-Reife des Kunden angemessen sind.

Als erster inhaltlicher Schritt erfolgt eine Analyse der wichtigsten wertschöpfenden Ge­schäftsprozesse beim Kunden. Je nach Unternehmensgröße und ERP-Reife kann dies in einem Workshop erfolgen, dem eine Aufnahme der wesentlichen Abläufe folgt.

Zu jedem Auswahlprozess gehört eine ROI-Analyse der betriebswirtschaftlichen Nutzeneffekte des neuen ERP-Systems [Gr10]. Diese kann – mit leicht anderer Zielstellung – zu verschiedenen Zeitpunkten durchgeführt werden. Ein erster möglicher Zeitpunkt wäre die Erhebung der Ist-Prozesse, um mögliche in der Anbieterpräsentation vorzuführende Szenarien auch nach ihrer wirtschaftlichen Bedeutung gewichten zu können.

Nach der Erhebung der Ist-Prozesse, ggf. ergänzt durch eine ROI-Analyse, kann eine Zieldefinition für das ERP-Projekt vorgeschlagen und abgestimmt werden. Bei Entscheidungen im Verlauf der Auswahlphase kann dann wieder auf diese Grundlage zurückgegriffen werden. Dies verhindert sogenannte „Moving Targets“ mit einhergehender steigender Unzufriedenheit bei allen Beteiligten über den zunehmend schleppenden Projektverlauf.

Einer der wichtigsten Schritte im Auswahlprozess ist die Festlegung der auswahlrelevanten Anforderungen. Darunter sind diejenigen Anforderungen zu verstehen, die es gestatten, die Eignung der ERP-Systeme differenziert für den vorliegenden Fall zu bewerten. Es geht nicht darum, alle überhaupt relevanten Anforderungen zu ermitteln, sondern nur solche, die geeignete von weniger geeigneten Systemen unterscheiden. Das umfasst Funktionen, Schnittstellen, Datenmodelle und Integrationswerkzeuge, etwa zur Datenintegration oder Prozessmodellierung. Dieser Schritt baut auf der Phase „Ist-Prozesse analysieren“ auf, weil dort die auswahlrelevanten Aspekte ermittelt werden.

Das Marktscreening wird typischerweise durch die externen Berater durchgeführt, die an dieser Stelle ihre Markt- und Anbieterkenntnis einbringen. Gelegentlich beteiligen sich Anbieter an Ausschreibungen in Gebieten, auf denen sie noch wenig Erfahrungen haben, um dort vielleicht überraschend zu gewinnen. So versuchte ein Spezialist für die Prozessindustrie, ein qualifiziertes Angebot für den Maschinenbau abzugeben. Die erforderliche Entwicklungsleistung wollte er mit den Auszubildenden seines Unternehmens erbringen. Erfahrene Berater können solche Bewerbungen gleich aussondern.

Um speziell die für eine Auswahlentscheidung relevanten Datenmodelle und Funktionen beurteilen zu können, müssen nach der Festlegung der Anforderungen gemeinsam mit dem Kunden Präsentationsszenarien entwickelt werden, die es ermöglichen, in kurzer Zeit zu erkennen, welche Funktionen das System im Standard mitbringt.

Praxistipp: Auf internen Zeitaufwand achten

Effizienz bei den Präsentationen ist wichtig, weil ein Tag, an dem ca. zehn Fach- und Führungskräfte an einer ERP-Präsentation teilnehmen, ca. 5000 EUR interne Personalkosten verursacht. Wenn dann die Standardpräsentation des Anbieters gezeigt und der Standardfunktionsumfang vorgestellt wird, dann dient das nicht der Reduzierung der Unsicherheit bei der Auswahl.

Leider ist es so, dass Anbieter trotz der Entwicklung von knappen kundenspezifischen Szenarien unvorbereitet zur Präsentation beim Kunden erscheinen oder zumindest so wirken. In diesem Fall kann die Anbieterpräsentation nicht zur Erhöhung der Auswahlsicherheit beitragen. Beim Kunden wird wertvolle Zeit und Produktivität vergeudet. Übrigens vergeudet auch der Anbieter wertvolle Ressourcen; das scheint vielen Anbietern aber nicht so klar zu sein. Anstatt bei Zeitnot den Mut aufzubringen, abzusagen und einen gut vorbereiteten Termin zu vereinbaren, stürzen sich viele Anbieter in den vorzeitigen Heldentod auf offener Bühne. Aus diesem Grund ist es unumgänglich, eine zusätzliche Stufe der Qualifizierung durchzuführen, den Webcast mit dem Beraterteam. Unter nahezu realen Bedingungen wird vom Anbieter ein Dry-Run der für den Kunden vorgesehenen Funktionen anhand der vorbereiteten Szenarien durchgeführt. Dieses Vorgehen weist mehrere Vorteile auf. Zum einen können in der sachlichen Atmosphäre des Dry Run Fragen zum Kunden geklärt werden, ohne dass eine typische Vertriebssituation vorliegt. Zweitens kann eine weitere Präqualifizierung durchgeführt werden, indem nur die besten der per Webcast durchgesprochenen Systeme auch zur Kundenpräsentation eingeladen werden. Schließlich steigt die Qualität der tatsächlich beim Kunden durchgeführten Präsentationen deutlich, was auch die Abschlusswahrscheinlichkeit für den Anbieter erhöht.

Diejenigen Anbieter, die die Präqualifizierung erfolgreich durchlaufen haben, erhalten die Gelegenheit, vor ihrem potenziellen Kunden die verabredeten Szenarien zu präsentieren. Kunde und Berater bewerten die Präsentation u. a. hinsichtlich Funktionalität, Branchenkompetenz und Usability. Diese Bewertungen bilden eine wichtige Grundlage für den Entscheidungsvorschlag. Daher erhält der Anbieter vorab das zur Bewertung verwendete Kriterienblatt, damit er die Schwerpunkte seiner Präsentation daran ausrichten kann.

Während funktionale und ergonomische Aspekte sehr gut in einer Anbieterpräsentation ermittelt werden können, ist das Verhalten des Anbieters im Einführungsprojekt und seine Leistung in Wartung und Support nur durch einen Besuch von Referenzkunden zu erfragen. Daher wird empfohlen, einen Besuch bei einigen Referenzkunden des bevorzugten An­bieters an die Anbieterpräsentationen anzuschließen. Potsdam Consulting hat zu diesem Zweck eine spezielle Checkliste für Referenzbesuche entwickelt.

ERP-unsichere Key-User müssen darin geschult werden, prozessorientiert zu denken und betriebliche Abläufe in einen gedanklichen Zusammenhang zum ERP-System zu bringen. Einige Universitätsinstitute wie das ERP-Labor des Center for Enterprise Research bieten dazu ihre anbieterunabhängige Unterstützung an.

Nach Anbieterpräsentation und Referenzkundenbesuch fehlt für eine Entscheidung noch die finanzielle Sicherheit. Angebote des Anbieters nach den Präsentationen haben typischerweise nur den Charakter von Richtangeboten, können also nicht zur detaillierten Budgetplanung verwendet werden. Daher empfehlen das Center for Enterprise Research und Potsdam Consulting, einen ersten Schritt zur Realisierung bereits vor Abschluss des endgültigen Vertrags zu gehen: in einem Prozessworkshop, der die Abbildung der Sollprozesse im ERP-System klärt und vor allem den Softwareanbieter in die Lage versetzt, ein verbindliches Festpreisangebot für den Projektaufwand abzugeben. Dieser Prozessworkshop sollte alle wesentlichen Geschäftsprozesse des Unternehmens durchlaufen und dokumentieren, ob eine Umsetzung im Standard des ERP-Anbieters oder mit Modifikationen am System erfolgen kann. Idealerweise nimmt der Softwareanbieter die Dokumentation der Workshop-Ergebnisse in einem vereinbarten Format (einfaches Prozessmodell mit Angabe der Rollen und Informationssystemfunktion) vor. Auch Möglichkeit und Aufwand der Anpassung der Benutzungsoberfläche (Masken, Belege, Workflows) können in diesen Workshops schon so weit geklärt werden, dass der Anbieter den entfallenden Aufwand ermitteln kann.

Ferner hilft der Workshop dabei, einen Terminplan für das Projekt aufzustellen, weil der zeitliche Anpassungsaufwand an Prozessen und Systemen festgestellt werden kann. Je nach ERP-Reife des Anwenderunternehmens kann es erforderlich sein, eine gewisse Zeit für das Denken in Prozessen einzuplanen. Einige Beratungsunternehmen führen dazu z. B. entsprechende Übungen im Entwurf durchgängiger Geschäftsprozesse mit den Key-Usern durch.

Als Ergebnis des Prozessworkshops kann ein Lastenheft erstellt werden, das die notwendigen Funktionen, Stammdaten und Belege beschreibt und zum Bestandteil des mit dem Anbieter auszuhandelnden Vertrags wird. Es ist empfehlenswert, das Lastenheft (anders als die Prozessbeschreibungen) nicht durch den Anbieter erstellen zu lassen, sondern durch das eigene Projektteam oder den Auswahlberater.

Als Ergebnis des Prozessworkshops erstellt der Anbieter ein Festpreisangebot, das zur Basis der sich anschließenden Vertragsverhandlungen gemacht wird. Nach erfolgreichem Abschluss der Verhandlungen kann die Implementierung des neuen Systems beginnen.

Digitale Transformation und geschäftsprozessorientierte Software

Wesentliche Treiber der Digitalisierung sind die Verfügbarkeit von zusätzlichen Daten, insbesondere durch IoT-Devices, Wearables u. a. [Gr18]. Zudem stehen heute bessere Algorithmen zur Verfügung, die durch Einsatz von analytischen Verfahren oder Deep-Learning aus den verfügbaren Daten Auswertungen mit höherem Aussagegehalt (Planung, Prognose, Optimierung etc.) generieren können [Gr13a]. Die Ergebnisse dieser Analysen und Verarbeitungsvorgänge stehen wiederum weltweit zur Verfügung.

Die zusätzliche Steigerung der Performance der eingesetzten Hardware ermöglicht eine deutlich schnellere Verarbeitung und damit eine wesentlich schnellere Nutzung von durch die IT berechneten Informationen. Als technische Treiber kommen insbesondere in Unternehmenskontexten softwareintensive, eingebettete Systeme (sogenannte Cyper-physische Systeme) in Frage, die über globale Netze und Dienste weltweit miteinander verbunden sind.

Diese Entwicklungen führen zu der Möglichkeit eines direkten Informationsaustausches, einer sehr hohen Awareness über das Verhalten aller Objekte in der realen Welt, einem unmittelbaren Zugriff auf diese Objekte, die gleichzeitig durch ihre Awareness und durch ihre große Softwareverarbeitungskapazität mit einem deutlich autonomeren Verhalten ausgerüstet werden können. Alle diese Maßnahmen führen darüber hinaus zu einer höheren Anpassungsfähigkeit an Turbulenzen der Umgebung [Gr16].

Prozessorientierte Software-Systeme bilden das Rückgrat der Informationsverarbeitung in Unternehmen und anderen Organisationen. Daher müssen die Veränderungen der Arbeitsorganisation, die zuvor aufgezeigt wurden, von den Systemen begleitet und nachvollzogen werden können.

       Für den Bereich der Dematerialisierung gehört es dazu, dass die Systeme zwingend einen digitalen Schatten für jedes Produkt, jede Kapazität und jede übrige Ressource verfügbar halten müssen, entweder selbst oder über geeignet definierte und ausgewählte Parallelsysteme, wie Produktlebenszyklusmanagement-Systeme.

       Im Bereich der Destandardisierung muss das System der Zukunft in der Lage sein, alle Instanzen aller Geschäftsobjekte zu allen Ebenen der Herstellung und allen Zeitpunkten individualisiert abbilden zu können. Hier sind solche Systeme zweifellos im Vorteil, die aufgrund der schon jetzt bestehenden branchenweiten Regulierungsanforderungen individualisierter Objekte durch Seriennummern unterscheiden können.

       Die Delinearisierung schließlich führt dazu, dass die Prozesse wesentlich intensiver mit dem ERP-System gekoppelt werden müssen, um für die Nachverfolgbarkeit entsprechende Informationen zu gewinnen. Daher müssen zukünftige Systeme Prozessmodelle aufweisen, die zur Laufzeit von den Nutzern individuell angepasst werden können bzw. die auf die von den Nutzern durchgeführten tatsächlichen Prozessschritte angemessen reagieren und diese angemessen aufzeichnen können.

       Die Dehierarchisierung, d. h. die Verlagerung von Entscheidungs- und Koordinationsfunktionen aus einem hierarchisch hochgestellten System in die Koordination und Kommunikation zwischen einzelnen Objekten des digitalen Unternehmens bedeutet, dass die analytischen Fähigkeiten der Systeme stärker ausgebaut werden müssen. Zukünftige Systeme müssen Monitoring-Funktionen, Prognose-, Simulations- und Optimierungsfunktionen beinhalten.

       Als Konsequenz der Despezialisierung ist vorzusehen, dass bisher von der IT durchgeführte Aufgaben zu den Benutzern und Key-Usern wandern, Aufgaben, die bisher Mitarbeiter durchgeführt haben, wandern zu den Führungskräften, neue Fähigkeiten müssen in das Unternehmen hineingeholt werden, um den Bedarf an neuen spezialisierten Aufgaben, wie beispielsweise Analytic, Pflege der Sicherheitsexperten, Pflege der Cloud-Infrastrukturen etc. zu ermöglichen.

6.4	Best Practices bei der Einführung von geschäftsprozessorientierten Softwaresystemen

Während die Reduzierung der Auswahlsicherheit bei der Auswahl von Business Software das wesentliche Ziel darstellt, verfolgt die Einführung der neuen Lösung ein Zielbündel rund um die wirtschaftliche Abbildung der wertschöpfenden Geschäftsprozesse im neuen Softwaresystem. Dieser Beitrag beschreibt die einzelnen Aufgaben, die im Verlauf des Einführungsprozesses zu erfüllen sind, um eine erfolgreiche Systemeinführung sicherzustellen. Dabei wird ein bei der Einführung von ERP-Systemen vielfach praxiserprobtes Vorgehensmodell verfolgt.

Das generelle Vorgehen bei der ERP-Einführung entspricht der Darstellung in Bild 6.5.

Bild 6.5 Vorgehen bei der Einführung eines ERP-Systems [GFG16]

Alle Anbieter von ERP-Systemen weisen Vorgehensmodelle auf, die jedoch typischerweise auf einem hohen Aggregationsniveau angelegt sind, also drei bis fünf Phasen mit jeweils drei bis zehn Aufgaben, die in jeder Phase zu erledigen sind, enthalten. Eine Anpassung dieser Vorgehensmodelle an die konkrete Unternehmens- oder Projektsituation ist in den meisten Modellen nicht enthalten. Ebenso werden nur wenige Projekte nach den Prinzipien der agilen Softwareentwicklung durchgeführt.

Die agile Vorgehensweise kommt im Bereich der Erstellung von Anwendungen immer häufiger zum Einsatz und erzielt sehr gute Erfolge. Weiterhin beeinflusst die Wahl des Vorgehensmodells generell Laufzeit und Aufwand sowie das im Projekt zu erreichende Ergebnis sehr weitgehend. Daher sollte, wenn die Voraussetzungen erfüllt sind, eine ERP-Einführung in Form einer agilen Einführung erfolgen. Eine an ERP-Projekte angepasste Vorgehensweise [Sc15] wird im Folgenden kurz skizziert.

Ein Problem in ERP-Projekten ist, dass vorschnell von Standardfunktionen abgewichen wird. Ein Product Owner, der Anpassungswünsche priorisiert und Gesamtbudgetverantwortung hat, kann hier ein wirkungsvoller Gegenpol sein. Die Aufgaben der Key-User sind durch Interessenkonflikte geprägt. Ein Unterstützer und Schlichter (Scrum Master), der das Projekt verteidigt, aber auch Konflikte löst, kann viel zur Effektivitätssteigerung beitragen. Beide Rollen würden nach einem herkömmlichen Projektverständnis dem Projektleiter zufallen. Nach dem Scrum-Ansatz kann der Product Owner jedoch nicht der Scrum Master sein. Damit ergeben sich interessante Ansätze für eine bessere Ausbalancierung bei Zielkonflikten.

Backlog und Sprints schaffen eine zusätzliche Struktur. ERP-Projekte sind zeitlich gut strukturiert, abhängige Aufgaben in unterschiedlichen Arbeitsbereichen werden jedoch sehr schlecht abgebildet. Durch Zusammenfassung von Aufgaben in Sprints lassen sich effiziente Verbindungen herstellen. In Verbindung mit einer Sprintdynamisierung lassen sich agile Projektstrukturen schaffen. Während Aufwandsschätzungen für die Tätigkeiten der Anwendungsentwickler die Regel sind, lassen Tätigkeiten der Key-User oft derartige Schätzungen vermissen. In Verbindung mit Burndown-Analysen können Verzögerungen deutlich früher erkannt werden. Zudem können realistische Arbeitspakete gebildet werden, die Frustration vermeiden.

Durch Dynamisierung von Sprint-Teams und Sprint-Zeiten lassen sich die Scrum-Vorteile Eigenverantwortung und Flexibilität auch in ERP-Projekten erschließen. User Stories, d. h. konkrete Beschreibungen von Anwendungsfällen, bieten im Gegensatz zu definierten funktionalen Anforderungen die Freiheit, Lösungsansätze kreativ zu gestalten. Durch den iterativen Ansatz bleibt diese Freiheit im Projektverlauf bestehen.

Diese Vorgehensweise setzt jedoch ein hohes Maß an Vertrauen zwischen Anbieter und Anwender voraus, welches häufig zu Beginn der Einführungsphase nicht vorhanden ist. Möglicherweise haben in den zurückliegenden Vertragsverhandlungen Anbieter und An­wender eher gegensätzliche Positionen aufgebaut.

Grundsätzlich ist die Vorbereitung der Einführungsphase außerordentlich wichtig und als eigene Phase im Vorgehensmodell auch herauszustellen. In der Praxis stellt sich immer wieder heraus, dass eine klare Abschottung zwischen der Auswahl einerseits und der Einführung andererseits nicht sinnvoll ist. In der Einführungsphase werden wichtige Fragen abschließend geregelt, die den Liefer- und Leistungsumfang erst vollständig bestimmbar machen. Dies sind Aspekte, die eigentlich bereits in den Projektvertrag gehören. Auch kann die Auswahlsicherheit erst maximiert werden, wenn diese Informationen bekannt sind, die am Ende der Auswahlphase noch nicht unbedingt vorliegen. Daher ist es ratsam, keine strikte Trennung zwischen Auswahl und Einführung vorzunehmen und insbesondere darauf zu achten, dass bei Auswahlprojekten nur solche Berater herangezogen werden, die in der Lage sind, kompetent und mithilfe von abgesicherten Methoden auch die Einführungsphase angemessen zu begleiten [Gr16].

Die Vorbereitung der Einführung

Die Vorbereitungsphase zwischen Auswahl und dem tatsächlichen Beginn der Einführung ist extrem wichtig. In dieser Phase werden wesentliche Entscheidungen getroffen, die Aufwand, Ergebnis und Zeitbedarf für die nachfolgende Einführungsphase erheblich beeinflussen. Dazu seien im Folgenden nur einige Beispiele genannt.

Vor Beginn einer ERP-Einführung müssen Architekturfragen geklärt werden. In vielen Fällen werden nicht alle vorhandenen Standardsoftwaresysteme oder Individualentwicklungen gleichzeitig abgelöst, sondern einzelne Systeme, die vielleicht erst in den letzten Jahren angeschafft wurden, bleiben bestehen; andere bleiben zunächst bestehen, vielleicht bis zur zweiten oder dritten Phase. Daher ist der Ablösereihenfolge und auch der Notwendigkeit der Ablösung von vorhandenen Systemen große Bedeutung beizumessen. Weiter ist bei strittigen Fragen eine sorgfältige Abwägung vorzunehmen, in welchem betrieblichen Anwendungssystem welche Funktionalität oder welche Stammdatenhaltung angesiedelt werden soll. Häufig existieren sowohl ERP-Kundenstammdaten als auch CRM-Kundenstammdaten. Hier ist nicht nur eine Integrationsmethode (z. B. führendes System) festzulegen, sondern auch zu entscheiden (auf der Basis wirtschaftlicher Argumente), ob überhaupt zwei verschiedene Systeme eingesetzt werden müssen. Schließlich kommt dem Standort für das Startprojekt eine besondere Rolle zu, insbesondere in internationalen Settings oder in Unternehmensgruppen, in denen prinzipiell eine Auswahlmöglichkeit besteht, welches Unternehmen zuerst umgestellt wird. Abschließend ist die Festlegung der Projektorganisation eine wichtige Entscheidung. Neben der Aufteilung von Verantwortlichkeiten sollte zwingend ein Kommunikationsplan erarbeitet werden. Externe und insbesondere die internen Ressourcen müssen entsprechend des Projektplans reserviert werden.

Vorgehensmodell zur ERP-Einführung

Das praxiserprobte Vorgehensmodell der ERP-Einführung ist in Bild 6.5 dargestellt. Es besteht im Prinzip aus einem Kreislauf zwischen Analyse, Konzeption, Anpassung und Test, der je nach Wahl für eine agile oder klassische, lineare Einführung einmal oder mehrmals durchlaufen werden kann. Im agilen Konzept wäre das ein Sprint. Diese Abschnitte liegen zwischen der zuvor genannten wichtigen Vorbereitungsphase und der Umstellungsbzw. Abnahmephase nach Abschluss eines Teilprojekts, um einen nutzbaren Status des ERP-Systems zu erreichen. Über- bzw. unterlagert werden diese Schritte von drei wesentlichen Querschnittsaufgaben: dem Projektmanagement, dem Qualitätsmanagement und der Projektkommunikation, während als Projektsteuerung, wie sie auch im PRINCE-Vorgehen definiert ist, ein Trusted Advisory dringend empfohlen ist, um schwerwiegenden Konflikten bei der ERP-Einführung vorzubeugen.

Dieses Vorgehensmodell kann bei Einführung eines ERP-Systems in mehreren Unternehmensteilen mehrfach durchlaufen werden, wobei der Umfang der einzelnen Phasen zeitlich und vom notwendigen Aufwand her stark variieren kann. Die horizontalen Pfeile sollen verdeutlichen, dass hier ein Tailoring des Modells auf den projektspezifischen Umfang erfolgen muss. Die konkreten Inhalte einer Phase sind dabei von verschiedenen Kriterien abhängig. So ergeben sich bereits bei unterschiedlicher Unternehmensgröße, sehr unterschiedliche Anforderungen an die einzelnen Inhalte einer Phase. So wird z. B. die Einführung eines ERP-Systems an einem Auslandsstandort deutlich schneller verlaufen und eine geringere Vorbereitungsphase erfordern als die Ersteinführung am Heimatstandort des Unternehmens.

6.4.1

Risikoanalyse

In der Vorbereitungsphase eines Projekts ist eine systematische Abschätzung möglicher Risiken sinnvoll, um im späteren – wesentlich zeitkritischeren – Verlauf des Projekts auf Überraschungen durch Risiken besser eingestellt zu sein. Dabei sollten folgende Risiken betrachtet werden:

Organisatorische Risiken beziehen sich auf die mit der ERP-Einführung einhergehenden Regelungen zur Aufbau- bzw. Ablauforganisation. Fehlende Mitarbeiterkapazität, die für die inhaltliche oder organisatorische Betreuung eines neuen ERP-Systems zwingend erforderlich ist, stellt z. B. ein erhebliches organisatorisches Risiko dar.

Technische Risiken liegen vor, wenn auf noch nicht erprobte und für den konkreten Anwendungsfall als geeignet erkannte Techniken gesetzt wird. So kann ein technisches Risiko z. B. dadurch entstehen, dass eine zu große Anzahl von Artikeldaten mit einem dafür technisch kaum geeigneten System bewältigt werden soll.

Terminliche Risiken beziehen sich auf die Gefahr, dass ein planerisch festgelegter Zielerreichungstermin überschritten wird. Notwendige Individualanpassungen eines ERP-Systems stellen meist ein terminliches Risiko dar, insbesondere wenn die notwendige Zeit für Integrationstests nicht berücksichtigt wird.

Kapazitive Risiken im Projekt entstehen, wenn der abzuarbeitende Arbeitsumfang und die dafür zur Verfügung stehenden personellen Ressourcen auseinanderklaffen. Kapazitive Risiken entstehen auch dann, wenn das für das ERP-Projekt zur Verfügung stehende Personal über die gesamte Projektlaufzeit zu mehr als 80 % bereits mit geplanten Tätigkeiten belegt ist, da für ungeplante Aufgaben und persönliche Verteilzeiten nicht mehr ausreichend Spielraum verbleibt.

Kosten/Nutzen-Risiken liegen vor, wenn der Erfolg eines Projekts zweifelhaft ist, ohne dass Möglichkeiten zur Beeinflussung der mit dem Projekt verbundenen Kosten bestehen.

Psychologische Risiken entstehen aus dem Verhalten und aus der Einstellung der Benutzer des Systems. So kann mangelnde Akzeptanz der Benutzer die mit dem Produktivstart verbundenen Erwartungen nahezu vollständig torpedieren, wenn das notwendige Maß an Aufgeschlossenheit fehlt.

Die Erfahrung zeigt, dass es zu Projektbeginn bei ERP-Projekten häufig zu Problemen kommt, die den Start des Projekts behindern oder verzögern. Solche Probleme sind z. B.:

       Der Anfangstermin des Projekts wird nach hinten verschoben, der Endtermin (Produktivstart) bleibt jedoch bestehen. Die zur Verfügung stehende Zeitspanne verringert sich.

       Es bilden sich – offen oder verdeckt – Fronten gegen das Projekt.

       Es werden Zweifel an der fachlichen oder persönlichen Kompetenz des Projektleiters geäußert.

       Mit dem Verweis auf andere, negativ verlaufene Projekte wird ein mögliches Scheitern dieses Projekts antizipiert.

       Es kommt zu Spekulationen bzw. zur Bildung von Gerüchten bezüglich der Auswirkungen des Projekts. Zum Beispiel wird der Verlust von Arbeitsplätzen befürchtet.

       Es existiert eine zu hohe Erwartungshaltung an die mit dem Projekt verbundenen Ergebnisse.

Um die Auswirkungen solcher Probleme zu begrenzen, wird empfohlen, eine Projektdurchführungsstrategie [2, 3] zu planen und entsprechende Maßnahmen, etwa Situationsanalyse, Betroffenheitsanalyse und Beteiligungsplanung umzusetzen.

6.4.2

Überprüfung der Projektorganisation

Während in der Auswahlphase eine nebenamtliche Betreuung des ERP-Projekts ausreichte, muss nun die Projektorganisation professionalisiert werden. Je nach Größe des Unternehmens sind dazu mehrere Mitarbeiter hauptamtlich für die Mitarbeit im Projektteam abzustellen.

Der Einsatz externer Dienstleister bietet sich an, wenn im Unternehmen selbst die notwendigen Kompetenzen oder Kapazitäten nicht verfügbar sind. Externe Dienstleister können als Berater, Projektleiter oder Projektsteuerer eingesetzt werden. Als Projektleiter vertreten sie das Unternehmen nach innen (gegenüber den Mitarbeitern) und nach außen (gegenüber dem Softwarelieferanten und ggf. weiteren Zulieferern).

Unabhängig von der zeitlichen Freistellung von Mitarbeitern ist in jedem Fall ein internes Projektteam zu bilden, das mindestens aus Vertretern der von der Systemeinführung be­troffenen Fachabteilungen (Key-Usern) und der IT-Abteilung besteht. Zudem muss ein Lenkungsgremium eingerichtet werden, dem neben dem Projektleiter Vertreter der Unternehmensleitung und der Projektleiter des ERP-Anbieters angehören. Projektdokumentation und Qualitätssicherung sind Aufgabe der externen Projektsteuerung, die ebenfalls in das Lenkungsgremium entsandt wird.

Bild 6.6 Beispiel einer Projektorganisation [Quelle: Potsdam Consulting]

6.4.3

Aufgaben des Projektleiters

Dem Projektleiter kommt eine besondere Rolle zu. Er muss sich fachlich in den Prozessen auskennen, zudem für das notwendige Veränderungsmanagement mit einer gewissen Überzeugungsfähigkeit ausgerüstet sein. Externe Projektleiter können meist nicht beide Anforderungen abdecken. In den weiteren Verantwortungsbereich des Projektleiters fallen folgende Aufgaben:

       Integrationsmanagement: Koordination der richtigen Funktionsweise aller Bestandteile des Projekts

       Geltungsbereichsmanagement: Sicherstellung genau der notwendigen Projektarbeiten

       Zeitmanagement: Sicherstellung des termingerechten Projektablaufs

       Kostenmanagement: Sicherstellung der Einhaltung des vorgegebenen Budgetrahmens

       Qualitätsmanagement: Das neue ERP-System soll die geplanten Anforderungen erfüllen.

       Human Resource Management: Personaleinsatzplanung und Personalführung

       Kommunikationsmanagement: Sicherstellung des Projektinformationswesens

       Risikomanagement: Identifikation und Analyse von Risiken sowie Ergreifen von Maßnahmen gegen Risiken

       Beschaffungsmanagement von Waren und Dienstleistungen

6.4.4

Einstellen der Geschäftsprozessparameter

Zu den in diesem Arbeitsschritt notwendigen Einstellungen gehören u. a.:

       Währungen, Betriebskalender mit Feiertagen, landesspezifische Einstellungen

       Festlegung der von den einzelnen Unternehmensbereichen genutzten oder geplanten Nummernkreise für Artikel, Kunden, Lieferanten, Organisationseinheiten, Belege etc.

       Festlegungen zum Aufbau und zur Pflege von Stammdatenstrukturen

       Eingabe der im System verwendeten Maßeinheiten und der Umrechnungsvorschriften zwischen Maßeinheiten. So wird bei der Blechbearbeitung Stahlblech nach Tonnen eingekauft, aber in der Fertigung nach Millimetern angefordert und verarbeitet.

       Festlegung der einzusetzenden Kontenrahmen für Kostenrechnung, Controlling und Buchhaltung sowie Zuordnung der Konten zu den Positionen der Bilanz bzw. der Gewinn- und Verlustrechnung.

Ebenfalls in diesen Aufgabenbereich gehören die Festlegung von Schnittstellenspezifikationen zu anderen Anwendungssystemen und die organisatorische Einbettung dieser Schnittstellen (z. B. wer überspielt die Rechnungsdaten in die Buchhaltung?).

Aus der Praxis: Wie viel Customizing ist zu tun?

Der Umfang der einzustellenden Parameter bewegt sich zwischen einigen Dutzend bei funktionsspezifischer Software über einige 100 bei kleineren ERP-Systemen bis hin zu mehreren 1000 bei unternehmensweit eingesetzten Systemen wie SAP ERP.

Bei der Parameterfestlegung werden Konfigurationsfehler begangen, die teilweise erhebliche Auswirkungen haben können [DMHH09]. Eine aufgabenwidrige Parameterverwendung liegt vor, wenn ein bestimmtes Konfigurationsziel mit der falschen Stellgröße verfolgt wird. So ist z. B. bei der Einstellung von Dispositionsparametern zwischen dem nur auf die Mindestbestellgröße wirkenden Parameter minimale Losgröße und dem auf alle Bestellmengen wirkenden Rundungswert zu unterscheiden, der alle Bestellmengen auf ein Vielfaches seines Betrags aufrundet. Wirksame Parameter werden nicht beachtet, wenn z. B. auf das Setzen eines Sicherheitsbestands verzichtet wird. Ein zwangsweises Außerkraftsetzen von Parameterwirkungen erfolgt etwa, wenn durch Wahl des Losgrößenverfahrens „Feste Bestellmenge“ der oben beschriebene Rundungswert durch das Losgrößenverfahren ignoriert wird und stattdessen ein oder mehrere Lose mit der „festen“ Menge erzeugt werden.

Während des Projektablaufs sind über die inhaltlichen Fehler bei der Parametereinstellung hinaus folgende Probleme zu erkennen:

       Hoher Termindruck insbesondere bei „Big-Bang-Projekten“, die alle Module gleichzeitig in Betrieb nehmen, führt zu Zeitmangel bei der Parametereinstellung und damit auch zu mangelnder Sorgfalt. Statt individuell ermittelter passender Parameterwerte werden Initialwerte oder Defaultwerte belassen, deren Auswirkungen nicht überprüft werden.

       Fehlendes Controlling des betriebswirtschaftlichen Erfolgs des neuen Systems, insbesondere des Einflusses auf wirtschaftliche Größen wie Kapitalbindung oder Dispositionsmängel und deren Auswirkungen.

       Die ungeprüfte Parameterübernahme aus Altsystemen kann dann zu Problemen führen, wenn unterschiedliche, auf diesen Parametern basierende Verfahren genutzt werden. In diesem Fall ist die Parameterübernahme nicht sinnvoll.

       Auch bei der Parameterübernahme aus ähnlichen Unternehmen ist zu berücksichtigen, ob der mit der jeweiligen Parametereinstellung intendierte Zweck nicht ein anderer ist.

6.4.5

Prototypphase

Ziel dieser Phase ist es, die zuvor eingestellten Parameter des ERP-Systems unter realitätsnahen Bedingungen zu testen. Dazu ist als vorbereitender Schritt die Übernahme der Stammdaten aus den Altsystemen erforderlich. Je nach Vorliegen der bisher genutzten Stammdaten sind unterschiedliche Möglichkeiten einer Altdatenübernahme zu unterscheiden. Liegen die Daten in Form von proprietären Datenstrukturen vor, ist es zumeist nicht möglich, eine entsprechende Exportroutine zur Verfügung zu stellen, die alle Daten unter Beachtung der vorgesehenen Relationen des in der neuen Standardsoftware verwendeten Datenmodells exportiert. Daher besteht nur die Möglichkeit, Stammdatenlisten in ASCII-Dateien zu übertragen.

Wenn auch diese Möglichkeit nicht zur Verfügung steht, müssen die Daten ausgedruckt und manuell in das neue System übertragen werden. Der Nachteil des großen Aufwands ist jedoch mit zwei erheblichen Vorteilen verbunden:

Zum einen kann bei der Neuerfassung zwischen zu übertragenden und nicht zu übertragenden Daten entschieden werden. Artikel, die nicht mehr im Programm sind, oder Kunden, die seit mehreren Jahren nichts mehr bestellt haben oder deren Firma nicht mehr existiert, werden nur so identifiziert.

Zum anderen sind bei der manuellen Neueingabe alle Gültigkeitsüberprüfungen des neuen Systems aktiv. Ungültige Postleitzahlen oder falsche Verknüpfungen zwischen Firma und Ansprechpartner werden unter Umständen bei einem automatischen Import in die entsprechende Tabelle nicht erkannt.

6.4.6

Parametertest

Zur Prototypphase gehört die Überprüfung, ob die eingestellten Berechtigungen korrekt die gewollte organisatorische Aufgabenverteilung wiedergeben. Alle Ausdrucke des Systems, sowohl die intern verwendeten Belege und Berichte als auch die im Geschäftsverkehr verwendeten Briefe müssen auf formale und inhaltliche Richtigkeit überprüft werden.

Zumeist ergibt sich in der Prototypphase auch die Notwendigkeit weiterer Berichte. Über deren Realisierung sollte zügig entschieden werden, um einen geplanten Produktivstarttermin nicht zu gefährden.

Ein weiteres Ziel der Prototypphase liegt darin, weitere Mitarbeiter an die Bedienung des Systems heranzuführen. Hierzu sind entsprechende Schulungen vorzubereiten und durchzuführen.

Wichtig ist, dass die Schulungen nicht nur aus Folienvorträgen bestehen, sondern den Schwerpunkt auf die direkte Vermittlung von Kenntnissen am neuen ERP-System legen. Dies kann erreicht werden, indem einzelne Abschnitte der Geschäftsprozesse, die das neue System unterstützen sollen, mit Beispieldaten direkt am System geübt werden. Daher sollte jedem Teilnehmer der Schulung ein eigener Rechner mit installiertem ERP-System zur Verfügung stehen. Die Schulungen sind zeitnah zum Produktivstart durchzuführen, damit der erreichte Kenntnisstand nicht wieder in Vergessenheit gerät. Regelmäßige Wiederholungen unter allmählicher Erweiterung des Stoffs sind empfehlenswert.

Spätestens in der Prototypphase sind auch Lasttests der Software durchzuführen, um zu erkennen, ob die zu Beginn gewählte Dimension der Hardware ausreichend war. Ansonsten besteht die Gefahr, dass sich Performance-Probleme häufig erst bei Lastbetrieb herausstellen. Daher ist es außerordentlich empfehlenswert, diese Lasttests bereits in der Prototypphase durchzuführen. Im Produktivbetrieb des neuen Systems gefährdet eine unzureichende Performance unter Umständen die mit der Einführung der neuen Standardsoftware verbundenen Ziele. Wenn z. B. Änderungen des Auftragsnetzwerks (Net Change) nicht schnell genug durchgeführt werden können, ist eine genaue Lieferfähigkeitszusage nicht mehr möglich. Wenn nicht alle pro Tag eintreffenden Bestellungen am selben Tag bearbeitet werden können, ist ebenfalls die Konkurrenzfähigkeit des Unternehmens nicht mehr sichergestellt, da sich die Auslieferung bestellter Aufträge verzögert.

6.4.7

Umstellungsstrategien

Nachdem in der vorangegangenen Phase die für den reibungslosen Betrieb des ERP-Systems erforderlichen Parameter eingestellt wurden, muss sich das neue System nun in einem begrenzten Probebetrieb in der Praxis bewähren. Je nach Umstellungsstrategie stehen für diesen begrenzten Probebetrieb verschiedene Optionen zur Auswahl [Gr14]:

Aufteilung nach Geschäftsobjekten: Bei der Aufteilung nach Geschäftsobjekten wird ein ausgewählter Teil der Kunden, Artikel, Projekte etc. mit dem neuen System bearbeitet, während die übrigen Geschäftsobjekte weiterhin mit dem alten System bearbeitet werden. Vorteil dieser Aufteilung ist die Möglichkeit, die vorgenommenen Einstellungen am realen Geschäftsobjekt testen zu können. Nachteilig bei dieser Variante ist jedoch, dass zur Sicherstellung der Datenintegrität im bisher verwendeten System Doppeleingaben erfolgen müssen. Daher kann der Zeitraum einer Aufteilung nach Geschäftsobjekten mit einer parallelen Bedienung beider Systeme wegen der daraus resultierenden höheren Belastung der Mitarbeiter nur kurz, d. h. im Wochenbereich, sein. Das in dieser kurzen Zeit durchzuführende Testprogramm muss daher sorgfältig geplant werden.

Aufteilung nach Funktionen: Bei der Aufteilung nach Funktionen oder Programmmodulen werden nach und nach fertig angepasste Module des neuen Systems in den Produktivbetrieb überführt. Für jedes Modul oder jeden Funktionsblock findet somit eine stichtagsbezogene Ablösung der alten Systemfunktionalität durch ein Modul des neuen ERP-Systems statt. Dieses Vorgehen setzt die Aufteilbarkeit des Funktionsumfangs zwischen alten und neuen Systemen voraus. Je nach Integrationsgrad sind aber unter Umständen zahlreiche Schnittstellen des abgelösten alten Systems zu anderen Altsystemen für das neue System zu schaffen, solange die verbliebenen Altsysteme noch weiter betrieben werden. Zudem ist angesichts der hohen Integrationsdichte umfassender ERP-Systeme eine Herauslösung einzelner Module zumindest schwierig.

Nachteilig ist darüber hinaus, dass der Zeitraum der Umstellung sehr lang wird und die betroffenen Funktionen mit beiden Systemen arbeiten müssen. Auch der zweifache Ressourcenbedarf wird meist als nachteilig an dieser Lösung angesehen. In der Praxis kommt als Problem hinzu, dass bestimmte betriebswirtschaftliche Aufgaben, etwa das Anlegen eines neuen Projekts, Auftrags oder Kunden, wahlweise im alten oder im neuen System vorgenommen werden können, wenn diese Möglichkeit nicht im alten System ausdrücklich gesperrt werden kann (und dies auch tatsächlich durchgeführt wurde). Durch Fehlbedienungen dieser Art entsteht zusätzlicher Aufwand bei der Datenintegration und konsolidierung im neuen System.

Vollständige Ablösung des alten Systems: Bei der als „Big Bang“ bezeichneten vollständigen Ablösung eines oder mehrerer Altsysteme durch das neue ERP-System werden zu einem Stichtag alle Geschäftsprozesse auf das neue System umgestellt. Diese Lösung vermeidet die Implementierung nur vorübergehender Schnittstellen zu Altsystemen und verkürzt den Zeitraum der Umstellung erheblich. Sie stellt jedoch ein hohes Risiko dar, weil unter Umständen bei Problemen kein mit aktuellen Daten versehenes Altsystem mehr zur Verfügung steht und die betroffenen Geschäftsprozesse unmittelbar beeinträchtigt werden. Der „Big Bang“ stellt daher höchste Anforderungen an die Qualität der vorbereitenden Maßnahmen.

6.4.8

Zur Notwendigkeit einer externen Projektsteuerung

Die Einführung eines neuen ERP-Systems lässt sich mit einer Operation am offenen Herzen vergleichen. Nur wenige nehmen allerdings eine Herzoperation selbst vor! Bei der Einführung von ERP-Systemen kommt es jedoch immer wieder vor, dass der noch zur Markterkundung unbedingt erforderliche Berater nach Aussprechen seiner Empfehlung wieder verabschiedet wird mit dem Argument, den Rest kriege man auch allein hin. Der Autor dieses Beitrags kennt nur sehr wenige Unternehmen mit überaus großer ERP-Reife, die tatsächlich eine ERP-Einführung allein mit dem liefernden Softwarehaus erfolgreich gestaltet haben. Den meisten anderen Unternehmen fehlt es an den notwendigen personellen Ressourcen und dem notwendigen Wissen zur Optimierung von Geschäftsprozessen sowie über die Gepflogenheiten der ERP-Branche. Die Notwendigkeit einer externen Projektsteuerung liegt dann auf der Hand, wenn folgende Merkmale erkennbar sind:

       Der Zeitplan für die Einführung ist im Rückstand.

       Der Anbieter hält Qualitätsversprechen nicht ein.

       Die Funktionalität erscheint schwächer als ursprünglich erwartet.

       Anbieter und Kunde können sich nur schwer koordinieren.

       Ein deutlich höherer Projektaufwand ist zu erwarten.

       Die internen Kapazitäten sind ausgelastet.

       Mitarbeiter des Anbieters verfügen (noch) nicht über die erwarteten Fähigkeiten.

       Das Management des Kunden ist mit anderen Aufgaben ausgelastet.

Aufgabe der externen Projektsteuerung ist es, Zeit, Qualität und Projektkosten zu überwachen sowie zwischen Anbieter und Kunde zu vermitteln. Dazu gehört es, vorzuschlagen, was im Lenkungsausschuss entschieden werden muss, zu eskalieren, wenn der Anbieter nicht liefert, und zu besänftigen, wenn der Kunde Unmögliches fordert.

Im Rahmen der Zeitplanung drängt die externe Projektsteuerung auf Termineinhaltung, erinnert an bevorstehende Termine und fordert Ressourcen bei Anbieter und Kunde an. Vorschläge des Anbieters, welche Ressourcen er in das Projekt einbringen will, werden überprüft. Kommt es zu Terminverschiebungen, werden die Gründe validiert und dem Anbieter/Kunden zugeordnet. Zudem werden Auswirkungen von Änderungswünschen auf den Zeitplan aufgezeigt.

Ebenfalls von hoher Bedeutung für den Einführungserfolg ist das Qualitätsmanagement. Hier nimmt die externe Projektsteuerung Arbeitspakete nach Prüfung ab, beachtet Validierungsanforderungen, beurteilt Fachkonzepte, Schulungsmaßnahmen und deren Ergebnisse, die Dokumentation, Testverfahren und Testergebnisse sowie den jeweiligen Zielerreichungsgrad. Sie schätzt die Systemperformance ein und fordert die notwendige Datenqualität.

Schließlich trägt die externe Projektsteuerung auch zur Kostendisziplin bei: Sie berechnet die Auswirkungen von Änderungen auf die Projektkosten, überprüft die Anbieterrechnungen und bestreitet nicht geleisteten Anbieteraufwand. Sie stellt sicher, dass abgerechnete Leistungen laut Vertrag auch erbracht wurden, und bewertet Erweiterungsangebote. So wird sichergestellt, dass nicht versehentlich seitens des Anbieters zu hohe Kosten geltend gemacht und mangels Überblick des Kunden auch gezahlt werden.

Bild 6.7 Aufgaben der externen Projektsteuerung (Quelle: Potsdam Consulting)

Praxistipp: Externe Hilfe ist stets sinnvoll

Allein die direkt gesparten Kosten des Anbieters rechtfertigen schon eine Einschaltung einer externen Projektsteuerung. Wenn vor Beginn des ERP-Projekts eine ROI-Analyse [Gr162] durchgeführt wurde, kann auch der Wert der Zeiteinhaltung bemessen werden. Ein halbes Jahr Projektverzögerung führt in jedem Fall dazu, dass der erkannte Produktivitätsverlust anhält. Dieser kann schon 25 % des externen Projektvolumens ausmachen. Das Qualitätsmanagement schließlich beugt zu spät entdeckten Fehlern vor und senkt somit Kosten unmittelbar vor oder während des Produktivstarts.

Insgesamt kann daher eine externe Projektsteuerung für die ERP-Einführung nur empfohlen werden.

6.4.9

Betriebsformen für Business-Software

Die Diskussion um Cloud Computing hat die Frage der richtigen Betriebsform für ein ERP-System in den Fokus gestellt. Bisher waren entweder ein Betrieb der Business-Software durch die eigene IT im Haus (‚on premise‘) oder das Hosting bei einem entsprechend dafür qualifizierten Anbieter möglich. Die wachsende Verfügbarkeit von Cloud-ERP-Angeboten erhöht nun den Spielraum für Veränderungen. Cloud Computing stellt ein Modell für die Verfügbarmachung eines einfachen Netzwerkzugangs zu einem geteilten Pool konfigurierbarer Ressourcen (z. B. Netzwerke, Server, Speicher, Anwendungen und Dienstleistungen). Diese Ressourcen können sehr schnell zur Verfügung gestellt und freigegeben werden und benötigen dazu nur minimale Managementanstrengungen oder Interaktionen mit dem Provider der Dienstleistungen.

Fünf Aspekte unterscheidet ein Cloud-Computing-Angebot von einfachen Hosting-Angeboten oder anderen Fremdbezügen von IT-Leistungen. Neben dem On-demand-Selbstbedienungszugangs, der, ohne menschliche Interaktion zu beanspruchen, bei plötzlich auftretendem Bedarf statt 100 Pageviews nun 10 000 Pageviews ausliefern kann, gehört ein breitbandiger Netzwerkzugang über beliebige Browser zum Cloud Computing. Die Verfügbarmachung über lediglich einen Browser, womöglich auch noch mit proprietären Plug-ins, ist dem Cloud-Gedanken abträglich. Die Ressourcen in der Cloud werden vom Anbieter gepoolt, wobei in der Regel Multi-Tenancy-Modelle verfolgt werden, bei denen einige Ressourcenbestandteile dediziert einzelnen Anwendern zur Verfügung gestellt werden, während andere gemeinsam genutzt werden. Ein wesentliches Merkmal von Cloud Computing ist die schnelle Elastizität der Cloud, die ein Erhöhen oder Reduzieren der benötigten Ressourcen in sehr kurzer Zeit ermöglicht. Ebenso gehört zum Cloud Computing die Messung der Verfügbarkeit und Inanspruchnahme des Service. Die großen Softwareanbieter und darüber hinaus viele weitere Anbieter stellen Dienstleistungen, Infrastrukturen oder Plattformen in der Cloud zur Verfügung.

Als Liefermodelle können neben der Installation auf eigenen Rechnern (on premise) die Public Cloud und die Private Cloud unterschieden werden [Gr13]. In der Public Cloud wird das öffentlich verfügbare Angebot der Cloud-Service-Anbieter genutzt. In der Private Cloud wird ein eigenes Rechenzentrum für die eigenen in die Cloud zu verlagernden Anwendungen betrieben. Daneben ist auch eine hybride Lösung denkbar, die für bestimmte Aufgabenstellungen private und öffentliche Cloud-Angebote kombiniert.

Schließlich können sich auch mehrere Unternehmen zusammenschließen, um eine Cloud zu betreiben, dies wird dann als Community-Cloud bezeichnet.

Zu den Vorteilen von Cloud-Services gehören:

       Keine Investition in IT

       Keine Infrastruktur

       Kein Betriebspersonal

       Temporäre Nutzung von Ressourcen möglich

       Schwankende Lastverläufe und starkes Wachstum abbildbar

       24/7-Zugriff weltweit realisierbar

Folgende Risiken müssen vor einem Cloud-Einsatz überdacht werden:

       Die Frage der eventuellen Überbuchung von Ressourcen

       Die Vertraulichkeit und Prüffähigkeit von Daten

       Die Einhaltung von Compliance-Vorschriften

       Das Datenschutzrisiko

       Die Auswirkungen von Fehlern des Anbieters auf die Aufrechterhaltung des eigenen Geschäfts

       Die Skalierungsgeschwindigkeit muss ebenso überprüft werden wie der Umgang mit einer eventuell an einigen Standorten beschränkten Brandbreite. Ebenfalls ist zu klären, ob nicht Cloud-Computing-Server mit Schädlingen infiziert oder von ausländischen Ge­heimdiensten überwacht sein können.

6.5	Betrieb von geschäftsprozessorientierten Softwaresystemen

Aufgrund ihrer hohen Komplexität bergen geschäftsprozessorientierte Softwaresysteme im täglichen Betrieb eine Reihe von Risiken. Daher ist es erstaunlich, dass die Schwerpunkte der Literatur bisher vor allem in der Beschreibung sowie der Auswahl und Einführung von ERP-Systemen lagen. Der Betrieb komplexer ERP-Systeme wurde dagegen nur sehr vereinzelt und in Ausschnitten betrachtet. Dies ist besonders im Hinblick auf die hohen Kosten innerhalb der ERP-Betriebsphase bemerkenswert, welche die Einführungskosten im gesamten Lebenszyklus oft um ein Vielfaches übersteigen können.

Komplexe Prozesse im laufenden Systembetrieb machen es daher notwendig, die Serviceabläufe innerhalb der IT-Abteilungen zu strukturieren, zu standardisieren und ggf. auch zu harmonisieren. Viele im Support tätige Unternehmen sehen eine Herausforderung darin, sich von einem technologieorientierten Anwendungsentwickler und Infrastrukturbetreiber zu einem kundenorientierten IT-Dienstleister weiterzuentwickeln.

Das IT-Servicemanagement leistet im Betrieb komplexer ERP-Systeme bei der Durchführung service- und kundenorientierter Dienstleistungen einen erheblichen Beitrag zur qualitativen Leistungserbringung sowie zur Vermeidung und Verkürzung von Ausfallzeiten. Es adressiert folgende operative Problemstellungen und organisatorische Herausforderungen innerhalb der ERP-Betriebsphase:

       Wie lassen sich IT-Dienstleistungen planen und steuern?

       Mit welchen Methoden und Techniken können Störungen oder Ausfälle effizient behoben oder überbrückt werden?

       Wie können die Organisationsstrukturen der Serviceabteilungen bestmöglich gestaltet werden?

       Wie lässt sich die Erbringung von IT-Leistungen bzw. die Erfüllung von Leistungsverpflichtungen messen?

Antworten auf diese Fragen geben Servicereferenzmodelle wie z. B. ITIL, die sich in den letzten Jahren immer weiter verbreiten konnten. Details dazu enthält Kapitel 10 dieses Handbuchs.

6.5.1

Die Organisation der Wartung für geschäftsprozessorientierte Softwaresysteme

Ziel der Wartungsorganisation ist die Sicherstellung eines dauerhaften, effizienten und störungsfreien Betriebs innerhalb der gesamten Laufzeit des Systems (vgl. im gesamten Abschnitt).

Die Wartungsorganisation umfasst die oben dargestellten Prozesse des IT-Servicemanagements, der Qualifizierung, des Projektmanagements, der internen Kommunikation und Dokumentation. Schwerpunkte bilden dabei die Serviceprozesse zum ERP-Betrieb, wie sie z. B. im ITIL-Prozessmodell abgebildet werden, und die Abläufe zur Mitarbeiterqualifizierung. Der Begriff Qualifizierung umfasst alle Aktivitäten, die der Erhaltung, Erweiterung und Anpassung beruflicher Kenntnisse, Fertigkeiten und Fähigkeiten dienen. Als negative Folgen unzureichend qualifizierter Anwender können unvorhergesehene Betreuungskosten sowie Zeitaufwand zum manuellen Ausgleich unzureichender Datenqualität entstehen. Fachgerechte Qualifizierung muss daher systematisch geplant sowie individuell und zielgruppenspezifisch für Anwender und Mitarbeiter im Servicemanagement durchgeführt werden.

Aufgaben des Projektmanagements innerhalb der Wartungsorganisation betreffen beispielsweise die Einführung neuer Softwarekomponenten oder Release-Wechsel. Neben diesen direkt ERP-bezogenen Projekten kann aber auch die Restrukturierung von Teilen der Wartungsorganisation betroffen sein, z. B. die Neuausrichtung der Servicemanagementprozesse anhand eines bestimmten Referenzmodells. Die in den Projekten enthaltenen Prozesse stehen im direkten Bezug zu den Phasen Projektdefinition, Projektauftrag, Projektplanung, Projektdurchführung und Projektabschluss. So beinhaltet die Phase Projektplanung in der Wartungsorganisation beispielsweise den Prozess zur Zusammenstellung des ausführenden Projektteams.

Die Kommunikation der Wartungsorganisation umfasst alle Kommunikationswege, die genutzt werden, um den störungsfreien Betrieb der ERP-Lösung sicherzustellen. Kommunikation kann anhand klar definierter Strukturen oder aber ungeplant zwischen einzelnen Organisationsmitgliedern erfolgen.

Dokumentationsprozesse stellen die fünfte innerhalb der Wartungsorganisation enthaltene Prozessgruppe dar. Dokumentiert werden insbesondere Lösungen zu aufgetretenen Anwendungsproblemen innerhalb einer Fallbasis. Diese bilden die Basis zur Wiederverwendung bereits erarbeiteter Lösungsszenarien. Dabei besteht das Dilemma zwischen qualitativ hochwertigen und umfangreichen Dokumentationen und den gegebenen Zeitrestriktionen.

6.5.2

Service Level Agreements

Service Level Agreements stellen kennzahlenbasierte Absprachen eines Dienstleistungsanbieters mit seinen Kunden bezüglich der zu gewährleistenden Servicequalität dar [Krc09]. Der Grad der Leistungsqualität wird anhand der Definition der Leistung, der Darstellbarkeit der Leistung als Kennzahl, der Messmethode, des Erstellers sowie Empfängers der Leistung als auch anhand der Erstellungsfrequenz und des Leistungsniveaus beschrieben. Reaktionszeiten bei Fehlern (z. B. in Minuten, Stunden, Tagen), Stillstandzeit (z. B. für Hardwarewartung und Updates), Release-Wechsel (z. B. in Tagen), Wiederanlaufzeiten (z. B. vom Katastrophenfall bis zum erneuten Systemstart) können Beispiele für servicebezogene Kennzahlen sein. Grundsätzlich werden drei Arten von Service Level Agreements unterschieden:

       Ergebnisbezogene Dienstgütevereinbarungen: Anforderungen an die Qualität der zu erbringenden Leistungen werden festgelegt und über Kennzahlen (z. B. Indexwert einer Kundenzufriedenheitsbefragung) abgebildet.

       Prozessbezogene Dienstgütevereinbarungen: Anforderungen an den Leistungserstellungsprozess werden definiert und durch Kennzahlen (z. B. Reaktionszeiten) abgebildet.

       Potenzialbezogene Dienstgütevereinbarungen: Anforderungen an die im Leistungsprozess eingesetzten Inputfaktoren werden definiert (z. B. Sprachkenntnisse bei den Mitarbeitern des Service Desks).

       Erwartete Vorteile von Service Level Agreements liegen in einer hohen Kostentransparenz der erbrachten Leistungen sowie in der Sicherstellung einer durchgängigen Servicequalität. Die Übertragung der Wartungsaufgaben an einen externen Dienstleister ermöglicht Anwenderunternehmen eine Fokussierung auf ihre Kernkompetenzen. Allerdings können dadurch die eigene Handlungsfähigkeit eingeschränkt werden, Geschäftsprozesswissen verlorengehen und neue Abhängigkeiten entstehen [Ase05].

6.5.3

Implikationen für das Management

Die Wartungsorganisation steht vor permanenten Herausforderungen, welche beispielsweise durch neue Technologien (z. B. webbasierte Realisierung des ERP-Systems) entstehen können. Gleichzeitig werden die IT-Verantwortlichen zunehmend in die Verantwortung genommen, einen messbaren Mehrwert und eine hohe Produktivität für das Unternehmen zu generieren. Dieses Ziel kann jedoch nur mithilfe effizient gestalteter Serviceprozesse und qualifizierter Mitarbeiter erreicht werden.

Die Identifikation von unternehmensinternen Wissensträgern, welche immer wieder von Mitarbeitern bei der Lösung von Anwendungsproblemen befragt werden, stellt einen wichtigen Schritt zur schnellen Lösungsfindung dar. Benutzerhandbücher sind häufig in der Handhabung zu umständlich. Das Gleiche gilt auch bei der Lösungssuche im Intranet, da Lösungen hier nur schwer und mit großer Zeitintensität gefunden werden können. Daher müssen den Anwendern einfach gestaltete und leicht zugängliche Unterlagen zur Verfügung gestellt werden, welche die wichtigsten Fragen prozessbezogen gegliedert beantworten können. Bei elektronischen Medien sind in diesem Zusammenhang effiziente Suchmechanismen, hohe Performance, intuitive Anwendbarkeit sowie qualitativ hochwertige Lösungsvorschläge von großer Bedeutung.

Letzteres kann beispielsweise durch ein Redaktionssystem verbessert werden, in dem erfolgreiche Lösungen anwendergerecht für eine wiederholte Nutzung aufbereitet werden.

In Zusammenarbeit mit den Dienstleistungsunternehmen sollten in die Service Level Agreements (Dienstgütevereinbarungen) unternehmensspezifisch ausgerichtete Key Performance Indicators (z. B. in den Bereichen Antwortzeiten, Verfügbarkeit etc.) aufgenommen werden, d. h. festgelegte Leistungsparameter, die überprüfbar sein müssen. Opportunitätskosten können durch Unproduktivität in Folge von Anwendungsproblemen entstehen.

Fachgerechte und prozessorientierte Qualifizierung trägt in diesem Zusammenhang dazu bei, die Produktivität der Nutzer kontinuierlich zu steigern. Auch aus Sicht des Dienstleistungsunternehmens ist ein systematischer Qualifizierungsprozess die Basis für eine hohe Mitarbeiterkompetenz und eine hohe Servicequalität. Zielgerecht strukturierte Serviceabläufe und klare Verantwortlichkeiten verkürzen die Antwortzeiten im Service Desk. Ein erfolgreicher Servicebetrieb ist maßgeblich von qualifizierten Mitarbeitern abhängig. Diese sollten daher bei der Auswahl künftiger Weiterbildungsmaßnahmen zur Erhöhung der Prozessorientierung im Bereich Qualifizierung beteiligt werden. Klassische Classroom-Schulungen können beispielsweise durch weniger kostenintensive Training-on-the-Job-Maßnahmen abgelöst werden. Dabei werden Schulungen in der gewohnten Arbeitsumgebung durchgeführt und tatsächlich anfallende Geschäftsvorfälle bewältigt. Trainings in dieser Form sind besser in die täglichen Abläufe integrierbar und erfordern keine längeren Abwesenheitszeiten.

Fachgerechte Qualifizierung sollte proaktiv durchgeführt und nachfrageorientiert am betrieblichen Bedarf ausgerichtet werden. Dies wirkt sich durch Zeiteinsparungen, gesteigerte Produktivität sowie verbesserte Arbeitsqualität und Leistungsfähigkeit der Mitarbeiter aus.

Ein durchdachtes und systematisches Qualifizierungskonzept umfasst auch den konsequenten Aufbau einer organisationalen Wissensbasis. Zur Sicherstellung des reibungslosen ERP-Betriebs muss den Mitarbeitern die Möglichkeit zum Wissensaustausch gegeben werden. Dies kann auf formeller Weise innerhalb von Workshops oder auch informell geschehen. Die dafür benötigen Freiräume sollten zur Verfügung gestellt und der damit verbundene Wissensaustausch sollte gefördert werden.

Im Zusammenhang mit der Implementierung eines serviceorientierten Referenzmodells kann Unternehmen generell empfohlen werden, Anforderungen an die neuen Prozesse klar herauszuarbeiten sowie Ziele zu definieren, um keine unrealisierbaren Erwartungen zu wecken. Der Qualifizierungsaufwand kann dabei durchaus wirtschaftlich gerechtfertigt sein. Dabei sollten sowohl Potenziale zur Zeitersparnis erfasst werden (z. B. Lösungszeiten) als auch direkt monetär bewertbare Potenziale. Neben den unmittelbar quantifizierbaren Potenzialen sollten aber auch qualitative Potenzialbereiche berücksichtigt werden. Dazu gehört beispielsweise die Erhöhung der Kundenzufriedenheit aufgrund verkürzter Antwortzeiten.

Im Bereich Servicemanagement findet ITIL als De-facto-Standard eine große Akzeptanz. Weiterführende Konzepte sind z. B. die wissensbasierte Erweiterung der ITIL-Prozesse aufgrund der hohen Wissensintensität der Serviceabläufe oder die Kombination verschiedener serviceorientierter Referenzmodelle (z. B. ITIL und CobiT). Da das Servicemanagement vorwiegend wissensintensive Abläufe [Gr09] beinhaltet, sollten die Referenzprozesse um Aspekte der Wissensflüsse erweitert werden. So kann beispielsweise durch gezielte Dokumentationen Wissensverlusten entgegengetreten werden, welche beispielsweise aufgrund von Abgängen bestimmter Wissensträger im Servicemanagement entstehen.

Das Wichtigste – zusammengefasst:

       Klären Sie Inhalt und Bedeutung von IT-Compliance für Ihr Unternehmen, insbesondere die Schnittstellen zur Corporate Governance und Compliance auf der einen, zu IT-Governance, IT-Risiko- und IT-Sicherheitsmanagement auf der anderen Seite!

Im Rahmen des übergeordneten GRC-Konzepts muss IT-Compliance mit den verschiedenen Managementbereichen strukturell, konzeptionell und methodisch abgestimmt werden. Die Hauptverantwortung kommt hierbei der Unternehmensleitung sowie dem für die IT-Funktion Verantwortlichen zu. Grundlegend bezeichnet IT-Compliance einen Zustand, in dem alle die IT des Unternehmens betreffenden, verbindlich vorgegebenen bzw. als verbindlich akzeptierten Vorgaben nachweislich eingehalten werden. Dies erfordert die Identifizierung relevanter Regelwerke und die Erfüllung der aus ihnen resultierenden Vorgaben im Rahmen eines IT-Compliance-Prozesses.

       Klären Sie den Nutzen von IT-Compliance, um die Unterstützung von Top-Management und Fachabteilungen für IT-Compliance sicherzustellen!

Neben der selbstverständlichen Pflicht zur Erfüllung gesetzlicher Vorschriften soll IT-Compliance ein Unternehmen vor allem vor wirtschaftlichen Nachteilen als Folge von Rechtsverletzungen bewahren. Es sollen insbesondere Schadensersatzpflichten, Strafen, Buß- und Zwangsgelder vermieden werden. Der weitere Nutzen von IT-Compliance richtet sich auf die Erhöhung des Wertbeitrags der IT, die Steigerung der Qualität von IT-Prozessen, die Erhöhung der IT-Sicherheit sowie die Reduzierung von IT-Kosten und IT-Risiken.

       Richten Sie ein Managementsystem für IT-Compliance ein!

Ein Managementsystem für IT-Compliance legt fest, aufgrund welcher IT-Compliance-Ziele und Verhaltensprinzipien sowie mit welchen Methoden und Tools das IT-Management die auf IT-Compliance gerichteten Aufgaben und Maßnahmen nachvollziehbar steuert (d. h. plant, einsetzt, durchführt, überwacht, prüft und verbessert). Hierbei ist auch zu klären, durch welche IT-Systeme IT-Compliance herbeigeführt werden soll. Hierfür sind z. B. Lösungen für Security- oder Content-Management, Archivierung, Verschlüsselung, Nutzer-, Zugangs- und Lizenzverwaltung aufeinander abgestimmt einzusetzen.

       Organisieren Sie die Zusammenarbeit für IT-Compliance!

Die IT-Abteilung und ihre Leitung haben den Großteil an Maßnahmen zur Erfüllung der IT-Compliance-Anforderungen zu planen und durchzuführen. Eine besondere Bedeutung kommt der Position des IT-Compliance-Officers zu. Dieser hat die Unternehmens- und IT-Leitung in allen IT-Compliance-relevanten Fragen zu beraten, die Gestaltung und Weiterentwicklung des Managementsystems für IT-Compliance zu konzipieren und die Umsetzung zu koordinieren. Aber auch die Fachabteilungen tragen eine Verantwortung bei der Erfüllung von IT-Compliance-Anforderungen – und zwar immer dann, wenn bereichsbezogene organisatorische oder personelle Compliance-Maßnahmen ergriffen und entsprechende IT-gestützte Kontrollen eingeführt werden.

       Berücksichtigen Sie bei der Auswahl prozessorientierter Softwaresysteme neben wesentlichen funktionalen Anforderungen auch die Zukunftsfähigkeit und Integrationsfähigkeit des in Rede stehenden Produkts.

Vorfestlegungen hinsichtlich Anbieter oder Technologie erweisen sich in den seltensten Fällen als stichhaltig. Häufig kennen Externe den relevanten Teilmarkt besser als Sie selbst.

       Bei der Einführung prozessorientierter Softwaresysteme kommt es auf den Erfolg an, nicht auf Perfektion.

Es besteht immer die Möglichkeit, in einer weiteren Phase diejenigen Prozesselemente umzustellen, die in der ersten Phase nicht umgestellt werden konnten, aber auch einem durchgängigen Informationsfluss nicht im Wegstanden. Kritische Erfolgsfaktoren für die Einführung sind die Projektorganisation, der Projektleiter und die Einbindung von Management und Key-Users, also überwiegend organisatorische Aspekte.

       Beim Betrieb prozessorientierter Softwaresysteme stehen der Aufbau, die Bewahrung und Nutzung von Wissen über das Softwaresystem im Vordergrund.

Die Betriebsphase darf nicht ausschließlich unter Kostenaspekten gesehen werden, sondern muss auch definierte Prozesse für Change Requests und deren Abarbeitung enthalten.

6.6

Literatur

[As05]	Asendorf, S.: Outsourcing Alternativen für die IT. ERP Management, 1 (2005) 2, S. 30 – 33
[Bah09]	Bahrs, J., Vladova, G., u. a.: Anwendungen und Systeme für das Wissensmanagement. 3. Auflage. Berlin 2009
[DMHH09]	Dittrich, J., Mertens, P., Hau, M., Hufgard, A.: Dispositionsparameter in der Produktionsplanung mit SAP. Einstellungshinweise, Wirkungen, Nebenwirkungen. 5. Auflage. Braunschweig Wiesbaden 2009
[Egg07]	Eggert, S.: Marktrecherche zu Funktionen und Trends von Personalinformationssystemen. ERP Management 3. Jg. Heft 1, S. 49 – 58
[GFG16]	Gronau, N., Fohrholz, C., Glaschke, C.: Ein Vorgehensmodell zur erfolgreichen ERP-Einführung, ERP Management 3/2016, S. 36 – 39
[Gr09]	Gronau, N., u. a.: Wissen prozessorientiert managen. Methode und Werkzeuge für die Nutzung des Wettbewerbsfaktors Wissen in Unternehmen. München 2009
[Gr10]	Gronau, N.: ERP-Auswahl mittels RoI-Analyse – Risikoreduzierung und Nutzensteigerung. ERP Management. 6. Jahrgang 2010, Ausgabe 3, S. 17 – 20
[Gr13]	Gronau, N.: Betriebsformen für ERP-Systeme, ERP Management 4/2013, S. 20 – 23
[Gr13a]	Gronau, N,. u. a.: Wettbewerbsfaktor Analytics – Reifegrad ermitteln, Wirtschaftlichkeitspotenziale entdecken. Berlin 2013.
[Gr14]	Gronau, N.: Enterprise Resource Planning. Funktionen, Architektur und Management von ERP-Systemen. 3. Auflage. München 2014
[Gr16]	Gronau, N.: Handbuch der ERP-Auswahl. 2. Auflage. Berlin 2016
[Gr16a]	Gronau, N.: Identifikation von Potenzialen durch Industrie 4.0 in der Fabrik, Productivity Management 3/2016, S. 21 – 23.
[Krc09]	Krcmar, H.: Informationsmanagement. 5. Aufl. Berlin Heidelberg New York 2009
[Sc15]	Schüller, R.: ERP-Projekte mit agilen Methoden steuern. ERP Management 3/2015, S. 62 – 63.
[TMSL17]	Treber, S., Moser, E., Schneider, J., Lanza, G.: Digitales Dokumentenmanagement – Methodische Unterstützung zur Einführung von Dokumentenmanagementsystemen in produktionsnahen Unternehmensbereichen, Industrie Management 4/2017, S. 17 – 20