トピック6.6 — ベンダーとサービス統合の管理(SIAM)

数十のサプライヤーから縫い合わされた医療・ケアの環境では、患者と臨床家が実際に経験するサービスは、ベンダー間の継ぎ目と同じだけしか良くありません。したがって、誰かが、単一の契約では記述されない、端から端までの全体を所有しなければなりません。

医療・ケアにおいてなぜ重要か#

現代のNHSトラストや統合ケアシステム(ICS)は、一つのサプライヤーの上では動いていません。単一の臨床ワークフロー、つまり外来の予約、手紙、検査結果、処方になるGPの紹介は、あるベンダーの電子患者記録、別のベンダーの連携エンジン、三つ目のベンダーのホスティングのプラットフォーム、ネットワークの提供者、国のSpineサービス、そして会ったこともない第四の当事者が運営するマネージドサービスのデスクを横断しうるのです。それぞれの部分の契約は、健全かもしれません。患者が受け取るサービスは、それらの間の隙間に存在します。

これは、商務上の関係の、運用と稼働の側面であり、価値が実現されるか静かに失われるかの分かれ目です。調達と商務のチーム(トピック6.3 — 調達と商務参照)は、うまく購入し、契約を締結し、署名された合意を引き継ぎます。その後の何年かに起きること、つまりサプライヤーが協力するか互いを責めるか、障害が1時間で直るか1週間膿むか、そしていつか離れられるかは、ベンダーとサービス統合の管理の仕事です。これを誤れば、その失敗は抽象的ではありません。結果を黙って落とす病理のインターフェース、古いアレルギーを表示する共有ケア記録、引き継ぎの時間に臨床家を締め出す認証サービス。これらは、連携の問題として始まる患者安全の事象です(トピック1.6 — 臨床安全とリスクマネジメント参照)。

賭け金は、このセクターの三つの特徴によって鋭くなります。公金は、購入された成果が、届けられた成果であること、そしてサービスクレジットと価値が、放置されるのではなく、積極的に追求されることを求めます。データ保護、臨床安全、サイバーセキュリティの法定の義務は、選んでいない下請け業者を含め、サプライチェーン全体に流れ下らなければなりません(トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照)。そして、重要なサービスが少数の大手サプライヤーに集中していることは、一つのベンダーのランサムウェアのインシデント、破綻、キャパシティの失敗が、一つの地域全体をオフラインにしうることを意味します。サプライヤーを、一度に一つの契約ではなく、ポートフォリオとして管理することは、いまや、管理上ではなく、レジリエンスの責務です。

中核概念#

サービスの統合と管理(SIAM)は、複数のサービス提供者を調整し、統合して、事業に単一の端から端までのサービスを届けるための、管理のアプローチです。それは、組織が単一の元請けからマルチソースの運用モデルへ移り、その後、誰かがまだ、部品を全体として機能させなければならないことを発見したために、まさに規律として生まれました。SIAMは購入するプロダクトではなく、定義された役割、プロセス、ガバナンスを伴う運用モデルです。権威ある参照は、ScopismのSIAM Body of Knowledgeで、それはITILと、ITサービスマネジメント(ITSM)のより広い実践に取って代わるのではなく、並んで位置します。

SIAMのモデルには、三つの層があります。顧客、あるいは保持される組織は、決して外注できない説明責任、つまり戦略、需要、アーキテクチャ、商務上の所有、そして患者に対する最終的な注意義務を保ちます。サービスインテグレーターは、内部のチーム、外部のサプライヤー、あるいはハイブリッドで、提供者を調整し、重大インシデント管理のような横断的なプロセスを所有し、端から端までのビューを保つ層です。サービス提供者は、しばしばサービスタワー(ホスティング、エンドユーザーコンピューティング、臨床アプリケーション、ネットワーク)に組織され、それぞれが定義された一片を届けます。これらは、百科事典の項目ではなく、SIAMの専門用語であるため、ここでは平易な言葉で名指しし、SIAMの知識体系に基礎づけています。

その下に、商務の仕組みがあります。アウトソーシングと、そのデータとプロセスの変形であるビジネスプロセスアウトソーシングは、仕事を外部の提供者に委ねることを述べ、マネージドサービスは、あなたに代わるシステムの継続的でサブスクリプション型の運用を述べます。実績は、サービスレベル契約(SLA)、つまり測定可能で、通常は契約上の約束によって統治され、ますます、サプライヤーが達成するのに都合のよい構成要素の指標ではなく、利用者が実際に経験する成果を測定する経験レベル契約(XLA)によって補完されます。XLAには、定まった百科事典の項目がありません。標準ではなく、新しい実践として扱ってください。

二つのリスクの概念が、本トピックを枠づけます。サードパーティ管理は、外部の提供者、そして決定的に、彼ら自身の下請け業者、つまりサプライチェーンの深くにいる第四の当事者を監督する規律です。サプライチェーンのリスク管理は、そのチェーンを通じて伝わる失敗に対処し、銀行業から借りた用語である集中リスクは、単一のサプライヤー、プラットフォーム、地域に過度に依存する危険を捉えます。これらを管理することが、便利な調達の判断が、システム全体の脆弱性になるのを防ぎます。最後に、ベンダーロックインを避けることと、継続的改善を推進することは、稼働中のサービスが硬直化するのを防ぐ、二つの前向きな責務です。

ベストプラクティス#

  1. 各契約だけでなく、端から端までのサービスに説明責任を負う所有者を指名する。 マルチソースの決定的な失敗は、全員が箱を所有し、その間の矢印を誰も所有しないことです。利用者が経験するとおりの、臨床または事業のサービス全体に説明責任を負い、サプライヤーを招集し仲裁する権限を持つ、保持される組織の役割、しばしばサービスインテグレーションのリードやサプライヤー管理オフィスを確立します。この所有者は、どの単一のベンダーにもできないところで、端から端までのSLAを保持し、取締役会が「なぜ紹介システムが6時間止まったのか」と尋ねて、責任のなすり合いではなく答えを得られる人です。

  2. SIAMのモデルを意図して選び、設計し、契約に書き込む。 サービスインテグレーターが、内部か、外部か、ハイブリッドかを早期に決め、トレードオフについて誠実になります。内部のインテグレーターは、管理と知識を保ちますが、乏しい能力を求め、外部のものは成熟を買いますが、統治すべき層を加え、同じ会社がタワーも運営する場合は、利益相反の可能性があります。タワー、インテグレーターが所有する横断的なプロセス、あらゆる提供者の協力の義務を定義します。決定的に、これらの義務は、各提供者の契約に現れなければなりません。協力する義務、インテグレーターの重大インシデントのブリッジに参加する義務、データを共有する義務。サプライヤーは、落札時に買われたことだけを、運用時に行うからです(トピック6.3 — 調達と商務参照)。

  3. サプライヤーを分類し、重要なところに注意を向ける。 すべてのベンダーが同じガバナンスに値するわけではありません。コモディティのライセンスの再販業者を、戦略的なEPRのパートナーのように扱うことは、労力を無駄にし、重要な関係を飢えさせます。Kraljicマトリクスのようなセグメンテーションのモデルを使って、サプライヤーを、事業上の重要性と市場の難しさで、戦略、レバレッジ、ボトルネック、コモディティに分類し、ガバナンスのリズムをセグメントに合わせます。戦略的なパートナーには四半期ごとの経営陣の事業レビュー、コモディティには軽い実績の監視。これは、失敗が本当に痛手となる少数のサプライヤーに、保証、関係への投資、退出の計画を集中させる方法でもあります。

  4. 構成要素の指標だけでなく、成果と経験を管理する。 サプライヤーの環境は、あらゆる個別のSLA、つまり99.9%のサーバーの稼働率、目標内に解決されたチケットを達成しながら、臨床家の実際の一日は悲惨で、パスウェイが端から端まで壊れていることがあります。構成要素のSLAを、経験レベル契約と、患者と職員が経験することを反映する、端から端までの尺度で補完し、「ウォーターメロン」報告、つまり外側は緑で内側は赤に注意してください。指標が、ゲーム化して満たせるところ(チケットを閉じて再び開く、重大度を再分類する)では、サプライヤーのインセンティブが、実際に望む成果に整合するよう再設計します。

  5. すべてのサプライヤーにまたがる、統合された一つのインシデントと問題のプロセスを運営する。 インシデントが複数のベンダーにまたがるとき、「回転椅子」問題、つまり、各サプライヤーが、サービスが止まったまま、障害は他にあると主張することは、マルチソースで最も損害の大きい単独のパターンです。サービスインテグレーターに、重大インシデントを宣言し、関連するあらゆる提供者を一つのブリッジに引き入れ、どの構成要素に責任があるかにかかわらず解決を推進する権限を、「まず直し、責任の按分はあとで」という無過失のルールとともに与えます。これは、サービスマネジメントの機能がすでに運営している、内部のITILの規律を反映し(トピック3.8 — サービスマネジメントと稼働中の運用参照)、契約の境界を越えて拡張して、危機の間、サプライチェーンが一つの運用チームとして振る舞うようにします。

  6. 契約と実績の管理を、積極的で、エビデンスに基づく規律にする。 署名のあと引き出しに置かれた契約は、放棄されたお金と梃子です。SLAに対して構造化された実績レビューを行い、サービスクレジットを、当然あるところで追跡し、実際に請求し、共有のリスクと課題の台帳を維持し、更新や紛争のときに重要になる、監査可能な実績の記録を保ちます。サービスクレジットは要点ではなく、シグナルであり梃子です。成熟した関係は、持続的な不振を、少額のリベートを確保するだけのためでなく、改善計画、そして最終的には退出の引き金として使います(トピック6.4 — ガバナンスと保証参照)。

  7. 臨床安全、データ保護、サイバーの義務を、チェーンの末端まで流し下す。 法定の義務は、元請けのサプライヤーで止まりません。データをホストする下請け業者や、プロダクトの内部のオープンソースのライブラリにまで届かなければなりません。関連する標準のもとでの臨床安全の義務、データ処理の条件、NCSCのサプライチェーンのガイダンスに整合したサイバーの統制の流し下しを求め、チェーンに実際に誰がいるかを知るために、第四の当事者の可視性を求めます。集中リスクを明示的に評価します。重要なサービスのうち三つが、一つのハイパースケーラーのリージョンや一つのマネージドサービスの提供者の上にあるなら、単一の失敗が地域の障害になり、その緩和策は、取締役会が承知の上で下さなければならない判断です(トピック3.9 — 事業継続と災害復旧参照)。

  8. 離れたくて必死になる前に、退出を計画する。 離れる能力を確保する最も安価な時期は、署名する前です。それを最も必要とする瞬間には、あなたの梃子はすべて失われています。重要なサプライヤーごとに、オープンで文書化された形式でのデータ抽出、知識移転、移行支援の義務、そして他の場所で再プロビジョニングするために必要な資産とライセンスをカバーする、生きた退出の計画を維持します。本物のポータビリティは、約束されるのではなく、実証されます。データをエクスポートし、他の場所で立ち上げられることをテストしてください。独自形式のダンプでデータに対する契約上の権利を持つことは、それを使えることとは違うからです(実践でのベンダーロックインの回避については、トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム参照)。

チームで話し合うための問い#

  1. 午前2時に、インシデントが三つのサプライヤーにまたがるとき、彼ら全員を一つのチームとして行動させる権限を持つのは誰か。そして、すべての契約が、その呼びかけに応じる義務を彼らに課しているか。 これが重要なのは、回転椅子の失敗が技術的なギャップではなく、権限のギャップだからです。サプライヤーは、自分のSLAを守り、責任を転嫁するときに、合理的に振る舞い、それを覆せるのは、契約の裏づけを持つ指名されたインテグレーターだけです。そのような役割が、今日あなたの組織に存在するか、それが本物の権限を持つのか、招集して頼むだけなのか、そして提供者の契約が、共有の重大インシデントのブリッジでの協力を実際に求めているのか、単に奨励しているだけなのかを、正直に議論します。最も困難なケース、つまり、国のサービス、ホスティングの提供者、アプリケーションのベンダーにまたがる障害で、最初の1時間は根本原因が本当に曖昧なものを考えます。「まず復旧し、按分はあとで」という無過失のルールを運用しているのか、商務のチームが責任を論じあう間、解決が停滞するのかを見ます。良い答えは、説明責任のあるインテグレーターを挙げ、協力を強制する契約の条項を示し、モデルが機能した、最近のサプライヤー横断のインシデントを説明できます。あるいは、前回は機能しなかったと、率直に認めます。

  2. どのサプライヤーの突然の喪失に、私たちは本当に耐えられないか。そして、彼らが失敗した朝に、実際に何をするか。 この問いは、調達の便宜が埋めてしまいがちな、集中リスクの会話を強いるものです。環境は、少数の戦略的パートナーと少数のプラットフォームへの依存を堆積させ、集計された露出は、インシデントがそれを明らかにするまで、めったに描き出されません。どのベンダーが、臨床サービスの単一障害点か、その依存が契約上のものか、技術上のものか、知識上のものか、そして本当のリスクが、第四の当事者のチェーンのどれだけ深くにあるか、つまりサブプロセッサー、オフショアのサポートチーム、一つのハイパースケーラーのリージョンを話し合います。トレードオフを誠実に比較考量します。統合は、効率、連携、より良い価格を買い、多様化は、コストと引き換えにレジリエンスを買い、正しい答えは、過去の調達の偶然ではなく、取締役会の意図した選択です。これらのサプライヤーの退出と継続の計画が、単に書かれているだけでなく、テストされているか、そして来週サプライヤーが破綻したら、データを抽出して再ホストできるかを考えます。誠実な答えは、自分が管理するサプライヤーと、その失敗が存亡に関わる出来事である少数のものを区別し、後者についての残余のリスクが、適切なレベルで意図して受け入れられていることを示します。

  3. 私たちは、臨床家と患者が経験することを測定しているか。それとも、サプライヤーが緑と報告しやすいことだけか。 この問いは、構成要素のSLAと本物の成果のギャップを表に出します。マルチソースのサービスは、あらゆるダッシュボードが緑であるのに、静かに期待を裏切ります。環境の中で「ウォーターメロン」報告が隠れている場所を探ります。個別には達成された指標が、壊れたパスウェイに積み上がること、利用者に再試行を頼むことで閉じられたチケット、臨床家が決して触れないサーバーで測定された稼働率。端から端まで、あるいは経験レベルの本物の尺度があるか、誰がそれを所有するか、そしてサプライヤーが、望む成果のためにインセンティブを与えられているのか、ゲーム化できる代理指標のためかを議論します。より豊かな、経験に基づく測定が、お金と労力を要し、クレジットが古い指標に依存するサプライヤーに争われうる緊張を考えます。強い答えは、利用者の現実を反映する端から端までの尺度を少なくとも一つ示し、それがサプライヤーをまたいでどう統治されるかを説明し、現在のSLAが誤った行動に報い、次の中断点で再交渉が必要なところについて率直です。

  4. 私たちの連携の層を、誰が運営するべきか。内部のチームか、外部のサプライヤーか、ハイブリッドか。そして、その選択が生む利益相反について、誠実であったか。 サービスインテグレーター自体の、内製か購入かの判断は、意図してではなく、既定で下されることが多く、その後のあらゆる関係を形づくります。本当のトレードオフを議論します。内部のインテグレーターは、知識と管理を、保持される組織の内側に保ちますが、トラストが抱えられないかもしれない、乏しく高価な能力を求め、外部のインテグレーターは、成熟とツールを素早く買いますが、統治すべき層を加え、同じサプライヤーがサービスタワーも運営し、事実上、自分の宿題を採点している場合は、特に問題になります。中間のケース、つまり、保持される組織が説明責任と仲裁を所有し、パートナーが運用の機械を提供するハイブリッドと、あなたの組織が、インテグレーターに導かれるのではなく、それを指揮するだけの商務的・技術的な上級性を持っているかを考えます。連携の知識が、今日実際にどこにあるか、そしてそのインテグレーターの契約が終わったら、端から端までのビューがどうなるかを、誠実に見ます。誠実な答えは、誰が統合するかを挙げ、そのモデルが、引き継がれたのではなく、あなたの文脈のために選ばれた理由を説明し、サービスも提供するインテグレーターが、自分の実績を採点しないようにするセーフガードを示せます。

  5. 臨床安全、データ保護、サイバーセキュリティの法定の義務は、チェーンの深くにいる第四の当事者に実際に届いているか。それとも、私たちが署名した元請けで止まっているか。 これが重要なのは、患者安全やデータ侵害の事象に対する説明責任は、契約に従わないからです。たとえ失敗が、選んだことのないサブプロセッサーやオフショアのサポートチームという、三層下で起きたとしても、保持される組織に残ります。流し下しの条項が本物でテストされているか、つまり、関連する標準のもとでの臨床安全の義務、データ処理の条件、サイバーの統制が、下請け業者に契約上本当に課されているか、そしてそれらの下請け業者が誰かについての可視性を持っているかを探ります。元請けが、サプライチェーンを商務上機微だとして公開することに抵抗する一方で、見えないリスクは評価できず、第四の当事者の透明性を求めると、調達が遅れ、市場が狭まりうるという緊張を話し合います。具体的な失敗、つまりプロダクトの内部のオープンソースのライブラリ、ホスティングの下請け業者、第三者のアナリティクスのツールを考え、そこでのインシデントが、あなたの義務を強制可能なものとして見つけるのか、単なる願望として見つけるのかを考えます。強い答えは、流し下しが、想定されるのではなく、書かれ、エビデンスがあり、ときどき監査されていることを示し、チェーンのどこで現在可視性が尽きるかを挙げられます。

  6. 契約が署名されたあと、それをファイルして引き出しにしまうのではなく、クレジットを請求し、改善を推進し、購入した価値をサプライヤーに守らせて、積極的に管理するのは誰か。 マルチソースの決定的な漏れは、落札のあとに、調達の注意が移り、価値が実現されるか静かに失われる、運用と稼働の何年もを、誰も所有しないときに起きます。SLAに対する構造化された実績レビューを行っているか、受け取る権利のあるサービスクレジットを実際に追跡し請求しているか、そして持続的な不振が、改善計画を引き起こすのか、単に吸収されるのかを議論します。クレジットを追いかけることが、依存している関係を悪化させうる一方、成熟したアプローチは、クレジットを、確保するリベートではなく、改善のためのシグナルと梃子として扱い、しかしサプライヤーは、どの顧客が決して確認しないかを素早く学ぶという緊張を考えます。更新や紛争のときに重要になる、監査可能な実績の記録を維持しているか、継続的改善が、契約上の期待なのか、時折の好意なのかを見ます。誠実な答えは、各戦略的な関係を誰が所有するかを説明し、エビデンスに基づく実績管理が、サプライヤーの行動を変えた、最近の事例を示し、契約が管理されずに動き、価値が年々漏れているところを率直に認めます。

実践例:医療・ケアの事例#

Northmoor統合ケアシステムは、その規模に典型的なデジタル環境を運用しています。ある主要なベンダーのホストされた電子患者記録、別のベンダーの共有ケア記録のプラットフォーム、専門企業の連携エンジンとインターフェース層、NHS Englandの国のサービス、ネットワークの提供者による接続、そして、第一線のサポートが、それ自体オフショアに下請けされているシステムインテグレーターが運営する、マネージドサービスデスク。各契約は、10年かけて別々に調達され、それぞれ独自のSLAを持ち、そして最近まで、それぞれが異なる部門の異なるマネージャーによって統治されていました。

問題は、ある月曜日に、自らを告げます。臨床家が、GPの紹介が、添付ファイルが欠けた状態で、ときには何時間も遅れて急性期トラストに届いていると報告します。EPRのベンダーは、稼働率100%と報告し、チケットを閉じます。連携のサプライヤーは、自社のエンジンが受け取るすべてのメッセージを通していると言います。共有ケア記録のベンダーも同じことを言います。ネットワークの提供者は、障害を示しません。あらゆるサプライヤーが緑で、紹介のパスウェイは琥珀色から赤へ向かっており、箱と箱の間の矢印を誰も所有していません。9日間、チケットがたらい回しされる間、患者は待ちます。

Northmoorの対応は、保持される組織の中に、サービス統合の機能を立ち上げることで、サプライヤーとサービス管理の責任者が、小さなチームと、決定的に、取締役会から与えられた権限を伴って率います。彼らはまず環境を分類します。EPR、共有ケア記録、連携のサプライヤーは戦略的、ネットワークの提供者はボトルネックのサプライヤー、ライセンスの再販業者はコモディティと指定し、それに合わせたガバナンスのリズムを設定します。次に、各戦略的契約に付属する運用の別表を、次の中断条項で書き直し、30分以内にインテグレーターの重大インシデントのブリッジに参加し、求めに応じて診断データを共有する義務を含めます。「紹介が、完全に、期限どおりに届く」という端から端までの尺度が、構成要素のSLAと並んで定義・報告され、どの単一のベンダーでもなく、インテグレーターが所有します。

試験は6か月後に訪れ、結果のメッセージが静かに失敗し始めます。今回は、インテグレーターが1時間以内に重大インシデントを宣言し、三つの戦略的サプライヤーとネットワークの提供者を、無過失のルールの下で一つのブリッジに招集し、メッセージを端から端までたどるよう推進します。根本原因は、連携のサプライヤーが展開した文字エンコーディングの変更で、EPRが解析できなかったことと判明します。どの単一のサプライヤーにも見えなかった継ぎ目に、まさに存在した障害です。4時間で直り、共同の問題記録が修正を捉え、サービスクレジットが請求され、共有の回帰テストスイートに再投資されます。一方、ICSは、三つの戦略的サプライヤーがすべて同じクラウドのリージョンにホストしていることを静かに書き留め、集中リスクをBoard Assurance Frameworkに記録し、移動する必要が生じたときに、ポータビリティが約束されるのではなく実証されるよう、データ抽出のテストを委託します。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップは、通常、本トピックの反対側にいます。統合されるサプライヤーであり、その商務上の将来は、他者のSIAMモデルの中で、良き市民であることにかかっています。NHSの仕事を勝ち取ることは、ますます、重大インシデントのブリッジに参加し、サブプロセッサーを公開し、臨床安全とデータ保護の義務を流し下し、退出時にデータをきれいに返すことを証明することを意味するため、それらの協力の能力を早期に築くことは、間接費ではなく、競争上の優位性です。社内では、スタートアップは、重要な第三者、つまり自前のクラウドホスト、決済処理業者、認証の提供者の利用者でもあり、自分よりはるかに大きなベンダーに対する梃子がほとんどないまま、本物の集中リスクを抱えています。拡大する規律は、依存関係のマップを最新に保ち、安価な切り替えコストが利用できるところでアーキテクチャ上のロックインを避け、自分のチェーンの第四の当事者について、顧客に誠実であることです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設や訪問介護事業所、単独拠点のクリニックは、大きなトラストと同じ、臨床安全、データ保護、サイバーセキュリティの法定の義務を負いますが、専任のIT機能もなく、契約上の梃子もほとんどないまま、サプライヤーの積み重ねを管理します。実際には、SIAMの規律全体が、他の仕事も抱える一人か二人に集約されるため、現実的な動きは、臨床の一日が本当に依存する二つか三つのサプライヤー、つまり臨床システム、接続、共有記録のリンクを特定し、それらの関係を意図して管理しつつ、残りには軽い関与を受け入れることです。集中リスクは鋭く避けられません。単一の診療所管理システムや一本のブロードバンド回線が、完全な単一障害点になりえ、緩和策は、第二のサプライヤーではなく、運用的なもの(ダウンタイム手順、第二の接続)であることが多いのです。退出とポータビリティは、ここでも同様に重要です。独自の記録にロックインされた小さな提供者は、移る力がさらに乏しいため、サプライヤーに迫る問いは、オープンな形式でのデータのエクスポートと、契約が終わったときに何が起きるかです。スタートアップの段階を過ぎた小規模なヘルステックのサプライヤーは、その鏡像に直面します。大きなベンダーが持つようなコンプライアンスのチームなしに、NHSの顧客がいま求める、協力、流し下し、退出の義務を満たさなければなりません。

大企業#

大規模なトラスト、提供者の連合、ICSは、SIAMの典型的な顧客です。数十のサプライヤー、相次ぐ調達によって組み立てられた長寿命の環境、そして、端から端までの振る舞いを誰も完全には所有しないサービス。現実的な目標は、本物のサービス統合の能力を持つ、機能する保持される組織、注意が戦略的な少数に向かうためのサプライヤーの分類、契約の境界を越えて機能する、横断的なインシデントと問題の管理であり、完全に整合したSLAの幻想ではありません。最も難しい仕事は、契約上のものと文化的なものです。中断条項が許すにつれて、レガシーの合意に協力の義務を後付けし、サプライヤーを、自分の箱を守ることから、全体に対する自分の持ち分を所有することへ移すことです。この規模では、最大のレジリエンスの利得は、ポートフォリオ全体で集中リスクを描き出し、失敗が地域の出来事になる少数のサプライヤーについて、退出をテストすることから生まれます。

政府#

国の機関、つまりNHS England、権限移譲された保健省、Crown Commercial Serviceのようなフレームワークの運営者は、あらゆるトラストがサプライヤーを管理する環境を形づくります。その梃子は、Government Commercial FunctionのSourcing Playbookと標準条項を通じて期待を設定し、協力、ポータビリティ、サプライチェーンの保証を、各購入者が弱い立場から単独で交渉するものではなく、市場の既定にすることです。政府はまた、システム全体の視点も担います。個々のトラストには見えない、単一のサプライヤーやプラットフォームが、システム全体にとって重要な第三者になったことを見てとれ、その集中を、国のレジリエンスの問題として管理しなければなりません。その責務は、フレームワークの設計、保証の体制、国のサービスが、ロックインと単一障害点を固めるのではなく、減らすようにすることです(トピック9.1 — 地方政府・中央政府との協働参照)。

よくある失敗パターン#

  • 説明責任の真空。 あらゆるサプライヤーが構成要素を所有し、端から端までのサービスを誰も所有しないため、境界をまたぐ問題に居場所がない。本物の権限を持つ、説明責任のあるインテグレーターを指名する。
  • 回転椅子のインシデント。 サプライヤーが責任を転嫁する間、サービスが止まったままで、協力させる権限を与えられた人がいない。あらゆる契約に、単一の重大インシデントのブリッジと、無過失の「まず復旧」のルールを義務づける。
  • ウォーターメロンSLA。 あらゆる構成要素の指標が緑のまま、実際のサービスは赤で、サプライヤーは成果ではなく指標に報告する。インテグレーターが所有する、端から端までと経験レベルの尺度を加える。
  • 画一的なガバナンス。 コモディティの再販業者と、戦略的なEPRのパートナーを同じに扱うと、労力を無駄にし、重要な関係を飢えさせる。サプライヤーを分類し、ガバナンスのリズムを重要性に合わせる。
  • 引き出しの中の契約。 署名のあと、誰も実績を管理せず、クレジットを請求せず、改善を推進しないため、価値が年々漏れる。積極的で、エビデンスに基づく契約管理を運営する。
  • 見えない第四の当事者。 義務は元請けには流し下されるが、そこで止まり、未知の下請け業者がデータやリスクを抱えたままになる。サプライチェーンの可視性と、末端までの統制の流し下しを求める。
  • 管理されない集中。 重要なサービスが、単一の失敗がシステム全体に及ぶまで、一つのサプライヤー、プラットフォーム、地域へ静かに統合される。取締役会のレベルで、集中リスクを描き出し、意図して受け入れる。
  • 理論上の退出。 一度もテストされていない、データに対する契約上の権利は、ポータビリティではない。必要になる前に、データの抽出と再ホストを実証する。

成熟度モデル#

観点 着手 発展 標準化 管理 統合
運用モデル サプライヤーが、サイロの中で契約ごとに管理される 一部の調整があるが、役割が不明確 保持されるインテグレーターとタワーを伴う、定義されたSIAMモデル モデルが定義されたKPIに対して統治され、インテグレーターの実績がレビュー・保証される 継続的に調整されるモデルで、インテグレーターがサプライヤー横断の価値を推進する
端から端までの説明責任 誰もサービス全体を所有しない エスカレーションが場当たり的にマネージャーに届く 名前のあるインテグレーターが、端から端までのSLAと重大インシデントを所有する 端から端までのSLAが目標に対して積極的に管理され、定期的に保証された報告がある 端から端までと経験の尺度が、チェーン全体を統べる
サプライヤーの分類 すべてのサプライヤーが同じに扱われる 誰が重要かの非公式な感覚 正式な分類がガバナンスのリズムを推進する セグメントのKPIが追跡され、ガバナンスのリズムがそれに対して保証される ポートフォリオが、価値とレジリエンスのために積極的に再調整される
実績とクレジット SLAが監視されず、クレジットが請求されない 定期的なレビューで、クレジットが時々請求される 構造化されたレビュー、請求されるクレジット、改善計画 実績が目標に対して定量的に管理され、クレジットと改善計画が完了まで追跡される 成果に基づくインセンティブで、継続的改善が組み込まれる
サプライチェーンのリスクと退出 第四の当事者と集中が不明で、退出計画がない 元請けの一部の保証で、退出計画は書類上 下請け業者への流し下しで、退出計画が文書化される 集中と流し下しの保証が測定・報告され、退出への備えがレビューされる 集中が描かれ受け入れられ、退出とポータビリティがテストされる

チェックリスト#

  • 名前のある保持される組織の役割が、端から端までのサービスに説明責任を負い、端から端までのSLAを保持している。
  • SIAMのモデル、つまりインテグレーター、タワー、横断的なプロセスが定義され、サプライヤーの契約に書き込まれている。
  • サプライヤーが重要性で分類され、各セグメントに合ったガバナンスのリズムがある。
  • 端から端までと経験レベルの尺度が構成要素のSLAを補完し、インテグレーターが所有している。
  • サプライヤー横断の単一の重大インシデントのプロセスがあり、無過失の「まず復旧」のルールが契約上義務づけられている。
  • 契約の実績が積極的にレビューされ、サービスクレジットが追跡・請求され、改善計画が引き起こされる。
  • 臨床安全、データ保護、サイバーの義務が、第四の当事者の可視性を伴って、下請け業者に流し下されている。
  • サプライヤー、プラットフォーム、地域にわたる集中リスクが描かれ、取締役会のレベルで意図して受け入れられている。
  • 重要なサプライヤーごとに、データ、知識、移行支援をカバーする、生きた退出の計画がある。
  • 重要なサービスについて、データの抽出と再ホストが、契約上の約束だけでなく、テストされている。

主要な情報源#

  • Scopism — SIAM Body of KnowledgeとSIAM Professional Body of Knowledge — サービス統合と管理の役割、構造、プロセスの、決定版のオープンな参照。
  • AXELOS — ITIL 4 — SIAMがサプライヤーにまたがって拡張する、インシデント、問題、変更、サプライヤー管理のためのITサービスマネジメントの実践。
  • 英国政府Commercial Function — The Sourcing PlaybookとOutsourcing Playbook — 調達、契約管理、退出に関する公共部門のガイダンス。
  • Crown Commercial Service — 公共部門のテクノロジーとマネージドサービスの調達のための、フレームワーク合意と標準条項。
  • National Cyber Security Centre (NCSC) — Supply chain security guidance — サプライヤーと下請け業者にまたがるサイバーリスクの評価と管理。
  • 英国政府 / 内閣府 — 公共サービスにおける重要な第三者と集中リスクの管理に関するガイダンス。
  • NHS England — 臨床安全標準DCB0129/DCB0160と、サプライヤーに流し下されるべきデータ処理の要件。

参考文献#

  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

GitHubでこのページを編集 — 本書が信頼できる唯一の情報源であり、このサイトはそれを表示するだけです。