LetsChangeTogether

Was dieses Modell auszeichnet

1. 1

   Inform Layer als Single Source of Technical Truth

   Persistente, zeitlich konsistente technische Zustandsebene, bevor finanzielle Interpretation beginnt — verhindert konkurrierende Kostenwahrheiten. Startpunkt ist nicht die Abrechnung, sondern die rekonstruierbare Betriebsrealität.

2. 2

   Trennung von Beobachtung, Interpretation und Entscheidung

   Klare Phasen Inform → Optimize → Govern/Execute. Beobachtung, Bewertung und Steuerung bleiben getrennt — revisionsfreundlich und ohne Vermischung mit toolgetriebener Direktoptimierung.

3. 3

   Multi-Perspektiven-Modell ohne Konflikt

   Engineering, Produkt, Finance, Beschaffung und Leadership lesen dieselbe technische Realität mit unterschiedlichen Aggregationslogiken — eine Datenbasis, keine konkurrierenden Wahrheiten.

4. 4

   Remanenzkosten & hybride Realität

   Explizite Modellierung langer Hybrid-Phasen: Cloud-Migration kann kurzfristig teurer werden, On-Prem- und Cloud-Logiken müssen gemeinsam steuerbar bleiben — nicht cloud-zentriert vereinfacht.

5. 5

   Ex-post-Steuerung statt nur ex-ante Business Cases

   Der wirtschaftliche Wert von Plattformentscheidungen entsteht im Betrieb. Systematische Rückkopplung aus Ist-Kosten und technischen Zuständen — nicht nur Investitionsfreigaben vor Go-Live.

6. 6

   Rollenklarheit inklusive Negativabgrenzung

   Definiert, wofür jede Perspektive zuständig ist — und ausdrücklich, wofür nicht. Reduziert Grabenkämpfe zwischen Technik, Produkt und Finance in der Praxis.

7. 7

   Governance- und regulierungstauglich

   Von Grund auf revisionssicher, nachvollziehbar und in bestehende Gremien- und Controlling-Strukturen integrierbar — nicht operativ oder tool-lastig für regulierte Umfelder.

Was dieses Modell auszeichnet

1. 1

   Phasenbasierte, risikominimierte Einführung

   Crawl – Walk – Run statt Big-Bang: schnelle sichtbare Wertschöpfung, kontrollierte Skalierung und nachhaltige Verankerung in Organisation und Architektur.

2. 2

   Föderales Governance-Modell (Hub & Spoke)

   Zentrale Policy-Leitplanken und Standards mit dezentraler Umsetzung — Dezentralität bleibt handlungsfähig, konzernweite Steuerung wird möglich.

3. 3

   Datenarchitektur vor Tool-Einsatz

   Process before Tool: konsolidierte Datenbasis, Showback und Chargeback auf belastbarer Architektur — nicht toolgetriebene Insellösungen.

4. 4

   Service-Level-TCO als Entscheidungsgrundlage

   Pilotbasierte TCO-Modellierung auf Service-Ebene für vergleichbare Kostenwahrheit und fundierte Make-or-Buy- sowie Architekturentscheidungen.

5. 5

   Politische Durchsetzbarkeit in dezentralen Einheiten

   Roadmap mit klaren Meilensteinen, Unit Economics und Commitment-Strategien — Akzeptanz in den Sparten bleibt Teil des Designs.

Was dieses Modell auszeichnet

1. 1

   Inform Layer statt reiner Cost Visibility

   Rekonstruktion eines zeitlich stabilen technischen Zustandsbildes aus Quellsystemen — nicht nur Abrechnungsdaten, sondern Fakten zu Speicherklassen, DICOM-Lebenszyklen und Compute.

2. 2

   Klinische Datenflüsse end-to-end

   Röntgen → PACS → HL7/FHIR → SAP IS-H → Speicherklassen (Hot/Cool/Archive) und KI-Auswertung — FinOps folgt dem tatsächlichen Nutzungsverhalten.

3. 3

   Multi-Perspektiven ohne konkurrierende Wahrheiten

   Engineering, Radiologie/Klinik, Controlling und Einkauf lesen dieselbe technische Realität — mit jeweils passender Aggregation und Interpretation.

4. 4

   Regulatorik und SAP-Verzahnung

   Lange Aufbewahrungsfristen, klinische Rechtfertigung von Kosten und enge Kopplung an SAP-basierte Prozesse sind Teil des Modells — nicht nachträglicher Sonderfall.

5. 5

   Steuerung statt Kostensenkungsprogramm

   Fundierte Entscheidungen zu Architektur, Speicherstrategien und Cloud-Diensten auf belastbarer Datenbasis — unter klinischen und regulatorischen Rahmenbedingungen.

Was dieses Modell auszeichnet

1. 1

   Delivery ≠ Operations

   CI/CD schafft Reproduzierbarkeit — Application Operations trägt Betrieb, Beobachtung und Eingriffsentscheidungen. Klare Trennung reduziert Verantwortungsdiffusion.

2. 2

   Observability als Kontrollsystem

   Nicht passive Überwachung: Rekonstruktion des Systemzustands und steuerungsrelevante Entscheidungen aus technischen, anwendungs- und geschäftsspezifischen Signalen.

3. 3

   Separation of Duties auf Plattformebene

   Kubernetes-Schnittstellen (Namespaces, RBAC, Policy Controller) ermöglichen technische Verantwortungsgrenzen — einheitliche Pipeline, unterschiedliches Risikoprofil.

4. 4

   Signal-Zusammenspiel statt Einzelmetriken

   In marktkritischen Systemen entscheidet die zeitliche Korrelation mehrerer Signale — ob Abweichungen technisch, geschäftlich oder regulatorisch relevant sind.

5. 5

   Risikobegrenzung vor reiner Automatisierung

   Praxisnahe Eskalation bei Konfigurationsänderungen: operative Urteilskraft für Rollback, Scale-up oder Intervention — nicht Pipeline-Logs allein.