Thema 6.6 — Lieferanten- und Service-Integrationsmanagement (SIAM)

In einem Bestand von Gesundheit und Pflege, der aus Dutzenden Lieferanten zusammengenäht ist, ist der Dienst, den Ihre Patientinnen und Ihr Klinikpersonal tatsächlich erleben, nur so gut wie die Nahtstellen zwischen den Herstellern – deshalb muss jemand das Ende-zu-Ende-Ganze verantworten, das kein einzelner Vertrag beschreibt.

Warum das in Gesundheit und Pflege wichtig ist#

Kein moderner NHS Trust und kein Integrated Care System (ICS) läuft auf einem einzigen Lieferanten. Ein einzelner klinischer Arbeitsablauf – eine Hausarztüberweisung, die zu einem ambulanten Termin, einem Brief, einem Testergebnis und einem Rezept wird – kann eine elektronische Patientenakte eines Herstellers, eine Integrations-Engine eines anderen, eine Hosting-Plattform eines dritten, einen Netzwerkanbieter, einen nationalen Spine-Dienst und einen von einer vierten Partei betriebenen Managed-Service-Desk durchqueren, den Sie nie getroffen haben. Der Vertrag für jeden Teil mag solide sein. Der Dienst, den die Patientin erhält, lebt in den Lücken zwischen ihnen.

Das ist die Betriebsseite der kommerziellen Beziehung, und hier wird Wert entweder realisiert oder still verloren. Beschaffungs- und Kommerzteams (siehe Thema 6.3 — Beschaffung und Vertragsgestaltung) kaufen gut, vergeben den Vertrag und übergeben eine unterzeichnete Vereinbarung; was in den folgenden Jahren geschieht – ob Lieferanten kooperieren oder sich gegenseitig beschuldigen, ob ein Ausfall in einer Stunde behoben wird oder eine Woche schwelt, ob Sie je gehen können – ist die Arbeit des Lieferanten- und Service-Integrationsmanagements. Machen Sie es falsch, ist das Scheitern nicht abstrakt. Eine Pathologie-Schnittstelle, die still Ergebnisse verliert, eine gemeinsame Patientenakte, die eine veraltete Allergie zeigt, ein Authentifizierungsdienst, der Klinikpersonal bei der Übergabe aussperrt: Das sind Ereignisse der Patientensicherheit, die als Integrationsprobleme beginnen (siehe Thema 1.6 — Klinische Sicherheit und Risikomanagement).

Der Einsatz wird durch drei Merkmale des Sektors verschärft. Öffentliches Geld verlangt, dass die gekauften Ergebnisse auch die gelieferten sind und dass Service Credits und Wert aktiv verfolgt werden, nicht auf dem Tisch liegen bleiben. Gesetzliche Pflichten zu Datenschutz, klinischer Sicherheit und Cybersicherheit müssen die gesamte Lieferkette hinabfließen, einschließlich Unterauftragnehmern, die Sie nicht gewählt haben (siehe Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit). Und die Konzentration kritischer Dienste auf eine Handvoll großer Lieferanten bedeutet, dass der Ransomware-Vorfall, die Insolvenz oder der Kapazitätsausfall eines Herstellers eine ganze Region lahmlegen kann. Lieferanten als Portfolio zu managen – nicht Vertrag für Vertrag – ist heute eine Resilienzpflicht, keine administrative.

Kernkonzepte#

Service Integration and Management (SIAM) ist ein Managementansatz, mehrere Dienstleister zu koordinieren und zu integrieren, damit sie dem Geschäft einen einzigen Ende-zu-Ende-Dienst liefern. Es entstand als Disziplin genau deshalb, weil Organisationen von einem einzelnen Hauptauftragnehmer zu einem Multi-Sourcing-Betriebsmodell übergingen und dann entdeckten, dass immer noch jemand die Teile dazu bringen musste, sich als Ganzes zu verhalten. SIAM ist kein Produkt, das man kauft; es ist ein Betriebsmodell mit definierten Rollen, Prozessen und Governance. Die maßgebliche Referenz ist das SIAM Body of Knowledge von Scopism, das neben ITIL und der weiteren Praxis des IT-Servicemanagements (ITSM) steht, statt sie zu ersetzen.

Ein SIAM-Modell hat drei Schichten. Die Kundin oder beibehaltene Organisation (Retained Organization) behält die Verantwortlichkeiten, die nie ausgelagert werden können: Strategie, Nachfrage, Architektur, kommerzielle Verantwortung und die endgültige Sorgfaltspflicht gegenüber Patientinnen. Der Service Integrator ist die Schicht – ein internes Team, ein externer Lieferant oder ein Hybrid –, die die Anbieter koordiniert, übergreifende Prozesse wie das Major-Incident-Management verantwortet und die Ende-zu-Ende-Sicht hält. Die Dienstleister, oft in Service-Türmen (Service Towers) organisiert (Hosting, Endgeräte, klinische Anwendungen, Netzwerke), liefern je eine definierte Scheibe. Das sind SIAM-Fachbegriffe statt Lexikoneinträgen; sie werden hier daher in schlichter Sprache benannt und im SIAM Body of Knowledge verankert.

Darunter liegt die kommerzielle Mechanik. Outsourcing und seine Daten-und-Prozess-Variante, Business Process Outsourcing, beschreiben die Delegation von Arbeit an einen externen Anbieter; Managed Services beschreiben den laufenden, abonnementartigen Betrieb von Systemen in Ihrem Namen. Leistung wird über eine Service-Level-Vereinbarung (SLA) gesteuert – eine messbare, meist vertragliche Zusage –, zunehmend ergänzt durch eine Experience-Level-Vereinbarung (XLA), die das Ergebnis misst, das eine Nutzerin tatsächlich erlebt, statt der Komponentenkennzahl, die ein Lieferant bequem trifft. XLA hat keinen etablierten Lexikoneintrag; behandeln Sie sie als aufkommende Praxis, nicht als Standard.

Zwei Risikokonzepte rahmen das Thema. Third-Party-Management ist die Disziplin, externe Anbieter und – entscheidend – deren eigene Unterauftragnehmer zu überwachen, die Vierten Parteien tief in der Lieferkette. Lieferkettenrisikomanagement befasst sich mit den Ausfällen, die sich durch diese Kette fortpflanzen, und Konzentrationsrisiko – ein aus dem Bankwesen entlehnter Begriff – erfasst die Gefahr, zu stark von einem einzelnen Lieferanten, einer Plattform oder Region abzuhängen. Diese zu managen verhindert, dass eine bequeme Sourcing-Entscheidung zur systemischen Schwachstelle wird. Schließlich sind die Vermeidung von Vendor Lock-in und die Förderung kontinuierlicher Verbesserung die beiden vorausschauenden Pflichten, die einen Live-Dienst vor dem Erstarren bewahren.

Bewährte Praktiken#

1. Benennen Sie die rechenschaftspflichtige Verantwortliche für den Ende-zu-Ende-Dienst, nicht nur für jeden Vertrag. Das bestimmende Versagen des Multi-Sourcing ist, dass jeder einen Kasten besitzt und niemand die Pfeile dazwischen. Richten Sie eine Rolle in der beibehaltenen Organisation ein – oft eine Leitung Service-Integration oder ein Büro für Lieferantenmanagement –, die für den ganzen klinischen oder geschäftlichen Dienst, wie ihn die Nutzerin erlebt, rechenschaftspflichtig ist, mit der Befugnis, Lieferanten einzuberufen und zu schlichten. Diese Verantwortliche hält die Ende-zu-Ende-SLA, auch wo kein einzelner Hersteller es kann, und ist die Person, die ein Vorstand fragen kann „warum war das Überweisungssystem sechs Stunden ausgefallen?“ und eine Antwort bekommt statt einer Runde Fingerzeigen.

2. Wählen und gestalten Sie das SIAM-Modell bewusst und schreiben Sie es dann in die Verträge. Entscheiden Sie früh, ob der Service Integrator intern, extern oder ein Hybrid ist, und seien Sie ehrlich über den Zielkonflikt: Ein interner Integrator behält Kontrolle und Wissen, verlangt aber knappe Fähigkeit; ein externer kauft Reife, fügt aber eine zu steuernde Schicht und einen potenziellen Interessenkonflikt hinzu, wenn er auch einen Turm betreibt. Definieren Sie die Türme, die übergreifenden Prozesse, die der Integrator verantwortet, und die Kooperationspflichten jedes Anbieters. Entscheidend ist, dass diese Pflichten im Vertrag jedes Anbieters stehen – eine Pflicht zur Kooperation, zur Teilnahme an der Major-Incident-Bridge des Integrators, zum Datenteilen –, denn ein Lieferant wird zur Laufzeit nur das tun, wofür er bei der Vergabe gekauft wurde (siehe Thema 6.3 — Beschaffung und Vertragsgestaltung).

3. Segmentieren Sie Ihre Lieferanten und richten Sie Aufmerksamkeit dorthin, wo sie zählt. Nicht jeder Hersteller verdient dieselbe Governance; einen Commodity-Lizenzweiterverkäufer wie einen strategischen EPR-Partner zu behandeln verschwendet Aufwand und lässt die Beziehungen verhungern, auf die es ankommt. Nutzen Sie ein Segmentierungsmodell wie die Kraljic-Matrix, um Lieferanten nach geschäftlicher Kritikalität und Marktschwierigkeit in strategische, Hebel-, Engpass- und Commodity-Kategorien zu sortieren, und stimmen Sie den Governance-Rhythmus auf das Segment ab – vierteljährliche Executive Business Reviews für strategische Partner, leichte Leistungsüberwachung für Commodities. So richten Sie auch Assurance, Beziehungsinvestition und Ausstiegsplanung auf die wenigen Lieferanten, deren Ausfall wirklich schmerzen würde.

4. Managen Sie Ergebnisse und Erfahrung, nicht nur Komponentenkennzahlen. Ein Lieferantenbestand kann jede einzelne SLA treffen – 99,9 % Serververfügbarkeit, Tickets im Ziel geschlossen –, während der tatsächliche Tag der Klinikerin miserabel und der Pfad Ende-zu-Ende gebrochen ist. Ergänzen Sie Komponenten-SLAs durch Experience-Level-Vereinbarungen und Ende-zu-Ende-Maße, die widerspiegeln, was Patientinnen und Personal erleben, und hüten Sie sich vor „Wassermelonen“-Berichten: außen grün, innen rot. Wo eine Kennzahl durch Tricksen erfüllt werden kann (Tickets schließen und wieder öffnen, Schweregrade umklassifizieren), gestalten Sie sie so um, dass der Anreiz des Lieferanten mit dem Ergebnis übereinstimmt, das Sie tatsächlich wollen.

5. Führen Sie einen integrierten Incident- und Problemprozess über alle Lieferanten. Wenn ein Incident mehrere Hersteller umspannt, ist das „Drehstuhl“-Problem – jeder Lieferant besteht darauf, der Fehler liege anderswo, während der Dienst ausgefallen bleibt – das schädlichste Muster im Multi-Sourcing. Geben Sie dem Service Integrator die Befugnis, einen Major Incident auszurufen, jeden relevanten Anbieter auf eine Bridge zu holen und die Lösung voranzutreiben, unabhängig davon, wessen Komponente schuld ist, mit einer schuldunabhängigen Regel „erst beheben, dann Schuld zuweisen“. Das spiegelt die internen ITIL-Disziplinen, die Ihre Servicemanagement-Funktion ohnehin betreibt (siehe Thema 3.8 — Servicemanagement und Live-Betrieb), über die vertragliche Grenze hinaus erweitert, damit sich eine Lieferkette in einer Krise wie ein Betriebsteam verhält.

6. Machen Sie Vertrags- und Leistungsmanagement zu einer aktiven, belegten Disziplin. Ein nach der Unterschrift in der Schublade liegender Vertrag ist aufgegebenes Geld und aufgegebene Hebelwirkung. Halten Sie strukturierte Leistungsüberprüfungen gegen die SLAs ab, verfolgen und beanspruchen Sie Service Credits tatsächlich, wo sie fällig sind, führen Sie ein gemeinsames Risiko- und Issue-Register und pflegen Sie eine prüfbare Leistungsakte, die bei Verlängerung oder Streit zählt. Service Credits sind nicht der Punkt – sie sind ein Signal und ein Hebel; eine reife Beziehung nutzt anhaltende Minderleistung, um Verbesserungspläne und schließlich den Ausstieg auszulösen, nicht bloß, um einen kleinen Rabatt einzufahren (siehe Thema 6.4 — Governance und Assurance).

7. Lassen Sie Pflichten zu klinischer Sicherheit, Datenschutz und Cyber die ganze Kette hinabfließen. Ihre gesetzlichen Pflichten enden nicht bei Ihrem Hauptlieferanten; sie müssen den Unterauftragnehmer erreichen, der die Daten hostet, und die Open-Source-Bibliothek im Produkt. Verlangen Sie das Durchreichen (Flow-down) der Pflichten zur klinischen Sicherheit nach den einschlägigen Standards, Auftragsverarbeitungsbedingungen und Cyber-Kontrollen nach den Lieferketten-Leitlinien des NCSC, und verlangen Sie Sicht auf Vierte Parteien, damit Sie wissen, wer wirklich in der Kette ist. Bewerten Sie Konzentrationsrisiko ausdrücklich – wenn drei Ihrer kritischen Dienste auf einer Hyperscaler-Region oder einem Managed-Service-Anbieter sitzen, ist ein einzelner Ausfall ein regionaler Ausfall, und die Minderung ist eine Entscheidung, die der Vorstand wissentlich treffen muss (siehe Thema 3.9 — Business Continuity und Disaster Recovery).

8. Planen Sie den Ausstieg, bevor Sie verzweifelt gehen wollen. Der billigste Zeitpunkt, Ihre Fähigkeit zu gehen zu sichern, ist vor der Unterschrift; in dem Moment, in dem Sie sie am meisten brauchen, ist alle Hebelwirkung dahin. Pflegen Sie für jeden kritischen Lieferanten einen lebenden Ausstiegsplan, der Datenextraktion in offenen, dokumentierten Formaten, Wissenstransfer, Pflichten zur Übergangsunterstützung und die Assets und Lizenzen abdeckt, die Sie anderswo neu bereitstellen müssten. Echte Portabilität wird bewiesen, nicht versprochen – testen Sie, dass Sie Ihre Daten exportieren und anderswo hochziehen können, denn ein vertragliches Recht auf Ihre Daten in einem proprietären Dump ist nicht dasselbe, wie sie nutzen zu können (siehe Thema 4.0 — Technische Architektur, Cloud und Altsysteme zur praktischen Vermeidung von Vendor Lock-in).

Fragen zur Diskussion im Team#

1. Wenn ein Incident um 2 Uhr nachts drei Lieferanten überquert, wer hat die Befugnis, sie alle wie ein Team handeln zu lassen – und verpflichtet jeder Vertrag sie, den Ruf zu beantworten? Das ist wichtig, weil das Drehstuhl-Versagen keine technische Lücke, sondern eine Befugnislücke ist: Lieferanten verhalten sich rational, wenn sie ihre eigene SLA verteidigen und Schuld abwälzen, und nur ein benannter Integrator mit vertraglichem Rückhalt kann das übersteuern. Debattieren Sie ehrlich, ob es eine solche Rolle in Ihrer Organisation heute gibt, ob sie echte Befugnis hat oder nur einberuft und bittet und ob Ihre Anbieterverträge Kooperation an einer gemeinsamen Major-Incident-Bridge tatsächlich verlangen oder nur anregen. Bedenken Sie die härtesten Fälle – ein Fehler, der einen nationalen Dienst, einen Hosting-Anbieter und einen Anwendungshersteller umspannt, bei dem die Grundursache in der ersten Stunde wirklich mehrdeutig ist. Sehen Sie, ob Sie eine schuldunabhängige Regel „erst wiederherstellen, dann zuweisen“ betreiben oder die Lösung stockt, während Kommerzteams über Haftung streiten. Eine gute Antwort benennt den rechenschaftspflichtigen Integrator, verweist auf die Vertragsklauseln, die Kooperation erzwingen, und kann einen jüngsten Incident über mehrere Lieferanten beschreiben, in dem das Modell hielt – oder räumt offen ein, dass es beim letzten Mal nicht hielt.

2. Auf den plötzlichen Verlust welcher Lieferanten könnten wir uns wirklich nicht einstellen – und was würden wir am Morgen ihres Ausfalls tatsächlich tun? Das erzwingt das Gespräch über Konzentrationsrisiko, das die Bequemlichkeit des Sourcing gern begräbt: Der Bestand häuft Abhängigkeiten von einigen strategischen Partnern und einer Handvoll Plattformen an, und die aggregierte Exposition wird selten kartiert, bis ein Vorfall sie offenbart. Besprechen Sie, welche Hersteller Single Points of Failure für einen klinischen Dienst sind, ob die Abhängigkeit vertraglich, technisch oder wissensbasiert ist und wie tief in die Kette der Vierten Parteien das reale Risiko sitzt – der Unterverarbeiter, das Offshore-Supportteam, die eine Hyperscaler-Region. Wägen Sie den Zielkonflikt ehrlich ab: Konsolidierung kauft Effizienz, Integration und bessere Preise, Diversifizierung kauft Resilienz zu Kosten, und die richtige Antwort ist eine bewusste Vorstandsentscheidung, kein Zufall vergangener Beschaffungen. Bedenken Sie, ob Ihre Ausstiegs- und Kontinuitätspläne für diese Lieferanten getestet oder nur geschrieben sind und ob Sie Ihre Daten extrahieren und neu hosten könnten, wenn ein Lieferant nächste Woche insolvent würde. Eine ehrliche Antwort unterscheidet die Lieferanten, die Sie managen, von den wenigen, deren Ausfall ein existenzielles Ereignis ist, und zeigt, dass das Restrisiko bei Letzteren bewusst auf der richtigen Ebene akzeptiert wurde.

3. Messen wir, was unser Klinikpersonal und unsere Patientinnen erleben, oder nur, was unsere Lieferanten leicht grün berichten? Diese Frage macht die Lücke zwischen Komponenten-SLAs und realen Ergebnissen sichtbar, in der multi-gesourcte Dienste still enttäuschen, obwohl jedes Dashboard grün ist. Erkunden Sie, wo sich „Wassermelonen“-Berichte in Ihrem Bestand verstecken – die einzeln erfüllten Kennzahlen, die sich zu einem gebrochenen Pfad addieren, die Tickets, die geschlossen werden, indem man die Nutzerin bittet, es erneut zu versuchen, die Verfügbarkeit, gemessen an einem Server, den kein Klinikpersonal berührt. Debattieren Sie, ob Sie echte Ende-zu-Ende- oder Experience-Level-Maße haben, wer sie verantwortet und ob Lieferanten auf das gewünschte Ergebnis oder einen Proxy angereizt werden, den sie manipulieren können. Bedenken Sie die Spannung, dass reichere, erfahrungsbasierte Messung Geld und Aufwand kostet und von Lieferanten angefochten werden kann, deren Credits an der alten Kennzahl hängen. Eine starke Antwort kann auf mindestens ein Ende-zu-Ende-Maß verweisen, das die Realität der Nutzerin widerspiegelt, erklärt, wie es über Lieferanten hinweg gesteuert wird, und ist offen, wo aktuelle SLAs das falsche Verhalten belohnen und beim nächsten Break Point neu verhandelt werden müssen.

4. Wer sollte unsere Integrationsschicht betreiben – ein internes Team, ein externer Lieferant oder ein Hybrid – und waren wir ehrlich über den Interessenkonflikt, den diese Wahl erzeugt? Die Entscheidung selbst machen oder kaufen für den Service Integrator selbst wird oft per Voreinstellung statt bewusst getroffen und prägt jede folgende Beziehung. Debattieren Sie den realen Zielkonflikt: Ein interner Integrator hält Wissen und Kontrolle in der beibehaltenen Organisation, verlangt aber knappe, teure Fähigkeit, die ein Trust womöglich nicht halten kann; ein externer Integrator kauft schnell Reife und Werkzeuge, fügt aber eine zu steuernde Schicht hinzu und wird akut problematisch, wenn derselbe Lieferant auch einen Service-Turm betreibt und faktisch seine eigenen Hausaufgaben benotet. Bedenken Sie die Mittelfälle – ein Hybrid, in dem die beibehaltene Organisation Rechenschaft und Schlichtung besitzt, während ein Partner die operative Maschinerie liefert – und ob Ihre Organisation die kommerzielle und technische Seniorität hat, einen Integrator zu führen, statt von ihm geführt zu werden. Schauen Sie ehrlich, wo das Integrationswissen heute tatsächlich lebt und was mit Ihrer Ende-zu-Ende-Sicht geschieht, wenn der Vertrag dieses Integrators endet. Eine ehrliche Antwort benennt, wer integriert, erklärt, warum dieses Modell für Ihren Kontext gewählt statt geerbt wurde, und kann auf die Sicherungen verweisen, die einen Integrator, der auch Dienste liefert, daran hindern, seine eigene Leistung zu benoten.

5. Erreichen unsere gesetzlichen Pflichten zu klinischer Sicherheit, Datenschutz und Cybersicherheit tatsächlich die Vierten Parteien tief in der Kette – oder enden sie beim Hauptlieferanten, mit dem wir unterschrieben haben? Das ist wichtig, weil die Rechenschaft für ein Ereignis der Patientensicherheit oder eine Datenpanne nicht dem Vertrag folgt; sie bleibt bei der beibehaltenen Organisation, auch wenn der Ausfall drei Ebenen tiefer geschah, bei einem Unterverarbeiter oder einem Offshore-Supportteam, das Sie nie gewählt haben. Prüfen Sie, ob Ihre Flow-down-Klauseln real und getestet sind – ob Pflichten zur klinischen Sicherheit nach den einschlägigen Standards, Auftragsverarbeitungsbedingungen und Cyber-Kontrollen Unterauftragnehmern wirklich vertraglich auferlegt sind – und ob Sie überhaupt Sicht darauf haben, wer diese Unterauftragnehmer sind. Besprechen Sie die Spannung, dass Hauptlieferanten sich sträuben, ihre Lieferkette als kommerziell sensibel offenzulegen, während Sie ein Risiko, das Sie nicht sehen, nicht bewerten können, und dass die Forderung nach Transparenz der Vierten Parteien die Beschaffung verlangsamen und den Markt verengen kann. Bedenken Sie den konkreten Fehler – die Open-Source-Bibliothek in einem Produkt, der Hosting-Unterauftragnehmer, das Analytikwerkzeug eines Dritten – und ob ein Vorfall dort Ihre Pflichten durchsetzbar oder bloß erhofft vorfände. Eine starke Antwort zeigt, dass Flow-down geschrieben, belegt und gelegentlich auditiert statt angenommen ist, und kann benennen, wo in der Kette die Sicht derzeit endet.

6. Wer managt den Vertrag nach der Unterschrift aktiv – Credits beanspruchen, Verbesserung vorantreiben und Lieferanten an den gekauften Wert halten –, statt ihn in einer Schublade abzulegen? Das bestimmende Versickern im Multi-Sourcing geschieht nach der Vergabe, wenn die Aufmerksamkeit der Beschaffung weiterzieht und niemand die Jahre von Betrieb und Ablauf verantwortet, in denen Wert realisiert oder still verloren wird. Debattieren Sie, ob Sie strukturierte Leistungsüberprüfungen gegen die SLAs halten, ob Sie die Ihnen zustehenden Service Credits tatsächlich verfolgen und beanspruchen und ob anhaltende Minderleistung einen Verbesserungsplan auslöst oder einfach absorbiert wird. Bedenken Sie die Spannung, dass das Jagen von Credits eine Beziehung, von der Sie abhängen, verderben kann und ein reifer Ansatz Credits als Signal und Hebel zur Verbesserung statt als einzufahrenden Rabatt behandelt – Lieferanten aber schnell lernen, welche Kunden nie nachsehen. Prüfen Sie, ob Sie eine prüfbare Leistungsakte führen, die bei Verlängerung oder Streit zählt, und ob kontinuierliche Verbesserung eine vertragliche Erwartung oder ein gelegentlicher Gefallen ist. Eine ehrliche Antwort beschreibt, wer jede strategische Beziehung verantwortet, verweist auf einen jüngsten Fall, in dem belegtes Leistungsmanagement das Verhalten eines Lieferanten änderte, und räumt offen ein, wo Verträge ungemanagt laufen und Wert Jahr für Jahr versickert.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Das Integrated Care System Northmoor betreibt eine für seine Größe typische digitale Landschaft: eine gehostete elektronische Patientenakte eines großen Herstellers, eine Plattform für gemeinsame Patientenakten von einem anderen, eine Integrations-Engine und Schnittstellenschicht von einem Spezialisten, nationale Dienste von NHS England, Konnektivität von einem Netzwerkanbieter und einen Managed-Service-Desk, betrieben von einem Systemintegrator, dessen First-Line-Support selbst offshore untervergeben ist. Jeder Vertrag wurde über ein Jahrzehnt separat beschafft, jeder hat seine eigene SLA, und – bis vor Kurzem – wurde jeder von einer anderen Managerin in einem anderen Direktorat gesteuert.

Das Problem kündigt sich an einem Montag an. Klinikpersonal meldet, dass Hausarztüberweisungen mit fehlenden Anhängen, manchmal stundenlang verspätet, im Akut-Trust ankommen. Der EPR-Hersteller meldet 100 % Verfügbarkeit und schließt das Ticket. Der Integrationslieferant sagt, seine Engine reiche jede Nachricht durch, die sie erhält. Der Hersteller der gemeinsamen Patientenakte sagt dasselbe. Der Netzwerkanbieter zeigt keine Störungen. Jeder Lieferant ist grün; der Überweisungspfad ist auf Gelb-Richtung-Rot; und niemand besitzt den Pfeil zwischen den Kästen. Neun Tage lang warten Patientinnen, während die Tickets hin- und herspringen.

Northmoors Antwort ist, in der beibehaltenen Organisation eine Service-Integrationsfunktion einzurichten, geleitet von einer Leiterin für Lieferanten- und Servicemanagement mit einem kleinen Team und – entscheidend – vom Vorstand mandatierter Befugnis. Sie segmentieren zuerst den Bestand – EPR, gemeinsame Patientenakte und Integrationslieferant werden als strategisch eingestuft, der Netzwerkanbieter als Engpasslieferant, die Lizenzweiterverkäufer als Commodity – und setzen einen passenden Governance-Rhythmus. Dann schreiben sie den operativen Anhang jedes strategischen Vertrags bei dessen nächster Break-Klausel um, sodass er die Pflicht enthält, innerhalb von dreißig Minuten der Major-Incident-Bridge des Integrators beizutreten und auf Anfrage Diagnosedaten zu teilen. Ein Ende-zu-Ende-Maß „Überweisung vollständig und pünktlich zugestellt“ wird definiert und neben den Komponenten-SLAs berichtet, verantwortet vom Integrator, nicht von einem einzelnen Hersteller.

Der Test kommt sechs Monate später, als Ergebnisnachrichten still zu scheitern beginnen. Diesmal ruft der Integrator innerhalb der Stunde einen Major Incident aus, holt alle drei strategischen Lieferanten plus den Netzwerkanbieter unter einer schuldunabhängigen Regel auf eine Bridge und treibt sie an, die Nachricht Ende-zu-Ende zu verfolgen. Die Grundursache ist eine Änderung der Zeichenkodierung, die der Integrationslieferant ausgerollt hatte und die die EPR nicht parsen konnte – ein Fehler, der genau in der Nahtstelle lag, die kein einzelner Lieferant sehen konnte. Er ist in vier Stunden behoben, ein gemeinsamer Problemdatensatz hält die Korrektur fest, und ein Service Credit wird beansprucht und in eine gemeinsame Regressionstest-Suite reinvestiert. Währenddessen vermerkt das ICS still, dass alle drei strategischen Lieferanten in derselben Cloud-Region hosten, hält das Konzentrationsrisiko im Board Assurance Framework fest und beauftragt eine getestete Datenextraktions-Übung, sodass Portabilität, falls es je umziehen muss, bewiesen statt versprochen ist.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit sitzt meist auf der anderen Seite dieses Themas – es ist der Lieferant, der integriert wird, und seine kommerzielle Zukunft hängt davon ab, ein guter Bürger im SIAM-Modell eines anderen zu sein. NHS-Aufträge zu gewinnen bedeutet zunehmend zu beweisen, dass Sie einer Major-Incident-Bridge beitreten, Ihre Unterverarbeiter offenlegen, Pflichten zu klinischer Sicherheit und Datenschutz durchreichen und Daten beim Ausstieg sauber zurückgeben; diese Kooperationsfähigkeiten früh aufzubauen ist ein Wettbewerbsvorteil, kein Overhead. Intern ist ein Startup zugleich Konsument kritischer Dritter – des eigenen Cloud-Hosts, Zahlungsabwicklers und Authentifizierungsanbieters – und trägt echtes Konzentrationsrisiko bei fast keiner Hebelwirkung gegenüber Herstellern, die weit größer sind als es selbst. Die Disziplin, die skaliert, ist, die Abhängigkeitskarte aktuell zu halten, architektonisches Lock-in zu vermeiden, wo billige Wechselkosten verfügbar sind, und gegenüber Kunden ehrlich über die Vierten Parteien in der eigenen Kette zu sein.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder Anbieter häuslicher Pflege, eine Einzelstandort-Klinik – trägt dieselben gesetzlichen Pflichten zu klinischer Sicherheit, Datenschutz und Cybersicherheit wie ein großer Trust, managt aber einen Stapel von Lieferanten ohne dedizierte IT-Funktion und mit wenig vertraglicher Hebelwirkung. In der Praxis fällt die ganze SIAM-Disziplin auf ein oder zwei Menschen zusammen, die auch andere Aufgaben haben; der realistische Schritt ist daher, die zwei oder drei Lieferanten zu identifizieren, von denen ein klinischer Tag wirklich abhängt – das klinische System, die Konnektivität, die Verbindung zur gemeinsamen Akte –, diese Beziehungen bewusst zu managen und beim Rest eine leichtere Hand zu akzeptieren. Konzentrationsrisiko ist akut und unvermeidlich: Ein einzelnes Praxismanagementsystem oder eine einzelne Breitbandleitung kann ein völliger Single Point of Failure sein, und die Minderung ist oft operativ (ein Ausfallverfahren, eine zweite Verbindung) statt ein zweiter Lieferant. Ausstieg und Portabilität zählen hier ebenso, denn ein kleiner Anbieter, der an eine proprietäre Akte gebunden ist, hat noch weniger Macht zu wechseln; die Fragen, auf die Sie einen Lieferanten drängen sollten, sind Datenexport in offenem Format und was geschieht, wenn der Vertrag endet. Ein kleiner Health-Tech-Lieferant jenseits der Startup-Phase steht vor dem Spiegelbild: Er muss die Pflichten zu Kooperation, Flow-down und Ausstieg erfüllen, die seine NHS-Kunden nun verlangen, ohne das Compliance-Team, das ein größerer Hersteller hätte.

Großunternehmen#

Ein großer Trust, ein Provider-Kollaborativ oder ein ICS ist der archetypische SIAM-Kunde: Dutzende Lieferanten, ein langlebiger, durch aufeinanderfolgende Beschaffungen zusammengesetzter Bestand und Dienste, deren Ende-zu-Ende-Verhalten niemand ganz verantwortet. Das realistische Ziel ist eine funktionierende beibehaltene Organisation mit echter Service-Integrationsfähigkeit, Lieferantensegmentierung, damit Aufmerksamkeit zu den strategischen Wenigen fließt, und übergreifendem Incident- und Problemmanagement, das über vertragliche Grenzen hinweg funktioniert – keine Fantasie perfekt aufeinander abgestimmter SLAs. Die schwerste Arbeit ist vertraglich und kulturell: Kooperationspflichten in Altvereinbarungen nachzurüsten, wo Break-Klauseln es erlauben, und Lieferanten davon zu verschieben, ihren Kasten zu verteidigen, hin dazu, ihren Anteil am Ganzen zu verantworten. In dieser Größenordnung kommen die größten Resilienzgewinne daher, Konzentrationsrisiko über das Portfolio zu kartieren und den Ausstieg für die Handvoll Lieferanten zu testen, deren Ausfall ein regionales Ereignis wäre.

Regierung#

Eine nationale Stelle – NHS England, ein dezentrales Gesundheitsministerium oder ein Rahmenvertragsbetreiber wie der Crown Commercial Service – prägt das Umfeld, in dem jeder Trust seine Lieferanten managt. Ihr Hebel ist, Erwartungen über das Sourcing Playbook der Government Commercial Function und Standardbedingungen zu setzen, Kooperation, Portabilität und Lieferkettenassurance zum Marktstandard zu machen, statt dass jeder Käufer sie allein aus der Schwäche verhandelt. Die Regierung trägt auch die Systemsicht: Sie kann sehen, was ein einzelner Trust nicht sehen kann – wenn ein einzelner Lieferant oder eine Plattform zum kritischen Dritten für das ganze System geworden ist –, und muss diese Konzentration als Frage der nationalen Resilienz managen. Ihre Pflicht ist sicherzustellen, dass Rahmenvertragsdesign, Assurance-Regime und nationale Dienste Lock-in und Single Points of Failure verringern, statt sie zu verfestigen (siehe Thema 9.1 — Zusammenarbeit mit lokalen und nationalen Regierungen).

Häufige Fehlermuster#

• Das Verantwortungsvakuum. Jeder Lieferant besitzt eine Komponente, keiner den Ende-zu-Ende-Dienst; grenzüberschreitende Probleme haben kein Zuhause. Benennen Sie einen rechenschaftspflichtigen Integrator mit echter Befugnis.
• Der Drehstuhl-Incident. Lieferanten wälzen Schuld ab, während der Dienst ausgefallen bleibt und niemand befugt ist, sie zur Kooperation zu bringen. Schreiben Sie eine einzige Major-Incident-Bridge und eine schuldunabhängige Regel „erst wiederherstellen“ in jeden Vertrag.
• Wassermelonen-SLAs. Jede Komponentenkennzahl ist grün, während der tatsächliche Dienst rot ist; Lieferanten berichten an die Kennzahl, nicht an das Ergebnis. Fügen Sie Ende-zu-Ende- und Experience-Level-Maße hinzu, die der Integrator verantwortet.
• Einheitliche Governance. Einen Commodity-Weiterverkäufer und einen strategischen EPR-Partner gleich zu behandeln verschwendet Aufwand und lässt die Beziehungen verhungern, auf die es ankommt. Segmentieren Sie Lieferanten und stimmen Sie den Governance-Rhythmus auf die Kritikalität ab.
• Der Vertrag in der Schublade. Nach der Unterschrift managt niemand die Leistung, beansprucht Credits oder treibt Verbesserung voran, sodass Wert Jahr für Jahr versickert. Führen Sie aktives, belegtes Vertragsmanagement.
• Unsichtbare Vierte Parteien. Pflichten werden an den Hauptlieferanten weitergereicht und enden dort, sodass unbekannte Unterauftragnehmer die Daten oder das Risiko halten. Verlangen Sie Lieferkettensicht und Flow-down der Kontrollen bis nach unten.
• Ungemanagte Konzentration. Kritische Dienste konsolidieren sich still auf einen Lieferanten, eine Plattform oder Region, bis ein einzelner Ausfall systemisch wird. Kartieren und akzeptieren Sie Konzentrationsrisiko bewusst auf Vorstandsebene.
• Der theoretische Ausstieg. Ein nie getestetes vertragliches Recht auf Ihre Daten ist keine Portabilität. Beweisen Sie Datenextraktion und Neu-Hosting, bevor Sie es brauchen.

Reifegradmodell#

Checkliste#

• Eine benannte Rolle in der beibehaltenen Organisation ist für den Ende-zu-Ende-Dienst rechenschaftspflichtig und hält die Ende-zu-Ende-SLA.
• Das SIAM-Modell – Integrator, Türme, übergreifende Prozesse – ist definiert und in Lieferantenverträge geschrieben.
• Lieferanten sind nach Kritikalität segmentiert, mit einem zum Segment passenden Governance-Rhythmus.
• Ende-zu-Ende- und Experience-Level-Maße ergänzen Komponenten-SLAs und werden vom Integrator verantwortet.
• Ein einziger lieferantenübergreifender Major-Incident-Prozess existiert, mit einer vertraglich vorgeschriebenen schuldunabhängigen Regel „erst wiederherstellen“.
• Vertragsleistung wird aktiv überprüft, Service Credits werden verfolgt und beansprucht, und Verbesserungspläne werden ausgelöst.
• Pflichten zu klinischer Sicherheit, Datenschutz und Cyber sind an Unterauftragnehmer durchgereicht, mit Sicht auf Vierte Parteien.
• Konzentrationsrisiko über Lieferanten, Plattformen und Regionen ist kartiert und bewusst auf Vorstandsebene akzeptiert.
• Für jeden kritischen Lieferanten existiert ein lebender Ausstiegsplan, der Daten, Wissen und Übergangsunterstützung abdeckt.
• Datenextraktion und Neu-Hosting wurden für kritische Dienste getestet, nicht nur vertraglich versprochen.

Zentrale Quellen#

• Scopism — SIAM Body of Knowledge und SIAM Professional Body of Knowledge — die maßgebliche offene Referenz für Rollen, Strukturen und Prozesse von Service Integration and Management.
• AXELOS — ITIL 4 — Praktiken des IT-Servicemanagements für Incident, Problem, Change und Lieferantenmanagement, die SIAM über Lieferanten hinweg erweitert.
• UK Government Commercial Function — The Sourcing Playbook und Outsourcing Playbook — Leitlinien des öffentlichen Sektors zu Sourcing, Vertragsmanagement und Ausstieg.
• Crown Commercial Service — Rahmenverträge und Standardbedingungen für die Beschaffung von Technologie und Managed Services im öffentlichen Sektor.
• National Cyber Security Centre (NCSC) — Supply chain security guidance — Bewertung und Management von Cyberrisiko über Lieferanten und Unterauftragnehmer.
• HM Government / Cabinet Office — Leitlinien zum Management kritischer Dritter und von Konzentrationsrisiko in öffentlichen Diensten.
• NHS England — Standards der klinischen Sicherheit DCB0129/DCB0160 und Anforderungen der Auftragsverarbeitung, die an Lieferanten durchzureichen sind.

Referenzen#

1. Service integration and management — Wikipedia — https://en.wikipedia.org/wiki/Service_integration_and_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Outsourcing
5. Business process outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Business_process_outsourcing
6. Managed services — Wikipedia — https://en.wikipedia.org/wiki/Managed_services
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Third-party management — Wikipedia — https://en.wikipedia.org/wiki/Third-party_management
9. Supply chain — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain
10. Supply chain risk management — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_risk_management
11. Concentration risk — Wikipedia — https://en.wikipedia.org/wiki/Concentration_risk
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
14. Kraljic matrix — Wikipedia — https://en.wikipedia.org/wiki/Kraljic_matrix
15. Scopism — SIAM Body of Knowledge — https://www.scopism.com/
16. AXELOS — ITIL 4 — https://www.axelos.com/certifications/itil-service-management
17. UK Government Commercial Function — The Sourcing Playbook — GOV.UK — https://www.gov.uk/government/publications/the-sourcing-playbook
18. National Cyber Security Centre — Supply chain security guidance — NCSC — https://www.ncsc.gov.uk/collection/supply-chain-security
19. Crown Commercial Service — GOV.UK — https://www.gov.uk/government/organisations/crown-commercial-service