统一流程平台----面向业务而生

企业工作流平台经过近年的沉淀，从技术概念慢慢转向了业务需求技术解决方案。出现的方式作为低代码平台的一个流转组件，或者是升级为企业内业务流转的通用平台。不管怎么样，统一流程平台不再仅是技术模型，也同时是业务解决方案。

1. 工作流平台

当我们在企业内提到工作流平台时，大家都会认为这已经是一个标准技术组件，没有人会重新去设计。当我们真的去购买一个工作流组件或引入开源的工作流组件时，不得不面对各种的不适应：源码的分析/业务集成的推进/各种认知的重新定义等。

在2015年7月前，面对内部的自研工作流平台的缺陷，要不就避而不谈，人力完成流程流转。

2016年1月在珠江新城落地第一个R9版本时，整个运营支撑团队清爽了不少。

所以，工作流平台的核心是流转引擎运行稳定，再提供配套的运营支撑工具，这两个方面的配套才可能让业务平台平稳运营。

在现实中，大家关注的往往是运行流转引擎，把所有的问题都归结于此；在近年的工作运营过程中，以证实工作流引擎存在大量无法处理的事项，必须由外围的支撑服务与运营工具完成相关事项。

所以，工作流平台应该包含：工作流管理平台：【接入模块/流程设计/发布流程/流程实例全生命周期/流程运行分析/运营审计日志等】；工作流流转引擎；工作流支撑服务等构成。

在当前流行的开源低代码平台或近期构建的自建流程平台，java方向的工作流引擎基本在flowable或actvitiy的基础上构建，形成了较为通用的面向中小企业的流程解决方案。

基于开源项目的分析，大多数都是较为原生的集成，很少去改造。这给人很大的认知障碍。而规模化应用，经过量身改造才可能应对。

2. 统一流程平台

在2019年，我们的c#方向产品中自研工作流平台趋于稳定，并经历了类似某水务集团上千家分子公司规模化使用验证。怎么去构建符合国情的下一代基础平台成为我们必须面对的问题。最终我们进入了java方向，并且准备接手兄弟部门的一个flowable6.5原型构建独立于业务系统的统一流程平台。

flowable是面向技术的，解决了业务流转的核心技术。它存在面向技术的局限性；而我们自研的工作流平台存在大量实用的功能，是无法在flowable中短期实现。

回头来看，我们对flowable的改造让符合国情的企业实际需求在项目中落地：驳回/移交/取回/加签/并行分支/子流程标准化拼接/面向业务的消息队列集成等。让我们的统一流程平台在flowable运转内核的基础之上完成面向规模企业需求解决方案构建。

统一流程平台是工作流平台的一个延申：他的内容与工作流平台类似。

3. 面向业务而生的平台

在统一流程平台中，为了解决规模企业的实际运营需求，提供了一下解决方案：

在实际业务中，不仅仅需要流转，同时需要触发深层业务运转，使产品相对智能化。这给我们在分布式支撑消息上构建了独立的消息与业务编排内容。

面向业务，统一流程平台在标准化与外围定制中不断前行。。。。。