如何打造企业级敏捷灵动的OA.docx
《如何打造企业级敏捷灵动的OA.docx》由会员分享，可在线阅读，更多相关《如何打造企业级敏捷灵动的OA.docx（6页珍藏版）》请在冰点文库上搜索。
如何打造企业级敏捷灵动的OA
如何打造企业级敏捷灵动的OA 系统
我国自有OA系统以来的近15年里，约5000家OA厂商向超过10万个单位提供了OA产品或项目的实施，哪怕是基于最乐观的估计，OA实施成功率也不到15%。
很多OA系统成了摆设或在应用1、2年之后就完全废弃。
究竟是什么原因，使得美好的愿望，最后往往以噩梦而结束呢？
我们认为，这有哲学意义上的OA价值观、方法论、组织行为能力、技术原因等方面的诸多因素甚或这些因素交叉作用的原因。
本文谨从OA适应变化能力的技术原因做一些管豹之见。
只有在变化中不断创新与突破，才能取得未来的竞争优势！
在一个动力系统中，初始条件下一个微小的变化都有可能带动整个系统的长期且巨大的连锁反应，这是一种混沌现象，这就是著名的蝴蝶效应（ButterflyEffect）理论。
随着全球之间联系的不断加强，企业事务、政务事务的发展也就受到了来自内部或外部各种事物的影响。
在一个“唯一不变的就是变化本身”的时代里，需要管理者随时适应内部与外部条件的变化，适时调整战略与业务模式，做到以动制动。
对于政府而言，服务型的政府、节约型的政府已经成为政府机关文化改革的方向与热点，随着政府机构改革的深入与政务业务流程的持续优化与再造，政务运行也彰现出不断变化的特征。
对于企业，这样的变化来自于企业自身的产品更新换代的变化、企业运营成本控制的变化、竞争对手的产品及市场策略的变化、市场环境的变化等内部与外部的变化。
从适应变化的方面来看，可能涉及到组织机构的变化、人力资源分配的变化、流程再造与过程控制的变化、营销模式的变化等等。
只有在变化中不断创新与突破的企业，才能取得未来的竞争优势！
传统OA应用系统的短板
带着美好的愿望，OA系统带来几多方便的同时也带来些许新的烦恼，比如：
开发周期长。
传统的软件开发需要历经“需求分析--- 设计---编码--- 测试---试运行---N次修订设计---N次编码---运行”等冗长的开发过程，显然不能顺应当今事物万变的迫切需要，极端的例子是，项目开发尚未完成，可能客户方的组织机构、人员配置、业务模式都发生了变化，投入巨资得到的开发结果成为了大堆的比特垃圾。
投入人力财力巨大。
在传统的开发模式下，无论是需求分析、编码还是试运行，项目双方都将投入巨大的人力财力。
用户方自我维护能力缺失。
当前的应用系统普遍功能繁多、涉及多种复杂技术，随着用户业务的发展与变化，需要适时调整业务应用系统，而一旦开发方缺位，所有的后续系统改进计划只能搁置。
业务流程定制。
OA系统属于工作流应用系统，业务流程引擎的核心能力事实上是OA应用系统的成败之技术关键。
目前国内OA系统，却大多忽视了基本的流程引擎关键能力，最后造成很多上了OA系统的用户跛一只脚上路。
这里列举几个例子，以说明业务流程引擎应该关注的问题：
一、流程重定向能力
业务流程被赋予自定义能力之后，理论上可以满足应用单位所有的业务流程所需。
但所定制流程是有限的，而业务模式是不可穷举的，业务模式的紧急变化以及组织行为的事务个性普遍存在于各种规模的政府、企事业单位，因此，定制流程在运行中必须具备流程重定向的能力，以在任何不可预测的变化中随时便捷地改变流向，而无须从系统流程配置上调整。
遗憾的是，我们见过很多厂商的OA，在文件流转出现紧急事件时，往往采用的是从流程定制的角度去临时修改定制业务流程，而不具备流程重定向的能力，最后导致“办公自动化”成为了名副其实的“办公手动化”。
二、文件召回能力
在流程运行中，必须识别流转文件的“产权”，自本节点发送出去的文件，到下一节点处理之前，须能被本节点回收处理，基于这样的设计，能避免很多工作的尴尬。
三、流程嵌套能力
业务流程至少具有层次性与结构性两个特征。
层次性：
组成流程的活动本身也可以是一个流程。
流程是一个嵌套的概念，流程中的若干活动也可以看作是“子流程”，可以继续分解若干活动。
结构性：
流程的结构可以有多种表现形式，如串联、并联、反馈等。
往往，这些表现形式的不同，给流程的输出效果带来很大的影响。
OA的应用，以收文为例，收文阅文之后，可能转为督办，督办其实就是一个嵌套进来的新流程，其流程模型基本类似于一个发文流程模型，这个过程也就是我国公文办理中“阅转办”的一个模式。
同理，串联、并联、反馈等子流程，均可按流程嵌套模式得以应用，从而塑造强大的流程流转能力。
很多OA厂商过分关注了串联、并联等流程应用的模式，而忽视了流程嵌套的本质，带给客户的应用结果往往就是生涩而不成熟的，严重的影响到了系统的易用性和实用性。
采用面向服务的架构（SOA）----OA的革命
香农OA INTRAOFFICE4.0基于面向服务的架构（SOA）开发，以面向服务的方法快速构建企业级的OA应用，其核心能力包括：
组织机构管理、人员权限角色管理、业务流程管理、功能模块组织管理、Portal信息管理、表单管理、文挡模版管理、统计分析报表系统管理等等。
其技术实现深刻地改变了OA软件实施的方法论，打造了快速架构、随需而变的敏捷OA应用平台，可以由不谙计算机技术的OA行政管理者自行快速架构适应自身需求的OA应用并适时改进之。
一、项目实施方法的革命
长期以来，OA实施无外乎两种实施方法：
产品或项目。
产品是基于多年、多行业、多用户的长期而大范围应用形成的经验积累之形成，产品大多都注重OA共性的东西，在对用户的个体需求上往往不甚满足。
产品实施模式，项目实施双方的资源占用都比较小，也便于快速推广，要求在实施中以业务适应软件产品功能。
很多用户，特别是一些较大规模的组织或称企业级用户，较多倾向于以项目形式完成OA，要求软件必须符合业务现状，项目实施双方必将占用大量的资源，推广周期将拉长。
而最新的基于面向服务架构（SOA）的OA项目实施过程一般为：
用户业务模式梳理----信息系统建模----试运行----信息系统建模调整----运行 ----持续改进等过程。
SOA的软件工程方法倡导了从以技术为导向到以服务（业务应用）为导向的转变，较少地关注技术本身，而是把重点到转移到业务应用上来，可以架设更实用、更易用的软件系统。
可见，最新一代的香农OA极大降低实施成本、缩短实施周期、降低实施风险，是一个可快速架构、随需而变、持续改进的先进OA系统。
香农OA跨时10年，历经“OA项目定制开发----OA产品----OA产品+定制开发----基于面向服务架构（SOA）的OA”四个技术服务形态，自采用SOA架构以来，取得了100%实施成功率的骄人成绩。
二、项目风险的控制
OA项目风险控制关键点在于：
1、OA价值定位
信息化项目是“一把手工程”，OA项目尤其如此。
业务单一的应用系统应用范围狭小，如财务系统限于财务人员、业务处室信息系统限于业务处室相关工作人员，而OA则是组织内全体人员参与的信息系统，其实现的不仅是公文收发文以及通知公告等功能，而且更应成为组织内信息交流、群体协同工作的公共平台。
以常见的OA功能模块如组织机构、PORTAL、业务流程引擎、公告等配置为例：
组织机构：
定义了全部IT系统的组织机构，机构设置、职能、人员及权限角色、活动，无一不成为其它全部IT 系统的根本大法，因为它的组织是全部IT系统中最全面、最写实的。
PORTAL及用户认证：
可结合U-KEY、CA认证等，进行用户统一身份认证，PORTAL更可整合或抽取展现其它业务应用系统的数据。
业务流程引擎：
不仅作为收发文的基本业务流程引擎，也应该是其它信息系统业务交汇与驱动的主线。
公告、邮件、即时通信、无线移动办公工具：
可以方便地集成其它信息系统的功能。
以上可见，OA系统是汇聚组织战略实施的关键IT平台。
应用范围的扩大，已经深刻影响到组织行为的变革。
一个业务系统的成败只是小范围的成败，也许不足以引起组织的关注，而一个OA系统的成败将影响到项目负责人在整个组织内的声誉。
由于技术的原因，技术人员（或曰CIO）常被组织任命为OA系统的负责人，但CIO往往缺乏组织管理的知识能力，难以掌握组织行为管理与组织管理的资源，因而常常忽视组织管理的根源，而习惯性地去关注一些技术上的旁支末节，最后所谓“技术上满足用户”事实上成为了满足技术人员的技术喜好。
因此，在所有信息系统中，OA理应成为组织内管理战略实施的关键支撑平台。
OA价值定位将有助于确定OA实施目标，以调用组织适当资源支撑系统的顺利实施。
比较于传统的OA，基于SOA的OA刚好可以提前引入组织行为管理的持续改进，其关注服务的特点，使得组织当前业务模型可以快速数字化，并通过模型的优化分析，得到快速的改变适应。
在诸事以“快”为先的当今时代，SOA架构表现出了无以比拟的优势。
2、开发实施周期
一鼓作气的典故我们都很熟悉，根据我们多年的经验，OA实施第一阶段在2、3个月之内能取得显著的阶段性成果，则将极易推动后续阶段的实施。
因此，目标清晰的阶段性目标，也是风险控制的要点之一。
3、实施节奏
OA项目乃至信息化项目的实施都是一个漫长而艰巨的过程，一旦获利，将长期受益。
因而，OA实施也不应急功近利，而应根据组织自身的战略发展与需求紧迫程度，分阶段确定实施的主要目标，以创造“先易后难、循次渐进、以点带面”的良好IT发展局面。
如果项目启动伊始，项目各方就急于求成，大面铺开，不但抓不到实施重点，还会由于IT技术引入所致的过激组织行为变革而带来重重阻力，项目一朝受阻，将严重影响后续的项目实施。
4、方案成熟性
方案成熟性对于软件顺利实施的重要性不言而喻。
基于多年的OA经验，对各种规模、各行业的应用案例加以总结，形成一个个快速应用模版，在成熟的应用环境中指引用户快速上手，也是非常重要的。
三、应用集成的能力
作为企业级的战略发展支撑平台，OA应该具备应用集成能力。
企业服务总线（ESB）的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。
从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。
1、企业服务总线（ESB）可以有那些用处
ESB不是万能的，他不是一个应用程序框架，也不是一个企业应用的解决方案。
它只是一个基于消息的调用企业服务的通信模块！
你可以把它嵌入到你的应用程序框架中，例如嵌入到spring容器里面，或者嵌入到工作流系统中。
它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法。
2、企业服务总线（ESB）的应用特征
大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。
面向服务体系架构（SOA）是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。
SOA使用户可以不受限制地重复使用软件、把各种资源互连起来，只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务，那么其他应用系统就可以很方便的使用这些功能服务。
支撑SOA的关键是其消息传递架构-企业服务总线（ESB）。
ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。
ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务协调运作，实现不同服务之间的通信与整合。
ESB在不同领域具有非常广泛的用途:
电信领域：
ESB能够在全方位支持电信行业OSS的应用整合概念。
是理想的电信级应用软件承载平台。
电力领域：
ESB能够在全方位支持电力行业EMS的数据整合概念，是理想的SCADA系统数据交换平台。
金融领域：
ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。
电子政务：
ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。
高校领域：
ESB能够全方位支持数字化校园平台的数据整合与业务流程整合，是理想的教务教学、学生、科研等应用的承载平台。
3、企业服务总线（ESB）的结构和功能
ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。
它可以在不改变现有基础结构的情况下让几代技术实现互操作。
通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。
更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，用不着在应用程序或者数据发生变化时，改动服务代码。
四、畅快的IT流程
香农独创的面向对象多层次活动模型业务流程引擎，决定了香农OA可在任何业务流程模型下均能取得畅快运行。
更可以SOA的软件工程方法，快速部署各种复杂而多变的业务流程。
工作流系统的“僵硬”过程模型，使用户在某些情况下（如发生某种特殊情况）不得不越过工作流系统而用其他的方法（如人工的方法）来完成有关的工作。
这一点主要是由于目前已有的系统中，建立时的过程定义与运行时的过程执行脱节，致使预定义的过程模型不能很好地反应实际的业务流程。
由于对过程定义及过程实列动态修改将会带来一系列的困难，因此需要寻找更为灵活的工作流程形式化表示方法及过程的执行策略。
一种提高灵活性的做法是从过程实例的执行入手。
传统的做法是所有活动的执行都是由业务流程系统负责的，而在可灵活自由的工作流（FreeFlow）中，过程的执行可由用户干预。
为支持此种执行方式，需要给每个活动定义6种不同的状态，其中Inactive、Active、Ready为用户态（表示用户可能的操作）；而Disabled、Enabled及Pending为系统态（表示活动与系统中其他活动之间的关系）。
这样，就把在传统系统中被混为一谈的活动的时序关系和依赖关系区别开来，也就实现了活动之间的依赖关系与活动的执行顺序之间的分离。
在此种模型下，活动的系统态将由业务流程系统维护，而用户则可控制活动的用户态，以使系统在认为某个活动不能继续进行时（违反某种依赖关系），用户仍可根据实际情况让过程进行下去，但过程的总体状态仍将得以正确维护。
这种能力对于处理常规流程之外所发生的各种异常情况，是非常有效的。
基于上述各类模型，参照并行工程理念，我们提出“面向对象多层次协同模型”（Object-orientedMulti-HierarchyCooperationModel）,作为业务流程协同工作描述机制。
它的主要特性有如下4点。
任务模型层----根据工作对象，一项协同工作可以分解成若干相互协同的（子任务）：
T=｛T1，T2，…，Ti,…，Tn｝
活动模型层----每个任务根据其性质划分为若干活动步骤，采用轻权活动模型或过程模型执行各步骤：
A=｛A1，A2，…，Aj,…，Am｝
会话模型层----根据需要，活动执行过程中协作参与各方采用某种会话方式相互交换、共享信息：
Con=｛C1，C2，…，Ck,…，Cp｝
制定一定的任务、活动划分原则和协同策略----确定各任务之间、活动之间、任务与活动之间的关系：
R=｛R1，R2，…，Rl,…，Rq｝
我们用下述4元组表达式描述一个协同工作系统S：
S=｛T，A，Con，R｝ 表示该系统的协同有任务T、活动A、会话Con3个层次，并遵循R所确定的关系。
升级会员 