Від теми журналу до практики проєкту
Відповідні сторінки послуг і технічні сторінки до публікації
Wunderbares Wetter, die Sonne scheint – und Microsoft 365 macht Pause. In vielen Büros geht plötzlich weniger als geplant: Outlook hakt, Nachrichten kommen verspätet an, Teams ist nicht erreichbar und aus „Wir stimmen das kurz ab“ wird ein erstaunlich analoger Vormittag.
Anderswo läuft die Arbeit einfach weiter. Die Anwendung startet lokal, die Daten sind erreichbar, der nächste Vorgang kann bearbeitet werden. Nur der Kaffee wird kalt, weil niemand hektisch im Minutentakt auf eine Statusseite schaut.
Das ist eine gute Pointe. Vor allem aber ist es eine ernste unternehmerische Frage: Wie viel Handlungsfähigkeit geben wir ab, wenn Identität, Kommunikation, Dateien, Zusammenarbeit und zentrale Geschäftsprozesse am selben externen Anbieter hängen?
Die großflächige Microsoft-365-Störung vom 12. und 13. November 2026 hat unter anderem Outlook, Exchange Online, Teams und weitere verbundene Dienste beeinträchtigt. Unternehmen und öffentliche Stellen in mehreren Regionen meldeten Einschränkungen. Microsoft arbeitete an der Wiederherstellung; Hinweise auf einen Cyberangriff gab es nach damaligem Stand nicht.[1]
Der Vorfall ist kein Beweis dafür, dass Cloud-Dienste grundsätzlich schlecht sind. Er ist aber ein ziemlich unübersehbarer Hinweis darauf, dass Bequemlichkeit noch keine Resilienz ist.
Nicht die Cloud ist das Problem, sondern der fehlende Plan B
Cloud-Dienste haben gute Gründe, erfolgreich zu sein. Sie erleichtern Zusammenarbeit, Updates, mobilen Zugriff und den schnellen Aufbau neuer Funktionen. Ein professionell betriebener Cloud-Dienst kann für viele Unternehmen sicherer und zuverlässiger sein als ein lieblos gepflegter Server im Abstellraum.
Die falsche Schlussfolgerung aus einem Ausfall wäre deshalb: „Alles zurück ins eigene Rechenzentrum.“ Die richtige Frage lautet: Welche Tätigkeiten müssen auch dann möglich bleiben, wenn ein externer Dienst für Stunden oder länger nicht verfügbar ist?
Kritisch wird es, wenn aus einem hilfreichen Dienst eine einzige, alles verbindende Voraussetzung wird:
- Die Anmeldung hängt am Cloud-Konto.
- Die E-Mail liegt beim selben Anbieter.
- Termine, Dateien und Chats liegen dort ebenfalls.
- Freigaben und Automatisierungen verwenden dieselbe Identität.
- Selbst der Zugriff auf Ausweichdokumente setzt wieder genau diesen Dienst voraus.
Dann entsteht kein einzelner Ausfall. Es entsteht eine Kettenreaktion.
Lokal arbeiten ist kein nostalgischer Rückschritt
„Lokal“ klingt für manche nach Diskette, beigem Rechnergehäuse und einem Drucker, der nur nach gutem Zureden arbeitet. Gemeint ist etwas anderes: Eine Anwendung und ihre wesentlichen Funktionen bleiben auf dem eigenen Arbeitsplatz oder in einer kontrollierten eigenen Infrastruktur verfügbar. Ein externer Dienst kann sie ergänzen, aber er ist nicht für jeden Handgriff die Eintrittskarte.
Local-First-Software kann beispielsweise ermöglichen, Dokumente zu öffnen und zu bearbeiten, Daten zu erfassen, Auswertungen zu erstellen oder bestehende Vorgänge weiterzuführen, obwohl eine Internetverbindung oder ein externer Plattformdienst gestört ist. Synchronisation und Versand können später nachgeholt werden, sobald die Verbindung wieder steht.
Das ist keine Absage an Vernetzung. Es ist eine Rückfallposition.
Auch bei unseren Lösungen ist genau diese Unterscheidung wichtig. Ein lokal ausgeführtes Werkzeug wie netPDF kann seine Kernaufgaben auf dem Rechner erledigen, ohne dass erst ein fremder Cloud-Dienst antworten muss. Andere Systeme können kontrolliert in der eigenen Infrastruktur betrieben werden. Natürlich kann keine lokale Anwendung einen ausgefallenen fremden Mailserver herbeizaubern. Sie kann aber verhindern, dass zusammen mit dem Mailserver auch jede andere produktive Tätigkeit stehen bleibt.
Digitale Souveränität bedeutet nicht: keine Cloud. Sie bedeutet: Kein einzelner externer Ausfall darf allein darüber entscheiden, ob das Unternehmen noch handeln kann.
Europas digitale Unabhängigkeit beginnt im Einkaufsprozess
Digitale Unabhängigkeit ist kein abstraktes Brüsseler Schlagwort und auch keine Frage der Flagge auf dem Rechenzentrum. Sie zeigt sich in sehr konkreten Entscheidungen:
- Können Daten vollständig und in dokumentierten Formaten exportiert werden?
- Gibt es offene Schnittstellen statt ausschließlich proprietärer Verknüpfungen?
- Ist ein Anbieterwechsel praktisch möglich oder nur theoretisch im Vertrag erwähnt?
- Existieren unabhängige Sicherungen außerhalb des produktiven Dienstes?
- Bleiben kritische Arbeitsabläufe in einem definierten Notbetrieb verfügbar?
- Kann ein europäischer oder selbst betriebener Dienst eine sinnvolle Alternative sein?
Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt für Cloud-Dienste ausdrücklich vorbereitete Exit-Strategien. Bei kritischen Diensten muss ein Wechsel in eine andere Cloud oder eine eigene Betriebsform möglich sein; auch unzuverlässige Dienste und längere Ausfälle gehören in diese Planung.[2]
Die Europäische Kommission bewertet digitale Souveränität inzwischen ebenfalls anhand konkreter Kriterien – darunter technologische Autonomie, Resilienz, Lieferketten, Recht, Datenkontrolle und die praktische Fähigkeit, Systeme zu beherrschen und weiterzuentwickeln.[3]
Das ist der entscheidende Punkt: Souveränität entsteht nicht durch eine Absichtserklärung. Sie entsteht durch Architektur, Verträge, Datenformate und geübte Betriebsabläufe.
Der Fehler der Autoindustrie – diesmal mit Daten statt Lieferketten?
Die europäische Automobilindustrie liefert eine unbequeme Parallele. Über Jahre war China zugleich wichtiger Absatzmarkt, Produktionsstandort und zentraler Teil neuer Lieferketten. Diese Verbindung brachte Wachstum und Effizienz. Gleichzeitig entstanden Abhängigkeiten bei Batterien, Rohstoffen, Komponenten und Marktzugang. Inzwischen sind chinesische Hersteller technologisch und preislich erheblich stärker geworden, während China weniger auf europäische Industrieimporte angewiesen ist. Europäische Hersteller können diese Entwicklung nicht kurzfristig zurückdrehen.[4]
Der Fehler bestand nicht darin, in China Geschäfte zu machen. Der Fehler war, wirtschaftlichen Erfolg mit dauerhafter strategischer Sicherheit zu verwechseln und Alternativen zu spät aufzubauen.
In der Informationstechnik droht Europa eine ähnliche Entwicklung – nur mit Daten, Identitäten und Software statt mit Batteriezellen und Produktionslinien. Solange ein großes Plattformpaket bequem, günstig und zuverlässig erscheint, werden immer mehr Aufgaben darin gebündelt. Parallel verschwinden alternative Produkte, eigenes Betriebswissen und die praktische Fähigkeit zum Wechsel. Wenn die Abhängigkeit schließlich sichtbar wird, reicht es nicht mehr, einen anderen Vertrag zu unterschreiben. Daten müssen migriert, Prozesse neu aufgebaut, Beschäftigte geschult und zahlreiche miteinander verzahnte Systeme ersetzt werden.
Digitale Abhängigkeit kann sogar schneller wachsen als eine industrielle Lieferkette. Ein Fahrzeugwerk lässt sich nicht unbemerkt über Nacht verlagern. Bei Software dagegen genügt oft eine weitere integrierte Funktion, ein neues Lizenzpaket oder eine zentrale Anmeldung – und schon hängt der nächste Geschäftsprozess am selben Ökosystem.
Die Lehre aus der Automobilindustrie darf deshalb nicht lauten, keine internationalen Partnerschaften mehr einzugehen. Sie lautet: Kernkompetenzen, Alternativen und die Fähigkeit zum Wechsel müssen erhalten bleiben, bevor eine Abhängigkeit wirtschaftlich oder technisch kaum noch auflösbar ist. Wer erst diversifiziert, wenn der bisherige Partner zum Risiko oder zum überlegenen Wettbewerber geworden ist, beginnt zu spät.
Sieben Fragen für den nächsten ruhigen Vormittag
Ein Ausfalltag ist ein guter Anlass, ohne Panik und ohne Schadenfreude die eigene Abhängigkeit zu prüfen. Sieben Fragen reichen für einen ehrlichen Anfang:
-
Welche fünf Arbeitsabläufe müssen auch vier Stunden ohne den wichtigsten Cloud-Anbieter funktionieren?
Nicht jede Komfortfunktion ist kritisch. Angebote schreiben, Rechnungen bearbeiten, Kundeninformationen finden oder eine Produktion steuern können es sehr wohl sein. -
Können sich Beschäftigte im Notfall noch anmelden?
Wenn Identität, Mehrfaktor-Anmeldung, Geräteverwaltung und alle Anwendungen an derselben Plattform hängen, kann bereits die Anmeldung zum Flaschenhals werden. -
Wo liegt die letzte unabhängige, tatsächlich lesbare Sicherung?
Eine Kopie im selben Dienst, unter derselben Identität und in derselben administrativen Abhängigkeit ist nur begrenzt unabhängig. -
Wurde ein vollständiger Datenexport schon einmal getestet?
Der Button „Exportieren“ ist noch keine Exit-Strategie. Entscheidend ist, ob Daten, Anhänge, Berechtigungen und Beziehungen anschließend in einem anderen System nutzbar sind. -
Gibt es einen Kommunikationsweg außerhalb der betroffenen Plattform?
Ein dokumentierter Telefonbaum, ein unabhängiger Statuskanal oder eine getrennte Notfalladresse wirken altmodisch – bis sie gebraucht werden. -
Welche Kernwerkzeuge arbeiten lokal oder im eigenen Netz weiter?
Dokumentbearbeitung, PDF-Prozesse, Warenwirtschaft, Zeiterfassung und weitere Fachaufgaben sollten nicht automatisch zusammen mit einer Kollaborationsplattform ausfallen. -
Wann wurde dieser Notbetrieb zuletzt geübt?
Ein Plan, den niemand ausprobiert hat, ist im Ernstfall vor allem ein Textdokument. Idealerweise eines, das gerade in der nicht erreichbaren Cloud liegt.
Abhängigkeit ist bequem – bis sie sichtbar wird
Solange alles funktioniert, fühlt sich eine eng integrierte Plattform effizient an. Ein Konto, eine Oberfläche, ein Vertrag, ein Anbieter. Die Kosten der Abhängigkeit erscheinen erst später: bei einem Ausfall, einer Preisänderung, einer Schnittstellenänderung, einer strategischen Neuausrichtung oder beim Versuch, Daten und Prozesse wieder herauszulösen.
Deshalb geht es nicht darum, Microsoft oder einen anderen großen Anbieter zum Feindbild zu erklären. Jeder technische Dienst kann ausfallen – der kleine lokale Server ebenso wie die globale Plattform. Professionelles Risikomanagement fragt nicht, ob ein Fehler passieren darf, sondern was das Unternehmen dann noch tun kann.
Wer alle wichtigen Schlüssel an einen Anbieter übergibt, sollte wenigstens einen belastbaren Ersatzschlüssel besitzen.
Heute ist ein guter Tag für einen kleinen Souveränitätscheck
Vielleicht ist die aktuelle Störung in ein paar Stunden vergessen. Die strukturelle Frage bleibt: Wollen europäische Unternehmen ihre digitale Zukunft so gestalten, dass ein einzelner Plattformausfall ganze Arbeitstage bestimmt?
Die Alternative ist kein radikaler Rückzug aus der Cloud. Sie ist ein bewusster Mix aus lokalen Fähigkeiten, kontrollierbarer Infrastruktur, offenen Standards, unabhängigen Sicherungen und austauschbaren Diensten. Cloud dort, wo sie echten Mehrwert bietet. Lokale Handlungsfähigkeit dort, wo Stillstand teuer wird.
Und wenn beim nächsten großen Ausfall die wichtigsten Prozesse weiterlaufen, darf der Kaffee ruhig wieder kalt werden – diesmal aus den richtigen Gründen.
Lesenswert? Dann teilen Sie diesen Beitrag. Digitale Unabhängigkeit beginnt nicht mit einem Produktwechsel, sondern mit einer ehrlichen Debatte über Risiken, Alternativen und den eigenen Plan B.
Quellen und Einordnung
Stand der Recherche: 13. November 2026. Der Beitrag bewertet den öffentlich bekannten Zwischenstand der Störung und leitet daraus allgemeine Empfehlungen für Resilienz und digitale Souveränität ab. Er behauptet keine vollständige Ursachenanalyse.
- Associated Press: Microsoft outage hits companies and governments worldwide as it struggles to restore services, 13.11.2026; ergänzend: Microsoft Service Health Status.
- Bundesamt für Sicherheit in der Informationstechnik: Empfehlungen zur Vorbereitung einer Exit-Strategie bei Nutzung von Cloud-Dienstleistungen.
- Europäische Kommission: Sovereign Cloud Framework explained, 01.06.2026; außerdem: Open and interoperable digital ecosystems, 03.06.2026.
- Europäische Zentralbank: Which countries are most vulnerable to the industrial rise of China? Mapping Europe’s uneven exposure, Economic Bulletin 6/2026; Europäisches Parlament: The crisis facing the EU’s automotive industry, 2024.
Наступний крок
Якщо тема перетворюється на реальний проєкт, архітектуру, наявні системи та експлуатацію слід розглядати разом на ранньому етапі.
Ми підтримуємо не лише в окремих питаннях, а й тоді, коли з уривків вихідного коду, питань, пов’язаних із legacy, або ідей порталу має вирости надійний корпоративний проєкт.
- Поточний стан, цільова архітектура та технічні ризики оцінюються спільно.
- REST, доступ до даних, портали та Rollout не відсуваються на пізніший етап.
- Ви заздалегідь бачите, який шлях є економічно та операційно життєздатним.