7 Zusammenfassung und Ausblick

Transkript

1 7 Zusammenfassung und Ausblick 7.1 Zusammenfassung Enterprise-Management-Systeme (EMS) erfreuen sich in Unternehmungen verschiedener Branchen und Grössen zunehmender Beliebtheit. Diesem Markt werden weit über die Jahrtausendwende hinweg Wachstumsraten von 30-40% prognostiziert. Gründe für den vermehrten Einsatz von EMS sind vor allem veraltete Systemarchitekturen der bestehenden IS, die Möglichkeit der Nutzung einer gegenüber dem Ist-Zustand wesentlich erweiterten Funktionalität, erhoffte Kosteneinsparungen sowie der Ersatz bestehender Systeme aufgrund deren fehlender "Jahr 2000"-Fähigkeit zurückzuführen. Die Einführung eines integrierten Systems ist kein einfaches Unterfangen, wie Kostenund Zeitüberschreitungen in vielen R/3-Projekten zeigen. Die Führung solcher Projekte stellt hohe Anforderungen an das verantwortliche Management. Zur Problematik von Einführungsprojekten existieren bisher nur wenige systematische Erfahrungssammlungen. Ausserdem waren die projektbestimmenden Rahmengrössen nur unzureichend bekannt. Mit der vorliegenden Arbeit wird das Ziel verfolgt, die verantwortlichen Entscheidungsträger für die mit einer EMS-Einführung verbundenen Nutzenpotentiale und Gefahren zu sensibilisieren. Kapitel 2 widmete sich der Darstellung der Merkmale von EMS und bietet eine Übersicht über die aktuell am Markt angebotenen Systeme. Während der Darstellung des Evaluationsprozesses wurde ein Schwergewicht auf die Informationsbeschaffung im Umfeld von EMS gelegt. Die Wahl des R/3-Systems als Beispiel für die anschliessende Untersuchung von EMS-Projekten lässt sich vor allem mit der hohen Marktakzeptanz (Marktanteil in einzelnen Marktsegmenten von über 30%) und breiten Anwendungsspektrum (Branchenübergreifende Einsatzbarkeit, Internationalität, Sprachen- und Währungsunabhängigkeit etc.) begründen. Zur Veranschaulichung des Umfangs und der Komplexität wurden die Leistungsmerkmale und die Funktionalität des R/3-Systems in Kapitel 3 ausführlich dargestellt, weil ein R/3-Projekt unzulässigerweise häufig mit der Einführung von Office-Paketen verglichen 333

2 wird. Dabei konnte gezeigt werden, dass praktisch das ganze betriebswirtschaftliche Anwendungsspektrum (Rechnungswesen, Logistik und Personalwesen) durch R/3 abgedeckt werden kann. Ausserdem weist die vorhandene Client/Server-Architektur einen hohen Flexibilitätsgrad auf und ermöglicht dadurch eine flexible Anpassung des Systems. Kapitel 4 widmete sich der Darstellung des Einführungsprozesses. Dabei wurden verschiedene Typen von Vorgehensmodellen (sequentielle Vorgehensmodelle, Wasserfallmodelle und Spiralmodelle) miteinander verglichen und Vor- und Nachteile diskutiert. Im Anschluss daran folgte die Darstellung des SAP-Vorgehensmodells, welches in der Schweiz in mehr als 50% der R/3-Projekte als methodische Basis eingesetzt wird. Dabei lässt sich feststellen, dass bei der Anwendung dieses Vorgehensmodells einige Einschränkungen zu beachten sind. Das SAP-Vorgehensmodell vernachlässigt den Evaluationsprozess: seine Aktivitäten setzen erst nach dem Entscheid für R/3 an. Dadurch entstehen viele Doppelspurigkeiten und die vorhandenen Ergebnisse aus dem Evaluationsprozess bleiben beim vorgeschlagenen Vorgehen weitgehend unberücksichtigt. Ein weiteres Manko bezieht sich auf die fehlende Integration von BPR-Aktivitäten, welche in den meisten Fällen direkt mit der Einführung gekoppelt sind. Viele Beratungsunternehmen haben dieses Defizit erkannt und bieten eigene Vorgehensmodelle an, welche möglichen BPR-Massnahmen besser Rechnung tragen. Ein weiterer Nachteil des SAP-Vorgehensmodells bezieht sich auf die ungenügende Berücksichtigung von Projektmanagement-Aktivitäten. Schwächen bei Einführungsprojekten sind häufig auf ungenügende Kenntnisse der Anwender und Berater im diesem Bereich zurückzuführen. Zur Ermittlung der kritischen Erfolgsgrössen wurden im zweiten Teil dieses Kapitels in Anlehnung an den Einführungsprozess mögliche Erfolgsfaktoren skizziert. Durch Expertengespräche unter Anwendung der Delphi-Methode erfolgte eine Bewertung dieser Faktoren. Dabei zeigte sich deutlich die bereits erwähnte Gewichtung. Die Bedeutung von projektmanagementbezogenen Faktoren wurde deutlich in den Vordergrund gehoben, während systemtechnische Faktoren eher als zweitrangig beurteilt wurden. 334

3 In Kapitel 5 wurde auf der Basis der in der Literatur gewonnenen Erkenntnisse und der Ergebnisse der Expertenbefragung ein konzeptioneller Bezugsrahmen (Begriffs- und Hypothesenschema) als Grundlage für die Durchführung einer quantitativen Untersuchung zu Erfahrungen bei der Einführung von R/3 aufgestellt. Anhand der dabei ermittelten Einflussgrössen wurden Vorschläge für die Bestimmung des Projektvolumens und des zeitlichen Aufwandes abgeleitet. Die von R/3-Anwendern als kritisch befundenen Erfolgsfaktoren dienten zur Formulierung von Handlungsempfehlungen für die erfolgreiche Abwicklung von Einführungsprojekten. Die empirische Untersuchung brachte folgende Haupterkenntnisse zutage: R/3 wird praktisch in allen Branchen und in sehr unterschiedlich grossen Unternehmungen (4-50'000 Mitarbeiter) eingesetzt. Hinsichtlich der Unternehmensgrösse lassen sich bei der Art des R/3-Einsatzes kaum Unterschiede feststellen. Hingegen unterscheidet sich im branchenübergreifenden Vergleich die Einsatzbreite (Anzahl eingesetzter Module) im Dienstleistungssektor aus naheliegenden Gründen von der Einsatzbreite des R/3-Systems in den übrigen Branchen. Bei der Untersuchung der Kosten und des Zeitbedarfs von R/3-Projekten konnten starke Abhängigkeiten zwischen der vorgesehenen Benutzerzahl und den finanziellen bzw. zeitlichen Aufwendungen ermittelt werden. Im Bereich der Kosten verursacht ein Benutzer Gesamtaufwendungen (Software-, Hardware- und Einführungskosten) von rund CHF 20' Dieser Wert gilt allerdings nicht für sehr kleine (weniger als 30 Benutzer) und sehr grosse R/3-Installationen (mehr als 2'000 Benutzer). Die Zahl der eingesetzten Module beeinflusst die Einführungskosten nur geringfügig. Verantwortlich dafür ist der eher homogene Einsatz des R/3-Systems. Durchschnittlich werden 6 R/3 Module (meist FI, CO, MM, AM, HR, SD) verwendet. Für die zeitliche Dauer von R/3-Projekten in Personenmonaten liess sich aus den empirischen Daten ebenfalls eine Schätzgrösse ermitteln. Pro Benutzer muss mit einem zeitlichen Aufwand von 0.4 Personenmonaten gerechnet werden. Aufgrund der errechneten Gesamtdauer in Projektmonaten lässt sich die Zahl der Projektmitarbeiter abschätzen. Besonders zuverlässige Werte ergeben die genannten Schätzgrössen im Industriesektor. In den anderen Sektoren (z.b. Dienstlei- 335

4 stungssektor) ist die Vergleichbarkeit der Projekte aufgrund der sehr unterschiedlichen Anforderungen eher fraglich. Obwohl sich anhand der dargestellten Werte das Projektvolumen und der zeitliche Aufwand einer R/3-Einführung grob bestimmen lässt, kann dadurch eine individuelle Aufwandschätzung nicht ersetzt werden. Die ermittelten Werte sind als Näherungsgrössen zu verstehen. Die ermittelten Hauptprobleme bei R/3-Projekten bezogen sich auf fehlende Akzeptanz, unzureichende Freistellung der Projektmitarbeiter, Koordinationsprobleme, Komplexität des R/3-Systems und fehlende Verfügbarkeit qualifizierter Berater. In direktem Zusammenhang zu den erwähnten Problemen steht die Gewichtung der kritischen Erfolgsfaktoren. Besonders in den Vordergrund gehoben wurden die Faktoren Auswahl des Beratungspartners, Projektleiterwahl, Einbezug des Managements, klare Fomulierung der Zielsetzungen, Kommunikation, Anwenderschulung und BPR. Bei der Auswahl von Beratungspartnern spielen Kriterien wie ausgewiesenes R/3-Knowhow für den aktuellen Releasestand, Branchen- und Projektmanagement-Kenntnisse eine massgebende Rolle. Der Projektleiter hat innerhalb des Projektes eine Kernfunktion inne. Die Anforderungen an seine Person beziehen sich stärker auf persönliche Eigenschaften (Durchsetzungsvermögen, Motivationskraft und Kommunikationsfähigkeit). Betont werden auch die Erfahrung mit Grossprojekten und die Kenntnisse der eigenen Organisation. Durch den Einbezug des Managements wird dem R/3-Projekt die notwendige Durchschlagskraft verliehen. Wichtige Entscheide können dadurch sofort gefällt werden und gleichzeitig führt die aktive Beteiligung zu einer Erhöhung der Akzeptanz. Durch klare formulierte Zielsetzungen wird die "Marschrichtung" bestimmt und die Zusammenarbeit der beteiligten Personen geregelt. Probleme bei der realistischen Zielformulierung können auf Anhieb durch einen iterativen Zielfindungsprozess entschärft werden. Zur Förderung der Akzeptanz und der Reduzierung von Koordinationsproblemen muss die Kommunikation mit allen Beteiligten ständig gepflegt werden. Eine offene Informa- 336

5 tionspolitik und klar geregelte Kommunikationsbeziehungen schaffen die dafür benötigten Grundlagen. Eine gleich hohe Bedeutung nimmt die seriöse Vorbereitung und Durchführung der Anwenderschulung ein. Durch eine schlechte Anwenderausbildung erhöht sich die Gefahr von Fehleingaben und dadurch vermindert sich die Datenqualität. Konsequenz ist ein Vertrauensverlust in Aussagekraft und Korrektheit der vom System zur Verfügung gestellten Daten und damit verbunden eine Erhöhung der Akzeptanzprobleme. Die Einführung eines EMS hat in den meisten Fällen organisatorische Änderungen zur Folge. Ein dazu notwendiges Reengineering der Geschäftsprozesse muss mit der Einführung des EMS koordiniert werden. Häufig wird zu diesem Zweck entweder eine vorgängige oder eine simultane Umgestaltung der Geschäftsprozesse empfohlen. Durch die konsequente Berücksichtigung der dargestellten Erfolgsfaktoren können R/3- Projekte zielgerichteter abgewickelt und latent vorhandene Probleme bereits im Keim erstickt werden. Die Probleme mit der Komplexität des R/3-Systems lassen sich durch Berücksichtigung dieser Faktoren zwar beeinflussen, können aber grundsätzlich nicht als gelöst betrachtet werden. Zur Bewältigung dieses Problems muss auch die SAP AG zusätzliche Anstrengungen für mehr Transparenz und eine Vereinfachung des Einführungsprozesses unternehmen. 337

6 7.2 Ausblick Die Beherrschbarkeit von integrierten betriebswirtschaftlichen Anwendungssystemen wird durch die Forderung nach universeller Einsetzbarkeit zunehmend in Frage gestellt. Im Unterschied zur Entwicklung von Individualsoftware wurde zwar mit der Einführung von EMS in dieser Hinsicht eine quantensprungartige Verbesserung erreicht. Die Komplexität ist immer noch relativ hoch. Durch verschiedene, teilweise noch unausgereifte Ansätze wird versucht, die Grenzen des Machbaren immer weiter nach oben zu schieben. Seit einigen Jahren wird versucht, das Customizing von EMS durch den Einsatz von entsprechenden Tools zu vereinfachen. 314 Mittels Fragenkatalog werden die Bedürfnisse des Anwenders ermittelt. Ein integriertes Regelwerk versucht anhand der angegebenen Informationen die optimale Systemeinstellung zu finden. Das Problem dieses Ansatzes ist die schwere Voraussehbarkeit der Wirkungszusammenhänge der vorhandenen Einstellgrössen (z.b. Konfigurationsmöglichkeiten eines PPS-Systems). Diese müssten für einen praxistauglichen Einsatz vollumfänglich bekannt sein. Gleichzeitig besteht das Problem, dass das Regelwerk für jeden neuen Release wieder angepasst werden muss. Bei einfacheren Einstellungen (z.b. Abbildung der Organisationsstruktur) ist eine Verwirklichung dieses Ansatzes mit Hilfe von regelbasierten Werkzeugen durchaus praktikabel und auch bereits teilweise umgesetzt (vgl. ASAP 315 ). 314 Vgl. Hartinger (1995), S. 51 ff.; Mertens/Wedel/Hartinger (1991), S. 569 ff. 315 Vgl. Bürkle (1997). 338

7 Eine weitere Möglichkeit zur Reduktion der Einführungszeit ist der Einsatz von kundenspezifisch voreingestellten Systemen (configure to order). 316 Der Kunde sieht nur die für ihn relevanten Bereiche und kann sich dadurch bei der Einführung auf das Wesentliche konzentrieren. Der Vorteil dieser Methode liegt sicherlich auf der Kundenseite. Das Problem besteht aber darin, ein neues System sachgerecht kundenspezifisch einzustellen. Durch die Verwendung der Systemeinstellungen eines ähnlichen Anwendungsfalls lassen sich gewisse Synergien ausnutzen. Aber grundsätzlich sieht sich der Softwarehersteller mit sich ähnelnden Problemen (Releasewechselproblematik) konfrontiert wie beim toolbasierten Ansatz. Eine Vereinfachung könnte durch die Isolation von einzelnen Geschäftsprozessen erreicht werden. Für jeden Geschäftsprozess existieren vorkonfigurierte Varianten und im Bedarfsfall wird ein Anwendungssystem nach dem Component-Ware-Prinzip zusammengesetzt. Durch die starke Integration der einzelnen Anwendungsbereiche scheint auch mit diesem Ansatz vorläufig kein bahnbrechender Erfolg zu realisieren sein, weil die Problematik der Integration der Komponenten besteht. In einem weiteren Ansatz wird die Idee verfolgt, betriebwirtschaftliche Anwendungsobjekte verschiedener Hersteller über das Netz zu integrieren (Network Business Objects). 317 Voraussetzungen dafür sind eine konsequente Kapselung der einzelnen Objekte und die Standardisierung der Schnittstellen (z.b. CORBA). Der Anwender könnte exakt auf seine Bedürfnisse abgestimmte Business Objekte auf dem Markt erwerben und frei miteinander kombinieren. Der Konfigurationsaufwand könnte durch massgeschneiderte Prozesse erheblich reduziert werden. Insgesamt betrachtet erscheint dieser Ansatz plausibel. SAP verfolgt mit der Entwicklung ihres Business Frameworks eine ähnliche Stossrichtung. Nachteile dieses Konzepts sind Probleme mit der Standardisierung der Schnittstellen und die Probleme der einfachen Systemintegration. 316 Vgl. SAP AG (1997b). 317 Vgl. Shepard (1995). 339

8 Allen Konzepten ist eines gemeinsam: Es wird auf einfache Weise versucht, den Einsatz von Informationssystemen auf der betriebswirtschaftlichen Anwendungsplattform zu vereinfachen und damit eine Kostenreduktion und kürzere Einführungszeiten zu bewirken. Die geforderten Sachziele, die Steuerung des Leistungserstellungsprozesses und die rasche Bereitstellung von entscheidungsrelevanten Informationen, bleiben immer die gleichen. Der erforderliche Anpassungsaufwand bei einer Veränderung der Anforderungen muss weiter reduziert werden, damit mit den Marktveränderungen Schritt gehalten werden kann. Lösungsansätze für die Reduktion der Komplexität integrierter Systeme sind in der tool-basierten Einführungsunterstützung und in der Desintegration der einzelnen Anwendungsbereiche zu suchen. *** 340