产品经理初识流程引擎
一、什么是流程引擎
如果你去网上搜索，可能会被各种专业的解释搞得有点摸不着头脑，从产品经理的角度看这个问题，可以简单地理解为：在产品中，拥有通过可视化图形界面灵活配置多套业务流程的能力，这种“能力”，就是流程引擎。
流程引擎的核心是可在一个产品中配置多套业务流程；可视化配置并非流程引擎的标配，但可视化配置可以检验一个流程引擎的灵活程度，如果一个流程引擎无法脱离代码层面进行配置，而是每次配置时都需要开发人员写一些补充代码，这样的流程引擎是不合格的。
二、为什么需要流程引擎
这个问题很简单，因为业务场景需要。
在实际业务中，有一些场景，流程不单一，或流程经常发生变化，每次都通过代码去调整流程是不现实的，这个时候就需要流程引擎。
流程引擎和传统流程的区别，在于传统流程是将业务抽象成流程，一旦业务发生变化，或产生新的业务，都需要调整流程的代码逻辑或重新编写一套流程代码；而流程引擎则是将业务抽象为流程节点，根据业务的不同，可将流程节点组合成多个不同的流程。
举个简单的例子，以下是常规的电商交易流程：
但对于货到付款的订单，流程则变成了这样：
在传统流程中，上图是两个独立的流程；而在流程引擎中，会将每个流程节点打散，并根据业务进行流程的重新组合：
这样有几个好处：
- 适应复杂多变的业务流程，当流程节点足够多时，理论上可以组合出无限多种流程搭配；
- 流程配置和调整更加灵活，如增加、删减或调整流程顺序等；
- 提高业务模块的复用能力，相同流程节点在不同流程中可以有不同的处理逻辑。
通过流程引擎还可以轻松实现“流程穿梭”的效果，比如有些企业的订单是采用月付的形式，在实际业务中，会形成订单和结算两个业务流程，订单的完成依赖于结算单的完成，因此就会出现两条业务线相互交叉的情况。
而通过流程引擎，就可以很轻松实现两个业务流程的交互：
三、流程引擎的对象
流程引擎常规的对象有3个：人、事、物。
1）人，审批人。常见于 OA 系统的审批流程，比如请假流程，由发起人发起请假审批，经一人或多人审批完成后，结束审批流程。
流程变化一般都会与状态机挂钩，面向人的流程一般只在起点和终点联动状态机更新状态，比如发起人发起审批后，到最后一个审批人完成审批前，无论经过多少人审批，状态始终都是“审批中”，直到最后一个审批人完成审批后，状态才更新为“审批通过”。
当然，如果中间有任何一名审批人不同意，则会提前结束流程，并更新状态为“审批不通过”。
2）事，事务。这种流程主要用于呈现业务的顺序，并且为了明确业务的最新动态，一般在流程的每一个节点都需要联动状态机修改状态，比如上文提到的电商交易流程，就是一种事务型的流程。
3）物，物件或物流。可以反映一个物品的去向或动向，比如物流网点运输设计，可以设计每个网点之间的运输顺序，这样当快件到达某一网点时，就可以同时明确下一站应该发往哪一个网点。与事务流程一样，一般只在起点和终点联动状态机更新状态。
从以上的几个流程你应该可以看得出，并非每个流程都是独立的，在真实的业务场景下，有时候一个流程中会牵涉多个对象，或不同对象之间的流程会有交叉，这种，就是“对象交叉”的现象，下面举几个例子，相信你会更好理解。
- “人”、“事”交叉：公司的合同用印审批流程（人）和合同归档流程（事）是两个流程，当员工发起合同用印审批流程通过后，系统需进入合同归档流程，对完成用印的合同进行归档。
- “人”、“物”交叉：公司的用车审批流程（人）和派车流程（物）是两个流程，当员工发起用车审批流程通过后，系统需进入派车流程。
- “事”、“物”交叉：比如电商交易中，卖家发货（事）后，商品交付给物流，进入物流运输流程（物）。
对象交叉的流程有时候是独立的，比如派车流程开始时，用车审批流程已经结束，而派车流程要在还车后才结束；有时候是强关联的，比如上文提到的，月付订单需要在结算单结算完成之后才能结束。
看到这里，你可能会觉得流程引擎非常复杂，其实不然，流程引擎之所以看起来复杂，是由实际业务的复杂性决定的，流程引擎恰恰是为了能够更好、更灵活地解决复杂业务流程而被设计出来的一种更加简单的流程管理手段。
本篇文章只是很浅地探讨了一下流程引擎，后续如果有机会，可以再深入探讨一下，如果各位对此有兴趣，也可以去搜索相关资料详细了解。
以上便是本文的全部内容，感谢阅读！
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
