企业工作流平台经过近年的沉淀,从技术概念慢慢转向了业务需求技术解决方案。出现的方式作为低代码平台的一个流转组件,或者是升级为企业内业务流转的通用平台。不管怎么样,统一流程平台不再仅是技术模型,也同时是业务解决方案。
工作流平台
当我们在企业内提到工作流平台时,大家都会认为这已经是一个标准技术组件,没有人会重新去设计。当我们真的去购买一个工作流组件或引入开源的工作流组件时,不得不面对各种的不适应:源码的分析/业务集成的推进/各种认知的重新定义等。
在2015年7月前,面对内部的自研工作流平台的缺陷,要不就避而不谈,人力完成流程流转。
2016年1月在珠江新城落地第一个R9版本时,整个运营支撑团队清爽了不少。
所以,工作流平台的核心是流转引擎运行稳定,再提供配套的运营支撑工具,这两个方面的配套才可能让业务平台平稳运营。
在现实中,大家关注的往往是运行流转引擎,把所有的问题都归结于此;在近年的工作运营过程中,以证实工作流引擎存在大量无法处理的事项,必须由外围的支撑服务与运营工具完成相关事项。
所以,工作流平台应该包含:工作流管理平台:【接入模块/流程设计/发布流程/流程实例全生命周期/流程运行分析/运营审计日志等】;工作流流转引擎;工作流支撑服务等构成。
在当前流行的开源低代码平台或近期构建的自建流程平台,java方向的工作流引擎基本在flowable或actvitiy的基础上构建,形成了较为通用的面向中小企业的流程解决方案。
基于开源项目的分析,大多数都是较为原生的集成,很少去改造。这给人很大的认知障碍。而规模化应用,经过量身改造才可能应对。
统一流程平台
在2019年,我们的c#方向产品中自研工作流平台趋于稳定,并经历了类似某水务集团上千家分子公司规模化使用验证。怎么去构建符合国情的下一代基础平台成为我们必须面对的问题。最终我们进入了java方向,并且准备接手兄弟部门的一个flowable6.5原型构建独立于业务系统的统一流程平台。
flowable是面向技术的,解决了业务流转的核心技术。它存在面向技术的局限性;而我们自研的工作流平台存在大量实用的功能,是无法在flowable中短期实现。
回头来看,我们对flowable的改造让符合国情的企业实际需求在项目中落地:驳回/移交/取回/加签/并行分支/子流程标准化拼接/面向业务的消息队列集成等。让我们的统一流程平台在flowable运转内核的基础之上完成面向规模企业需求解决方案构建。
统一流程平台是工作流平台的一个延申:他的内容与工作流平台类似。
![](https://i-blog.csdnimg.cn/blog_migrate/36d25d5ed39d132122e82c10f568a7d2.png)
面向业务而生的平台
在统一流程平台中,为了解决规模企业的实际运营需求,提供了一下解决方案:
![](https://i-blog.csdnimg.cn/blog_migrate/02f4f53ac27da616f441519b82cbcb24.png)
在实际业务中,不仅仅需要流转,同时需要触发深层业务运转,使产品相对智能化。这给我们在分布式支撑消息上构建了独立的消息与业务编排内容。
面向业务,统一流程平台在标准化与外围定制中不断前行。。。。。