发展
虽然我国对BPM的专业研究较晚,但是BPM需求的产生是在20世纪末,20世纪90年代,Michael Hammer和James Champy的成名之作
《公司再造》(Reengineering the Corporation)一书在全美公司领域引发了一股
有关业务流程改进的汹涌浪潮。这两位管理学宗师在书中
展示了这样一个观点——重新设计公司的流程、结构和文化能够带来绩效上的显著提高。但是由于缺少对变革管理以及员工变革主动性的关注,在很多致力于把他们的理论付诸实践的公司身上产生了反作用的结果。曾经的有关业务流程再造的金科玉律黯然失色,并且变得落时。今天,业务流程改造有了新名字——
业务流程管理(BPM),而且再次进入了流行
时段。受到全球竞争压力、消费品化以及政府监管的刺激,美国公司正在重新审视他们的业务流程,寻找到更高效的方法,通过自动化甚至
外包的手段去实施它们。公司再次把业务流程管理——这种通过
分析、建模和监控持续优化业务流程的实践,
当作一种解决业务难题和帮助公司实现自己财务目标的系统方法。
“公司正在认识到全面而可靠的理解自己的流程对于实现任何
绩效目标都是非常根本的要求”,咨询机构Process Renewal Group的创始人Roger Burlton说。“如果大多数组织还没有做点什么业务流程管理的事情的话,那么他们一定已经在开始做这项工作了”。
业务流程(也叫做
经营流程)是为了实现一定的经营目的而执行的一系列逻辑相关的活动的集合,业务流程的输出是满足市场需要的产品或服务。根据功能、管理范围等的不同,企业的
流程管理一般分为
生产流程层、运作层、计划层和战略层四个层次。图1对各个层次做了比较。
管理目标
流程管理的各层次均有
相对独立的、特定的方法,但层次之间也有着密切的联系。首先,
高层的管理目标最终要通过低层的业务活动来实现;其次,
当低层的管理解决不了实际问题时,就需要引入高层的管理,例如当运作层的调度无法解决资源的配置问题时,就说明分配给该流程的资源数目需要修改,此时需要引入计划层的管理,重新进行资源能力计划的计算;最后,低层的数据为高层的管理决策提供依据,企业的
策略管理和战略管理中的模型和参数来自对企业实际经营活动统计数据的积累。因此,从整个
企业流程管理的角度来看,有必要将这四个层面上的流程管理统一到一个框架下,并和企业的信息系统联系起来。
从
企业信息系统的角度来看,办公自动化系统、
事务处理系统和决策支持系统等都是常见的企业信息系统,但这些系统并没有加入流程的因素,只是用来帮助员工更好地完成某些特定的任务。工作流系统的出现使得整个流程的自动流转或自动执行成为可能,但是工作流一般只解决
生产流程层的问题,与企业的计划和战略决策还存在一定的脱节。另外,随着企业
业务流程向企业外部(供应商和客户)延伸,传统的工作流系统无力解决跨企业的流程集成问题。基于以上原因,面向企业的业务流程管理解决方案由此应运而生。
业务流程是把一个或多个输入转化为对顾客有价值的输出的活动。简而言之,业务流程是以涉及为顾客提供产品或服务为最终目标的组织活动的集合。一个典型的业务流程应该包括下面六大要素:流程目的(它存在的理由);输入资源;按一定秩序执行的活动;这些活动之间的结构(相互关系和作用);输出结果;该流程创造的价值。
一家企业成功的基础,就是通过业务流程协调各种资源来达成企业目标。无论是向顾客交付产品,与合作伙伴协同,还是引导员工的努力,
业务流程能够将企业的产品、品牌和价值有机地编织到一起,例如下面这些业务活动都是业务流程:
根据生产所需,安排原材料的检验、入库和供应;
回答客户的咨询;
从供应商那里采购;
向市场投放新产品。事实上,业务流程集成了企业内各种业务的特征,业务流程也因此成为企业运作特性的核心。
建立和规范
在一个企业尤其是中小企业建立的初期,由于企业生存的压力,管理者普遍关注市场和销售,对流程和制度不重视,运作基本靠员工的经验和一些简单的制度,企业的成功往往取决于
企业主的个人能力和一些偶然的机会,比如拥有该行业成功所需要的特定资源。处于这个层次的企业,当在解决了生存问题,开始走向规模化的时候,面临着从人治向法治的转变。这个时候解决的是一个从无到有的问题,像许多企业推行ISO9001体系或其他一些基本制度的建设,都是为了解决这个问题。国内的大部分中小企业和一些市场化程度不高的行业里的企业大都属于这个层次。
处于第一个层次的企业,面临的最大的问题是无序,通常会出现组织结构不健全,机构因人设岗的,权责不清和没有制度流程。这些企业通常没有成型的组织机构,谁熟悉哪一块也就由谁负责该项业务,职能通常会有交叉,企业的运作基本上依赖于人的经验和惯性,经常会发生越级指挥事件,同时会表现出高度集权的特点。
从
流程管理的角度,这个时期的企业急需的是建立起基本的流程和规范,如
业务运作流程、作业指引、岗位说明书、人力资源管理体系等。
这个时期的企业不能强求业务流程的精细,关键是明确权责,识别和描述流程,使工作例行化。
业务流程优化
由于企业规模的扩大,组织的机构会逐渐庞大,分工会越来越细,企业官僚化程度也在随着增加,这个时候面临的最大问题是低效,也就是效率的低下,通常这类企业会表现出以下特点:
组织机构完整,甚至大而全,也有书面的职责说明、制度流程,但是
会出现部门间合作不畅,跨部门流程工作效率低下,决策时间长,
制度流程虽然有但是没有达到精细化的程度,流程执行不到位等等问题。有相当一部分企业还通过了
ISO9001认证或有完整的制度流程体系。具备这个特点的企业一般是一些迅速膨胀后颇具规模的民营企业和一些国有企业。其
业务模式相对稳定,而且通常
企业发展比较快。
在这个阶段的企业需要解决的问题如何提高企业的
效率和反应速度。通常采用的方法是
先对现有流程的绩效进行评估,识别缺失的关键环节和需要改善的环节,针对流程各环节从可以以下四个角度进行分析:
-活动:是否过于复杂,存在精简的可能性
-活动实现形式:是否能用更有效率的工具来实现活动
-活动的逻辑关系:各环节的先后关系可否作调整以达到改进目标
-活动的承担者:是否可以通过改变活动的承担者来使流程更有效率
然后通过对现有流程的简化、整合、增加、调整等方式来提升流程效率,还可以通过明确流程所有者(processowner)的形式来监督流程的整体表现,从而避免部门间推委的问题。
一般在进行
流程优化的时候关注的是相对低层次的流程的效率和成本等,可以采用一些方法和工具对现有的流程进行改良,同时强调流程的
有效执行,一般不会涉及到大的组织变革和流程变革,这个时候解决一个从有到更好的问题。
以一家家电企业的研发流程为例,该企业有完整的研发流程和制度,但在实际运作中,新产品研发周期很长而且研发效率较低,设计变更频繁,模具空置率高;各类评审的手续复杂,研发与市场以及工艺部门、生产部门之间经常发生推委事件等等。通过对研发流程的
绩效表现、流程各个环节以流程的运作情况进行诊断分析,发现流程.各个阶段包括
概念阶段、计划阶段、开发阶段、验证阶段、发布阶段、生命周期阶段各个阶段的关键控制要点的操作性不强,缺乏有效的检查清单而使重要的评审点评审受限于评审点的经验甚至流于形式;和各个相关部门之间的接口不清晰、导致重复返工;不同类型和难度的研发项目采用同样的流程导致流程的效率低下等等,找出上述问题后,针对性的优化上述流程以后,就可以有效的解决上述问题,提高研发流程的效率。
业务流程优化的特点
是一些局部的变革,对企业的冲击相对较小,相对比较容易实施,
缺点是只是一些改良,对一些存在结构性问题的企业往往不能解决根本性问题。
业务流程重组
这个时候往往是公司的战略转型期,需要对流程进行根本性的变革,需要全面评估
业务流程,需要根据战略对流程进行重新设计和重组流程以适应公司的战略,流程重组往往伴随着IT系统的实施、重大的
组织变革和
业务模式的变革。这个阶段往往是一次重大的管理变革。
企业架构之流程管理(BPM)
这个时候企业的流程本身并没有很多的问题,但是往往不能适应新的战略,一般伴随IT系统的实施或者新的
战略调整,需要对企业的流程进行全面的评估和战略性思考,同时随着流程的调整需要进行一系列的配套措施。
以某知名的房地产企业为例,公司的新战略要求能够快速的交付产品,快速的进行
存货周转,但是在对房地产开发的整体
业务流程进行审视时,发现对现有的业务流程进行简单的优化和完善并不能解决问题,在整个开发流程中,招标采购占了相当长的时间,如果只是对该流程进行一些局部的优化并不能有效的解决快速交付产品的问题,在对整个业务流程进行后战略性思考,提出了从设计角度对一些材料和工程进行标准化设计,在采购方面建立
战略采购系统的模式,通过这种标准化的产品设计和战略采购,使得一些费事费力的采购招标过程可以免去,从而极大的加快了产品的交付和提高了效率。这个变革涉及到整个规划设计、采购招标乃至
成本预算等流程的变革。
业务流程重组因为往往伴随着
业务模式的调整,是一次重大的管理变革,存在较大的实施风险,但一旦成功,往往能给企业带来业绩的重大改善。
这三个层次的
流程管理适用于不同阶段的企业,当然他们之间的界限不是严格意义上的。在进行
业务流程的规范时,最好能对流程进行一些优化,
业务流程优化和业务流程重组之间的界限也只是程度上的区别,关键是进行流程管理时根据管理的现状采用合适的方法和步骤。
面向工作流
工作流描述了在BPM空间内人与人的交互和人与系统的交互,应用最为广泛的在协同办公领域。根据独立分析师Sandy Kemsley所述,工作流就是我们所熟知的BPM的初始阶段。“一开始就有工作流,”Kemsley在她网站的第二专栏中写道。“更确切地说,在预先确定的流程图中有一个扫描过的人与人之间交互的路由文档。”在当代BPM的大背景下,工作流和EAI(
企业应用集成)平起平坐,并在某种程度上,可以看成是人的集成。工作流BPM指的是在优化
业务流程中以人为本的活动。这些措施包括活动监控,流程治理,正如BPM的成因,是对未完成文档向下进一步处理的编制。
面向文档
文档管理和工作流齐头并进。当文件穿过工作流时,追踪文件的去向以及它们的变动,维护文档记录的可靠性、安全性、可用性,早在计算机革命之前,已经成为了业务的必要元素。今天的
企业文档管理系统利用计算机技术来提供存储、安全、索引和检索选项。可用性正日益重要,因为多方参与者经常需要凭借多个应用来使用同一个文件。因此,依靠现有业务系统的集成是面向文档BPM成功的一个主要元素。
面向业务规则
自动化这门学科可以追溯到人工智能的早期,当时研究人员试图以最简单的术语,集中于规则的使用来描述复杂的系统。像最早的尝试模拟国际象棋游戏实验计算机,这些系统按照状态机的模式工作。有点像游戏规则,组织显式地或隐式地按照关键“规则”来定义过程,这些关键“规则”在流程的某些点上提出要做出哪些决定或更改——或请求哪些授权。一旦被称为推理机,同类的软件系统就发展成了业务规则引擎或者业务规则管理系统。创建和维护业务规则的复杂性常常成为这些推广这些系统的阻碍成分。
这些系统承担了类似以建模为中心的BPM工具的角色。(诚然,很多用户会将以建模为中心的BPM作为一个独特的类别。)以建模为中心的方法起初倾向于自上而下的进行工作,这些工作就是在模型中用特殊符号描述一个组织,或组织的改进。一些工具厂商已经完成对可执行模型的支持——他们的模型可以生成或者帮助形成可用的业务逻辑的代码。与这里介绍的其他类型的BPM系统相比,
业务规则引擎在纯BPM系统中的规模将变得更大。
面向EAI
在整个90年代从不同系统对集成可操作型数据方法的改进,采取的是企业应用集成或EAI的形式。虽然这些往往是硬接线的一对一集成,消息队列这种应用集成变得尤其流行,同时隐含
业务流程表现为有组织的队列,例如,清除银行支票或执行库存订单,让集成服务器很大程度上有了面向工作流的BPM的味道。今天,许多架构师都倾向于把数据集成问题看成业务流程问题。同样地,一些架构师将期望根据B2B或
电子数据交换(
EDI)来集成的过程自动化。
1.确定BPM项目的轻重缓急
许多组织犯这样一个错误:没有把BPM应用系统与项目实施部门及整个企业最重要的
战略目标紧密联系起来。BPM所关注的“流程效率”应当与更重要的战略目标结合起来,譬如提供效率更高的客户服务。
IT组织以及来自每个业务部门重要的
利益相关者应当就项目的轻重缓急达成一致,所选的项目不仅能给单个部门直接带来好处,还能给多个部门或者整个组织直接带来好处。达成一致意见的最佳办法就是,召开项目优选讨论会,所有利益相关者以及客观的协调者,如执行发起人或者外部顾问都来参加。
2.确认BPM试点项目
一旦确定了BPM项目的轻重缓急,就应当选择针对某个部门的特定项目作为正式行动前的试点。成功的项目试点不仅会证明BPM的成功,还有助于证明有必要在整个企业扩大部署策略。因此,所选择的试点应当直接支持企业最紧迫的
战略目标,无论是提高
客户服务、更快地推出新品,还是缩短流程时间以获得竞争优势。
一个例子是,某地方政府选择虐待儿童案上报过程作为试点项目,因为该项目为在重要地区提供公共服务带来的好处最为明显。另一个例子是,以抵押贷款办理员关注的抵押贷款开办作为试点项目,以考察是否能通过缩短贷款开办时间从而获得竞争优势。一家汽车制造商专注于简化分布广泛的
应收款项流程,从而支持跨组织提供最佳服务这一业务目标。
这些率先进行的项目被选中,不是因为它们一定就能证明迅速获得投资回报,而是因为它们对整个组织的业务战略来说至关重要。
3.成立亲合团体
许多组织在选择合适的试点项目及确保成功方面煞费苦心,可是在把项目推广到其他部门和流程方面却没有给予同样的关注和努力。等到试点项目完成后才开始规划下一个部署阶段,这是错误的做法。
组织需要有精心设备、分阶段进行的部署计划,还要考虑到有缓急之分的BPM项目以及有密切关系的亲合团体(affinity group)。亲合团体是指共享流程、文档/文件和数据的部门。譬如,有着共同
管理职能的几个部门,如财会、营销和客户服务部门。这些部门或者业务单位可以重复使用流程的相同部分,从而能够获得跨部门的流程效率,降低实施、支持及培训成本。亲合团体里面的主要部门实施BPM应用系统后,它可以指导实施类似应用系统的下一个部门。这种方法促进了整个团体共享流程自动化知识。
作为这种方法的一部分,组织应当考虑亲合团体里面每个部门确认在最初实施阶段,哪些项目处于最有可能成功的准备状态和具备所需的资源。还要评估诸多因素,如自动化程度、计算机使用技能以及亲合团体里面每个部门的工作量。
成功的企业BPM策略可能需要报告职能关系和对职责方面进行调整,事先进行这种改变很重要。譬如说,BPM策略会影响多个系统和应用软件,包括ERP系统、财务应用软件、内容管理系统以及集成服务。BPM策略还需要改变人们的办事方法以及使用系统的方法,即使核心流程根本上没有变动。
在评估组织变化时,把通常分散在组织各个角落以及IT不同部门的BPM知识集中起来也很重要。有些组织会因而建立“BPM卓越中心”(BPM Center of Excellence),充当专家小组,负责评估、研究及实施BPM技术。代表可以包括参与BPM试点项目及后续项目的来自IT部门和系统集成商的人员。如果采用了亲合团体方案,IT支持人员、BPM系统管理员和来自各部门的重要业务用户也可以参与进来,分享经验和最佳策略。
一旦项目得到了执行发起人和几个重要的项目利益相关者的评审和一致同意,就应当把企业BPM策略、策略依赖的分析以及整个部署计划传达给行政管理班子、部门/业务单位的负责人、IT管理人员以及参与“现状”评估的各方。这一步应当通过对每个部门的优先项目和需求进行一系列演示报告来进行。
遗憾的是,许多组织要么忽视了这一步,要么策略的传达对象不够广泛或者内容不够明确。沟通策略是任何技术策略项目的一个重要组成部分,但对BPM来说尤为重要,因为BPM会对系统、流程和多个级别的职员带来重大影响。
BPM卓越中心可以负责沟通,最初的试点项目完成后应当继续沟通。另一个最佳策略就是成立由最初的项目利益相关者组成的BPM策略指导委员会,每月或者每个季度开一次会,评审策略,把最新情况传达给组织其余部门。
5、赢得企业上下的广泛支持
遵照这些步骤将帮助你避免在整个企业部署BPM时掉入最大的陷阱:把重要的业务部门排除在规划过程外面。部署规划不仅仅是项目经理和当前BPM项目队伍的工作。确认前期项目以及后续推广项目需要诸部门及业务单位提供反馈意见,特别是因为规划有赖于如何选择对贵组织的
战略目标产生最大影响的流程自动化应用系统。有些部门要到项目的后期阶段才能看到BPM策略在本部门的实施,在这些部门达成共识和得到他们的支持同样很重要。
移动应用时代来临了。而对于移动应用来说,业务流程管理(BPM)成为了焦点,使用BPM可以大的提高企业的工作效率。
为移动BPM做好准备
如果组织不开始为移动BPM做准备,他们可能就会发现自己在争先恐后地追赶,在不久的将来花更多的钱。移动再造业务流程是一个数十亿美元的新兴产业。在未来五至七年内,该行业将带动企业走向移动流程。为了避免落后,企业组织就可以开始盘点他们的流程来为移动机会做准备。如果想要采取移动BMP,专家们还触及五个关键步骤,为公司准备一个移动BPM方案:
1、确定移动需求。首先,对你的流程进行分析,为一个移动方法寻找可以优化的步骤。在确定在一个领域中,最终用户和员工使用同一个流程从后,要考虑如何重新设计这些步骤,使他们能运用移动。寻找真正依赖于大量的实时通信或信息的实时访问信息流程—‘通信热点的流程’。抽出时间来分析流程并发现哪些步骤是移动的最大受益者,公司能避免为移动而移动。
2、了解您的员工和您的客户。观察员工在工作中做什么,他们怎么做的,以确定移动是否可以帮助他们更好地完成工作。有时候在顾客面前,能有这个流程引导,你将变得更加重要。同样,企业组织应保持对最终用户的密切关注,以创造一个令人满意的移动客户体验。用户的需求具有如此巨大的能力,能够使企业发生前所未有的事情。在过去,很多都是由技术驱动的。它已经正在由终端用户和客户的需求推动。
3、从组织的高管那里得到支持。如果管理层不相信移动BPM提供的好处,一它将很难得以实现。尤其是一个具有一般企业方向,适当的利用现有技术追求企业目标,更为重要。
4、有一个合适的移动资产管理系统。为了平滑过渡到移动BPM,使用系统来管理和规范员工对移动设备的使用是非常重要的。在你的移动资产管理里面,你至少需要有一些组织级别,这样才能向前发展。
5、制定明确的移动BPM战略。如果没有一个明确的目标,在BPM的其他方面再怎么努力,BPM方案都可能会动摇。强烈建议所有公司制定一个整合的BPM战略。如果你整合一个战略为三到五年,您将不知道以后会发生什么,但你可以每6个月更新它,您就可以在市场有竞争力,您也将得到一些关注的焦点。
移动BPM攻略
移动能力可以给BPM愿景增加速度和敏捷性——但是,这并不意味着转向移动可以一蹴而就。为了取得收益最大化,在将移动计算集成到业务流程的过程中,企业和IT专业人士应该从整体角度出发,从设定明确的最初目标开始,直至移动应用成为每个人的日常工作的一部分。
移动BPM第一步:设定目标,项目试点
当组织机构决定要在现有流程中增加移动能力的时候,他们应该先从设置简单、易于理解的目标开始,位于康涅地格州费尔菲尔德的圣心大学的管理学副教授Paul Bailo这样说道。确定在这流程中你认为什么可以实现增值,并解释清楚原因。最重要的是,不要急于铺开摊子去实现你的移动规划,首先应该先去做一个或几个试点项目。这些测试的运行能够有助于减少对所有参与方的压力,同时,也使得向移动能力的转变过程是一个循序渐进的演变,而不是一场革命。制定一个计划,然后去和其他人沟通,沟通,再沟通,尤其要特别注意强调对个人用户来说有什么好处,这将显著的提高采用率。深入分析,在实施移动性的过程中也是非常关键的一步,他说道。这需要搞清楚,对于各种不同角色的员工,应该去跟踪什么,以及如何进行跟踪。
下一步:建立一种移动思维
许多机构都开始以数据和内容来衡量移动能力,作为一个例子,称之为“进步巨大”的全国公共广播电台(NPR)的做法。NPR正在努力通过“一次创建,到处发布”(COPE)模型去管理它所有的内容。他们已经创建了很多应用编程接口(API),通过这些API,他们可以通过多个设备和网点来发布他们的内容。设备就是容器,想想在这些容器之外发生的事情,想想您要发布的数据。
进一步:处理移动BPM的挑战
然而,实现移动BPM也有其内在的组织方面的挑战。首先,你要确保你团队中有合适的人选去规划和推动项目的实施。团队成员可以包括
首席信息官(CIO),销售总监或类似的更高级别的人员。接下来,确保你已经明确了你要解决的业务问题。这是关键性的起点。然而,计划好你将如何提供优异的最终用户体验,也是非常重要的。这两个方面你必须都要做对,如果这两者之中任何一项出现问题,其他就不用谈了。
从技术角度来说,了解现有的基础设施也很重要。举例来说,如果准备实施“自带设备办公”(BYOD)策略,也就是说,每个雇员将在工作中使用自己的移动设备。你需要了解组织和员工的当前状况,以及你想要达到的目标状况。尽管根据预测,移动消费,尤其是在应用方面的花费,到2015年将增长100%,但移动费用的开销可能并不是一个很大的问题。为了抓住新的机遇,IT预算正在向移动方向倾斜。然而,如果你看一下在ERP和CRM系统和分析上的花费,其中已经做了很多投资可以应用到移动能力上。
始终保持移动用户的前沿和核心地位
永远不要忽视您的最终用户。通常情况下,高层做了很多决定,虽然这些决定会影响他们,但是他们的想法却没有得到充分考虑。事先就处理好他们所关注的问题,可以避免很多后患。移动应用是一个需要用户界面、用户体验和业务分析的综合体。需要能够为用户体验进行设计的人员,同时还能实现你所需要的功能。那些属性从未像如此紧密相连;实际上在把这个业务结构都放进了移动设备之中。
最后,移动设备的固有限制可能意味着很多其他地方也需要因之改变。从战略的角度来看,你需要枕戈待旦,时刻准备着将移动能力集成到流程管理中——即使你的第一代移动功能已经付诸实施,也不可有一丝松懈。
BPM的经过了十几年的发展,已经历经几个开发语言的,JAVA与.net是最受企业欢迎的开发语言。
1:Java bpm
JAVA BPM是一个扩展性很强的流程管理系统,百分百用JAVA语言开发,持久层采用Hibernate实现,理论上说,只要Hibernate支持的数据库JBPM都支持。同时它还能被部署在任何一款JAVA应用服务器上。
2:.NET bpm
.NET BPM 是基于微软.NET技术的BPM,具有集成大型企业软件的特征。.Net bpm采用的是B/S架构,附带有多种可视化编辑器,主要特点有:缩减代码编写量,快速开发,图形化设计,预警检测等。
促进有效的BPM策略
正确的BPM使用从仔细识别真正的业务流程开始,而不是它们目前的实现;要把业务流程和应用工具看作是交互元素;对策略的流程和应用维度的重视程度应当与对实现的重视程度相当甚至更高。
BPM被用来打破结合了若干业务目标的特定活动。在许多情况下,也许是BPM策略实施最佳的情况下,它可能是作为企业架构的一个元素而存在的。在应用设计和开发方面,BPM是需求的来源。
BPM驱动现代化的关键
应用现代化是重构应用的过程,其目标是吸收被证明能够提供最好敏捷性和效率的设计原则和技术。它主要考察的是支持业务流程的实现,大多数情况下,会把应用实现当作功能基础。
明智的BPM驱动应用现代化解决办法认识到。工具与流程之间存在根本性的依赖。员工利用手头的东西做自己能做的事,所以应用和数据的可用性往往框定了他们做事的方式。这种相互依赖给应用现代化制造了极大的风险,因为太容易就会把过去基于工具的限制带给将来的应用了。这意味着你必须从当前的应用细节退后一步重新捕捉真正的业务流程。
这时候,企业架构也许提供了一条容易的途径,如果存在一个“EA模型”的话(几乎一直都是这样)。可以说,对于一家大企业来说,永远都不要在没有根据已有的标准(如TOGAF)制定一项EA模型之前,就进行大规模的遗留应用现代化。而在应用现代化项目的范围存在更多限制的情况下,是有可能从当前的应用中恢复业务流程定义的。如果你没有EA框架来引导BPM映射,可以利用应用工作流,通过把应用功能组织进支持的业务流程来对它们“抽象”化。
确定“工作模型”
有一个合适的BPM框架,现代化遗留应用的第一步是评估该框架的工作流限制。这种做法的目标是确定应用最适合支持的工作模型。下面一些模型可供参考:
1、简单事务流:业务流程靠事务驱动,当一个流程被发起时,它是按照既定的路径走到结束的。大多数遗留应用都是这样工作的,无论业务有没有执行。
2、流化计算模型:业务流程受到活动流的驱动,这些活动流可能牵涉到多个事件和来源,流程需要在这些流当中得到交互式的支持。
3、事务+分析:业务流程基本上属于事务性,但大数据采集和分析驱动了一批流程。 这些模型每一个都有一个合适的应用结构,后者随后可以推动中间件工具以及应用程序接口(API)的选择。事务型应用,尤其是简单的事务型应用,可以很容易地跟SOA应用模型连接起来,而SOA也可以用在事务+分析模型的主事务流上。流计算模型应该基于复杂事件处理以及流(Stream/flow)式API,尤其是微服务。CEP可能对事务+分析模型也有用,因为分析有实时的需要。
这种模型会叠加到原来的BPM流程图上,表明了应用是如何与流程自然建立起来的工作流关联起来的。流程既是模型定义的事务或流的来源,也是活动如何排序的引导力。把握住这种映射来确保不会在建构应用时打破BPM工作流。
映射应用组件
BPM驱动应用现代化项目的下一步是映射当前和未来应用组件到你选择的模型里面。如果应用组件适合总体图定义的流,那这种组件就适合用来提供相适应的接口。不过要注意所需的API和信息模型;这些合起来可以形成中间件选择的需求。
这时候就要考虑业务流程和应用工具的交互性问题。贯穿你模型的临时性工作流在逻辑上未必与应用组件相适应,或者这个时候你希望使用的流里面合适的组件未必具备所需的信息。如果是这种情况,那可以考虑对流进行试验性的重映射,改变组件次序,然后收集所需的信息。你在做的是改变假定的业务流程来优化特定的应用用法,所以根据过去经验从最有价值的组件开始是明智之选。
策划实施
当所有应用和组件已经映射进模型之后,策划应用现代化并实施策略。重要的是要保持功能(BPM)与结构(技术)的分离,所以新的组合应用图和工作流应该在一开始做好的BPM流程图之上构建。记住,对这张图进行少量改动以适应某些应用组件所需的特定信息。