BPM方案日趋符合Web 2.0精神

最近不少人在讨论BPM和Web 2.0的关系。有人认为，BPM是一个Web 2.0应用程序，因为它带来了流程中参与者之间的协作。而有人则强烈反对这一观点，理由是BPM具有结构性的特点，这与Web 2.0非结构性协作和自由分享信息的特质是冲突的。那么BPM究竟是不是一种Web 2.0解决方案呢？要回答这个问题，首先求证BPM是否符合Web 2.0的三个特征。

首先，BPM是不是RIA（富互联网应用程序）？这可以说是一个技术使用与发展的问题。RIA通常使用一些新技术开发，例如AJAX、Adobe Flex或者Microsoft SilverLight。尽管现在的BPM产品几乎没有使用这些新技术，但我预测，在接下来的2年内，大多数的厂商都会将他们的用户界面做得跟RIA一样。

这实际上不是BPM的问题，而是BPM厂商能以多快的速度采用新技术的问题。这一点可以说是满足了。

其次，BPM是否具有Mashup（内容聚合）能力？我相当认可，BPM是第一批具有Mashup能力的应用程序，这甚至都发生在Web 2.0流行之前。BPM客户端该算是一种典型的Mashup，它将各种来源的信息进行集中处理，这些来源包括数据库、Web服务、BPM服务器，以及ERP、CRM等其他企业级应用程序。当然，BPM应用程序之所以能够方便、灵活地创建Mashup，与所用的底层BPM软件能力密切相关。不过，关键在于BPM客户端是Mashup，它可供所有流程的参与者使用。

最后是协作方面是否符合Web 2.0精神。有两类BPM解决方案都不能算是Web 2.0：第一类，服务于以系统为中心流程或者直线型流程的BPM，在速度上是做过优化的，并且很少需要人工参与。从这一点上看，这些解决方案并不是协作，也不需要协作——它们是高度机械化的自动化产品线。另一类BPM解决方案，在20世纪90年代被称为“产品工作流”，它们需要人工参与，但是其目的在于大量的固定流程处理，或者起到类似呼叫中心的作用。因此，这类应用程序也不怎么需要协作，其重点在于结构化、一致性和速度。但是此外，还有大量的业务流程需要人工参与，特别是知识性工作者。在BPM或者工作流概念发展的早期，这些流程被划分为管理或特殊类型。“特别”一词表示它与之前那两种流程不一样，它需要协作，但是当时的技术还无法提供更多的协作机会。这些以人为中心的流程正是BPM真正成为Web 2.0应用程序的潜力。

因为人的工作是相当复杂的，其交互过程通常无法通过提前编程来自动实现，比如：商议——知识工作者在决定一件事之前，通常想要和其他人进行讨论；通知——知识工作者想让别人知道他们下决定的事情及其原因；分配——知识工作者通常想将一些任务分配给别人；分享与同化——知识工作者想要分享他们所下的结论或得到的信息，这样的分享和同化能够促进企业进步。

所有这些都是很特别的，或者说是需要协作的。很多BPM的客户端都提供这类能力。但是，如果BPM想要真正满足知识工作者的需求，那么BPM客户端就不得不提供所有能力。Web 2.0应用程序，如博客、Wiki、即时通信、论坛、Internet文档共享等的进一步流行，意味着BPM解决方案需要提升其技术力量以便为BPM用户提供类似的能力。所以说，BPM正在演化为一个丰富的平台，在需要时既能加强结构性和一致性，又能支持实时和特别的协作。第三点也满足了。

因此，我的结论是，尽管现在的BPM解决方案可能还算不上真正意义上的Web 2.0应用程序，但所有以人为中心的BPM解决方案迟早都要成为Web 2.0应用程序

不过值得注意，由于Web 2.0应用程序的核心目的是让人们能够一起工作，所以以人为中心的BPM解决方案并不是支持协作、Mashup和RIA技术的理想实例。只是那些灵活地将BPM作为Web 2.0解决方案的厂商将具有显著的竞争优势，他们将更好地改变他们的终端用户，并创造持久的价值。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。