企业发展初期，会制定一堆制度，来规范企业管理，然而更多是奖励和惩罚的作用，不能提升管理和业务效率，这时便需要搭建企业流程中心。那么，如何搭建呢？本文作者对此进行了分析，一起来看一下吧。
企业发展初期，会制定一堆制度，用来规范企业管理，但制度更多是奖励和惩罚的作用，并不能提升管理和业务效率。
比如，我们开车走高速的时候，超速会扣分、会罚款，这是交通局制定的制度，但用户开车的时候还是会不经意超速，不能很好地解决问题；而流程则是规范用户行为，能指导用户把事情做对做好，比如前面说的超速，地图软件就是流程的应用，通过地图软件全程的指引，用户开车时就很清楚地知道什么时候该减速，从而降低了很多超速的行为。
一个成熟的企业，员工是不需要了解制度的，企业通过各种流程和工具把制度落地，潜移默化中规范了员工行为和管理，而且员工体验更好。
既然流程这么重要，但很多企业在信息化建设初期，为快速满足业务需求，各自都会为某一项业务搭建一套流程，从而产生了很多系统和流程，各流程之间是断层的，数据之间没有打通，需要人工线下再整理和汇总，这种流程并不连贯，这时候就需要搭建一个企业级的流程中心。
流程中心作为一种与业务较为独立的系统，应做到以下三点：
1）开发成本
最大程度的与业务系统的解耦，最大程度减少开发资源的浪费与重复造轮子的问题，方便业务系统快速接入，并提供不同的接入方案。
2）整合性
流程中心需建立统一待办、统一发起、统一后台管理，方便员工集中处理流程、提升用户审批与流程处理的效率。同时，流程中心需要与人力资源系统、用户中心、消息中心、主数据平台、财务系统等整合，流程可快速实现上下游对接，如审批时需要使用人力系统的员工、汇报关系等，订单业务流转完成后最终需写入财务系统等，需实现业财一体化。
3）扩展性
流程中心属于企业公共服务产品，所有业务系统都可接入，每个系统又可以独立进行管理；流程中心同时需要具备极强的横向扩展性，如增加一项审批操作驳回、抄送等，版本升级后所有接入的系统都可升级，同时又可兼容旧版本。例如流程引擎版本升级，为了不影响核心业务系统流程，先灰度在内部独立的系统上应用，待运行稳定后业务系统再升级。
这里需要说明一下，目前大部分企业流程中心的定位只是OA的审批流，这个与BPM还是有很大区别，BPM核心解决的是业务流程打通，确保数据的闭环。比如AlphaFlow BPM。
流程中心包括三大核心：流程引擎、流程管理和流程应用。
整个产品框架如下：
1. 流程引擎
目前比较成熟用得比较多的流程引擎是：AlphaFlow、Activiti、Flowable、flowable实际是activiti的升级版，是同一个架构师。
需要注意的是大部分BPM系统流程引擎和表单引擎是一个整体的（如AlphaFlow、钉钉、飞书等），但我觉得这种完全整合并不太好，因为大部分业务系统都有自己的表单，交互也比较复杂，靠表单引擎搭建并不能满足业务需求，交互体验也比较差；所以我建议表单引擎只是作为流程中心的补充，流程中心也可以接其他系统的表单。
业务系统接入流程中心时，复用待办中心、审批消息、审批操作、审批意见、流程分析等，但表单内容与数据流转仍由业务系统实现，流程中心将审批结果回传给业务系统。
2. 流程管理
流程管理是流程中心产品设计最复杂的部分，流程管理员可以流程进行分类、绘制流程图、对流程进行测试和监控等，产品设计时有以下几个点需要考虑：
1）流程分类和编码需统一规划
企业发展到一定规模后，会有几十甚至几百个流程，这时候就需要对流程进行分类，方便员工查找，很多企业在流程分类上比较随意，比如有的创建分类为人力行政类与考勤类，运营类与业务类等，这种会导致员工在发起申请时就已经很迷茫，找不到对应的流程，且容易申请错误。
所以我们在流程分类一定要认真思考，就像知识库一样，要分类简单清晰（这里建议大家看一下流程分层相关的书籍，根据价值链分析，对流程进行分层管理）；另外，分类最好是有人统一管理。
同时，流程的编码也一定要统一规划，流程编码决定了流程单号，单号是唯一的，如果编码不规范，就会导致产生重复的流程单号，对上下游单据都会产生较大影响；这里建议有些流程编码的行业缩写一定不要更改，比如PO是指 Purchase Order 采购订单。
2）流程需要版本管理
流程需求不断调整和优化，每次调整就会产生新的版本。发布新版本后，已经运行中的流程仍然用旧版本，新发起的流程才使用新版本，这样可以保证运行中的流程不容易出错，能正常流转。
3）流程的权限要灵活
流程权限包括后台管理权限、用户发起权限等。有些企业不同部门是不同的流程管理员，所以需要根据流程设置管理员，流程管理员只能管理他负责的流程，包括进行流程发布、节点配置、流程监控、统计分析等。流程发起权限应用的场景很多，需要与人力资源系统或业务系统打通，如指定部门、指定职位、指定角色、指定员工、指定职级等。
比如，我所负责的流程发起权限包括如下：
4）对接不同系统需要有补偿机制
前面讲到BPM与OA最大的区别就是BPM解决的是业务流程闭环，OA解决的是审批流；BPM在与各业务系统对接时，需要调用不同的服务，为了确保流程正常流转和体验，有些服务会采用异步方式，同时还要考虑流程驳回、干预、拒绝等场景，同一流程单号需要确保每次调用业务系统可靠、准确且不重复，出现异常需要有补偿机制。
5）要有流程测试功能
流程调整后管理员和业务方都希望能自动测试和验证，避免发布后出现问题，所以需要能模拟自动测试的功能，这个大部分流程平台都没有该功能。自动测试需要把流程中使用的条件和变量根据不同业务场景填写相关值，然后开始自动测试，看流程是否能正常流转，所有场景测试通过后就才可以发布该流程。
3. 流程应用
流程应用时一定要建立统一待办中心，并统一大家对审批操作的认知，很多系统原来就有自己的待办或者已经定义好的操作按钮，已经先入为主占领用户的一些的认知，这时候统一会有一些难度，但可以从整体流程效率和产品体验上可以慢慢培养，让用户一步步接受。
这还有个前提，操作按钮的定义一定要与各部门流程管理员一起先共识。我在推动建立流程中心时，公司曾使用云之家、K3 Cloud、飞书审批以及自研审批等，每个系统都有各自的一些定义和特殊操作，为统一操作花了不少时间。
以下是我这边最终共识操作按钮定义：
【撤回】：提交或审批后，撤回重新操作，如果下一步审批人已审批不能撤回
【撤销】：撤销申请，流程终止
【催办】：对当前节点未审批的人员发送催办消息，每个流程实例每天每人只能催办一次
【复制】：复制流程申请表单，单号不复制
【评论】：对流程进行评论，可在不同审批意见节点评论
【打印】：对表单按定义的打印格式进行打印
【保存】：流程发起时暂存表单
【同意】：审批通过，流程往下流转
【确认】：对表单内容确认，会弹窗对内容进行二次确认，确认后流程往下流转
【拒绝】：审批不通过，流程终止
【驳回】：流程驳回给发起人，提交后回到当前审批节点
【退回】：包含退回上一步和退回发起人两种选择，退回发起人流程退回申请节点，提交后重新走审批流程
【转交】：将流程转交他人审批
【加签】：前加签，加签他人审批后回到当前审批节点
【抄送】：将流程抄送给他人，抄送人仅查看
这里我只是对流程中心整体产品框架做了介绍，后续还会发布具体产品功能的设计，我之所以想写出来，主要发现流程平台大部分是技术分享，产品分享的很少，因为这个还是太偏向于技术底层。
