我的客户正在寻找业务流程管理 (BPM) 解决方案。他们需要的是简单的文档路由和审批系统。实施 BPM 系统的驱动因素是什么?开发人员应该建议实施 BPM 解决方案与工作流工具或自定义开发的阈值是多少?
jBPM 什么时候适合?应用程序中内置的状态机何时适合?应该存在哪些问题来确定您需要使用类似于 jBPM 的解决方案?
我正在寻找一些真实世界的示例,例如“我们尝试自己构建解决方案,但由于_而最终选择了 AquaLogic/jBPM/Lombardi ”。请填空。
我的客户正在寻找业务流程管理 (BPM) 解决方案。他们需要的是简单的文档路由和审批系统。实施 BPM 系统的驱动因素是什么?开发人员应该建议实施 BPM 解决方案与工作流工具或自定义开发的阈值是多少?
jBPM 什么时候适合?应用程序中内置的状态机何时适合?应该存在哪些问题来确定您需要使用类似于 jBPM 的解决方案?
我正在寻找一些真实世界的示例,例如“我们尝试自己构建解决方案,但由于_而最终选择了 AquaLogic/jBPM/Lombardi ”。请填空。
BPM 酸性测试(来自 Michael Havey 的 Essential Business Process Modeling,O'Reilly 出版)。
... BPM 仅适用于具有基本状态或流程感的应用程序 - 即面向流程的应用程序。如果应用程序合法地面向流程,则应用程序通过了 BPM 酸性测试。例如,旅行社应用程序通过了测试,因为它最好根据行程的状态来理解,并且始终根据行程已到达的距离来定义。面向过程的应用程序的其他典型特征包括:
- 长跑——
从开始到结束,该过程跨越数小时、数天、数周、数月或更长时间。
- 持续状态 -
因为这个进程是长期存在的,它的状态被持久化到一个数据库中,这样它就比托管它的服务器更持久
- 突发,大部分时间都在睡觉——
该进程大部分时间都处于休眠状态,等待下一个触发事件发生,此时它会醒来并执行一系列活动。
- 系统或人类通信的编排 -
该过程负责管理和协调各种系统或人类参与者的通信。
...例如,在自动取款机中,用户可以查询他们的账户余额、提取现金、存入支票和现金以及支付账单——任何流程感都是短暂且无关紧要的;ATM 是在线交易处理器,而不是面向流程的应用程序。
我写了一个工作流引擎,因为我的雇主想拥有这个 IP,以 jBPM 为模型。现在,您使用这种工具而不是创建自己的有限状态机的原因是在不改变持久性的情况下适应变化并支持工作流过程的边缘情况,正如我将解释的那样。
您典型的,或者更好地称之为“幼稚”的有限状态机实现具有一组与管理的数据及其流经的过程紧密耦合的数据库表。可能有一种方法可以保留过去的版本并跟踪谁在此过程中采取了哪些行动。如果遇到问题,则会更改数据和流程结构。然后需要更改那些紧密耦合的表以反映新结构,并且可能无法向后兼容旧表。
工作流引擎以两种方式克服了这一挑战,通过使用序列化来表示数据和流程,以及抽象集成点,特别是安全性。序列化方面意味着数据和进程可以在系统中一起移动。这允许相同类型的数据实例遵循完全不同的进程,直到进程可以在运行时更改,例如通过添加新状态。这些都不需要更改底层存储。
集成点是将算法注入流程并与身份验证存储(即必须采取行动的用户)联系在一起的方法。注入算法可能包括确定状态是否完成,而身份验证存储示例是 LDAP。
现在的权衡是难以搜索。例如,由于数据是序列化的,因此通常无法查询历史信息——除了检索记录、反序列化和使用代码分析。
工作流工具的另一个方面是嵌入到其设计和功能中的体验,您可能不会考虑自行推出,并且可能会在您确实需要它时后悔。我想到的两种情况是定时任务和并行执行路径。
定时任务是在经过一定的持续时间后为参与者分配数据责任。例如,假设新闻稿是书面的并提交批准,然后在没有审查的情况下坐了一周。您可能希望您的系统做的是识别那个挥之不去的文件并引起相关各方的注意。
并行执行路径在我的经验(内容管理系统)中并不常见,但仍然是经常出现的情况。它的想法是给定的数据被发送到两个不同的审查或处理路径,只是在稍后的某个时间点重新组合。这类问题需要有用的合并算法和同时表示数据相乘的能力。事后将其编织成一个简单的解决方案比看起来要复杂得多,特别是如果您想跟踪历史数据。
如果您的系统不太可能发生变化,那么滚动您自己的系统可能是一个更简单的解决方案,尤其是在更改可能会破坏旧信息的情况下。但是,如果您怀疑自己需要这种类型的持久性,或者会遇到一些不常见但棘手的场景,那么工作流工具会提供更多的灵活性和保障,您不会因为数据和业务流程而陷入困境改变。
也许问几个问题会有所帮助。
流程会改变吗?旧版本的进程是否会继续存在,而新版本的进程会出现?是否应该测量流程(和每个步骤)的运行时间?
是关于业务流程(协调多个资源的状态)还是资源生命周期(仅是单个文档/资源的状态)?...
对不起,如果它不是一个答案。
我会仔细研究推动您努力的业务需求(即“业务案例”)。据我了解,BPM/工作流程可能有以下一个或多个目标:
1. 自动化操作
这通常需要通过任务自动化来以机器代替人,例如创建文档、归档信息、通知用户等。
2.跟踪每个过程
当存在大量流程时,公司需要建立跟踪,而业务用户通常会在办公文档、电子邮件中运行它们而失去对它们的跟踪。每个外部状态请求(例如来自客户的)都会变成调查。
3. 建立控制
对于管理人员来说,获得流程的高级视图并对其进行统计研究通常很重要:查看 KPI 是否保持不变、是否存在滞后、异常等
4. 管理过程中的文档交换和协作
BPM 通常用作文档交换工具,因为它们通常可以从电子邮件和口头通信切换到 BPM 中的可跟踪交换
5.自动化企业系统之间的数据交换
这是一个纯粹的集成案例,通常在已经使用(或由)各种系统执行许多操作的情况下需要,并且需要自动化它们之间的信息交换。
现在,功能齐全的即用型 BPM 适用于 2、3 有时甚至是 4。jBPM 和其他工作流引擎适用于 1 和 3,但有一个重要的警告 - 它们需要复杂的配置/开发。
基于 SOA 的流程编排引擎(有时也称为 BPM!)适用于 (5) 和 (3)。
请随时添加到列表中并争论!我已将此作为我的博文发布,并在此处进行了详细说明:http: //processmate.net/do-you-need-a-bpm-or-a-workflow/
归根结底,所有处理业务相关信息的业务系统都是 BPM 或工作流系统。任何业务的信息处理都可以用工作流或“业务流程”来描述,涉及角色和活动。
事实上,这些业务活动通常用 Java、C# 或其他编程语言来描述,这基本上只是自动化的结果,没有足够成熟的技术来使用自动代理来处方和描述业务流程。
重点一直放在增长、上市时间等方面,并且在没有适当考虑长期维护和灵活性的情况下进行了计算机化。现在代码中 99% 的内容不应该是这样。
相比之下,实时控制系统、视频游戏、高性能计算、预测、商业智能和数学分析都是不适合图形工作流描述的问题示例。这些都是应该由计算机完成并由计算机专家维护的事情。
业务流程应该由业务运营专家规定、描述和阅读。随着世界经济不再强调“增长”,随着使这种(工作流程系统)变得更好和更广泛接受的技术,灵活性的收益将越来越被认可。