做工作流需要拿出足够的勇气，并且需要长时间投入，这个是不少公司有研发工作流但最终失败或放弃的原因。我们现行工作流产品，是经过多个版本迭代，并在2015年完全重构后持续发展5年才基本稳定/可靠的。想快速见效或者项目化使用，建议就外购成型工作流组件即可，要不然上线后工作流将成为灾难存在......

在高度分工的商业环境中，消息平台已经是业务协同的核心组件。

经过4年的发展，自研工作流已经形成了初步完整体系，已包含流程设计器/工作流引擎/工作流引擎支持服务/工作流消息组件/工作流运维工具/工作流引擎扩展方案为一体的工作流整体解决方案。为了尽快推进工作流产品在全公司的了解，正在推进工作流引擎开发与实施移交系列文档。工作流体系组件架构及依赖关系，作为工作流产品实施过程中必须理解的内容，将作为移交系统中的开篇，为实施团队提供工作流体系全貌的构建图，以...

执行审签，常规工作流只提供一个确认结论，然后给出意见输入就完了。随着风险管控需求的加深。要求管控内容贯穿整个企业运营过程。其中审批环节将是重要的管控结合点，所以我们的工作流引入了审批过程单据，审批意见明细化以及审批意见回复等内容。并在审批节点引入审核提示等内容，支持审批与全面风险管控相结合的方案。

统一流程平台，独立与业务系统，面向企业基础信息化构建。

由于整个产品是基于元数据方案构建，在协同平台支持下构建的业务实现，使我们在开始构建工作流产品的时候，就针对可能的变化做好了预留。我们没有严格按照AOP开发构建出切片点/CI等标准概念，但根据业务模型需要，采用管道架构模式，对所有的执行动作都划分为DoBefore/DoWork/DoAfter标准过程。三个动作连续依赖，使实际开发人员能根据业务需求，在特定的位置集成特定业务。在近4年的业务广过程..

审批加签，主要的目的是解决审批过程中审批业务需要系统配置之外的人员参与时，提供给业务人员的一种操作可能，使具体业务能基于现实需求完成相关审签。

审批节点选人，是工作流引擎适用性的一个核心组件，节点选人方式将直接影响到工作流引擎的生命周期。经过4年的不断调整，优化，形成了当前基于四个层次加工选人的标准方案。

低代码平台不是无代码平台，采用配置的方式完成UI/流程/报表的处理，有业务人员在完成基本的产品框架后，由研发人员完成业务规则代码固化，最终达到产品交付的目的。

移动应用暂时未发布使用，如果整体完成发布，将是一个不错的开发框架，但主体沿用了ruoyi-vue-pro的解决方案，缺失以数据为中心的建设思路。ruoyi-vue-pro是芋道开源的一个springboot单应用项目，基于ruoyi平台扩展事项，包含了常用的应用示例。这个项目包含了基于组织结构的权限体系/并实现了当前通用的应用实例，包含了bpm/报表等应用基础组件，是一个快速开发平台的基础原型。生