欢迎关注大型情感类主题：有效的需求分析——业务流程篇！

这篇文章的标题和前两个内容不一样。 这让我意识到，虽然自己也画了几年流程图，但到了现在，自己也只限于能画流程图，甚至连怎么画流程图都没有完整的方法论。 但是，幸运的是，直到现在我才意识到有关业务流程的知识是如此独特。

内容回顾

最近的文章是关于需求分析的知识体系。 同样，让我们回顾一下上次的关键知识点。

定义需求：需求=预计-现状。

外因性触发需求：

参观-应对措施：分享收获； 竞争对手的动向-应对措施：竞争分析； 热点与新趋势——应对策略：共享理解的内源性需求——应对策略——表象还原、原因共享、共同决策。

机会场景往往来源于以下三个方面。

新业务； 新技术； 新人们。 stakeholder :项目是游戏。 重要的是获得足够的筹码。 也就是说，需要找到重要的芯片。 如果获得足够的芯片，就可以获得项目。 此外，也不可能获得所有的筹码。

前期的内容主要谈了宏观层面，也就是目标远景的确立方法。 项目方向确定后，需要逐步深入，将能量从抽象层转移到具体层。 今天我们一起来解开业务流程之谜吧。

我们知道

身世

企业存在各种各样的业务流程，但是为什么会存在这些流程呢？ 这是探索业务流程身世之谜的小故事！

改革开放初期，有一个小人物。 而且他是文盲，从7岁开始在路边捡烟头赚钱，9岁做学徒生意。 之后，为了维持生活，买了葵花籽炒了之后卖了。 这个时候，所有的事情都由他一个人负责，自己采购，自己销售，自己发货，自己记账…

我不知道他是从哪里偷的技术，但是炒出来的葵花籽多么好吃。 一次试三次，闻起来很清爽。 这样，他的生意越来越红火，一天的向日葵种子可以卖上千斤了。 自己一个人明显忙不过来，叫了几个人来帮忙。

他请来了kddym，帮助他管理订单、发货和仓库； 请了zldxz来帮我记账、收钱、理财。 然后，kddym必须等到zldxz收钱后，把收钱的证明书交给他，检查后再发货。 否则，就会出现问题。

在那之后一段时间里，销售额越来越大了。 这个小人物zldxz是亲戚，但他觉得即使万一眼红，做账取钱也很麻烦。 因此，他又叫来了蓝猫，让她们一个人理财，一个人理财，互相监督。

后来，这个小作坊越来越发展，开始和税务局打交道。 但是，zldxz的水平，如果能记账就好了，但不能那样做。 怎么办才好呢？ 只能再找一个专业的会计负责这件事。

最后，由于这个小人物雇佣的员工达到了12人，他是否是资本主义也引起了轩然大波……

你知道这个故事的原型是以我们历史上有名的向日葵种王年广九为原作的吗？ 那个时代是铭刻在上一代人心中的动荡时代，也是值得我们每个人用心感受的波澜万丈的历史。 有兴趣的同学，请读一下《激荡三十年》。 其中的故事很棒。

让我们回到主题上来。 从故事可以看出，过程产生的原因在于分工，分工产生的原因可以分为规模、风险、专业三类。

我一个人忙不过来，请了几个人帮忙。 这就是规模扩大带来的分工。 担心zldxz做账，请蓝猫，一个人理财，一个人理财，互相监督，这就是风险发生的分工； 与税务局的交易不能在zldxz进行。 我又找了专业的会计。 这就是专业分工。

分工后，kddym负责订单、发货、仓库的管理； zldxz负责记账、收钱、理财等，各司其职。 这时，kddym被赋予了“仓库管理员”的角色，kddym负责的订货、发货、仓库管理等，就是我们所说的“活动”的概念。

kddym和zldxz之间并不是完全独立的，他们是合作关系。 话里也提到了，zldxz从客户那里收钱，把收钱的证明书交给kddym，检查后可以发货。 在这个环节中，向我们说明了“合作”、“产物关系”、“规则”、“审查”的概念。 其实通过理解“合作”，流程图中各活动之间的连接就变得清晰了。

关于合作进程，并不是一成不变的。 例如，一些VIP客户可以不收费就发货。 这就是过程的“分支”。 但是，不收费发货，一定会有问题的时候。 这个问题就是我们所说的“异常”。

总结一下吧。 这个插曲给我们带来的启示如下。

分工产生的原因：规模、风险、专业； 业务流程的三个管理要素：审查、规则、异常； 业务流程的五个基本要素：分工、活动、合作、产物关系、分歧。

姻缘

正如开头所说，我只限于能画流程图。 现在想想，我画流程图的方法与业务流程的知识体系密切相关。 或者是业务流程知识体系的冰山一角。 幸运的是，我的方法没有大错误，对解决具体问题很有效。

的作图方法包括以下五个步骤。

整个过程的起点是什么？ 整个过程的终点是什么？ 在整个过程中，相关的角色是谁？ 整个流程

程中，都需要做什么事情？做每一件事情的条件是什么？分别产出什么结果？

（此方法的具体实践过程，我在另外一篇文章总结过，我会在文章结尾处加入相应链接，欢迎阅读）

我们与之前小故事得到的启示进行比对，可以找到以下的对应关系：

在整个流程中，涉及到的角色都是谁？对应：分工、协作；在整个流程中，都需要做什么事情？对应：活动；做每一件事情的条件是什么？对应：规则、审核；分别产出什么结果？对应：分支、异常、产物关系。

其实我们细品的话，业务流程的八个要素，都能够在画流程图的方法中找到对应关系，但唯独流程的起点与终点，我们还未涉及。想要了解此处的猫腻，我们还得从企业价值，这个话题说起。

我们先看一个定义：企业或组织的核心价值在于响应客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业/组织带来价值。

企业、组织中的每个成员的工作都是属于某个流程的，从这个定义中，我们得到以下结论：业务流程的起点即外部服务请求；业务流程的终点即满足服务请求。

其实，判断流程的起点与终点并没有我们想象的那么简单，不信的话，我们一起来做一下这道选择题：

用户投一份意外保险，业务流程的终点是什么？

A、保险到期；B、保单出险；C、保单生效

面对这个题目，有没有让你回想起上学期间，期末考试的纠结感？然后，当我公布答案为”C”的时候，又有多少同学是一脸问号的表情的？如果你正是如此，欢迎在留言板一起吐槽~

这道题的解析过程如下：

我们上述，给出了结论：业务流程的终点即满足服务请求。

单纯地从这个结论来说的话，选择C是没有问题的，但是A和B为什么不对呢？其实也很好理解，试想一下，客户给自己投一份意外保险的目的是什么呢？不可能是为了出险吧？应该没有人买保险，是为了使用~所以B是不对的。至于A这个答案，我们类比一下登录流程也就很容易理解了，没有人会把用户退出系统，当做登录流程的终点吧~

对象

此“对象”，也许非你想的彼“对象”，我们要说的是“面向对象”的这种思维方式。

写到此处，不由地想起，自己之前写PRD文档的经历。当时一个功能模块的文档，写了100多页，写起来想死，改起来更想死，关键是，看的人同样想死……所以，为了活着，我们开发直接告诉我，他决定不看文档了，以后只看原型……

当时我问我们领导，文档有没有必要写这么复杂时，我们领导回复我：“当然有，这份文档是公司领导层做需求评审的依据，是开发团队将来开发产品的标准，同时我们做项目交付的时候，这份文档也是交付内容之一啊。”

我觉得这不是我们把文档写复杂的原因，而恰恰是致使文档复杂的“病因”。领导层关注的是方向，并非细节，所以面向领导层时，有时候一个思维导图即可；面向客户的话，他才不关心你是怎么实现的呢，他想要知道的，是这个产品怎么用，对应的应该是《用户使用手册》。而PRD文档，我们可以定义为就是给开发团队造产品的“工程图纸”！面向对象带来的是简洁和高效！

同样的，对于流程图来说，也应该采取面向对象的思想来将其划分。这里，我们就直接给出结论，业务流程可以分为以下四种：

（这是我手动码出来的图！）

优化

最后，我们再来说一个话题：业务流程的优化。

有很多同学跟我探讨过这样的问题：“我们老板说让我优化一下我们产品，这个该如何下手是好啊？”我也回复过很多同学：业务流程的优化，是产品优化的重要一环。今天我们来具体讨论一下，该怎样优化吧。

医院的流程想必大家都深有体会，幸亏每个医院都设置了“急诊室”这样的环节，不然，一部分病人可能医院的流程还没走完，自己就先走一步了~

我们来吐槽一下医院排队这个环节：找服务人员开单，找收费人员收费，检查科室则是每个体检项目排队一次，最后还要排队到服务人员那里拿最后的报告！其中最令人发指的，就是开单和收费需要分别排队，这简直****（自行脑补）。

面对这样的场景，该如何优化呢？其实优化策略思考起来也很简单：第一种就是，我们把开单和收费的环节整合在一起，开完单子直接缴费，无需二次排队；第二种，我们可以把人工收费改成IC自动收费，大大提升效率。

我们将其上升到方法论的层面，总结一下，业务流程的优化策略即为“ESIA”。

Eliminate：即清除无效。找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除。Smiply：即简化高频。对频率最高的环节进行优化，流程效率将提升。Integer：即整合依赖。将相互依赖的环节整合在一起，提高效率。Automate：把人做起来麻烦的事，让电脑来干，提升效率。

当然，一切的优化都必须考虑实际的场景，关于场景这个课题，就让我们下一篇文章再细说吧。

结语

信息系统的核心价值之一是支持业务，而业务支持的核心是对业务流程的固化、优化和重构。今天我们总结了关于业务流程的知识方法，感谢您的观看。

如果我有帮助到您，也希望您能够帮助我一下，您点击的每一次“在看”，每一次的分享，每一次的赞赏，哪怕是一块钱，都是笔者不断前行的动力。晓庄同学在此叩谢！我们下期，不见不散！

相关阅读

如何进行有效需求分析？（二）

如何进行有效需求分析？（一）

#专栏作家#

晓庄同学；公众号：晓庄同学产品笔记，人人都是产品经理专栏作家。智慧校园领域的B端产品经理。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议