Wenn Wachstum Regionalisierung bedeutet
Ein europäischer Hersteller ist seit Jahren in China tätig. Was ursprünglich ein Absatzmarkt war, hat sich nach und nach zu einer strategischen Geschäftseinheit entwickelt – mit eigenen lokalen Kunden, Lieferanten und Partnern. Um seine Position zu stärken, beschließt das Unternehmen, seinem China-Geschäft mehr Eigenständigkeit zu geben: mit einer eigenen Vertriebsstruktur, eigenen Entscheidungsbefugnissen und einer engeren Zusammenarbeit mit lokalen Partnern und Lieferanten.
Zunächst scheint dies eine reine Geschäftsentscheidung zu sein. Systeme und Daten spielen in den Überlegungen kaum eine Rolle. Im Mittelpunkt steht weiterhin der Ausbau des Geschäfts. Sechs Monate später landet die erste unangenehme Frage auf dem Tisch. Ein neuer lokaler Partner benötigt Zugriff auf Systeme, für die die globale IT-Architektur nie ausgelegt war. Kurz darauf stellt die Compliance-Abteilung eine noch kritischere Frage: Durften die Daten, die nun an diesen Partner fließen, das Land überhaupt jemals verlassen? Was als Geschäftsentscheidung begann, ist unbemerkt zu einer IT-Herausforderung geworden – möglicherweise auch zu einem rechtlichen Problem.
Genau an dieser Stelle machen viele Unternehmen einen grundlegenden Fehler: Sie gehen die Dinge in der falschen Reihenfolge an.
Ein Muster, kein Zufall
Die Anfrage des Partners erweist sich als erste von mehreren Herausforderungen. Das regionale Serviceteam benötigt kürzere Reaktionszeiten, als das globale System ermöglicht. Die Compliance-Abteilung beginnt zu hinterfragen, wo Kundendaten tatsächlich gespeichert werden. Jede Anfrage wird einzeln bearbeitet – ohne übergeordneten Plan und ohne klare Zuständigkeit.
Betrachtet man diese Fälle im Zusammenhang, wird deutlich, dass es sich nicht um voneinander unabhängige Probleme handelt. Sie spiegeln vielmehr ein gemeinsames Muster wider: Das Geschäft hat sich verändert, die Grundlagen der unternehmensweiten IT-Entscheidungen sind jedoch gleichgeblieben. Genau darin liegt einer der ersten strategischen Fehler, den viele Unternehmen machen.
Warum Datenlokalisierung bei der IT-Lokalisierung an erster Stelle stehen muss
Der Fehler beginnt meist mit einer naheliegenden Frage: Welche Anwendungen benötigen wir tatsächlich, und welche bestehenden Systeme können das Geschäft unterstützen, wenn es sich zunehmend regionalisiert? Diese Frage erscheint als logischer nächster Schritt. Sie führt zu konkreten Entscheidungen, die das IT-Team unmittelbar umsetzen kann. Sobald sie beantwortet ist, nimmt die Umsetzung schnell Fahrt auf.
Was häufig zu spät geklärt wird, ist die Frage, wo die verschiedenen Datenkategorien überhaupt gespeichert werden dürfen. Nach unserer Erfahrung wird dieser Aspekt oft als nachrangig behandelt – als etwas, das die Compliance-Abteilung später klären kann. Dabei sollte er von Anfang an bestimmen, wie Anwendungen konzipiert, miteinander verbunden und lokalisiert werden.
Die Folgen dieser falschen Reihenfolge zeigen sich erst spät. Ein System wird ausgewählt und eingeführt. Erst danach stellt sich heraus, dass bestimmte Daten das Land gar nicht verlassen durften. Die Folge sind kostspielige Anpassungen oder nachträglich entwickelte Umgehungslösungen, die niemand eingeplant hatte. Aus einer vermeintlich unkomplizierten Entscheidung für eine Anwendung wird ein Problem bei der Einhaltung regulatorischer Vorgaben. Die nachträgliche Korrektur ist deutlich teurer, als von Anfang an in der richtigen Reihenfolge vorzugehen.
Nicht für alle Daten gelten dieselben Regeln. Zu verstehen, welche Unterschiede bestehen, ist der Ausgangspunkt für die nächsten Entscheidungen.
Die Systeme folgen den Daten, nicht umgekehrt
Regionalisierung ist im Kern eine Geschäftsentscheidung mit weitreichenden IT-Konsequenzen. Deshalb muss die IT-Architektur von den Anforderungen an die Datenlokalisierung ausgehend gestaltet werden.
Grenzüberschreitende IT-Compliance: ein dynamisches regulatorisches Umfeld
Dieses Risiko ist keineswegs hypothetisch. Unternehmen, die sowohl in Europa als auch in China tätig sind, müssen zwei regulatorische Umfelder berücksichtigen, die sich unabhängig voneinander weiterentwickeln. Was in einer Rechtsordnung zulässig ist, kann in der anderen eingeschränkt oder untersagt sein. KI-Anwendungen verschärfen diese Herausforderung zusätzlich, da sie in der Regel auf mehr Daten aus mehr Quellen zugreifen als die Systeme, die sie ersetzen.
Unser Ansatz: Zunächst wird ermittelt, wo die jeweiligen Daten gespeichert werden müssen und dürfen. Anschließend werden die Anwendungslandschaft und die IT-Infrastruktur auf dieser Grundlage gestaltet. Zusammen bilden diese Entscheidungen das IT-Zielbild.
Die drei Lokalisierungsmodelle im Überblick
Im Folgenden konzentrieren wir uns auf die ersten beiden Schritte. Der dritte Schritt – das Zielbetriebsmodell und die Sicherheit – ist ein eigenes Thema, das eine separate Betrachtung verdient.
Die meisten Unternehmen würden den ersten Schritt als Datenlokalisierung bezeichnen. Bei Detecon verwenden wir einen umfassenderen Begriff, denn es geht nicht nur darum, wo Daten gespeichert werden. Entscheidend ist vielmehr, wo Daten und geschäftliche Fähigkeiten angesiedelt sein müssen und wie diese Entscheidung alles Weitere beeinflusst.
Wo gehören die Daten tatsächlich hin?
Bei Detecon bezeichnen wir diesen Klassifizierungsschritt als Geopatriation.
Geopatriation geht über die engere Definition hinaus, die in der Branche teilweise verwendet wird. Dort beschreibt der Begriff vor allem die Verlagerung von Workloads weg von globalen Cloud-Anbietern hin zu lokalen Rechenzentren oder privaten Clouds vor Ort. Bei Detecon verstehen wir darunter einen umfassenderen Ansatz: Es geht darum, festzulegen, wo Daten und geschäftliche Fähigkeiten angesiedelt sein müssen – unabhängig davon, ob ein Unternehmen ein bestehendes System migriert oder ein neues von Grund auf entwickelt.
Dieser Ansatz bildet die Grundlage dessen, was wir als Enterprise-Architektur für die IT-Lokalisierung verstehen: keine einzelne Infrastrukturentscheidung, sondern eine Abfolge von Entscheidungen, die bei den Daten beginnt.
Anstatt mit der Infrastruktur zu beginnen, müssen Unternehmen zunächst verstehen, welche Anforderungen ihre Daten tatsächlich stellen. Denn davon hängen die spätere Anwendungslandschaft und letztlich auch die Frage ab, wo die einzelnen Systeme betrieben werden.
Für jedes System stellen sich dabei dieselben vier Fragen. Die Antworten bestimmen, wie es in Bezug auf diese drei Aspekte einzuordnen ist. Wir nennen sie CRED:
Connectivity (Konnektivität): Benötigt das System einen kontinuierlichen Zugriff mit geringer Latenz? Und was passiert, wenn diese Verbindung unterbrochen wird?
Regulatory Risk (Regulatorisches Risiko): Sind die Daten heute rechtlich besonders sensibel, und wie wahrscheinlich ist es, dass sich dies künftig ändert?
Ecosystem Integration (Integration ins Ökosystem): Wie schnell verändert sich das lokale Umfeld heute und in Zukunft?
Data Protection (Datenschutz und Datensicherheit): Wie viel geistiges Eigentum wäre bei einem Sicherheitsvorfall gefährdet, und wie könnte sich dieses Risiko künftig entwickeln?
Anhand dieser vier Fragen lässt sich ein System in der Regel einem von drei Modellen zuordnen: vollständig lokal, lokal mit Anbindung an globale Systeme oder weiterhin global betrieben. Die folgenden Beispiele veranschaulichen diese Einordnung. Sie bildet die Grundlage für die anschließenden Entscheidungen zur Anwendungslandschaft und zum Betrieb der Systeme.
Vier Fragen, eine Entscheidung
Diese vier Kriterien gelten nicht nur für einzelne Systeme. Sie lassen sich auf die gesamte Wertschöpfungskette anwenden, wobei je nach Unternehmensfunktion unterschiedliche Kriterien stärker ins Gewicht fallen.
Was bestimmt den Lokalisierungsbedarf?
Das CRM-System des Herstellers eignet sich gut, um diese Zusammenhänge genauer zu betrachten.
Kundendaten unterliegen einem mehrstufigen Regelwerk des chinesischen Rechts. Dazu gehören das Gesetz zum Schutz personenbezogener Informationen (Personal Information Protection Law, PIPL), das Cybersicherheitsgesetz (Cybersecurity Law) und das Datensicherheitsgesetz (Data Security Law). Je nach Sensibilität und Umfang können Daten außerdem als „wichtige Daten“ eingestuft werden. Diese Kategorie kann strengere Anforderungen auslösen, selbst wenn es sich nicht um personenbezogene Informationen handelt. In der Praxis bedeutet das: Für die Übermittlung großer oder besonders sensibler Datenbestände ins Ausland ist in der Regel eine formelle behördliche Prüfung erforderlich. Für kleinere oder weniger risikobehaftete Datenübermittlungen stehen weniger aufwendige Verfahren zur Verfügung.
Chinesische Kundendaten außerhalb Chinas zu speichern, ist daher selten eine einfache Ja-oder-Nein-Frage. Entscheidend ist, um welche Daten es sich genau handelt und in welchem Umfang sie vorliegen. Auch die Integration in das lokale Ökosystem spricht für eine entsprechende Lösung: Chinesische Kunden nutzen überwiegend Plattformen wie WeChat und Alipay. Deren Schnittstellen entwickeln sich schnell – häufig schneller, als ein für einen anderen Markt konzipiertes System Schritt halten kann.
Genau diese Dynamik macht die Integration in das lokale Ökosystem für ein außerhalb Chinas entwickeltes System besonders anspruchsvoll. In der Praxis spricht diese Kombination häufig dafür, das CRM in China vollständig eigenständig aufzusetzen: nicht nur als lokale Kopie des globalen Systems, sondern als separate Instanz mit eigenem lokalem Betrieb.
Das MES (Manufacturing Execution System), das die Abläufe in der Produktion steuert, wirft andere Fragen auf – und zwar gleich in Bezug auf zwei Kriterien. Es verarbeitet Prozessparameter und Konfigurationen, die für Wettbewerber von großem Interesse wären. Diese Daten können so sensibel sein, dass bestimmte Kategorien nach dem chinesischen Datensicherheitsgesetz strengeren Anforderungen an die lokale Verarbeitung unterliegen.
Liegen solche Daten in einer Datenbank, auf die mehrere Systeme und Teams zugreifen, hängt ihr Schutz davon ab, wer auf welche Informationen zugreifen kann. Rollenbasierte Zugriffsrechte allein bieten dabei keine ausreichende Garantie. Über Ländergrenzen hinweg lassen sie sich nur schwer konsistent umsetzen. Zudem kann eine Sicherheitsverletzung in einer solchen gemeinsam genutzten Datenbank deutlich mehr sensible Informationen offenlegen als in einem System, das für einen klar abgegrenzten Zweck konzipiert wurde.
Ein zweiter Aspekt ist die Konnektivität. Hier stoßen viele Unternehmen in der Praxis erstmals auf die Herausforderungen grenzüberschreitender Datenverbindungen in China. Systeme wie das MES benötigen einen kontinuierlichen Zugriff mit geringer Latenz. Müssen Daten die Great Firewall passieren, um einen Server außerhalb Chinas zu erreichen, entstehen genau die Verzögerungen, die eine Echtzeitüberwachung der Produktion nicht tolerieren kann.
Hinzu kommt, dass die Verbindung nicht dauerhaft gewährleistet ist. Ein einziges Unterseekabel, das beispielsweise durch einen Schiffsanker oder eine Naturkatastrophe beschädigt wird, kann die physische Verbindung zwischen zwei Kontinenten für mehrere Tage unterbrechen, bis die Reparatur abgeschlossen ist. Ein System, das vollständig auf den grenzüberschreitenden Zugriff nach China angewiesen ist, trägt dieses Risiko von vornherein in seiner Architektur.
Anders als das CRM muss das MES jedoch nicht vollständig unabhängig betrieben werden. In der Regel reicht eine lokale Instanz aus, die Daten nur dann an das globale ERP-System übermittelt, wenn dafür kein Echtzeitaustausch erforderlich ist.
Finanzkonsolidierungsdaten liegen am anderen Ende dieses Spektrums. Aggregierte Finanzkennzahlen lösen selten dieselben regulatorischen Bedenken oder Schutzanforderungen für geistiges Eigentum aus wie Kunden- oder Produktionsdaten. Auch das Integrationsumfeld verändert sich hier kaum. Deshalb bleibt der Finanzbereich in den meisten Fällen weitgehend Teil des globalen Systems.
Eine pauschale Antwort gibt es allerdings auch hier nicht. Unternehmen unterschätzen häufig, wie viele unterschiedliche Aufsichtsbehörden für dieselben Daten zuständig sein können. Steuerbezogene Daten, die grenzüberschreitend übermittelt werden, müssen beispielsweise sowohl die Anforderungen des Datensicherheitsgesetzes und des Cybersicherheitsgesetzes als auch steuerrechtliche Meldepflichten erfüllen. Je nach Branche können weitere Aufsichtsbehörden hinzukommen. Deshalb sollte jeder Fall einzeln geprüft werden, statt von einer pauschalen Regelung auszugehen.
Diese Klassifizierung bietet einen Planungshorizont von etwa fünf Jahren – keine starre Festlegung, die nach Ablauf dieser Frist automatisch ihre Gültigkeit verliert. Sie bleibt so lange relevant, wie die zugrunde liegenden Rahmenbedingungen bestehen. Eine Überprüfung ist erst dann erforderlich, wenn sich tatsächlich etwas Wesentliches verändert, etwa durch ein neues Gesetz, den Ausfall einer Verbindung oder eine grundlegende Veränderung des Geschäfts.
Systeme folgen den Daten, nicht umgekehrt
Für das CRM ist die Entscheidung durch die Klassifizierung bereits weitgehend vorgegeben. Da bestimmte Kundendaten – abhängig von ihrer Nutzung – in China verbleiben müssen und das System in einem anderen digitalen Ökosystem funktionieren soll, kam eine gemeinsam genutzte globale Instanz von Anfang an kaum infrage.
Für große Unternehmen bedeutet das in der Regel, ein separates, weitgehend eigenständiges CRM für das China-Geschäft zu betreiben. Die regionale Organisation übernimmt den Betrieb, während der Datenaustausch mit Europa auf das Notwendige begrenzt bleibt. Kleinere Unternehmen können einen solchen parallelen Betrieb häufig nicht rechtfertigen. Sie greifen stattdessen auf einen lokalen Partner oder eine schlankere, speziell auf China zugeschnittene Lösung zurück, die die wesentlichen Anforderungen abdeckt, ohne den vollständigen Betriebsaufwand eines zweiten Systems zu verursachen.
Beim MES ergibt sich ein anderes Bild. Auch dessen Daten müssen lokal bleiben, doch das System muss nicht von Grund auf neu entwickelt werden. Eine lokale Instanz in China wird über eine kleine, klar definierte Anzahl von Schnittstellen mit dem globalen ERP verbunden. So lassen sich relevante Kennzahlen in die konzernweite Berichterstattung übernehmen, ohne die zugrunde liegenden Produktionsdetails offenzulegen.
Für den Finanzbereich ist kein vollständig eigenständiges lokales System erforderlich. In den meisten Fällen kann er weitgehend wie bisher auf den globalen Systemen aufbauen und das China-Geschäft darin abbilden. Ergänzende lokale Anwendungen, beispielsweise für steuerliche oder gesetzliche Meldepflichten, sind jedoch auch hier üblich.
CRM und MES benötigen möglicherweise beide eine lokale Präsenz in China. Daraus folgt aber nicht, dass sie dieselbe Architektur benötigen. Dieser Unterschied ist kein Zufall, sondern Ausdruck eines übergreifenden Prinzips für Entscheidungen über Informationssysteme: Wo Geschwindigkeit und lokale Anpassungsfähigkeit besonders wichtig sind, sollte ein System möglichst unabhängig arbeiten können. Wo Integration und häufig auch Kosten für einen einheitlichen Standard sprechen, sollte es eng an die bestehende Systemlandschaft angebunden bleiben.
Das CRM folgt eher dem ersten Prinzip. Entscheidend ist, wie schnell es sich an einen dynamischen lokalen Markt anpassen kann. Ein spezialisiertes lokales System ist dazu häufig besser in der Lage als eine globale Softwareplattform, die gleichzeitig zahlreiche Märkte bedienen muss.
Beim MES steht das zweite Prinzip im Vordergrund. Hier kommt es darauf an, dass Produktionsdaten zuverlässig in die bestehenden Berichts- und Planungsprozesse des Konzerns einfließen. Das spricht dafür, möglichst nah am bestehenden Standard zu bleiben, anstatt eine vollständig eigenständige Lösung aufzubauen.
Aus der Klassifizierung allein waren diese Entscheidungen noch nicht ersichtlich. Klarheit entstand erst, als das Unternehmen für jedes System einzeln prüfte, wie viel Unabhängigkeit tatsächlich erforderlich ist und auf welche Verbindungen es keinesfalls verzichten kann.
Das Ergebnis ist eine Architektur, die sich an den geschäftlichen Anforderungen und den Daten orientiert – nicht an bevorzugten Infrastrukturmodellen.
Erst jetzt: Wo werden die Systeme betrieben?
Sobald die Anwendungslandschaft definiert ist, folgt die Entscheidung über die Betriebsumgebung. Damit verbunden ist auch die Frage, wer für den täglichen Betrieb der jeweiligen Systeme verantwortlich ist.
Das CRM eignet sich aufgrund seiner eigenständigen Architektur und seiner Anforderungen an Geschwindigkeit und lokale Integration für den Betrieb auf einer chinesischen Public-Cloud-Plattform. Sie bietet die erforderliche Flexibilität und ermöglicht die Anbindung an das lokale Ökosystem, ohne dass das Unternehmen eine eigene Infrastruktur betreiben muss. Auch die Betriebsverantwortung kann sich verlagern: Statt vollständig bei der zentralen IT zu liegen, kann sie stärker von der regionalen Organisation übernommen werden.
Das MES gehört dagegen in eine andere Kategorie. Aufgrund der sensiblen Produktionsdaten und des Bedarfs an kontinuierlichem Zugriff mit geringer Latenz wird es lokal betrieben – entweder On-Premises oder in einer Private-Cloud-Umgebung in unmittelbarer Nähe zur Produktion. Im Vordergrund stehen Kontrolle und Zuverlässigkeit, nicht die Flexibilität, die eine Public Cloud bieten würde.
Für den Finanzbereich ist kein separates lokales System erforderlich. Er kann weiterhin die bestehenden globalen Systeme nutzen.
Jede dieser Betriebsentscheidungen ergibt sich unmittelbar aus den beiden vorherigen Schritten. Wenn die Infrastruktur erst am Ende und nicht am Anfang betrachtet wird, ist sie die logische Konsequenz der zuvor getroffenen Entscheidungen – und keine isolierte Grundsatzdiskussion.
Mit diesen drei Entscheidungen ist das IT-Zielbild vollständig: Die Anforderungen an die Daten sind geklärt, die Anwendungslandschaft ist definiert und die Betriebsumgebungen sind festgelegt.
Über die Infrastruktur hinaus
Die Architektur steht, doch damit ist die Arbeit nicht abgeschlossen. Sicherheitsrichtlinien, die zuvor für ein einheitliches System galten, müssen nun auch über getrennte Umgebungen hinweg konsistent bleiben. Auch Kostenverteilung und Verantwortlichkeiten gewinnen an Bedeutung, wenn sich eine regionale Geschäftseinheit und eine zentrale IT-Funktion die Aufgaben teilen, die zuvor vollständig bei der zentralen IT lagen.
Diese Fragen gehen über die Architektur selbst hinaus. Sie führen zum nächsten Thema: der Frage, wie das Unternehmen die geschaffene Systemlandschaft tatsächlich betreibt.
Wo sollten Unternehmen anfangen?
Die meisten Unternehmen scheitern bei der IT-Lokalisierung nicht daran, dass sie den falschen Cloud-Anbieter auswählen. Sie scheitern, weil sie zuerst über die Infrastruktur entscheiden, bevor sie verstanden haben, welche Anforderungen das lokale Geschäft stellt, wo die zugehörigen Daten angesiedelt sein müssen und welche Systeme diesen Anforderungen folgen müssen.
Die richtige Reihenfolge einzuhalten, erfordert keinen perfekten Plan vom ersten Tag an. Entscheidend ist, die richtigen Fragen in der richtigen Reihenfolge zu stellen und Entscheidungen dann zu überprüfen, wenn sich das Geschäft oder das regulatorische Umfeld tatsächlich verändert – und nicht einfach, weil Zeit vergangen ist.
Genau dieser Abfolge folgt Detecon bei der Beratung von Unternehmen, die ihr Geschäft zwischen Europa und China regionalisieren: von der ursprünglichen Geschäftsentscheidung über die Anforderungen an den Speicherort der Daten und die Gestaltung der Anwendungslandschaft bis hin zur Wahl der Betriebsumgebung.
Denn eine erfolgreiche Regionalisierung bedeutet nicht, die richtige Cloud auszuwählen. Sie bedeutet, zuerst die richtigen Fragen zu stellen.
