您如何知道何时需要 BPM 解决方案？
我的客户正在寻找业务流程管理 (BPM) 解决方案。他们需要的是简单的文档传递和审批系统。实施 BPM 系统的驱动因素是什么？开发人员建议实施 BPM 解决方案与工作流程工具或自定义开发的门槛是什么？
jBPM什么时候适合？什么时候适合应用程序中内置的状态机？应该存在哪些问题来决定您需要采用类似于 jBPM 的解决方案？
我正在寻找一些现实世界的例子，“我们试图自己构建解决方案，但由于_而最终选择了 AquaLogic/jBPM/Lombardi”。请填空。
My customer is looking for a Business Process Management (BPM) solution. What they need is simple document routing and an approval system. What are the drivers for implementing a BPM system? What is the threshold where a developer should suggest implementing a BPM solution vs. a workflow tool or custom development?
When does jBPM fit? When does a state machine built into an app fit? What problems should exist that determine that you need to go with a solution similar to jBPM?
I am looking for some real world examples of "we tried to build the solution ourselves, but ended up going with AquaLogic/jBPM/Lombardi because of _". Please fill in the blank.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
BPM Acid Test（摘自 Michael Havey 的《Essential Business Process Modeling》，O'Reilly 出版）。
BPM Acid Test (from Essential Business Process Modeling by Michael Havey, published by O'Reilly).
我写了一个工作流引擎，因为我的雇主想要拥有这个 IP，以 jBPM 为模型。现在，您使用此类工具而不是创建自己的有限状态机的原因是在不改变持久性的情况下适应变化并支持工作流过程的边缘情况，正如我将解释的那样。
在不改变持久性的情况下适应变化
典型的，或者也许更好地称之为“天真的”，有限状态机实现的特点是一组与所管理的数据及其流经的过程紧密耦合的数据库表。可能有一种方法可以保留过去的版本并跟踪谁在此过程中采取了哪些操作。如果遇到问题，请更改数据和流程结构。然后，需要更改那些紧密耦合的表以反映新的结构，并且可能无法向后兼容旧的结构。
工作流引擎通过两种方式克服了这一挑战，即使用序列化来表示数据和流程，以及抽象集成点（特别是安全性）。序列化方面意味着数据和流程可以在系统中一起移动。这允许相同类型的数据实例遵循完全不同的流程，以至于流程可以在运行时更改，例如通过添加新状态。而这一切都不需要改变底层存储。
集成点是将算法注入流程并与身份验证存储（即必须采取操作的用户）联系起来的方法。注入的算法可能包括确定状态是否完成，而身份验证存储的示例是 LDAP。
现在的权衡是很难搜索。例如，由于数据是序列化的，因此通常无法查询历史信息 - 除了使用代码检索记录、反序列化和分析之外。
边缘案例
工作流工具的另一个方面是嵌入到其设计和功能中的体验，您可能不会考虑自己推出，并且当您确实需要它时可能会后悔。我想到的两种情况是定时任务和并行执行路径。
定时任务是在经过一定时间后分配参与者对数据的责任。例如，假设一份新闻稿已发出并提交批准，然后等待一周而不进行审查。您可能希望系统执行的操作是识别该挥之不去的文档并引起相关方的注意。
根据我的经验（内容管理系统），并行执行路径并不常见，但仍然是经常出现的情况。它的想法是，给定的数据片段沿着两条不同的审查或处理路径发送，仅在稍后的某个时刻重新组合。此类问题需要有用的合并算法和同时表示数据相乘的能力。事后将其编织成一个简单的解决方案比看起来要棘手得多，特别是如果您想跟踪历史数据。
结论
如果您的系统不太可能改变，那么推出自己的系统可能是一个更简单的解决方案，特别是如果更改可能会破坏旧信息。但是，如果您怀疑自己需要这种类型的持久性，或者会遇到一些不常见但棘手的场景，那么工作流工具提供了更大的灵活性和保障，您不会因为数据和业务流程而陷入困境。改变。
I wrote a workflow engine, because my employer wanted to own the IP, modeled after jBPM. Now the reason you use such a tool, instead of creating your own finite state machine, is accommodating changes without altering persistence and supporting edge cases of workflow processes as I'll explain.
Accommodating Changes Without Altering Persistence
Your typical, or perhaps better to call it "naive", finite state machine implementation features a set of database tables tightly coupled to the data managed and the process it flows through. There might be a way to keep past versions and track who took what action during the process as well. Where this runs into problems changes to data and process structure. Then those tightly coupled tables need to be altered to reflect the new structure and may not be backwardly compatible with the old.
A workflow engine overcomes this challenge in two ways, by using serialization to represent the data and process, and abstracting integration points, in particular security. The serialization aspect means data and process can move together through the system. This allows data instances of the same type to follow completely different processes to the point the process can altered at runtime, by adding a new state for instance. And none of this requires changing the underlying storage.
Integration points are means of injecting algorithms into the process and ties to authentication stores (i.e. users who must take action). Injected algorithms might include determinations of whether or not a state is completed, whereas authentication stores example is LDAP.
Now the tradeoff is difficult search. For instance, because data is serialized, it's usually not possible to query historical information - other than retrieve the records, deserialize and analyze using code.
Edge Cases
The other aspect of a workflow tool is the experience embedded into its design and functionality that you will likely not consider rolling your own and may live to regret when you do need it. The two cases the come to my mind are timed tasks and parallel execution paths.
Timed tasks are assigning an actor responsibility for data after a certain duration has passed. For instance, say a press release is writ and submitted for approval, and then sits for a week without review. What you probably want your system to do is identify that lingering document and draw attention of the appropriate parties.
Parallel execution paths are uncommon in my experience (Content Management Systems), but are still a situation that arises often enough. It's the idea that a given piece of data is sent down two different paths of review or processing, only to be recombined at some later point. This type of problem requires having useful merging algorithms and the ability to represent the data multiply simultaneously. Weaving that into a homespun solution after the fact is much trickier than it may seem, especially if you want to keep track of historical data.
Conclusion
If your system is not likely to change, rolling your own may be an easier solution, particularly if changes can break old information. But if you suspect you have a need for that type of durability or will experience some of these uncommon but thorny scenarios, a workflow tool provides a lot more flexibility and insurance that you won't paint yourself into a corner as the data and business processes change.
也许问几个问题会有帮助。
流程会改变吗？
当新版本的流程出现时，旧版本的流程会继续存在吗？
是否应该测量流程（以及每个步骤）的运行时间？
是关于业务流程（编排多个资源的状态）还是资源生命周期（仅单个文档/资源的状态）？
...
抱歉，如果这不是一个答案。
Maybe asking a few questions could help.
Will the processes change ?
Will an older version of a process live on while newer version of the process come into existence ?
Should the running time of processes (and each step) be measured ?
Is it about business processes (orchestrating the state of multiple resources) or resource lifecycles (only the state of a single document/resource) ?
...
Sorry if it's not much of an answer.
我会仔细研究推动您努力的业务需求（即“业务案例”）。据我了解，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/
I'd take a closer look at the business need that drives your effort (i.e. "business case"). In my understanding BPM/workflow might have one or more of the following goals:
1. Automate actions
This is usually required to replace human with machine through automation of tasks, such as creating documents, archive information, notify users, etc.
2. Tracking of each processes
Companies need to establish tracking when there are a significant number of processes, and business users lose track of them as usually run them in office documents, emails. Every external request for status (e.g. from a client) turns into an investigation.
3. Establish control
For managers it's usually important to gain a high-level view of the process and study it statistically: see whether KPIs are kept to, any lags, exceptions, etc
4. Manage in-process document exchange and collaboration
BPMs often serve as a document exchange tool, as they often enable switch from email and verbal communication to a traceable exchange in a BPM
5. Automate data exchange between enterprise systems
This is a pure integration case and usually is demanded in the case when a number of actions are already performed with (or by) various systems, and there is a need to automate the information exchange among them.
Now, full featured ready-to-use BPMs are good for 2, 3 and sometimes 4.
jBPM and other workflow engines are good for 1 and 3, but with an important caveat - they require complex configuration/development.
SOA-based process orchestration engines (sometimes called BPM too!) are good for (5) and (3).
Please feel free to add to the list and argue!
I've posted this as my blog post and elaborated a bit more here: http://processmate.net/do-you-need-a-bpm-or-a-workflow/
最终，所有处理业务相关信息的业务系统都是 BPM 或工作流系统。任何企业的信息处理都可以用工作流或“业务流程”来描述，涉及角色和活动。
事实上，这些业务活动通常用Java、C#或其他编程语言来描述，这基本上只是自动化的结果，没有足够成熟的技术来用自动代理来规定和描述业务流程。
重点一直放在增长、上市时间等方面，并且在没有适当考虑长期维护和灵活性的情况下进行了计算机化。现在代码中 99% 的内容都不应该是这样。
相比之下，实时控制系统、视频游戏、高性能计算、预测、商业智能和数学分析都是不适合图形工作流程描述的问题的例子。这些都是应该由计算机来完成、由计算机专家来维护的事情。
业务流程应由业务运营专家规定、描述和阅读。随着实现这一点的技术（工作流程系统）变得更好，灵活性收益将得到越来越多的认可，并且随着世界经济不再强调“增长”而得到更广泛的接受。
Ultimately, all business systems that deal with processing of business related information are BPM or workflow systems. Any business's information processing can be described in terms of workflows or "business processes", involving roles and activities.
The fact that these business activities are often described in Java, C# or other programming languages is basically just the result of automation without mature enough technology for prescription and description of business processes with automatic agents.
The emphasis has been on growth, time to market, and so on, and computerisation was carried out without proper thought about long term maintenance and flexibility. 99% of what is in code now should not be.
In contrast, real time control systems, video games, high performance computing, forecasting, business intelligence and mathematical analysis are all examples of problems that do not lend themselves to graphical workflow description. These are things that should be done by computers and maintained by computer experts.
Business processes should be prescribed, described, and readable by business operations experts. The flexibility gains will become increasingly recognised as the technology that enables this (workflow systems) gets better, and more widely accepted as the world economy de-emphasises "growth".