开发软件之前的业务流程梳理：从现状图到系统需求

许多软件项目都从一份功能清单开始：需要采购模块、需要库存报表、需要分级审批。清单看起来很完整，却常常跳过一个更根本的问题：今天的工作实际上是怎么进行的？谁在做什么？工作在哪里停滞？哪些环节真正需要改变？如果没有这些答案，新软件往往只是把旧的混乱数字化，或者反过来强加一套与现场实际不符的流程。

业务流程梳理（流程映射）就是在写下第一行代码之前回答这些问题的方法。本文介绍什么是流程梳理、现状图与目标图的区别、如何组织流程梳理工作坊、对大多数企业而言足够用的图示方法，以及如何把流程图转化为清晰的软件需求。

摘要

• 流程梳理描绘一个工作流程中的步骤、角色、单据、决策和等待时间
• 现状图（as-is）反映实际情况，目标图（to-be）展示改进后的设计
• 最大的浪费通常出现在等待时间、重复录入数据和不必要的审批上，而不在工作速度上
• 简单的泳道图足以应对大多数项目；流程复杂时再使用完整的 BPMN
• 达成共识的目标图将成为需求文档、测试和用户培训的基础

为什么要在开发软件之前梳理流程？

软件项目失败的一个常见原因是需求没有被正确理解。用户根据自己感受到的问题提出功能需求，而不是基于完整的工作流程。采购部门要求更快的请购表单，而真正的问题却是审批在一位出差经理的桌上等了三天。

流程梳理能让这类问题显现出来。把每一个步骤从头到尾画出来之后，团队就能看到工作在哪里停下、数据在哪里被重复录入、决策在哪里缺乏足够的信息。随后软件就可以针对这些环节进行设计，而不只是把纸质表单搬到屏幕上。

现状图与目标图

As-is：描绘现实

现状图反映今天实际的工作方式，包括捷径、例外情况，以及在系统之外进行的工作，例如 WhatsApp 消息或个人电子表格。最大的诱惑是按照书面制度来画流程，而不是按照实际情况。因此，现状图必须与真正执行流程的人一起绘制，而不能只由他们的上级完成。

对于每个步骤，都要记录由谁执行、需要什么输入、产生什么输出、使用哪个系统或单据、执行需要多长时间，以及进入下一步之前要等待多久。正是这些等待时间数据，最常让人恍然大悟。

To-be：设计改进

目标图展示改进措施和新软件落地后期望的工作流程。并非所有改进都必须依靠软件。有时需要的只是删除不必要的步骤、合并两道审批，或把决策权交给更接近实际工作的人。之后软件再去支持经过简化的流程，开发成本更低，使用也更容易。

组织流程梳理工作坊

1. 01选择一个边界清晰的流程，例如从请购到支付供应商，而不是一次梳理全部运营
2. 02邀请所有相关角色的代表参加，包括一线员工，而不只是部门负责人
3. 03从流程的触发点和最终结果开始，再按顺序填写中间的步骤
4. 04使用便利贴或数字白板，让步骤便于移动和讨论
5. 05标出每一个问题点：等待、重复录入、反复出现的错误、缺乏数据的决策
6. 06为每个步骤收集真实的单据样例，例如表单、报表和截图
7. 07最后形成按优先级排列的问题清单，并指定负责设计目标图的人

每个流程通常用两到三个小时的工作坊就足以完成初步的现状图。随后通过从头到尾跟踪几笔真实交易来验证流程图，因为人们常常会忘记那些自己习以为常的步骤。对于跨部门流程，例如采购审批流程，往往需要与各方再开一次会，以就交接环节达成一致。

示例：分销企业的采购流程

一家分销商觉得采购流程太慢，想开发一个采购模块。工作坊梳理出从仓库请购到向供应商发出订单的十一个步骤。结果发现，所有步骤的实际工作时间加起来不到两个小时，但从开始到结束的平均耗时却长达六天。大部分时间都花在等待上：请购单要等每周一统一汇总，然后再等仓库经理、采购主管和财务总监依次签字，尽管大多数订单金额很小。物料数据还被录入了三次，从纸质表单到电子表格，再到会计系统。

达成共识的目标图取消了每周汇总，按金额设置审批，使小额订单只需一人审批，并让仓库直接在系统中提交请购。最终开发的软件比原计划更简单，流程时间目标缩短到一天。如果没有流程梳理，团队可能只会做一个数字表单，把两个小时的工作加快一点，而六天的等待依然存在。

对大多数企业足够用的图示方法

流程图的表示方法有很多。对于大多数业务项目，简单的泳道图就已足够：每个角色或部门占一条横向泳道，步骤画成方框，决策画成菱形，箭头表示顺序。泳道之间的交接一目了然，而问题通常就出在这些地方。

BPMN 是一种更完整的业务流程建模标准，适用于分支众多、包含定时事件和例外情况，或将由工作流引擎直接执行的流程。但过于细致的图示会让业务用户难以阅读。原则是选择所有工作坊参与者都能看懂的表示方法，只在给开发团队的文档中补充技术细节。

最常见的浪费

• 数据从一个系统或单据重复录入到另一个，既容易出错又耗费时间
• 对很少被驳回的小额交易设置多层审批
• 因为没有授权代理，工作只能等待不在岗的人
• 数据早已在系统中，却仍每周手工编制报表
• 只有打电话或发消息才能了解的状态信息
• 两个部门重复检查，却互不知道对方已经检查过

这些浪费中的许多都可以通过从单据自动录入数据、例行报表自动化或系统间集成来减少，但只有在流程梳理清楚之后，解决方案才会变得清晰。

从流程图到软件需求

达成共识的目标图是编写软件需求文档的最佳素材。由系统支持的每一个步骤都转化为需求：需要哪些界面或表单、记录哪些数据、适用哪些规则、发送哪些通知，以及谁有权执行该步骤。流程图上的每个决策点都成为必须测试的业务规则。

同一张流程图在项目收尾阶段也会用到。用户验收测试（UAT）的场景按照流程图上的路径编写，包括例外路径。用户培训材料也更易理解，因为它讲解的是工作流程，而不只是屏幕上的按钮。这样，流程图就成为贯穿分析到上线的主线。

衡量成效

由于现状图记录了工作时间和等待时间，企业就有了衡量新软件效果的基准。例如，从请购到向供应商发出订单的时间从五天缩短到一天，或数据重复录入的次数从四次减少到一次。这样的数字远比简单地宣布系统已上线更能说服管理层。

常见问题

谁应当主导流程梳理？理想的人选是一位立场中立、同时了解业务和技术的人，例如内部团队或供应商的业务分析师。关键是业务方的流程负责人要对结果共同负责。

流程梳理会拖慢项目吗？梳理会在前期多花几周时间，但通常能通过减少中途的需求变更以及开发了却无人使用的功能，节省更多时间。

需要梳理公司的所有流程吗？不需要。从新软件将涉及或最常出问题的流程开始。梳理可以逐步扩展，与分阶段实施同步推进。

如果每个分支机构的做法都不一样怎么办？先梳理几种不同做法，再商定一套标准流程，只保留确有必要的例外。这种标准化往往是最大的收益，甚至在软件上线之前就能体现出来。

梳理流程用什么工具？在工作坊中，便利贴加白板或协作式数字白板就已足够。达成共识后，可以在绘图软件中整理流程图，方便分享和更新。比工具更重要的是，流程图要存放在容易找到的地方、标注日期，并在流程变化时及时更新，这样在系统进一步开发或新员工入职时，它仍然是可靠的参考。

结论

业务流程梳理是一笔小投入，却能保护对软件的大投入。通过现状图了解现实、通过目标图简化流程，再把流程图转化为需求、测试和培训，企业就能构建出真正解决问题的软件。其结果是更简洁的系统、更快接受变化的用户，以及可以用数字衡量的成效。