业务建模 之 业务用例图

读书笔记

业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。

很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了。其实，我们那牛×哄哄的系统也只是组织的一个零件，和组织厕所里的马桶没有本质区别。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人肉系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。要改进组织的价值，不一定要开发软件，有时换人（也就是说，不是更换软件系统，而是更换人肉系统）更管用。和一套软件系统的价格相比，也许雇用一名高级员工花费更多。

为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后发现问题，自然要改。“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求变化会消于无形。遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。设计是应对真正需求变化的手段，假的需求变化应该通过改进业务建模来应对。

1. 【业务建模步骤1-1】：选定要改进的组织

如何圈定这个最合适的研究范围，没有标准答案，可能要试很多次。如果发现组织的绝大多数流程和改进不相干，说明选的范围可能太大了；如果发现很多要改进的地方未涉及，说明选的范围可能太小了。

以下是可以参考的几点思路： 画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统…）包在里面。

2. 【业务建模步骤1-2】：组织的业务用例图

2.1 业务执行者

首先来寻找组织的执行者，也就是业务执行者（Business Actor）。业务执行者的定义是：在组织之外和组织交互的人群或组织。

有箭头从执行者指向用例，也有箭头从用例指向执行者。前一种执行者称为用例的主执行者，后一种执行者称为用例的辅助执行者。

2.2 业务工人和业务实体

在寻找业务执行者时，有时会和组织内的人混淆，例如银行里面的营业员。营业员在组织里面，不是业务执行者，我们称其为业务工人（Business Worker）——组织内的人肉系统。

业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的零件。

业务工人可能会被新的业务工人替换，但更多的可能是被新的业务实体（Business Entity）替换。业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。

责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。

业务用例中为什么只有业务执行者？

1. 业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。
2. 在识别业务执行者时，不需要画业务工人和业务实体，在接下来画业务用例的实现——业务序列图的时候加上就可以。
3. 业务执行者是一个组织（或人群），而不是系统。因为研究对象是组织，和它对应的概念也应该是组织。

2.3 识别业务执行者

识别业务执行者时，可以这样思考：拿着摄像机对准组织的边界，谁上门找它办事？谁打电话给它？谁发邮件给它？它出门找谁办事？打电话给谁？发邮件给谁…可能就会找到它的供应商、客户……如果研究的组织是一个部门，那么其他部门就有可能成为它的执行者。

2.4 业务用例

业务用例是什么

业务用例指业务执行者希望通过和组织交互达到的，而且组织能提供的价值。以上面提到的商业银行为例，我们可以这样思考，储户到银行的目的是什么？可能是存款、取款、转账，得到银行针对储户的用例.

业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现.

业务用例刷新了业务流程的概念。我们把业务流程看作是业务用例的实现，将其组织在业务用例的下面。组织内部之所以有业务流程，是因为要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。

这种思路对改进业务流程有非常大的帮助：先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。

识别业务用例

`识别业务用例有两条路线：

1. 一条是从业务执行者开始，思考业务执行者和组织打交道的目的；
2. 另一条是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。`

   第一条路线是主要的，思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点。第二条路线用于补漏，找到之前可能会遗漏的执行者和用例。

管理型业务用例

采用第二条路线思考时，会出现的一个错误是直接将内部活动作为业务用例。只要了解基本道理，稍加注意就可以避免这个错误。这条路线还引出一个值得商讨的话题：管理型业务用例。

例如，公交公司里有调度员负责制订运营计划，计划哪条线路配备多少台车，配备多少司机，每天多少个运行班次，每班的发车时间。如果以公交公司为研究对象，调度员是业务工人，所以“调度员→制订运营计划”不是业务用例，那么这个工作归属于哪个业务用例呢？通过思考调度员为什么要“制订运营计划”，一直向外推，可能会得到类似“公司董事会：提高公交线路效率”这样的用例，即管理型业务用例。

“管理型业务用例”还隐含另一个问题：也许现在挑选的研究范围并不合适。如果调度流程是需要改进的核心流程，说明选择公交公司为研究范围不合适，可以考虑缩小为公交公司调度室。当然，如果不存在这样一个专门的调度室，仍然保持原来的研究范围也没关系。

2.5 总结

业务用例是组织的、而不是组织内某个系统的用例。 组织的用例不会因为某个人肉系统或电脑系统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的。您可以注意到：前面画的业务用例图，研究对象都是组织。

为什么要研究组织的用例呢？因为我们想要把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。

业务用例不是思考系统提供什么“功能”，而是思考组织购买了这个系统，对组织本来就有的哪些“功能”会带来一点点帮助。