주제 6.6 — 공급업체 및 서비스 통합 관리(SIAM)

수십 개 공급업체로 엮인 보건·돌봄 자산에서 환자와 임상의가 실제로 경험하는 서비스는 공급업체 사이의 이음새만큼만 좋으므로, 어떤 단일 계약도 기술하지 않는 종단 간 전체를 누군가 소유해야 한다.

보건·돌봄에서 이것이 중요한 이유#

현대의 어떤 NHS 트러스트나 통합 돌봄 시스템(ICS)도 단일 공급업체로 운영되지 않는다. 일반의 의뢰가 외래 진료 예약, 서신, 검사 결과, 처방이 되는 단일 임상 워크플로는 한 공급업체의 전자 환자 기록, 다른 공급업체의 통합 엔진, 세 번째 공급업체의 호스팅 플랫폼, 네트워크 제공자, 국가 스파인(spine) 서비스, 만나 본 적 없는 네 번째 당사자가 운영하는 관리형 서비스 데스크를 가로지를 수 있다. 각 부분의 계약은 건전할 수 있다. 환자가 받는 서비스는 그 사이의 틈에 산다.

이것은 상업적 관계의 운영 측면이며, 가치가 실현되거나 조용히 잃어버려지는 곳이다. 조달 및 상업 팀(주제 6.3 — 조달 및 상업 계약 참조)은 잘 구매하고, 계약을 수주하고, 서명된 협약을 인계한다. 이후 수년간 일어나는 일 — 공급업체가 협력하는지 서로를 탓하는지, 장애가 한 시간 만에 고쳐지는지 일주일을 곪는지, 우리가 떠날 수 있는지 — 은 공급업체 및 서비스 통합 관리의 일이다. 잘못되면 실패는 추상적이지 않다. 조용히 결과를 떨어뜨리는 병리 인터페이스, 오래된 알레르기를 보여 주는 공유 진료 기록, 교대 시점에 임상의를 잠가 버리는 인증 서비스는 통합 문제로 시작하는 환자 안전 사건이다(주제 1.6 — 임상 안전과 위험 관리 참조).

세 가지 분야 특성이 위험을 날카롭게 한다. 공적 자금은 구매한 성과가 전달된 성과일 것을, 그리고 서비스 크레딧과 가치가 테이블 위에 남겨지지 않고 적극 추구될 것을 요구한다. 데이터 보호, 임상 안전, 사이버 보안에 대한 법정 의무는 우리가 고르지 않은 하청업체를 포함해 전체 공급망으로 흘러내려야 한다(주제 1.7 — 정보 거버넌스, 데이터 보호, 사이버 보안 참조). 그리고 핵심 서비스가 소수의 대형 공급업체로 집중되는 것은 한 공급업체의 랜섬웨어 사건, 지급 불능, 역량 실패가 한 지역 전체를 오프라인으로 만들 수 있음을 뜻한다. 공급업체를 한 번에 한 계약씩이 아니라 포트폴리오로 관리하는 것은 이제 행정이 아니라 회복탄력성의 의무다.

핵심 개념#

서비스 통합 및 관리(SIAM)는 여러 서비스 제공자를 조율하고 통합하여 업무에 단일한 종단 간 서비스를 전달하는 관리 접근법이다. 조직이 단일 주 계약자에서 다중 조달 운영 모델로 옮겨 가고, 그 뒤 여전히 누군가 부분들이 전체로 행동하게 만들어야 함을 발견했기 때문에 정확히 하나의 규율로 등장했다. SIAM은 구매하는 제품이 아니라 정의된 역할, 프로세스, 거버넌스가 있는 운영 모델이다. 권위 있는 참조는 Scopism의 SIAM Body of Knowledge로, ITIL 및 IT 서비스 관리(ITSM)의 더 넓은 실천을 대체하지 않고 나란히 있다.

SIAM 모델에는 세 개의 층이 있다. **고객 또는 유지 조직(retained organization)**은 결코 외주할 수 없는 책임을 유지한다. 전략, 수요, 아키텍처, 상업적 소유, 환자에 대한 최종 돌봄 의무다. 서비스 통합자는 제공자를 조율하고, 주요 사고 관리 같은 횡단 프로세스를 소유하며, 종단 간 시야를 쥐는 층 — 내부 팀, 외부 공급업체, 또는 혼합 — 이다. 서비스 제공자는 흔히 서비스 타워(호스팅, 최종 사용자 컴퓨팅, 임상 애플리케이션, 네트워크)로 조직되어 각각 정의된 조각을 전달한다. 이들은 백과사전 항목이 아니라 SIAM 전문 용어이므로 여기서는 쉬운 언어로 명명하고 SIAM 지식 체계에 근거를 둔다.

그 밑에는 상업적 기제가 있다. 아웃소싱과 그 데이터 및 프로세스 변형인 업무 프로세스 아웃소싱은 외부 제공자에게 업무를 위임하는 것을 말하고, 관리형 서비스는 대신 시스템을 구독 방식으로 지속 운영하는 것을 말한다. 성과는 측정 가능하고 보통 계약상인 약속인 서비스 수준 협약(SLA)으로 거버넌스되며, 점점 더 공급업체가 맞추기 편한 구성 요소 지표가 아니라 사용자가 실제로 경험하는 성과를 측정하는 경험 수준 협약(XLA)이 보완한다. XLA에는 확립된 백과사전 항목이 없으므로, 표준이 아니라 부상하는 실천으로 다루라.

두 가지 위험 개념이 주제의 틀을 만든다. 제3자 관리는 외부 제공자를, 그리고 결정적으로 공급망 깊숙한 곳의 제4자인 그들 자신의 하청업체를 감독하는 규율이다. 공급망 위험 관리는 그 사슬을 통해 전파되는 실패를 다루고, 은행업에서 빌린 용어인 집중 위험은 단일 공급업체, 플랫폼, 지역에 지나치게 의존하는 위험을 포착한다. 이를 관리하는 것이 편리한 조달 결정이 체계적 취약성이 되지 않게 해 준다. 마지막으로 공급업체 종속을 피하고 지속적 개선을 이끄는 것은 라이브 서비스가 굳는 것을 막는 두 가지 미래 지향적 의무다.

모범 사례#

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 공급망 지침에 맞춘 사이버 통제의 흘려보내기를 요구하고, 사슬에 실제로 누가 있는지 알도록 제4자의 가시성을 요구하라. 집중 위험을 명시적으로 평가하라. 핵심 서비스 셋이 하나의 하이퍼스케일러 지역이나 하나의 관리형 서비스 제공자에 있다면 단일 실패가 지역 장애이며, 완화는 이사회가 알고 내려야 하는 결정이다(주제 3.9 — 업무 연속성과 재해 복구 참조).

8. 절박하게 퇴출을 택하기 전에 퇴출을 계획하라. 떠날 능력을 확보하는 가장 저렴한 때는 서명 전이다. 가장 필요한 순간에는 레버리지가 모두 사라져 있다. 모든 핵심 공급업체에 대해 개방적이고 문서화된 형식의 데이터 추출, 지식 이전, 전환 지원 의무, 다른 곳에 다시 프로비저닝하는 데 필요한 자산과 라이선스를 다루는 살아 있는 퇴출 계획을 유지하라. 진정한 이식성은 약속이 아니라 입증된다. 데이터를 내보내 다른 곳에 세울 수 있는지 시험하라. 독점 덤프로 된 데이터에 대한 계약상의 권리는 그것을 쓸 수 있다는 것과 같지 않기 때문이다(실제로 공급업체 종속을 피하는 방법은 주제 4.0 — 기술 아키텍처, 클라우드, 레거시 참조).

팀과 논의할 질문#

1. 새벽 2시에 사고가 세 공급업체에 걸칠 때, 그들 모두를 한 팀으로 행동하게 만들 권한은 누구에게 있으며 — 모든 계약이 그들에게 호출에 응답하도록 의무를 지우는가? 회전 의자 실패는 기술적 격차가 아니라 권한의 격차이므로 이것이 중요하다. 공급업체는 자신의 SLA를 방어하고 책임을 떠넘길 때 합리적으로 행동하며, 계약의 뒷받침이 있는 지정된 통합자만이 이를 뒤집을 수 있다. 오늘 조직에 그런 역할이 있는지, 실제 권한이 있는지 소집하고 호소할 뿐인지, 제공자 계약이 공유된 주요 사고 브리지에서의 협력을 실제로 요구하는지 단지 권장하는지 정직하게 토론하라. 가장 어려운 사례를 고려하라. 국가 서비스, 호스팅 제공자, 애플리케이션 공급업체에 걸치는 결함으로, 첫 한 시간 동안 근본 원인이 진정으로 모호한 경우다. "먼저 복구하고 나중에 나눈다"는 무과실 규칙을 운영하는지, 상업 팀이 책임을 다투는 동안 해결이 정체되는지 살펴보라. 좋은 답은 책임 있는 통합자를 명명하고, 협력을 강제하는 계약 조항을 가리키며, 모델이 유지된 최근의 공급업체 간 사고를 설명할 수 있다 — 또는 지난번에는 그렇지 못했음을 솔직히 인정한다.

2. 어떤 공급업체의 갑작스러운 상실을 우리는 진정으로 견딜 수 없으며 — 그들이 실패한 날 아침에 실제로 무엇을 할 것인가? 이는 조달의 편의가 묻어 버리는 집중 위험 대화를 강제한다. 자산은 소수의 전략적 파트너와 몇 개의 플랫폼에 대한 의존을 쌓아 가며, 총 노출은 사건이 드러내기 전에는 거의 지도화되지 않는다. 어떤 공급업체가 임상 서비스의 단일 장애점인지, 의존이 계약적인지 기술적인지 지식 기반인지, 실제 위험이 제4자 사슬 얼마나 깊은 곳에 있는지 — 하위 처리자, 해외 지원 팀, 단일 하이퍼스케일러 지역 — 논의하라. 상충 관계를 정직하게 저울질하라. 통합은 효율, 통합, 더 나은 가격을 사 주고, 다각화는 비용을 치르고 회복탄력성을 사 주며, 올바른 답은 과거 조달의 우연이 아니라 이사회의 의도적 선택이다. 이 공급업체에 대한 퇴출과 연속성 계획이 시험되었는지 단지 쓰였는지, 공급업체가 다음 주 지급 불능이 되면 데이터를 추출해 다시 호스팅할 수 있는지 고려하라. 정직한 답은 우리가 관리하는 공급업체와 실패가 존재적 사건인 소수의 공급업체를 구별하고, 후자에 대한 잔여 위험이 올바른 수준에서 의식적으로 수용되었음을 보여 준다.

3. 우리는 임상의와 환자가 경험하는 것을 측정하고 있는가, 아니면 공급업체가 초록으로 보고하기 쉬운 것만 측정하고 있는가? 이 질문은 구성 요소 SLA와 실제 성과 사이의 격차를 드러내며, 다중 조달 서비스가 모든 대시보드가 초록인 채로 조용히 실망시키는 곳이다. 자산 어디에 "수박" 보고가 숨어 있는지 탐색하라. 개별적으로 충족되었지만 합치면 망가진 경로가 되는 지표, 사용자에게 다시 시도하라고 해서 닫은 티켓, 임상의가 닿지 않는 서버에서 측정된 가동 시간이다. 진정한 종단 간 또는 경험 수준 척도가 있는지, 누가 소유하는지, 공급업체가 원하는 성과에 대한 유인을 받는지 조작할 수 있는 대리 지표에 받는지 토론하라. 더 풍부한 경험 기반 측정은 돈과 노력이 들고 크레딧이 옛 지표에 달려 있는 공급업체가 이의를 제기할 수 있다는 긴장을 고려하라. 강한 답은 사용자의 현실을 반영하는 종단 간 척도를 최소한 하나 가리킬 수 있고, 그것이 공급업체 전반에서 어떻게 거버넌스되는지 설명하며, 현재 SLA가 잘못된 행동을 보상하여 다음 중단점에서 재협상이 필요한 곳에 솔직하다.

4. 통합 계층은 누가 운영해야 하는가 — 내부 팀, 외부 공급업체, 혼합 — 그리고 그 선택이 만드는 이해 상충에 정직했는가? 서비스 통합자 자체의 직접 수행 대 구매 결정은 흔히 의도적이 아니라 기본으로 내려지며, 이후 모든 관계를 형성한다. 진정한 상충 관계를 토론하라. 내부 통합자는 지식과 통제를 유지 조직 안에 두지만 트러스트가 보유하지 못할 수 있는 희소하고 비싼 역량을 요구한다. 외부 통합자는 성숙도와 도구를 빠르게 사 주지만 거버넌스할 층을 더하고, 같은 공급업체가 서비스 타워도 운영하면 사실상 자기 숙제를 채점하는 격이 되어 심각하게 문제가 된다. 중간 사례를 고려하라. 유지 조직이 책임과 중재를 소유하고 파트너가 운영 기계를 제공하는 혼합 모델, 그리고 조직이 통합자에게 이끌리지 않고 통합자를 지휘할 상업적, 기술적 직급이 있는지다. 통합 지식이 오늘 실제로 어디 있으며, 그 통합자의 계약이 끝나면 종단 간 시야에 무슨 일이 일어나는지 정직하게 보라. 정직한 답은 누가 통합하는지 명명하고, 그 모델이 물려받은 것이 아니라 여러분의 맥락에 맞게 선택된 이유를 설명하며, 서비스도 전달하는 통합자가 자기 성과를 채점하지 못하게 하는 안전장치를 가리킬 수 있다.

5. 임상 안전, 데이터 보호, 사이버 보안에 대한 법정 의무가 사슬 깊숙한 제4자에게 실제로 닿는가 — 아니면 서명한 주 공급업체에서 멈추는가? 환자 안전이나 데이터 침해 사건에 대한 책임은 계약을 따라가지 않기 때문에 이것이 중요하다. 실패가 고르지 않은 하위 처리자나 해외 지원 팀에서 세 단계 아래 일어났어도 책임은 유지 조직에 남는다. 흘려보내기 조항이 실제로 시험되었는지 탐색하라. 관련 표준에 따른 임상 안전 의무, 데이터 처리 조건, 사이버 통제가 하청업체에 진정으로 계약상 부과되는지, 그 하청업체가 누구인지 가시성이 있는지다. 주 공급업체가 자기 공급망을 상업적으로 민감하다며 노출하기를 거부하는 반면, 보이지 않는 위험은 평가할 수 없고, 제4자 투명성을 요구하면 조달이 느려지고 시장이 좁아질 수 있다는 긴장을 논의하라. 구체적 실패를 고려하라. 제품 안의 오픈 소스 라이브러리, 호스팅 하청업체, 제3자 분석 도구에서 사건이 일어나면 여러분의 의무가 시행 가능한가, 단지 포부인가. 강한 답은 흘려보내기가 가정되지 않고 서면으로 작성되고, 증거를 갖추며, 가끔 감사됨을 보여 주고, 사슬의 어디에서 가시성이 끝나는지 명명할 수 있다.

6. 계약이 서명된 뒤 누가 그것을 서랍에 철해 두지 않고 — 크레딧을 청구하고, 개선을 이끌며, 우리가 구매한 가치를 공급업체에 지키게 하며 — 적극 관리하는가? 다중 조달에서 결정적인 누수는 수주 뒤, 조달의 주의가 옮겨 가고 가치가 실현되거나 조용히 잃어버려지는 운영의 수년을 아무도 소유하지 않을 때 일어난다. SLA에 대한 구조화된 성과 검토를 열고 있는지, 마땅히 받을 서비스 크레딧을 실제로 추적하고 청구하는지, 지속적 부진이 개선 계획을 촉발하는지 단지 흡수되는지 토론하라. 크레딧을 쫓는 것이 의존하는 관계를 해칠 수 있고, 성숙한 접근은 크레딧을 챙길 환급이 아니라 개선의 신호이자 지렛대로 다루지만, 공급업체는 어느 고객이 결코 확인하지 않는지 빨리 배운다는 긴장을 고려하라. 갱신이나 분쟁 때 중요해질 감사 가능한 성과 기록을 유지하는지, 지속적 개선이 계약상 기대인지 가끔의 호의인지 살펴보라. 정직한 답은 각 전략적 관계를 누가 소유하는지 설명하고, 증거를 갖춘 성과 관리가 공급업체의 행동을 바꾼 최근 사례를 가리키며, 계약이 관리되지 않은 채 운영되어 가치가 해마다 새는 곳을 솔직히 인정한다.

실제 사례: 보건·돌봄 예시#

Northmoor 통합 돌봄 시스템은 그 규모에 전형적인 디지털 자산을 운영한다. 한 주요 공급업체의 호스팅 전자 환자 기록, 다른 공급업체의 공유 진료 기록 플랫폼, 전문 업체의 통합 엔진과 인터페이스 계층, NHS England의 국가 서비스, 네트워크 제공자의 연결, 1차 지원 자체가 해외에 하청된 시스템 통합업체가 운영하는 관리형 서비스 데스크다. 각 계약은 10년에 걸쳐 따로 조달되었고, 각각 자체 SLA가 있으며, 최근까지 각각 다른 부서의 다른 관리자가 거버넌스했다.

문제는 월요일에 모습을 드러낸다. 임상의들이 일반의 의뢰가 첨부 파일이 빠진 채, 때로는 몇 시간 늦게 급성기 트러스트에 도착한다고 보고한다. EPR 공급업체는 100% 가동 시간을 보고하고 티켓을 닫는다. 통합 공급업체는 엔진이 받는 모든 메시지를 통과시키고 있다고 말한다. 공유 진료 기록 공급업체도 같은 말을 한다. 네트워크 제공자는 결함이 없다고 보인다. 모든 공급업체가 초록이고, 의뢰 경로는 주황에서 빨강으로 가고 있으며, 상자 사이의 화살표를 아무도 소유하지 않는다. 9일 동안 티켓이 튕기는 사이 환자들은 기다린다.

Northmoor의 대응은 유지 조직 안에 공급업체 및 서비스 관리 책임자가 이끌고, 작은 팀과 결정적으로 이사회가 위임한 권한을 가진 서비스 통합 기능을 세우는 것이다. 그들은 먼저 자산을 세분화한다. EPR, 공유 진료 기록, 통합 공급업체는 전략적으로, 네트워크 제공자는 병목 공급업체로, 라이선스 재판매업체는 일반 상품으로 지정하고, 그에 맞는 거버넌스 리듬을 정한다. 이어서 다음 중단 조항 시점에 각 전략적 계약에 첨부된 운영 일정을 다시 써서 30분 안에 통합자의 주요 사고 브리지에 합류하고 요청 시 진단 데이터를 공유할 의무를 포함시킨다. "의뢰가 완전하게 제시간에 전달됨"이라는 종단 간 척도가 정의되어 구성 요소 SLA와 함께 보고되며, 어느 단일 공급업체가 아니라 통합자가 소유한다.

시험은 6개월 뒤, 결과 메시지가 조용히 실패하기 시작할 때 온다. 이번에는 통합자가 한 시간 안에 주요 사고를 선언하고, 세 전략적 공급업체와 네트워크 제공자를 무과실 규칙 아래 하나의 브리지로 소집하여 메시지를 종단 간으로 추적하도록 이끈다. 근본 원인은 통합 공급업체가 배포한 문자 인코딩 변경을 EPR이 파싱할 수 없었던 것으로 드러난다. 정확히 어느 단일 공급업체도 볼 수 없는 이음새에 있던 결함이다. 4시간 만에 고쳐지고, 공동 문제 기록이 수정을 포착하며, 서비스 크레딧이 청구되어 공유 회귀 테스트 모음에 재투자된다. 한편 ICS는 세 전략적 공급업체 모두 같은 클라우드 지역에 호스팅한다는 점을 조용히 기록하고, 집중 위험을 이사회 보증 프레임워크에 기록하며, 이전해야 할 때 이식성이 약속이 아니라 입증되도록 시험된 데이터 추출 연습을 위탁한다.

부문별 관점#

스타트업#

디지털 보건 스타트업은 보통 이 주제의 반대편에 있다. 통합되는 공급업체이며, 상업적 미래는 다른 이의 SIAM 모델에서 좋은 시민이 되는 데 달려 있다. NHS 업무를 따내는 것은 점점 더 주요 사고 브리지에 합류하고, 하위 처리자를 공개하고, 임상 안전과 데이터 보호 의무를 흘려보내고, 퇴출 시 데이터를 깨끗하게 돌려줄 것임을 입증하는 것을 뜻하므로, 이 협력 역량을 일찍 구축하는 것은 간접비가 아니라 경쟁 우위다. 내부적으로 스타트업은 핵심 제3자 — 자체 클라우드 호스트, 결제 처리자, 인증 제공자 — 의 소비자이기도 하며, 자신보다 훨씬 큰 공급업체에 대해 거의 레버리지 없이 실질적 집중 위험을 안는다. 확장되는 규율은 의존성 지도를 최신으로 유지하고, 저렴한 전환 비용이 가능한 곳에서 아키텍처 종속을 피하며, 자기 사슬 속의 제4자에 대해 고객에게 정직한 것이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원이나 재가 돌봄 기관, 단일 사업장 클리닉 — 는 대형 트러스트와 같은 임상 안전, 데이터 보호, 사이버 보안의 법정 의무를 지지만, 전담 IT 기능도 계약상 레버리지도 거의 없이 공급업체 스택을 관리한다. 실제로 SIAM 규율 전체가 다른 일도 하는 한두 사람에게 몰리므로, 현실적인 수는 임상의 하루가 진정으로 의존하는 두세 공급업체 — 임상 시스템, 연결, 공유 기록 연결 — 를 식별하고 그 관계를 의도적으로 관리하면서 나머지에는 더 가벼운 접촉을 받아들이는 것이다. 집중 위험은 절실하고 피할 수 없다. 단일 진료소 관리 시스템이나 하나의 광대역 회선이 전면적 단일 장애점일 수 있으며, 완화는 흔히 두 번째 공급업체가 아니라 운영적인 것(가동 중단 절차, 두 번째 연결)이다. 퇴출과 이식성도 여기서 똑같이 중요하다. 독점 기록에 갇힌 소규모 제공자는 옮길 힘이 더 적으므로, 공급업체에 압박할 질문은 개방형 형식의 데이터 내보내기와 계약이 끝나면 무슨 일이 일어나는가다. 스타트업 단계를 지난 소규모 보건 기술 공급업체는 거울상에 직면한다. 더 큰 공급업체가 가질 준수 팀 없이 NHS 고객이 이제 요구하는 협력, 흘려보내기, 퇴출 의무를 충족해야 한다.

대기업#

대형 트러스트, 제공자 협업체, ICS는 SIAM 고객의 전형이다. 수십 개 공급업체, 연속된 조달로 조립된 오래된 자산, 종단 간 행동을 아무도 완전히 소유하지 않는 서비스다. 현실적 목표는 진정한 서비스 통합 역량이 있는 작동하는 유지 조직, 주의가 전략적 소수에게 흐르도록 하는 공급업체 세분화, 계약 경계를 넘어 작동하는 횡단 사고 및 문제 관리이지, 완벽하게 정렬된 SLA라는 환상이 아니다. 가장 어려운 일은 계약적이고 문화적이다. 중단 조항이 허용하는 대로 레거시 협약에 협업 의무를 소급해 넣고, 공급업체를 자기 상자를 방어하는 것에서 전체에 대한 자기 몫을 소유하는 것으로 옮기는 일이다. 이 규모에서 가장 큰 회복탄력성 이득은 포트폴리오 전반의 집중 위험을 지도로 그리고, 실패가 지역 사건이 될 소수 공급업체의 퇴출을 시험하는 데서 나온다.

정부#

NHS England, 자치 보건부, Crown Commercial Service 같은 프레임워크 운영자와 같은 국가 기관은 모든 트러스트가 공급업체를 관리하는 환경을 형성한다. 그 레버리지는 Government Commercial Function의 Sourcing Playbook과 표준 조건을 통해 기대를 정하고, 각 구매자가 약한 위치에서 혼자 협상하는 대신 협력, 이식성, 공급망 보증을 시장의 기본으로 만드는 것이다. 정부는 체계적 시야도 지닌다. 개별 트러스트가 볼 수 없는 것, 곧 단일 공급업체나 플랫폼이 시스템 전체의 핵심 제3자가 되었을 때를 볼 수 있으며, 그 집중을 국가 회복탄력성 문제로 관리해야 한다. 그 의무는 프레임워크 설계, 보증 체제, 국가 서비스가 종속과 단일 장애점을 굳히지 않고 줄이도록 보장하는 것이다(주제 9.1 — 지방 및 중앙 정부와의 협업 참조).

흔한 실패 양상#

• 책임의 진공. 모든 공급업체가 구성 요소를 소유하고 아무도 종단 간 서비스를 소유하지 않아 경계를 넘는 문제가 갈 곳이 없다. 실제 권한이 있는 책임 있는 통합자를 명명하라.
• 회전 의자 사고. 서비스가 멈춘 채 공급업체가 책임을 떠넘기고 아무도 그들을 협력하게 할 권한이 없다. 모든 계약에 단일 주요 사고 브리지와 무과실 "먼저 복구" 규칙을 의무화하라.
• 수박 SLA. 실제 서비스가 빨강인데 모든 구성 요소 지표가 초록이며, 공급업체는 성과가 아니라 지표에 맞춰 보고한다. 통합자가 소유하는 종단 간 및 경험 수준 척도를 더하라.
• 획일적 거버넌스. 일반 상품 재판매업체와 전략적 EPR 파트너를 똑같이 다루면 노력을 낭비하고 중요한 관계를 굶긴다. 공급업체를 세분화하고 거버넌스 리듬을 중요도에 맞추라.
• 서랍 속의 계약. 서명 후 아무도 성과를 관리하거나, 크레딧을 청구하거나, 개선을 이끌지 않아 가치가 해마다 샌다. 적극적이고 증거를 갖춘 계약 관리를 운영하라.
• 보이지 않는 제4자. 의무가 주 공급업체에 흘려보내지지만 거기서 멈춰, 알려지지 않은 하청업체가 데이터나 위험을 쥐고 있다. 공급망 가시성을 요구하고 통제를 끝까지 흘려보내라.
• 관리되지 않는 집중. 핵심 서비스가 단일 공급업체, 플랫폼, 지역으로 조용히 통합되어 단일 실패가 체계적이 된다. 이사회 수준에서 집중 위험을 지도로 그리고 의식적으로 수용하라.
• 이론상의 퇴출. 한 번도 시험되지 않은 데이터에 대한 계약상 권리는 이식성이 아니다. 필요하기 전에 데이터 추출과 재호스팅을 입증하라.

성숙도 모델#

체크리스트#

• 지정된 유지 조직 역할이 종단 간 서비스에 책임지고 종단 간 SLA를 쥔다.
• SIAM 모델 — 통합자, 타워, 횡단 프로세스 — 이 정의되어 공급업체 계약에 써 넣어져 있다.
• 공급업체가 중요도에 따라 세분화되어 있고, 각 세그먼트에 맞는 거버넌스 리듬이 있다.
• 종단 간 및 경험 수준 척도가 구성 요소 SLA를 보완하며 통합자가 소유한다.
• 계약상 의무화된 무과실 "먼저 복구" 규칙이 있는 단일 공급업체 간 주요 사고 프로세스가 있다.
• 계약 성과를 적극 검토하고, 서비스 크레딧을 추적하고 청구하며, 개선 계획이 촉발된다.
• 임상 안전, 데이터 보호, 사이버 의무가 제4자 가시성과 함께 하청업체에 흘려보내진다.
• 공급업체, 플랫폼, 지역 전반의 집중 위험이 지도화되고 이사회 수준에서 의식적으로 수용된다.
• 모든 핵심 공급업체에 데이터, 지식, 전환 지원을 다루는 살아 있는 퇴출 계획이 있다.
• 핵심 서비스에 대해 데이터 추출과 재호스팅이 계약상 약속에 그치지 않고 시험되었다.

주요 출처#

• Scopism — SIAM Body of Knowledge and SIAM Professional Body of Knowledge — 서비스 통합 및 관리의 역할, 구조, 프로세스에 대한 결정적인 공개 참조.
• AXELOS — ITIL 4 — SIAM이 공급업체 전반으로 확장하는 사고, 문제, 변경, 공급업체 관리의 IT 서비스 관리 실천.
• UK Government Commercial Function — The Sourcing Playbook and Outsourcing Playbook — 조달, 계약 관리, 퇴출에 관한 공공 부문 지침.
• Crown Commercial Service — 공공 부문 기술 및 관리형 서비스 조달을 위한 프레임워크 협약과 표준 조건.
• National Cyber Security Centre (NCSC) — Supply chain security guidance — 공급업체와 하청업체 전반의 사이버 위험을 평가하고 관리.
• HM Government / Cabinet Office — 공공 서비스의 핵심 제3자와 집중 위험 관리에 관한 지침.
• 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