主题 1.1 — 运营模式

一句话概括: 目标运营模式(TOM)是对你的机构战略如何流经价值流、能力、团队、治理、技术、数据与供应商、从而交付数字医疗与照护成果这一过程的刻意设计——它的形态是否得当,决定了下游的一切究竟是快速而安全,还是缓慢而脆弱。

为什么这在医疗与照护领域很重要#

大多数数字医疗机构失败,并不是因为缺乏人才或技术,而是因为它们的运营模式在与自己作对。资金被捆绑在限时项目上,决策权归属不明,每个团队都在重新构建同一套登录、集成与审计管道。结果就是公共资金上的重复成本、不一致的临床安全水平,以及无法在整合照护系统(ICS)内共享数据的服务。

运营模式在这个领域之所以与众不同,是因为它必须调和相互竞争的善——它必须足够联邦化,以尊重信托机构、地方政府、全科诊所等主权机构的自主权,又要足够连贯,才能让患者在它们之间获得同一种安全的体验。它必须在运行(让临床系统安全可用)与变革(改进它们)之间取得平衡——因为停机可能影响照护。它还必须按比例花钱:保证工作要重到足以满足公共问责与临床安全的要求,又要轻到不至于扼杀迭代。TOM 正是这些取舍被明确表达出来、而不是随机发生的地方。

核心概念#

运营模式的层次。 一个有用的 TOM 是一个层层叠加的体系,每一层都服务于其上的一层:

• 战略与成果 — 你存在的目的所在的、可衡量的人群与服务成果(通常以OKR的形式表达;见主题 1.3——循证决策)。
• 价值流 — 向用户交付价值的端到端流程,例如"转诊、分诊并治疗一名患者"——围绕市民的旅程组织,而不是围绕组织架构图组织。
• 能力 — 你必须具备的做事能力(身份识别、预约、临床文档记录、分析)。即使解决方案在变化,能力也保持稳定。
• 团队 — 被组织起来交付能力与价值流的人(见下文的 Team Topologies)。
• 治理与决策权 — 谁来决定什么,以及保证工作如何被应用。
• 技术与数据 — 团队所依托的平台、标准与数据架构。
• 供应商 — 你所采购的市场,以及你如何管理它。

自上而下地设计(战略 → 价值流 → 能力)能让团队与技术对齐于成果,而不是对齐于遗留结构。

中心化 vs 联邦化 vs 平台化模型。 中心化模型将交付集中在一个团队或一个独立机构中:标准化统一、成本低廉,但容易成为瓶颈,且往往脱离地方需求。联邦化模型将交付下放给信托机构与地方:反应迅速、地方拥有主导权,但容易重复与分化。平台化模型是调和二者的模式:一个中央团队以平台的形式提供共享、可复用的能力(身份识别、互操作性、托管、设计系统),联邦化的团队则在其之上快速构建。大多数成熟的卫生系统最终都会收敛到"平台加联邦"的形态。

Team Topologies。 该框架命名了四种团队类型——流对齐型(拥有一条价值流)、平台型(提供自助式能力)、赋能型(帮助他人提升某项能力)与复杂子系统型(如算法之类的深度专业工作)——并强调它们之间要保持低摩擦的互动。它与平台模型完美契合:平台团队降低了流对齐团队的认知负担,使其能够专注于用户与临床价值。

运行 vs 变革。 运行是让在线服务保持安全可用;变革是改进或构建它们。既构建又运行一项服务的产品团队("谁构建,谁运行")能够闭合反馈回路,提升安全性,但这种平衡必须被诚实地纳入预算——为了资助变革而克扣运行经费,正是临床系统退化的原因。

最薄可行平台(TVP)。 出自 Team Topologies:平台应当是真正能为流团队减少摩擦的最小一组共享服务——不多不少。一个过度构建的平台会变成它自己的瓶颈,自己的遗留系统。从每个团队真正需要的少数能力(身份验证、互操作层、托管、设计系统)开始,只根据有证据支持的需求来增长。

最佳实践#

1. 自上而下地从成果设计模式,而不是自下而上地从组织架构图设计。 从你必须推动的人群与服务成果出发,推导出交付它们的价值流,然后才设计团队与技术。一个锚定在现有层级结构上的 TOM,只会把现有的孤岛自动化。

2. 采用平台加联邦的形态。 以自助式平台的形式在中央提供共享能力,让信托机构与地方的流对齐团队在其之上构建。这能让你在安全与互操作性上获得全国范围的一致性,同时保有地方的速度与主导权——这正是该领域所要求的调和之道。

3. 资助产品,而不是项目。 将资金从限时项目转移到与价值流对齐、持续获得资助的产品团队。项目资金迫使团队在恰好学会该领域知识的那一刻解散;产品资金则能维持医疗服务所需的安全知识与迭代能力(见主题 5.0——以产品为主导的工作)。

4. 让支出控制与风险相称、分阶段进行。 使用与证据挂钩的分阶段资助——在探索、alpha、beta 与上线各个关口逐步释放资金,而不是一次性批准整个项目。GDS 式的支出控制与 NHS 的保证路径,正是为了防止在未经验证的想法上产生巨额沉没成本而存在的;应根据风险与价值来设定这些门槛,而不是搞一刀切的官僚主义。

5. 用 RACI 或 RAPID 图谱让决策权明确化。 权责不明是导致交付停滞最常见的原因。为每一类重大决策指明谁是负责人/问责人/被咨询者/被告知者(RACI),或者谁来推荐、批准、执行、提供意见与最终决定(RAPID)。将其公开发布,让团队不再把自己本已有权做出的决定层层上报。

6. 让平台保持精简,并由需求驱动。 只有当两个或以上团队被证实确实需要同一样东西时,才构建共享能力,并把平台当作拥有自己用户(内部团队)的产品来对待。克制预先构建宏大平台的冲动;最薄可行平台是靠被采纳来赢得其范围的。

7. 将供应商管理纳入模式之内,而不是排除在外。 刻意决定哪些能力是战略性的(自建/自有),哪些是大宗商品式的(采购),避免在核心临床数据上受制于单一供应商的锁定,并在合同中要求开放标准与退出权。你的供应商是你运营模式的一层,他们的工作方式必须与你的相兼容。

8. 让决策权明确化。 一个运营模式只有在人们知道谁来决定什么的情况下才能奏效——哪些选择归产品团队,哪些归临床安全权威,哪些必须提交董事会。绘制决策权图谱,把每一项决策推到能够安全承担它的最低层级,这样交付就不会被不必要的上报所拖累。权责不明是导致交付缓慢、趋于自保的最常见原因之一。

9. 把运营模式当作一个你要不断演进的产品来对待。 目标运营模式不是一次设定好、然后挂在墙上的框架;要随着需求、技术与合作关系的变化而检视它,并依据证据来调整。关注几个信号——工作流动性、决策所需时间、返工与团队健康状况——并在它们明确显示出阻碍作用时改变结构,而不是为了追随重组的风潮而改变。

与团队讨论的问题#

1. 我们的运营模式是从成果与价值流自上而下设计的,还是仅仅把我们现有的组织架构图及其孤岛自动化了? 这个问题直指本主题的核心警示:一个锚定在当前层级结构上的 TOM,只会巩固你已经拥有的那些孤岛,因此在任何重组之前都值得把它摆到桌面上讨论。它在医疗与照护语境中之所以重要,是因为价值流跟随的是市民跨越主权机构的旅程——转诊、分诊、治疗——而组织架构图跟随的是机构边界,一个建立在后者之上的模式,只会持续在公共资金上生产碎片化、不可互操作的服务。值得坦诚讨论的张力在于,自上而下地从成果出发进行设计,确实具有破坏性:它会切穿部门所有权、预算与汇报线,而这些正是高级人员用整个职业生涯建立起来的,因此真正做好这件事存在实实在在的政治成本。用具体的方式来检验自己:说出你们排名前三的成果,并追溯你们实际的团队边界与资金线跟随的究竟是这些价值流,还是各个部门;如果团队与部门一一对应,那就是答案。一个好的、诚实的回答会承认模式在哪些地方是按组织架构图塑造的,指出至少一条目前因分散在孤岛中而受损的价值流,并对机构愿意重新划定哪些结构边界抱有现实态度。

2. 我们的最薄可行平台应当包含什么?我们要如何防止它要么被过度构建成瓶颈,要么构建不足导致每个团队都重复搭建同一套基础管道? 平台加联邦的形态,只有在平台保持精简且由需求驱动时才能奏效,这个问题促使团队直面本主题所指出的两种失败模式——变成自身遗留瓶颈的宏大平台,以及因其缺失而迫使每个团队重新构建登录、集成与审计功能。它之所以重要,是因为在一个 ICS 中,平台实际上就是共享基础设施(身份识别、FHIR 互操作层、带有安全基线的托管、设计系统),把它的范围搞错,会在每一个流团队身上成倍放大成本或摩擦。值得讨论的取舍在于时机与证据:建得太早,你可能猜错并造出一个瓶颈;建得太晚,重复劳动已经固化——因此"两个或更多团队被证实确实需要同一样东西"这一测试标准才是关键所在,团队应当压力测试一下自己究竟是真的在应用它,还是只是在构建那些看起来显然属于核心的东西。看看你们目前把什么当作平台、什么被团队重新构建,并追问平台的运营方式,究竟是作为一个拥有自己内部用户与 SLA 的产品,还是作为一个人人都要排队等候的队列。一个诚实的答案会具体说明今天哪些能力通过了"两个团队"测试,抵制预先构建其余部分的诱惑,并承诺把平台团队的内部用户当作拥有真实服务水平的真实客户来对待。

3. 我们的决策权在哪些地方确实是模糊不清的?团队今天正在上报升级的哪些事情,其实本应有权自行决定? 权责不明被指认为交付停滞最常见的原因,因此这个问题揭示了一份公开的 RACI 或 RAPID 图谱本应消除的日常摩擦。在一个联邦化的卫生系统中,这一点尤为尖锐,因为地方团队、ICS 数字化委员会、临床安全与信息治理对一项决策都有合理的主张,边界不清则意味着要么一切都被上报升级,要么更糟——在出问题之前没有人真正拥有这个决定。值得探讨的张力在于,下放决策权需要在护栏之内信任团队,而高级领导与董事会往往恰恰在涉及临床安全或公共资金时不愿给予这种信任——然而正是这种不信任,才首先造成了上报升级的拥堵。把它具体化:列出最近上报升级的五个决策,针对每一个追问本应由谁来决定、什么样的护栏本可以让他们自行决定;这种模式通常会揭示出少数几类反复出现的模糊决策。一个好的答案会给出一份具体的、可公开发布的"谁决定什么"声明——区分平台标准、服务设计与临床安全签核——并诚实说明机构真正愿意下放哪些决策、又会将哪些保留在中央,以及为什么。

4. 我们对运行与变革的资助是诚实的吗?还是我们正在悄悄地克扣在线服务运营的经费,来支付新功能的账单? 本主题直言不讳地指出,克扣运行经费来资助变革,正是临床系统退化的原因,这个问题迫使这种平衡在停机或安全事件替你做出这个决定之前就被摆上台面。它在医疗与照护领域之所以重要,是因为"运行"并不是后台开销——它是临床医生在照护现场所依赖系统的可用性,因此一个被削减的运行预算,表现出来的是可能影响患者的停机,而不仅仅是让用户感到不便。这种取舍令人不安,因为变革是可见的、会被赞扬的,而运行在失败之前是不可见的,因此董事会与路线图天然会偏向新事物;"谁构建谁运行"模式有助于保持反馈回路的闭合,但前提是团队的运行时间真正得到保护,而不是名义上分配、实际上被挪用。把它具体化:看看上个季度每个产品团队的实际产能中,有多大比例真正用于保持服务的安全与可用,与计划相比如何,以及运行工作是被追踪和重视,还是被当作打断来对待。一个诚实的答案会指出今天哪些地方的运行工作正在被资助不足,把一个现实的运行分配作为首要支出而不是剩余份额来保护,并坦率说明哪些在线服务正背负着累积的运营风险。

5. 对于每一项能力,我们是否刻意选择了自建自有还是采购?我们是否在不经意间接受了核心临床数据上的供应商锁定? 这里的最佳实践是刻意决定自建/采购,避免核心临床数据上的单一供应商锁定,并把供应商当作运营模式的一层来对待,而不是排除在外——这个问题检验的是这些选择究竟是真正在做出的,还是默认发生的。它之所以重要,是因为在数字医疗领域,后果最严重的锁定往往围绕着临床记录及其数据展开,一个没有现实退出路径的专有存储系统可能会困住整个系统长达十年,并主宰下游每一项服务能做什么。张力在于速度与可选性之间:采购通常更快、当下往往更便宜,尤其对于人手紧张的团队而言,但每一次在没有开放标准或退出权的情况下进行的便利采购,都会悄悄收窄明天的选择,而这一成本只有在你试图离开时才会显现。把它具体化:列出你们的核心能力,把每一项标记为战略性的(自建/自有)或大宗商品式的(采购),并检查大宗商品类别背后的合同是否真的要求开放标准(HL7 FHIR、SNOMED CT)与可强制执行的退出权。一个好的答案会区分出少数真正具有战略性的能力,与许多可以安全采购的能力,坦率说明机构在哪些地方已经被锁定在核心临床数据上,并承诺在最重要的合同中纳入开放标准与退出权。

6. 我们将如何知道我们的运营模式需要改变?什么样的信号会告诉我们——而不是随波逐流地为了某种风潮或新领导的到任而重组? 本主题将运营模式定位为一个你依据证据不断演进的产品,而不是一张挂在墙上的图纸,因此这个问题要求团队事先定义,什么样的证据才足以证明重塑它是合理的。它在医疗与照护领域之所以重要,是因为重组具有破坏性且代价高昂——它会打散来之不易的领域知识与临床安全知识——然而这个领域却容易受到由政策周期与新任命驱动、而不是由当前模式是否真正碍事所驱动的结构性动荡的影响。张力在于稳定与适应之间:模式改变得太频繁,团队就永远无法安定下来或积累安全专长;改变得太少,固化的结构又会在早已不适配工作之后长期拖慢流动性。把它具体化:选择一小组要关注的信号——工作流动性、决策所需时间、返工与团队健康状况——并就它们出现何种变化会触发一次刻意的重新设计、而不是一次较小的调整达成一致。一个诚实的答案会锁定少数几个领先指标,区分由证据驱动的改变与重组表演,并明确谁对检视这个模式负责,并在信号表明它正在阻碍交付时采取行动。

实践中:一个医疗与照护案例#

一个覆盖五个地方的 ICS,其下每家信托机构都在各自建设自己的患者预约工具。成本重复,体验分化,且没有一家能干净地共享数据。该 ICS 重新设计了自己的运营模式。

它确定了三个成果(减少未就诊率、削减可避免的入院、改善获取服务的公平性)及支撑它们的价值流。它组建了一个小型平台团队,拥有四项最薄可行能力:一个共享的身份识别/登录系统、一个基于 FHIR 的互操作层、带有安全与临床安全基线的通用托管,以及一个设计系统。每个地方都保留一个流对齐团队,但现在是在平台之上构建,而不是从零开始。

资金从年度项目投标转向针对每条流的常设产品预算,并通过探索/alpha/beta 关口逐步释放。一份公开发布的 RAPID 图谱明确表明,地方团队决定自己在平台与临床安全护栏内的服务设计,而 ICS 数字化委员会决定平台标准。一年之内,三个地方共享了同一项预约能力,设计与安全基线保持一致,过去需要一个项目周期才能上线的新功能现在只需数周即可交付——因为平台吸收了那些无差别的繁重工作。

行业视角#

运营模式的规模要与它所服务的机构相匹配;同样的几个层次——价值流、能力、团队、治理、平台、供应商——在初创企业、大型企业与政府机构那里,呈现出截然不同的形态。

初创企业#

在一家小型数字医疗公司里,运营模式大多是隐性的,这也没关系:一两个流对齐团队,创始人持有大部分决策权,而且没有平台团队,因为目前还没有什么东西值得平台化。这里的纪律在于及早把少数真正重要的决策明确化——临床数据存储要自建还是采购、要承诺采用哪些开放标准——这样今天的权宜之计就不会变成明天的锁定。运行与变革掌握在同一批人手中,因此风险在于为早期客户维持系统运转会挤占路线图;对工程时间做一个简单、诚实的划分,就是受保护运行预算的轻量版等价物。选择供应商是为了速度,但一家初创企业仍然应当拒绝在核心临床数据上被锁定,因为它未来的 NHS 买家会要求退出权。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院或居家照护提供者、一家单一场所的诊所,或是一家已过预收入阶段的小型健康科技供应商——拥有真实的患者与持续的运营,但没有平台团队,没有专门的数字或 IT 能力,现金与人手也没有多少余地。这里的运营模式很大程度上是一组拼接在一起的采购能力,因此决定性的选择是供应商方面的选择:在你所采购的临床系统中坚持要求开放标准与退出权,因为你承担着与大型信托机构同样的互操作性与临床安全职责,却没有它的采购能力或内部专长。运行与变革都落在同一小撮同时也在提供照护的人身上,因此诚实的纪律是保护一点点时间来保持系统的安全与更新,而不仅仅是四处救火。决策权很简单——通常由一位合伙人或业主经理来决定——但这也使得数字方面的决策很容易被无限期搁置,因此价值在于指出少数真正重要的决策(选用哪种临床记录系统、加入哪个共享的区域平台)并刻意做出决定。当一个 ICS 或国家机构提供共享的身份识别、互操作性或设计平台时,小型企业最好的做法往往是在其之上构建,而不是重新发明——借用它自己无法配置人手去构建的能力。

大型企业#

一家 NHS 信托机构或 ICS,正是平台加联邦的形态大显身手之处:各个主权机构必须在患者眼中感觉像是同一项服务。这里的难题更多是政治性的,而不仅仅是技术性的——把资金从限时项目投标转移到常设产品预算,并公开发布一份 RACI/RAPID 图谱,让地方团队不再上报升级那些本属于他们自己的决策。一家大型健康科技或制药企业拥有平台工程方面的实力,但面临着过度构建一个宏大内部平台、使其变成自身瓶颈的风险;最薄可行平台的测试标准——两个或以上团队被证实确实需要同一样东西——正是这种情况下的刹车。在这个规模上,决策权与资金流动才是运营模式;技术通常不是制约因素。

政府机构#

一个国家级或地方公共机构所设计的运营模式,是其他机构必须置身其中的,因此它关于标准与平台的选择实际上就是国家基础设施。NHS England 或 DHSC 提供一个共享的身份识别层、一条互操作性主干,或一个设计系统,正是在人群规模上应用平台模式,而它的支出控制与分阶段保证关口,正是公共资金问责的方式。失败模式是一个变成遥远瓶颈的中心化模型,为每一个地方情境强制推行同一个解决方案;纠正之道是把真正共通的能力平台化,把其余的联邦化给信托机构与地方政府。对议会负责也意味着自建/采购与供应商管理是公开记录的事项,因此开放标准与退出权不仅是审慎之举,更是被期待的做法。

常见失败模式#

• 把组织架构图自动化。 围绕现有部门而不是价值流设计团队,让 TOM 巩固了孤岛。解药:自上而下地从成果与价值流出发进行设计。
• 变成瓶颈的平台。 一个范围过大的中央平台团队,每一个请求都必须在其后排队。解药:最薄可行平台,并作为带有 SLA 的产品来对待。
• 用项目资金做产品工作。 到期作废的资金迫使团队解散再重建。解药:带有分阶段关口的持续性产品资金。
• 被克扣去喂养变革的运行经费。 对在线服务运营投入不足,直到临床系统退化。解药:明确地为运行与变革分别提供资金,并保护运行预算。
• 无人认领的决策。 没有人知道谁来决定,于是一切都被上报升级。解药:一份公开发布的 RACI/RAPID。
• 默认发生的锁定。 核心临床数据被困在一个没有退出路径的专有供应商系统中。解药:在每一份战略性合同中纳入开放标准与退出权。

成熟度模型#

检查清单#

• 运营模式是从成果与价值流设计的,而不是从现有层级结构设计的。
• 共享能力以最薄可行平台的形式提供,流团队在其之上构建。
• 产品团队获得持续资助,并与价值流对齐。
• 支出控制是分阶段的(探索/alpha/beta/上线关口),并与风险和价值相称。
• 决策权已被记录(RACI 或 RAPID)并公开发布。
• 运行与变革分别明确获得资助,运行预算受到保护。
• 团队类型(流对齐型、平台型、赋能型、复杂子系统型)已被理解并加以运用。
• 自建/采购是针对每项能力的刻意选择;核心临床数据避免了锁定。
• 合同要求开放标准(如 HL7 FHIR、SNOMED CT)与退出权。

关键来源#

• Matthew Skelton 与 Manuel Pais ——《Team Topologies》(流对齐、平台、赋能、复杂子系统团队;最薄可行平台)。
• GOV.UK 服务手册 ——支出控制与分阶段保证(探索/alpha/beta/上线);政府数字服务。
• NHS 数字服务手册 ——NHS 服务标准(service-manual.nhs.uk)。
• AXELOS ——用于项目组合与项目治理的项目组合管理(MoP)与成功项目管理(MSP)。
• Bain & Company ——RAPID 决策权框架;以及 RACI 责任分配模型。
• John Doerr ——用于定义成果的《Measure What Matters》(OKR)。

参考文献#

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