BCG Platinion Case: Digitale Transformation eines gesamten Konzerns

Vorschläge für den Kandidaten zur Diskussion des Cases:

1. Denke an das eigentliche Ziel einer solchen Bewertung im größeren Case-Kontext

• In diesem Fall besteht das Ziel der Bewertung darin, die relevantesten Bereiche in der IT-Landschaft zu identifizieren und die dringendsten Problembereiche zu priorisieren, die angegangen werden müssen
• Konzentriere dich auf die wichtigsten Informationen – es reicht aus, die Hauptdimensionen zu erfassen (eine detaillierte Bewertung ist weder erforderlich noch gewünscht)

2. Behalte im Hinterkopf, wem die Ergebnisse präsentiert werden und passe den Kommunikationsstil entsprechend an

• Der CIO wird sich wahrscheinlich nicht für kleinere Details interessieren, während andere Führungskräfte auf Kundenseite möglicherweise nicht über tiefgehendes technisches Wissen verfügen
• Fokussiere dich auf die übergeordnete Sichtweise und vermittle die Hauptaussagen zuerst; eine tiefere Analyse kann anschließend bei Bedarf erfolgen. Ein strukturiertes Framework kann genutzt werden, um einen ganzheitlichen Überblick zu bieten und gleichzeitig die Analyse zu unterteilen

Beispielhafte Lösung (andere Antworten sind möglich):

1. Definiere den Rahmen für die Bewertung

• Die Zuordnung von IT-Anwendungen zur industriellen Wertschöpfungskette und zur Geschäftsfunktion bietet einen ganzheitlichen Überblick
• Relevante Dimensionen für die Analyse der Anwendungen könnten sein:
  • „Impact“ (geschäftskritisch oder nicht)
  • Schweregrad (hoch/mittel/niedrig) der ermittelten Probleme in Bezug auf Stabilität, Skalierbarkeit, lange TTM (Time-to-Market)
  • Art der Anwendung (z. B. maßgeschneiderte- oder Standardsoftware)

2. Beschreibe den Ansatz, den du zur Durchführung der Bewertung wählen würdest

• Analysiere die verfügbare Dokumentation (z. B. Application Map/Inventory, Vorfallsberichte zur Identifizierung von Stabilitätsproblemen)
• Führe Interviews mit wichtigen Stakeholdern (z. B. CIO, Leiter IT Ops, ausgewählte BRM²/BU³-Leads), um die Informationen zu ergänzen

3. Definition der Treiber für die Priorisierung von Deep Dives und Empfehlungen

• Konzentriere dich auf geschäftskritische Anwendungen, die besonders schwerwiegende Probleme aufweisen, und behandle den Rest nach Ausnahmeprinzip

Vorschläge für den Kandidaten zur Diskussion des Cases:

1. Definiere Annahmen, um den Umfang der Analyse einzuschränken

• Angesichts der begrenzten Informationen (und Zeit), die zur Verfügung stehen, ist es wichtig, im Vorfeld plausible Hypothesen aufzustellen, die die Analyse leiten.
• Validiere diese Hypothesen mit dem Interviewer und passe deinen Ansatz je nach Feedback an

2. Gehe die Problempunkte nacheinander an und bleib einheitlich

• Beschreibe die technologischen Hebel, mit denen jeder Pain Point angegangen werden könnte, einen nach dem anderen, und erläutere dabei die Hauptgründe für die Empfehlung
• Vermische keine Themen und behalte die im Vorfeld validierten Annahmen im Hinterkopf

Beispielhafte Lösung (andere Antworten sind möglich):

Pain Point „Stabilität“

• Hypothesen zu den Grundursachen
  • Fehlerhafter/schlecht geschriebener Custom Code (z. B. aufgrund verschiedener Änderungen im Laufe der Zeit) mit begrenzter oder fehlender Dokumentation
  • Veraltete/nicht mehr unterstützte Anwendungen
  • Exzessive Anpassung von Anwendungssoftware
• Vorgeschlagener technischer Hebel
  • Refactoring von kundenspezifischen Anwendungen in eine modulare und entkoppelte Architektur: Die Anpassung der aktuellen Anwendungen wäre zu komplex. Es könnte einfacher sein, ganze/teilweise benutzerdefinierte Anwendungen unter Verwendung neuer Technologien und vor allem mit einem modularen Ansatz (z. B. „Microservices-Architektur“) neu zu schreiben, der eine einfachere Isolierung von Fehlern ermöglicht, so dass die nicht betroffenen Funktionen weiter funktionieren und somit die Gesamtstabilität erhöht wird.

Pain Point „Skalierbarkeit“

• Hypothesen zu den Ursachen
  • Einschränkungen in der gesamten IT-Architektur
  • Veraltete/„kapazitätsbeschränkte“ IT-Infrastruktur
• Vorgeschlagener technischer Hebel
  • Cloud-Lösungen: PaaS (Platform-as-a-Service)-Cloud-Lösungen können für neue/umgeformte kundenspezifische Entwicklungen genutzt werden, um Kapazitätsbeschränkungen der lokalen Infrastruktur zu überwinden.
    Ebenso können SaaS (Software-as-a-Service)-Lösungen als Anwendungen für „Standard“/nicht differenzierende Funktionalitäten betrachtet werden.

Pain Point „Time-to-Market“

• Hypothesen zu den Ursachen
  • Einschränkungen in der gesamten IT-Architektur
  • Abhängigkeiten aufgrund einer stark integrierten/gekoppelten IT-Anwendungslandschaft
  • Komplexe und sehr manuelle SW-Release-Management-Verfahren
• Vorgeschlagener technischer Hebel
  • Refactoring von kundenspezifischen Anwendungen mit modularer und entkoppelter Architektur: Neben höherer Stabilität ermöglicht die Modularisierung auch eine schnellere Implementierung von Funktionalitäten, da jedes einzelne Modul unabhängig geändert und eingesetzt werden kann
  • Automatisierung des Lebenszyklus der SW-Entwicklung: Neben dem Refactoring würde die Einführung neuer SDLC-Ansätze wie DevOps, die eine starke Automatisierung implizieren (z. B. automatisierte Tests, kontinuierliche Bereitstellung usw.), schnellere Release-Zyklen ermöglichen.

Vorschläge für den Kandidaten zur Diskussion des Cases:

1. Setze Prioritäten und beginne mit der Beschreibung der wichtigsten Dimensionen

• Fühle dich nicht gedrängt, eine vollständige Liste der anwendbaren Dimensionen vorzulegen, nehme dir Zeit, deine Antwort zu strukturieren
• Fordere dich selbst heraus, Themen zu identifizieren, die nicht sofort offensichtlich sind

2. Beispiele sind eine gute Möglichkeit, die Konzepte zu vertiefen, aber mache sie so spezifisch wie möglich

• Berücksichtige den Case-/Kundenkontext, wenn du Beispiele anführen willst; z.B. könnte ERP in vielen Fällen ein gutes Beispiel für eine geschäftskritische Anwendung sein, aber nicht, wenn der Kunde eine Versicherungsgesellschaft ist

Beispielhafte Lösung (andere Antworten sind möglich):

• Refactoring zu Microservices (modulare & entkoppelte Architektur)
  • Relevanz für das Geschäft und spezifische Anforderungen: Der Aufwand für eine Neuimplementierung im eigenen Haus mit einer kundenspezifischen Entwicklung ist für geschäftskritische, differenzierende Funktionalitäten sinnvoll (Abwägung mit Funktionalitäten, die von Anwendungssoftware-Alternativen abgedeckt werden, ist möglicherweise nicht geeignet)
  • Erwartete Frequenz von Änderungen: Anwendungen, bei denen eine hohe Änderungshäufigkeit und die Freigabe neuer Funktionen zu erwarten ist (z.B. aufgrund von geschäftlichen Prioritäten oder gesetzlichen/regulatorischen Anforderungen), profitieren am meisten von der kürzeren Markteinführungszeit.
  • Heterogene Skalierbarkeitsanforderungen: Das Refactoring von Anwendungen, die hohe Skalierbarkeitsanforderungen nur für ausgewählte Funktionalitäten würde eine hohe Effizienz bei der Skalierung einzelner Module (statt der gesamten monolithischen Anwendung) ermöglichen
• Einführung von Cloud-Lösungen
  • Nutzungsmuster: Anwendungen mit dynamischen Nutzungsmustern (d.h. Peaks und Valleys im Vergleich zu Flat) würden am meisten von der elastischen Skalierbarkeit profitieren, die durch Cloud-Lösungen ermöglicht wird (z.B. anwendbar auf PaaS-Lösungen in Kombination mit der Implementierung neuer Microservices)
  • Technologische Kompatibilität: Einige Technologiestapel (z.B. Cobol, z/OS) sind kaum für Cloud-Migrationen geeignet (obwohl dies im Falle einer SaaS-Implementierung transparent wäre)
  • Latenzempfindlichkeit: Anwendungen, die sehr „latenzempfindlich“ sind, könnten durch die zusätzliche Latenz, die durch Cloud-Optionen im Vergleich zu On-Premise-Lösungen entsteht, negativ beeinflusst werden

Vorschläge für den Kandidaten zur Diskussion des Cases:

1. Führe deinen Gesprächspartner durch die Schritte, um deinen Ansatz zu demonstrieren

• Erkläre bei Bedarf explizit deine Annahmen und bespreche diese mit deinem Gesprächspartner
• Schreibe wichtige Informationen und Zwischenschritte deiner Berechnung auf, um den Ansatz klarer zu beschreiben, und lege die Hebel dar, die zur Kostensenkung führen

2. Trainiere deine Skills im Kopfrechnen

• Diese Art von Frage soll deine quantitativen Fähigkeiten zeigen und wie gut du mit Zahlen umgehen kannst, ohne einen Taschenrechner zu benutzen

Beispiel (deine Antwort könnte die folgenden Schritte umfassen):

• Im Bereich Change the Business (CtB) gibt das Unternehmen 4,3 % mehr Geld aus als die Konkurrenz
• Der Grund dafür sind die höheren Kosten für die Erstellung neuer Software in einer komplexen und verworrenen Landschaft, die sich auf 11,4 % der gesamten IT-Kosten belaufen
• Um die IT-Ausgaben zu optimieren, kann das Unternehmen einen Blick auf das Projektportfolio werfen und die Kosten durch die Nutzung von Kategorien im Portfolio senken
• Annahme, dass Projekte, die nicht der Regulierung unterliegen, 60 % des Projektportfolios ausmachen (basierend auf der Annahme, dass es sich zu 40 % um regulatorische Projekte handelt, siehe Exhibit "Analysis") und vollständig reduziert werden können
• Die Portfoliokosten können um 60 % gesenkt werden, was zu einer Reduzierung von 48 Mio. € (80 Mio. € CtB * 60 %) führt. Eine vollständige Kürzung aller nicht-regulatorischen Ausgaben wird das Unternehmen jedoch bei der Umsetzung neuer Produkte, Modernisierungs- oder Innovationsprojekte einschränken.

Zusammenfassend lässt sich sagen, dass Change the Business (CtB) reduziert werden kann, aber auch die Instandhaltung in RtB sollte untersucht werden, indem die technischen Schulden (Modernisierung des Kerns) und die externen Kosten durch Neuverhandlung und Reduzierung der externen Kosten (z.B. durch Reduzierung des Portfolios) reduziert werden