Thema 5.2 — Programmgeführte Arbeit

In einem Satz: Programmgeführte Arbeit koordiniert eine Gruppe verwandter Projekte und Produkte auf eine strategische Veränderung hin, die keines allein liefern könnte, und hält eine klare Sichtlinie von der Arbeit zu den Nutzen, die sie realisieren soll.

Warum das in Gesundheit und Pflege wichtig ist#

Die größten Veränderungen in Gesundheit und Pflege sind nie ein einzelnes Projekt. Die Einführung einer gemeinsamen Patientenakte über ein Integrated Care System (ICS), der Umzug einer Region auf eine einzige elektronische Patientenakte, die Umgestaltung eines Pfads der Akut- und Notfallversorgung oder ein Virtual-Ward-Programm über mehrere Trusts – jedes davon ist ein koordiniertes Bündel aus Projekten, Produktteams, Personalveränderung, Baumaßnahmen und klinischer Neugestaltung, ausgerichtet auf ein strategisches Ergebnis. Managt man die Teile isoliert, kollidieren sie: inkompatible Datenstandards, doppelte Ausgaben, widersprüchliche klinische Arbeitsabläufe und Nutzen, die nie tatsächlich eintreten.

Programmmanagement existiert, um diese Koalition zusammenzuhalten und auf Ergebnisse und Nutzen ausgerichtet zu halten, nicht nur auf Outputs. Das ist in Gesundheit und Pflege besonders wichtig, weil systemweite Veränderung die Patientensicherheit über Organisationsgrenzen hinweg berührt, über mehrere Jahre große Summen öffentlichen Geldes bindet und davon abhängt, dass viele autonome Organisationen sich entscheiden, im Gleichschritt zu gehen. Ein Programm liefert die Führung, den gemeinsamen Zielzustand und die Nutzendisziplin, um das möglich zu machen – und ebenso wichtig, um zu wissen, ob es funktioniert.

Das wiederkehrende Versagen, gegen das es schützt, ist das Programm, das Millionen ausgibt, einen Haufen technischer Outputs liefert und doch nichts Messbares für Patientinnen oder Personal verändert. Dieses Thema nutzt Managing Successful Programmes (MSP), das dominierende Framework des britischen öffentlichen Sektors, und zeigt, wie programmgeführte Arbeit mit den projektgeführten (Thema 5.1 — Projektgeführte Arbeit) und produktgeführten (Thema 5.0 — Produktgeführte Arbeit) Arbeitsweisen koexistiert, die sie koordiniert. Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM) erklärt dann, wie eine Organisation über viele Programme hinweg priorisiert.

Kernkonzepte#

Programm. Eine befristete, flexible Organisation, geschaffen, um eine Gruppe verwandter Projekte und Aktivitäten zu koordinieren, zu leiten und zu überwachen, damit Ergebnisse und Nutzen geliefert werden, die auf strategische Ziele ausgerichtet sind. Ein Programm unterscheidet sich von einem Projekt dadurch, dass es über das Ergebnis und die Nutzen definiert ist, die es anstrebt, und die Ungewissheit der Koordination vieler beweglicher Teile managt, statt einen einzelnen festen Output zu liefern.

MSP (Managing Successful Programmes). Das britische Best-Practice-Framework zum Management transformativer Veränderung durch mehrere verwandte Projekte. Es ist um Prinzipien, Themen und einen „Transformationsfluss“ von Prozessen organisiert und für große, komplexe Veränderungen gedacht, bei denen der Endzustand der Richtung nach bekannt ist, der Weg aber viele wechselseitig abhängige Lieferungen umfasst.

Vision und Blueprint. Die Vision ist das überzeugende Bild der Zukunft, die das Programm schaffen wird. Der Blueprint macht sie konkret: Er beschreibt das Zielbetriebsmodell (Target Operating Model) – den künftigen Zustand von Prozessen, Organisation, Technologie, Information und Rollen (oft als POTI zusammengefasst). Der Blueprint ist der Bezugspunkt, auf den jedes Projekt gesteuert wird, damit die Teile ein stimmiges Ganzes ergeben.

Nutzenrealisierung (Benefits Realisation). Das Herz des Programmmanagements. Nutzen sind die messbaren Verbesserungen, die die Investition rechtfertigen – weniger verzögerte Entlassungen, weniger doppelte Tests, schnellere Diagnose, geringere Verwaltungslast. MSP behandelt Identifizieren, Abbilden, Messen und aktives Managen von Nutzen über den ganzen Lebenszyklus als Kerndisziplin, denn Outputs schaffen nur dann Wert, wenn sie genutzt werden, um zu verändern, wie Versorgung geliefert wird.

Tranchen. MSP gliedert ein Programm in Tranchen – Arbeitsblöcke, die an einem größeren Überprüfungspunkt enden, an dem ein Schritt an Fähigkeit geliefert wurde und die Nutzenrealisierung beginnen kann. Eine Tranche ist ein Moment, Ergebnisse zu zeigen, den Blueprint gegen die Realität neu zu bewerten und zu entscheiden, ob fortgesetzt, angepasst oder gestoppt wird, und nicht bloß eine Scheibe des Terminplans.

Programmvorstand und SRO. Die Senior Responsible Owner (SRO) ist die einzelne Person, die dafür rechenschaftspflichtig ist, dass das Programm seine Ziele erreicht und seine Nutzen realisiert, mit genug Seniorität und Befugnis, um zu führen und Entscheidungen zu treffen. Die SRO leitet einen Programmvorstand – typischerweise eine Business Change Managerin, Projektleitungen und leitende Stakeholder –, der Richtung über Organisationsgrenzen hinweg gibt.

Business Change Manager (BCM). Die besondere Rolle in MSP: jemand aus dem operativen Geschäft (nicht aus dem Liefer-Team), rechenschaftspflichtig dafür, die Veränderung zu verankern und Nutzen vor Ort zu realisieren. Die BCM ist der Grund, warum Programme Ergebnisse statt nur Outputs liefern – Projekte übergeben Fähigkeit, die BCM verwandelt sie in Nutzen.

Bewährte Praktiken#

1. Verankern Sie das Programm in einer Vision und einem Blueprint. Definieren Sie das strategische Ergebnis und übersetzen Sie es in ein konkretes Zielbetriebsmodell (Prozesse, Organisation, Technologie, Information – POTI). Jedes beteiligte Projekt und Produkt wird dann auf denselben Zielzustand gesteuert, und das verhindert, dass eine Koalition von Lieferungen zersplittert.

2. Managen Sie Nutzen, nicht nur Lieferergebnisse. Bauen Sie eine Nutzenlandkarte, die jeden Output mit den Ergebnissen und messbaren Nutzen verknüpft, die er erzeugen soll, mit Verantwortlichen und Baselines. Überprüfen Sie Nutzen im Programm aktiv und seien Sie bereit, Arbeit zu stoppen, die sich nicht auszahlen wird – der Schwerpunkt von MSP auf Nutzenrealisierung ist die Disziplin, die ein Programm von einer teuren To-do-Liste unterscheidet.

3. Gliedern Sie die Arbeit in Tranchen mit echten Überprüfungspunkten. Liefern Sie Fähigkeit in Tranchen und zeigen Sie an jeder Tranchengrenze die bisher realisierten Nutzen, bewerten Sie den Blueprint an dem neu, was Sie gelernt haben, und treffen Sie eine echte Entscheidung fortsetzen/anpassen/stoppen. Frühe Tranchen sollten auf sichtbare Quick Wins zielen, um Vertrauen der Stakeholder für die schwereren späteren aufzubauen.

4. Ernennen Sie eine befähigte SRO und einen echten Programmvorstand. Benennen Sie eine einzelne SRO mit der Seniorität und Befugnis, das Programm zu leiten und über Organisationsgrenzen hinweg zu entscheiden, und berufen Sie einen Vorstand, der die betroffenen Organisationen wirklich vertritt. Programme scheitern, wenn Rechenschaft diffus ist oder die SRO grenzüberschreitende Entscheidungen nicht wirklich durchsetzen kann.

5. Setzen Sie Business Change Manager ins operative Geschäft. Weisen Sie BCMs aus den Organisationen an der Front zu, damit sie Annahme und Nutzenrealisierung dort verantworten, wo Versorgung geleistet wird. Gelieferte, aber nicht angenommene Fähigkeit realisiert keinen Nutzen; die BCM-Rolle ist der Mechanismus, der diese Lücke schließt.

6. Koordinieren Sie die beteiligten Projekte und Produkte – mikromanagen Sie sie nicht. Das Programm setzt Blueprint, Abhängigkeiten, Standards und Nutzen; es lässt Projekte und Produktteams innerhalb dieses Rahmens liefern. Es managt die Nahtstellen – gemeinsame Datenstandards, Informationsgovernance, Reihenfolge und gemeinsame Infrastruktur –, nicht die internen Einzelheiten jeder Lieferung.

7. Managen Sie übergreifende Risiken, Abhängigkeiten und Stakeholder unermüdlich. Der Wert, den ein Programm gegenüber eigenständigen Projekten hinzufügt, liegt weitgehend im Management dessen, was zwischen ihnen geschieht. Pflegen Sie eine Sicht auf Programmebene auf Abhängigkeiten und gemeinsame Risiken und investieren Sie stark in Stakeholder-Engagement über autonome Organisationen hinweg, denn Ausrichtung ist freiwillig, nicht befohlen.

8. Schließen Sie das Programm, wenn die Veränderung verankert ist, und übergeben Sie laufende Dienste an Produktteams. Ein Programm ist befristet. Wenn der Blueprint erreicht ist und Nutzen realisiert werden, schließen Sie es bewusst, übertragen Sie dauerhafte Dienste an dauerhafte Produktteams (Thema 5.0) und verfolgen Sie Nutzen weiter in den Regelbetrieb hinein – viele Nutzen fallen erst nach dem Ende des Programms an.

Fragen zur Diskussion im Team#

1. Hat unsere leitende verantwortliche Person tatsächlich die Befugnis, Entscheidungen über souveräne Partnerorganisationen hinweg durchzusetzen, oder nur die Rechenschaftspflicht, wenn sie es nicht tun? Programmgeführte Arbeit steht und fällt mit grenzüberschreitender Befugnis, weil die Veränderung autonome Trusts, Primärversorgung, Gemeinde, psychische Gesundheit und Sozialpflege umspannt, die nicht einfach befohlen werden können, im Gleichschritt zu gehen. Das charakteristische Versagen ist eine benannte SRO, die die persönliche, öffentliche Rechenschaft für Nutzen trägt, aber nicht das Standing hat, einen widerstrebenden Partner zu zwingen, einen gemeinsamen Datenstandard zu übernehmen oder einen klinischen Arbeitsablauf zu ändern – Rechenschaft ohne Befugnis. Die Debatte sollte offen sein, wo im System die reale Macht sitzt: ob der Programmvorstand die betroffenen Organisationen wirklich vertritt oder ein Berichtsforum ist, ob die SRO so senior ist, dass ihre Entscheidungen über souveräne Grenzen hinweg beachtet werden, und was geschieht, wenn ein Partner sich weigert mitzugehen. Bedenken Sie eine jüngste organisationsübergreifende Entscheidung und verfolgen Sie, ob sie tatsächlich hielt. Eine gute Antwort nennt, wer die SRO ist, und prüft ihre Befugnis an einem konkreten grenzüberschreitenden Konflikt, ist ehrlich über die Organisationen, die faktisch aussteigen können, und behandelt einen repräsentativen Vorstand und eingebettete Business Change Manager als tragende Mechanismen freiwilliger Ausrichtung statt als Governance-Dekoration.

2. Woran werden wir erkennen, dass dieses Programm Nutzen realisiert und nicht bloß Outputs geliefert hat – und wer im operativen Geschäft ist rechenschaftspflichtig, Fähigkeit in Nutzen zu verwandeln? Output-Theater ist die wiederkehrende Pathologie, vor der das Thema warnt: Ein Programm gibt Millionen aus, produziert einen Haufen Interoperabilitätsplattformen und Integrationen, und doch ändert sich nichts Messbares für Patientinnen oder Personal. Die Unterscheidung, die das verhindert, ist die Business Change Managerin – jemand aus dem Betrieb an der Front, nicht aus dem Liefer-Team, rechenschaftspflichtig dafür, die Veränderung zu verankern und Nutzen dort zu realisieren, wo Versorgung geleistet wird –, sodass die Frage das Team zwingt, diese Menschen zu benennen und zu bestätigen, dass es sie gibt. Die Spannung ist, dass Lieferung sichtbar und befriedigend ist, während Annahme langsam, unglamourös und leicht als „wird schon geschehen“ angenommen ist; eine gemeinsame Patientenakte, die hinter einem zusätzlichen Login vergraben ist, realisiert keinen Nutzen, wie gut sie auch gebaut ist. Bringen Sie die Nutzenlandkarte in die Diskussion und prüfen Sie hart, ob jeder Output mit einem verantworteten, mit Baseline versehenen, messbaren Nutzen verknüpft ist (weniger doppelte Tests, weniger verzögerte Entlassungen) oder Nutzen nur behauptet werden. Eine ehrliche Antwort benennt eine BCM in jeder Partnerorganisation, räumt ein, wo Nutzen derzeit unverantwortet oder ungemessen sind, und akzeptiert, dass manche Nutzen erst nach Programmschluss anfallen und in den Regelbetrieb hinein verfolgt werden müssen.

3. Gliedern wir dieses Programm in Tranchen, um frühe Nutzen einzufahren und echte Punkte für fortsetzen/anpassen/stoppen zu schaffen, oder driften wir auf eine Big-Bang-Lieferung zu, die das ganze Risiko auf einen späten Moment verschiebt? Tranchen sind das, was ein Programm von einem teuren eingefrorenen Plan unterscheidet: Jede Tranchengrenze sollte einen Schritt an Fähigkeit liefern, die bisher realisierten Nutzen zeigen, den Blueprint an dem neu bewerten, was tatsächlich gelernt wurde, und eine echte Entscheidung fortsetzen, anpassen oder stoppen stützen. Die Versuchung in Gesundheit und Pflege ist, aus Gründen der Ingenieurbequemlichkeit zu sequenzieren und sichtbaren Wert aufzuschieben – jeden Trust anzubinden, bevor irgendjemand etwas nutzen kann –, was das ganze Risiko in eine einzige späte Lieferung lädt und den Vorstand ohne Evidenz lässt, um fortgesetzte Investition über Haushalts- und politische Zyklen zu verteidigen. Die Debatte sollte prüfen, ob frühe Tranchen gezielt auf Quick Wins zielen, die Vertrauen der Stakeholder für die schwerere spätere Arbeit aufbauen, und ob die Überprüfungspunkte echte Entscheidungen oder Terminplan-Checkpunkte sind. Bedenken Sie, was der erste nachweisbare Nutzen ist, wie bald er eintritt und was der Vorstand bei einer Tranchenüberprüfung tatsächlich täte, wenn die Annahme hinterherhinkt oder der Blueprint sich als falsch erweist. Eine gute Antwort beschreibt konkrete Tranchen mit frühen, messbaren Erfolgen, behandelt jede Grenze als echtes Go/No-go mit einem tatsächlich revidierbaren Blueprint und ist ehrlich über jeden Druck, Wert bis zum Ende aufzuschieben.

4. Haben wir einen einzigen, gepflegten Blueprint des Zielbetriebsmodells, oder optimiert jedes Projekt still auf seine eigene Version der Zukunft? Der Blueprint – das konkrete POTI-Zielbetriebsmodell aus Prozessen, Organisation, Technologie und Information – ist das, was die Teile zu einem stimmigen Ganzen macht statt zu einer Kollision lokal sinnvoller Entscheidungen. Ohne ihn optimiert jedes beteiligte Projekt rational für seinen eigenen Umfang: Ein Trust wählt einen Datenstandard, der zu seiner bestehenden EPR passt, ein anderer gestaltet einen klinischen Arbeitsablauf um seine eigene Personalbesetzung, und die gemeinsame Patientenakte zersplittert in Integrationen, die technisch verbinden, aber nicht zusammenhalten. Die Spannung ist, dass die Pflege eines Blueprints für Liefer-Teams unter Auslieferungsdruck wie Overhead wirkt und er eine lebende, an jeder Tranche neu geprüfte Referenz sein muss statt eines einmal geschriebenen und beiseitegelegten Dokuments. Die Debatte sollte klären, ob der Blueprint tatsächlich in nutzbarer Form existiert, wem er gehört und ob reale Projektentscheidungen von ihm gesteuert oder nur nachträglich mit ihm abgeglichen werden. Bedenken Sie eine jüngste Designentscheidung in einem Projekt und fragen Sie, ob der Blueprint sie prägte oder still übergangen wurde. Eine ehrliche Antwort kann auf einen aktuellen Blueprint verweisen, benennt seinen Verantwortlichen und ist offen, wo lokale Optimierung den Zielzustand bereits auseinanderzieht.

5. Was bleibt bestehen, wenn das Programm schließt – und haben wir die dauerhaften Produktteams benannt, die die Fähigkeit betreiben und Nutzen in den Regelbetrieb hinein weiter verfolgen? Ein Programm ist per Definition befristet, doch die gemeinsame Patientenakte, die Interoperabilitätsplattform und die Nutzen, die sie erzeugen, sind es nicht; der Abschluss ist daher ein Designproblem, das von Anfang an zu planen ist, kein Nachgedanke. Das wiederkehrende Versagen an beiden Enden des Spektrums ist real: Manche Programme schließen nie und verhärten lange nach der Verankerung der Veränderung zu dauerhaften Bürokratien, andere schließen abrupt und lassen einen Live-Dienst ohne dauerhafte Verantwortliche zurück. Das Thema ist ausdrücklich, dass dauerhafte Dienste an dauerhafte Produktteams (Thema 5.0) übergehen sollten und dass viele Nutzen erst nach dem Ende des Programms anfallen und in den Regelbetrieb (BAU) hinein verfolgt werden müssen – was bedeutet, dass die übernehmenden Teams und die fortlaufende Nutzenverantwortung identifiziert werden müssen, solange das Programm noch die Befugnis und Finanzierung hat, sie aufzubauen. Die Debatte sollte ans Licht bringen, wer jede dauerhafte Fähigkeit betreiben wird, wie sie finanziert wird, sobald das Transformationsgeld endet, und wer weiter Nutzen misst, wenn sich der Programmvorstand aufgelöst hat. Eine gute Antwort benennt die konkreten Produktteams und BAU-Verantwortlichen, beschreibt den Finanzierungsübergang ehrlich und behandelt Abschluss und Nutzenverfolgung als geplante Tranchen statt als hoffnungsvolle Übergabe.

6. Wie managen wir die Nahtstellen zwischen Projekten – gemeinsame Standards, Informationsgovernance, Reihenfolge und gemeinsame Infrastruktur –, statt die Interna jeder Lieferung? Der Wert, den ein Programm gegenüber einer Reihe eigenständiger Projekte hinzufügt, liegt fast ganz im Raum zwischen ihnen: den Abhängigkeiten, den gemeinsamen Datenstandards, dem Rahmen aus Informationsgovernance und Einwilligung und der gemeinsamen Infrastruktur, die keinem einzelnen Projekt gehört, von der aber alle abhängen. Die Versuchung für ein Programmteam ist, ins Mikromanagement der Interna jeder Lieferung abzudriften – bequeme, sichtbare Arbeit –, während die wirklich schweren übergreifenden Nahtstellen ungemanagt bleiben, bis sie als Integrationsfehler oder Blocker der Informationsgovernance beim Go-live auftauchen. In Gesundheit und Pflege sind diese Nahtstellen ungewöhnlich tragend, weil Datenflüsse und Einwilligung souveräne Organisations- und Regulierungsgrenzen überqueren, wo Ausrichtung freiwillig ist und Rechtspflichten geteilt, aber ungleich ausgestattet sind. Die Debatte sollte prüfen, ob es eine Sicht auf Programmebene auf Abhängigkeiten und gemeinsame Risiken gibt, wem die gemeinsamen Standards und die Infrastruktur gehören und ob das Programm Nahtstellen koordiniert oder sich in Projektdetails einmischt. Eine ehrliche Antwort benennt die konkreten Nahtstellen, die das Ergebnis am meisten bedrohen, nennt ihre Verantwortlichen und ist offen, ob das Programm an den Grenzen Wert schafft oder die Arbeit der Projekte dupliziert, die es ermöglichen sollte.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein ICS macht sich daran, eine gemeinsame Patientenakte zu liefern, die Klinikpersonal in Akut-, Gemeinde-, psychiatrischer Versorgung, Primärversorgung und Sozialpflege eine einheitliche Sicht auf eine Person gibt. Kein einzelnes Projekt kann das leisten: Es umspannt mehrere Trusts, mehrere Quellsysteme, Vereinbarungen der Informationsgovernance, Neugestaltung klinischer Arbeitsabläufe und öffentliches Engagement. Es wird als MSP-Programm koordiniert.

Die SRO – eine ICS-Executive mit echter systemübergreifender Befugnis – leitet einen Programmvorstand mit Vertretungen jeder Partnerorganisation und benannten Business Change Managern in jeder. Das Programm setzt eine Vision („die richtige Information über die richtige Person, verfügbar für die richtige Klinikerin am Behandlungsort“) und einen Blueprint, der das Zielbetriebsmodell beschreibt: die Architektur und Standards des Datenaustauschs (HL7-FHIR-basierte Interoperabilität), den Rahmen der Informationsgovernance, das Einwilligungsmodell und die neu gestalteten klinischen Arbeitsabläufe.

Die Arbeit ist in Tranchen organisiert. Tranche eins verbindet zwei bereitwillige Akut-Trusts und liefert eine schreibgeschützte Akte, ein bewusster Quick Win, der den Ansatz belegt und dem Vorstand erlaubt, einen frühen Nutzen – eine messbare Verringerung doppelter Tests – zu zeigen, um Vertrauen aufzubauen. Bei der Überprüfung von Tranche eins erfährt der Vorstand, dass die Annahme durch Klinikpersonal dort hinterherhinkt, wo die Akte hinter einem zusätzlichen Login vergraben ist; er passt daher den Blueprint an und priorisiert die Single-Sign-on-Integration vor der Ausweitung des Rollouts.

Unter dem Programm koexistieren die Arbeitsweisen. Die Interoperabilitätsplattform wird von einem dauerhaften Produktteam (Thema 5.0) betrieben, das sie über das ganze Programm und darüber hinaus weiter verbessert. Die Anbindung jedes Trusts ist ein begrenztes Projekt (Thema 5.1) mit eigenem Business Case und Go-live. Das Programm selbst koordiniert den Blueprint, die Standards, die Abhängigkeiten und – über die BCMs – die Nutzenrealisierung. Wenn der Blueprint erreicht ist und Nutzen aus doppelten Tests und verzögerten Entlassungen fließen, schließt das Programm; das Plattform-Produktteam bleibt bestehen, und die Nutzenverfolgung geht in den Regelbetrieb über.

Sektorperspektiven#

Startup#

Nur wenige Startups führen Programme im Sinne von MSP durch – ihnen fehlt der organisationsübergreifende Umfang, der eines definiert –, doch eine Scale-up, die über mehrere Trusts einführt, wird faktisch zur Programm-Teilnehmerin. Ihre realistische Rolle ist die einer Lieferantin innerhalb des Programms eines anderen: ihr Produkt auf den Programm-Blueprint auszurichten, Tranchenmeilensteine zu treffen und den Nutzenfall zu speisen, den die SRO belegen muss. Finanzierung und Überleben hängen davon ab, dass das Programm weitergeht; das Startup behandelt Tranchenüberprüfungen daher als existenzielle Go/No-go-Punkte und investiert in den Erfolg der Business Change Manager, denn Annahme vor Ort ist das, was seinen Vertrag verlängert. Die Disziplin, die es sich borgen muss, ist die Sprache des Nutzens – seinen Wert als realisierte Ergebnisse zu rahmen, nicht als ausgelieferte Features.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder ein kleiner Health-Tech-Lieferant jenseits der Startup-Phase – führt fast nie ein Programm durch, wird aber routinemäßig als betroffener Teilnehmer in eines hineingezogen, wenn ein ICS eine gemeinsame Patientenakte einführt oder Systeme über das Gebiet konvergiert. Sein praktisches Anliegen ist die Nahtstelle, die das Programm verantwortet: Er muss die verbindlichen Datenstandards, Vereinbarungen der Informationsgovernance und das Einwilligungsmodell mit dünner oder gar keiner eigenen IT-Kapazität und ohne Luft für die Aufnahme von Arbeitsablaufänderung übernehmen, trägt aber dieselben Rechtspflichten wie die großen Trusts um ihn herum. Die wertvollste Beziehung, die er hat, ist die zur Business Change Managerin seines Ortes, denn eine gut unterstützte Annahme – Schulung, Single Sign-on, ein Arbeitsablauf, der zur tatsächlichen Arbeitsweise der Praxis passt – ist der Unterschied zwischen dem Eintreten des Programmnutzens und einer still umgangenen Veränderung. Seine realistische Forderung an das Programm ist verhältnismäßige Unterstützung und eine Reihenfolge, die keine Ressourcen im Unternehmensmaßstab voraussetzt, und sein ehrlicher Beitrag ist frühes, offenes Feedback bei Tranchenüberprüfungen darüber, was vor Ort nicht praktikabel ist.

Großunternehmen#

Ein ICS oder großer Trust ist die natürliche Heimat programmgeführter Arbeit: Gemeinsame Patientenakten, EPR-Konvergenz und Pfadtransformation sind von Natur aus organisationsübergreifend und mehrjährig. Das Schwere ist Befugnis – die SRO muss Entscheidungen über souveräne Partnerorganisationen hinweg durchsetzen, die nicht einfach befohlen werden können; ein wirklich repräsentativer Programmvorstand und in jedem Partner eingebettete Business Change Manager sind daher tragend, nicht dekorativ. Finanzierung ist gemischt (Systemtransformationsgelder, Trust-Kapital, nationale Zuweisungen), was Nutzenlandkarte und Tranchenüberprüfungen unverzichtbar macht, um fortgesetzte Investition gegenüber Systemleitungen und Regulierern zu verteidigen. Das wiederkehrende Risiko in dieser Größenordnung ist Output-Theater: technische Lieferung, bei der niemand rechenschaftspflichtig ist, sie in Nutzen zu verwandeln.

Regierung#

Im nationalen Maßstab tragen Programme die schwerste Governance – sie gelangen typischerweise in das Government Major Projects Portfolio, durchlaufen Assurance und Gateway Reviews der Infrastructure and Projects Authority und stehen Ministern, dem Public Accounts Committee und dem National Audit Office Rede und Antwort. Die SRO ist persönlich und öffentlich für die Nutzenrealisierung im gesamten System rechenschaftspflichtig, und Blueprints müssen nationale Standards (Interoperabilität, Informationsgovernance, die NHS App als gemeinsame Eingangstür) mit lokaler Autonomie in Einklang bringen. Finanzierung läuft über mehrjährige Spending-Review-Zuweisungen; Tranchierung und Nutzennachweis sind daher der Mechanismus, um Investition über Haushalts- und politische Zyklen hinweg aufrechtzuerhalten oder anzuhalten. Der Einsatz ist bevölkerungsweit: Die Nutzen eines nationalen Programms – oder sein Scheitern – werden in Millionen Patientinnen und Milliarden Pfund gemessen.

Häufige Fehlermuster#

• Output-Theater. Das Programm liefert technische Outputs, aber niemand verantwortet, sie in Nutzen zu verwandeln; für Patientinnen ändert sich also nichts. Abhilfe: Nutzenlandkarten mit Verantwortlichen und BCMs im operativen Geschäft.
• Ein Programm, das nur ein großes Projekt ist. Output-fokussierte Governance mit festem Umfang, angewandt auf wirklich ungewisse, organisationsübergreifende Veränderung. Abhilfe: nach Ergebnissen/Nutzen und Tranchen steuern, nicht nach einem einzigen eingefrorenen Plan.
• Eine machtlose SRO. Rechenschaft ohne Befugnis, über Grenzen hinweg zu entscheiden. Abhilfe: eine SRO ernennen, die senior genug ist, systemübergreifende Entscheidungen durchzusetzen, gestützt auf einen repräsentativen Vorstand.
• Kein Blueprint / Zielzustand. Projekte optimieren lokal, und die Teile fügen sich nie. Abhilfe: einen POTI-Blueprint definieren und pflegen, auf den alles zusteuert.
• Big Bang statt Tranchen. Das ganze Risiko auf eine späte Lieferung verschoben. Abhilfe: die Arbeit in Tranchen gliedern, frühe Nutzen einfahren und an Überprüfungspunkten neu planen.
• Programm, das nie schließt. Es wird lange nach der Verankerung der Veränderung zur dauerhaften Bürokratie. Abhilfe: bewusst schließen, dauerhafte Dienste an Produktteams übergeben, Nutzen im BAU weiter verfolgen.

Reifegradmodell#

Checkliste#

• Ist dies wirklich Veränderung mit mehreren Projekten und Organisationen hin zu einem strategischen Ergebnis?
• Gibt es eine klare Vision und einen konkreten Blueprint (Zielbetriebsmodell / POTI)?
• Gibt es eine Nutzenlandkarte, die Outputs mit messbaren, verantworteten, mit Baseline versehenen Nutzen verknüpft?
• Ist die Arbeit in Tranchen mit echten Überprüfungspunkten fortsetzen/anpassen/stoppen gegliedert?
• Gibt es eine befähigte SRO mit Befugnis, über Organisationsgrenzen hinweg zu entscheiden?
• Vertritt der Programmvorstand die betroffenen Organisationen wirklich?
• Sind Business Change Manager im operativen Geschäft eingebettet, um die Annahme zu verantworten?
• Werden übergreifende Standards, Abhängigkeiten und gemeinsame Risiken auf Programmebene gemanagt?
• Koexistieren produkt-, projekt- und programmgeführte Arbeitsweisen mit klaren Rollen (Themen 5.0–10)?
• Gibt es einen bewussten Abschluss, mit dauerhaften Diensten, die an dauerhafte Produktteams übergeben werden, und Nutzen, die in den BAU hinein verfolgt werden?

Zentrale Quellen#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): Prinzipien, Themen und der Transformationsfluss (einschließlich Blueprint, Tranchen, Nutzenmanagement und den Rollen SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — Leitlinien zu Großprogrammen, SRO-Rechenschaft und Assurance-/Gateway-Reviews.
• HM Treasury — The Green Book und Leitlinien zum Nutzenmanagement (Bewertung und Evaluierung von Nutzen).
• AXELOS — Management of Portfolios (MoP), zur Einordnung von Programmen in ein Portfolio (siehe Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM)).
• NHS England — Leitlinien zu Integrated Care Systems und gemeinsamen Patientenakten (Interoperabilität, HL7-FHIR-Standards) für den Domänenkontext.
• Mik Kersten — Project to Product, zum Wandel von output-basierter zu ergebnis-/nutzenbasierter Investition.

Referenzen#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/