（OA自动化）如何打造企
业级敏捷灵动的 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的革命
香农 基于面向服务的架构（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所确定的关系。
