Thema 1.1 — Das Betriebsmodell

In einem Satz: Ein Zielbetriebsmodell (Target Operating Model, TOM) ist die bewusste Gestaltung, wie die Strategie Ihrer Organisation durch Wertströme, Fähigkeiten, Teams, Governance, Technologie, Daten und Lieferanten fließt, um Ergebnisse der digitalen Gesundheit und Pflege zu liefern – und seine richtige Form entscheidet darüber, ob alles Nachgelagerte schnell und sicher oder langsam und brüchig ist.

Warum das in Gesundheit und Pflege wichtig ist#

Die meisten Organisationen der digitalen Gesundheit scheitern nicht an fehlendem Talent oder fehlender Technologie, sondern daran, dass ihr Betriebsmodell gegen sie arbeitet. Finanzierung ist an zeitlich begrenzte Projekte gebunden, Entscheidungsrechte sind unklar, und jedes Team baut dieselbe Login-, Integrations- und Audit-Infrastruktur neu. Das Ergebnis sind doppelte Kosten auf öffentliche Rechnung, uneinheitliche klinische Sicherheit und Services, die über ein Integrated Care System (ICS) hinweg keine Daten teilen können.

Ein Betriebsmodell ist in diesem Bereich besonders, weil es konkurrierende Güter in Einklang bringen muss. Es muss föderiert genug sein, um die Autonomie souveräner Organisationen – Trusts, Kommunalverwaltungen, Hausarztpraxen – zu achten, und zugleich kohärent genug, um Patientinnen und Patienten über sie hinweg ein sicheres Erlebnis zu bieten. Es muss Betrieb (klinische Systeme sicher verfügbar halten) gegen Veränderung (sie verbessern) abwägen, wenn Ausfallzeiten die Versorgung beeinträchtigen können. Und es muss verhältnismäßig ausgeben: Absicherung schwer genug für öffentliche Rechenschaft und klinische Sicherheit, leicht genug, um Iteration nicht zu ersticken. Im TOM werden diese Zielkonflikte explizit gemacht, statt dem Zufall überlassen zu werden.

Kernkonzepte#

Die Schichten eines Betriebsmodells. Ein brauchbares TOM ist ein Stapel, in dem jede Schicht der darüberliegenden dient:

• Strategie und Ergebnisse — die messbaren Bevölkerungs- und Serviceergebnisse, die zu verbessern Sie existieren (oft als OKRs ausgedrückt; siehe Thema 1.3 — Evidenzbasierte Entscheidungen).
• Wertströme — die durchgängigen Abläufe, die Nutzenden Wert liefern, z. B. „Patientin überweisen, sichten und behandeln“ – organisiert entlang der Reise der Bürgerinnen und Bürger, nicht entlang des Organigramms.
• Fähigkeiten — das, was Sie können müssen (Identität, Terminbuchung, klinische Dokumentation, Analytik). Fähigkeiten bleiben stabil, auch wenn sich Lösungen ändern.
• Teams — die Menschen, die organisiert sind, um Fähigkeiten und Wertströme zu liefern (siehe Team Topologies unten).
• Governance und Entscheidungsrechte — wer was entscheidet und wie Absicherung angewandt wird.
• Technologie und Daten — die Plattformen, Standards und Datenarchitektur, auf denen die Teams bauen.
• Lieferanten — der Markt, bei dem Sie einkaufen, und wie Sie ihn steuern.

Ein Entwurf von oben nach unten (Strategie → Wertströme → Fähigkeiten) hält Teams und Technologie an Ergebnissen statt an Altstrukturen ausgerichtet.

Zentralisierte, föderierte und Plattformmodelle. Ein zentralisiertes Modell bündelt die Lieferung in einem Team oder einer bundesnahen Stelle: konsistent und günstig zu standardisieren, aber ein Engpass und oft fern vom lokalen Bedarf. Ein föderiertes Modell überträgt die Lieferung an Trusts und Orte: reaktionsschnell und lokal verantwortet, aber anfällig für Duplizierung und Auseinanderdriften. Ein Plattformmodell ist das versöhnende Muster: Ein zentrales Team stellt gemeinsame, wiederverwendbare Fähigkeiten (Identität, Interoperabilität, Hosting, Designsystem) als Plattform bereit, und föderierte Teams bauen zügig darauf auf. Die meisten reifen Gesundheitssysteme laufen auf „Plattform plus Föderation“ zu.

Team Topologies. Dieses Rahmenwerk benennt vier Teamtypen – Stream-aligned (verantwortet einen Wertstrom), Platform (stellt Self-Service-Fähigkeiten bereit), Enabling (coacht andere in einer Fähigkeit) und Complicated-Subsystem (tiefe Spezialarbeit, etwa an einem Algorithmus) – und betont reibungsarme Interaktion zwischen ihnen. Es lässt sich sauber auf das Plattformmodell abbilden: Plattformteams senken die kognitive Last der Stream-aligned-Teams, damit diese sich auf Nutzer- und klinischen Wert konzentrieren können.

Betrieb vs. Veränderung. Betrieb heißt, Live-Services sicher und verfügbar zu halten; Veränderung heißt, sie zu verbessern oder zu bauen. Produktteams, die einen Service sowohl bauen als auch betreiben („you build it, you run it“), schließen die Rückkopplungsschleife und verbessern die Sicherheit, aber das Gleichgewicht muss ehrlich finanziert werden – den Betrieb auszuhungern, um Veränderung zu finanzieren, ist der Weg, auf dem klinische Systeme verfallen.

Die dünnste tragfähige Plattform (Thinnest Viable Platform, TVP). Aus Team Topologies: Eine Plattform sollte die kleinstmögliche Menge gemeinsamer Services sein, die die Reibung für Stream-Teams tatsächlich verringert – nicht mehr. Eine überbaute Plattform wird zum eigenen Engpass und zum eigenen Altsystem. Beginnen Sie mit den wenigen Fähigkeiten, die jedes Team wirklich braucht (Authentifizierung, eine Interoperabilitätsschicht, Hosting, ein Designsystem), und wachsen Sie nur bei belegtem Bedarf.

Bewährte Praktiken#

1. Entwerfen Sie das Modell von den Ergebnissen abwärts, nicht vom Organigramm aufwärts. Beginnen Sie mit den Bevölkerungs- und Serviceergebnissen, die Sie bewegen müssen, leiten Sie die Wertströme ab, die sie liefern, und entwerfen Sie erst dann Teams und Technologie. Ein TOM, das in der bestehenden Hierarchie verankert ist, automatisiert nur die heutigen Silos.

2. Übernehmen Sie die Form „Plattform plus Föderation“. Stellen Sie gemeinsame Fähigkeiten zentral als Self-Service-Plattform bereit und lassen Sie Stream-aligned-Teams in Trusts und Orten darauf aufbauen. Das gibt Ihnen nationale Konsistenz bei Sicherheit und Interoperabilität mit lokaler Geschwindigkeit und Eigenverantwortung – der Ausgleich, den der Bereich verlangt.

3. Finanzieren Sie Produkte, nicht Projekte. Verlagern Sie Geld von zeitlich begrenzten Projekten zu dauerhaft finanzierten Produktteams, die an Wertströmen ausgerichtet sind. Projektfinanzierung zwingt Teams, sich genau dann aufzulösen, wenn sie den Fachbereich gelernt haben; Produktfinanzierung erhält das Sicherheitswissen und die Iteration, die Gesundheitsleistungen brauchen (siehe Thema 5.0 — Produktgeführte Arbeit).

4. Gestalten Sie die Ausgabenkontrolle verhältnismäßig und gestuft. Nutzen Sie gestufte, an Evidenz geknüpfte Finanzierung – geben Sie Geld an den Toren Discovery, Alpha, Beta und Live frei, statt ein ganzes Programm im Voraus zu genehmigen. Ausgabenkontrollen im Stil des GDS und der NHS-Assurance-Weg sollen große versunkene Kosten für unbewiesene Ideen verhindern; wenden Sie sie als nach Risiko und Wert skalierte Schwellen an, nicht als pauschale Bürokratie.

5. Machen Sie Entscheidungsrechte mit einer RACI- oder RAPID-Karte explizit. Unklare Befugnisse sind die häufigste Ursache stockender Lieferung. Benennen Sie für jede bedeutende Entscheidungsart, wer verantwortlich (Responsible)/rechenschaftspflichtig (Accountable)/zu konsultieren (Consulted)/zu informieren (Informed) ist (RACI) oder wer empfiehlt (Recommend), zustimmt (Agree), ausführt (Perform), Input gibt (Input) und entscheidet (Decide) (RAPID). Veröffentlichen Sie sie, damit Teams aufhören, Entscheidungen zu eskalieren, die sie treffen dürfen.

6. Halten Sie die Plattform dünn und bedarfsgetrieben. Bauen Sie gemeinsame Fähigkeiten nur, wenn zwei oder mehr Teams nachweislich dasselbe brauchen, und behandeln Sie die Plattform als Produkt mit eigenen Nutzenden (den internen Teams). Widerstehen Sie dem Drang, eine große Plattform vorab zu bauen; die dünnste tragfähige Plattform verdient sich ihren Umfang durch Annahme.

7. Steuern Sie Lieferanten als Teil des Modells, nicht außerhalb. Entscheiden Sie bewusst, welche Fähigkeiten strategisch (bauen/besitzen) und welche Standardware (kaufen) sind, vermeiden Sie Lock-in bei einem einzigen Lieferanten für klinische Kerndaten und verlangen Sie in Verträgen offene Standards und Ausstiegsrechte. Ihre Lieferanten sind eine Schicht Ihres Betriebsmodells, und ihre Arbeitsweisen müssen mit Ihren vereinbar sein.

8. Machen Sie Entscheidungsrechte explizit. Ein Betriebsmodell funktioniert nur, wenn die Menschen wissen, wer was entscheidet – welche Entscheidungen bei einem Produktteam liegen, welche bei einer Instanz für klinische Sicherheit und welche einen Vorstand erreichen müssen. Kartieren Sie Entscheidungsrechte und schieben Sie jede Entscheidung auf die niedrigste Ebene, die sie sicher tragen kann, damit die Lieferung nicht durch unnötige Eskalation gedrosselt wird. Unklare Befugnisse sind eine der häufigsten Ursachen langsamer, defensiver Lieferung.

9. Behandeln Sie das Betriebsmodell als Produkt, das Sie weiterentwickeln. Ein Zielbetriebsmodell wird nicht einmal festgelegt und an die Wand gerahmt; prüfen Sie es, wenn sich Nachfrage, Technologie und Partnerschaften ändern, und passen Sie es anhand von Evidenz an. Beobachten Sie wenige Signale – Arbeitsfluss, Zeit bis zur Entscheidung, Nacharbeit und Teamgesundheit – und ändern Sie Strukturen, wenn sie nachweislich im Weg stehen, nicht als Reaktion auf Reorganisationsmoden.

Fragen zur Diskussion im Team#

1. Ist unser Betriebsmodell von Ergebnissen und Wertströmen abwärts entworfen, oder hat es einfach unser bestehendes Organigramm und seine Silos automatisiert? Diese Frage zielt auf die zentrale Warnung des Themas, dass ein in der aktuellen Hierarchie verankertes TOM nur die Silos verfestigt, die Sie bereits haben; sie gehört daher auf den Tisch, bevor irgendeine Reorganisation beginnt. Sie ist im Kontext von Gesundheit und Pflege wichtig, weil Wertströme der Reise der Bürgerinnen und Bürger – überweisen, sichten, behandeln – über souveräne Organisationen hinweg folgen, während Organigramme institutionellen Grenzen folgen, und ein auf Letzteren gebautes Modell weiter fragmentierte, nicht interoperable Services auf öffentliche Rechnung hervorbringt. Die Spannung, die ehrlich zu debattieren ist: Ein Entwurf von den Ergebnissen abwärts ist tatsächlich einschneidend, denn er schneidet durch Abteilungsverantwortung, Budgets und Berichtslinien, um die herum leitende Personen ihre Karrieren aufgebaut haben; es gibt also echte politische Kosten, es richtig zu tun. Prüfen Sie sich konkret, indem Sie Ihre drei wichtigsten Ergebnisse benennen und nachzeichnen, ob Ihre tatsächlichen Teamgrenzen und Finanzierungslinien diesen Wertströmen oder den Abteilungen folgen; wenn Teams sauber auf Abteilungen abgebildet sind, ist das Ihre Antwort. Eine gute, ehrliche Antwort räumt ein, wo das Modell organigrammförmig ist, benennt mindestens einen Wertstrom, der derzeit zu seinem Nachteil über Silos zerteilt ist, und ist realistisch, welche Strukturgrenzen die Organisation neu ziehen will.

2. Was gehört in unsere dünnste tragfähige Plattform, und wie verhindern wir, dass sie entweder zu einem Engpass überbaut oder so unterbaut wird, dass jedes Team dieselbe Infrastruktur neu baut? Die Form „Plattform plus Föderation“ funktioniert nur, wenn die Plattform dünn und bedarfsgetrieben bleibt, und diese Frage lässt das Team beiden vom Thema benannten Fehlerbildern begegnen – der großen Plattform, die zum eigenen Altsystem-Engpass wird, und dem Fehlen, das jedes Team zwingt, Login, Integration und Audit neu zu bauen. Sie ist wichtig, weil die Plattform in einem ICS faktisch gemeinsame Infrastruktur ist (Identität, eine FHIR-Interoperabilitätsschicht, Hosting mit Sicherheits-Baselines, ein Designsystem) und ein falscher Zuschnitt entweder Kosten oder Reibung über jedes Stream-Team hinweg vervielfacht. Der Zielkonflikt betrifft Zeitpunkt und Evidenz: Bauen Sie zu früh, raten Sie falsch und schaffen einen Engpass; bauen Sie zu spät, ist die Duplizierung bereits verhärtet – daher ist der Test „zwei oder mehr Teams brauchen nachweislich dasselbe“ der Kern, und das Team sollte prüfen, ob es ihn tatsächlich anwendet oder nur baut, was offensichtlich zentral erscheint. Schauen Sie, was Sie derzeit als Plattform behandeln und was Teams neu bauen, und fragen Sie, ob die Plattform als Produkt mit eigenen internen Nutzenden und SLAs betrieben wird oder als Warteschlange, hinter der sich alle anstellen. Eine ehrliche Antwort benennt die konkreten Fähigkeiten, die heute den Zwei-Team-Test bestehen, widersteht der Versuchung, den Rest vorab zu bauen, und verpflichtet sich, die internen Nutzenden des Plattformteams als echte Kunden mit echten Service-Levels zu behandeln.

3. Wo sind unsere Entscheidungsrechte tatsächlich unklar, und was eskalieren Teams heute, das sie selbst entscheiden dürfen sollten? Unklare Befugnisse werden als häufigste Ursache stockender Lieferung genannt; diese Frage bringt daher die alltägliche Reibung ans Licht, die eine veröffentlichte RACI- oder RAPID-Karte beseitigen soll. Sie ist in einem föderierten Gesundheitssystem besonders wichtig, wo Ortsteams, ein ICS-Digitalgremium, klinische Sicherheit und Informationsgovernance alle legitime Ansprüche auf eine Entscheidung haben und unklare Grenzen bedeuten, dass entweder alles eskaliert oder – schlimmer – niemand eine Entscheidung verantwortet, bis etwas schiefgeht. Die Spannung, die es zu erkunden lohnt: Das Delegieren von Entscheidungen erfordert Vertrauen in Teams innerhalb von Leitplanken, dem sich leitende Personen und Gremien gerade dort oft widersetzen, wo klinische Sicherheit oder öffentliches Geld berührt sind – doch gerade das Vorenthalten dieses Vertrauens erzeugt den Eskalationsstau. Machen Sie es konkret, indem Sie die letzten fünf eskalierten Entscheidungen auflisten und für jede fragen, wer hätte entscheiden sollen und welche Leitplanke es ihm ermöglicht hätte; das Muster offenbart meist wenige wiederkehrende unklare Entscheidungsarten. Eine gute Antwort liefert eine konkrete, veröffentlichbare Aussage, wer was entscheidet – mit Unterscheidung zwischen Plattformstandards, Servicedesign und Freigabe der klinischen Sicherheit – und ist ehrlich, welche Entscheidungen die Organisation wirklich delegieren will und welche sie zentral behält und warum.

4. Finanzieren wir Betrieb und Veränderung ehrlich, oder hungern wir im Stillen den Betrieb von Live-Services aus, um neue Funktionen zu bezahlen? Das Thema ist unmissverständlich, dass das Aushungern des Betriebs zugunsten der Veränderung klinische Systeme verfallen lässt; diese Frage bringt das Gleichgewicht ans Licht, bevor ein Ausfall oder Sicherheitsvorfall es für Sie tut. In Gesundheit und Pflege ist sie wichtig, weil „Betrieb“ kein Backoffice-Overhead ist, sondern die Verfügbarkeit der Systeme, auf die sich Klinikpersonal am Behandlungsort verlässt; ein verkümmertes Betriebsbudget zeigt sich also als Ausfallzeit, die Patientinnen und Patienten betreffen kann, nicht bloß verärgerte Nutzende. Der Zielkonflikt ist unbequem, weil Veränderung sichtbar ist und gefeiert wird, während Betrieb unsichtbar bleibt, bis er versagt; Gremien und Roadmaps neigen daher naturgemäß zum Neuen. Ein Modell „you build it, you run it“ hilft, indem es die Rückkopplungsschleife geschlossen hält, aber nur, wenn die Betriebszeit des Teams wirklich geschützt ist, statt nominell zugewiesen und dann geplündert zu werden. Machen Sie es konkret, indem Sie schauen, welcher Anteil der Kapazität jedes Produktteams im letzten Quartal tatsächlich darauf entfiel, Services sicher und verfügbar zu halten, verglichen mit der Planung, und ob Betriebsarbeit erfasst und wertgeschätzt oder als Unterbrechung behandelt wird. Eine ehrliche Antwort benennt, wo der Betrieb heute unterfinanziert ist, schützt eine realistische Betriebszuweisung als erste Belastung statt als Rest und ist offen, welche Live-Services angesammeltes betriebliches Risiko tragen.

5. Welche Fähigkeiten entscheiden wir uns bewusst zu bauen und zu besitzen, und welche zu kaufen, und nehmen wir bei klinischen Kerndaten ungewollt einen Lock-in in Kauf? Bewährte Praxis ist, Bauen versus Kaufen bewusst zu entscheiden, Lock-in bei einem einzigen Lieferanten für klinische Kerndaten zu vermeiden und Lieferanten als Schicht des Betriebsmodells statt als etwas außerhalb zu behandeln – diese Frage prüft, ob diese Entscheidungen tatsächlich getroffen werden oder nur so geschehen. Sie ist wichtig, weil in der digitalen Gesundheit der folgenreichste Lock-in die Patientenakte und ihre Daten betrifft, wo ein proprietärer Speicher ohne realistischen Ausstieg ein ganzes System ein Jahrzehnt lang festsetzen und diktieren kann, was jeder nachgelagerte Service tun kann. Die Spannung ist Geschwindigkeit versus Optionalität: Kaufen ist heute schneller und oft billiger, gerade für ein überlastetes Team, aber jeder bequeme Kauf ohne offene Standards oder Ausstiegsrechte engt still die Wahl von morgen ein, und die Kosten werden erst sichtbar, wenn Sie gehen wollen. Machen Sie es konkret, indem Sie Ihre Kernfähigkeiten auflisten, jede als strategisch (bauen/besitzen) oder Standardware (kaufen) markieren und prüfen, ob die Verträge hinter den Standardwaren-Fähigkeiten tatsächlich offene Standards (HL7 FHIR, SNOMED CT) und durchsetzbare Ausstiegsrechte verlangen. Eine gute Antwort unterscheidet die wenigen wirklich strategischen Fähigkeiten von den vielen, die sich gefahrlos kaufen lassen, ist ehrlich, wo die Organisation bei klinischen Daten bereits gebunden ist, und verpflichtet sich in den wichtigsten Verträgen zu offenen Standards und Ausstiegsrechten.

6. Woran erkennen wir, dass unser Betriebsmodell sich ändern muss, und welche Signale würden es uns sagen – statt aus Mode oder wegen der Ankunft einer neuen Führungskraft zu reorganisieren? Das Thema fasst das Betriebsmodell als Produkt auf, das man anhand von Evidenz weiterentwickelt, nicht als Diagramm an der Wand; diese Frage bittet das Team daher, im Voraus zu definieren, welche Evidenz eine Umgestaltung rechtfertigen würde. Sie ist in Gesundheit und Pflege wichtig, weil Reorganisation störend und teuer ist – sie löst hart erarbeitetes Fach- und klinisches Sicherheitswissen auf –, der Sektor aber zu Strukturfluktuation neigt, die von politischen Zyklen und Neubesetzungen getrieben ist statt davon, ob das aktuelle Modell tatsächlich im Weg steht. Die Spannung liegt zwischen Stabilität und Anpassung: Ändern Sie das Modell zu bereitwillig, lassen Sie Teams nie zur Ruhe kommen oder Sicherheitsexpertise aufbauen; ändern Sie es zu selten, drosseln verkrustete Strukturen den Fluss lange, nachdem sie nicht mehr zur Arbeit passen. Machen Sie es konkret, indem Sie eine kleine Menge Signale zur Beobachtung wählen – Arbeitsfluss, Zeit bis zur Entscheidung, Nacharbeit und Teamgesundheit – und vereinbaren, welche Bewegung darin eine bewusste Umgestaltung statt einer kleineren Anpassung auslösen würde. Eine ehrliche Antwort legt sich auf wenige Frühindikatoren fest, unterscheidet evidenzgeleiteten Wandel von Reorganisationstheater und ist klar, wer dafür rechenschaftspflichtig ist, das Modell zu prüfen und zu handeln, wenn die Signale sagen, dass es die Lieferung behindert.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein ICS, das fünf Orte umfasst, lässt jeden Trust eigene patientenorientierte Terminwerkzeuge bauen. Kosten verdoppeln sich, Erlebnisse driften auseinander, und keines teilt Daten sauber. Das ICS gestaltet sein Betriebsmodell neu.

Es definiert drei Ergebnisse (Nichterscheinen verringern, vermeidbare Einweisungen senken, Zugangsgerechtigkeit verbessern) und die dahinterstehenden Wertströme. Es stellt ein kleines Plattformteam auf, das vier dünnste tragfähige Fähigkeiten verantwortet: eine gemeinsame Identität bzw. ein gemeinsames Login, eine FHIR-basierte Interoperabilitätsschicht, gemeinsames Hosting mit Sicherheits- und Baselines der klinischen Sicherheit sowie ein Designsystem. Jeder Ort behält ein Stream-aligned-Team, baut aber nun auf der Plattform auf statt bei null.

Die Finanzierung wechselt von jährlichen Projektanträgen zu ständigen Produktbudgets für jeden Strom, freigegeben über die Tore Discovery/Alpha/Beta. Eine veröffentlichte RAPID-Karte stellt klar, dass Ortsteams ihr Servicedesign innerhalb der Leitplanken von Plattform und klinischer Sicherheit selbst entscheiden, während das ICS-Digitalgremium Plattformstandards entscheidet. Innerhalb eines Jahres teilen drei Orte eine Buchungsfähigkeit, die Design- und Sicherheits-Baseline ist konsistent, und neue Funktionen, die früher einen Projektzyklus brauchten, erscheinen in Wochen – weil die Plattform die undifferenzierte Schwerarbeit aufgenommen hat.

Sektorperspektiven#

Ein Betriebsmodell wird auf die Organisation zugeschnitten, der es dient; dieselben Schichten – Wertströme, Fähigkeiten, Teams, Governance, Plattform, Lieferanten – werden von einem Startup, einem Großunternehmen und einer Regierungsstelle sehr unterschiedlich gezeichnet.

Startup#

In einem kleinen Unternehmen der digitalen Gesundheit ist das Betriebsmodell überwiegend implizit, und das ist in Ordnung: ein oder zwei Stream-aligned-Teams, ein Gründer, der die meisten Entscheidungsrechte hält, und kein Plattformteam, weil es noch nichts zu plattformisieren gibt. Die Disziplin besteht darin, die wenigen wirklichen Entscheidungen früh explizit zu machen – Bauen versus Kaufen beim klinischen Datenspeicher, auf welche offenen Standards man sich festlegt –, damit die Abkürzung von heute nicht der Lock-in von morgen wird. Betrieb und Veränderung liegen in denselben Händen, sodass das Risiko besteht, dass der Betrieb für frühe Kunden die Roadmap aushungert; eine einfache, ehrliche Aufteilung der Entwicklungszeit ist das schlanke Äquivalent eines geschützten Betriebsbudgets. Lieferanten werden nach Geschwindigkeit gewählt, doch ein Startup sollte Lock-in bei klinischen Kerndaten dennoch ablehnen, weil seine künftigen NHS-Käufer Ausstiegsrechte verlangen werden.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder ambulanter Pflegeanbieter, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Phase ohne Umsatz – hat echte Patientinnen und Patienten und laufenden Betrieb, aber kein Plattformteam, keine eigene Digital- oder IT-Fähigkeit und wenig Spielraum bei Geld oder Personal. Hier ist das Betriebsmodell weitgehend eine Reihe zugekaufter, zusammengenähter Fähigkeiten; die entscheidenden Weichenstellungen sind daher Lieferantenentscheidungen: auf offene Standards und Ausstiegsrechte in den beschafften klinischen Systemen zu bestehen, weil Sie dieselben Interoperabilitäts- und klinischen Sicherheitspflichten tragen wie ein großer Trust, aber ohne dessen Einkaufsmacht oder hauseigene Expertise. Betrieb und Veränderung fallen auf dieselbe Handvoll Menschen, die auch Versorgung leisten; die ehrliche Disziplin ist daher, ein wenig Zeit zu schützen, um Systeme sicher und aktuell zu halten, statt nur Brände zu löschen. Entscheidungsrechte sind einfach – meist entscheidet eine Partnerin oder der Inhaber –, doch das macht es leicht, digitale Entscheidungen endlos aufzuschieben; der Wert liegt darin, die wenigen wichtigen zu benennen (welche Patientenakte, welcher gemeinsamen regionalen Plattform man beitritt) und sie bewusst zu treffen. Wo ein ICS oder eine nationale Stelle eine gemeinsame Identitäts-, Interoperabilitäts- oder Designplattform anbietet, ist der beste Zug des kleinen Unternehmens oft, darauf aufzubauen, statt neu zu erfinden, und sich die Fähigkeit zu borgen, die es selbst nicht besetzen kann.

Großunternehmen#

Ein NHS Trust oder ICS ist der Ort, an dem sich die Form „Plattform plus Föderation“ bewährt: souveräne Organisationen, die sich für eine Patientin wie ein einziger Service anfühlen müssen. Die schweren Probleme sind ebenso politisch wie technisch – Geld von zeitlich begrenzten Projektanträgen zu ständigen Produktbudgets zu verlagern und eine RACI-/RAPID-Karte zu veröffentlichen, damit Ortsteams aufhören, Entscheidungen zu eskalieren, die ihnen gehören. Ein großes Health-Tech- oder Pharma-Unternehmen verfügt über die Plattform-Engineering-Kraft, riskiert aber, eine große interne Plattform zu überbauen, die zum eigenen Engpass wird; der Test der dünnsten tragfähigen Plattform – zwei oder mehr Teams brauchen nachweislich dasselbe – ist die Bremse. In dieser Größenordnung sind Entscheidungsrechte und Mittelfluss das Betriebsmodell; die Technologie ist in der Regel nicht die Beschränkung.

Regierung#

Eine nationale oder lokale öffentliche Stelle entwirft Betriebsmodelle, in denen andere Organisationen leben müssen; ihre Entscheidungen über Standards und Plattformen sind daher faktisch nationale Infrastruktur. Wenn NHS England oder DHSC eine gemeinsame Identitätsschicht, ein Interoperabilitätsrückgrat oder ein Designsystem bereitstellt, ist das das Plattformmuster im Bevölkerungsmaßstab, und seine Ausgabenkontrollen und gestuften Assurance-Tore sind die Art, wie öffentliches Geld zur Rechenschaft gezogen wird. Das Fehlerbild ist ein zentralisiertes Modell, das zu einem fernen Engpass wird und für jeden lokalen Kontext dieselbe Lösung vorschreibt; das Korrektiv ist, die wirklich gemeinsamen Fähigkeiten zu plattformisieren und den Rest an Trusts und Kommunalverwaltungen zu föderieren. Rechenschaft gegenüber dem Parlament bedeutet auch, dass Bauen/Kaufen und Lieferantensteuerung öffentlich nachvollziehbar sind; offene Standards und Ausstiegsrechte sind daher nicht nur klug, sondern erwartet.

Häufige Fehlermuster#

• Das Organigramm automatisieren. Teams um bestehende Abteilungen statt um Wertströme entwerfen, sodass das TOM Silos verfestigt. Gegenmittel: von Ergebnissen und Wertströmen abwärts entwerfen.
• Die Plattform, die zum Engpass wird. Ein überdimensioniertes zentrales Plattformteam, hinter dem sich jede Anfrage anstellen muss. Gegenmittel: dünnste tragfähige Plattform, behandelt als Produkt mit SLAs.
• Projektfinanzierung für Produktarbeit. Auslaufendes Geld erzwingt Auflösen-und-Neuaufbauen-Fluktuation. Gegenmittel: dauerhafte Produktfinanzierung mit gestuften Toren.
• Betrieb zugunsten der Veränderung ausgehungert. Betrieb von Live-Services unterfinanzieren, bis klinische Systeme verfallen. Gegenmittel: Betrieb und Veränderung explizit finanzieren und das Betriebsbudget schützen.
• Herrenlose Entscheidungen. Niemand weiß, wer entscheidet, also eskaliert alles. Gegenmittel: ein veröffentlichtes RACI/RAPID.
• Lock-in per Voreinstellung. Klinische Kerndaten in einem proprietären Lieferantensystem ohne Ausstieg gefangen. Gegenmittel: offene Standards und Ausstiegsrechte in jedem strategischen Vertrag.

Reifegradmodell#

Checkliste#

• Das Betriebsmodell ist von Ergebnissen und Wertströmen her entworfen, nicht von der bestehenden Hierarchie.
• Gemeinsame Fähigkeiten werden als dünnste tragfähige Plattform bereitgestellt, Stream-Teams bauen darauf auf.
• Produktteams sind dauerhaft finanziert und an Wertströmen ausgerichtet.
• Die Ausgabenkontrolle ist gestuft (Tore Discovery/Alpha/Beta/Live) und verhältnismäßig zu Risiko und Wert.
• Entscheidungsrechte sind dokumentiert (RACI oder RAPID) und veröffentlicht.
• Betrieb und Veränderung sind explizit finanziert, das Betriebsbudget ist geschützt.
• Teamtypen (Stream-aligned, Platform, Enabling, Complicated-Subsystem) werden verstanden und genutzt.
• Bauen/Kaufen ist je Fähigkeit eine bewusste Wahl; klinische Kerndaten vermeiden Lock-in.
• Verträge verlangen offene Standards (z. B. HL7 FHIR, SNOMED CT) und Ausstiegsrechte.

Zentrale Quellen#

• Matthew Skelton & Manuel Pais — Team Topologies (Stream-aligned-, Platform-, Enabling-, Complicated-Subsystem-Teams; dünnste tragfähige Plattform).
• GOV.UK Service Manual — spend controls und gestufte Assurance (Discovery/Alpha/Beta/Live); Government Digital Service.
• NHS digital service manual — NHS service standard (service-manual.nhs.uk).
• AXELOS — Management of Portfolios (MoP) und Managing Successful Programmes (MSP) für Portfolio- und Programm-Governance.
• Bain & Company — Entscheidungsrechte-Rahmenwerk RAPID; und das Zuständigkeitsmodell RACI.
• John Doerr — Measure What Matters (OKRs) zur Definition von Ergebnissen.

Referenzen#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book