深圳oa软件系统

1940年5月10日，德军以飞机坦克装甲师为基础的闪电战vs. 拥有更多更强坦克的英法联军。

14天后，敦刻尔克赢了，坦克的数量质量不是最关键，

最关键是：怎么用？

建模解析重点：在《建模-概念（一）MVC》中，我们讲过：理解表单建模的概念，是为了在设计时依据表单建模的设计思想，遵循必要的设计原则，发挥表单建模的实力，实现较复杂的（normal和hard）流程驱动型业务场景。

表单建模项目的关键：流程！还是流程！！始终是流程！！！

把流程与流程关联成一组流程这码事，在【流程】模块就可以搞定，不需要表单建模。建模表单的核心价值是：

把这一组流程提升到管理高度。

要实现这个提升，肯定需要用到表单建模的一些功能，例如台账与报表。我用下面的图表对比简单的说明一下如何实现管理高度。

所以，基于战术的重要性，我们有必要提升一下流程认知水平，重温一下软件过程，从而最终能归纳出主流程。

（编者注：据说这篇的阅读难度★★★★★，不仅提出灵魂拷问~何为主流程，甚至动用了大三的知识储备~软件工程。）

1. 流程认知：主流程≠OA工作流

2. 工作流：为什么需要主流程

3. 流程认知：主流程是我们思考“业务管理<- ??? ->事务处理”之间的桥梁

4. 流程认知：归纳主流程

5. 主流程是需求与设计之间的桥梁

6. 表单建模如何呈现主流程

1、流程认知：主流程≠OA工作流

在谈到主流程之前，先做个概念扫盲。我们对流程的认知往往来自OA，而OA工作流程擎普遍遵循WfMC参考模型。这就让我们把流程的概念缩小了，大家觉得流程一定得是这样的

  执行起来通常是这样的，在任何时候，只有一个当前（待处理）节点，流程的运行状态即该节点（的名称）。

实际上，流程是分级的，一个企业的流程可以分成4~6级。同一个行业大类，比如说制造业、房地产、金融服务业等等，一级流程基本一致；细分行业的二三级流程的差异是比较大的；具体到企业，四~六级流程也是不同的。

这一、二、三......级流程长什么样？与OA工作流一样吗？下面的国际标准的APQC流程分类框架图，可以看到流程居然是带编号的条目，而不是流程图形式。

我们在表单建模中谈到的【主流程】，是在某个业务范围内，找出属于关键性的事务处理，浓缩成一个流程。

认识归纳主流程，首先是理解Process，而不是设计Workflow。但是归纳主流程的目的，就是要通过信息系统实现它，所以主流程又不等同Process，实际上主流程介于Process与Workflow之间，往往仍采用了流程图的样式，但不是一个糖葫芦串（不受限于任何时候只有一个当前待处理节点）。

欲立先破，流程≠OA工作流，不拘泥于流程的格式，是我们认识主流程的起点。（请参阅《流程认知：流程≠OA工作流》，进一步了解何为流程）

2、为什么需要主流程

任何建模项目都存在一个从“业务原型”到“系统实现”的过程。这个过程与软件开发过程类似，包括需求-分析-设计-配置-测试-上线。

图解：

1.业务方告诉你，我是一只大大鸟，比小小鸟飞得更快更高……

2.你研究鸟儿飞行的原理；

3.你设计出一架飞机；

4.你把它拼了出来；

5.你试驾飞机，坠毁，跳伞逃生后返回3；

6.直到有一天你宣布，飞机??，邀请业务方一起飞。

这其中，第二步不可或缺，而且如何理解决定了后面的结果，当你的理解是“翅膀是飞行的秘密”，那可能做成

 基于这个理解的终极版本是

或者进一步理解成“翅膀向下扑腾的反作用力是飞行的秘密”，那就做成

基于这个理解的终极版本是

直到你发现流体力学原理，才会有如下的成果

开发商业应用时，这个关键的第二步，就是在“理解业务的本质”，思考业务在“过去-现在-未来”保持稳定不变的核心结构。在表单建模中，这个“理解业务的本质”体现为归纳【主流程】。

3、流程认知：主流程是我们思考

“业务管理<- ??? ->事务处理”之间的桥梁

稍微复杂一些的业务，例如采购、制造、设计，都会包含几十个四五级的流程，再细可拆成成百上千个流程操作节点，再考虑到运行起来会重复执行很多次，就像下图所示（一个箭头代表走了一次OA/其它系统的工作流，更细小的流程节点就不画上去了）。

如果我们仅通过OA流程模块来管理，实际会是下面这样，各式各样的流程无差别堆积在【流程模板】中。对于个人，这个问题还不大，只要有“今日事今日毕”的执行力就好，但对于企业整体或各业务板块的管理者们，无法一目了然地观察到哪些出现风险，哪些应急宜缓。

一个业务不等同于该业务包含的全部事务处理（琐碎工作）的简单集合，这好比一台车≠全部零件，一个公司≠全体员工。

好在完整的业务与琐碎具体的事务之间，普遍存在多个用于管理的维度。选择适当的维度，对业务板块进行切割，可以一目了然地从宏观尺度管控。就像这样，就能较好判断：新品品类够不够、订单是不是在下降、库存是否积压、产能是否充足......而不只是盯着这张订单的交货赶不及了，那个新品研发项目成本超了，又或是某一种原材料短缺了。

自上而下拆块管控，可以很好地避免了通过“细致入微地控制全部10000+个零部件“从而实现驾驭一台疾驰的车的尴尬。（一台整车通常包含一万多个不可拆解的零部件）

对宏观的业务切割，常见的有两个维度：1> 按业务对象；2> 按对象状态。

• 按业务对象，比如，项目管理的【项目】、合同管理的【合同】；费控的【会计科目】或【成本中心】等等，这个维度是横向分割业务。

• 按对象状态，项目管理的“项目状态”、合同管理的【合同状态】、采购管理的【采购进程】、资产管理的【资产状态】，费控的【归口管理部门】等等，这个维度是纵向分割业务。

 业务方通常不考虑主流程，但无论过去现在未来，他们都会用（大部分时候是同时在用）上面两种方式，把一个业务板块分割成为更小的单元，这样既可以【呈上】~一览全局，又可以【启下】~管理到更细小的原子级事务（细到流程处理节点）。

其中，纵向分割揭示了关键业务对象，例如合同、项目、资产等等；横向分割揭示OA工作流的关键节点。理解业务方如何分割管理业务板块，流程/IT方就能找到主流程，再结合同行的解决方案，归纳出一个不错的主流程。

PS

我说的是发现和归纳主流程，不是发明和创造主流程。因为主流程在表单建模项目之前，就是存在的（即使业务方此前尚未意识到）。即使来自是公司新开展的业务，也有（可能性>95%）其它同行做过。还有，如果在表单建模项目分析阶段，我们改变了主流程，那也是基于现有主流程在做优化。

总之，不要忽略分析（已知业务）与对标（同行），而去凭空发明主流程。

4、流程认知：归纳主流程

【主流程】对复杂业务做极致简化，简化成一张图或一个表，描述了

①主要的业务场景

②主要业务对象

③业务对象的关键信息

④主要业务场景如何改变主要业务对象及其关键信息

【主流程】在变化的业务中寻找稳定性，昨天、今天、可以预见的明天，业务虽然在持续优化，主流程本身却基本不变。

以下是4个案例供大家参考

No.1、费控管理主流程

【主要业务场景】：预算编制、预算变更、事前申请、事后报销/付款等；关键业务对象：预算科目、成本中心；业务对象的关键信息：预算科目+成本中心+预算周期对应的预算及实际

No. 2、合同管理主流程

【主要业务场景】：合同审批、合同变更、收付款、合同履约等；关键业务对象：合同、收付款单；业务对象的关键信息：合同状态，应收-实收、应付-实付。

No. 3、资产管理主流程

【主要业务场景】：资产领用、归还、盘点等；关键业务对象：资产；业务对象的关键信息：资产状态、资产位置。

No. 4、任务管理主流程

【主要业务场景】：任务创建、下发、执行&反馈、评价等；关键业务对象：任务；业务对象的关键信息：任务状态。

PS：对主流程的归纳，有时仅仅一张流程图是不够的，还要通过归纳主流程背后的数据逻辑来帮助理解主流程。很多业务板块，都存在一个【预期值-实际值】构成的关键数据对，深入研究这个数据对，就会发现，主流程中的诸多事务处理，都是在调整预期值、实际值，而管理的重点，则是控制好预期值与实际值的一致性。比如：合同管理就是在控制【合同额-实收款】这个数据对；费控就是在控制【预算（额度) - 执行(实际发生额）】这个数据对，为了更好地控制，有的预算科目甚至可以拆成【预算额度-事前申请额】和【事前申请额-实际发生额】两个数据对分别控制。

5、主流程是需求与设计之间的桥梁

主流程不仅是业务板块与事务处理之间的桥梁，同时也是需求与设计之间的桥梁。

下面这个燃气工程项目涉及22条流程，此外另有7项事务，因无审批要求未设计成流程。通过“需求->分析->设计”三阶段的关键产出物，我们可以体会到【主流程】的桥梁作用。

（一）需求阶段。列出已知的全部流程，以及非流程关键需求，并根据业务的理解归类。

（二）分析阶段。归纳出主流程的六大步骤，确定每个步骤中的关键流程或者事务处理。

（三）设计阶段的首先做概要设计，确定了流程、台账、报表。

6、表单建模如何呈现主流程

开篇说到：Process≠Workflow，因此主流程的概念与OA工作流不同。在我们借助表单建模将主流程落地到信息系统时，绝大多数表单建模应用，主流程在OA系统中是需要一组流程及功能组合实现的。    

上面的燃气工程项目管理中，一次立项可以是为一个小区统一通燃气，实际执行时，完全可能出现一部分业主已经点火了，另一部分业主还没入伙，也就不会着急考虑通燃气。

这个主流程包含的的22个子流程，7个功能之间确实存在紧密的联系，有些是不同OA工作流之间的触发关系，也有些是OA表单上的字段联动，但绝对不是从头到尾串成一串糖葫芦，大家伙一起齐头并进。

那么，我们怎样呈现出燃气工程项目管理的主流程？

答案是通过【台账】~状态包括“受理、立项、签订施工合同、进行中、异常终止、结束”，其中“进行中”囊括的【设计】、【施工】、【验收】、【点火】则分别用百分比展示出【计划-实际】。

每一行的这寥寥几个数据，每一张工程项目的卡片，背后可能是几十个流程。

再举个例子：合同管理，包括合同的签订、变更、执行、回款，以及子合同的签署等等，可能是几十个4~6级流程，但对于一个主合同，确实存在一个概念上的高阶流程构成的流程组。我们无法在OA上配置出1~3级流程，但我们可以通过建模，配出主合同台账，并用金额/数量或者状态标记出这个主流程。

当然，对于复杂业务，仅仅通过这样一个台账呈现主流程是不够的，比如说合同管理，销售/采购、成本、财务、安监、法务等等部门以及老板、客户关注的信息都不一样，这就要求我们关注：多用户视角。