业务流程不是需求

没有一个项目不是重视需求调查的。从第一天开始，开发人员就拿着一个笔记本，把用户都拉到会议室，询问他们的业务流程是什么样的。知道了业务流程，开发者剩下的工作就明确了，一条一条的去实现他们，系统就OK了。但是，业务流程可以代替需求吗？

实际上，在业务流程的背后，有一个更加根本的因素——商业需求。商业需求才是真正的需求，业务流程只是一种实现手段而已。

开发者询问用户：“你们的业务流程是什么样的？”这个问题其实是很难回答的。业务流程的制定首先是要最大限度的满足商业需求。并且，业务流程要受到各种条件的制约，IT系统也是这个条件之一。开发者问用户业务流程是什么样的，用户也要问开发者系统的设计是什么样的，能达到什么样的性能指标，在这个基础上才能制定合理的业务流程。

比如一家移动通信公司，在处理新用户入网的时候采用了一个这样的流程，按流程先后顺序：

1：首先把SIM卡和号码在交换网络上做对应关系的注册；

2：市场部把SIM卡存入一定的金额，发给销售商，收取销售商的货款；

3：销售商把卡卖给用户，用户填写入网合同，SIM装入手机可以立即通话；

4：销售商把入网合同交给市场部，市场部资料录入人员将用户的资料录入系统；

5：计费系统按照用户选择的资费对话单进行计费；

6、市场部按照用户的消费情况给销售商计算佣金和返利。

这个流程的制定并不是业务部门可以单独确定的，他和IT系统有着很深的联系。用户买到SIM卡以后，需要立即可以通话，但是由于IT系统的条件有限，无法做到及时向交换网络注册SIM卡，所以就必须先把SIM卡和号码在交换网络上做好，再发放到销售点去。由于采用了这样的办法，又产生了一个新的问题：买到SIM卡的用户可以立刻打电话，但是在资料录入人员录入用户的资料之前，他们在系统里是没有资料的，也没有计费策略，这是一段资料空白期。怎样控制空白期的时间长度，怎样对这些通话进行计费，怎样防止空白期的恶意欠费。。。又形成了一个个新的问题，于是又要发明一个个业务流程来处理这个问题。

IT系统和业务流程是紧密关联的，他们互相制约，也互相促进。如果希望先把业务流程定下来，再回头去开发IT系统，这个难度是很大的。开发IT系统，需要把目光看的更深入一点：IT系统和业务流程是为什么服务的。

IT系统和业务流程都是为了更好的实现商业需求。商业需求是企业为用户服务、与伙伴合作的过程中产生的需求，每个商业需求都是关系到实际的商业利益的。比如说刚才那个用户入网的流程，如果按照商业需求来看，他是为了满足下面几点：

1、用户买到SIM，可以立刻装到手机里面打电话；

2、用户的通话可以按照他选择的资费策略进行计费；

3、用户交的钱计入他的账户，通话费用从这个账户中扣除；

4、用户填写的合同归档，作为日后办理相关事宜的依据；

5、营业员收的钱计入他自己的账本，待稽核人员下班后核查；

6、市场部根据用户的消费情况付给代理商佣金。

这几点就是“入网”这个业务流程需要满足的商业需求。企业在实现这些商业需求的过程中，一定是遇到了一些麻烦，于是希望有一个IT系统来帮助自己。IT系统的开发者要和企业用户坐在一起，先把这些商业需求搞清楚。在这个基础上，一方面要设计支持系统，另一方面要根据支持系统的情况来制定新的流程。最终实现自动化的业务流程，更好的满足商业需求。

从商业需求中提取重要的元素，分析这些元素的行为和相互之间的关系，我们就可以得到一个重要的东西：领域模型。

领域模型应该来源于企业的商业活动，而不应该是IT系统的业务流程。

设计领域模型，最基本的方法就是抓住一些明显的元素进行分析。更进一步，需要抓住一些隐含的元素。业务领域中有经验的人员，他们在分析问题时候，有时候会随手画出一个草图，写下一些数值，或者查询某个表单，这都是重要的领域元素。了解这些东西，可以使复杂的领域问题变得容易理解，使领域模型更加符合企业的实际情况。

当这个模型渐渐清晰的时候，开发者和用户就可以一边进行IT系统的设计，一边设计出更加合理高效的业务流程。有了一个个实际的东西摆在面前，用户也能很容易的回忆起商业活动中一些重要的细节。比如看到这个租机合同，开发者会问：“这个合同有什么用处？”用户回答说：“我知道一个用处，用户办理资费变更的时候，需要检查一下这个合同，有些资费形式是合同不允许的。”

于是开发者就在资费变更的流程中记下这样的代码：

IF NOT 用户->合同->允许(资费) THEN
  EXCEPTION("用户的合同禁止该资费")
END IF

下一步的工作，就是继续将这个商业需求的细节搞清楚。“合同如何判断一个资费形式是否允许，是判断这个资费的收益率，还是判断他的品牌类型。。。”

不要被表面的业务流程所迷惑，透过表面，看到背后的商业需求，你会发现需求原来非常稳定，这么多年来其实变化不多。也不需要知道所有的细节性的需求，只要了解比较重要的20％的需求，其实就可以开始进行系统的设计和编码了。把眼光放在商业需求上，最终的业务流程才能最大限度的满足需要，IT系统也能面临少一点的“需求变更”。