Suche
Close this search box.
Suche
Close this search box.

DataNavigator

Ihr Ansprechpartner

Fabio Giacomo Müller

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:

BeschreibungBeispiele
Regulatorische AnforderungenGesetze und regulatorische Vorgaben unterscheiden sich in jedem Land. Nicht nur muss die Software in der Lage sein, die unterschiedlichen regu­latorischen Anforderungen umzu­setzen, sondern es müssen auch lokale Experten die Anforderungen detailliert und regulatorisch konform definieren.Rechnungslegung:
Abdeckung nationaler und interna­tionaler Rechnungslegungsanforde­rungen (HGB, IFRS etc.)
Bankregulatorik:
Bundesbank / EZB-Aufsicht
IT-Sicherheit/IT-Risiko:
MaRisk, BAIT
Risk & Compliance:
Know your Customer (KYC)
Funktionale AnforderungenFunktionalitäten unterscheiden sich von Land zu Land, sei es durch indivi­duell getriebene Funktionalitäten oder marktspezifische Gegebenheiten, die das Kundenverhalten abdecken. In den meisten Fällen wird eine bestehende Software abgelöst, und die Benutzer hängen noch an den Funktionalitäten aus dem Altsystem, auch wenn diese nicht geschäftskritisch sind.Geschäftskritisch:
Notwendig für tägliches Geschäft
Marktdifferenzierend:
Wettbewerbsvorteile, USPs
Prozessual:
Verbesserte Bedienung, höherer Automatisierungsgrad
Design / Look & Feel:
Modernes Design, verbesserte Bedienung
Technische AnforderungenTechnische Anforderungen lassen sich in zwei Bereiche aufteilen. Zum einen gibt es die Infrastrukturthemen rund um die IT-Landschaft, die oft dezentral in den Ländern aufgebaut wurden und nur selten einheitliche Leistungen aufzeigen. Zum anderen betrifft es die technische Integration mit lokalen Systemen, wie z.B. lokalen Kreditaus­künften.Architektureller Fit:
Anpassungsfähigkeit an die kon­zernweite Plattform
Tech Stack:
Cloud-fähig, Microservices, APIs
Standardintegrationen:
Abdeckung an international ver­breitete Systeme
Softwarefähigkeiten:
Mehrwährungsfähigkeit, Mandan­tenfähigkeit
Tabelle 1 – Harte Faktoren bei internationalen Softwareeinführungen

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:

BeschreibungBeispiele
Expertise und Abstraktions-fähigkeitExpertise in den Unternehmen ist über mehrere Abteilungen und Ressourcen verteilt. Die richtigen Experten zu identifizieren, ist bereits eine Heraus­forderung. Zudem bedarf es bei diesen Experten auch einer Abstraktions­fähigkeit, um Geschäftsvorfälle auf ein Niveau zu bringen, in dem notwendige Funktionalitäten durch das Neusystem gegebenenfalls prozessual anders verarbeitet werden.Detailwissen:
Bereichsexperten, wie z.B. Accounting, Operations
Fehlende Abstraktionsfähigkeit:
Kein Blick über den eigenen Bereich hinaus
Transferleistungen:
Fehlendes Verständnis, sobald es zu kleinsten Abweichungen kommt
Verfügbarkeit und ZeitzonenLimitierte Verfügbarkeiten aufgrund unterschiedlicher Zeitzonen reduzieren die Möglichkeiten zur Zusammenarbeit speziell außerhalb Europas. Dies gilt wegen verschiedener Arbeits­gepflogenheiten unter Umständen selbst innerhalb einer Zeitzone. Hinzu kommen seit der Covid-Zeit ein geringeres Reiseaufkommen und vermehrte digitale Zusammenarbeit.Arbeitsbeginn / -ende:
Später oder früher Beginn/Ende
Pausenzeiten:
Typische Pausenzeiten, speziell Mittagspause
Zeitzonen:
Interkontinental, aber auch kontinental
Flexible Arbeitszeiten:
Gleitzeit, Halbtags etc.
Kulturelle UnterschiedeWährend Sprachbarrieren offensicht­liche kulturelle Unterschiede in ver­schiedenen Ländern darstellen, gibt es weitere Arbeits- und Kommunikations­verhalten, die sich teilweise stark unterscheiden und zu Missverständ­nissen führen können. Dies kann sich negativ auf die Arbeitsmoral aus­wirken. Das Thema alleine füllt ganze Bücher, Seminare oder Fortbildungen.Hierarchie Denken:
Flache oder strikte Hierarchie­struktur
Kommunikationsstil:
Direkte oder indirekte Kommuni­kation
Pünktlichkeit:
Termintreue
Konfliktbewältigung:
Ausweichen oder direkte Konflikt­kommunikation
Tabelle 2 – Weiche Faktoren bei internationalen Softwareeinführungen

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.

Abbildung 1 – Komplexitätsreduktion durch hybriden Ansatz

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.

Ihr Ansprechpartner

Fabio Giacomo Müller
DataNavigator
Kann der Einsatz von Künstlicher Intelligenz die Erfüllung der Anforderungen an die Nachhaltigkeitsberichterstattung erleichtern? Tomislav Bisic und Simon Wilmerding schildern
DataNavigator
Wann immer es um Daten geht, spielt auch die Möglichkeit einer Manipulation von Daten eine Rolle. Die kritische Abschätzung von
DataNavigator
Tokens sind digitale Objekte, die eigenständig einen Wert darstellen. Sie bieten damit großes Potential, Eigentum an vielfältigen Vermögenswerten nicht nur