Architecture 在最纯粹的体系结构中，BPM的目的是什么？

我正在为一家希望引入BPM（业务流程管理）工具的中型公司构建一个体系结构。我知道这会很有帮助，并希望引入它，但在体系结构中找到合适的位置时却举步维艰

---

我想知道何时以及如何使用BPM工具，如何区分业务流程和应用程序工作流？

为什么要引入BPM工具？这是流行语吗？如果您正在努力在体系结构中找到一席之地，那么我怀疑该工具不会带来巨大的成功（至少在您目前的理解中不会）

应用程序工作流工具通常关注特定流程的建模，并为半技术流程设计人员提供显示步骤和交互的能力，同时允许程序员使用实现这些部分的代码充实框架。就我个人而言，我发现培训半技术流程负责人的开销可以抵消有效沟通和周转方面的承诺收益，但在大型组织中，它可以确保流程“所有者”拥有购买计划所需的控制幻觉。我说的是幻觉，因为在一天结束时，是it人员重新生成实现流程的代码，并且经常由于技术方面的问题而恢复建议的更改（此类工具通常使更改更容易建议而不是实现）

有些业务流程管理工具只不过是具有更高价格标签的应用程序工作流工具。有些人从更高的角度出发，将手动流程和其他非IT流程合并到体系结构中（尽管很明显，这些步骤实际上只不过是退出和重新进入IT流程的存根或网关守卫）。我不知道你怎么称呼一家中型公司，但在一家拥有160名员工的航空航天工程公司，我们发现了BPM工具，我们对其进行了过度评估

---

可悲的是，这是一个只能给出有针对性的答案的问题，即使有所有的事实（不同的系统分析师会给出不同的观点）。我希望快速概述至少会有所帮助。请注意销售炒作：我发现这些工具只有在具有特定流程的特定组织中才有价值，而在其他组织中则是一个障碍。

如果一家公司拥有处理大多数情况的流程，那么是时候引入BPM工具来检查当前流程了。从某种意义上说，这让我想起了前一段时间提出的“”问题。

我发现，在已经建立了一些正式业务流程的公司中引入BPM更为有用和有益-

应用程序工作流更倾向于仅自动化用户交互（文档、授权、签名等）。但在用户/系统交互方面，BPM非常方便

这不仅是最终用户可以看到和理解应用程序的真实流程（因为他们不会移动手指进行任何更改），而且可以避免重复任务或系统之间的复杂交互

当然，您可以在从0开始的应用程序中对其进行编码，但当业务流程实际可作为服务用于其他流程时，这种编码就没有意义或无法扩展。BPM套件可以让您在几小时内完成这项工作（实际上只需点击几下，但不要告诉客户）

因此，回到您的问题，根据BPM工具的容量，如果已经有一个业务流程，并且该流程需要不同领域和不同系统的用户之间的交互，那么值得引入BPM

如果交互更加“人性化”（文档、审批等），应用程序工作流也可以（如果已经有了该工具，则将BPM用作工作流）

如果交互对象是同一地区的amog用户，或者数据相对容易使用，并且没有人关心业务流程（即轮到谁来买苏打水），那么您可以从头开始创建web/桌面应用程序

何时以及如何使用BPM工具“

奥斯卡·雷耶斯（Oscar Reyes）在其帖子的第一句话中直接指出了这一点。你需要过程愿景

BPM工具（严格来说）是一种用来管理业务流程的工具。戈代克在上面帖子中的警告也是正确的。并非所有BPM工具都是平等创建的。事实上，我挑战你不能让任何人同意BPM实际上是什么。该术语已被包括软件供应商、顾问、分析师和新闻机构（仅举几例）在内的各方篡夺

但要直接回答这个问题，当企业希望自动化部分或全部业务流程时，BPM工具是合适的。注意。。。所有业务都有业务流程。只是并不是所有的业务都由他们记录或管理

“如何”实现BPM工具取决于上下文，因为存在不同的“类型”BPM解决方案。从广义上讲（这是争论的温床），您可以将BPM分解为事务性流程和以人为中心的流程。事务性BPM的目标是自动化系统级流程——主要是集成。您将在这里看到很多关于SOA的内容。以人为中心的BPM（显然）针对的是涉及人机交互的流程—主要是文档或结构化/非结构化数据管理

“区分业务流程和应用程序工作流”

见上文。这是一个非常笼统的讨论。为了充分识别BPM项目，需要提前做很多工作

要问的第一个问题是，“我们公司目前是通过流程管理其业务，还是希望如此？”。这个问题的答案应该来自最高层。我的经验是，如果没有执行层对以流程为中心的业务管理的承诺，BPM项目很可能会失败