3.3 产品、服务、流程三域应用

3.3 产品、服务、流程三域应用

本节摘要：同一套七步流程，跑在产品、服务、流程三类问题上，对象清单的构成与模板侧重会自然漂移。本节给出三域的对照差异，并用一个服务域案例完整展开，最后谈跨域迁移的注意事项。

三域的地貌差异

第 1.2 节说过，封闭世界以"用户与产品交互的现场"为界。三域的现场不同，清单就不同；清单不同，高产模板也不同。

一个规律值得注意：越往服务与流程域走，封闭世界清单里"人"与"信息"的占比越高，模板操作的靶子从物理属性变成角色与数据。第 2.5 节空调案例其实已经跨了产品与流程的界——对象是楼宇系统，操作的是数据孤岛。

服务域案例完整展开：退房排队

背景：商务酒店早高峰退房排队，客人投诉集中在"赶飞机还在等查房"。管理层方案有两个：加收银台（加人加硬件）、推行 express 通道（给 VIP 特权，普通客人更不满）。

操作：走七步。重述：对象系统：前台、房卡、账单系统、查房流程；环境：早高峰、赶时间的客人、行李。矛盾："我们想确保房间无损坏才放行，但查房时间使退房排队。"——对冲型（保障 vs 速度），首选属性依赖。生成候选：

服务域候选池节选：

AD-1 放行依赖风险等级：常住客免查直接放行（阈值型）
AD-2 查房时机依赖退房动作本身：插卡于电梯即触发查房广播（提前并行）
联-1 行李员领任务：帮拿行李时顺带目检房间（联合，环境对象领活）
分-2 查房从退房序列中分割出去：改为离店后抽查，押金预授权兜底
​

验收：AD-1、分-2 通过定性改变（"保障与速度的矛盾"被结构重组，前者按风险分级、后者把查房移出关键路径）；AD-2 因依赖电梯改造被暂列储备；联-1 通过但目检可靠性存疑，与 AD-1 组合。

结果：落地组合是 AD-1 + 分-2 + 押金预授权：常住客与低风险订单即退即走，损坏由离店后抽查加预授权兜底。前台高峰队长缩短七成，查房人力反而下降（抽查比例远低于全查）。

解读：这个案例展示了服务域的两个特征——"人"（行李员）与"数据"（入住风险等级）成为模板的操作对象；以及押金预授权这类金融工具是封闭世界边界上的常见灰色地带，它不是新对象（账单系统本来就能做预授权），只是从未被这么用。

变式：医院的分诊、银行的开户审核、软件的账号注销，全是"保障与速度对冲"的脸型，第一反应都该是属性依赖（按风险分级放行）。

图3.3-1 三域模板侧重的迁移地图

跨域迁移的两条提醒

其一，别把产品域直觉硬搬进服务域。产品域最顺手的消除模板，在服务域删掉的多半是某个岗位环节——这动的是人的利益，阻力曲线完全不同，务必配上 2.6 节说的回退窗口。其二，服务与流程域的"伪需求证伪"概率更高。很多审批与查核环节的历史理由早已失效，功能证伪路径（回顾 2.6）在这里的命中率意外地高，值得优先尝试。

⚠️ 常见坑：跨域迁移时忘记重画封闭世界。拿产品域的清单去套服务问题，会把"顾客的等待心理"这类关键环境对象漏在圈外，属性依赖的高产配对（情绪 × 流程行为）就全错过了。

本节要点回顾

• 三域差异集中在对象清单构成与高产模板侧重，流程与规则不变；
• 服务域特征：人与信息成为操作对象，验证快、试点便宜；
• 流程域特征：分割与属性依赖当家，警惕为拆而拆的碎片化；
• 金融类既有工具（预授权、押金）常是边界上的合法素材；
• 伪需求证伪在服务与流程域命中率更高，值得优先尝试。

延伸问答

有没有跨三域的混合问题

有且常见——数字化转型类问题常常同时含产品组件、服务触点与流程环节。处理办法是分层画封闭世界：每域各画一张清单，注明共享对象（同一条客户数据可能同时出现在三张清单上），模板在层内操作、方案在层间对齐。

三域里哪一域最适合新手练手

服务域。验证快（一家门店就能试点）、出圈冲动容易识别（加人加设备）、模板连招空间大。用服务域练熟流程与纪律，再进产品域面对硬约束，节奏最稳。

流程域项目怎么处理部门墙

把部门墙本身写进环境对象清单。它不是背景噪音，是流程封闭世界的真实边界条件——第 2.4 节的重排方案能不能落地，一半取决于跨部门的接口设计。承认它比假装它不存在，方案存活率高得多。

顺手练一题

把第 2 章练过的同一个问题分别放到三个域各推一次：如果它是产品（做成物件）、是服务（有人来做）、是流程（改动做事顺序），候选方案分别长什么样？多数人会惊讶地发现服务域版本又快又便宜。这个练习建立的是跨域直觉——很多问题的最佳形态不在它被提出来的那个域里。

三域报告的呈现差异

向管理层汇报时，三域方案要换不同的叙述重心：产品域先讲验证数据（试点良率、用户测试），服务域先讲一线反馈（执行者的话原样引用最有说服力），流程域先讲指标曲线（前后对比图加异常点解释）。同一个排序清单，配三种附件。这也是把 ASIT 产物接入组织既有决策语言的必要翻译——方案再好，用错了域的汇报语法就会被误读。

域的选择本身是推演对象

一个容易被忽略的自由度：问题被提出的域未必是解决方案的最佳域。退货率高的问题看似产品域，推演后可能发现最优解是流程域的预检环节。建议在定义环节就给问题标注候选域列表，允许方案跨域落地——只要封闭世界清单覆盖了跨域对象，这仍是合法的封闭世界操作，不是出圈。