不同类型的BPM软件和客户

作者：Rashid N. Khan

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 每当我到世界各地拜访客户与潜在客户时，都会见到两种截然不同的所谓 BPM 软件。如果光从这两种软件的厂商宣传资料来看，一般人可能会以为两者其实大同小异，只不过其中一种的价钱远高于另外一种而已。 销售时，一种有完整的专业服务，另外一种，则宣称用户只要自行DIY 即可。在我看来，很多时候，这两种其实争夺的是同一个市场。除了上述的差异之外，其相似性与相同的名称，的确让客户感到非常困惑。客户无法理解，为何类似的软件竟然在价格、功能、以及产品交付方式上有这么大的差异。由于两种软件都有其市场，所以会让人认为这两类软件的客户型态应该有很大的差异，而事实上也的确如此。 不同类型的客户 第一类型的客户是“应用软件导向”的客户。其目标是要以最低的价格取得功能最多的应用软件。 应用软件导向的客户基本上大多是程序开发人员，这些人以各类型应用软件 (包括 BPM) 为重心，其余都只是次要，而其主要任务就是让应用软件功能更好。这类客户，不论是开发人员或是独立开发厂商，都喜欢弹性、轻巧而且能轻松整合至其应用软件的功能。这些客户不喜欢高价位、重量型的应用软件，因为这类软件不容易维护与支持。此外，开发人员喜欢自行设计程序，不需要实施顾问的协助。当应用软件导向的客户在寻找 BPM 解决方案时，他们真正需要的是一套能够在现有企业应用软件上附加工作流程功能的软件，或是另外建立一个客制化项目。 为了突显其特性，我们还是称这类软件为“工作流程工具”，当然，厂商为了赶搭 BPM 潮流，比较喜欢称之为 BPM 软件。工作流程工具通常只提供工作流程的基本功能，而其它功能则由客户自行开发程序来补足。许多企业应用软件，例如：ERP、CRM、EDMS、资产管理等等，都需要一些工作流程功能来加强其核心功能。这些应用软件的开发人员，能使用工作流程工具来提供工作流程的功能，而不必再自行闭门造车。此外，许多客制化项目也需要一些基本的工作流程能力。对于这些客制化应用软件的开发人员来说，现成的工作流程工具是很方便，因为可直接与其客制化应用软件整合。 要满足这类应用软件导向的客户需求，工作流程工具必须便宜而轻巧。由于工作流程工具已经整合至应用软件内， 应用软件的终端使用者永远也看不到工作流程工具，或是其任何组件。 最后一点，应用软件导向的开发人员，其视野也仅限于应用软件本身。虽然应用软件可能内建了某些流程，但这些应用软件的目标，并不在于让其应用领域之外的流程大量自动化。 第二类型的客户是“流程导向”的客户。对于流程导向的客户来说，业务流程才是重心，而应用软件的目的在于让流程更顺畅、更完整。由于流程是业务的基础，因此流程的效率就无比重要。这类型的客户基本上是业务人员。其寻找 BPM 解决方案的目标，是要让公司能够管理业务流程的整个生命周期。因此，BPM 解决方案必须完整，而且要内建许多功能，包括：模型化、协同设计、整合、管理、用户界面、角色管理、监控、评估等等，以及一个独立的规则引擎。 流程导向的客户关心的是业务问题，而不是 IT 或程序开发问题。其寻找的是一套业务解决方案，而不是客制化开发方案。事实上，由于企业灵活性非常重要，流程导向的客户希望客制化的程序开发越少越好，这样才不会太难维护与更新。流程导向的客户通常面对的是与业务相关的大量流程。因此，需要的是完整的解决方案，而也通常喜欢藉由专业服务的协助来加快实施速度。 流程导向的客户比较不关心价格问题，因为他们觉得关键业务流程自动化所带来的投资报酬更为重要。此外，流程导向的客户喜欢独立的 BPM 平台，以便需要用到各种应用软件的流程都能自动化。这类客户需要的是所谓真正的“BPM 解决方案”或是“BPM 软件包”。 除了前两种客户之外，还有第三种客户。这类客户想要 BPM 软件包的功能，但却只希望付出工作流程工具的价格与努力。他们的重心正好介于应用软件导向与流程导向之间。我在中东遇到一位这样的客户。他是一个大型政府机构的信息官，他希望越多流程自动化越好。他想要一套完整的解决方案、阿拉伯文界面，以及当地的阿拉伯语支持服务。这样的需求对于企业解决方案来说，也相当合理。但最终还是回归到价格问题。他问我：“为何你们的 BPM 软件不采用 Intuit QuickBooks 的定价模式？”我当时实在不忍心告诉他，我们的价格不是 20 套 Intuit QuickBooks 软件可以比得上的。面对这类不知道该以应用软件或流程为重心的客户，唯一的方法就是教育他们。 不同类型的BPM软件 即使客户很清楚自已的重心是什么 (不论是应用软件导向或流程导向)，客户还是要面对困难的抉择。其实，厂商也分成三类。首先是纯粹的 BPM 厂商，提供完整、独立的 BPM 解决方案。其次是工作流程工具厂商，提供为其它软件附加工作流程能力的软件。最后则是在自家软件内建工作流程功能的应用软件厂商。由于 BPM 最近炒得火热，因此不管是哪一类厂商都不断强烈推销自己所谓的 BPM 方案。例如，每一家 EDMS 与 ECM 厂商都宣称拥有 BPM 或工作流程解决方案，其中又以 Filenet 为分析师所评选的龙头。像这样的情况，实在让客户一头雾水，完全不知什么才是 BPM、什么不是 BPM。 我个人认为答案其实很简单。如果某家厂商的产品能将 BPM 功能独立定价、销售并提供支持，那就应该可算是真正的 BPM 解决方案。若其 BPM 功能只能搭配某个应用软件销售、实施与支持，那就不算是真正的 BPM 应用软件。 当然，客户真正关心的，是这三种方式到底哪一种才能真正为客户提供长期的投资效益。客户应该投资在嵌入特定应用软件的工作流程工具，还是应该投资在独立的 BPM 解决方案，以便让各种核心业务流程都能自动化？客户是否应该依赖其企业应用软件厂商的工作流程功能？当然，身为 BPM 市场领导厂商的执行长，我个人的观点可能会有点偏颇。不过，我愿意在此与各位分享，为何我认为独立的 BPM 解决方案才是未来的潮流，也是我们公司的前途所在。我的理由有三： 第一，嵌入式工作流程功能不但难以扩充，也不易管理。如果一个公司使用了好几套应用软件或客制化应用软件，而每一套都有自己的嵌入式工作流程功能，那该公司就必须同时执行工作流程方案。除非这些应用软件的工作流程功能都很初级 (当然，如果这样就没什么用处)，否则，这些不同的工作流程系统将很难管理。光是管理一套工作流程系统就已经很难了，更何况有好几套要管理。而每一套都有自己的设计工具、使用者界面、规则储存库、管理方式、建模工具等等必须学习。一旦有系统变多，就会变得既不实际、又不经济。反之，BPM 软件包是一套独立的流程动化平台，能搭配各种企业应用软件。一个公司只要熟悉一套产品，就能将所有的业务流程自动化，不论对何种企业应用软件或人员皆然。 第二，随着面向服务架构 (Services Oriented Architecture，SOA) 的出现与逐渐普及，BPM 解决方案比起工作流程工具更有发展性。虽然每一家企业应用软件厂商都曾经尝试将 BPM 能力整合至其产品，但我实在无法想出有哪一家在这方面算是成功的。反倒是这些企业应用软体厂商开始了解，其优势在于服务其专长领域，并透过 SOA 架构将这些服务开放出来。如此，就能让完整的 BPM 解决方案顺利执行业务流程的生命周期管理。 最后，工作流程工具原本就定位在低价市场，而随着大型厂商的进入，这些工具的价格将越来越低。而且，最近还听说Microsoft 也有意在其操作系统中，免费提供更多工作流程功能。因此，如果开发人员想在其应用软件中运用简单的工作流程功能，他们将使用 Visual Studio 所提供的工具，而不会另外购买工作流程工具软件。所以，这些工作流程工具厂商的业务将无以为继。 (end)

文章内容仅供参考 (投稿) (5/18/2006)