Eine strukturierte Methodik für Technologie-Beschaffungsentscheidungen. Vom Scoring der strategischen Ausrichtung über die TCO-Modellierung bis hin zur Commonalization-Analyse und der Bewertung des Anbieterrisikos — das vollständige Playbook für Unternehmen, die Daten brauchen, keine Meinungen.
Ein europäischer Industriekonzern baute über 18 Monate eine maßgeschneiderte PLM-Integrationsplattform über 3 Divisionen hinweg. Kosten: 4,2 Mio. €. Zwei Jahre später stellte man fest, dass eine kommerzielle Lösung alle drei Divisionen für insgesamt 800 K€ hätte bedienen können — doch zu diesem Zeitpunkt hatten drei separate Teams inkompatible Systeme ohne jede Commonalization gebaut. Die wahren Kosten waren nicht die 4,2 Mio. €. Es waren die 2 Jahre der Divergenz, die eine Konsolidierung nahezu unmöglich machten.
Diese Geschichte ist nicht ungewöhnlich. In Gesprächen mit Engineering-Verantwortlichen europäischer Industriekonzerne tauchen immer wieder dieselben Fehlermuster auf. Die eigentliche Ursache ist fast nie die Technologie. Es ist das Fehlen eines strukturierten Entscheidungsprozesses — und, entscheidend, das Fehlen einer Commonalization-Bewertung, bevor jemand eine Zeile Code schreibt oder einen Anbietervertrag unterzeichnet.
Jede Einheit baut eigenständig. Keine zentrale Governance, keine Commonalization-Bewertung. Dasselbe Problem wird fünfmal zum fünffachen Preis gelöst. Divisions-CTOs schützen ihre Autonomie, und die Konzern-IT hat kein Mandat, portfolioweite Entscheidungen durchzusetzen. Das Ergebnis: inkompatible Systeme, die sich ohne eine mehrjährige Migration nicht konsolidieren lassen.
Teams vergleichen die Build-Kosten von Jahr 1 mit der Lizenzgebühr von Jahr 1. Echte TCO umfassen 5 Jahre Wartung, Talentbindung, Infrastruktur, Schulung und Opportunitätskosten. Build-Kosten sind vorlastig und sichtbar. Wartungskosten sind verteilt, in Teambudgets verborgen und kumulierend. Die Build-Option wirkt in Jahr 1 günstig und in Jahr 5 teuer.
Commodities werden gebaut, weil „wir das schon immer so gemacht haben“. Kerndifferenzierer werden ausgelagert, weil „die Anbieter-Demo großartig aussah“. Ohne Rahmen gewinnt die Politik. Die lauteste Stimme im Raum entscheidet, ob gebaut oder gekauft wird — und das ist meist diejenige, die am meisten von der Entscheidung profitiert, nicht am meisten zu verlieren hat.
Jede Make/Buy-Entscheidung sollte anhand dieser sechs Dimensionen bewertet werden. Die Standardgewichtungen unten eignen sich für einen industriellen Großkonzern mit mehreren Geschäftseinheiten — passen Sie die Gewichtungen an Ihren konkreten Kontext an. Ein Startup gewichtet Time to Value vielleicht mit 30 %. Ein Rüstungsunternehmen gewichtet Risiko und Abhängigkeit vielleicht mit 35 %.
Die Gewichtungen müssen sich zu 100 summieren. Die Abschnitte 3, 4, 5 und 6 vertiefen die vier am höchsten gewichteten Dimensionen.
Schafft der Eigenbau einen Wettbewerbsvorteil? Ist es Kern Ihrer Differenzierung oder eine Commodity, die Anbieter besser können? Beinhaltet die Opportunitätskosten von Engineering-Talenten.
Vollständiger Kostenvergleich über 5 Jahre: Entwicklung, Wartung, Infrastruktur, Talente, Schulung, Anbietergebühren, Integration, Migration und versteckte Kosten.
Kann eine Lösung mehrere Divisionen, Einheiten oder Produktlinien bedienen? Wiederverwendungs-Scoring, Golden-Path-Potenzial und Chance zur einheitenübergreifenden Standardisierung.
Risiko des Anbieter-Lock-ins, IP-Eigentum, Abhängigkeit der Lieferkette, Schlüsselpersonen-Risiko (Build), technologische Obsoleszenz und regulatorische Exposition.
Wie schnell liefert jede Option produktiven Wert? Build-Zeitpläne vs. Anbieter-Deployment, Integrationskomplexität und organisatorische Reife.
Haben Sie die Talente, um zu bauen und zu warten? Einstellungszeitplan, Schulungsinvestition, Bindungsrisiko und kulturelle Passung von Build vs. Buy.
flowchart TD
A([Start: Technology Need]) --> B[Strategic Assessment]
B --> B1[Alignment with core competency?]
B --> B2[Competitive differentiation?]
B --> B3[Commonalization across entities?]
B1 & B2 & B3 --> C[Initial Classification]
C --> C1{Core to strategy?}
C1 -- Yes --> D[Build Track]
C1 -- No --> E[Buy Track]
D --> D1[Internal capability assessment]
D --> D2[TCO modeling: 5-year build cost]
D --> D3[IP & talent retention plan]
E --> E1[Vendor market scan]
E --> E2[TCO modeling: 5-year buy cost]
E --> E3[Integration & migration plan]
D1 & D2 & D3 --> F{Build TCO < 1.5x Buy TCO?}
E1 & E2 & E3 --> F
F -- Build wins --> G[Build Governance Gate]
F -- Buy wins --> H[Vendor Selection Process]
F -- Unclear --> I[PoC / Pilot Both]
I --> F
G --> J([Build Approved])
H --> K([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style D fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style G fill:#1e293b,stroke:#22c55e,color:#e2e8f0
style H fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style I fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style J fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style K fill:#0d1f12,stroke:#22c55e,color:#e2e8f0Standardgewichtung: 30 %
Die strategische Ausrichtung ist die wichtigste einzelne Dimension, weil sie die Richtung der gesamten Analyse bestimmt. Eine Fähigkeit, die Kern der Wettbewerbsdifferenzierung ist, sollte fast immer gebaut werden. Eine Commodity-Fähigkeit sollte fast immer gekauft werden. Das Schwierige ist die korrekte Klassifizierung.
| Klassifizierung | Definition | Standardaktion | Beispiele |
|---|---|---|---|
| Kerndifferenzierer | Schafft Wettbewerbsvorteil. Kunden wählen Sie wegen dieser Fähigkeit. | Build | Proprietäre Algorithmen, einzigartige Fertigungsprozesse, Kern-IP |
| Strategischer Enabler | Für die Strategieumsetzung erforderlich, aber nicht einzigartig für Ihr Geschäft. | Build oder Partner | Datenplattform, MLOps-Pipeline, maßgeschneiderte Integrationen |
| Operative Notwendigkeit | Muss zuverlässig funktionieren. Kein Wettbewerbsvorteil dadurch, es anders zu machen. | Buy | ERP, E-Mail, HR-Systeme, Standard-MES |
| Commodity-Dienstprogramm | Standardisiert, austauschbar. Der Markt bietet ausgereifte Lösungen. | Buy (SaaS) | Cloud-Hosting, Office-Tools, Projektmanagement |
Jeder Ingenieur, der ein Commodity-Tool baut, ist ein Ingenieur, der nicht Ihr Kernprodukt baut. Die Opportunitätskosten von Engineering-Talenten sind der am stärksten unterbewertete Faktor bei Make/Buy-Entscheidungen.
Standardgewichtung: 25 %
Ein 5-Jahres-TCO-Modell ist das Minimum für jede Technologieinvestition über 100 K€. Die meisten Teams modellieren nur die Kosten von Jahr 1, was systematisch die Build-Option (niedrige Anfangskosten, hohe kumulierende Wartung) gegenüber der Buy-Option (höhere Anfangslizenz, vorhersehbare Jahreskosten) bevorzugt.
Die Build-Kosten von Jahr 1 betragen typischerweise 40-50 % der 5-Jahres-Summe. Die restlichen 50-60 % entfallen auf Wartung, Talente und Infrastruktur.
Die Buy-Kosten von Jahr 1 (Lizenz + Implementierung) betragen typischerweise 50-70 % der 5-Jahres-Summe. Die laufenden Kosten sind vorhersehbarer als beim Build.
Versteckte Kosten erhöhen sowohl das Build- als auch das Buy-TCO-Modell typischerweise um 15-30 %. Berücksichtigen Sie sie in beiden, um Verzerrungen zu vermeiden.
Beispiel: Manufacturing Execution System für 3 Einheiten, insgesamt 200 Nutzer.
| Kostenkategorie | Build (5 Jahre) | Buy (5 Jahre) |
|---|---|---|
| Erstentwicklung / Implementierung | 1.200 K€ | 350 K€ |
| Jährliche Lizenz / Hosting | 180 K€ | 400 K€ |
| Wartung und Updates (5 J.) | 900 K€ | 150 K€ |
| Team (dedizierte FTEs, 5 J.) | 1.500 K€ | 300 K€ |
| Schulung und Einarbeitung | 120 K€ | 200 K€ |
| Integration und Migration | 200 K€ | 250 K€ |
| Sicherheit und Compliance | 100 K€ | 80 K€ |
| 5-Jahres-Summe | €4,200K | €1,730K |
In diesem Beispiel kostet der Eigenbau über 5 Jahre das 2,4-Fache des Kaufs. Die Build-Option erscheint nur in Jahr 1 günstiger (1.200 K€ vs. 1.200 K€ inklusive Implementierung + Lizenz des ersten Jahres). Die Divergenz beginnt in Jahr 2, wenn sich Wartungs- und Teamkosten kumulieren.
Standardgewichtung: 15 %
Commonalization ist die am stärksten übersehene Dimension bei Make/Buy-Entscheidungen — und die mit dem höchsten ROI für Organisationen mit mehreren Einheiten. Eine Lösung, die 4 Einheiten statt 1 bedient, senkt nicht nur die Kosten um 75 %. Sie beseitigt Integrationsschulden, ermöglicht Wissensaustausch und schafft einen Golden Path, der künftige Deployments beschleunigt.
Bewerten Sie jedes Kriterium mit 0-10. Eine Gesamtpunktzahl über 35 weist auf ein starkes Commonalization-Potenzial hin und rechtfertigt die Investition in eine gemeinsame Lösung. Unter 20 sind einheitenspezifische Lösungen angemessen.
| Kriterium | Punkte 0-3 (Niedrig) | Punkte 4-6 (Mittel) | Punkte 7-10 (Hoch) |
|---|---|---|---|
| Einheitenübergreifende Anwendbarkeit | 1 Einheit benötigt dies | 2-3 Einheiten haben ähnliche Bedarfe | 4+ Einheiten haben identische Kernanforderungen |
| Schnittstellen-Standardisierung | Völlig unterschiedliche UX pro Einheit | Ähnliche Workflows, unterschiedliche Datenmodelle | Gleiche Workflows, gleiche Datenmodelle, geringfügige Konfig-Unterschiede |
| Datenmodell-Kompatibilität | Inkompatible Schemata, keine gemeinsame Taxonomie | Teilweise Überschneidung, mit Aufwand abbildbar | Gemeinsame Stammdaten, gemeinsame Taxonomie, kompatible Schemata |
| Wiederverwendung der Deployment-Muster | Unterschiedliche Infrastruktur pro Einheit | Gleiche Cloud, unterschiedliche Konfigurationen | Ein einziges Deployment für alle Einheiten (mandantenfähig) |
| Wartungskonsolidierung | Separate Teams, kein gemeinsamer Code | Einige gemeinsame Bibliotheken, separate Deployments | Ein Team wartet eine gemeinsame Plattform für alle Einheiten |
Vervollständigen Sie diese Checkliste vor jeder Make/Buy-Entscheidung über 100 K€. Sie erzwingt einheitenübergreifende Sichtbarkeit und verhindert das teuerste Fehlermuster: dasselbe mehrfach zu bauen.
In jeder Organisation mit mehreren Einheiten, mit der wir gearbeitet haben, behaupten die Verantwortlichen der Einheiten, ihre Anforderungen seien „völlig einzigartig“. In der Praxis sind 70-85 % der funktionalen Anforderungen über die Einheiten hinweg identisch. Die wahrgenommene Einzigartigkeit liegt meist in Geschäftsregeln, die parametrisierbar sind, nicht in der grundlegenden Architektur. Der Test: Wenn Sie den Unterschied in einer Konfigurationsdatei statt durch eine Codeänderung beschreiben können, ist er nicht wirklich einzigartig. Führen Sie diesen Test durch, bevor Sie der Behauptung einer Einheit zustimmen, sie brauche ein separates System.
Standardgewichtung: 15 %
Sowohl Build als auch Buy bergen Risiken. Das Ziel ist nicht, Risiko zu eliminieren — sondern es zu quantifizieren und in das TCO-Modell einzupreisen. Ein Lock-in-Ausstiegskostenposten von 200 K€ ist beherrschbar. Ein Neuaufbau einer internen Plattform für 2 Mio. € aufgrund des Weggangs einer Schlüsselperson ist es nicht.
Ein durchgerechnetes Beispiel, das vier Beschaffungsoptionen für einen Industrie-OEM vergleicht, der ein Manufacturing Execution System bewertet. Bewerten Sie jede Option mit 1-10 pro Dimension, multiplizieren Sie mit der Dimensionsgewichtung und summieren Sie für das gewichtete Gesamtergebnis.
| Dimension | Gewichtung | Build In-HouseEigenentwicklung | Buy (SaaS)Cloud-Anbieter | Buy (On-Prem)Lizenzierte Software | PartnerCo-Entwicklung |
|---|---|---|---|---|---|
| Strategische Ausrichtung | 30% | 9/10(27.0) | 4/10(12.0) | 5/10(15.0) | 7/10(21.0) |
| Gesamtbetriebskosten | 25% | 4/10(10.0) | 8/10(20.0) | 6/10(15.0) | 7/10(17.5) |
| Commonalization-Potenzial | 15% | 6/10(9.0) | 8/10(12.0) | 7/10(10.5) | 9/10(13.5) |
| Risiko und Abhängigkeit | 15% | 8/10(12.0) | 4/10(6.0) | 6/10(9.0) | 5/10(7.5) |
| Time to Value | 10% | 3/10(3.0) | 9/10(9.0) | 6/10(6.0) | 7/10(7.0) |
| Organisatorische Fähigkeit | 5% | 5/10(2.5) | 9/10(4.5) | 7/10(3.5) | 8/10(4.0) |
| Gewichtetes Gesamt | 100% | 63.5 | 63.5Sieger | 59.0 | 70.5 |
In diesem Beispiel gewinnt Buy (SaaS) für ein Manufacturing Execution System bei einem Industrie-OEM. Der Eigenbau erzielt den höchsten Wert bei der strategischen Ausrichtung (9/10), verliert aber bei TCO, Time to Value und organisatorischer Fähigkeit. Das MES ist operative Infrastruktur, kein Wettbewerbsdifferenzierer — der hohe Wert für die strategische Ausrichtung bei „Build“ spiegelt die Präferenz des Engineering-Teams wider, keine objektive Bewertung.
Stichentscheid-Regel: Liegen zwei Optionen weniger als 5 Punkte auseinander, führen Sie einen parallelen Pilot von 6 Wochen durch. Für Build vs. Buy bedeutet das einen Anbieter-PoC parallel zu einem Build-Sprint, um beide TCO-Modelle mit echten Daten zu validieren.
Kritische Prüfung: Bevor Sie die Werte akzeptieren, lassen Sie den Konzern-CTO, die Einheiten-CTOs und den CFO unabhängig voneinander Gewichtungen und Werte vergeben. Verschiedene Stakeholder erzeugen verschiedene Sieger — das Gespräch über das Warum ist wertvoller als die endgültige Zahl.
Wenn Sie vor dem vollständigen 6-Dimensionen-Scoring eine schnelle richtungsweisende Antwort benötigen, nutzen Sie diesen Entscheidungsbaum. Er erfasst die wichtigsten Verzweigungsfragen und leitet zu einem empfohlenen Ansatz. Die vollständige Scoring-Matrix sollte die anfängliche Richtung anschließend validieren und verfeinern.
flowchart TD
A{Is this core to competitive advantage?} -- Yes --> B{Do we have the talent to build & maintain?}
A -- No --> C{Does a mature vendor solution exist?}
B -- Yes --> D{Can we build faster than buy+customize?}
B -- No --> E[Partner or Acqui-hire]
C -- Yes --> F{Can it serve multiple entities?}
C -- No --> G[Build with commonalization mandate]
D -- Yes --> H[Build In-House]
D -- No --> I[Buy & Customize]
F -- Yes --> J[Buy & Standardize]
F -- No --> K{Is customization >40% of solution?}
K -- Yes --> G
K -- No --> J
style A fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style B fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style C fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style E fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style G fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style H fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style I fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style J fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style K fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0Dies sind die wiederkehrenden Muster, die wir bei fehlschlagenden Technologie-Beschaffungsentscheidungen sehen. Kritische Anti-Patterns sind organisatorische Versäumnisse, die Governance-Änderungen erfordern. Hohe Anti-Patterns sind analytische Versäumnisse, die ein Rahmen verhindern kann. Mittlere Anti-Patterns sind kognitive Verzerrungen, die Bewusstsein abmildern kann.
| # | Anti-Pattern | Schweregrad | Was passiert |
|---|---|---|---|
| 1 | Das Not-Invented-Here-Syndrom | Kritisch | Bauen, weil „wir unser Geschäft am besten kennen“, ohne Marktalternativen zu bewerten. Engineering-Teams neigen standardmäßig zum Bauen, weil sie das tun. Ohne eine strukturierte Bewertungsstufe gewinnt die Build-Option durch Trägheit, nicht durch Analyse. |
| 2 | Die Demo-Falle | Hoch | Sich für den Kauf auf Basis einer geschliffenen Anbieter-Demo ohne domänenspezifischen PoC entscheiden. Anbieter investieren stark in Demo-Szenarien, die Best-Case-Leistung zeigen. Ihre Produktionslast, Datenqualität und Integrationsanforderungen werden Probleme aufdecken, die Demos verbergen. |
| 3 | Das Divisions-Lehen | Kritisch | Jede Einheit trifft unabhängige Build/Buy-Entscheidungen ohne portfolioübergreifende Sichtbarkeit. Ohne ein zentrales Technologie-Investitionsgremium wird dasselbe Problem fünfmal zum fünffachen Preis gelöst. Commonalization-Chancen sind unsichtbar, wenn Entscheidungen in Silos getroffen werden. |
| 4 | Die TCO-Amnesie | Hoch | Die Build-Kosten (nur Jahr 1) mit der Anbieterlizenz (jährlich) vergleichen — und die 5-Jahres-Summe ignorieren. Build-Kosten sind vorlastig, aber Wartung, Talentbindung und Infrastruktur kumulieren jährlich. Ein fairer Vergleich erfordert ein vollständiges Modell über mindestens 5 Jahre. |
| 5 | Der Sunk-Cost-Fehlschluss | Hoch | Weiterbauen, weil „wir bereits 2 Mio. € investiert haben“, obwohl Kaufen künftig günstiger wäre. Vergangene Ausgaben sind für die zukunftsgerichtete Entscheidung irrelevant. Die Frage ist: Was ist der günstigste Weg von heute zu einer funktionierenden Lösung in 3 Jahren? |
| 6 | Die Lock-in-Panik | Mittel | Alle Anbieterlösungen aus Angst vor Lock-in meiden, selbst wenn die Build-Kosten 5-mal höher sind. Das Lock-in-Risiko ist real, aber quantifizierbar. Ein Ausstiegskostenposten von 200 K€ ist beherrschbar; ein Build-Aufschlag von 2 Mio. €, um ihn zu vermeiden, ist es nicht. Bepreisen Sie das Lock-in-Risiko, behandeln Sie es nicht als binär. |
| 7 | Das Innovationstheater | Mittel | Maßgeschneiderte Lösungen bauen, um innovativ zu wirken, obwohl Standardtools schneller liefern würden. Die Führung belohnt sichtbaren Engineering-Aufwand statt langweiliger, aber effektiver Anbieterimplementierungen. Das Ergebnis sind überkonstruierte interne Tools, die das 3-Fache kosten und 6 Monate zu spät liefern. |
| 8 | Der Plattform-Optimismus | Hoch | „Wir bauen eine Plattform, die alle bedient“, ohne einheitenübergreifende Anforderungen zu validieren. Interne Plattformprojekte, die versuchen, alle Divisionen gleichzeitig zu bedienen, scheitern in 70 % der Fälle. Beginnen Sie mit 2 Einheiten, beweisen Sie den Wert, dann erweitern Sie. |
| 9 | Die Kompetenz-Fata-Morgana | Mittel | Annehmen, dass das aktuelle Team bauen und warten kann, ohne den langfristigen Talentbedarf zu bewerten. Bauen ist ein 1-Jahres-Projekt. Warten ist eine 10-Jahres-Verpflichtung. Teams, die v1 bauen können, schaffen es oft nicht, die Talente zu binden, um das System zu warten und weiterzuentwickeln. |
| 10 | Das Governance-Vakuum | Kritisch | Keine formalen Entscheidungsrechte, keine Commonalization-Stufe, Entscheidungen von demjenigen, der am lautesten ruft. Ohne ein Technology Investment Board und definierte Schwellenwerte sind Technologie-Beschaffungsentscheidungen politisch, nicht analytisch. Dies ist die Grundursache der anderen 9 Anti-Patterns. |
Organisatorische Versäumnisse, die Governance-Änderungen erfordern. Sie lassen sich nicht durch eine bessere Tabelle lösen.
Analytische Versäumnisse, die ein strukturierter Rahmen verhindert. Das 6-Dimensionen-Modell beseitigt sie.
Kognitive Verzerrungen, die Bewusstsein abmildern kann. Schulung und Entscheidungs-Checklisten reduzieren das Auftreten.
Ein Rahmen ohne Governance ist eine Empfehlung. Governance ohne Durchsetzung ist Theater. Die Organisationen, die das 4,2-Mio.-€-Divergenzmuster vermeiden, haben vier Dinge etabliert: ein Technology Investment Board, eine verpflichtende Commonalization-Bewertung, Entscheidungsstufen an Ausgabenschwellen und eine jährliche Portfolioprüfung.
| Investitionshöhe | Entscheidungsbefugnis | Erforderliche Artefakte | Prüfprozess |
|---|---|---|---|
| < 100 K€ | Divisions-CTO | Commonalization-Checkliste (selbstzertifiziert) | Im Portfolio-Tracker protokolliert |
| 100 K€ – 500 K€ | Divisions-CTO + Architekturprüfung Konzern | Vollständige Commonalization-Bewertung + TCO-Modell (3 Jahre) | Freigabe des Architekturgremiums erforderlich |
| 500 K€ – 1 Mio. € | Technology Investment Board | 6-Dimensionen-Scoring + Anbieter-Shortlist + PoC-Plan | TIB-Abstimmung mit einheitenübergreifender Vertretung |
| > 1 Mio. € | Technology Investment Board + CFO | Vollständiger Business Case + 5-Jahres-TCO + Risikobewertung + Ausstiegsplan | Freigabe auf Vorstandsebene mit vierteljährlichen Fortschrittsstufen |
Bevor eine Build-Entscheidung genehmigt wird, muss die anfragende Einheit die Commonalization-Bewertung ausfüllen und einreichen. Dies ist die wirksamste einzelne Governance-Kontrolle.
Einmal pro Jahr prüft das TIB alle größeren Technologieinvestitionen, um neue Konsolidierungschancen zu identifizieren. Märkte ändern sich, Einheiten entwickeln sich, und neue Commonalization-Wege entstehen.
6-monatiger Prozess • 5 Geschäftseinheiten bewertet • 4 auf eine einzige Plattform konsolidiert
Ein europäischer Industrie-OEM mit 5 Geschäftseinheiten stellte fest, dass 4 davon unabhängig voneinander unterschiedliche Lösungen für denselben Fertigungsausführungs-Workflow gebaut oder gekauft hatten. Gesamtausgaben: 6,8 Mio. € im Konzern. Nach Einführung eines strukturierten Make/Buy-Rahmens mit verpflichtender Commonalization-Bewertung konsolidierte man auf eine einzige Plattform für 4 Einheiten, senkte die jährlichen IT-Ausgaben um 1,2 Mio. € und reduzierte die Integrationswartung von 12 FTEs auf 4.
Die konsolidierte Plattform ging für 2 Einheiten innerhalb von 6 Monaten und für alle 4 innerhalb von 12 Monaten in Betrieb. Die 5. Einheit hatte einen wirklich einzigartigen Workflow (18/50 in der Commonalization-Bewertung) und wurde zu Recht auf ihrer bestehenden Lösung belassen. Die zentrale Erkenntnis: Der Rahmen erzwang keine Standardisierung — er offenbarte, wo Standardisierung gerechtfertigt war und wo nicht.
Das während dieses Projekts etablierte Technology Investment Board verhinderte in seinem ersten Betriebsjahr 3 weitere doppelte Technologieanschaffungen. Gesamteinsparungen des ersten Jahres allein durch die Governance-Änderung: 1,8 Mio. € (Konsolidierungseinsparungen + verhinderte Doppelungen).
Zentrale Lektion: Die Commonalization-Bewertung war der entscheidende Faktor. Ohne sie hätte die Scoring-Matrix für jede Einheit isoliert eine andere Antwort hervorgebracht. Die einheitenübergreifende Sicht verschob die Entscheidung von „für eine bauen“ zu „für alle kaufen“ — ein grundlegend anderes und grundlegend besseres Ergebnis.
Die Entscheidung ist der Anfang, nicht das Ende. Technologieinvestitionen verfallen ohne aktives Monitoring. Die Teams mit den besten Ergebnissen verfolgen TCO-Abweichung, Adoptionsraten und Commonalization-Werte mit derselben Strenge, die sie auf Produktmetriken anwenden.
| Metrik | Ziel | Messung | Eskalationsauslöser |
|---|---|---|---|
| TCO-Abweichung | Innerhalb von 15 % des genehmigten Modells | Vierteljährlicher Vergleich von Ist- vs. Plankosten | Prüfen, wenn die Abweichung 2 aufeinanderfolgende Quartale über 20 % liegt |
| Adoptionsrate | ≥ 80 % der Zieleinheiten innerhalb von 12 Monaten | Deployment-Tracking auf Einheitsebene und Zahl aktiver Nutzer | Eskalieren, wenn die Adoption nach 6 Monaten unter 50 % stagniert |
| Commonalization-Wert | ≥ 70 % gemeinsame Komponenten über Einheiten hinweg | Verhältnis gemeinsamer vs. einheitenspezifischer Module/Konfigurationen | Architekturprüfung, wenn die Anpassung 40 % der Codebasis übersteigt |
| Einhaltung des Anbieter-SLA | ≥ 99,5 % Verfügbarkeit, Reaktionszeiten gemäß Vertrag | Monatliche Anbieter-Scorecard mit automatisiertem Monitoring | Formale Anbieterprüfung, wenn im Quartal ein kritisches SLA verfehlt wird |
| Build-Qualität (falls gebaut) | < 5 P1-Vorfälle pro Quartal | Vorfall-Tracking, mittlere Lösungsdauer, Deployment-Frequenz | Build-Entscheidung prüfen, wenn Vorfälle das 3-Fache des Branchen-Benchmarks übersteigen |
| Jährliche Portfolioprüfung | Alle 12 Monate durchgeführt | Alle größeren Technologieinvestitionen gegen den aktuellen Markt neu bewerten | Konsolidierungsprüfung auslösen, wenn neue Commonalization-Chancen gefunden werden |
Diese Signale weisen darauf hin, dass die ursprüngliche Entscheidung möglicherweise zu überdenken ist. Warten Sie nicht auf eine Krise — der Sunk-Cost-Fehlschluss ist der Feind einer guten Kurskorrektur.
Wenn das Monitoring zeigt, dass die ursprüngliche Entscheidung nicht mehr optimal ist, folgen Sie diesem Protokoll. Das Ziel ist nicht, Schuld zuzuweisen — sondern die zukunftsgerichteten Kosten zu minimieren. Die versunkenen Kosten sind irrelevant.
Ich unterstütze CTOs und CIOs in Industrieunternehmen bei strukturierten Make/Buy-Bewertungen — von der Commonalization-Bewertung über die TCO-Modellierung bis hin zum Governance-Design und der Anbieterauswahl. Sie erhalten einen objektiven Rahmen und jemanden, der dieselben teuren Fehler in Dutzenden von Organisationen mit mehreren Einheiten gesehen hat.