Das Schlagwort "Global Player" hat es in sich: Global bedeutet nicht nur "auf dem Weltmarkt präsent", sondern auch "global gesteuert". Das setzt transparente internen Abläufe voraus. Player heißt "nach gewissen, der Unternehmenskultur angepassten Regeln spielend" sowie "auf Veränderungen flexibel und effizient reagierend". Letzteres lässt sich erreichen, indem die Einführung von ERP-Software zentralen Vorgaben (Templates) folgt.

Entgegen den üblichen - auf zwei bis drei Jahre angelegten - Planungen kann die Einführung eines ERP-Systems drei bis fünf Jahre dauern. Das hängt von der Unternehmensstruktur und der Diversifizierung ab. Da ist langer Atem gefragt, nicht kurzfristiger "Erfolgshunger". Wird die Einführung richtig gemacht, also auf das Unternehmen abgestimmt, winken als Lohn der Mühen eine hochgradige Standardisierung oder die Harmonisierung als gelungener Kompromiss von Prozess- und Systemlandschaft. Standardisierung bedeutet auch hier die Anlehnung an ein vorgegebenes Modell.

Unterschiedliche Prozesse - intransparente Kosten

Die Ausgangssituation ist in vielen Unternehmen identisch. Systemlandschaften sind künstlich aufgebläht; Prozesse, die eigentlich nach den vorgenommenen Anpassungen identisch sein sollten, werden in den einzelnen Geschäftseinheiten weiterhin unterschiedlich ausgeführt, und die Kosten sind wenig transparent.

Im Sinne einer globalen Aufstellung sollten Prozesse und Systeme zusammengeführt werden. Dabei muss die Veränderung der Prozesse eine Veränderung der Systeme bedingen - nicht umgekehrt. Also sind die Fachbereiche die treibende Kraft. Der Finanzvorstand, Personalchef oder Einkaufsleiter erwarten allerdings, dass "der Strom aus der Steckdose" kommt. Sie sind häufig verwundert, wenn sie sich in einem Change-Management-Prozess wiederfinden.

Erfolgreiche Projekte müssen einen guten Mix aus Business und IT hinbekommen. Das Team sollte das Tagesgeschäft kennen, aber zu hundert Prozent dem Projekt zugeordnet sein. Berichtet der Projektleiter an den Business-Vorstand, so ist bereits die halbe Miete eingefahren.

Unternehmen nutzen häufig eigene Vorgehensmodelle

Standardrezepte zur Vorgehensweise gibt es leider nicht. Die Unternehmen nutzen vorzugsweise eigene Modelle. Entscheidungsfaktoren für die Vorgehensweise sind - neben den bekannten Faktoren Kosten, Zeit und Personaleinsatz - der Wille zur Veränderung seitens der Geschäftsführung, eine Diversifizierung der Geschäftseinheiten, die Komplexität der Prozess- und Systemlandschaft, der Integrationsgrad oder die Projektorganisation samt den entsprechenden Fähigkeiten (Skills).

In der Praxis beginnen die Vorgehensmodelle bei der unternehmensweiten Adaption von "Best-Practice"-Geschäftsprozessen und enden beim einheitlichen Geschäftsmodell (Template). Im ersten Fall entscheidet sich das Unternehmen aufgrund der Diversifizierung seiner Geschäftssparten dazu, bewährte Prozesse unternehmensweit zu standardisieren. Es verzichtet dabei gegebenenfalls auf Integrationsfaktoren. Im Interesse der Unternehmensziele lassen sich eigens zugeordnete Task Forces oder Kompetenzzentren aufbauen, die für die Implementierung und Weiterentwicklung der Prozesse verantwortlich zeichnen und von einem übergeordneten Projekt-Management gesteuert werden.

Sind die Ziele nicht von Anfang an in die strategischen Überlegungen eingebunden, findet sich das Projekt zwangsläufig im Dreieck aus Budget, Personal und Zeit wieder. Dann wird an den Ausgangsparametern gedreht, und die Folge sind häufig entweder höhere Kosten oder Abstriche an den Anforderungen.

Die Implementierung einheitlicher Geschäftsprozesse über das gesamte Unternehmen setzt eindeutige Prioritäten auf Seiten der Geschäftsführung voraus. Hauptmerkmale einer zentralen Template-Strategie sind eine homogene Reporting-Struktur, die länderübergreifende Transparenz von Prozessen, die Stammdaten-Bereinigung sowie die Standardisierung der IT-Infrastruktur und der Anwendungen.

Die Grenzen der Standardisierung

Jeder CIO einer lokalen Einheit hat in der Vergangenheit seine IT so weit wie möglich an die Anforderungen seiner Kollegen aus Finanzwesen, Einkauf oder Logistik angepasst. An dieser Stelle lautet die Frage deshalb: Wie weit geht der Template-Ansatz? Manche Ausprägungen sehen unternehmensweite Templates vor, die über zentrale Teams weltweit kontrolliert werden; nach Abschluss des Projekts geht die Verantwortung in die Serviceorganisation über. Änderungsanträge werden dabei über globale Teams autorisiert, um das Template nicht zu gefährden. Der späteren Optimierung oder Anpassung an Benutzeranforderungen sind hier möglicherweise Grenzen gesetzt.

Vorstellbar ist auch die Kopplung von globalen Templates - im Finanz- oder Einkaufsbereich - mit regionalen eigenständigen Speziallösungen, die einen Business Case vorweisen können. Allerdings muss dabei immer der Pflegeaufwand für externe und interne Teams im Auge behalten werden. Auch die Architektur der Systemlandschaft - bezogen auf Supportstrukturen, Transportwesen und Ausfallsicherheit - spielt hier eine wichtige Rolle.

Eine Template-Strategie zielt ganz und gar auf das Gesamtunternehmen ab - also weniger auf einzelne Geschäftseinheiten, die sich unter Umständen darin nicht adäquat berücksichtigt finden. Erschwerend kommt hinzu, dass die Einheiten unter Umständen mit höheren Kostenumlagen rechnen müssen, die allerdings langfristig kompensiert werden.

Der Top-down-Ansatz

Bei einem Template-Projekt hat das Programm-Management unter anderem die Aufgabe, den "roten Faden", also die Vision eines einheitlichen Unternehmens ("One Company Vision"), im Visier zu halten. Die wichtigste Entscheidung muss aber gleich zu Beginn des Projekts vom Management getroffen werden. Sie betrifft die strategische Ausrichtung, die Einfluss auf die Prozessmodellierung und die spätere Umsetzung nimmt.

Ein zentrales Template zu nutzen heißt, einem Top-down-Ansatz zu folgen. Dieses Konzept sollte sich auch in Planung und Umsetzung wiederfinden. Ganz oben auf der Agenda steht das Herausarbeiten von Standardisierungsansätzen. Zunächst muss geklärt werden, welche Prozesse standardisiert werden können und wie sie sich auf die Organisation auswirken. Darauf aufbauend sind Datenstrukturierung und -harmonisierung zu betrachten. Mit der Standardisierung der Daten einhergehen sollte die Integration der definierten Datenstandards in die Systemlandschaft.

Als nächster Schritt steht die Einbindung der Fachabteilungen an. Dabei muss geklärt werden, welche Change-Management-Funktionen in den einzelnen Niederlassungen existieren. Die Abweichungen der künftigen Prozesslandschaft vom Status quo sind für einzelne Organisationseinheiten möglicherweise massiv, beispielsweise in den Einkaufsprozessen, die neben internen auch externe Ressourcen einbinden.

Zentralisierter Business-Blueprint

Für das Erarbeiten von Standardisierungsansätzen sowie deren Umsetzung empfiehlt sich ein zentralisierter Business-Blueprint. Länderspezifische Abweichungen sollten nur bei gesetzlichen und steuerlichen Anforderungen zugelassen werden. Darüber hinaus heißt es, Prioritäten zu setzen: Unter Umständen müssen vorhandene Prozesse zunächst über Schnittstellen integriert werden, weil die technischen Lösungen im ERP-System ansonsten modifiziert werden müssten oder weil diese Prozesse später im Projektverlauf ohnehin neu integriert werden müssen.

Solche Fragen sollten zwischen Projekt-Management und der Einführungsorganisation abgestimmt werden. Dasselbe gilt für die mit dem Echtstart verbundenen Risiken und die Maßnahmen zu ihrer Verringerung. Die manuelle Weiterführung eines Prozesses nach dem Going-Live ist auf ein Minimum zu reduzieren, sonst würde die angepeilte Effektivität von den Geschäftseinheiten bezweifelt und der Business Case gefährdet.

Schließlich muss auch festgelegt werden, wann der Bedarf einer Niederlassung mit dem nächsten Release gedeckt werden soll. Hier ist häufig Überzeugungsarbeit in Richtung der lokalen Einheit zu leisten. Die Prioritäten sind doch zuweilen unterschiedlich verteilt, beispielsweise beim Reporting. Aus der langfristig angelegten "Vogelperspektive" des Programm-Managements stehen Standardprozesse im Vordergrund, beispielsweise in Beschaffung oder Rechnungswesen. So hat vielleicht die Einführung einer Schnittstelle Vorrang vor der Verfeinerung eines speziellen Reports.

Die lokale Einheit strebt selbstverständlich danach, alle Prozesse so schnell wie möglich in das neue System zu übernehmen, weil sie sie für die tägliche Arbeit braucht. Das erfordert ein angemessenes internes Release-Management - direkt nach dem Projekt wie auch im laufenden Betrieb.

Eine Simultan-Schach-Partie

Solche ein internationaler Rollout ist mit Simultan-Schach vergleichbar. Der Programm-Manager spielt nach vorgegebenen Regeln parallel mit allen Beteiligten. Er sieht sich dabei mit unterschiedlichen Anforderungen konfrontiert. Seine Kunst besteht darin, in allen Spielen die Entscheidung zu treffen, die den Projektfortschritt im Sinne des gesamten Unternehmens sichert. Konflikte lassen sich durch eine enge Kooperation von Projekt-Management und Geschäftsleitung lösen.

Gegen die Silo-Organisation

Aber auch in Richtung Unternehmensführung ist bisweilen Aufklärungsarbeit zu leisten. Das Verständnis für die Globalisierung ist nicht in allen Einheiten eines Unternehmens gleich ausgeprägt. Viele Unternehmen sind noch in Silos organisiert; ihre Funktionalbereiche müssen erst lernen, integriert zu arbeiten und einen Prozessschritt nicht mit der Übergabe eines Dokuments als beendet zu betrachten. Diesen Unternehmen fällt es naturgemäß schwer, integrierte Prozesse einzuführen oder auf Legal-Entity-Basis zu arbeiten.

Ein wichtiger Punkt bei der Einführung von ERP-Systemen ist daher das Change-Management. Wie intensiv es betrieben werden muss, hängt vom Grad der Standardisierung ab. Ob es Erfolg hat, ist eine Frage der Kommunikation. Strategische Entscheidungen sollten unbedingt vom (Senior-)Management in das Unternehmen getragen werden. Auf der operativen Ebene empfiehlt es sich, über die Prozessverantwortlichen zu kommunizieren.

Großzügig bemessen sein sollte die Vorlaufzeit, die ein Projektteam braucht, um in einer Geschäftseinheit eine ERP-Lösung zu implementieren. Deshalb sind Verhandlungen mit einem externen Partner über den finalen Systemintegrationsteil erst zu führen, nachdem die Anforderungen spezifiziert sind. Änderungen können nie ausgeschlossen werden, aber zumindest lassen sich so die finanziellen Auswirkungen in Grenzen halten.

Künftige Anforderungen

Durch Enterprise SOA (vormals ESA) und "Netweaver" öffnet sich das führende ERP-System dem Wettbewerb. Die Unternehmen müssen ihre Release-Strategie darauf ausrichten und externe Lösungsansätze dahingehend prüfen, wie sie sich in die SAP-Landschaft integrieren lassen.

In den Projektteams werden künftig auch Prozessexperten ("Business Process Experts") vertreten sein, die nicht nur die IT-Seite, sondern auch den Prozessgedanken abdecken. Die Unternehmen müssen sich also damit auseinandersetzen, wie sie eine optimale Personalstruktur entwickeln können, die den Anforderungen der Globalisierung gewachsen ist. (qua)