CIO须知 企业如何更好地实施BPM.docx

《CIO须知 企业如何更好地实施BPM.docx》由会员分享，可在线阅读，更多相关《CIO须知 企业如何更好地实施BPM.docx（5页珍藏版）》请在三一办公上搜索。

1、对于BPM一定是包括了自动化的业务流和人工工作流引擎两部分的内容，同时为了更好的处理在业务流程建模中的业务规则往往还需要有单独的规则引擎子系统或模块。一个完整的BPM系统往往包括了流程建模和设计，数据建模，界面设计，基础数据和权限设计，流程执行和监控，流程仿真，流程绩效评估多个方面的内容。由于BPM主要完成的流程组合和编排是整个SOA架构的上层内容，因此一个完整的BPM系统设计和构建本身就是组件化和SOA服务化思想进行的。对于BPM软件的实施,我们从通过BPM系统全新构建业务应用和基于BPM系统进行流程整合两个场景来讨论BPM软件实施过程中的异同。全新构建业务应用一个完整的BPM系统本身就可以

2、理解为一个既开放，又相当封闭的SOA架构平台。开放主要是说该系统能够很好的集成和复用已有的SOA共享服务能力，封闭则是说BPM软件可以从设计建模，到测试，到部署上线端到端的完成一个业务应用的构建。可以看到全新构建业务应用相当来说反而容易，这个时候没有和企业内部遗留IT系统集成和协同的麻烦。在这种情况下4A基础数据完全可以以BPM系统为最初的源头，很多跨流程的业务单据信息也直接在BPM系统中进行建模和设计。对于界面和展现即完全利用BPM软件本身提供的一整套快捷开发工具进行，本身也不存在单独构建一个IT系统时候还需进行基础技术框架构建的问题。但是在这种场景下构建BPM,仍然存在一些问题无法解决，具

3、体包括如下：首先对于业务系统，即以工单和流程驱动的系统，还有就是以核心共享数据为基础驱动的系统。前者类似0A,ITIL类业务系统;后者类似资产，资源管理等系统。注意对于后者我们期望的一个完整的全局数据模型，这个数据模型往往会应用到多个业务流程中，而不是简单的工单。在这种情况下采用BPM软件是很实现完整的业务功能的。因此BPM更多的还是适用于流程驱动的业务应用。其次，通过BPM软件构建出来的系统往往是跨越了多个业务部门的一个端到端业务流程管理，在这种情况可能并不会再具备原有的项目系统，采购系统，物流系统等严格的业务系统划分，而是这些业务都完整的实现在了一个短到短的业务流程上。那么这个BPM系统的

4、业务管理和认责部门是谁？这个时候我们往往找不到一个主导的责任部门，那么这个BPM系统后续如何推广实施？靠IT部门的力量往往是很难真正落地的。这也是我们常说的BPM系统的推广难点已经不在技术上，而在于业务上。最后即使是流程驱动的业务系统，如果期望通过BPM软件提供的功能完全通过可配置和可视化设计的方式完全实现出来还是存在困难，即使有相关的规则引擎，但是仍然很难做到完全可配置的快速开发。这就自然涉及到了即使全新构建BPM系统，在BPM的底层仍然需要有实现核心能力和业务组件和技术组件，这些组件重点变成提供领域服务能力，而不是前台界面展现和协同。这个点必须要意识到，否则容易理解为BPM是万能的，啥流程

5、都可以很简单的建模和配置设计出来，那就大大的犯错了。遗留系统通过BPM来整合场景这个相当于前者来说往往更加困难，困难点就再在于期望通过BPM来解决原有的端到端流程中的协同断点，同时又需要最大化的保留历史遗留系统的IT资产。大家看SOA架构好像觉得这个问题已经很简单的解决了，即历史的遗留系统都会识别为组件，组件应该将遗留系统的业务和数据服务能力提供出来，然后通过BPM层对服务进行组合，服务进行编排，形成一个端到端的完整流程。但是这个本质问题还是BPM和遗留业务的关系问题。如果基于BPM是来实现一个完整的端到端流程，这个端到端流程在构建过程中确实可以调用遗留系统的服务能力，但是这个端到端流程是否涉

6、及到单据和数据的产生，是否涉及到人工流程的处理？如果流程会产生单据和数据信息，那么根据原有IT架构这些业务单据仍然应该产生和存储在遗留IT系统而不是BPM系统，对于人工流程的处理同样的道理，仍然应该是在原有业务系统中统一处理而不是在BPM系统。这个一分析清楚我们就容易理解，遗留系统场景下BPM进行整合，不能凭空的再找出一个BPM系统出来，BPM的重点是将原有业务系统中的单据和流程整合和集成起来，而不是替代原有系统的能力。最终集成的效果可以通过POrtIet形式展示到门户，而不是新增加一个业务系统。把这个理解清楚了，就清楚在这种场景下BPM实施的重点应该是由业务系统提供完整的领域服务层能力出来，

7、而BPM重点是来统一实现界面层和展现,实现各个业务系统中服务能力的组合。即使再这种情况下都还需要考虑如何解决门户层应用功能和原有IT系统间功能的统一工作台展现，这个问题没有解决好就会变成业务部门人员需要两处处理业务，现在在实施层面是很难推广的。实施BPM有个很重要的内容，就是4A系统或者叫模块的实施，已经原有的工作流引擎是否已经成功实施。如果这些没有实施，那么BPM将作为为4A和工作流的基础支撑，如果已经实施那么就存在如何同步原有的4A数据，是弃用原有各个业务系统不统一的流程引擎还是保留资产进行整合的问题。对原有的IT资产保留的越多，你会看到BPM本身在实施过程中能够用到的能力越是减少和退化。

8、对于一个已经相当成熟的内部IT来说，BPM还存在哪些价值和意义。第一个方面是通过BPM来实现端到端流程执行的监控和流程绩效评估，注意这本身在完整的应用架构里面就是在执行层上面的事情，这样可以减少和已有的业务系统之间的功能性冲突。第二是对于企业内部的很多职能管理部门，如审计部门，风控部门，流程管理部门等，这些部门本身不承载核心业务价值链上的单据产生和业务，而重点是基于已有业务系统能力进行的IT管控和治理，因此对于这些部门新建设的业务系统是最适合通过BPM工具来完成的。对于BPM本身在进行流程建模设计的时候，也要注意到最好采用子流程的模式进行分层建模和设计，即对于BPM流程的顶层重点是自动化的端到

9、端业务流，而对于下层才是人工审批流流程，否则一个完整的端到端BPM流程将很难进行后续的执行监控。当前很多企业就IT成熟度来说都没有到能够理解和实施BPM的程度,这也是为何很多企业的BPM实施仅仅变成了一个企业内部的统一工作流引擎平台实施的原因。个人认为对于一个BPM项目的成功实施，最重要的就是分析和建模方法的转变，如果仍然是按照传统的方法已经将业务分解到多个业务系统，那么面对的又将是遗留系统流程整合问题，而不是直接通过BPM+S0A方式来构建业务系统的问题。流程驱动IT是分析建模中的一个重要点，从流程开始自顶向下分析和分解，划分组件和识别服务;在从组件开始自底向上进行服务组合和编排，形成应用或

10、流程。这是一个完整的闭环路线，没有前者我们就很难真正的保证我们最终划分的组件，识别的服务能够真正应用到后续的服务组合和编排上面。不应该太早的进入到业务系统的概念，对于SOA整个咨询和建模方法论里面的，我们是弱化业务系统的概念，而是进一步强化了业务组件和技术组件的概念。这样做的目的主要是在SOA参考架构里面原有的业务系统已经变成一个弱边界，业务系统仅仅是多个组件的灵活组合或组装;其次当我们以业务系统出发进行考虑的时候，我们思维里面仍然是纵向架构模式，但是当我们以组件，服务和流程角度来考虑的时候，思维里面是一种横向分层架构模式。对于横向架构模式本身重要的目的就是要打破传统业务系统纵向的强划分。上面

11、谈的是BPM实施中相当关键的一点，把这点想清楚了就清楚了BPM流程建模的真正意义。在流程建模过程中我们是按照流程驱动的思路在分解流程，在规划流程应该涉及到的流程环节和活动节点，在设计每个流程节点应该业务自动化和人工化处理的事情，在考虑相关的流程节点是否应该有前台的展现和交互界面，表单所涉及到的数据对象结构;这块想通了我们才会进一步考虑这些需要的数据或业务规则逻辑处理能力究竟应该由下层的哪些业务组件或技术组件来提供这些服务。上面这句话如何理解？即就业务组件或技术组件本身来说还是按业务域，数据或技术域分开的，底层是组件化和服务化的，但是这些组件本身更偏服务能力提供，这些组件并不关系前端对应了什么流

12、程，应该有什么样的人机界面交互，这些组件的职责相当简单，就是提供业务或技术服务能力而已。但是在组件或服务的上层，我们最终涉及完成的前端或业务流程流转所需要的界面却是不分业务组件或系统的，其本身就是流程化和一体化的，这些前端界面，交互和展现不属于任何一个业务系统，而应该属于BPM系统。这就是一个理想化的BPM构建的方法和思路，把这个思路想明白后做过传统IT系统开发的就比较容易理解为啥BPM系统实施如此困难，为何BPM系统实施看到的很多都是单纯的HWF人工工作流引擎的实施。这个的本质就是分析和建模思路没有转变，没有从传统围绕业务系统为核心转换为横向的围绕组件和服务为中心来思考。BPM构建和实施层面

13、当前各个国际大厂商的BPM工具和产品套件已经相当成熟，但是在这里要说明的是BPM软件产品虽然可以灵活的通过配置和可视化建模设计和方式来构建业务系统前端流程，但是其配置的繁琐和复杂程度往往超过了直接写代码的模式。也就是说很多时候可配置的方法虽然开似很美好，能够灵活的应对业务的变化，但是很多时候往往开发配置效率是降低的，同时对于BPM本身新设计完成的流程仍然涉及到需重新发布的过程，也远远无法达到我们期望的零部署模式。一个BPM建模和执行工具平台，更多的是从服务层开始流程整合，而不是从遗留系统的界面层。如果己经有成熟的业务系统和前端功能界面，那么实际问题仅仅是两个系统的两个功能间的业务或数据交互问题

14、，这类问题是不需要用BPM工具来解决的，直接用到ESB服务总线这层就足够了。对于BPM平台一定要注意到其擅长的并不是单个业务系统内部的功能构建，如果一个业务系统本身不涉及到外部交互，仅仅涉及到内部功能或数据流转，我们其实强烈不推荐采用BPM产品和建模方法，能够有人工工作流引擎就足够了。一个稍微复杂点的业务如果全部用BPM可视化建模和配置来实现出来，超过几十个节点是常事。这种BPM建模文件文件维护的难度反而不如逻辑清晰的源代码。不要把BPM产品理解为快速开发平台，虽然很多BPM产品想朝这个方向走，但是确实不是BPM擅长的事情。真正BPM产品最擅长的还是在跨系统的业务流程场景出现的时候，这种业务场

15、景显然放在任何一个已有的业务系统都不合适，但是这种端到端流程本身在业务上又需要统一管理和管控。在这种场景下是最需要BPM的能力，即前端交互和流程流转统一规划和设计，原有的业务系统仅仅为上层提供数据和业务服务能力。大家可以考虑下，如何我们要构建一个企业电商的客户自服务平台，这个自服务平台需要能够方便客户实现对从订单到交互的全流程跟踪和管理。这种平台往往本身并不产生大量的基础数据和存储逻辑，而是需要大量的调用或系统企业内部已有的CRM系统，ERP系统，PDM系统，MDM系统的能力。对于这些遗留系统能够提供的能力根据客户需求和流程的需要进行组合和编排。同时基于这些能力，重新设计端到端的前端界面交互和

16、流程流转，这就是个BPM相当理想的实施环境。从这个层面来说企业内部常见的风险管控系统，合同端到端跟踪系统，财务共享服务平台等都是比较适合BPM的应用场景。企业如何提升BPM实施效果大多数主要的BPM产品都能满足特定的软件套件产品选择或者小规模试验项目的条件要求，Clo必须扩展自己一定的精力放到某些工作上来，包括实际环境可升级测试、业务用户的操作难题，以及仔细评估类似的客户执行情况等等。很多供应商供能够满足功能性的产品方案清单的要求，现在CIO的工作目的就在于确保系统能和组织寻求运营创新方法的初衷和目标很好地结合起来。首先处理好集成问题应该考量速度和创新两个因素，然后再对BPM进行集成。要当心这

17、样一些BPMS占据上风-它要求从一个模块输出流程确认信息，然后进入另一个模块(整个过程会在在流程定义、模拟、执行和报告功能模块之间进行转换)。这种“救火队传递水桶长龙”的办法增加开发时间并且压抑了流程创新。根据AniCo的Kirkham的观点，每一个BPM解决方案都必须经过多次重复检测，从而确定正确的流程，以及根据业务需求进行不断的改动。这要求流程模型和对流程的实际执行与管理之间紫密结合起来。和BPMS软作包一样重要的就是这个平台如何才能很好地将其他业务应用引入新的流程。辛辛那提Bell公司借助BluespringSoftware公司的BPMS产品将微软OffiCe应用软件整合进“报价到现金”

18、(QUOtetOCaSh)工作流程中。通过取消销售和财务部门之间就销售和客户订货价格有关的手动操作，新流程降低了65%的交易周期以及75%的资金循环和人力参与时间。在部分新流程当中，财务分析师通过电子邮件收到事先处理过的电子计算表格。进行必要的分析，然后把这些电子计算表格用电子邮件返回，让它能够继续进入流程的下一个步骤。BlUeSPringSoftWare为这一流程提供协调编排工作，并且提供财务数据和公司其他系统之间必要的连接。“这样做的好处在于你没有改变人们工作的方式，你只是取消了行政管理任务，并且让这些行政管理人员把注意力集中到增值工作上来，ChiPBUrke说，他是辛辛那提BeIl公司负

19、责IT部门的级副总裁。协调好BPM和SOA的关系执行BPMS的一个良好的开端就是“开发出一个简单而灵活的集成架构，特别是如果BPM应用被用作一个监控和协调层，置于现有处理应用的顶部的时候，DennisKoreVitSki说，他是T-MobiIe负责供应链系统的前总监。如果一个面向服务的架构或者中间件层已经存在，T-Mobile的BPM平台还能够通过把现有服务快速协调进一个新业务流程的办法来平衡其投资回报。举个例子，T-Mobile实施了LOmbardiSoftware的TeamWorksBPMS,目的在于从一个复杂的业务往返流程中恢复失去的收入。这个流程涵盖了客户和OEM部门，还有内部的财务和

20、客户服务部门。TeamWorks软件能够利用T-Mobile现有的一些Tibco架构的集成节点，从而让BPM工作团队集中精力改进流程。有时候BPM会推动某个组织向Se)A(SerViCe-C)rientedArchitecture,面向服务的架构)前进。“我们最终会实现这个目标，BPM给我们提供了通过一种安全的方式向合作者开放权限的可能”，DougSchwinn说，他是玩具制造商Hasbro公司的CIO。如果没有SoA可以使用，那么很多BPMS平台都提供可以跟原有系统的集成工具箱。尽管进步的集成技术和SOA的出现已经让系统整合变得更加轻松，但“你还是需要对以硬件为核心的、集成原有系统的工作挑战

21、表现的毕恭毕敬。这是一项艰苦的工作，而且比大部分商务人士所喜欢从事的那些工作要花费更多的时间”，PhilGilbert说，他是LombardiSoftware公司的CTOoGilbert建议BPM创新要把集成努力与流程设计工作区分开-换句话说，IT应该管理底层系统集成，而业务分析专家则为流程设计工作。如果附加系统集成在新发布的版本当中，并且进一步简化了流程，那么这种分工方法有助于更快地把功能实现交到最终用户的手里。随着BPM在机构推广开来，流程管理挑战也会随之出现。改变流程或者数据源会造成意料之外的副作用。但是可以显着提高整体的组织运行绩效的潜力还是让管理这些风险的努力很有价值。GiIbert

22、说目前整个产业仅仅接触到其中的皮毛。“BPM技术的战略价在于流程监控，以及提供对公司全部运营流程的一个整体俯视-而不管BPM平台是否实际在执行这些功能流程二“对于你的业务流程来说，理想的业务流程管理系统本质上将会是一个数据库管理系统，真正的突破在于根据提炼出的数据定义你的业务流程”，Fingar说。为了保持竞争力，机构将不得不像他们现在管理数据那样尽可能迅速和高效地增强流程管理能力。确实，业务流程管理软件毕竟不是人脑，其实一根筋，只会根据预先定义的流程走下去。而若管理中存在过多的特权主义，显然会增加人工干涉的工作量，降低了业务流程管理软件自动化作业的效率。所以，要提高业务管理软件在企业管理中的

23、效益，尽可能的消除特权主义给业务流程管理所带来的影响。培训是关键通过BPM的实施，调整后的流程从流程制定到用户接受并按此工作，是需要这个过程的，而且，这个过程，还比较长，毕竟江山易改，本性难移。所以，在业务流程管理项目中，还要注意的一个问题就是如何才能让用户迅速的接受新的流程，并按此操作。除了平时加强培训、监督外，我们公司还采取文化大革命那时候的大字报、小字报的形式。如在每个部门的办公室，我们都作了一些大海报，海报的内容就是部门管理流程。如在质量部门，挂了供应商验厂流程与原材料进货检验程序;如在采购部门张贴了采购员出差审批程序、采购不良品管理流程等等。同时，对于各个员工，我们业务流程项目管理小

24、组，还为他们量身定制了很多小卡片，卡片上就是他们最常用的一些业务流程，就贴在他们办公桌前面，是时时刻刻提醒他们按照标准流程来办事情。如此，即使用户对于某些流程可能不熟悉，按照以前他们喜欢瞎蒙，但是，现在流程就在他们面前，他们也就会按照流程来办事情了。如此，就提高了员工对于新流程的接受力度，能够在最短时间内接受新流程。所以，我建议各位要上BPM项目的朋友们，会了尽快的把业务流程管理项目扶上正道，可以借鉴一下我们公司的做法。贴贴大字报，做做小卡片，这些工作看来比较小，不起眼，但是，其功效可是不小的。规范流程最重要很多人使用系统，无论是业务流程管理软件还是其他的诸如ERP等管理软件，都会说，软件是死

25、的，人是活的。这句话对吗?从表面上来看，确实有些道理。再怎么先进的软件、计算速度再怎么快的电脑，仍然是人造出来的，其没有智慧。但是，从BPM项目来说，这句话是非常错误的。若我们真有这种想法，那还不如不用BPM软件呢，流程都通过人工管理好了，那还更加方便;遇到一些意外情况时，处理起来还更加方便，不会被软件所束缚。但是，为什么现在还是有这么多人在上BPM项目呢?就是因为现在人太聪明了，太喜欢自作聪明。管理层很难管理他们，所以，他们需要给每个员工头上戴上一个“紧箍咒”，告诉他们,要给我按标准流程来做，不要违反规矩。毕竟，国有国法，家有家规。若员工视企业管理流程为无物，对其视若无睹,则企业管理就会乱套，就像洪水泛滥一样，不堪收拾。