KI Managed Service – das klingt nach Vereinfachung. Doch Tiefe ist mühsam. Sie kostet Zeit und verlangt Konzentration. Deshalb wird sie gern vermieden.
Doch in meiner Erfahrung führt genau diese Vermeidung zu dem, was alle vermeiden wollen: unnötige Kosten, unnötige Risiken, unnötige Nacharbeit.
Mein neues Buch „Das Helferlein-Paradox“ entstand aus einer einfachen Frage: Was passiert, wenn ich versuche, für einen KI Managed Service ein Service Level Agreement zu schreiben?
Die Antwort war unbequem. Aber sie hilft, Unnötiges zu vermeiden.
KI Managed Service: Was Sie erwartet
Wenn Sie Entscheidungen verantworten: Sie erfahren, warum die Compliance-Kosten für KI Managed Service in kritischen Anwendungen bei 500.000 bis 800.000 Euro im ersten Jahr liegen können – und warum diese Zahl keine Panikmache ist, sondern eine nüchterne Kalkulation.
Wenn Sie entwickeln oder konstruieren: Sie finden eine Sprache für das, was Sie vermutlich längst spüren. Den Unterschied zwischen einem Industrieroboter, der zuverlässig schweißt, und einem Sprachmodell, das plausibel klingt, aber nicht verlässlich ist. Und Sie finden Argumente für das nächste Gespräch mit jemandem, der meint, „mit KI läuft das doch von selbst“.
Wenn Sie lokale LLM-Infrastruktur aufbauen: Sie verstehen, warum das Researcher-Modell – KI als Werkzeug, nicht als Entscheider – der einzig gangbare Weg für verantwortungsvolle Anwendungen ist. Und was das für Ihre Architekturentscheidungen bedeutet.
Wenn Sie in Technologieunternehmen investieren: Sie lernen, welche Fragen Sie stellen sollten, bevor Sie in ein KI-Startup investieren. Was kann vertraglich zugesichert werden? Was nicht? Wo endet das Versprechen, wo beginnt die Hoffnung?
Wie dieses Buch über KI Managed Service entstand
Ich habe dieses Buch nicht gegen KI geschrieben. Ich habe es mit KI geschrieben. Und ich habe KI gebaut.
Meine Forschung war praktisch: der Entwurf einer LLM-Architektur für AWS. Persönliche Erfahrungen mit OpenAI und Anthropic über Monate hinweg. Versuche mit LMStudio und Ollama in meinem eigenen Lab – lokal, internetunabhängig, unter meiner Kontrolle.
Ich habe Agentensysteme getestet und dabei erlebt, wie sich APIs laufend ändern. Was gestern funktionierte, funktioniert heute anders – oder gar nicht mehr. Ich habe Online-Plattformen wie marblism.com evaluiert, die versprechen, fertige Agentenlösungen bereitzustellen. Und ich habe Microsoft Copilot Studio untersucht, um zu verstehen, wie Enterprise-Anbieter das Thema KI Managed Service angehen.
Jeder dieser Versuche lieferte Erkenntnisse. Nicht immer die erhofften. Aber immer nützliche.
Auch die Hardware-Frage stellte sich konkret. Mein Sohn baut gerne Rechner selbst – er spielt mit den besten verfügbaren Grafikkarten. Wir überlegten, ob er einen Rechner für mein Lab zusammenbauen würde. Also rechnete ich den Bedarf nach: Welche GPU-Speicher brauche ich für lokale Modelle in brauchbarer Größe? Was kostet das? Die Zahlen waren ein weiteres Argument, dieses Buch zu schreiben. Wer über KI-Infrastruktur entscheidet, sollte wissen, was sie wirklich kostet.
Ich wollte wissen, wie sich diese Systeme verhalten, wenn niemand zusieht. Was sie können. Wo sie scheitern. Und ob das, was die Anbieter versprechen, dem entspricht, was ich erlebe.
Die Fähigkeit, Service Level Agreements kritisch zu lesen und zu formulieren, kam nicht aus dem Nichts. Sie entstand durch jahrzehntelange Arbeit an Verträgen bei Kunden – und durch meine eigenen Entwürfe für einen Konzern, der einen Managed Service für kritische Infrastruktur vertraglich absichern musste. Wer einmal versucht hat, Garantien für etwas zu formulieren, das sich nicht garantieren lässt, vergisst diese Erfahrung nicht.
Claude, das Sprachmodell von Anthropic, wurde dabei mein Recherchewerkzeug, Sparringspartner und kritischer Gegenleser. Über Monate hinweg. In hunderten von Gesprächen.
Dabei habe ich genau das praktiziert, was ich im Buch als „Researcher-Modell“ beschreibe: Die KI liefert Material, Perspektiven, Formulierungsvorschläge. Die Entscheidung, was davon stimmt, was brauchbar ist, was veröffentlicht wird – die liegt bei mir.
Das ist keine Einschränkung. Das ist die einzige Arbeitsweise, die in kritischen Kontexten funktioniert.
Zwei Sprachen, drei Kontinente
Die deutschsprachige Ausgabe ist seit Januar 2026 verfügbar – als Kindle, in Kürze als Taschenbuch, und über Tolino im deutschen Buchhandel.
Die englische Ausgabe „The Little Helper Paradox“ erscheint in zwei Wochen. Sie durchläuft gerade den sprachlichen Feinschliff – validiert von einer kanadischen Lektorin, nach demselben Prinzip: KI als Werkzeug, Mensch als Entscheider.
Was mich besonders freut: Das Buch wird aktuell von IT-Profis in Indien gelesen, mit denen ich seit zwanzig Jahren zusammenarbeite. Unsere gemeinsame Erfahrung – was in der Zusammenarbeit zwischen deutschen und indischen Teams funktioniert und was nicht – ist direkt ins Buch eingeflossen. Kapitel 13a zieht die Parallele: Wer gelernt hat, dass erfolgreiche Offshore-Zusammenarbeit explizite Strukturen braucht, wird auch mit LLMs besser arbeiten. Die Verantwortung für klare Aufträge liegt beim Auftraggeber – nicht beim Ausführenden.
Und ja, ich erwarte auch die Auseinandersetzung mit amerikanischen Interessenvertretern. Ein Buch, das fragt, was KI nicht leisten kann, wird nicht überall Applaus ernten. Das ist in Ordnung. Die Fragen bleiben trotzdem richtig.
Was Leser über KI Managed Service sagen
Die ersten Rückmeldungen überraschen mich – in ihrer Bandbreite.
Eine Bibliothekarin schrieb, das Buch habe ihr Aufschluss gegeben, was es im verantwortlichen Entwicklungsumfeld alles zu beachten gäbe. Sie arbeitet nicht in der IT. Aber sie versteht jetzt, welche Fragen gestellt werden müssen.
Ein ehemaliger Schüler von mir – jemand, der jahrelang Beschaffungsentscheidungen in einem hochregulierten Industrieumfeld verantwortete, wo Fehler keine Option sind – formulierte es so:
„Ein ziemlich nahe an Wahnsinn und Ehrlichkeit gezeichnetes Buch. Respekt an deine tiefsinnigen Antworten auf noch ungestellte Fragen.“
Antworten auf noch ungestellte Fragen – das trifft es vielleicht am besten. Dieses Buch versucht nicht, den aktuellen Hype zu bedienen. Es versucht, die Fragen zu formulieren, die in zwei Jahren auf jedem Schreibtisch liegen werden.
Warum KI Managed Service nicht funktioniert
Große Sprachmodelle können beeindruckende Ergebnisse liefern. Aber sie können eines nicht: garantieren, dass das Ergebnis korrekt ist.
Das ist kein Bug. Das ist Systemverhalten.
Und deshalb funktioniert das klassische KI Managed Service-Modell – „Sie zahlen, wir garantieren“ – für LLM-Anwendungen in kritischen Bereichen nicht. Nicht aus technischen Gründen allein. Sondern aus vertraglichen, aus haftungsrechtlichen, aus organisatorischen.
Wer das versteht, kann KI sinnvoll einsetzen. Wer es ignoriert, wird Lehrgeld zahlen. Eine systematische GAP-Analyse hilft, die Lücken zwischen Versprechen und Realität sichtbar zu machen.
Für wen ist dieses Buch?
Für alle, die mit KI arbeiten wollen, ohne die Verantwortung abzugeben.
Für Ingenieure, die wissen, dass Fehler Konsequenzen haben.
Für Entscheider, die verstehen wollen, bevor sie unterschreiben.
Für Investoren, die wissen möchten, was hinter dem Versprechen liegt.
Und für alle, die glauben, dass tiefes Nachdenken keine Zeitverschwendung ist – sondern die einzige Art, Unnötiges zu vermeiden.
Das Helferlein-Paradox: LLM zwischen Versprechen und Verantwortung
Verfügbar als Kindle: Bei Amazon kaufen
Taschenbuch und Tolino: in Kürze
The Little Helper Paradox (Englisch)
Erscheint Februar 2026
Fragen zum Buch oder zu KI Managed Service in Ihrem Unternehmen? Nehmen Sie Kontakt auf.
90% aller Transformationsprojekte verfehlen ihre ursprünglichen Ziele. Diese Statistik ist nicht neu, doch ihre Auswirkungen auf Managed Services werden häufig unterschätzt. In hochverfügbaren Umgebungen – etwa in KRITIS – können Verzögerungen existenzbedrohend sein; das zugrunde liegende Prinzip gilt jedoch für alle Arten von Managed Services, unabhängig von Branche oder Kritikalität.
Die Ursache liegt nicht in mangelnder technischer Kompetenz oder unzureichenden Budgets. Das Problem ist strukturell: Klassische Change-Management-Ansätze versuchen, bestehende Systeme und Organisationen zu verändern. Dieser Ansatz stößt auf organisatorische Widerstände, kulturelle Barrieren und technische Altlasten, die Projekte auf 10+ Jahre ausdehnen können. KRITIS dient in diesem Beitrag als Beispiel – die beschriebenen Vorgehensweisen lassen sich auf alle Managed Services übertragen.
Warum KRITIS-Transformationen besonders komplex sind
Betreiber kritischer Infrastrukturen stehen vor einzigartigen Herausforderungen:
Regulatorischer Druck intensiviert sich: Das IT-Sicherheitsgesetz 2.0 und die NIS-2-Richtlinie verschärfen Compliance-Anforderungen erheblich. Unternehmen müssen nicht nur nachweisen, dass ihre Systeme sicher sind, sondern auch, dass sie kontinuierlich überwacht und verbessert werden.
Zero-Downtime-Anforderung: Kritische Infrastrukturen können nicht einfach „abgeschaltet und neu aufgesetzt“ werden. Jede Änderung muss im laufenden Betrieb erfolgen, was die Komplexität exponentiell erhöht.
Fachkräftemangel verschärft Situation: Qualifizierte IT-Sicherheitsexperten sind rar. Interne Teams sind oft bereits an ihren Belastungsgrenzen und können zusätzliche Transformationsprojekte kaum stemmen.
Technische Altlasten bremsen aus: Viele KRITIS-Betreiber arbeiten mit gewachsenen IT-Landschaften, die über Jahrzehnte entstanden sind. Diese Systeme zu modernisieren gleicht einem chirurgischen Eingriff am offenen Herzen.
Der Greenfield Approach: Paralleler Aufbau statt Transformation
Der Greenfield-Ansatz kehrt die traditionelle Denkweise um: Anstatt bestehende Strukturen zu verändern, werden parallel neue, moderne Systeme aufgebaut. Die alte und neue Welt koexistieren zunächst, bis die neue Infrastruktur vollständig etabliert ist.
Kernprinzipien des Greenfield-Ansatzes:
Paralleler Aufbau: Neue Systeme entstehen unabhängig von bestehenden Strukturen
Modernste Technologie: Keine Kompromisse aufgrund legacy-bedingter Einschränkungen
Klare Zielvision: Definition des gewünschten Endzustands ohne Rücksicht auf historische Beschränkungen
Stufenweise Migration: Kontrollierter Übergang von alt zu neu
Zeitvorteil: Was bei klassischen Transformationen 10-15 Jahre dauert, kann durch parallelen Aufbau in 2-3 Jahren realisiert werden.
Managed Services: Die strukturelle Marktlücke
Der Markt zeigt eine auffällige Diskrepanz: Systemhäuser beherrschen Projekte, versagen aber oft beim dauerhaften Betrieb. Diese Lücke betrifft alle Betreiber geschäftskritischer Services – KRITIS ist nur ein prominentes Beispiel.
Projekt vs. Service – Die fundamentalen Unterschiede:
Aspekt
Projektgeschäft
Managed Service
Zielsetzung
Definierter Scope, Abnahme
Dauerhafte Verfügbarkeit
Erfolg
Projekterfolg = Abnahme
Kundenzufriedenheit über Jahre
Kultur
„Wir liefern ab“
„Wir übernehmen Verantwortung“
Geschäftsmodell
Einmaliger Auftrag
Wiederkehrende Umsätze
Risiko
Begrenzt auf Projektlaufzeit
Kontinuierliche Haftung
Das Problem: Viele Anbieter behaupten, Managed Services anbieten zu können, haben aber weder die organisatorischen Strukturen noch die kulturelle Ausrichtung dafür entwickelt.
Praxisfall: Wenn der Vertrag unterschrieben ist, aber niemand liefern kann
Im beschriebenen Fall wurde der vereinbarte Managed Service nach Vertragsunterzeichnung nicht geliefert. Stattdessen versuchte der Anbieter, mit zahlreichen Einzelmaßnahmen das bestehende Vorgehen fortzusetzen und den Dienst wie üblich zu betreuen.
Was geschah:
Operative Tätigkeiten wurden ad hoc verteilt, jedoch ohne klar definiertes Service-Modell
Verantwortlichkeiten und Eskalationswege blieben unklar
Kein nachhaltiges Betriebsmodell (keine expliziten SLAs/SLOs, keine 24/7-Strukturen, keine systematische Continual Service Improvement)
Kein organisatorischer Wechsel vom Projekt- in den Service-Modus
Ergebnis:
Das Ziel, einen klaren Managed Service zu etablieren, wurde verfehlt
Unklare Zuständigkeiten und fehlende Verbindlichkeit führten zu Reibungsverlusten
Der Dienst blieb im alten Betreuungsmuster; der Kunde musste temporär übernehmen
Fazit: Ohne klare Trennung von Projekt und Service entsteht Innovations-Theater statt echter Transformation. Ein Managed Service erfordert ein explizites Operating Model, definierte Rollen (z. B. Service Owner und On-Call), messbare Serviceziele sowie kontinuierliche Verbesserungsprozesse.
Einordnung zur Literatur: Die Beobachtung deckt sich mit den Lehren aus den einschlägigen Büchern zur Service-Transformation: Build und Run müssen organisatorisch getrennt, Verantwortlichkeiten eindeutig zugewiesen und SLAs/SLOs verbindlich verankert werden; erst dann entsteht ein belastbares, skalierbares Service-Modell.
Hinweis auf mein eben erschienenes Buch bei Amazon zum Thema:
Regulatorische Herausforderungen verstärken den Handlungsdruck
Das IT-Sicherheitsgesetz 2.0 und die NIS-2-Richtlinie erhöhen den Druck auf KRITIS-Betreiber erheblich:
Verschärfte Nachweispflichten:
Kontinuierliche Risikobewertung der IT-Systeme
Dokumentierte Incident-Response-Prozesse
Regelmäßige Penetrationstests und Schwachstellenanalysen
Meldepflichten bei Sicherheitsvorfällen innerhalb 24 Stunden
Problematik für interne Teams:
Diese Anforderungen überfordern viele interne IT-Abteilungen. Der Fachkräftemangel verschärft die Situation zusätzlich. Externe Unterstützung wird zur Notwendigkeit.
Warum klassische Transformation hier versagt:
Bei herkömmlichen Change-Projekten dauert es Jahre, bis neue Compliance-Prozesse vollständig implementiert sind. Diese Zeit haben KRITIS-Betreiber nicht mehr.
Projekt vs. Service: Die kulturellen Unterschiede verstehen
Die Unterscheidung zwischen Projekt- und Service-Mentalität ist fundamental und wird oft unterschätzt:
Projektkultur:
„Scope erfüllen und abschließen“
Optimierung für einmalige Leistungserbringung
Erfolg = termingerechte Abnahme
Team löst sich nach Projektende auf
Service-Kultur:
„Verantwortung übernehmen und kontinuierlich verbessern“
Optimierung für langfristige Kundenzufriedenheit
Erfolg = dauerhaft stabile Verfügbarkeit
Team entwickelt sich kontinuierlich weiter
Die Herausforderung: Ein Systemhaus kann nicht einfach per Knopfdruck von Projekt- auf Service-Modus umschalten. Dies erfordert fundamentale organisatorische und kulturelle Veränderungen.
Handlungsempfehlungen für KRITIS-Betreiber
1. Greenfield-Potentiale identifizieren:
Analysieren Sie, welche Ihrer IT-Services parallel neu aufgebaut werden können, anstatt bestehende Systeme zu transformieren.
2. Service-Fähigkeit bei Anbietern prüfen:
Stellen Sie nicht nur die Frage „Können Sie das Projekt?“, sondern „Können Sie dauerhafte Verantwortung übernehmen?“
Prüfkriterien für echte Service-Fähigkeit:
24/7-Organisationsstrukturen vorhanden?
Referenzen für mehrjährige Service-Verträge?
Kontinuierliche Verbesserungsprozesse etabliert?
Service-Level-Agreements mit finanzieller Haftung?
3. Regulatorische Compliance als Service-Anforderung definieren:
Machen Sie NIS-2- und IT-SiG-Compliance zu einem expliziten Bestandteil Ihrer Service-Ausschreibungen.
4. Parallele Strukturen nutzen:
Nutzen Sie den Greenfield-Ansatz, um moderne, compliance-konforme IT-Services aufzubauen, während die bestehende Infrastruktur weiterläuft.
Fazit: Geschwindigkeit durch Parallelität
Der traditionelle Ansatz, bestehende IT-Infrastrukturen schrittweise zu modernisieren, ist für Betreiber geschäftskritischer Managed Services nicht mehr zeitgemäß. Regulatorischer Druck, Fachkräftemangel und die Komplexität gewachsener Systeme machen klassische Transformationsprojekte zu einem Risiko – in KRITIS besonders sichtbar, aber keineswegs exklusiv.
Der Greenfield-Approach bietet eine bewährte Alternative: Durch parallelen Aufbau moderner, compliance-konformer Services können Organisationen ihre Ziele in Jahren statt Jahrzehnten erreichen.
Entscheidend ist dabei die Auswahl der richtigen Partner. Nicht jeder Anbieter, der Projekte beherrscht, kann auch echte Managed Services liefern. Die Unterschiede in Kultur, Organisation und Geschäftsmodell sind fundamental.
Die zentrale Frage für Betreiber lautet:
Können Sie es sich leisten, weitere 10 Jahre auf die Transformation zu warten – oder ist es Zeit für einen parallelen Neuanfang?
Sie stehen vor ähnlichen Herausforderungen in Ihrer kritischen Infrastruktur? Lassen Sie uns über konkrete Lösungsansätze sprechen: www.it-dialog.com
Eine Analyse der systematischen Versagensmuster externer IT-Expertise zeigt: Nicht selten dominiert Innovationstheater – glänzende Präsentationen ohne belastbare Umsetzung. Das Problem ist nicht der Einsatz externer Berater an sich, sondern wie sie ausgewählt, eingesetzt und kontrolliert werden. Wenn alle sagen „geht nicht“ und McKinsey aufgibt – dann braucht es einen anderen Ansatz.
Die ernüchternde Realität: Zahlen ohne Rhetorik
Die Standish Group erhebt seit 1994 Daten zu IT-Projekterfolgen mit ernüchternden Ergebnissen:
Nur 9% der IT-Projekte in Großunternehmen sind erfolgreich (pünktlich, im Budget, volle Funktionalität)
52,7% der Projekte überschreiten das Budget oder reduzieren den Umfang
31,1% werden komplett abgebrochen
Durchschnittliche Kostenüberschreitung: 189% des ursprünglichen Budgets
Diese Zahlen bedeuten: In neun von zehn IT-Projekten bei Großunternehmen stimmt am Ende entweder das Budget nicht, der Zeitplan nicht, der Funktionsumfang nicht – oder das Projekt wird komplett abgebrochen.
Die Pegasystems-Studie 2025 quantifiziert die jährlichen Verluste durch technische Schulden: 370 Millionen USD Gesamtverlust pro Unternehmen und Jahr.
Dokumentierte Katastrophen: Was wirklich schiefging
National Grid vs. Wipro: Über 1 Milliarde USD Schaden
National Grid USA wollte ihre Back-Office-Systeme auf SAP migrieren. Budget: 290 Millionen USD. Sie wechselten von Deloitte zu Wipro – Hauptgrund: Kostensenkung.
Wipros Behauptung: „Well-established SAP practice“ für Utilities. Die Realität: Wipro hatte faktisch keinerlei Erfahrung mit SAP-Implementierungen für US-regulierte Versorgungsunternehmen.
Die Folgen nach Go-Live:
Mitarbeiter wurden falsch bezahlt oder gar nicht
8 Millionen USD Überzahlungen nie zurückgeholt
15.000+ Lieferantenrechnungen nicht verarbeitet
Buchungsabschluss: von 4 Tagen auf 43 Tage
Stabilisierungskosten: 30 Millionen USD pro Monat
Gesamtschaden: Über 1 Milliarde USD
Weitere dokumentierte Millionenschäden
Unternehmen
Jahr
Schaden
Kernproblem
Revlon
2018
64 Mio. USD
Keine SAP-Erfahrung, falscher Systemwechsel
MillerCoors vs. HCL
2014-2017
100 Mio. USD
80 Defekte beim ersten Rollout
Lidl
2011-2018
500 Mio. EUR
SAP-Standard passte nicht zu Geschäftslogik
US Air Force ECSS
2005-2012
1+ Mrd. USD
Kein klares Ziel, kein Wille zur Umsetzung
Die vier Typen externer Expertise, die regelmäßig scheitern
Typ 1: Der Offshore-Volumenanbieter
Charakteristik: Behauptet Expertise, optimiert aber für Volumen und Marge. Setzt Junior-Personal ein. Versagensmechanismus: „Wir haben SAP-Erfahrung“ ist technisch korrekt, aber irreführend. SAP für einen Einzelhändler ist etwas anderes als SAP für ein reguliertes Versorgungsunternehmen.
Typ 2: Der Systemintegrator ohne Domain-Wissen
Charakteristik: Kennt die Technologie, nicht die Branche. Versagensmechanismus: Technische Korrektheit ist nicht gleich Geschäftstauglichkeit.
Typ 3: Die Big-4-Firma mit Interessenkonflikt
Charakteristik: Berät, implementiert und prüft – manchmal beim selben Kunden. Das strukturelle Problem: Wer vom Folgegeschäft abhängt, hat keinen Anreiz, Probleme zu benennen.
Typ 4: Der Berater als „Partner des Managements“
Charakteristik: Sagt, was der Kunde hören will. Keine unabhängige Prüfung. Versagensmechanismus: Berater, die Probleme benennen, gefährden den nächsten Auftrag.
Wann externe Expertise tatsächlich wirkt
Die Analyse zeigt fünf kritische Erfolgsbedingungen:
1. Nachweisbare Referenzen im identischen Kontext
Nicht „ähnlich“, sondern identisch. SAP für ein US-Versorgungsunternehmen erfordert andere Expertise als SAP für einen europäischen Einzelhändler.
2. Trennung von Implementierung und Prüfung
Wer implementiert, kann nicht gleichzeitig unabhängig prüfen. Investieren Sie in unabhängige Qualitätssicherung als Versicherungspolice.
3. Geschäftsmodell, das Problemfindung belohnt
Ein Berater, dessen Auftrag es ist, Probleme zu finden, hat einen anderen Anreiz als ein Berater, dessen Folgeauftrag von zufriedenen Stakeholdern abhängt.
4. Seniorität ohne Team-Overhead
Das Problem großer Beratungshäuser: Seniors machen die Akquise, Juniors die Arbeit.
Gaps entstehen jeden Tag. Jede Schnittstelle, die nicht passt. Jeder Mitarbeiter, der geht. Jede Anforderung, die erst bei der Implementierung sichtbar wird.
Der Unterschied: Wenn unmögliche IT-Projekte doch gelingen
Referenzbeispiele aus der Praxis:
120 SAP-Systeme bei CIBER stabilisiert mit nur 4-Personen-Kernteam – als alle anderen aufgaben
Migration des Telekom-Kernnetzes (160 Millionen Verbindungen) – obwohl die Telekom sagte „unmöglich“
M/OMS Output Management System – 1988 entwickelt, nach 39 Jahren noch in Betrieb
Der Schlüssel: Unabhängige Senior-Expertise mit nachweisbarer Domain-Kontinuität, deren Geschäftsmodell die Identifikation von Problemen belohnt statt bestraft.
Fragen vor der Beauftragung
Bevor Sie externe IT-Expertise beauftragen, sollten Sie folgende Fragen beantworten:
Referenzen: Hat der Anbieter nachweisbare Erfahrung in exakt diesem Kontext?
Personal: Wer arbeitet tatsächlich am Projekt? Die Seniors aus dem Pitch oder ein Junior-Team?
Interessenkonflikt: Hängt der Anbieter vom Folgegeschäft ab?
Kontrolle: Wer behält die Projekthoheit? Gibt es eine unabhängige Prüfinstanz?
Accountability: Was passiert bei Versagen? Wie ist die Haftung geregelt?
Schlussfolgerung
IT-Projekte scheitern nicht, weil externe Expertise grundsätzlich versagt. Sie scheitern, weil:
Kostensenkung wichtiger ist als Qualifikation
Behauptungen nicht verifiziert werden
Kontrolle abgegeben wird
Interessenkonflikte ignoriert werden
Verträge keine Accountability erzwingen
Die dokumentierten Schäden – von 64 Millionen USD bei Revlon bis über 1 Milliarde USD bei National Grid – sind keine Naturkatastrophen. Sie sind das vorhersagbare Ergebnis vorhersagbarer Entscheidungen.
Die Frage ist nicht: Externe Expertise ja oder nein? Die Frage ist: Welche externe Expertise, unter welchen Bedingungen, mit welcher Accountability?
Wenn niemand traut sich ran und alle sagen „geht nicht“ – dann braucht es einen IT Troubleshooter Stuttgart, der gescheiterte Projekte retten, die unmögliche IT Migration möglich machen, Ihre IT-Krise lösen und unmögliche IT-Projekte realisieren kann – auch wenn McKinsey aufgibt.
Über den Autor
Michael Schmid ist Principal Consultant und Inhaber der it-dialog e.K. (gegründet 2000). Als Physiker mit über 40 Jahren IT-Erfahrung positioniert er sich als unabhängiger Experte für kontinuierliche Gap-Analyse in kritischen IT-Projekten.
Sein Ansatz unterscheidet sich von klassischer Beratung: Keine Implementierung, keine Teams, kein Folgegeschäft-Interesse. Stattdessen: Identifikation dessen, was nicht funktionieren wird – bevor die Millionen verbrannt sind.
Nehmen Sie Kontakt auf, wenn Sie vor unmöglichen IT-Projekten stehen: Kontakt | LinkedIn
Diese Studie basiert auf öffentlichen Gerichtsakten, Branchenstudien und dokumentierten Projektkatastrophen. Vollständige Quellenangaben auf Anfrage verfügbar.
Sie kennen die Situation: Ein kritisches IT-System fällt aus, die Geschäftsprozesse stehen still, und plötzlich wird aus dem eigentlich kompetenten IT-Team eine Gruppe ratloser Experten. „Das geht nicht“, „Zu komplex“, „Haben wir noch nie gemacht“ – diese Sätze hören Sie in solchen Momenten häufiger als Lösungsvorschläge. Doch genau jetzt braucht Ihr Unternehmen Handlungsfähigkeit statt Lähmung.
Die Wahrheit ist: IT-Krisen sind nicht die Ausnahme, sondern die Regel in der digitalen Geschäftswelt. Der Unterschied zwischen Unternehmen, die gestärkt aus solchen Situationen hervorgehen, und denen, die daran scheitern, liegt nicht in der Technik – sondern in der systematischen Vorbereitung und dem Mut zur strukturierten Problemlösung.
Warum IT-Teams in Krisen blockieren
Das größte Hindernis bei IT-Krisen ist paradoxerweise nicht die Komplexität der Technik, sondern die organisatorische Lähmung. Wenn gewohnte Prozesse nicht mehr funktionieren, entstehen Verantwortungsvakuum und Entscheidungsparalyse. IT-Experten, die normalerweise methodisch und risikobewusst arbeiten, werden plötzlich mit Situationen konfrontiert, die außerhalb ihrer Komfortzone liegen.
Diese Blockade verstärkt sich durch drei typische Faktoren:
Fehlende Entscheidungsstrukturen: In normalen Zeiten funktionieren IT-Prozesse über etablierte Hierarchien und Genehmigungsverfahren. Im Krisenfall sind diese Strukturen oft zu langsam oder nicht verfügbar.
Unklare Verantwortlichkeiten: Wer darf was entscheiden? Wer trägt die Verantwortung für drastische Maßnahmen? Diese Unsicherheit führt dazu, dass niemand die Initiative ergreift.
Angst vor Fehlentscheidungen: Der Gedanke „Wenn wir es falsch machen, wird alles noch schlimmer“ lähmt das Handeln – obwohl Untätigkeit oft die schlechteste Option ist.
Die 10 Goldenen Regeln für IT-Krisenmanagement
Regel 1: Klare Verantwortlichkeiten definieren
Bestimmen Sie noch vor der Krise einen Notfallmanager und einen Verantwortlichen für Informationssicherheit. Diese beiden Personen bilden das Krisenteam und sind befugt, schnelle Entscheidungen zu treffen. Wichtig: Beide müssen regelmäßig geschult werden und eng mit der Geschäftsleitung abgestimmt sein.
Regel 2: Kritische Prozesse identifizieren und priorisieren
Analysieren Sie systematisch, welche Geschäftsprozesse zeitkritisch sind und welche IT-Systeme Ihre „Kronjuwelen“ darstellen. Diese erhalten in der Krise oberste Priorität. Erstellen Sie eine klare Rangfolge – dies ermöglicht rationale Entscheidungen unter Zeitdruck.
Regel 3: Vollständige IT-Dokumentation erstellen
Dokumentieren Sie alle IT-Systeme, Kommunikationswege, Technologien und Schnittstellen. Diese Dokumentation muss nicht perfekt sein – arbeiten Sie sich vom Groben ins Feine vor. Nutzen Sie automatisierte Netzwerkanalysetools, um den Aufwand zu reduzieren.
Regel 4: Externe Unterstützung vertraglich sichern
Klären Sie mit Ihren IT-Dienstleistern im Vorfeld, welche Unterstützung Sie bei Sicherheitsvorfällen erhalten. Lassen Sie sich Verfügbarkeit und Reaktionszeiten vertraglich zusichern. Identifizieren Sie spezialisierte Notfallanbieter für kritische Szenarien.
Regel 5: Geschäftsleitungs-Commitment einholen
Erarbeiten Sie gemeinsam mit der Geschäftsleitung Leitlinien für das Krisenmanagement. Ohne klare Rückendeckung und definierte Befugnisse funktioniert kein effektives Krisenmanagement. Die Geschäftsleitung muss verstehen, dass schnelle Entscheidungen manchmal wichtiger sind als perfekte Lösungen.
Regel 6: Proaktives Vorsorgekonzept entwickeln
Konzipieren Sie Maßnahmen, die präventiv auf Schadenshöhe oder Eintrittswahrscheinlichkeit wirken. Definieren Sie Handlungsweisen, die die Reaktionsfähigkeit nach einem Schadensereignis sicherstellen. Dies umfasst sowohl technische als auch organisatorische Vorsorgemaßnahmen.
Regel 7: Das Notfallhandbuch als zentraler Dreh- und Angelpunkt
Erstellen Sie ein praxistaugliches Notfallhandbuch mit kurzen, übersichtlichen Informationen. Sogenannte „IT-Notfallkarten“ haben sich bewährt – kompakte Handlungsanleitungen für spezifische Szenarien. Integrieren Sie Geschäftsfortführungspläne und Wiederanlaufpläne mit klaren Zuständigkeiten.
Regel 8: Regelmäßige Tests und Aktualisierungen
Testen Sie Ihre Notfallpläne regelmäßig durch simulierte Krisenszenarien. Aktualisieren Sie Dokumentationen und Prozesse basierend auf den Erkenntnissen. Ein ungetesteter Notfallplan ist oft wertlos.
Regel 9: Kommunikationsstrukturen etablieren
Definieren Sie klare Kommunikationswege für den Krisenfall. Wer informiert wen? Welche Kanäle bleiben auch bei IT-Ausfällen verfügbar? Bereiten Sie Kommunikationsvorlagen für verschiedene Stakeholder vor.
Regel 10: Nachbereitung und Lessons Learned
Führen Sie nach jeder Krise eine strukturierte Nachbereitung durch. Dokumentieren Sie, was funktioniert hat und was verbessert werden muss. Diese Erkenntnisse fließen in die Aktualisierung Ihrer Notfallpläne ein.
Praktische Umsetzung: Der erste Schritt aus der Lähmung
Wenn Sie sich fragen, wo Sie anfangen sollen, folgen Sie diesem bewährten Vorgehen:
Sofortmaßnahmen (erste 24 Stunden):
Bestimmen Sie einen Krisenverantwortlichen
Verschaffen Sie sich einen Überblick über betroffene Systeme
Aktivieren Sie externe Unterstützung
Informieren Sie relevante Stakeholder
Kurze Frist (erste Woche):
Analysieren Sie die Ursachen
Implementieren Sie Workarounds für kritische Prozesse
Dokumentieren Sie alle durchgeführten Maßnahmen
Kommunizieren Sie regelmäßig mit Betroffenen
Mittelfristige Stabilisierung (erste 4 Wochen):
Entwickeln Sie dauerhafte Lösungen
Überprüfen Sie Ihre Notfallpläne
Schulen Sie Ihr Team basierend auf den Erfahrungen
Stärken Sie präventive Maßnahmen
Technische Grundlagen für effektive Krisenprävention
Neben organisatorischen Maßnahmen sind technische Vorsorgemaßnahmen entscheidend:
Monitoring und Früherkennung: Implementieren Sie umfassende Monitoring-Systeme, die Probleme erkennen, bevor sie kritisch werden. Automatisierte Alarme und Dashboard-Lösungen verschaffen Ihnen den nötigen Vorsprung.
Backup- und Recovery-Strategien: Regelmäßige, getestete Backups sind die Lebensversicherung Ihrer IT. Definieren Sie Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) für verschiedene Systemkategorien.
Sicherheitsmaßnahmen: Firewalls, Antiviren-Programme und Verschlüsselungstechnologien bilden die erste Verteidigungslinie. Regelmäßige Sicherheitsüberprüfungen und Penetrationstests identifizieren Schwachstellen, bevor sie ausgenutzt werden.
Mitarbeiterschulungen: Der Mensch ist oft das schwächste Glied in der Sicherheitskette. Schulungen zu Phishing-Prävention und Cyber-Sicherheit schaffen Bewusstsein und Widerstandsfähigkeit.
Der Mindset-Shift: Von der Blockade zur Handlungsfähigkeit
Der entscheidende Unterschied zwischen erfolgreichen und erfolglosen Unternehmen liegt in der Einstellung zur Krise. Anstatt zu warten, bis alle „Ja“ sagen, oder bis die perfekte Lösung gefunden ist, benötigen Sie den Mut zur strukturierten Problemlösung.
Erfolgreiche IT-Krisenmanager zeichnen sich durch folgende Eigenschaften aus:
Sie treffen Entscheidungen basierend auf verfügbaren Informationen, auch wenn diese unvollständig sind
Sie kommunizieren transparent über Unsicherheiten und Risiken
Sie fokussieren sich auf das Wesentliche und vermeiden Perfektionismus
Sie lernen kontinuierlich aus Fehlern und passen ihre Strategien an
Fazit: Handlungsfähigkeit als Erfolgsfaktor
IT-Krisen sind unvermeidlich, aber sie müssen nicht zum Geschäftsrisiko werden. Der Schlüssel liegt in der systematischen Vorbereitung und der Bereitschaft, auch in unsicheren Situationen zu handeln. Beginnen Sie mit klaren Verantwortlichkeiten, dokumentieren Sie systematisch, und schaffen Sie ein praxistaugliches Notfallhandbuch.
Der wichtigste Erfolgsfaktor ist jedoch das richtige Mindset: Warten Sie nicht auf Einstimmigkeit oder die perfekte Lösung. In der Krise ist eine gute Entscheidung, die schnell umgesetzt wird, oft besser als die theoretisch perfekte Lösung, die zu spät kommt.
Sind Sie bereit, Ihr IT-Krisenmanagement auf das nächste Level zu heben? Kontaktieren Sie uns für eine Gap-Analyse Ihrer aktuellen Notfallvorsorge. Gemeinsam entwickeln wir Lösungen, die funktionieren – auch wenn alle anderen sagen, es geht nicht.
Wie aus 40.000qm dreimal die richtige Lösung wurde – und warum sie trotzdem scheiterte
Transformation ist nicht nur ein Buzzword. Manchmal ist es Überlebenskunst. Das Oktogon in Rendsburg durchlief eine dreifache Transformation Krise: 2014 sollte es Deutschlands erstes Innovationshotel werden. 2015 wurde daraus in einer Transformation Krise ein Konzept für ein Migrationsinternat. 2016 endete die Transformation Krise mit einer erzwungenen Rückabwicklung. Diese Geschichte zeigt, warum die beste Lösung in einer Transformation Krise scheitern kann – und warum das Scheitern selbst eine Lösung sein kann.
Phase 1: Transformation Krise – Das Innovationshotel für Eingesperrte
Das Oktogon sollte die Transformation ermöglichen:
40.000qm ehemalige Kaserne in Rendsburg
Platz für 200+ Innovatoren
Weg vom Konzern-Druck
Finanziert durch PE-Investoren, die verstehen
Die Transformation-Idee war revolutionär: Nicht Innovation IN Unternehmen, sondern Innovation AUSSERHALB – und dann zurück.
Warum es die richtige Transformation war
Das Innovatorenproblem ist real:
M/OMS läuft seit 1988 – trotz, nicht wegen der Umgebung
Jeder kennt Projekte, die „politisch“ gestorben sind
Innovatoren brauchen Schutzräume
Das Oktogon bot alles:
Physischen Abstand zu Bremsern
Community von Gleichgesinnten
Ressourcen ohne Rechtfertigungszwang
Zeit für echte Transformation
Dann kam die erste Transformation Krise.
Phase 2: Transformation Krise Flüchtlinge – Vom Hotel zum Internat
August 2015. Die Investoren springen ab.
Nicht wegen des Konzepts. Sondern weil die Stadt eine Erstaufnahme für Asylbewerber in der Nähe plante. Die Investoren fürchteten um ihre Reputation. 40.000qm standen vor der Pleite.
Die Transformation in 72 Stunden:
Statt Innovationshotel → Migrationsinternat.
Das neue Konzept: Integration als Transformation
Wenn schon Flüchtlinge, dann richtig. Nicht Unterbringung, sondern Transformation:
Das Migrationsinternat-Konzept:
2.000 Menschen Kapazität
3 Monate intensive Qualifizierung
8.000-10.000 Menschen pro Jahr transformiert
Sprache + Ausbildung + Kultur = Integration
Die vorhandene Infrastruktur:
Mensa für 2.000 Personen
Schulungsräume (ehemalige Kaserne)
Unterkünfte fertig
Nur Sanierung nötig, keine Container
Der Gang nach Berlin: Transformation trifft Bürokratie
Das Bundeskanzleramt fand das Konzept gut. Weiterleitung ans Innenministerium.
Erste Frage des Ministeriums: „Wie viele Container brauchen Sie?“
Meine Antwort: „Keine. Wir haben 40.000qm Gebäude.“
Das System-Problem der Transformation:
Ich dachte: Integrierte Lösung, Qualifizierung, nachhaltige Transformation
Die Behörde dachte: Unterbringung, Container, Verwaltung
IHK Lübeck/Kiel: Wollten auch ausbilden, hatten aber keine Räume
Drei Akteure, eine offensichtliche Lösung, keine Transformation.
Drei schlechte Teillösungen statt einer Transformation
Uns lief die Zeit davon.
Phase 3: Transformation Krise Exit – Die Kunst des Ausstiegs
Dezember 2015. Die Lage:
Investoren weg (Innovationshotel)
Behörden zu langsam (Migrationsinternat)
Finanzdruck steigend
Keine Lösung in Sicht
Die letzte Transformation Krise: Den Verkäufer zur Rücknahme zwingen.
Das war keine Kapitulation. Das war Strategie:
Sauberer Schnitt statt endloser Hängepartie
Keine Insolvenzgefahr
Keine faulen Kompromisse
Transformation des Problems in eine Lösung
Die Exit-Transformation gelang
Innerhalb von 4 Wochen:
Rechtliche Position aufgebaut
Verkäufer in Zugzwang gebracht
Rückabwicklung erzwungen
Finanzdruck eliminiert
Diese Transformation war die wichtigste: Erkennen, wann man transformieren muss – in den Ausstieg.
Transformation Krise Lehren: Was wir gelernt haben
Lehre 1: Transformation ist nicht optional
2014: Markt forderte Innovationsräume → Transformation zum Innovationshotel
2015: Krise forderte Flüchtlingslösung → Transformation zum Integrationskonzept
2016: Deadlock forderte Exit → Transformation zur Rückabwicklung
Jede Transformation war richtig für ihren Moment.
Lehre 2: Die beste Lösung garantiert keine Transformation
Das Oktogon hatte immer die beste Lösung:
Für Innovatoren: Perfekter Schutzraum
Für Integration: 40.000qm fertige Infrastruktur
Für den Exit: Saubere Rückabwicklung
Trotzdem scheiterten zwei von drei Transformationen.
Lehre 3: System-Trägheit killt Transformation
Warum Deutschland keine Transformation kann:
Zu viele Stakeholder
Zu lange Entscheidungswege
Zu viel Absicherung
Zu wenig Mut
Das Container-Denken ist symptomatisch: Lieber schlechte Standard-Lösung als gute Transformation.
Lehre 4: Exit ist auch eine Transformation
Die schwierigste Transformation: Aufgeben zum richtigen Zeitpunkt.
Nicht jeder Kampf ist gewinnbar
Nicht jede Transformation gelingt
Aber jeder Exit kann kontrolliert sein
Transformation-Analyse für PE-Investoren
Was das Oktogon über Portfolio-Transformation lehrt
1. Multi-Optionalität ist wertvoll: 40.000qm konnten dreimal unterschiedlich transformiert werden. Flexible Assets überleben Krisen.
2. Transformation-Geschwindigkeit entscheidet: 72 Stunden vom Innovationshotel zum Migrationsinternat. Aber Behörden brauchten Monate. Speed kills oder rettet.
3. Stakeholder-Komplexität tötet Transformation:
Innovationshotel: 1 Entscheider → möglich
Migrationsinternat: 5+ Entscheider → tot
Exit: 2 Parteien → erfolgreich
4. Exit-Transformation ist unterbewertet: Der erzwungene Rückverkauf war die profitabelste Transformation. Manchmal ist raus besser als rein.
Gap-Analysis zeigt nicht immer den Weg zum Sieg. Manchmal zeigt sie, wie man mit Würde kämpft. Bei CIBER Deutschland führte ich 2015 eine Gap-Analysis unter Extrembedingungen durch: 90% der Mitarbeiter waren zum Konkurrenten gewechselt, 120 SAP-Systeme drohten zu kollabieren, und eine feindliche Übernahme stand bevor. Mit den verbliebenen 10% kämpften wir. Diese Gap-Analysis Geschichte handelt nicht vom Siegen – sondern vom Kämpfen mit denen, die bleiben.
Die Ausgangslage: Gap-Analysis im Wirtschaftskrieg
CIBER AG Deutschland, 2015. Die US-Mutter vor der Insolvenz. Ein Konkurrent witterte seine Chance: Systematisch 90% der Mitarbeiter abwerben, das Unternehmen kollabieren lassen, dann billig übernehmen.
Die klassische Berater-Analyse hätte gesagt: „Aufgeben. Ohne Personal keine Chance.“
Meine Gap-Analysis sollte zeigen: Was ist mit 10% noch möglich?
Gap-Analysis Befund 1: Der Loyalitäts-Gap
Warum blieben die 10%?
Meine Gap-Analysis begann nicht bei Systemen, sondern bei Menschen:
Wer blieb trotz besserer Angebote?
Was motivierte sie zu bleiben?
Welche Skills hatten die Verbliebenen?
Gap-Analysis Erkenntnis: Die 10% waren nicht die Übriggebliebenen. Es waren die Loyalen. Die mit Ehre. Die, die ein sinkendes Schiff nicht verlassen.
Diese Gap-Analysis zeigte: Mit diesen 10% konnte man kämpfen.
Gap-Analysis Befund 2: Der System-Gap
120 SAP-Systeme, 10% Personal – die Gap-Analysis Mathematik
Die systematische Gap-Analysis der Systemlandschaft ergab:
80% der Systeme: Quasi-identische Kopien
15% der Systeme: Variationen eines Grundmusters
5% der Systeme: Wirklich unique
Gap-Analysis Lösung: Nicht 120 individuelle Systeme betreuen, sondern 5 Templates managen.
Diese Gap-Analysis machte das Unmögliche rechnerisch möglich.
Gap-Analysis Befund 3: Der Wissens-Gap
90% Know-how weg – was die Gap-Analysis über Wissen verrät
Die abgewanderten Kollegen nahmen ihr Wissen mit. Manche hinterließen bewusst Chaos. Die Gap-Analysis musste klären:
Was wissen wir noch?
Was können wir rekonstruieren?
Was müssen wir neu lernen?
Gap-Analysis Strategie:
Radikale Dokumentation
Reverse Engineering wo nötig
Wissen der 10% multiplizieren
Diese Gap-Analysis wurde zum Crashkurs in Wissensmanagement unter Feuer.
Gap-Analysis Befund 4: Der Zeit-Gap
Wochen bis zum Kollaps – Gap-Analysis gegen die Uhr
Die Gap-Analysis identifizierte kritische Zeitfenster:
2 Wochen: Erste Systeme würden ausfallen
4 Wochen: Kunden würden abspringen
8 Wochen: Point of no return
Gap-Analysis Prioritäten:
Kritische Systeme zuerst
Sichtbare Stabilität für Kunden
Automatisierung im Schnelldurchlauf
Diese Gap-Analysis wurde zum Wettlauf gegen die Zeit.
Die Schlacht: Gap-Analysis in Aktion
Woche 1-2: Gap-Analysis und Mobilisierung
Die verbliebenen 10% versammelten sich. Die Gap-Analysis hatte gezeigt, was möglich war. Nicht Sieg, aber Widerstand. Sie entschieden zu kämpfen.
Woche 3-4: Gap-Analysis Umsetzung beginnt
Template-Strategie implementiert
Erste Automatisierungen live
120 Systeme auf 5 Grundmuster reduziert
Die Gap-Analysis Maßnahmen griffen. Die Systeme hielten.
Woche 5-8: Der Kampf
Die 10% arbeiteten wie 100%. Nachts, Wochenenden, Feiertage. Die Gap-Analysis hatte den Weg gezeigt, aber gehen mussten sie ihn selbst.
Die Systeme liefen stabil.
Das Ende: Was Gap-Analysis nicht ändern kann
Am Ende reichte es nicht. Die finanziellen Probleme der Muttergesellschaft, der Kundenverlust, die Marktposition – manche Gaps sind zu groß.
CIBER wurde übernommen.
Aber: Die 10% hatten bewiesen, was möglich ist. Die Gap-Analysis hatte funktioniert. Die Systeme liefen bis zum letzten Tag stabil.
Gap-Analysis Lehren aus der Niederlage
Lehre 1: Gap-Analysis zeigt die Wahrheit
Manchmal ist die Wahrheit: „Es wird nicht reichen.“ Aber besser kämpfend untergehen als kampflos kapitulieren.
Lehre 2: Menschen sind der wichtigste Gap
Die 10%, die blieben, waren mehr wert als die 90%, die gingen. Gap-Analysis muss Menschen-Faktoren einbeziehen.
Lehre 3: Gap-Analysis funktioniert auch unter Feuer
Selbst unter extremsten Bedingungen identifiziert systematische Gap-Analysis Handlungsoptionen.
Lehre 4: Niederlage ist auch ein Ergebnis
Eine ehrliche Gap-Analysis verschweigt nicht, wenn die Lage aussichtslos ist. Sie zeigt nur, wie man trotzdem kämpft.
Gap-Analysis für PE-Investoren: Die unbequeme Wahrheit
Standard Due Diligence hätte gesagt: „90% Mitarbeiter weg = aufgeben“
Meine Gap-Analysis zeigte:
Mit 10% ist Stabilisierung möglich
Die wahren System-Redundanzen
Der tatsächliche Zeitrahmen
Die realen Optionen
Das Ergebnis war nicht „Sieg“, sondern „Klarheit“.
Warum diese Gap-Analysis Geschichte wichtig ist
PE-Investoren wollen Erfolgsgeschichten. Ich erzähle auch von Niederlagen. Warum?
Weil echte Gap-Analysis die Wahrheit zeigt:
Manchmal findet man 100-Millionen-Gaps
Manchmal findet man unheilbare Wunden
Beides ist wertvoll zu wissen
Weil Charakter in der Krise sichtbar wird:
Wer bleibt, wenn alle gehen?
Wer kämpft, wenn alles verloren scheint?
Mit wem würden Sie in den nächsten Kampf ziehen?
Die 10% Regel der Gap-Analysis
Aus CIBER habe ich die „10% Regel“ abgeleitet:
In jeder Krise bleiben 10%, die kämpfen wollen.
Mit diesen 10% und systematischer Gap-Analysis kann man:
Systeme stabilisieren
Zeit kaufen
Optionen schaffen
Würdig kämpfen
Nicht immer gewinnen. Aber immer die Wahrheit kennen.
Gap-Analysis heute: Was ich mitgenommen habe
Die CIBER Gap-Analysis war keine Niederlage. Sie war eine Lehre:
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
