工作流引擎建模优化

工作流建模工具优化？

     在工作流引擎系统中，业务人员通常情况下会根据自身的一些业务特征和需求去绘制一个模型图，然后进行编码工作，最终交给测试人员进行测试，这样的开发流程也会导致一个问题，测试人员需要耗费过多时间琢磨相关流程的业务含义和需求，然后对每一个业务流程需求进行细化，书写用例，最后测试。如果说测试人员和开发人员对于需求的理解有误差，可能也会导致在测试的过程中会反复的遇到一些常用的常见的问题，然后咨询开发人员，这样就会导致整个开发周期大大加长。

     为此盘古BPM工作流引擎已经考虑到到了这个问题，随之推出了流程自动化测试的功能，这样即可以大大减少测试人员的测试周期，沟通问题以及反复回归测试的问题。从而使人人可以绘制流程和测试。测试人员无需再去对流程需求进行更加细化的梳理和整理。甚至说根本不用再去了解流程是怎么回事以及如何运转。盘古BPM工作流引擎彻底将建模工作交给业务实施人员的前提就是自动化流程的强大和无BUG。虽然说测试人员对于整个流程需求无需过多的学习，但是还是解决不了运维人员绘制流程的问题？为此特意推出了建模明细功能。旨在帮助企业更好地了解业务建模的瓶颈，比如说是建模元素不够用怎么办？工具栏不强大怎么解决？业务需求吃不透导致的反复进行建模元素的绘制问题怎么办？BPM2.0标准知识不系统等等问题。

     由于BPM2.0标准过于庞大、臃肿和死板话，也会导致每个业务建模师对于标准的理解程度不一致，只是水平参差不齐，进而建模的时候各行其是，难以标准话。这也是工作流系统中的一个痛点，核心建模师离职之后，系统直接崩溃，新流程无人能快速绘制。这也是盘古BPM工作流需要重点解决的问题。每家企业根据自身的一些业务系统去收集建模师的建模喜好，BPM建模元素的使用情况，推出更好、更接地气、更简单实用的建模元素和操作标准。从而达到认知标准一致，操作喜好无差异化。

      对于BPM2.0标准而言，因为没有太多的边界值，每个人的理解又不是完全一致。 比如没有标准之前，同样的流程交给“张三”和“盘古”两位同学来绘制，“张三”同学可能会使用到2个节点绘制这个流程，“盘古”同学可能会会使用到3个节点绘制这个流程，在规范标准之后，“张三”和“盘古”两位同学可以轻松使用两个节点搞定流程。这也侧面说明标准的重要性。

      因此盘古特意推出了流程明细功能，当业务建模师在绘制流程的时候，系统可以去统计每一个业务建模师的喜好，比如说张三用户经常使用到的一些元素、集合节点、事件等等？虽然每一个用户的操作喜好是不一样的，但是我们的系统标准是一样的，这样我们就可以使用系统标准去衡量每一个业务绘制人员的知识水平和理解度，进而进行定期的培训，从而让每一个业务建模是对于BPM2.0的标准认知是一样的。

     这样经过长时间的发现问题和收集大量业务建模师经常使用到的一些元素，就可以快速诊断出每一个业务建模师对每一个元素的理解，从而达到一个统一标准，进而提升生产效率。

      盘古BPM对于元素以及工具栏进行了操作行为的收集。收集到的日志大概有下面两个部分。

      第1个部分用于收集常用的一些BPM2.0元素使用情况和元素的一些操作情况，比如说元素的删除，元素的添加、活动或者连线的操作，节点按钮的点击情况等等，这样做之后，经过一段时间系统就可以计算出在不同的系统中，在不同的业务场景中，不同业务建模师对于元素或者节点的使用情况和占比。

      第2个部分用户收集工具栏的使用情况。 不同的业务建模人员存在有不同的喜好，因此系统肯定能分析出效率低下的原因，比如一个建模师经常进行节点的删减操作，建议去看看需求再来绘制，经常进行节点的增加就建议使用复制粘贴功能，经常去二级面板拖拽元素绘制，就可以将二级面板提升为一级面板，一级面板元素不经常使用，就可以将其降级为二级面板元素等等。

      系统可以收集不同用户的喜好，就可以对不同的业务线建模师进行定期的专业技能培训，从而大大提升业务建模速度，然后发现和收集系统中经常出现的一些问题，进而按照不同的业务线拆分出来不同的菜单模块和建模工具，从而让建模工具更加的好用和耐用。

      接下来看一下盘古BPM工作流引擎中如何使用流程明细功能。这里以这里借款流程为例进行说明。首先打开“工作”，然后找到模型管理，点击新增按钮，紧接着开始进行模型的绘制，业务建模师可以根据自己的需求进行建模即可。

建模日志

    用户任意绘制一个模型之后，点击流程明细如下图所示：

流程明细

流程明细分为下面5个模块：

盘古BPM工作流后台有操作行为的导出功能，使用方定期导出分析即可。

相关教程