凤凰时尚网移动版

总之，大多数时候，你要想做第二种流程图，必然要先将第一种给梳理出来。所以，第一种如实反映的流程图是躲不过的。既然如此，基于YY或者头脑风暴是不现实的。我们需要走到前线去，掌握现实中业务是如何运作的。而且很多时候，越细节越好。

那怎么做呢？基于有限的知识与经验，我可以给如下建议：

调研

梳理呈现

评审确认

三部曲，如图所示：

除了在本部分开始的那几个问题要顾及到，其实调研过程解决的仍然是who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？搞明白这几个问题，我们的调研就可以圆满完成了。

流程图的表现，要回答这几个问题：

Who——谁？部门，角色，岗位

What——什么事情？

Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。

Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里操作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）

Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。

Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。

举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。

在调研中：

你首先可以要求精通业务流程的人给你系统讲解一遍。

调研具体操作的人，来验证他给你讲解的是否全面和偏差。

实地观察和记录（花点时间走遍业务流程）

三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。

比如，你现在找到了一个厨师：

你主要负责做什么菜系？

热菜。

那菜单都是谁给你的？

我们的服务员。

她都怎么提供给你？

她负责客人点菜后，然后手写一个单子，给我放到窗口上。

单子上都会写什么？

桌号、菜名等

那如何客人点的是冷菜呢？

恩，有复印本，直接拿一份给冷菜间。

那你怎么开始工作呢？从洗菜到切菜，一直烹饪都是一个人吗？

哦，不，我只负责烹饪。当接到菜单后，首先我的助理会进行择菜，刀工进行切菜，这样如果有几个菜就完全可以并行。

当你们做好后呢？

放到窗口，按铃，喊桌号和菜名，传菜员就会传菜。
……

在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，”烹饪”，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。

而另一家餐饮店的业务流程却是不一样的，你同样抓住一个厨师进行询问：

要做什么菜，菜单是哪里来的？
打印出来的。

所有菜都会在这里打印吗？

哦，只有热菜在这里打印出来，冷菜、酒水就会在冷菜间和酒水间打印出来。

打印机是谁在操作的？

没人操作，它会自动打印不同的单子给我们。

……

下面的问题，可能厨师就不了解了，要问点菜员了。

请问你是怎么点菜的？

拿设备啊，客人点菜就按几下，确认就好了。

之后呢？

之后就可以将菜单打印出来。

不同的菜系会在不同的烹饪间打印吗？

是的，我们可以分单打印。是在这中心打印机里完成分单。

然后，你可以继续调研烹饪后的传菜和上菜流程。

你的调研和观察使你拥有了“烹饪”所需的原材料。

角色：部门、岗位或人

活动：做了什么事情

次序：做这些事情的次序如何

规则：什么情况下到什么事情

还记得我们之前提过的流程图要素吗？回顾下：

接下来的任务是不是很简单，对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。