怎样构建BPM生态系统

据《经济学家》杂志（The Economist）的一项调查显示，来自全球1000多家公司的CEO和CIO一致认为，业务流程方面的创新能够比某些产品或者服务方面的创新带来更显著的竞争优势。所以，弗雷斯
特研究公司（Forrester Research）预测：到2009年，业务流程管理（Business Process Management，BPM）套件市场的产值将达到27亿美元，也就不足为奇了。

我们所说的业务实际上主要由一批流程组成，比如采购、制造、销售和开票等流程。随着公司变得更庞大、更复杂、更全球化，有关管理业务流程会给盈利能力带来影响。

除了日常管理外，BPM还有助于让高层管理人员全面了解公司业务运作状况、解读战略性动力。 有效的BPM加上动态改动业务流程的能力，这是许多公司孜孜以求的目标，原因在于它可以提供业务敏捷性。这里的敏捷性意味着能够比竞争对手更迅速地灵活应对市场形势。

BPM不需要编程即可实现流程的自动化，它基于结合人员任务、应用集成和业务规则的图形化设计。

本文首先概述让BPM系统能够不断发展所依赖的技术进步，然后介绍将来业务效率方面的提高为何会来自有助于改进底层业务流程的模拟和优化工具。

IT和业务目标的协调同步

所以，要是你没有做好以下几个方面：最佳数量折扣、面对货币波动的价格响应以及最佳产品捆绑，进行改进（比如缩短完成整个销售周期的时间）又有什么意义？

任何一项技术的第一条规则就是，有效运营运用自动化后，效率会大大提高；第二条规则就是，低效运营运用自动化后，效率还会大大降低。

许多公司不知道整个端到端流程是什么样，也不知道为什么工作是这样完成的。大多数情况下，如今现有的流程是很早以前落实到位的，那时万维网、虚拟团队、"黑莓"和外包等还没有开始影响工作场所。建模让公司在匆忙进行设计之前，有机会重新思考、简化事情。

理想情况下，公司应当以业务目标为主。CEO应当能够与新的合作伙伴达成协议，或者换掉供应链中表现不佳的那个部分，IT不会受到制约。董事会应当能够批准战略性收购，而不用担心系统的集成费用高于收购交易带来的财务效益。公司的首席运营官应当能够下令：某个部门将实行财务报告，不必担心IT引起的延误。

SOA、BPM和ESB的关系

有了面向服务的架构（Service-oriented Architecture，SOA），我们离实现这种远景迈出了一大步。

SOA是一种企业级的IT架构方式，它把IT资源作为与业务协调的服务来提供，从而满足业务要求。SOA支持面向服务（service orientation），这种方式可以通过相联服务的形式整合公司。面向服务让应用程序能够调用对方的行为作为服务；也就是说，这种可以重复的业务任务是自我描述、可以发现的，可满足服务质量的特定要求，还可以通过治理来加以管理。

组件是可以得到执行来提供功能的一段代码；服务是实际运行的一个组件，常常在各自的进程内运行，进程与调用服务的应用程序分开来存放。

的确，应用程序本身可以分成多个部分，每个部分都在各自的进程内运行，通过服务调用对方。
这就是组合式应用，这组相关、集成的服务支持在SOA上构建的业务流程。

不过，BPM和SOA的驱动因素大不相同：BPM是业务驱动型计划，而SOA是IT驱动型计划。

一个相关的概念是企业服务总线（Enterprise Service Bus，ESB），它让在不同平台上运行、用不同编程语言编写、使用不同编程模型的软件应用可以彼此联系，不需要费时又费钱的软件重组。

ESB能够在传输期间对消息进行路由和转换处理。它是基于标准的，这有助于方便集成不同厂商的产品，并且避免SOA那样被厂商锁定（vendor lock-in）的现象。

ESB执行的主要任务之一就是，把服务使用者（调用服务的一方）与服务提供者（部署服务的一方）联系起来。ESB让使用者能够调用服务，并且把这种调用与执行该服务的提供者对应起来。这样一来，使用者和提供者不需要了解对方，它们只要连接到ESB即可。

SOA和ESB不是什么新概念，只不过用于封装及集成应用功能的不断发展的方法的最新版本。

ESB较之传统解决方案的真正优点在于，它能够跨业务部门的界限很好地扩展。如今的集成应用程序需要在包括本企业、业务合作伙伴及客户的扩展型企业顺畅运行。

这意味着能够跨下面这些系统利用业务信息和实用程序：

使用不同数据模型的系统
使用不同技术实施的系统
往往使用不同安全政策/程序的系统
通常隐藏在企业或者业务部门防火墙后面的系统

即便是在一家公司里面，如果不同的业务部门在解决方案方面作出不同选择，同样要考虑这样因素。在这样一种环境下，集中式的中心辐射型（hub and spoke）架构即便采用集群也根本不具有良好的扩展性。如果我们试图部署到中心辐射型系统组成的分布式集群，路由和业务规则的集中管理这一传统强项也会变成弱项。

有了ESB，企业就能够从少量充当聚合点的初始容器无缝扩展到由局部化集成点组成的多层网络。

但是新平台迅速成为自己成功的牺牲品，原因在于一旦新平台向外扩展，大多数企业变得完全依赖它们，这样几乎不可能安排时间让系统停运，以便维护或者改进。任何停运时间都会马上影响销售或者增加成本。

能够管理实行变化的成本，这是任何解决方案的关键；而ESB在这方面同样很出色。使用轻便的分布式容器，这意味着新服务随时可以从中央服务器"动态"部署到远程节点上，不会带来任何停运时间。

这还意味着，使用中央消息总线可确保服务下线后，与活动业务流程有关的消息被留在队列上，直到重新开始处理。

比较旧的解决方案，比如中心辐射型引擎，也许能在业务部门内部扮演集成解决方案的角色；而ESB却是把横跨企业、需要利用各组件的诸多业务流程联系起来的必然解决方案，它采用了一种商定、安全的方式，往往有着不同的架构、用不同技术实施。 标准化有望让包括业务流程执行语言（BPEL）引擎在内的异构组件可以连接到不同厂商的ESB。ESB改变了集成的意义，能够迅速引入规范的SOA机制，有望带来技术和经济方面的显著效益。

模拟和优化构建BPM生态系统

你的BPM流程应当包括了解风险这个环节，以便作出的决策不但最有希望成功，而且大有益处。因而，如今的业务绩效管理需要预测分析应用软件，让公司能够作出尽量提高成功概率、又能缓解风险、了解不确定因素的决策。

使用建模和模拟技术，让公司能够深入了解业务规划的各种可能结果、量化这些结果的概率和影响，并且作出风险和回报经过权衡的决策。结果就是得到更有价值的决策。

往往会在实践中需要模拟和优化，这是由于实际环境的系统大多过于复杂，无法通过反复试验来进行测试。如今，越来越多的业务流程管理软件厂商提供模拟功能，以便扩展建模功能、提高分析水平。

模拟旨在充当这种手段：通过设计假设场景，评估模型环境下流程变化和新流程带来的影响。进一步的模拟能够在"真实"环境下作出实际决策之前，分析及检验决策。因为模拟接近现实，它还允许把不确定因素和可变因素加入到流程绩效的预测当中。

一旦表示某个系统或者流程的模拟模型开发完毕，你可能希望根据某个绩效指标，在一组可行的选择中找到最佳配置。

对简单的流程而言，也许只要通过反复试验或者列举所有可能的配置就能找到最佳配置。如果流程很复杂，配置又依赖许多战略性选择，那么采用反复试验方法所取得的成功非常有限。这种情况下，你可能需要利用优化工具来帮助寻找最佳配置。

模拟模型的优化针对这样的情形：分析师想看到哪几组模型规范（如输入参数以及/或者结构性假定）可能会得到最佳绩效。

比如在制造领域，你可能希望设计一种优化模型，力求通过控制员工和机器的数量，从而最大程度地缩短周期时间，同时限制资本投资和运营成本，另外最大程度地提高所有资源的利用率。 针对这种优化问题的模型将包括与人力和机器有关的决策可变因素，以及基于周期时间（通过对生产设施进行模拟获得）的绩效衡量指标。

如果提议改变业务流程以便改进绩效，就可以人为地模拟及优化预测的改进措施。这时就可以分析及量化对最终目标进行改动的敏感性，从而降低实际实施的风险。

风险可能需要添加、移除及修改流程、处理时间、所需资源、调度表、流程内部的工作率、技能水平和预算。

绩效目标可能包括吞吐量、成本、库存、周期时间、资源及资本利用率、启动时间、现金流量和废料。
在业务流程管理和改进这个环境下，可以认为模拟是了解及传达进行变化引起的不确定因素的一种方式；而模拟提供了管理这种不确定因素的一种方式。

文章来源：计世网

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友