BCG Platinion Case: Digitale Transformation eines gesamten Konzerns

i

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