订单可视化2实战-生产交付流程（流程再造核心区）

1.      

1.1.  概述

订单可视化的核心便是主生产交付流程，也称制造过程。生产过程如果复杂的话，可以将触角延伸至每一个角落与具体岗位；简单的话，也可以成为一条线，即不管3721，流程如流水，一路向前，直至流程结束。

做一个主流程再造，做到哪个部门，我就要得罪哪个部门。因为流程再造的目的便是打破各自的舒适区，找出各节点的问题，加上我们的重新整理会影响责任与利益。

还有一个重要的点是，当前公司各部门基本上所有的问题处理都是EXCEL，一开始照着EXCEL实施（犯了一两个月错误）这本身就有问题，后面我们便不再听从业务部门，而是按照以用户为中心的WEB程序化，信息系统化，打破以前的习惯，遇到的阻力不小。

图 2‑1最简流程图

1.2.流程上下文是矛盾的焦点

做流程就是要理顺各环节之间的利益矛盾与责任归属，明确各自的职责。而我们在做流程时，光拉通这一根线，直至最后稳定就用了整整一年。而且我们在此情况下放弃了其它所有业务（如各业务环节细化，只做这个流程及对应的考核，简单分析）才有了初步成果。造成这种情况的原因主要有：一、公司管理上存在一定问题，各环节没有一定基础的责任归属，一旦出问题，便是各自推责。往往一个物料或者一个质量问题，需要几个部门协调几次会议才能最终达成一致，这需要一个过程，而这个过程无法加速，所以随着流程的基本稳定，我们开始着为每个环节弄一个转序标准、驳回标准、异常提交标准。

流程按activiti(现在叫flowable)的设计，根本就没有驳回一说，所以需要经过的线就是画线。按照这个理论，如果把每一种可能都划线，那我们项目组会得骂得很惨。所以我们采取了动态画线的功能，即介入流程引擎内部，动态画线进行驳回。

我们放开了驳回功能，允许用户自由驳回到任意节点，但发现真正放出此功能用的时候数据就会乱套了，很多时候扯皮的事情谁也不认。没有办法，我们只能限定后一环节向上一环节驳回。

总的来说，流程再造的核心便是将流程各节点的责任与义务明确成点，让操作人员有可以参照的点，最终形成制度并将制度流程化、模板化。

在将核心流程理顺以后，当系统运行稳定后，便可以再逐步实施各个节点的业务。

1.2.  流程版本迭代（升级）带来的问题

流程版本稳定后，我们可以专心的做其它的东西。可是，罪恶的根源就在于流程再造需要不断迭代，不断迭代的结果就是流程不断的发版本。而流程的升级是困扰业内的最大问题，到不是说技术上有多难，而是一旦升级业务与统计分析均要改变适应，并且最大的工作量还要在于兼容以前的老版本，一个订单一两年之久。

为什么要兼容以前的老版本，这个需要从流程与流程实例的概念进行说明。每一个版本发上去以后，可以有许多的流程实例（可以理解为一个生命），为了保证生命的运行过程（业务）不受干扰，是不能去改这个模版的。而且升级了流程便是更改了业务逻辑，所以原来的实例还是保持原样，新开的流程才会用最新的。

这个兼容性问题在OA等 办公流程上是不会出现的，因为不关注业务仅流程而已。而BPM是需要关注流程背后的逻辑，需要想办法让所有辈份的流程业务都能正常运行，这就会造成每个流程版本需要写一套代码（逻辑），造成代码量增大。

另外一个问题是流程（业务）的变更，导致 不同流程中节点及业务代表有所不同，这给我们的数据分析及统计工作带来了极大的挑战，这也是初期数据一直不致不准确无参考价值的最大原因。

1.3.  流程拆单带来的一系列问题

拆单这个问题是困扰了我半年之久的问题，直到现在我们仍然采取相对折中的方式在做处理，但对于有子流程的仍然无法给出很好的答案，在看过《activit权威指南》后，有了思路，理论上是可行的，此书不错，推荐搞流程的好好看看。

拆单在制造业是合理的业务场景，拆单带来的问题主要有技术上有子流程、和分支的时候，流程在克隆后还需要进行现场恢复，以便让用户感觉到一致；业务上，便是增加了数据展示的复杂度，增加了订单状态监控的复杂度。

拆单我们最初也想过一台设备开一个流程，但如果100，1000个，那这就麻烦大了，人和机器都吃不消。所以最后我们便采取新开流程再恢复现场的办法，前面说过这个方法比较好，麻烦在于当流程复杂后，恢复现场太难了。好在我们的主流程暂时还算简单，随着对activiti引擎的深入了解，现在对于如何恢复有了思路但实施还是需要不断的实践纠错。

1.4.  如何保证流程数据的准确与执行到位

由于我们的流程完全依赖人工进行任务处理及数据输入，如何管理好流程的数据成了最大的难题。在执行之初，没有做入考核模块以前，同事们总是想点就点，催一下就点一下。我心里急啊，再这么搞，这系统就得作废，在会上提出来以后，总经理给了提点与部署。做考核，每个节点过期一天扣一分，后期再用这个进行扣钱。这个东西出来以后，效果惊人。

但在考核这一块，目前我们只有扣分，没有加分或者综合评价一个人。有可能出现任务多的，表现也差，所以目前我们采取人工介入的方式处理此问题。我们也在寻求类似淘宝的信用评价体系，结合系统实际来解决此问题。

保持了一段很好的时间，执行一段时间以后人就松懈了，这时就需要制度进行配套，来保证数据能及进的反馈到线上，因此还需要配备管理团队定期检查数据并做处理。这系统只能解决80%的事情，还有20%需要人来介入。假如说数据是从传感器直接读取，就不会有这个问题。

这个过程一是要制度，二是要领导带头及支持。而一个企业流程破坏的最大影响便是领导，所以流程再造体现了领导集本的决心与意志，还需要以身作则。

总的来说保证数据的准确需要做到：一、领导的支持与以身作则；二、制度的规范与执行监察来保证业务人员及时反馈信息；三、不断完善评价体系，对在系统中录入信息有供献、在公司业务做的好的人员进行展示，并给以奖励；四、及时与业务沟通，积极响应业务诉求，一定要为业务部门解决实际所存在的问题（这个流程再造最终的数据分析结果是面向公司领导层）

1.5.  当前系统的不足

没做好主要是前期一直在拉通流程与核心节点的业务，时间、精力与人手均不充分。而且软件工程这事，不一定就是加人就好，人多了就容易人浮于事，因此适当做长线可能更合适。

一、   用户个性化信息存储

随着系统功能越来越多，让用户看到所有功能这不是可取之处。用户根据需求仅关注自己的功能，关注自己相关的订单或者关心的订单变更信息，对重点项目发生的事情可以接收到预警信息。

二、   数据分析友好性仪表盘

用户登录账号，自己关心的信息显示在自己设定的仪表盘上，一目了然的看到订单的运行状态、历史对比、同级对比、预警信息、公司整体运行情况、历史质量问题等等信息。再根据需要是否下钻。

数据分析是一个大活，随着系统的数据逐渐增多，功能越来越大。一般的公司都会有四五个人的小团队专门做数据分析。在条件不满足时，我们只能捡最重要的，抓大放小，细节活能放就先放一放。

三、 与公司现有IM对接，并实现消息的即时推送

公司内部有OA，需要与其对接，做到消息的即时推送。还有就是页面上当接收到新的任务及变更时，后台需要向前台直接推送。这个往大了做就是一个消息推送系统，互联网上有对应的SAAS服务，但我们是内网，只能自己做。

四、   界面不友好，相对来说较为传统的后台管理

虽然基于Bootstrap，也用了标准的商业模版，但在我们这些技术人员的折腾下，也是有点丑。好在还能用，一直没有一个合适的前端来做此事，当然，这是因为条件不成熟，暂时也就只能忍着。现在我们尽量的让期颜色 单一、布局整齐，尽量看起来整齐一点。

作者：长沙大东家

邮箱：[e-mail]

日期:20170930 凌晨 于长沙