软件需求分析做到后来你会发现绝大部分问题的根子都埋在最开始那半步——你要分析的那个目标组织边界到底画在哪。最近重读《软件方法》第2章业务建模部分最有感触的就是“目标组织规格范围”的调整。这个词听起来有点像工程词汇实际上特别接地气它就是回答“我们到底在给多大、多细的一个组织做建模”。以医院为例子这个调整过程特别典型因为医院既有清晰的科室层级又有跨科室的协作流程还有区域医疗协同等外围关系随便选一个口径当边界后面的业务用例图、业务序列图都会跟着跑偏。这篇文章适合产品经理、需求分析师、软件架构师以及所有在项目里需要回答“系统为什么这么做”的人。我会从概念拆解讲到实操步骤把调整目标组织规格范围这件事彻底说透。围着医院场景走一遍之后你会发现很多建模上的争论其实根本不用吵画一圈边界答案自己就出来了。1. 先搞清楚“目标组织”和“规格范围”到底指什么1.1 目标组织你打算改造谁的业务《软件方法》第2章的核心是业务建模而业务建模最忌讳的事情就是一上来就画系统的界面、数据库和接口。正确的顺序是先把目标组织的业务看明白再从中推导出系统的职责。那“目标组织”是什么把它理解成“你打算围绕谁的业务来做分析和改进”就对了。它可以是医院、学校、银行网点也可以是一个物业公司。关键不在于这个名字听起来多大而在于这个组织本身是一个完整的主体有清晰的边界并且能够对外交付某种价值。很多需求工作做不下去就是因为目标组织选得模模糊糊。你说“我要给医院做一套系统”这句话听上去很具体但医院只是一个泛称它可以是一家三甲医院整体医院里的某个科室医院的信息中心一个跨院的区域医疗协作体这些候选对象都可以叫“医院相关组织”但它们对外承担的价值和业务逻辑完全不同。如果不先把目标组织锁定后面讨论需求时几个人脑子里各自装着一个尺寸完全不同的“医院”方案自然对不齐。1.2 规格范围两个维度都要盯住“目标组织规格范围”这个组合词我建议拆成两部分理解。第一是“范围”也就是纵向的边界。边界以内流程、资源、职责都属于这个组织边界以外都是它的外部执行者。以医院为例如果你把范围定在“门诊部”那住院部、药房库房、检验科就全都跑到了边界外面它们和门诊部之间变成两个组织之间的合作而不是一个组织内部的分工。第二是“规格”我把它理解为建模的细致程度。同样是“医院”这个边界你可以把它当成一个黑盒子只关心医院整体对外提供的服务也可以把盒子撬开画到科室级别、岗位级别甚至某个设备的操作级别。规格越细模型能看到内部分工但成本和复杂度也随之上升。这两个维度经常会纠缠在一起。有的人说“我们范围很小”结果规格画得非常细等于把一个三甲医院每一台仪器都建模了有的人说“我们范围很大”结果规格又很粗一张图里全是“医院提供医疗服务”这种正确但没用的废话。维度一句话定义医院场景示例范围目标组织的横切边界边界外是执行者心内科、门诊部、医院、医联体规格对组织内部结构的刻画细度只画门诊/住院还是细到科室、岗位、设备调整目标组织规格范围就是同时校准这两个维度范围太大就收缩规格太粗就细化直到业务用例能稳定地画出来为止。1.3 医院场景里的坐标从科室到医院再到医联体我拿医院这个例子把坐标轴拉开你会更直观地看到范围不同业务建模的结果差异有多大。如果把目标组织选成“心内科”那这家科室对外的业务可能有心血管疾病诊疗、出院随访、介入手术等。执行者是患者、家属、兄弟科室的会诊医生、耗材供应商。这时候检验科、放射科、住院部都成了外部组织心内科和它们之间的协作属于组织间的业务交互而不是内部流程。如果把目标组织选成“医院整体”边界往外推了一大截。挂号处、缴费处、药房、检验科、住院部统统收进边界内外部执行者变成患者、医保机构、药品供应商、卫健委、教学合作院校等。这时候业务用例不再是一两个而是“诊疗服务”“体检服务”“科研教学”等一堆并行的价值流。如果把目标组织选成“区域医联体”那就更复杂了。边界外的执行者还会多出基层社区卫生服务中心、上级转诊医院、疾控中心等。这时候“患者首诊在社区、确诊后转诊到中心医院、术后康复回社区”这样的连续服务链条才可能成为真正的业务用例。我在实际项目里见过一个很常见的错误目标组织明明只是“医院信息科”却试图用“医院整体”的宽度去建模然后开始编造“信息科给患者提供诊断服务”这种明显不对的用例。信息科不接触患者它的外部客户是医院的其他部门它的业务是用信息系统支撑医院运转。如果一开始把边界画到“信息科”就应该老老实实以“全院各科室的数字化支撑”为业务主线而不是硬套医院的对外医疗价值。所以目标组织规格范围没有绝对的“正确值”只有“适合当前业务改进目标”的值。建模者要做的是根据我们关心的业务问题不断调整这个值直到模型既能反映真实业务又能为后续系统需求提供方向。2. 为什么要调整规格范围失控的典型症状2.1 范围过大的症状业务用例多得离谱有一次我和同事搭一个区域医疗平台的需求模型初始目标组织框的是“整个区域医疗系统”。听着很高大上画业务用例图的时候直接翻车了。患者、家属、卫健委、医药公司、保险公司、疾控、社区服务中心、各医院信息科……外部执行者列了十几类业务用例草拟出来有四十多个连“献血服务”“慢病随访”这种明显需要跨多个组织的复杂价值流都涌进来了。这还不是最糟的最糟的是内部流程完全无法收敛。门诊、住院、急救、转诊、体检、科研、教学、后勤所有部门都在边界内要画内部协作图就会画成一张蜘蛛网。范围过大的本质是目标组织吞掉了太多本应属于“合作伙伴”的其他组织导致模型里出现大量组织间协同而组织间协同在业务建模里很难被一个组织完整负责画出来的图自然失控。范围过大的直接后果是模型的每个业务用例都变得没指纹。你把“医疗服务”画成一个胖用例等于没说拆细一点又冒出来六十个用例根本没法决策。2.2 范围过小的症状找不到对外交付的价值反过来如果把目标组织范围缩得太小又会踩另一种坑。有一回一个同事给“医院的收费窗口”建模认为收费窗口作为一个独立目标组织对外业务就是“收费”或“结算”。可当他拿价值闭环一检验就发现问题了患者交完钱拿到的是收费凭证但患者要的从来不是一张凭证而是后续的检查、药品和诊疗服务。收费窗口单独存在的价值只有依附于医院整体的诊疗链条才能成立。换句话说边界内的组织必须能够单独回答一个问题“如果外面只剩我这个组织顾客为什么还要找我”收费窗口回答不了这个问题因为它的价值没有闭环。临床科室勉强能回答因为患者可以直接从诊疗行为中获得病情改善医疗结算中心就回答不了它更像一个内部职能单元。我在另一个项目里也见过类似情况把“学校的教务处”当作目标组织想给教务系统建模。结果业务用例画来画去都是“排课”“查成绩”“毕业审核”每个用例旁边挂的执行者全是“学生”和“教师”。但你问一句“学生是因为教务处的排课工作才来上大学的吗”显然不是学生是为了接受教育来的。教务处提供的所有服务都只是教育价值链上的一环单独拿出来承载不了“教育”这个核心价值。这就是目标组织规格范围过小的典型症状组织边界内部没有一个能对外闭环的核心价值。强行建模就只能建模出一堆内部管理流程。2.3 判断标准用“价值闭环”当体温计既然谈论调整总要有一个判断标准。我自己的经验是把“价值闭环”当成体温计。什么是价值闭环就是一个组织对外交付的结果能否让外部的某个执行者在不需要依赖更多外部辅助的情况下获得一个可感知、可验证的价值。可以拿医院挂号做测试。患者挂号的直接产出是“一个候诊资格”。但只有挂到号患者并不能认为自己获得了诊疗价值他还得排队、就诊、检查、取药。所以“挂号”这个动作对患者来说不是闭环它的利益要依赖后续多个环节才能兑现。如果强行让收费窗口或挂号处当目标组织业务模型就缺了一个“头”和“尾”。再看“门诊诊疗”就不一样。患者走进诊室医生问诊、查体、开单患者走出诊室时获得了一个关于“我大概什么病、下一步怎么办”的判断。这个结果对患者是可用的。哪怕后续检查还没做患者也已经从诊疗行为本身获得了阶段性价值。所以门诊科室能作为独立闭环。利用这个判断标准建模时可以设三个具体问题这个组织对外交付的结果外部执行者单独享受吗这个结果的实现是否依赖组织边界之外的其他核心环节完成如果把这个组织删掉外部执行者是否会立刻找到替代方案把这三条问完一个目标组织规格范围是否合适就有了明确答案。2.4 以医院挂号为例做个症状对照把上述内容落到挂号场景列一张症状对照表会更清楚。目标组织选择典型业务用例画法价值闭环是否成立问题定性医院挂号处/收费窗口挂号、收费、退号不成立患者要的不是凭证和号源范围过窄切断了诊疗价值链医院门诊部门诊诊疗、门诊手术、门诊咨询成立患者能直接获得诊疗结果范围合适但只覆盖门急诊医院整体诊疗服务、体检服务、应急救治、教学科研成立价值完整范围合适规格粒度需控制区域医联体分级诊疗、双向转诊、连续健康管理成立但过程复杂范围偏大需要高规格模型支撑大多数学员包括我自己一开始都会在“挂号处”这一行犯错。因为软件项目的实际交付范围可能只是预约挂号于是不自觉地把目标组织也缩成了挂号处。这是两码事后面我会专门讲这个暗坑。在这之前先记住一个结论挂号不能成为目标组织的核心业务用例因为挂号不构成价值闭环它只是医院内部流程对外暴露的一段接口。3. 一步一步调整目标组织规格范围的实操方法3.1 第1步先拉一份执行者清单调整目标组织规格范围不需要一上来就空想“边界应该在哪里”。我的做法是反向操作先拉执行者清单。执行者就是会与目标组织产生业务交互的外部角色。在医院的例子里顺着患者的就医动线走一遍你能拉出一长串候选者患者患者家属陪护人员医保经办机构商业保险公司药品和设备供应商上级转诊医院基层首诊机构卫健委等监管方医学院实习的师生科研合作单位不要急着筛掉谁这一步的重点是把“可能发生业务交互”的角色都放在桌面上。边界画在哪直接决定哪些角色进入执行者列表哪些被吸收到组织内部。比如你打算把目标组织定为“门诊部”那么住院部、检验科、放射科这些部门就全部变成外部执行者。你拉出来的执行者清单里就会出现“住院部”“检验科”“药房”这类组织型执行者。要是你打算把目标组织定为“医院整体”这些角色就全部消失变成内部流程的一部分。这一拉你立刻会发现目标组织规格范围的选择不是抽象概念而是直接决定了哪些角色需要对话、哪些流程需要画进模型、哪些界面需要后续系统支持。3.2 第2步给每个交互打“价值闭环”标签执行者清单拉完之后第二步是把这些执行者和目标组织之间可能发生的交互全部列出来。还是以医院为例如果初始目标组织选的是“医院整体”你会列出下面这些交互患者来医院接受门诊治疗患者住院接受手术和护理患者做健康体检患者来院进行急诊抢救医保机构与医院进行费用结算药企向医院供应药品耗材医学院向医院派送实习学生接下来逐个问前面那条判断标准价值闭环是否成立。“患者来院进行急诊抢救”成立因为一个濒危患者进入急诊科本身就值钱了哪怕只完成了分诊和初步抢救也已经产生了独立价值。“医院与医保机构费用结算”成不成立从患者角度看它不会成为患者来医院的理由从医保机构角度看它也只是医保体系的一部分。所以它的价值闭环不在医院这个边界内完整成立它是更高层“医疗保障系统”里的一个片段。“药企供应药品耗材”也一样药企不会因为要供应药品而成为医院的客户医院只是其渠道之一。它属于供应链协作不是医院的核心业务价值链。做完这一步你就会发现目标组织内部真正的业务用例往往只剩少数几个其余都是支撑流程或外部协作。3.3 第3步按检验结果决定扩大、缩小还是保持这一步就是真正的“调整”环节。根据第2步的检验结果分三种情况处理。第一种情况几乎所有交互都成立价值闭环而且闭环之间有大量跨组织协同。这时候说明你的目标组织范围过小模型画出来的东西像一堆内部职能转移。比如前面说的“挂号处”项目挂号不是闭环你需要把边界扩大到“门诊部”或“医院整体”把前端的导诊、中台的医生资源、后台的药品准备都纳入边界挂号才能被理解成流程片段。第二种情况交互数量巨大但每一个闭环都模模糊糊你很难说清楚组织对外最核心的价值是什么。这说明范围过大需要收缩。比如“区域医联体”它对外确实可以形成一个“连续健康管理”的完整闭环但如果项目只是想解决某个医院内部的流程问题那范围就必须收缩回“医院”甚至“门诊部”否则业务用例的颗粒度会散掉。第三种情况交互清单稳定闭环清晰几个核心业务用例都能一句话讲明白。那就别动说明当前规格范围正好。需要说明的是这三种情况会在项目推进中反复出现。我不是说这个判断只做一次就完了而是建议每推进一轮需求分析都把执行者清单和闭环标签重放一次。尤其是当你发现某个业务用例“画不下去”的时候第一反应不应该是硬编用例而是回头重新调目标组织规格范围。3.4 第4步用业务用例图复核条件允许的话把调整后的边界画成一张业务用例图来复核。这属于《软件方法》业务建模的招牌动作。画法很朴素画一个矩形框表示目标组织写清楚名字和边界矩形框外画火柴人代表所有外部执行者每个执行者与目标组织之间连一条业务用例表示它们与目标组织之间的价值交付关系。以“医院整体”为例最简单的画法就是框内写“医院”框外画“患者”“医保机构”“药品供应商”“医学院”患者连向“诊疗服务”“体检服务”医保机构连向“费用结算”药品供应商连向“药品供应”医学院连向“临床教学合作”这一张图摆出来目标组织规格范围是否合适一眼可见。如果框外面只剩下两三个执行者或者框内写了一大堆看似截然不同的用例那大概率是范围或规格出了偏差。我见过不少团队做需求分析时会花数周去讨论“这个功能要不要”但从来没画过业务用例图。如果他们肯花一小时把目标组织边界画出来很多争论根本不会发生。因为边界一旦明确谁是外部执行者、谁是内部流程立刻就有共识。3.5 完整推演一个医院预约挂号项目的目标组织调整过程把上面四步串成一个连贯案例感受会更具体。假设项目目标是做一个“线上预约挂号系统”用户故事大概是这样患者通过App选择科室和医生预约就诊时间线上支付到院后签到候诊。很多团队拿到这个需求第一反应是“我们要做个挂号App”然后开始设计界面、排期、开发。但按《软件方法》的路径我们必须先回答目标组织规格范围。第一次设定有人提议“目标组织就是挂号处”。但做完第2步价值闭环检验立即发现挂号不是闭环这个目标组织撑不起来。第二次设定把目标组织扩大到“门诊部”。此时门诊部的核心业务用例包括“门诊诊疗”“门诊咨询”“门诊手术”预约挂号变成门诊诊疗这条用例的前置环节。这样一来系统的定位不尬了它不是为了挂号而挂号而是为了让门诊诊疗资源可预约、可分配、可追溯。第三次调整就要看规格了。如果我们希望在建模时处理科室协作、医生排班、号源分配规则那么规格应该细化到门诊部下的科室和医生岗位。如果我们只是在做一个简单的信息发布和预约登记规格可以粗一些只保留“门诊部在线上为患者提供可预约的诊疗排程”就够。最终的目标组织定为“门诊部”规格细到科室排班和号源池范围稳定。这个调整过程看起来很费事但它带来的好处是所有关于“要不要做候诊队列提醒”“要不要做医生评价”“要不要做爽约限制”的争论都有了判断依据。因为这些功能都是围绕“门诊诊疗价值闭环”的支撑能力不是凭空发明的需求。我后来做类似系统时会刻意保留“目标组织调整记录”把每次调整前后的执行者清单、价值闭环标签都保存下来。不要小看这个动作需求变更时它是唯一能解释“我们当初为什么这么设计”的凭证。4. 调整中常见的暗坑与我的实测心得4.1 暗坑1把“开发范围”当成“目标组织范围”这是我在项目中踩过最深的一个坑。很多项目的功能边界是既定的比如甲方说“我们只做预约挂号不做排班”。如果把这个功能边界直接等同于目标组织范围那你的目标组织就会变成“挂号处”然后业务用例建模就崩了。我建议做一个严格的区分开发范围是本次软件交付包含的功能集它由项目预算、工期、优先级决定。目标组织范围是业务建模时定义的组织业务边界它由业务价值闭环决定。两者可以不一致而且大部分时候就是不一致的。你的系统只做预约挂号但你的目标组织完全可以是整个门诊部只不过这次交付的软件只支持门诊部业务流程中的一段罢了。按这个思路走后面需求整理就顺了。预约挂号系统只是门诊部业务信息化拼图中的一块将来要加检查预约、报告查询、在线复诊都在同一张业务地图上有位置。你要是把目标组织砍成挂号处以后每一次扩展都要重新建模项目成本直线上升。4.2 暗坑2以组织架构图代替业务边界还有一个容易犯的错误是照抄组织架构图来确定边界。医院信息科的人很容易拿一张现成的行政架构图说“这块是门诊部那块是住院部我们的目标组织就是门诊部。”但行政架构是管理汇报线不是业务价值线。同一家医院门诊和住院的行政边界非常清楚但业务上常常是连续的。比如一个患者因为腹痛来门诊医生怀疑胆囊问题开彩超门诊做不了得去住院部超声室做。执行这个检查时患者的价值实现跨越了门诊和住院两个部门。如果你按行政架构把边界切在门诊部这个跨部门检查流程就变成两个组织之间的协作业务用例图会多出一条“委托检查”的用例复杂度和理解成本都上去了。更合理的做法是把目标组织范围定成“提供诊疗服务的医院整体”或者至少是“门急诊与住院服务”让价值流在边界内滚动。行政架构可以作为规格细化的参考不能作为范围划分的依据。4.3 暗坑3追求“全生态”会让模型失去战斗力与范围过小相对的是有人喜欢把边界越画越大动辄“全生态”。有次评审会上一个产品经理很兴奋地建议既然都做医疗信息化了干脆把目标组织定成“区域医疗生态”这样既有格局又符合政策方向。结果业务用例图画出来光执行者就排了三排转诊、分级诊疗、互联网医疗、医保控费、公共卫生全堆在一起。这个建议的问题在于生态不是组织生态是一堆组织的协作网络。你很难画出一个矩形框把“区域医疗生态”当成一个单一主体来建模因为它内部的决策权、责权利都是分散的。目标组织必须有一个能负责的“主体感”。它要有明确的负责人、明确的业务评价指标、明确的对外承诺。医院可以说“我们负责为患者提供安全和可及的医疗服务”但“区域医疗生态”没法说“我们负责在自己内部完成这件事”因为生态本身有一堆组织各管一摊。在调整规格范围时建议守住这个底线目标组织必须能作为一个完整主体对外负责一个或多个价值闭环。超出这个底线的范围再大也只是画饼。4.4 实操心得白板画圈与“执行者视角”最后分享几个我自己天天在用的土办法不一定写进教材但对实操特别有效。第一招白板画圈。开会时拉一块白板画一个圈代表目标组织圈外写执行者圈内写业务用例和内部流程。谁都别讲PPT直接在圈上改。范围调整的本质就是不断移动这个圈的位置和大小。哪个执行者该进圈变成内部流程哪个该被请到圈外画一笔就清楚。这个方法我至少用过十次每次都能把一个小时的无效争论压缩成十分钟的边界讨论。第二招执行者视角。每次调整目标组织范围之前把自己代入执行者问一句“我为什么需要这个组织”。如果这句回答起来费劲说明组织边界放错了位置。比如你以“收费处”为目标组织替患者问“我为什么需要收费处”答案只能是“因为要交钱”这没有价值感。你以“门诊部”为目标组织替患者问答案变成“因为我要弄清楚我到底得了什么病”价值感一下就出来了。第三招不断重画。目标组织规格范围不是画一次就定了。我习惯在项目迭代的每个关键节点都把它拿出来问一遍。很多时候业务理解加深以后会发现当初画的边界其实少了一个重要执行者或者多圈进了一个协作部门。这时候老老实实调边界不要觉得丢面子。业务建模本来就是螺旋推进的过程。4.5 调整完成后后续建模会顺很多目标组织规格范围调到位最直接的好处是业务序列图和后续系统用例图都有了稳定的依托。业务用例图只是告诉读者这个组织对外提供了哪些价值。具体怎么提供的要靠业务序列图来表达。而只有目标组织边界定清楚了业务序列图画起来才不会跑偏。你不用再纠结“某个内部操作是不是该画进来”因为你已经从组织价值出发把内部流程的起止点定义好了。以医院门诊为例当目标组织确定为“门诊部”规格细到科室层面那么画业务序列图时对象就可以是导诊台、分诊护士、门诊医生、收费窗口、药房这些内部业务单元。当目标组织确定为“门诊部内部的某个专科诊室”对象就会明显收缩邻科会诊就变成了外部执行者交互。也就是说目标组织规格范围的调整决定了你后续每张模型的视野宽度和信息密度。前面省一步后面可能要花十步来补救。我自己重读第2章时的最大感受是所谓业务建模本质上是在做“有边界的观察”没有边界就谈不上观察。目标组织规格范围就是这个边界的标尺医院这个例子恰好把标尺上的每一格都演示得清清楚楚。下次你接到一个“给医院做系统”的需求时建议不要急着画原型先拉着相关方在白板前画个圈把目标组织规格范围调清楚。你会发现后面的路突然就亮了。