DataNavigator #19: Softwareeinführungsprojekte im internationalen Kontext

Softwareeinführungsprojekte sind bereits im nationalen Kontext von hoher Komplexität und zahlreichen Herausforderungen geprägt. Meist werden die initial abgestimmten Projektpläne durch Verzögerungen in der Anforderungsabstimmung und -freigabe oder bei der eigentlichen Konfiguration und Entwicklung angepasst. Das Resultat sind Projekte, die entweder signifikant das geplante Budget und die geplante Einführungszeitleiste überschreiten oder sogar komplett abgebrochen werden müssen.

Zur besseren Illustration nehme man ein international tätiges Asset Finance-Unternehmen, das ein neues System weltweit in den Landesgesellschaften einführen möchte. Auf den ersten Blick unterscheidet sich ein Leasing- oder Finanzierungsprodukt weltweit nicht sonderlich. Man hat ein Asset, welches je nach Laufzeit, Nutzungsverhalten und Restwert mithilfe eines Zahlungsplans dem Kunden angeboten wird – dies gilt weltweit. Eine Einführung in ver­schiedenen Ländern sollte also doch gar nicht so schwer oder komplex sein!

Mit dieser Annahme würde man sehr wahrscheinlich schnell merken, dass man das Thema signifikant unterschätzt hat. Wagt man sich an eine Softwareeinführung in mehreren Ländern, kommt es zu einer Reihe von weiteren Herausforderungen, die über die nationalen hinaus­gehen. Zum einen gibt es „harte“ Faktoren bei den Herausforderungen, wie regulatorische, fachliche und technische Anforderungen. Zum anderen gibt es „weiche“ Faktoren bei den Herausforderungen, wie Expertise und Abstraktionsfähigkeit, Verfügbarkeiten und Zeitzonen sowie die allgemeinen kulturellen Herausforderungen.

Die Herausforderungen, die diese harten und weichen Faktoren stellen, werden im Folgenden kurz skizziert bevor denkbare Lösungsansätze für erfolgreiche Softwareeinführungsprojekte auch im internationalen Kontext illustriert werden.

Lokale Anforderungen als harte Determinanten im Projekt

Softwareeinführungen im internationalen Kontext funktionieren nicht ohne Berücksichtigung lokaler Anforderungen. Bei der Einführung eines Contract Management Systems für einen Asset Finance-Anbieter sind daher vielfältige Anforderungen zu erfüllen, die ein entsprechendes Projekt hart beschränken. Diese harten Faktoren lassen sich wie in Tabelle 1 skizziert unterscheiden:

Betrachten wir zur Verdeutlichung der Herausforderungen, die diese harten Faktoren mit sich bringen, zwei Beispiele für regulatorische und funktionale Anforderungen genauer.

Es ist unabdingbar, dass es unterschiedliche regulatorische Anforderungen in unterschied­lichen Ländern gibt. Diese Änderungen müssen zwingend umgesetzt werden, und es ist von Vorteil, wenn ein Softwarehersteller bereits eine laufende Lösung in dem jeweiligen Land hat. Das mag für Unternehmen wie SAP und Microsoft zwar zutreffen, aber bei vielen Software­herstellern handelt es sich um lokale Anbieter, die sich opportunistisch globalisieren. So sehen sich die Hersteller in jedem Land einer neuen Herausforderung gegenüber. Man könnte meinen, dass gemeinsame Regularien im EU-Raum zumindest die Einführung eines Systems in EU-Ländern vereinfachen würden, aber das entspricht nicht ganz der Realität.

Nehmen wir zum Beispiel die EU-Datenschutzgrundverordnung „General Data Protection Regulation“ (GDPR), eine Verordnung, die für alle EU-Mitglieder gilt. So könnte man annehmen, dass Softwarehersteller, die der EU-weiten GDPR entsprechen, in der Einführung in weiteren EU-Ländern einen Vorteil haben. Dem ist aber leider nicht so. Jedes Land hat einen gewissen Spielraum zur Auslegung der GDPR, wie zum Beispiel in Deutschland durch die Datenschutz-Grundverordnung (DSGVO). Daher müssen in (fast) jedem Land in Europa lokale Anpassungen aufgrund einer vermeintlich EU-weiten Verordnung erfasst, definiert und umgesetzt werden.

Beispielhaft dafür ist die Vorgabe unter der GDPR ein „Data Protection Impact Assessment“ (DPIA) durchzuführen. In den meisten europäischen Ländern ist diese nicht verpflichtend. Nur in Frankreich gibt es eine Pflicht zur Durchführung von DPIAs für Datenverantwortliche bezüglich von Risiken für die Rechte und Freiheiten des Einzelnen, aber keine regulatorische Pflicht. In den Niederlanden gibt es dagegen eine Regel, dass die Regierung bei datenrelevanten Gesetzesvorschlägen ein DPIA berücksichtigt. In UK und Italien wiederum werden Leitlinien für die Durchführung von DPIAs herausgegeben und in Deutschland gibt es Standards und Vorgaben für eine freiwillige Durchführung von DPIAs.

Gleiches gilt für funktionale Anforderungen. Es wäre eine Illusion zu denken, dass es weltweit keine Unterschiede gibt. Im Gegensatz zu regulatorischen Anforderungen gibt es bei den funktionalen Anforderungen hingegen mehr Möglichkeiten, diese zu hinterfragen und auf wirtschaftlichen Sinn zu prüfen. Das Beispiel der typischen Abrechnungszyklen regelmäßiger Beitragszahlungen illustriert die Unterschiede funktionaler Anforderungen je nach Land. Die Abrechnungszyklen haben oft den gleichen Rhythmus wie die Lohnzahlungen, in Deutschland also monatlich. Im System muss daher ein monatlicher Abrechnungszyklus verfügbar sein. Dieser kann meistens aus zwei bis drei Optionen bestehen, ob man am Anfang, in der Mitte oder am Ende des Monats bezahlen möchte. Diese Anforderung ist in vielen Ländern gleich. Schaut man sich jedoch Australien an, wo Lohnzahlungen alle zwei Wochen erfolgen, sieht man die Anforderung von zweiwöchentlichen Abrechnungszyklen. Auch diese Anforderung kann durch die Wirtschaftlichkeitsfrage geprüft werden. Da man durch diese gängige Ab­rechnungsart in dem jeweiligen Land wahrscheinlich viele Kunden verlieren würde, wenn man die Abrechnung nur monatlich anbietet, und der Verlust der Kunden die Investition in die Anforderungsumsetzung übersteigt, ist diese Anforderung gerechtfertigt und muss über­nommen werden.

Anhand der Beispiele wird deutlich, dass man bei internationalen Softwareeinführungen nicht ohne Berücksichtigung lokaler Anforderungen auskommt.

Unterschiedliche Gepflogenheiten als weiche Faktoren

Lokale Systemanforderungen in den Ländern sind aber meist nicht die größten Heraus­forderungen. Neben den harten Faktoren spielen daher die weichen Faktoren oftmals eine nicht zu unterschätzende Rolle in den Projekten und können durchaus über Erfolg oder Misserfolg entscheiden. Tabelle 2 skizziert wichtige weiche Faktoren mit dazugehörigen Beispielen:

Nehmen wir daher das Beispiel Verfügbarkeiten und Zeitzonen genauer unter die Lupe. Bei internationalen Einführungsprojekten arbeitet man meist in Gruppen aus verschiedenen Ländern zusammen. Neben den offensichtlichen Zeitunterschieden auf der Welt gibt es aber auch innerhalb einer Zeitzone Herausforderungen, die einem nicht direkt in den Sinn kommen, zum Beispiel Anfangs- und Endzeiten eines typischen Arbeitstages. In Deutschland wird spätestens um acht Uhr morgens angefangen, um zwölf mit dem Glockenschlag die Mittags­pause (meist dreißig oder sechzig Minuten) eingeläutet und um siebzehn Uhr die Tür hinter sich abgeschlossen. Anders sieht es in Spanien aus, wo der Arbeitsbeginn nicht vor neun Uhr, wenn nicht sogar zehn Uhr, erfolgt und die Mittagspause gerne auch zwischen dreizehn und fünfzehn Uhr (meist 90 Minuten) gelegt wird. Der Arbeitstag endet dafür auch erst nach neunzehn Uhr. Legt man diese Zeiten übereinander, bleiben nur wenige Stunden am Tag, in denen sich die Arbeitszeiten überschneiden und ein gemeinsames Arbeiten ermöglicht wird.

Hybrider Lösungsansatz zur Erfüllung der harten Anforderungen

Nun stellt sich oft die Frage, ob eine Standardsoftware für einen internationalen Einsatz über­haupt in Frage kommt oder ob man doch auf eine Individuallösung auf lokaler Ebene setzen muss. Die Wahl zwischen einer Standard- und einer Individuallösung ist oft eine Gratwande­rung. Beide Extreme sind in diesem Fall auch nicht zu empfehlen.

Eine Standardlösung kann zwar kostengünstig und schnell implementiert sein, aber im Zweifel muss der Standard so stark angepasst werden, dass er zu den lokalen Anforderungen passt. Das kann bei einer nicht modularen Bauweise des Systems auch schnell dazu führen, dass die individuellen Anpassungen gegen den Standard arbeiten und das System entweder fachlich den Anforderungen nicht entspricht oder technisch so komplex umgesetzt wird, dass die Per­formance darunter leidet.

Eine Individuallösung hingegen lässt schnell den Eindruck entstehen, dass alle lokalen Anfor­derungen nach Belieben umgesetzt werden können und man dadurch in Bezug auf Projekt­laufzeit und Kosten untergeht. Dabei öffnet man oft die Tür, nicht diszipliniert genug die Anforderungen zu hinterfragen, da man sich ja speziell auf die individuelle Lösung eingelassen hat.

Die Empfehlung liegt daher, wie so oft, in der goldenen Mitte. Der Standardansatz darf nicht den Anspruch einer Plug-and-Play-Lösung haben, und der Individualansatz darf nicht gleich­bedeutend mit der Umsetzung aller Anforderungen sein. Eine Lösungsempfehlung kann also zweigeteilt sein.

Eine Standardlösung sollte als Grundlage der Software definiert werden. Dabei sollte man unbedingt eine Gruppe möglicher Länder, in denen die Software eingeführt werden soll, bei der Auswahl und Definition der Standardlösung eng einbinden. Die Länder müssen sich über die Kernfunktionalitäten einig werden und am Ende ihr „Commitment“ abgeben, dass sie die Funktionalitäten in dieser Ausprägung nutzen werden. Diese Kernfunktionalitäten umfassen typischerweise die grundlegenden Geschäftsprozesse, die über alle Länder hinweg gleich sind. Falls es zu gemeinsamen Anpassungen an der Standardsoftware kommen sollte, können die Kosten über alle Länder hinweg aufgeteilt werden.

An den Stellen, an denen die Länder stark voneinander abweichen, wird die Basissoftware um lokale Anforderungen erweitert. Dabei sind die Länder dazu angehalten, jegliche Änderungen am Standard der Basissoftware zu rechtfertigen, indem sie eine Wirtschaftlichkeitsrechnung präsentieren müssen. Es werden nur Anforderungen umgesetzt, die einen positiven Business Case vorweisen können.

Dieses in Abbildung 1 illustrierte Vorgehen ermöglicht es, die Software auf die Bedürfnisse der Länder zuzuschneiden, ohne dabei die Grundfunktionalitäten und den Kern der Software zu gefährden.

Einbindung der Menschen als weicher Erfolgsfaktor

Die involvierten Menschen im Projekt sind ausschlaggebend für eine erfolgreiche Einführung der Software. Ohne motivierte und befähigte Projektmitarbeiter wird es keine erfolgreiche Einführung geben. Der Lösungsvorschlag für die Software-Architektur lässt sich auch auf das Projektteam übertragen.

Wenn es um einen Mehrländer-Rollout geht, ist ein zentrales Kernteam, das alle Einführungen weltweit mitbegleitet, unabdingbar. Den Lerneffekt, den dieses Kernteam mit sich trägt und mit jedem Rollout anreichert, bietet einen enormen Vorteil gegenüber individuellen lokalen Teams. Mit jeder weiteren Einführung wächst die Expertise und die Erfahrung im Kernteam und kann im nächsten Land angewendet werden. Nach mehreren Einführungen kann dadurch das Kernteam durch den Multiplikatoreffekt erweitert werden, indem man neue Ressourcen in ein erfahrenes Team einbindet.

Diese zentralen Kernteams arbeiten mit der lokalen Projektorganisation eng zusammen und geben ihr Wissen weiter. Sie trainieren und befähigen die lokalen Teams damit diese spätestens ab der Übergabe vom Projekt an die Produktion selber in der Lage sind, die Anwendung zu verwalten und weiterzuentwickeln. Bereits mit dem Start der Einführung sollten daher die Personen ernannt werden, die das System in der Produktion übernehmen werden, damit sie sukzessive an das System herangeführt werden und Teil der Einführung sind. Sie können dadurch besser nachvollziehen, wie das System funktioniert und warum gegebenenfalls Funktionalitäten abgewählt wurden. Die lokale Organisation ist damit nicht nur Anwender, sondern wird zum Eigentümer der Anwendung.

Fazit

Die Kombination aus Standardlösung und Individuallösung bietet eine ausgewogene Herangehensweise an die internationale Softwareeinführung und zum Management der harten Faktoren. Während die Standardlösung eine einheitliche Grundlage schafft und Kosteneinsparungen ermöglicht, erlaubt die Individuallösung die Anpassung an lokale Bedürf­nisse und Geschäftsprozesse. Unternehmen sollten sorgfältig abwägen, welche Funktionen standardisiert werden können und welche Bereiche tatsächlich spezifische Anpassungen erfordern.

Diese Mischung aus Standard- und Individuallösung ist in analoger Weise unbedingt auch auf das Projektteam zum Management der weichen Faktoren zu übertragen. Ein zentrales Kern­team, welches alle Einführungen mitbegleitet, Erfahrungen anreichert und in die lokalen Projekte weitergibt, hilft dabei die ein oder andere Herausforderung zu minimieren und den Projekterfolg zu sichern.