从分布式SOA看集成技术发展2007-06-14 来自：java060515  [收藏到我的网摘]

对于今天的大多数企业而言，集成已经是一个不可回避的话题。在不同的历史时期，基于对信息技术的不同理解，企业采用了多种技术建设了各种各样的应用系统，比如，OA、ERP、CRM等，这些系统由于建设时间不同，负责建设的厂商不同，采用的标准也不同，因此，形成了一个个无法共享的信息孤岛。随着系统的增多，特别是门户、商业智能还有协同应用的诞生对系统整合的需求日益迫切，集成成了一个热门话题，也成了一个难题。

　　集成技术的三个发展阶段

　　集成技术的发展已经有很多年了，大体经历了以下三个阶段：

　　点对点的集成。早期，由于需要集成的系统比较少，最常见的是两、三个系统之间进行数据交换。这时，企业普遍采用编程的方式来完成系统之间的数据交换任务。这种方式简单，但其最大的问题是缺乏灵活性，每两个系统之间需要进行互访时都要开发一段程序。两三个系统之间的互访尚可以应付，随着系统的增加，其复杂性和工作量成指数级增加。

　　EAI 这种方法是建立一个集中的数据交换平台(这个平台通常由中间件担当)，同时在每个应用系统中安装一个名为Adapter(适配器)的插件。Adapter负责把应用系统的数据翻译为统一规范的格式，发送数据交换平台上，同时也把接受到的数据转换为系统所需的格式。这个平台降低了集成的难度，同时，可扩展性也比较好。不足之处在于，集中的数据交换平台和Adapter的开发都非常复杂，初期投资比较高，具有较高的应用门槛，非一般企业可以承受，而另一方面，由于投资大，用户的期望也非常高，所以很多用户最后对其效果并不满意。几年前，Tibco和Vitria等公司在这方面做了不少工作。

　　基于SOA(Service-OrientedArchitec-ture)的集成。SOA概念的普及给那些徘徊在应用集成大门之外的企业带来了新的希望。SOA通过建立一种统一的架构，使得软件开发人员能快速开发、集成和重用应用。更为重要的是，基于这种软件框架，系统能在业务发生变化之后，动态响应新的需求，快速重新装配各种软件构件和服务。今天基于SOA的集成方法正推动着市场的发展，BEA、IBM、Oracle等大多数供应商也开始转向SOA。

　　分布式SOA基础架构

　　尽管很多供应商提供了基于SOA的集成方法和产品，但最常见的还是基于集成平台的集成方法。这个平台类似于SOA集成服务器，它采用多种集成技术，为其他有需要的应用和服务提供可重用的业务服务。大多数厂商提供的这个平台以企业服务总线(EnterpriseServiceBus，ESB)的形式出现，当然也有一些厂商采用其他形式，比如围绕BPM进行业务流程集成。

　　“尽管与传统的集成方式相比，这种方式向SOA迈出了一大步，也解决了不少实际问题，但这种方式并没有真正体现SOA的分布式的优势。”SOA领域的专家、率先提出分布式SOA基础架构理念的IONA的CTOEricNewcomer说。

　　因为这里的集成本台大多数是从EAI产品演变而来的。它们的主要特征就是由消息总线提供数据格式转换和路由，完成流程自动化和应用适配器的功能。与EAI产品不同的只是，现在的集成服务平台支持服务集成。

　　这种总线式的架构本质上是集中式的SOA架构，它仍然带有传统的EAI产品的弱点。比如，集中式SOA架构会增加成本，限制资源的再利用，降低系统的灵活性，并且有可能形成成本高昂的系统瓶颈。最糟糕的结果是，它很有可能偏离技术中立的原则，把用户绑定在供应商的专有技术上，成为用户取消SOA计划的第一原因。如果SOA架构的灵活性不足以满足用户的各项需求，无疑会导致用户对SOA架构的彻底失望。

　　而SOA本质上应该是分布式，不应该存在有集中的控制点，任何应用只要符合相关规范都可以进入SOA网络进行交互(自然上述集中式的SOA架构也可以作为SOA的一部分)。

　　那么，分布式SOA架构如何来解决集成的问题呢?IONA提出的方法是对那些老系统进行SOA封装，即在每个应用上部署一个小的智能终端，由这个轻量型的插件来完成与SOA网络的通信，而网络中不再需要一个集中的控制平台。IONA的中国区总裁薛志勇认为，这种方式的最大优点是投资小、支持渐进式的部署、技术中立，也不存在瓶颈，更为重要的是，这种方式符合SOA的开放性、分布式的本质。

SOA 和 Web 2.0 有不少共通之处，例如在「边缘」和「中心」的角色关系上，存在着微妙的相似之处。

ZDNet 的 Dion Hinchcliffe 画过一幅很棒的图 ，值得仔细玩味。左手边是用户的所在，常称作网络的边缘 (edge)，而右手边则是大家所共享的网络，在英文中常叫作云 (cloud)。不管是在企业 (Enterprise 2.0)，或消费者领域 (Web 2.0)，位于边缘的用户们，透过各种无所不在的边缘装置 (edge devices) — 桌上型 PC、无线上网的笔记本电脑、PDA、手机、数碼相机、摄像机、录音机，甚至客厅的游戏机、家庭娱乐中心等，与网络中的各种服务作双向交互，主动贡献大量的内容，并与其它用户共享。在这种新环境下生成的内容，近两年来已陆续出现各种名词来形容，包括 User-Generated Content、Consumer-Generated Media（或 Consumer-Generated Content）、Citizen Media、Citizen Journalism 等。

我们如果将服务器端视为中心（”the center” 或说「轴心」”the hub”），那么 IT 的演化史，其实可视为是一系列介于 edge 和 center 之间的钟摆运动。数十年前，大机当道，一切中央集权，edge 端非常寒酸，只有一迭迭喂数据的卡片纸，加上一群没有任何智能的笨终端 “dumb terminals”、调制解调器，和键盘。从 “dumb terminal” 的戏称和当时对键盘器具的称呼 — 远程打字 (teletype)，便约略透露出当时 edge 角色的渺小（Unix 上 tty 的命名由来，正是取自 teletype 中的三个字母）。80 年代，PC 和 LAN 的逐渐兴起，打破了先前中央独霸的权力结构，edge 的重要性开始崛起，透过各式各样的应用，用户的生产力得到激发，企业的信息架构也开始顺应这股力量，C-S computing 开始接掌 IT。90 年代中期，荡到 edge 端的钟摆拉到了极限，两层式 C-S 架构开始出现性能瓶颈，管理等方面的问题也一一浮现，Web 的出现，像场及时雨，带来了三层式架构，某种程度上提供了大机时代中央化和 PC 时代去中央化间的平横，Java、J2EE、.NET 陆续出现，对这样的架构提供支持，在这个现在被称作 “Web 1.0″ 的时代，钟摆往中央回移，edge 端的主角变成了浏览器和 thin-client。

过去几年间，宽带、无线和多媒体，加上各种迷你、能无线上网的数碼器具，带领我们走入无所不在运算 (pervasive computing) 的新环境。在引领风骚的 SOA、On-Demand、Software as a Service (SaaS)、Web 2.0，乃至发酵中的 Enterprise 2.0 纪元，重心拉回 edge，世界被抹平，人人都能发声，人与人的距离从来没这么贴近过；edge 和 center 间的交互作用外，有更多 edge-to-edge 和 peer-to-peer 间的协作。钟摆间权力洗牌的戏曲，正一幕幕上演着。 

SOA 和 Web 2.0 有不少共通之处，例如在「边缘」和「中心」的角色关系上，存在着微妙的相似之处。

ZDNet 的 Dion Hinchcliffe 画过一幅很棒的图 ，值得仔细玩味。左手边是用户的所在，常称作网络的边缘 (edge)，而右手边则是大家所共享的网络，在英文中常叫作云 (cloud)。不管是在企业 (Enterprise 2.0)，或消费者领域 (Web 2.0)，位于边缘的用户们，透过各种无所不在的边缘装置 (edge devices) — 桌上型 PC、无线上网的笔记本电脑、PDA、手机、数碼相机、摄像机、录音机，甚至客厅的游戏机、家庭娱乐中心等，与网络中的各种服务作双向交互，主动贡献大量的内容，并与其它用户共享。在这种新环境下生成的内容，近两年来已陆续出现各种名词来形容，包括 User-Generated Content、Consumer-Generated Media（或 Consumer-Generated Content）、Citizen Media、Citizen Journalism 等。

我们如果将服务器端视为中心（”the center” 或说「轴心」”the hub”），那么 IT 的演化史，其实可视为是一系列介于 edge 和 center 之间的钟摆运动。数十年前，大机当道，一切中央集权，edge 端非常寒酸，只有一迭迭喂数据的卡片纸，加上一群没有任何智能的笨终端 “dumb terminals”、调制解调器，和键盘。从 “dumb terminal” 的戏称和当时对键盘器具的称呼 — 远程打字 (teletype)，便约略透露出当时 edge 角色的渺小（Unix 上 tty 的命名由来，正是取自 teletype 中的三个字母）。80 年代，PC 和 LAN 的逐渐兴起，打破了先前中央独霸的权力结构，edge 的重要性开始崛起，透过各式各样的应用，用户的生产力得到激发，企业的信息架构也开始顺应这股力量，C-S computing 开始接掌 IT。90 年代中期，荡到 edge 端的钟摆拉到了极限，两层式 C-S 架构开始出现性能瓶颈，管理等方面的问题也一一浮现，Web 的出现，像场及时雨，带来了三层式架构，某种程度上提供了大机时代中央化和 PC 时代去中央化间的平横，Java、J2EE、.NET 陆续出现，对这样的架构提供支持，在这个现在被称作 “Web 1.0″ 的时代，钟摆往中央回移，edge 端的主角变成了浏览器和 thin-client。

过去几年间，宽带、无线和多媒体，加上各种迷你、能无线上网的数碼器具，带领我们走入无所不在运算 (pervasive computing) 的新环境。在引领风骚的 SOA、On-Demand、Software as a Service (SaaS)、Web 2.0，乃至发酵中的 Enterprise 2.0 纪元，重心拉回 edge，世界被抹平，人人都能发声，人与人的距离从来没这么贴近过；edge 和 center 间的交互作用外，有更多 edge-to-edge 和 peer-to-peer 间的协作。钟摆间权力洗牌的戏曲，正一幕幕上演着。 

　　一旦完成了逻辑模型，您就有效地定义了一个规范的信息模型。这个模型的定义将完成您的信息模型的初始设计，就意味着您已经有效地开始将数据变成信息。还有最后一步，就是进一步改进您的信息模型：应用程序规范。

　　不是所有的消费应用程序将会直接使用规范的信息模型。应用程序规范为消费应用程序提供一个抽象层来定义它们自己的特定于其自身需求的逻辑模型。

　　应用程序规范封装了消费应用程序需要的额外的信息模型状态和行为，简化了消费应用程序对规范的信息模型资源的使用。由于每个消费应用程序或者一组关联的业务应用程序的应用程序规范都是惟一的，所以不需要在规范的信息模型中包括它们。如果应用程序规范包含更大范围（例如，跨部门或者跨企业），那么它应该成为规范的信息模型的一部分。

　　为SOA参考架构创建数据服务层和为组织定义规范的信息模型是困难的，这些任务实现起来都非常困难，而具有挑战性的任务又很少能赢得什么荣誉：实现起来非常困难，很少能够做到最好。本文所述的方法应该能给您足够的信息去规划、评估和开始设计数据层的SOA转换，并将组织的数据变成信息。在实际当中，SOA参考架构的数据服务层的规划、设计和开发依赖于许多特殊的因素，这些因素特定于您的组织或状况，它们已经超出了本文所讨论的范围。

　　既然我们已经开始在SOA系统中把我们的数据变成信息，那么我们可以考虑把这些信息变成知识。本系列的第二篇也是最后一篇文章“SOA中的数据，第二部分：将信息转换成知识”将介绍这一过程。

　　从第一个选定的资源开始（我建议您首先端到端地制作一个资源，也许不是最高优先级的那个，这允许您使用控制度更高并且便于管理的方式实现数据管理和数据服务层的SDLC过程），对现有的物理方面进行检查。对于数据库或者一组表，考虑来自用户的各种查询、数据库的逻辑存储过程及其触发器、各种具有副作用的操作。这构成了物理数据资源定义和描述。对于信息访问，要使用什么呢？MOM、第三方适配器、专有的集成或者点对点的定制集成？这构成了物理信息资源定义和描述。

　　由于数据服务层是完整的SOA参考架构的一部分，所以应该规定SOA构建块的定义和要求。您的资源的当前状态与SOA RA构建块的目标状态之间很可能存在差距。业务的第一步是引导当前的物理状态尽可能地接近您的SOA构建块目标状态标准。您可能会想起前面讨论的关于SOA参考架构中“服务”的定义和描述。为简单起见，假设您的服务定义要求包含WSDL、SOAP和用XSD定义的文档样式。其它推荐的规范包括 WS-Addressing和XQuery/XPath。有了这个定义，我们需要考虑怎样把关系数据库、XML数据和／或信息访问系统中的表转换或者映射到一组满足构建块服务定义准则的服务上。

　　有许多不同的工具和技术可以映射现有的数据和信息访问资源到图２所示的物理数据层，定义与您的特殊要求和服务定义一致的逻辑服务模型。BEA的 AquaLogic Data Services Platform（ALDSP）是我们的从数据／信息访问资源向SOA构建块（数据服务）转换的实现技术，它为您的SOA参考架构提供了基于标准的、面向服务的数据服务层。

　　一旦您导入了您的物理资源（不考虑它们的接口和实现），您就有了物理的数据服务层（参见图2）。物理的数据服务层中的服务有着一致的外观和表示——即底层的实现细节和通信协议被抽象化和封装，并且从视图中移除（必要时，您仍然可以访问底层），只提供了资源定义（服务定义）和操作的信息。 既然您有了自己的“数据”，下面该定义您的逻辑模型。

　　逻辑建模的目标是抽象、集成、规范和管理一个或多个物理数据服务的集合，可以将这些操作抽象到两个层上：逻辑数据标准化层和逻辑数据集成层，如图2所示，它们也有一组可用的规则：管理规则、数据规则、集成规则和业务规则。

　　在进一步讨论之前，需要注意： ALDSP允许支持您的逻辑抽象设计要求所需的任何逻辑层。这些逻辑层只是面向设计时的，其作用是允许设计和开发人员有效地分离和分层逻辑模型和内容。这些逻辑层不是运行时部署的一部分——也就是说，即使设计时可以有若干逻辑层，但它们并没有对应于运行时的一组间接层。通过平展和优化，它们成为一个运行时层。开发和操作人员能够察看这些运行时工件和优化，并且在认为必要时进行调整。

　　您可以规定一组不同的准则和因素作为逻辑模型层的基础，而不是我在这里所使用的。例如，可以有单独一个层来包含所有的逻辑抽象，也可以有若干个逻辑层。经证明，逻辑层太少可能有限制作用并可能随时间增加了复杂性。至少，您应该规定一组准则来确定逻辑抽象层和它们所包含的内容。

　　例如，您可以有一个逻辑抽象来执行标准化，如图2所示。逻辑数据标准化层允许您“清除”和简化任何复杂的或混乱的信息。改变那些您不直接拥有或负责的现有数据库或者其他系统的物理结构通常也是困难的，或者任何程度的改变都是不可行的。逻辑数据标准化层让您可以重新构建而不必强制改变物理数据层。（如果您需要关于“数据标准化”的更多信息，我建议您用“数据标准化”进行Web搜索，会了解到更多的相关内容和要求。）这个逻辑层提供一个模型设计，当更新或退出直接使用这些数据资源的系统时，它可以用作未来物理数据和信息的模型。逻辑数据服务的目标是提供一个高级共享服务和消费应用程序更加易于使用的、更加易懂的和更加可重用的服务模型。

　　第五步和第六步可以颠倒次序。关键是确保逻辑模型不受当前物理资源的过度约束。换句话说，在逻辑模型将要利用物理数据服务的时候，不要让当前那些物理资源的局限性限制它们，或者对您的整个数据服务层设计施加过度的影响。物理资源是起点，接着是建立更丰富的更多表示形式的模型。

　　规则和规则的处理决定了数据是怎样变成信息的。它们在数据服务层提供了关系、语义和行为。如图2所示，规则分为几类：

1. 管理规则给出利用物理数据层的系统和数据资源的各种要求和/或限制。这可能包括安全性、访问窗口（日期/时间）、缓存，元数据、事务和各种副作用或需要执行的辅助操作（例如，登录和审计）。
2. 数据规则提供验证、一致性、反复确认和其它与数据准确性和一致性相关的规则。它们也能在物理模型或逻辑模型中提供缓存管理和其它的副作用。数据规则可作用于表级别、行级别、列级别或字段级别。
3. 集成规则提供跨逻辑数据层和物理数据层的映射和一致性。集成映射更高一级的抽象到对应的逻辑层或物理层。例如，一个位于更高一级的抽象的用户ID是新的规范的数据模型的一部分，这个模型转换自/被转换到几个底层的来自若干用户数据库和/或后端系统的本地格式。集成规则位于系统和/或数据库层。
4. 业务规则提供有意义的业务关系和一些业务逻辑，即行为。面向对象编程考虑的是封装在模型对象中的状态和行为。在数据服务中，业务规则扮演一个类似行为的角色。业务规则在数据模型层捕捉业务处理逻辑。这个逻辑是业务实体的恰当定义的基础，也是这个业务实体与其他业务实体的关系的基础，这些实体的关系是跨所有应用的业务实体固有的，例如，在一个企业级的或至少一个部门级的范围里。在这些规则中，有些是在规范的模型中定义的，而另外一些是在应用程序规范模型中定义的。

　　第一步是确定数据内容，即您您当前的数据和信息系统访问资源。您您的组织拥有哪些数据和信息资源（本文后面，简称为“资源”）？例如，数据库、信息资源和应用程序（指遗留系统、记录系统）。对于每一个资源，您需要了解支撑元数据，如文档、历史、技术／工具／产品／平台、版本、所有权／管理部门、位置、安全性和访问机制。根据资源及其元数据的数量，您可能想考虑某些元数据目录或者储存库，也可能是一个或一组标准模板，能够以一致的方式获取元信息并允许进行检索。

　　一旦您已经开始创建资源目录，第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分，它获取关于资源的使用者、使用时间、使用频率、使用目的（例如，CRUD）和使用地点（即，访问类型——成批的、在线的、实时的或报告式的）的信息。了解用户为何使用某个特殊的资源也是很重要的，这将有助于任务优化，而且为新的数据模型提出要求。

　　一旦您得到了使用某个资源的每个已知用户的情况——“使用者、使用内容、使用地点、使用时间、如何使用以及为什么使用”，您就可以开始分析和形成所有资源用户的概括。这样做的目的是要找到在现有资源向SOA构建块转换的过程中进行简化和重用的可能。它们包括，但不限于，那些面向服务的、自描述的和可发现的资源，这些资源能够便捷地应用于采用开放的、公共的、行业和／或企业标准的SOA生态系统。

　　在这组SOA构建块中包含的一个定义是您的服务定义。要使用什么样的标准、规格和版本呢？例如，可能会要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一个的特定版本，而其它的则可以是可选项／推荐项。数据和信息访问资源很可能会采用与基本SOA构建块定义（即服务）一致的格式。（使用您喜欢的搜索引擎搜索“Service Identification”和“Service Definition”这两个主题可以找到这方面的内容。）

　　由于每个编目好的资源已经以某种方式存在，所以应该具有预测的或者实际的产品使用统计信息，包括事务规模、模式、并发用户、可靠性、可用性、可伸缩性和性能（RASP）等方面的信息。

　　使用信息也很好地表明了业务和IT的价值和优先权。这个基线信息用来定义一组度量，这组度量将构成服务级别协议（SLA）并允许目标定义和历史跟踪。为了支持 SOA的数据服务层，要规划软硬件的大小和容量，在这一过程中，度量和当前产品信息的价值是无法估量的。确定您的SLA是双向的，即服务提供者针对每个用户定义SLA术语、条件和处罚；用户应该遵守这个协议。

　　例如，一个协议声明用户A每天（这里指一天24小时，从午夜GMT12:00开始计算）可以在DataServiceXYZ（资源/服务的提供者）上执行最多100个get()请求，而每个请求的响应时间将≤2秒。如果用户A发出了超过协议规定的最大数量的get()请求，那么服务提供者能够根据协议规定对其处罚。对服务提供者也有相应的要求。如果用户A的请求数量不大于规定的最大值，则服务提供者必须提供≤2秒的响应时间，否则就要面对协议规定的相应的处罚。

　　度量和SLA定义约定的要求和规则，这些要求和规则影响每个资源的价值、目标和规模的基础。跟踪并重用您的基线度量、SLA，建立一个成本和效益模型。

　　有了上述的一定程度的一组已获取信息，应该可以在所有其它的编目好的资源上下文中开始评价每个资源——即，指定每个资源的优先权。一个好的策略是拥有最少3个、最多10个优先权级别（过多了）；小于3个不够，多于10个难于管理。

　　优先权分配的目的是帮助识别在应用上最重要的资源和所支持的业务功能的价值。您应该设计一组度量（包括第三步中的那些）和定义来根据经验比较和评价每个资源，以确定其优先级。分配资源优先级将有助于确定项目的合理起点、潜在的∵业务/IT赞助和相关的业务价值。

　　当这些资源向SOA构建块转换时，使用上述的所有信息能够建立、记录和跟踪每个资源的“当前使用”快照。对于剩下的几个步骤，应该在所有编目好的资源中选择那些被指定为最高优先级的资源。实际数量的选择要根据您的风险评估、优先权评价、业务/IT目标、资源以及其它类似的因素来进行。

SOA中数据的价值

　　各种组织对于定义和细化自身SOA参考架构（SOA RA）有着不同的动机、出发点和优先次序，向SOA转换时可能会发生变化。规划设计SOA RA的完整方法应该包括数据服务（data services）层。本文采用数据服务层这一术语包含数据和信息访问服务。

　　如果在SOA RA中没有企业数据服务层，则其后的业务项目将被迫开发成特定于每一个应用程序的专用“点”或者一次性解决方案。几乎没有通用性，几乎没有共享的服务定义、重用和一致性，规范的数据模型的定义也会变得难懂。如果认识到SOA的优点，则会逐渐认识到它的众多优势。我们很可能都看到过这样的统计信息：企业应用程序软件开发的５０％到８０％的项目资源消耗在数据集成任务上。这一“事实”应该足以确定在任何SOA实现中数据服务层是必不可少的一部分。企业软件解决方案的主要设计目标是数据处理，结合这一概念， SOA 中数据的价值应该非常明显。

　　图１展示了BEA的SOA参考架构较高层次上的概念，它说明了位于上面的几个层。注意，数据服务层位于第一个区域，这表明它在SOA RA中的重要性。

关于数据访问和连通性服务的注释

　　访问数据资源的数据访问服务通常被总称为企业信息系统（EIS），也叫数据库和文件系统。它们可以是遗留系统、记录系统，包装好的商业应用程序、用户、伙伴、第三方应用程序和服务，以及Web services。它们的共同之处是向其他应用程序提供数据和/或信息（在本文中的意思是行为）。因此，这些应用程序在通过数据访问层被访问时就是数据的另一种形式或另一个数据源。在一个更高的抽象层上，数据服务与消费应用程序看上去一样，这是SOA RA的数据服务层的主要目标（标准化/一致性）之一。公开的接口与一个或多个数据库、表、后台、遗留系统、快速收缩的系统和/或外部系统交互，这是数据服务层封装的一个实现细节。

　　连通性服务以基于标准的方式将应用程序和数据库公开为应用程序服务。

将数据转换成信息

　　假设您的组织正计划向 SOA转换。 SOA RA的所有层和所有方面（见图1）的研究和规划已经开始，您的任务是数据服务层的实现。现在该怎么办？想想下面的几个步骤：

1. 盘点现有的数据和系统访问资源
2. 确定依赖关系矩阵
3. 建立基线度量/SLA
4. 设置资源优先级
5. 执行数据建模
6. 创建逻辑建模
7. 设置信息规则
8. 建立应用程序规范

　　图2是SOA RA数据服务的一组可能的内部抽象层示例，这里将采用我们的9个步骤来映射这些需求和性能。

为什么使用数据？

　　数据是普遍存在的（data是复数；datum是单数，尽管“data”能够同时使用单数和复数）。大部分 IT工作的核心就是收集、分发和管理数据，并且当需要数据的时候、在需要数据的地方、以要求的方式为需要数据的人（拥有正确的权限）提供数据。有些人可能会想起在IT（“信息技术”）这一术语出现之前，多数的企业把他们的“计算机部门”及其工作称为DP或“数据处理”。

　　在过去、现在和可预见的将来，数据是所有技术浪潮中一个不变的常量。同样的数据，过去由（很可能仍然是）大型机处理，现在也很可能已经由一个或多个的客户机-服务器、CORBA/DCOM、 Java EE、.NET、 Web services、SOA和Web 2.0来完成。随着时间的流逝，数据的存储、格式和传输可能已经改变，数据的处理方式可能已经改变，但是“数据”依然保留（而且还在增加）。其实，所有工业技术浪潮有着一个相同点：它们都是新的或者改良的数据处理方法。数据就是基础。如果您您也认为数据是企业解决方案的基础，则由此得出结论：数据（以及数据建模/管理）也是SOA（与Web 2.0）的企业架构需要优先考虑的事情。

数据是什么？

　　让我们先看一下字典中“数据”的定义，然后对其进行补充。就本文而言，数据是基本的、最小的，或者拥有一些结构、关系和状态的“信息”片断的底层集合，但不包括行为。例如，一个包含街道地址、城市等数据列的地址表是数据。就像一个用户表中的地址定义。数据是结构和状态，但没有行为。数据是构成信息的原始的构建材料。数据是信息的前提。

信息是什么？

　　让我们再看一下信息的定义，然后对其进行补充。就本文而言，信息是数据的集合，是提供附加的形式、基本关系、语法和语义上下文的基本逻辑——也就是说，它是状态和核心模型行为。例如，确保ZIP码有效并与城市一致。信息是数据的扩展，它向和域（语法和语义）上下文一致的行为模型提供映射或关联数据、定义逻辑的能力。信息基于数据，需要数据。换句话说，信息表示封装了状态（数据）和行为（逻辑）的实体（主体，对象）。可以认为信息类似于面向对象编程中的模型类的实例，这个实例包含用于保持状态的数据成员（实例变量）和提供（模型）行为的方法。

　　本文是关于“SOA中的数据：将数据转换成知识”的两篇系列文章的第一篇。本文通过SOA参考架构（SOA RA）的定义介绍了在SOA中从数据到信息的转换方法，它构成了完整SOA转换方案的一部分，并且还讲述了一个企业SOA的实现。这个系列的第二部分描述了在SOA中从信息到知识的转换方法，这是对完整SOA转换方案的一个扩展，并且还描述了一个企业SOA RA的很有价值的扩充。

小结 Web 2.0

Web 2.0 是一个新事物吗？不是，它是 Web 连续演变过程中的一环而已，是一个用来表示人们使用 Web 的方式所发生的重要变化的符号。这些变化背后，是一系列设计原则和模式，是一组基本特征，是支持这些设计原则和特征的技术选择和编程模型。它们以简单性、易用性、社区与参与架构所支持的网络效应和用户增值带来的群众智慧，以及软件即服务的交付模式为基本指向，奠定了一个基于 Web 实现的 SOA 架构风格，即 Web Oriented Architecture。WOA 跟 SOA 相辅相成，各自适用不同的情景，WOA 将 SOA 扩展到 Web，又将 Web 引入 SOA，使得 SOA 的服务和数据资产，可以被更多的人，以更加简单、易用的方式使用起来。

向前，向前，再向前：从 Web 2.0 到 Web 3.0

Web 2.0 只是 Web 的一个发展阶段，它还在成熟的过程中，不过 Web 的发展是连续的，人们已经开始在谈论 Web 3.0，也就是如何将因特网转化为一个以 3D 为基础的虚拟世界，如何利用人工智能，如何将互联网转化为真正的语义网。这些发展都是非常激动人心的，它们的发展成果将像 Web 2.0 一样，给我们的商业、社会和技术带来深远的影响。让我们拭目以待，积极参与和推动吧。

Web 2.0 成功的核心模式

Web 2.0 和过去的 Web 1.0 之间有什么不同？讨论这个话题，最权威的莫过于 Tim O'Reilly 所写的“什么是 Web 2.0？”，我在这里拾人牙慧，概述一下我的理解。

Web 的演变是持续进行的，Web 就像是有生命的实体，在不断生长，所以当我们说 Web 2.0 和 Web 1.0 之间的差别时，是一个相对静态的阶段性观点，而不是绝对的。

如前所述，Web 2.0 是指互联网泡沫之后，人们使用 Web 的方式的巨大变化，开发人员、最终用户和商家，都在不断地实践新的方法。几年过去，他们取得了很多了不起的成果，缔造了很多成功的 Web 2.0 公司，从 Google、Salesforce、MySpace、Flickr、Delicious、YouTube、Linkedin 到今天十分火爆的 Facebook，具有 Web 2.0 特征的公司，风起云涌。如何定义 Web 2.0 不重要，重要的是 Web 2.0 背后的模式和原则，这些模式对于 Web 2.0 的成功至关重要。

Web 2.0 具有八个核心模式，它们分别是：

1. 群众智慧（Collective Intelligence）

   建立一个参与架构，借助网络效应和算法，使得软件随着使用的人越来越多而变得越来越好。

2. 数据，下一个“Intel Inside”

   利用独特、难以复制的数据源，成为这个时代的“Intel Inside”，其中，数据变得跟功能一样重要，成为核心竞争能力。

3. “复合”创新

   建立一个平台，通过数据和服务的组合，来创造新的市场和机会。

4. 丰富用户体验

   超越传统的 Web 页面模式，让在线应用拥有桌面应用一样的丰富用户体验。

5. 支持多种设备

   支持各种连接到因特网的设备，为用户提供无所不在、无缝的在线体验。

6. 软件即服务（Software as a Services，SaaS），和永久试验版（Perpetual Beta）

   改变了传统软件开发和使用的模式，转向永久在线、持续更新、软件即服务的模式。

7. 利用长尾

   借助因特网带来的接触极大规模客户的能力以及极低成本的营销方式，来获得细分的“利基”（niche）市场的利润。

8. 轻量级模型和低成本优势的可扩充能力

   利用轻量级的商业模型和软件开发模式，来快速、廉价地构造产品和服务。

以上几个模式，分别关注不同方面，但是它们由如下几个 Web 2.0 的特质而相互关联起来：

1. 大规模互连

   今天我们从过去一对多的发布和通信，转向多对多的连接，网络效应使得边际同核心一样重要，颠覆着旧的通信、发布、分发和聚合模式。

2. 去中心化

   这种大规模互联，也颠覆着传统的控制和权力结构，带来更大程度的去中心化。从全球信息流动，营销，到新产品设计，这种发自底层的草根力量， 都在“叫板”来自权力阶层的声音。系统更多地从通过边沿的拉动来生长，而不是借助核心的推动向外生长。

3. 以用户为中心

   网络效应给予用户前所未有的力量，他们参与、对话、协作，最终产生巨大的影响。消费者可以说话、交流和讨论他们的经验，他们拥有控制权，积极主动地影响着产品的方向，同时也对那些积极应对的公司报以忠诚和口口相传的口碑营销。

4. 开放

   这种开放性，是以因特网的开放技术标准为基础的，但很快地演进到一个由开放应用所构成的生态系统，这些应用建构在开放数据、开放 API 和可重用的组件之上。开放，还意味着超越技术层次的更大程度的透明性，如公司对外沟通，共享知识产权、产品的开发过程等。

5. 轻量级

   软件由小团队使用敏捷方法设计和开发，使用简单数据格式和协议，采用运行开销小的平台和框架，应用和服务部署简易，商业上力图保持低的投资和成本，营销上利用简单的消费者之间的口口相传来形成病毒式传播。

6. 自然浮现

   不是依靠预先完整定义好的应用结构，而是让应用的结构和行为随着用户的实际使用而灵活适应和自然演变；成功来自合作，而不是控制。

这些特质，Web 2.0 的应用体现得越来越多，由这样的应用所构成的应用生态系统，具备了将大规模个性化的信息和服务带给极大规模普通人的潜力。

首先，Web 2.0 带来了“简单性”，也就是软件容易使用、易于组合和混用、易于扩展。这对传统软件，尤其是企业软件来说是很不简单的一个改变，因为企业软件过去高高在上，往往需要花很大的力气来集成，需要专业人员来维护和扩展，用户也需要经过训练才能很好地使用软件。

其次，Web 2.0 带来了“软件即服务”的观念，用户付费即用，无需操心开发、安装、部署和运营维护，开发的过程也极大程度地由用户驱动，用户需求的反馈非常及时。

还有就是社区和用户增值，也就是用户不只是纯粹的消费者，他们还是生产者，系统利用他们贡献的数据（比如 标签、意见）和行为，通过网络效应和算法，获得“群众智慧”，利用它们构成的社会网络，获得口碑相传。

这些设计原则和模式，被人们总结为 Web Oriented Architecture，简称 WOA。WOA 与时下企业软件正流行的 SOA，采用同样的设计哲学和理念，也是以服务为中心的架构模式，只是它主要采用来自 Web 的概念和技术来构建服务架构：

1. 使用 REST 来表示和访问服务，每个网络资源（或者说实体）可以用一个 URL 来唯一地表示和确定，其上只有 GET、POST、PUT 和 DELETE 四个操作；

2. 数据被编码成 XML 文档或者 ATOM Feed 以用来交换数据，在服务器和浏览器之间，也可以使用 JSON 编码的文档；

3. 基于 AJAX 的丰富用户体验；

Web 2.0 的编程模型正在形成，它包括下面几个重要部分。

1. 一个轻量级的编程模型，就是使用 REST 和 Feed，有时也考虑 SOAP，比如 Amazon 既提供 REST 也提供 SOAP，社区里使用 REST 的比例要更高一些。

2. 数据服务，数据服务将不同来源的数据结合、过滤、转换、消除不一致性，提供必要的质量保证，比如数据一致性、安全、访问控制和数据管理。

3. 提供丰富用户体验的因特网和 Web 应用，结合使用 AJAX、HTML、XHTML、CSS、DOM、XML 和 XSLT，利用 XMLHttpRequest 和 JavaScript 将一切绑定在一起，使得在线应用提供如同桌面一样的丰富用户体验。

4. 可“混用”（Mash-able）的资产，将内容和 IT 资产变成可以灵活重组的资产，利用互联网轻量级的内容聚合方法来建立复合 Web 应用。

5. 企业 Mashup 平台，让那些需要内容和信息的人们，可以轻松的聚合和重组来自不同地方的内容和数据，快速满足他们因情景而不断变化的需求。

WOA 将企业 SOA 的服务，带给更多的人，带给那些对 IT 不是太了解的普通用户和业务部门的雇员（Line of business persons）。

首先，WOA 将企业 SOA 提供的服务提供到 Web 上，将企业的服务延伸到了全球范围，并且简化了：

1. 开发
2. 服务组和
3. 部署和可访问能力
4. 质量保证：性能、可伸缩性和安全性

反过来，企业在将自己的 SOA 服务扩展到 Web 的同时，也在使用来自 Web 的服务和 Feeds。但是二者不能相互取代，很多企业内部的核心流程和数据资产，所要求的企业级安全性、可靠性、可管理能力等，是 WOA 所不能提供的。所以我们说，Web 2.0 是 SOA 的扩展，二者相辅相成，但并非竞争和取代的关系。Web 2.0 提供的丰富用户体验，极度的简单性和易用性，让 SOA 所提供的核心业务服务和数据，能够被更多的普通用户和业务人员，以更简单、更富于个性化的新的方式使用和组合。

关于 Web

Web 是一个生长着的、开放的、动态的分布式系统。

Web 始于1989 年，当时英国科学家 Tim Berners-Lee 和比利时人 Robert Cailliau 在欧洲粒子物理研究所（European Organization for Nuclear Research ，简称 CERN）共同提议和构造了在因特网（Internet）上使用超文本来发布、分享和管理信息。Web 是 World Wide Web，即互联网的简称，是一个相互链接在一起、通过 Web 浏览器来访问的超文本文档系统。浏览器里看到的网页，可能包含文本、图像以及其它的多媒体，通过文档之间的超链接，可以从一个网页浏览到其它网页。

Web 逐渐在科研和大学中流行起来，然后走向大众，变成人们生活、娱乐和工作中的基本工具。在这个发展过程中，Web 拥有了最大量的用户，人们随时在使用它，把它变成了最大的分布式计算系统，基于最广为接受的开放标准，时时新、日日新，成为一个动态生长着的开放系统。

Web 2.0 趋势

什么是 Web 2.0？ 今天的 Web 跟过去如此不同，所以叫做 Web 2.0，意指一个社会、商业、技术三相融合的发展阶段。

Web 2.0，是由 O’Reilly 公司在 2003 年造的一个词，2004 年召开 Web 2.0 大会之后，这个词就流行起来，意指基于 Web 的下一代社区和托管服务，比如社会网络、维基百科、大众分类等等，帮助 Web 用户协作和分享。

虽然，2.0 似乎在暗示 Web 的升级换代，实际上是指软件开发人员和最终用户使用互联网平台的方式的变化。而在商业上，关于如何才能在这样的一个新平台上获得成功的探索，也从来没有停止过。

那么，这些变化都是什么？核心推动力是什么？

这种使用互联网的方式的变化，与过去多年来快速发展的宽带化、Web 用户规模的快速增长、用户的参与热情，都密不可分。 大规模 的 普通用户 需要更好用、更个性化、更加以他们为中心、更多样的内容、服务和 应用 ，这就是互联网发展的第一推动力。而对于开发者而言，如何在 Web 平台上快速、便宜地满足这样的需求，推动着他们探索和实践更好的用户体验、更加轻量级的编程模式、软件如何作为服务来运营并提供给用户；与此同时，围绕着如何利用这样大规模的用户群体自己来创造、贡献和共享价值，开发者们又开始思考和探索激活网络效应、群众智慧的参与架构和社会计算模式。商家在经历了上一次互联网泡沫之后，也不断的尝试新的、成功的商业模式，即如何让相互协作和分享的用户口碑相传来病毒式地营销，如何利用这种用户社区的传播和推荐能力来开拓大规模的个性化服务，从大规模单一市场转向选择性极大并丰富的多样化市场，即长尾经济。

技术、商业和社会三种因素融合式地共同发展，相互推动，经过几年全球范围的尝试和实践，新的技术范型、商业模式和生活方式不断涌现，Web 变得更加开放、动态，社区也更加去中心化，人们却又能够更加紧密地协作和分享，内容、服务和应用更加的多样化和个性化，商业模式也逐渐走向如何满足大规模的小众需求。

　　近年来，随着信息化建设的总体思路进一步明确，应用系统建设稳步推进，信息应用水平不断提高，信息化基础建设快速发展，河南省国税局按照“统筹规划、统一标准，突出重点、分步实施，整合资源、讲求实效，加强管理、保证安全”的原则和一体化建设要求，以金税三期建设思路为指导，加快税收管理信息系统建设，强化信息应用，创新管理方式，为实施科学化、精细化管理提供有力依托，促进税收事业健康发展。

　　SOA(面向服务的体系结构)是一种 IT 体系结构样式，支持将业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全存在于一个地方，也可能分散于各地且采用不同的技术，通过对来自各地的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使业务能够适应不断变化的情况和需求。

　　这些服务是自包含的，具有定义良好的接口，允许这些服务的用户(客户机或使用者)了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库(甚至不一定绑定到特定的基础设施)。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。所有交互都是基于“服务契约”进行的;服务契约用于定义服务提供者和客户机之间的交互。通常，将通过创建“基于消息的”系统来实现此目标。

　　SOA对需要使用信息技术解决关键业务问题的企业(包括希望减少冗余架构、创建跨客户和员工系统的公共业务接口的企业;需要基于角色和工作流对用户提供个性化信息的业务的企业;希望通过Internet实现跨区销售、升级销售和经由移动设备的访问来提升客户服务的组织)很有价值。从业务的角度来说，面向服务的体系结构的重点在于开发能帮助完成业务任务的技术，而不是通过技术约束来规定行动。

　　面向服务的体系结构基于实际活动或业务服务进行组织，而不是形成不同的信息竖井。通过实现 SOA，可以带来大量好处，包括以下各个方面：

　　(1)更高的业务和 IT 一致性

　　(2)基于组件的系统

　　(3)松散耦合的组件和系统

　　(4)基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作

　　(5)动态构建的按需应用程序

　　(6)更高的代码重用率

　　(7)更好地标准化整个业务流程

　　(8)更易于集中企业控制

　　3、数据挖掘

　　数据挖掘(Data Mining)就是从大量的数据中抽取出潜在的、不为人知的有用信息、模式和趋势，是一种更深层次的数据分析。这个定义包括好几层含义：数据源必须是真实的、大量的;发现的是用户感兴趣的知识;发现的知识要可接受、可理解、可运用。

　　数据是形成知识的源泉，原始数据可以是结构化的，如关系数据库中的数据;也可以是半结构化的，如文本、图形和图像数据;甚至是分布在网络上的异构型数据。方法可以是数学的，也可以是非数学的;可以是演绎的，也可以是归纳的。发现的知识可以被用于信息管理，查询优化，决策支持和过程控制等，还可以用于数据自身的维护。因此，数据挖掘是一门交叉学科，它把人们对数据的应用从低层次的简单查询，提升到从数据中挖掘知识，提供决策支持。在这种需求牵引下，汇聚了不同领域的研究者，尤其是数据库技术、人工智能技术、数理统计、可视化技术、并行计算等方面的学者和工程技术人员，投身到数据挖掘这一新兴的研究领域，形成新的技术热点。

　　数据挖掘可按以下步骤实施：

　　(1)定义问题

　　该步骤包括分析业务需求，定义问题的范围，定义计算模型所使用的度量，以及定义数据挖掘项目的最终目标。

　　(2)准备数据

　　准备数据就是合并和清除定义问题步骤中标识的数据，数据可以分散在不同的地方并以不同的格式存储，或者可能包含缺陷项或缺少项之类的不一致性。

　　(3)浏览数据

　　浏览数据是为了了解数据，以便在创建模型时作出正确的决策。浏览技术包括计算最大值和最小值，计算平均偏差和标准偏差，以及查看数据的分布。浏览完数据之后，便可确定数据集是否包含缺陷数据，然后制订纠正这些问题的策略。

　　(4)生成挖掘模型

　　在生成模型之前，必须随机将已准备的数据分离到单独的定型数据集和测试数据集。使用定型数据集生成模型并通过创建预测查询来测试数据集测试模型的准确性。您将使用从浏览数据步骤中获得的知识来帮助定义和创建挖掘模型。模型通常包含多个输入列、一个标识列以及一个可预测列。定义完挖掘模型的结构之后，需要对其进行处理，使用说明模型的模式来填充空结构。这称为“定型”模型。模式通过利用数学算法计算原始数据而得。

　　4、SOA与数据挖掘在税务系统应用

　　4.1　SOA是实施数据省局集中，推进信息资源整合，奠定数据挖掘的基础

　　SOA基础架构包括三层关键结构，最底层是数据层，主要是高效组织的结构化数据;中间层是集成工具，能够将底层数据的异构和分布结构屏蔽，并无逢内嵌到中间层，提供清晰明确的统一视图和接口;最上层是应用工具，以数据管理为核心，控制非结构化的内容，提供用户所需的信息和服务。

　　如果基层税务部门提供的数据不真实，或者不全面，税务部门就难以提供准确的数据进行分析决策。用正确的方法去分析错误的数据，显然不能得出正确的结论。另一方面分散的数据也不利于数据挖掘，而实施SOA的一个关键就是高效组织的结构化数据。

　　为了避免出现这一局面，从2006年起，税务系统开始实施税收数据的省级集中。这样，省局就可以直接掌握基层税收征管数据，而基层就不能修改软件或数据库中的数据，这为省局能够直接掌握基层的数据提供了条件。

　　截至2006年上半年，全国共有31个国税局推广应用了总局统一的综合征管信息系统，部分地税局也在全省范围内统一应用了自行开发的综合征管软件。相关数据已实现了省级集中，31个省国税局征管数据已集中到总局，目前总局已有十大类涉税数据。

　　4.2 数据挖掘是税务信息化的核心

　　数据集中使省局、总局集中了大量的涉税原始信息，较好地解决了税务机关上下级之间信息不对称的问题，对解决微观领域中税务机关与纳税人之间信息不对称的问题也有较大的帮助。数据集中后，用于开展税收管理、深化税收分析等的信息资源得以大大增加：横向上从入库数、应征数扩大到企业基本信息、纳税申报以至部分生产经营和财务指标;纵向上税收数据的颗粒度大大缩小，可以很快聚焦到最原始的微观领域数据来研究问题。同时，数据集中也使分析的效率得到空前提高。

　　数据集中使得海量的税款征收信息流汇集到了税收管理信息系统。通过SOA技术整合信息资源，建立标准统一、内容完整、信息真实的税收经济数据库。一是税款的应征、入库、欠税、缓税、减免税等数据;二是企业纳税申报的有关数据，包括纳税申报表及附表中的有关数据，如销售收入、利润、增值税销项税金、进项税金等;三是主要行业、企业的生产经营指标，如重要产品产销量、价格、库存数据等等;四是有关宏观经济数据，如GDP、工业增加值、投资、消费、进出口等主要经济数据。

　　目前河南国税自行开发的电子税源档案全面采集或抽取现有业务系统(税收征管信息系统(CTAIS)、金税工程、出口退税、纳税评估、电子申报等)中的企业涉税信息和各类财务报表数据，经过加工处理和规划存储，建成全省统一的税收业务综合数据库。与此同时，这套系统整合了已有的税务监控、查询分析、报表管理等软件，开发形成集一户式查询、业务考核、报表管理、税负查询、精细化管理和各类业务查询于一身的综合性查询分析应用软件。

　　5、结束语

　　数据挖掘加强了税源信息综合应用，夯实税收征管基础，提高了各项税收政策的执行力，全面推动税收管理的科学化、精细化。SOA适应数据集中分析应用需要，创新税务管理方式，不断完善税务管理机制。

总结：SOA 角色及其对您的团队的意义

本文讨论的关键词是培训。当您决定进行 SOA 项目时，需要仔细考虑团队人员的当前角色，并确保通过培训、指导和调整试验及错误周期来帮助他们准备好进行其在 SOA 中的工作。

　　关键词　SOA　数据挖掘　整合　管理　信息化

开发人员的角色

在传统 IT 小组中，开发人员通常负责应用程序的一个片段。这些片段可以由功能（如注册中心或报告模块）或技术（如 JavaServer Pages® [JSP]、Enterprise JavaBeans [EJB]、数据库层等等）确定。

由于 SOA 团队通常采用较短的开发周期，所以按技术对开发人员进行划分并不实际。因此，将按功能划分的开发团队转变到新的 SOA 开发人员角色更为容易一些。

成功的 SOA 开发人员将能同时理解业务流程和功能。他们会恰当构建所需的服务来满足业务流程的需求。越来越重要的是，要执行用于错误处理、跟踪/审核、数据转换和安全性的良好设计原则，并确保将其加入到任何服务代码中。由于 SOA 的核心原则之一是重用，所以开发人员必须放弃传统开发人员希望构建一切的想法。如果某个方面的服务已经存在，请使用这个服务——而不要自己从头构建。

由于 Web 服务的技术发展并有大量有关该技术的参考材料可供使用，因此可以说开发人员已经“全副武装”，能充分胜任其在新 SOA 环境中的工作了。

业务分析人员的角色

业务分析人员可能是最难得到正确认识的一个角色。作为技术人员兼架构师，我倾向于将架构师视为最关键的 SOA 团队成员。不过，基于经验和最慎重的考虑，我必须指出，作为 SOA 团队中的一员，实际上业务分析人员的工作变化最大。无论开发环境如何，业务分析人员都执行两个主要职能：

• 与执行人员和策略级的用户沟通，以了解其对系统的要求。
• 与技术团队成员沟通，以将确定的要求转换为能进行编码和测试的技术规范。

在 SO

业务分析人员的角色

业务分析人员可能是最难得到正确认识的一个角色。作为技术人员兼架构师，我倾向于将架构师视为最关键的 SOA 团队成员。不过，基于经验和最慎重的考虑，我必须指出，作为 SOA 团队中的一员，实际上业务分析人员的工作变化最大。无论开发环境如何，业务分析人员都执行两个主要职能：

• 与执行人员和策略级的用户沟通，以了解其对系统的要求。
• 与技术团队成员沟通，以将确定的要求转换为能进行编码和测试的技术规范。

在 SOA 环境中，业务分析人员还有两项新职能：

• 与整个开发团队合作，让他们开始以服务 的方式思考问题。（他们需要何种服务来进行其工作？已经存在哪些服务可供使用或在调整后进行使用？如此等等。）
• 与技术团队合作，以设计和构建必要的服务，可能会利用已经存在的现有服务。

无论喜欢与否，在很多企业中，由于组织使用的技术的局限性，业务分析人员通常会不断更改相关要求。这个问题可能并不能得到消除，但在 SOA 环境中，业务分析人员进行服务设计的空间肯定更大，而不用过多地担心技术。

A 环境中，业务分析人员还有两项新职能：

• 与整个开发团队合作，让他们开始以服务 的方式思考问题。（他们需要何种服务来进行其工作？已经存在哪些服务可供使用或在调整后进行使用？如此等等。）
• 与技术团队合作，以设计和构建必要的服务，可能会利用已经存在的现有服务。

无论喜欢与否，在很多企业中，由于组织使用的技术的局限性，业务分析人员通常会不断更改相关要求。这个问题可能并不能得到消除，但在 SOA 环境中，业务分析人员进行服务设计的空间肯定更大，而不用过多地担心技术。

项目经理的角色

SOA 环境中的项目经理的角色与传统 IT 环境中的项目经理之间的主要差异在于项目生命周期。无论 SOA 团队采用何种方法（IBM Rational® Unified Process (RUP)、瀑布式、敏捷方法），项目经理通常都需要为每个服务计划较短的交付周期。他们与业务用户和不同服务使用者一起定义服务水平协议 (SLA)。此外，他们必须与多个 IT 小组（如基础设施支持小组）共同确保这些 SLA 是可以实现的。

项目经理在服务运行时进行协调和跟踪方面的角色比跟踪日常服务交付更为重要。不过，由于周期较短，这个工作相对较为容易一些。

趋向采用 SOA

软件开发领域的主要发展趋势是从传统软件体系结构过渡到面向服务的体系结构 (SOA)。在传统软件体系结构中，将项目视为单个新应用程序的交付。在 SOA 中，将项目视为集成服务的交付——一些是新建的，一些是现有的。无论其规模和预算如何，几乎所有信息技术（Information Technology，IT）部门当前都在进行过渡到 SOA 的工作。您可能已经读过多篇关于 SOA 采用、成熟度模型和实现的文章了。本文将描述在组织采用 SOA 或过渡到更高的 SOA 成熟度水平的过程中，您的 IT 团队成员中所需的一组新角色及其各自的职责。

在形成 SOA 团队时，最大的范式转换是从组合应用程序交付过渡到服务交付。传统软件开发人员通常构建应用程序中的一个模块，或典型的三层体系结构中的单个层的一部分。开发人员的一个例子就是在模型-视图-控制器（Model-View-Controller，MVC）体系结构中负责控制器或模型层的人员。在 SOA 环境中，这些开发人员现在负责服务实现。他们并不需要知道何时、如何或为什么调用服务以及谁调用服务。他们所关心的就是，服务进行什么工作以及需要符合什么样的服务水平协议（Service Level Agreement，SLA）。

为了进行此范式转换，您需要形成完整的 SOA 团队，其中的每个角色的职责与传统软件开发团队中的相同角色略有不同。本文将说明 SOA 团队中以下角色的情况：

• 架构师
• 开发人员
• 业务分析人员
• 项目经理

在典型的 IT 组织中还包括多个其他角色，包括基础设施支持、数据库支持、安全性等等。不过，了解了这些主要角色如何改变后，您就能够对其他角色进行调整，以与其匹配。

理解架构师的角色

在较大的组织中，通常有两个体系结构小组。企业体系结构小组定义组织内的每个应用程序小组都必须遵循的控制策略、最佳实践和过程。应用程序体系结构小组负责其特定应用程序的体系结构，确保体系结构能够支持当前和将来的业务需求。

企业架构师

在 SOA 组织中，企业架构师的角色是推动和促进 SOA 的采用。他们需要帮助应用程序架构师和各个开发小组理解 SOA 的基础知识并将业务需求转换为有意义的服务，以便这些小组进行实现和公开。

仅由您自己的应用程序或业务流程使用的服务几乎没有价值。企业架构师需要确保所有应用程序架构师定期讨论其项目，以确定他们可以公开或使用的服务。在不能重用现有服务的情况下，企业架构师还需要确保充分利用构建新服务的每个机会。促进对现有服务的重用肯定比编写新服务具有更高的优先级。最后，他们必须确认服务是在可靠的技术之上构建的，且能够满足所确立的 SLA。

企业架构师负责定义测定和跟踪 SLA 的机制。他们定义有关控制、安全性、灾难恢复等等的策略和过程。他们通常是涉及到 Web 服务管理、编排和企业服务总线的解决方案的主要决策者。

应用程序架构师

应用程序架构师的角色是确保所编写的代码是面向服务的，且遵循可用于面向服务的开发的最佳实践和流程。他们需要在不会对解决方案进行过度设计的前提下将业务需求转换为有意义的服务。典型的服务创建和使用比代码的直接调用开销更大。因此，确定作为服务公开的粒度级别以及如何进行公开是此角色的主要工作职能。

应用程序架构师还要与组织中的企业架构师及其他应用程序架构师紧密合作，以确保充分利用每个服务重用机会，且恰当地对服务进行构建、发现、安全保护、使用和测定。

应用程序架构师最终负责服务交付和使用（非功能要求）的所有技术方面的工作，包括 SLA 遵循情况的可测定性、符合控制策略、执行和确保安全策略等等。

阅读不同 SOA 文献中关于架构师的信息时，您可能会遇到术语业务架构师，即应该理解业务情况并设计服务的人员。在我的 SOA 团队定义中，此角色的工作由应用程序架构师完成，而不是由企业架构师完成。应用程序架构师或业务架构师是业务小组和技术小组间负责技术设计方面的协调人，而业务分析人员则是负责业务方面的协调人。

按照省政法委统一要求，太原市政法系统从现在起集中开展为期3个月的纪律作风教育整顿。

此次纪律作风教育整顿的重点包括三个方面：整顿思想特别是特权思想；整顿政治纪律、执法纪律、廉政纪律；整顿办案作风、办公作风、办事作风。目的是为了严肃纪律、改进作风、服务群众、促进工作，解决群众反映强烈的纪律作风方面的突出问题，促进社会和谐。整顿活动分4个阶段逐步实施，即学习提高阶段、自查自纠阶段、开门整顿阶段、整改查处阶段。为此，太原市要求各级政法部门要进一步深入推进执法公开，凡是能公开的工作制度、办事规则都要公开，有条件的都要实行执法工作信息化管理，增强政法工作的透明度，切实保障群众的知情权、参与权和监督权。同时，全市政法各部门要通过座谈会、问卷调查，以及设立举报信箱、开通举报电话等形式，掌握线索、拓宽渠道、广开言路，自觉主动地接受群众的监督。对群众的投诉和掌握的违法违纪线索，坚持有案必查、查实必办、决不姑息。各县（市、区）委政法委和市直各部门，要组织专门人员对政法单位和政法干警的纪律作风、执法办案、为民服务、警容风纪、在岗在位、车辆使用等情况进行明察暗访，发现问题，严肃处理。整顿活动中，对不胜任本职工作的，要离岗培训；对不适合从事政法工作的，要坚决清理出政法队伍；对因疏于管理导致队伍中发生严重违法违纪案件、造成恶劣影响的，要追究领导责任

1   9世纪末20世纪初意大利社会学家和经济学家帕累托发现的“帕累托原则”指出，在任何一组事务中，最重要的通常只占一小部分，大概为 20%，这个原则又被称为“重要的少数”，或者80/20定律。“帕累托原则”主张团体中80%的贡献是由20%的成员所做出的，换句话说，在一个项目中只要做好重要的20%的事情，就能达到80%的效果。

　　不幸的是，许多CIO在信息化项目实施中，却往往忽视“帕累托原则”，而使自己的信息化项目陷入窘境。

　　探索中的企业信息化往往需要在前进中不断摸索，更需要信息化效果的尽快显现来增强企业信息化的信心。如果在信息化实施时不抓重点，尽快显现出信息化的实施效果，而将信息化战线拉得过长，很有可能在信息化尚未成功之时就会导致项目因得不到企业老板和员工的认可而中途夭折。

　　如何利用“帕累托原则”原则帮助我们抓住信息化建设的重点，来顺利完成信息化项目实施？笔者根据自己的工作实践总结出几点经验与读者共享。

　　选择信息化项目 满足20%需求

　　面对企业方方面面的需求，信息化项目的选择往往令CIO们大伤脑筋，用信息化有限的预算满足企业的全部需求显然不现实，然而又要保证信息化的实施效果，CIO往往陷入需求和预算的两难。

　　用“帕累托原则”抓住关键问题，对需求进行罗列和排序，不仅能明晰需求，更能够帮助CIO选择合适的信息化项目。首先，把收集到的每个需求按其重要性进行排列，考察实现每个需求能够为企业带来的价值，以及每个需求的紧迫性、需求的使用范围和频率。然后，与技术人员商讨需求实现的成本及难度，设想在需求实现中可能会遇到所有阻碍。在此基础上，对需求进行再次排序，找出其中最关键的20%需求，作为选择信息化项目依据。

　　根据笔者的经验，完成了企业这20%的需求，往往可以解决企业中80%问题，而我们花的精力却只有20%。用20%的投入实现80%的效果，不但可以增加员工和一把手信息化建设的信心，还能减少在实施过程中遇到的阻碍，一举两得，何乐而不为？

重组企业20%关键流程

　　企业的业务流程数以百计，特别是制造业，把企业的ISO内控流程拿出来，有厚厚的几本。但是，企业在实际工作中，80%的流程一个月都难得用到一次，如供应商考核流程，要半年甚至一年才会用到一次；设备检修，也每季度才检修一次；信用额度的审批，一般企业都要一年调整一次……若一开始，我们就考虑这些难以用到的流程，那么项目的难度就会无限的扩大。

　　实际上，企业平时用的最多的，或者说企业最关键的流程却只有20%，其中包括材料的采购、入库、验收流程，应收应付流程，生产领料流程等等，抓住这20% 的关键流程进行理顺重组，将大大缩短ERP实施时间、降低ERP的流程重组难度。

　　我们所要做的第一步，是根据企业的实际情况，找出企业利用最频繁的流程；第二步，考察企业当前业务情况，寻找存在的关键管理漏洞，这其中包括仓库原材料超收、业务员违规送样等漏洞。从中根据使用频率和管理漏洞找出关键流程，对关键的20%流程进行重组。

　　用20%的模块实现80%的业务

　　信息系统大都是模块式架构，因此项目的实施一般也按照模块进行实施。找准企业平时用的最多、给企业带来最大收益的几个模块，如销售，采购，生产，财务，仓库等，重点实施，可以让有限的资源相对集中在最关键的模块上，从而保证ERP项目的实施效果。

　　其它模块，诸如成本、库存盘点、对帐、报表等，一个月甚至一年才会用到一次，并且其内容又依赖于其他模块的实施，若一开始就大包大揽，全部上马，其实施难度和收效可想而知。

　　模块与业务之间是相辅相成的，主要模块服务于主要业务，20%的主要模块的实施往往能够带来80%主要业务的实现。因此，在项目实施规划时，要优先考虑牵扯到主要业务的重点模块，待主要模块效果显现后，再考虑完善其它模块来全面满足业务需求。

　　用关键20%制定项目评估指标

　　信息化项目的实施评估，往往依赖于对若干指标实施情况的考察。指标的选择，往往关系到最后的考核结果。如果不分主次，在各个模块、各个业务流程平均的抽几个指标出来评估项目的话，那想想会出现什么结果？我们会发现，信息化项目的实施效益很低。

　　如销售定单的出错率本来就只有1%，这时，销售定单流程可能已经不是主要流程，而恰恰我们又拿这个流程来考核，发现上了系统后，出错率仍然为1%或者0.99%，显然无法从这个指标看到ERP的效益。

　　相反，若我们在需求调研的时候，发现采购周期为3天，长于同类企业的1天的标准，那我们在需求调研时，即可形成关键需求；在实施后，这个采购周期就是评价ERP实施效果的关键指标。抓住了上面提到的20%需求，20%关键流程，20%关键业务来制定信息化项目的评估指标，其评估的结果才是合理的，真实的。

　　信息化项目的深入和完善是个循序渐进的过程，信息系统的成功上线，并不意味着项目的完结，相反却是一个新周期的开始，需求调研、流程优化、效果评估……不断的深入和优化将成为每位CIO永久的使命，“帕累托原则”也必将成为帮助CIO达成这一使命的持续动力

　　我们把这类缺乏规则约束，仅靠少数能人的灵光乍现和随机应变而取得快速发展的公司称为“随机应变型组织”。它们能留住好的人才，在财务上也能够非常成功；但是它们还是未达到自己的最高绩效水平，需要向一个更稳定、更持久的管理模式转变。

随机应变型组织的特点

　　随机应变型组织最大的特点就是它振奋人心的气氛。这里新鲜的观点比比皆是，它们推动了天才解决方案的提出。但是，此类组织中的员工往往过度消耗自己的精力，从而可能导致最终的崩溃。

　　刚加入帕帕克律师事务所6个月的助理律师比尔，收到了上司杰克从一个大型电信公司——广信公司打来的电话。广信正着手进行对一个大竞争对手的收购，他们希望帕帕克能确认是否有这样的经验和专家可胜任此项目。比尔刚接到任务，做一个关于公司资格背景的陈述，并简述一下广信的兼并过程。陈述安排在下周1中午，现在是周5。显然，比尔与女朋友伊丽莎白的周末滑雪计划可能泡汤，但他非常兴奋。这就是他之所以加入帕帕克的原因——有机会为世界顶级的大公司做大项目！

　　帕帕克在企业并购方面非常出名，已经拥有大量的石油产业客户，肯定会有一些模板和资格证明文档，比尔可以用这些资料来做这个资格背景陈述。但当他在公司局域网中搜索“帮助”的时候，他发现帕帕克的所有数据都过时好几年了。当比尔四处打听时，所得到的回答大都是“谁有时间管理数据库？你必须自己‘加工’文档内容，自己写案例，这些都没有报销。每个人都要忙着应付客户的事”。

　　比尔觉得这太难以理解了。他必须靠自己在短短6个月内建立起来的一点点关系，讨、借或是偷一些他能够利用的信息。而公司的数据库如果更新了，一切本来要容易很多。比尔给伊丽莎白打电话，取消他们的滑雪计划。这已经不是他第1次仓促地取消他们的周末计划了。同样，这也不是他第1次为了那些本应该早准备好的资料而到处找人。到周1早上陈述材料完成的时候，他已经工作了40个小时，而正常情况下这充其量只是10个小时或1个工作日的工作量。尽管最终陈述非常顺利，但比尔的女友却在2天前留了一张条，说要与他分手。
　　帕帕克是典型的随机应变型组织。它能够吸引很多可承受高压力工作环境的人才，是一个非常令人兴奋的工作地点，但是，人们要怀疑这种压力是否真正有必要。如果信息能够程序化地获得和共享，那么员工就不需要在周末做一些重复性的工作。
　　成立于2000年4月的印度24/7客户服务公司同样是随机应变型组织。24/7拥有世界500强企业中的很多客户，为它们提供电话服务中心和售后服务中心、市场调查等客户服务解决方案。该公司年收入从0开始已经增长到5000万美元，员工由5年前的20人增长到4000人。
　　公司不断获得客户的赞誉和推崇，但它的迅速增长也付出了巨大代价。随着董事会不断有新成员进入，公司越来越难以发动和组织他们接受必要的决策，来推动组织的发展。公司CEO康南对此深感苦恼，因为早期那种在吸引犹豫不决的客户时非常管用的“工作狂人”态度，将难以满足一个金领企业为了寻求尽责、可靠的服务提供者，而对组织健康提出的要求——幸运女神将青睐那些有稳定预期、有可测度的运作模式。

改善随机应变型组织的管理

　　如何改善随机应变型组织的管理？焦点问题应该是预防性防御——创建一个更为连贯、层次清晰且能自我矫正的组织，一个能让员工明确公司对自己要求的组织。

　　职责和流程规则的制度化

　　非正式的决策不能带来稳定的结果；组织需要引入更多的架构和规则，以承载它的成功发展。管理层需要非常清楚，谁知道什么以及如何让他们知道。这就意味着要明确决定权并以恰当的途径和信息为决策者提供支持。业务流程不仅要明确定义，而且组织应该确保他们是以规范的方式来执行的。

　　24/7客户服务公司的管理层已经对其决定权和激励作出了相应的调整。“我们不再以非正式的方式来着手解决问题，我们已经引入了以流程驱动的决策框架。首先是发现问题。然后这些问题要分发给各个不同职能单位的负责人。时间限制和跟踪机制都必须有。然后，我们每周要作为一支团队共同来着眼于一些重要的问题，想一想‘我们需要共同努力的有哪些事情’？”公司CEO康南这样说。

从经济增长的周期因素看，目前已经到了本轮周期的后期阶段，即便是不进行宏观需求紧缩，经济增长也会逐步进入下降通道
　　8月份，城镇固定资产投资增长率为21.5%，比7月份下降了5.9个百分点,相比于6月份的33.5%,更是下降了12个百分点；同时，8月份的工业增长率也下降到15.7%，比7月份下降了1个百分点，比6月份下降了1.8个百分点。

　　投资回落的两种假设

　　投资是主要的需求指标，工业产值则是主要的供给指标，这两个主要经济指标连续两个月的回落，是否预示着本轮经济增长目前已经到了一个“拐点”？
　　有些人不同意这个说法，认为目前统计局报出的数字有假，根据是主要的能源与原材料产出仍处在高增长区，而经济增长率与这些基础产品的增长呈正相关，在基础产品仍在高增长的时候，投资与工业增长率是不可能显著回落的。在这个判断下，解释统计数据回落的原因，就只有认为它不真实，可能是地方政府为了应付中央要抑制经济增长“由偏快转过热”的宏观调控政策，有意识瞒报投资和工业增长率。
　　另一种观点认为，主要需求与供给指标的回落，是宏观调控开始见成效，而目前经济运行中的增长冲动仍然很强劲，因此指标的回落并不意味着中国经济的拐点性变化。

　　5年投资周期临界点

　　我对以上这两种意见都不敢苟同。自2003年出现新一轮经济增长高潮以来，由于分配关系的变化，我一直撰文呼吁，我们必须警惕在2007年可能出现全面生产过剩问题。由于本轮经济增长高潮主要由重工业投资带动，而重工业的平均投资周期大约为5年,所以自2003年开始计算,到2007年这轮由重工业投资带动的经济增长高潮就可能会过去了，届时因为投资需求明显下落，而大量项目集中投产，会使总供给大量增加，但是由于分配矛盾不可能在短期内得到解决，国内消费需求始终受到抑制，就不可能出现经济增长由投资需求带动向消费需求带动的转换，所以由生产过剩所导致的经济增长率下滑是不可避免的。
　　2005年，虽然本轮投资周期还处在中间阶段，但是先期投入的许多项目已经开始形成产能投放，所以中国经济运行也相应出现了与本轮经济增长周期完全不同的特征，就是当投资、消费与出口这三大需求都出现高增长时，中国经济不仅没有2003、2004两年出现的通胀率上升和瓶颈制约，反而是CPI与PPI双双走低，大量前两年还是极度短缺的产品，去年则开始出现供过于求的状况，在国内市场压力下走向国外，导致贸易顺差突然放大。中国经济这种“高增长、低通胀”与贸易顺差放大同时出现的格局，除了用“在需求高增长的同时，供给增长比需求还快”的原因来解释，是不可能有其他合理解释的。
　　缓解供给增长大幅度超过国内需求矛盾的是出口，前8个月的贸易顺差已经接近1000亿美元，去年上半年，贸易顺差占GDP的比率为4%，今年上半年则上升到5.4%。贸易的高增长与贸易顺差急剧扩大，说明到目前为止，外需依然强劲，并且还拉动了出口价格上升。这个上升幅度，既消化了初级产品进口涨价因素，也普遍高于人民币汇率上升的幅度，由此提升了出口企业的利润水平，并引发了面向出口产业的投资热潮，使出口产业的投资增长，成为推动投资增长再度出现热潮的新因素。
　　但是对5年的投资周期来说，目前毕竟已经接近尾声，这最集中地表现为新上投资项目计划投资额的显著回落。我之所以不敢苟同目前的投资回落是地方政府造假行为结果的说法，就是因为新上项目计划总投资的回落其实早已发生了。
　　从统计数字看，去年前5个月，新上项目投资增长率已经下降到24.9%，今年前8个月则猛降到11.4%。我们必须理解，目前公布的固定资产投资增长率与新上项目计划总投资增长率这两个概念的区别，前者反映的是到目前为止已经完成的投资额，后者则代表未来将要发生的投资额，如果投资完成额虽然很高，但新上项目计划投资额的增长率在下降，则目前的投资高增长率是不可能持久的。如果情况相反，则说明一个新的投资高潮正在酝酿之中。
　　值得关注的倒是，如果8月份的新上项目投资的增长率已经下降到11.4%，则明年下半年至2008年初以后，投资增长率可能会下降得很猛，由于投资需求占目前拉动经济增长需求份额的60%左右，投资增长率的显著下降就真的可能使2007年成为本轮经济增长周期的大“拐点”了。

　　经济增长内生因素是关键

　　关于是中央政府的宏观调控导致了目前投资与工业增长率的明显下降这个观点，我认为也站不住脚。央行虽然今年以来已经进行了两次加息，但第一次加息是在4月份，而直到7月投资与工业增长率仍然很高，显然对抑制“过热”没有起什么作用。8月份的加息是在8月19日，8月的日子已经过了一半多，说对当月的投资与工业增长率下降能起到决定性作用，显然没有根据，而国务院31号文加强对土地的控制,与调整出口退税政策的出台，更是9月份以来的事，根本不可能对8月份的经济运行产生影响，所以投资与工业增长率的显著下降，更应该从经济增长的内生因素中去寻找。

　　寻找宏观调控“双放松”时机

　　由于从经济增长的周期因素看，目前已经到了本轮周期的后期阶段，即便是不进行宏观需求紧缩，经济增长也会逐步进入下降通道，所以，未来宏观调控的走势必定是从“双稳健”转入“双放松”，而不可能走入再度收紧。具体说什么时候会转入双放松，还要看未来经济运行的变化。
　　我认为，如果9月份的投资增长率下降到20%以下，则进入四季度后，宏观调控转向的可能性就极大。
　　另外，还必须关注美国经济的变化。如果欧元与日元的利率继续提升，则美元的利率也会被迫提升，如果美元利率上升到超过5.5%，则美国的房地产泡沫就有可能发生崩溃，由此牵累到中国的出口增长。因此，我们最需要防止的是由国内的生产过剩与美元泡沫崩溃所导致的内外需紧缩“双碰头”，准备好启动各方面需求的应对措施，防止中国经济的大起大落。
　　作者:中国宏观经济学会常务副秘书长　

　　仔细回味这本书，我们可以发现，目前的电信运营商可能是对全球化和信息化力量的冲击感受最为深切的企业——这两大力量直接导致了电信运营业本地竞争加剧，在世界变平坦的同时，原来相对封闭的、自成体系的电信运营格局被冲击得荡然无存，运营商平静富足的生活被彻底打破。

　　战略方向的转变，自然要求对组织结构进行调整。传统上，运营商的组织模式按照直线职能方式建立，由上至下实施纵向的指挥和控制。虽然这种模式职责明确，但组织层级多、信息链冗长，容易导致对外界的反应迟钝。而提供综合信息化服务，需要强调以客户为中心，缩短战略制订者与市场之间的距离，同时确保在新的战略方向下企业强有力的执行能力。这就要求企业必须朝着集中资源、缩短信息反馈流程和提高运作效率的方向，对组织实施扁平化改造。于是，“世界是平的”最终反映到了运营商组织的扁平化，其核心就是减少组织层次并整合企业的资源和能力，以达到实施专业化管理、形成更统一的核心 竞争力的目的。

　　在对组织进行扁平化改造的过程中，通常所采取的企业流程再造(BPR)方式，是一个外科手术式的剧烈变革，很容易造成企业经营的动荡，而且成功几率不高。作为省级电信运营商，如何在避免大手术的情况下重塑组织？这就需要以提升战略 执行力为导向，对组织管理模式实施创新。可从三个方面来分析省公司如何对组织实施扁平化改造。

　　一是集中资源，尤其是关乎企业未来发展的战略性资源，进行整合和统一配置，从而降低成本和提高效率，达到集约化运营的目标。

　　资源种类繁多，如何集中，以哪些资源的集中作为切入点？人事权和财务权的集中当然是最本质和最彻底的，但也最容易遭受抵制。为确保市场经营的顺利进行，推动而不是打击一线组织的积极性，对于省级运营商来讲，集中掌控应从两类资源入手——客户资源和外部合作资源。

　　信息化战略就是以客户为中心的，战略转型能否成功，取决于客户。因此，省公司应逐步做到计费和营账系统(BOSS)、客户关系管理系统(CRM)和客户呼叫中心(10086)的区域化集中，加强对客户信息资料的统一管理，提高对客户数据的挖掘分析能力，提升客户服务的统一规范水平。同时，以客户为中心对关键业务数据以及关键应用进行集中，有利于降低业务支撑系统总成本，有利于实现网络服务水平的标准化，实现降低成本和高效管理的目标，最终提供端对端的以客户为中心的服务，强化市场竞争力。

　　开展信息化业务，绝非运营商一家可为，强大的合作能力是信息化战略成败的关键，如弗里德曼所讲：“在铲平了的世界里，合作，成为企业生存和发展的第一要件。打造完美的产业链、建立合作共赢的商业模式已成为社会化大生产和通信业发展的必然趋势。”因此，省公司必须联合产业链上下游，同时做好政府和社会关系管理，必须加大对外合作性资源的集中，加强对外统一宣传、统一公关。广东移动等省公司在实践中，通过与省政府部门的合作，推出了“信息化八项工程”等重大社会信息化项目，为信息化业务的推广创造了良好的政策优势和社会舆论环境，同时加强了与文化交通管理部门或者电力等行业的总部合作，有力促进了行业信息化的开展。

　　二是对组织进行梳理和优化，明确各自在新组织形态中的定位。

　　随着资源的集中，相应的组织业务流程势必发生相应的变化，对新的业务流程进行梳理，是新的组织形式得以确立并顺利运行的基本前提。由于在扁平化的过程中，必将减少部分职能的纵向层级，在纵向压缩时，如不注重调整横向的职能和业务部门，尤其是对工作责任边界不做调整，那么组织变革的效果就会大打折扣，甚至影响到对组织变革的信心和评价。按照新的业务流程调整或设计新的组织部门以及工作职责，未雨绸缪地做好新老模式的对接，将减少管理中的混乱以及顾客服务质量的下降。

　　在实践中，江西和广东等省的移动公司，对照eTOM运营流程模型，开展效率管理探索，对与两类资源集中掌控相关的重要流程进行了梳理和优化，如优化了采购、客户管理管理、IT、企业外部资源管理等流程，并通过流程穿越和流程跨越等活动，加强对流程前后段和不同流程部门之间的互动，强化换位思考，打造合作环境。

　　第三，做好组织中管理者角色和能力的提前培训，确保组织调整顺利进行。

　　资源的集中与职能的调整，绝不是拼装机器部件那么简单，它涉及到对组织以往运行方式以及组织成员工作习惯的改变。因此，在结构调整前，应首先对行业形势及对企业发展提出的新的要求和挑战进行培训，树立危机意识和变革意识，让大家了解、学习并认同转型战略。然后，对照新的战略要求，对各个层次管理者的新角色以及所需要的工作能力进行有针对性的培训，确保管理者明确并适应新的工作定位。在对现有管理者进行培训的同时，加强后备管理者队伍建设，对不能胜任新要求的管理者，坚决撤换，从而确保整个组织调整进程的顺利进行。

　　当然，在资源和职能的集中过程中，也会遇到一些问题，比如针对客户个性化和本地化需求，公司如何快速反应和高效解决，如何加强一线基层团队的活力和积极性，如果定位中层管理者等等。这就需要省公司在进行组织扁平化的过程中，处理好集中化与本地化、统一配置与灵活处理、集权与授权之间的平衡关系，而这种平衡，需要采取创新性的思维和精细化的手段，稳步推进。

1.     企业信息化绩效研究的背景

迅速增长的IT投资，似乎没有得到明显的投资回报。20世纪80年代末，美国学者查斯曼（Strassman）调查了292个企业，结果发现这些企业的IT投资和投资回报率（ROI）之间没有明显的关联。对信息技术的大规模投资没能提升生产力水平——这个质疑后来逐渐演变为著名的“生产力悖论”。“生产力悖论”指出：从1960年代到1990年代中，美国GDP在增长，实际工资在增长，新技术层出不穷，人民的生活水平在提升，全要素生产力的增长率却一直呈现节节下降趋势，直到1990年代最后几年才有较强劲回升。数量模型与统计数据的研究结果与人们的常识和感受不甚相合。

2001年10月17日，麦肯锡公布了研究报告《IT与生产力》，结论与“生产力悖论”的吻合：“在1995年到2000年期间，美国经济确实得到了提高，但促成这一转变的能量主要来自少数几个商业领域，与人们普遍预料的相反，对IT行业的高额投资并不是创造美国生产力增长‘神话’的主要力量。在绝大部分经济领域中，对IT方面的大幅投资没有起到任何帮助生产力增长的作用。”麦肯锡报告推论的逻辑是，“占经济总量69%的53个行业部门为生产力增长的贡献率仅为0.3%。尽管IT投资浪潮中62%的资金增长是投入在这53个部门，但它们中的大多数遭受了生产力下降的厄运。”

2003年5月《哈佛商业评论》上刊载的尼古拉斯.卡尔（Nicholas G. Carr）题为《IT Doesn’t Matter》再次引发起巨大反响，几乎所有的重要媒体、IT业界巨头尤其是CIO、商业界重量级人物和专家学者们纷纷发表对此问题的看法。卡尔指出：实际决定公司资源是否真正具有战略价值的是稀缺性，而非普遍性。在今天，当IT已不再是专有技术，而是基础性技术,正在日益成为同铁路、电力一样的无差异性大众商品的情况下，企业通过对IT的常规投入获得优势的机会越来越小，“从战略重要性这个角度来看，IT会淡出舞台，不再那么紧要”。

在我国，目前企业上ERP项目通常的做法是，调研、撰写可行性报告、审批、招标、答辩、选定ERP软件提供商、安装系统、整理编码、输入工程数据、按每子系统实施、上线、验收。时间成本上由调研到系统初步验收要几年；经济成本包括项目的投入巨大，再加上日常的维护费用，升级费用；另外还包括人员增加等。效果上往往虽然订单处理、财务账目电子化了、库存管理电子化了，但生产计划调度的工作量似乎未见减少，量化的效益又难以说清，这就是我国大多数制造企业实施ERP项目的写照。

大量的实践和研究都证明，IT的存在价值将是能否将其转化为服务经济模式，IT的投资应通过与战略的融合，致力于价值实现、风险控制和流程管理。开展信息化绩效的研究、提高信息化的绩效已是迫在眉睫。

2.     研究途径

信息化绩效的实践和研究可分为三个方面：如何确定绩效目标？如何以绩效驱动实施？实施后如何评估绩效？

2.1     如何确定信息化绩效目标

第一，是从管理的角度来定义目标。整个企业从一个层面的目标来看是成功的，从另外一个层面的目标来看很可能是不成功的。所以这个认识上的问题就给ERP的绩效目标设置了障碍。所以，需要从“信息化整体成功”制定目标。

第二，将信息化绩效目标和战略目标结合。对照此目标看IT系统是不是和企业的战略目标结合了，如果IT系统能解决企业所面临的战略问题，自然是达到了目的。对于企业来讲，首先要理解IT的能力，IT资源，流程现状，要对IT的能力和公司的业务战略做分析，知道怎么样做才能够提高IT的价值。企业现有的能力和目标的能力，体现了IT的流程和IT资源的价值，可以从这些方面来评估并按照IT价值的角度来制定的信息化绩效目标。

第三，在信息化项目前期进行配套管理问题的解决。现实是应该在前期解决的管理问题，被回避，都放到了后期。而在后期，这些矛盾到了无法解决时，供应商也感到无能为力，项目轻则延期，重则严重挫伤企业积极性。实际上，很多企业运营流程不顺的时候硬把软件放上去，美其名“先固化后优化”，结果下面怨声载道，岂不知不少固化变成了“冗余流程的半自动化”。由于实施需要一定的周期，不可能把原来的所有基础推倒重来，很多人也不愿意都按照新的流程进行更改，结果是ROI变成了“ROI泡沫”。另一方面，很多供应商获得了相当多的利润，承诺的很多却做到的很少。

2.2    提高信息化绩效的实施研究

第一，在企业上系统之前，要进行一个全面的评估。企业价值链如何(战略)、组织就绪状态如何(流程)，企业领导力和执行力如何，应从这三个方面去进行分析。评估企业的IT战略和实施有没有支持业务的发展， IT战略和业务的结合情况如何。从不同层面的量化和对比来看，系统并不是对每个部门都产生效率，对单个部门很难评估投资收益率。要对整体效率评估。根据信息系统和企业战略目标相融合的战略性信息规划确定的信息化绩效目标是企业信息化的重中之重。

第二，按照量化的标准作为实施依据，通过这个标准去衡量项目实施方案，2005年， Gartner总结出CIO最关心的十个问题，第一个问题就是“价值管理”，就是怎么利用IT来创造价值。对企业而言，信息化建设是要提供价值的。应该先定义好所提供的价值，这个价值就是一个标准。但企业的情况千差万别，所以，实际上基本没有一套可以放之四海而皆准的标准可以衡量。

第三，管理变革和系统实施相结合。做不好管理变革方面的工作，实施ERP等信息化项目往往导致"零效益"或"零成功率"。企业实施信息化，业务部门的人员要了解自身的工作模式，哪些是关键的战略项目？对于一个行业来讲，首先仔细审核业务优先级和自身的能力，才能够确立项目的重点，不同行业的不同企业其针对绩效目标的业务优先级不同。其次用户企业要了解，信息系统的流程是什么，根据自身确定的目标，寻找和标准信息系统流程的差距。信息化建设获得业务部门充分的支持和理解，甚至由业务部门主导实施，才能够从确实获得业务部门的绩效。

案例  瑞士的ALVEO公司，对照量化目标判断实施方案

瑞士的ALVEO公司成立于1971年，共有员工400人，98年营业额为1.3亿瑞士法郎，专门从事聚烯烃泡沫的开发、生产、销售和生产开拓。该公司从99年开始实施ERP项目，基本达到预期目标，成功因素之一是由清晰的目标驱动进行了ERP实施，其制定的目标包括：保证客户咨询的时间在2 h以内，保证回答客户的可靠性，财务平均减少支付期5天，优化日常财务管理工作，PP减少计划处理时间50%，库存周转由12次到24次，提高收益0 .5%，职工人数不变，总产量增加25%。其通过诸如客户矩阵定义目标，通过ERP系统、配套的管理措施、严谨科学的项目管理等实现了目标

。

2.3    信息化绩效评价技术

绩效评价中的成本评价不仅包括采购的成本、部署的成本，也包括上线开始运行以后运行的成本、维护的成本、变动的成本。从收益的角度讲，一个是IT收益，直接产生的是IT部门的效益，就是这个系统的可用性提高了；另一个是业务收益，面向员工、从面向客户、面向供应商、面向合作伙伴的业务流程的效率提高情况，它能够产生的工作效益，这些都是从衡量IT价值方面要充分考虑的。因而收益评价更为复杂：

首先从财务的角度和非财务的角度看。财务的指标在很多情况下只看到一个结果，没有办法表述其根源，也没有办法表示当前的情况，而且决定财务指标的很多因素不是单一的，比如说市场的情况好，财务指标最终收益就会大大增长，很可能它并不是因为IT直接带来的。即到单纯的财务指标没有办法把信息化投资的效益很完整地描述出来。非财务的指标有很多方法。美国学者帕尔，提出信息化的非财务指标可以用强化回报率，有些东西没法用财务指标计算出来，但是你可以用一些参数，可以用一些指标，可以用一些和财务指标相关的参数转换成财务指标。利用价值的关联，信息化对其它部门部门的贡献来计算。如加快库存周转率缩短了，这些是通过信息化给企业加速所带来的价值。

其次用定量的测度和定性的测度，尤其是量化的测度，可以变成财务指标，可以变成其它指数。定性测度，如信息化很多效益反映在改进了决策质量，提高了竞争力，增加了团队合作的精神等等。中国信息化评测中心的企业信息化效能指标，这个指标很多是定性的，比如企业对信息化的投资，投资和信息化战略的适宜度，IT和企业战略适宜度、投资和规模是不是适宜。平衡计分卡的方法从客户的纬度、流程的纬度、财务的纬度、创新的纬度等方面进行评估，可以从企业的战略着手，先设置企业的战略，然后提出实现企业战略各个方面的指标，然后把这些指标分解成为四个方面，参照纬度设置一些指标，这些指标可以从企业内部的运作情况衡量出来，通过信息化在企业内部产生运作的合理性，内部效益的提升，从这方面衡量企业信息化的效益。

下面的技术主要是定量的测度技术

第一、评价工具或模型

IBM Rational¹估计项目成本的技术之一——COCOMO II模型：

工作量 = (人员) (环境) (质量) (规模过程*)

*表示过程有效性

这个等式抓住了以下关键因素：

工作量：完成项目需要的人月 ，过程：基于产生最终产品的过程的有效性的公式

环境：考虑工具和技术的因素 ，质量：考虑需要的产品质量的因素

规模：组成最终产品的人工产生的代码行数 ，人员：考虑团队能力的因素

由Barry Boehm和Dan Port对软件问题的“价值方面”定义了“基于价值的软件工程 (VBSE)”。VBSE涉及软件和信息系统产品，过程技术，以及它们与人类价值的互动。它使用风险分析来平衡软件规范和灵活性。目前，在美国最被认可的培训当属核子研究公司的执行官堪培尔所讲授的课程。堪培尔认为，关键是要学习如何获取正确的数据，即如何问合适的人合适的问题。堪培尔认为，一套成型的投资分析方法能够保证分析的连续性，尽管通过这样的分析方法所得出来的结论可能不够准确。

企业对IT咨询的需求分两种：知道自己应该做什么，但缺乏流程优化或重组的能力;或者能够完成流程优化，但缺乏将优化后流程的实施能力，如案例中小凌所在的公司;前者对咨询的需求将包括BPR和ERP实施，而后者的需求仅仅是ERP实施;显然，前者应付出的成本将比后者高;所以，企业若能在实施ERP之前就完成或部分完成BPR将大大降低信息化的成本。

世界上各大ERP产品都有其一套通用的流程体系，然后在实施的过程中视不同行业、不同企业的具体情况进行客户化开发。作为ERP产品供应商或咨询公司的实施顾问，他们的优势在于对产品本身通用流程的熟悉，但是对各行业和企业的流程体系熟悉程度较低，故无论是国际“四大”还是国内的ERP咨询公司，几乎所有的ERP实施项目都需花费大量时间去进行企业流程重新疏理和客户化流程重组。

此时，若企业自己缺乏流程文档的积累，那么花费大量的成本替咨询公司交学费的情况就难免会发生;但是，若企业有着明确的战略规划，而且对业务模式对应的管理流程和业务流程有着明确的认识，将大大减少提高ERP实施项目的时间，同时提高项目的效率。

ERP项目实施方式可分为两种，由咨询公司以实现产品功能为导向的实施方式，或者由企业以实现个性化需求为导向的实施方式，不难想像前者的风险和失败的可能性;导致前者发生的主要原因来自咨询公司与企业之间的信息不对称，尤其是对企业流程信息的不对称，所以，企业在实施ERP项目前就自己对流程体系进行一定的疏理，将大大提高ERP项目的成功率。

BPR：革命尚未成功

上世纪由西方发起轰轰烈烈的流程再造被视为一场颠覆性的革新运动，到目前为止可谓毁誉参半。有“BPR之父”之称的哈默教授在其《X-再造》一书中已承认BPR尚未成功，同志还需努力。究其原因，有如下几点：

◆ 多数BPR运动准备不足。一方面，BPR的目的是为了重塑企业业务模式，构建企业新的核心竞争力;而另一方面，完整的BPR不啻于掘地三尺，需耗费企业大量的人力物力，而开始从事BPR的企业大多将此当成可有可无的鸡肋。

◆ 企业高层重视不够。就理论而言，技术革新应由下而上，而管理革新必须由上而下。但在BPR掀起波澜的初期，企业领导人对BPR普遍缺乏足够动力和危机意识，于是BPR往往半途而废。在2000年联想BPR项目后的总结中有这样一个教训：讨论流程的业务人员层次低，变换频繁，业务部门主要负责人审核、把关投入的精力不足，导致组织结构只是初步结果， 业务流程没有覆盖到全部业务情况。

◆ 遭遇传统势力的阻力。BPR在提高业务运作效率的同时，也将彻底颠覆企业传统的权力结构，由臃肿的金字塔高度集权式企业改造为扁平化和分权式的企业，受冲击最大的是企业的中高管理层。在强大的阻力下，BPR面临较高的风险。摆在企业最高领导人面前的往往是一道两难的题目：是选择刮骨疗毒还是任由企业自身的免疫系统缓慢起效。小凌所在的公司应该是幸运的，因为该公司在咨询公司进入前，已经完成了部分BPR的工作，也正是这部分的BPR使公司完成了风险最大的内部管理变革，当年联想在花费了数千万元的咨询费启动了ERP项目后，遭遇内部一系列阻力，项目险些搁浅。为此，柳传志曾发出过那句广为流传的感叹：“上ERP也许会死，但不上ERP肯定会死”

◆ 实施不力。流程重组的终极目的是使企业业务运作效率最大化，消除一切低效率的行为，但流程优化本身只能实现纸上的规划，并不能解决问题。新流程的实施者往往发现虽然流程的审批环节减少，但决策速度还是跟不上市场需求的变化速度。即使在流程优化后，一个订单变更的流程还是需要走过生产部门、仓储部门和工艺设计部门三个环节，而一个大型企业往往同时面对成百上千的订单，在信息系统缺位的情况下，通过电话、传真的方式沟通明显不够经济。

当然，上述症状一般是在企业业务达到一定规模时才会发生，而有此规模的企业一般都部分实现了信息化，但是缺乏集成的各系统就有如汪洋中的孤岛，难以发挥效用，小凌所在公司在ERP上线前就面临流程实施不力的问题，其原因主要在于新的流程没有与原有的信息系统实现对接，而且原有的信息系统本身也未能实现集成。

以上问题其实都反映了一个共同的原因：BPR仅仅是规划，在实施过程中需要企业从全方位提供有效支持，而完整的信息系统才是高效实现新流程的前提。

BPR：上马ERP的充分必要条件

对于小凌所在的公司而言，BPR不但是ERP的充分条件，更是必要条件。ERP项目前的BPR虽然未能实现其全部目的，但是在以下几个方面是成功的：

◆ 通过BPR实现了内部的管理变革，BPR后的企业至少初步拥有了接受进一步变革的企业文化，使得ERP具备了成功实施的关键前提。

◆ 通过BPR，企业才真正发现了自身的准确需求，那就是对于企业全部流程进行重组的需求，而不是部分流程优化的需求;基于原有的信息系统实施新的ERP模块的需求，而不是盲目地接受自己不需要的ERP模块，大大提升了ERP项目的投资回报率。

在BPR之后，企业必须完成以下几个方面的调整来实现与原有信息系统的对接：

◆ 将公司原有的组织结构的层级设置、岗位编制和岗位职责按照新流程的要求进行相应调整，真正实现流程导向型的扁平化组织(小凌所在公司发生的20名高管在BPR后只剩下6名的情况并不意外。

◆ 基于新的流程，将原有的信息系统进行重新设置，包括：用户的权限级别、系统的角色定义、新功能的开发、报表和单据的格式。

◆ 信息录入人员的数量应根据新流程的要求进行调整。

◆ 静态主数据(包括物料、供应商、客户、BOM等等)的重新定义和动态数据的重新测试和转换。

◆ 在系统调整后，还需针对调整的内容对企业员工进行必要的培训。

◆ 若现有信息系统的功能已经无法满足新的流程体系，企业则应该考虑上一套全新的系统。

就像企业追求基业常青的可持续发展理念一样，BPR和ERP的升级改造将在企业的生命周期中不断上演

企业对IT咨询的需求分两种：知道自己应该做什么，但缺乏流程优化或重组的能力;或者能够完成流程优化，但缺乏将优化后流程的实施能力，如案例中小凌所在的公司;前者对咨询的需求将包括BPR和ERP实施，而后者的需求仅仅是ERP实施;显然，前者应付出的成本将比后者高;所以，企业若能在实施ERP之前就完成或部分完成BPR将大大降低信息化的成本。

世界上各大ERP产品都有其一套通用的流程体系，然后在实施的过程中视不同行业、不同企业的具体情况进行客户化开发。作为ERP产品供应商或咨询公司的实施顾问，他们的优势在于对产品本身通用流程的熟悉，但是对各行业和企业的流程体系熟悉程度较低，故无论是国际“四大”还是国内的ERP咨询公司，几乎所有的ERP实施项目都需花费大量时间去进行企业流程重新疏理和客户化流程重组。

此时，若企业自己缺乏流程文档的积累，那么花费大量的成本替咨询公司交学费的情况就难免会发生;但是，若企业有着明确的战略规划，而且对业务模式对应的管理流程和业务流程有着明确的认识，将大大减少提高ERP实施项目的时间，同时提高项目的效率。

ERP项目实施方式可分为两种，由咨询公司以实现产品功能为导向的实施方式，或者由企业以实现个性化需求为导向的实施方式，不难想像前者的风险和失败的可能性;导致前者发生的主要原因来自咨询公司与企业之间的信息不对称，尤其是对企业流程信息的不对称，所以，企业在实施ERP项目前就自己对流程体系进行一定的疏理，将大大提高ERP项目的成功率。

BPR：革命尚未成功

上世纪由西方发起轰轰烈烈的流程再造被视为一场颠覆性的革新运动，到目前为止可谓毁誉参半。有“BPR之父”之称的哈默教授在其《X-再造》一书中已承认BPR尚未成功，同志还需努力。究其原因，有如下几点：

◆ 多数BPR运动准备不足。一方面，BPR的目的是为了重塑企业业务模式，构建企业新的核心竞争力;而另一方面，完整的BPR不啻于掘地三尺，需耗费企业大量的人力物力，而开始从事BPR的企业大多将此当成可有可无的鸡肋。

◆ 企业高层重视不够。就理论而言，技术革新应由下而上，而管理革新必须由上而下。但在BPR掀起波澜的初期，企业领导人对BPR普遍缺乏足够动力和危机意识，于是BPR往往半途而废。在2000年联想BPR项目后的总结中有这样一个教训：讨论流程的业务人员层次低，变换频繁，业务部门主要负责人审核、把关投入的精力不足，导致组织结构只是初步结果， 业务流程没有覆盖到全部业务情况。

◆ 遭遇传统势力的阻力。BPR在提高业务运作效率的同时，也将彻底颠覆企业传统的权力结构，由臃肿的金字塔高度集权式企业改造为扁平化和分权式的企业，受冲击最大的是企业的中高管理层。在强大的阻力下，BPR面临较高的风险。摆在企业最高领导人面前的往往是一道两难的题目：是选择刮骨疗毒还是任由企业自身的免疫系统缓慢起效。小凌所在的公司应该是幸运的，因为该公司在咨询公司进入前，已经完成了部分BPR的工作，也正是这部分的BPR使公司完成了风险最大的内部管理变革，当年联想在花费了数千万元的咨询费启动了ERP项目后，遭遇内部一系列阻力，项目险些搁浅。为此，柳传志曾发出过那句广为流传的感叹：“上ERP也许会死，但不上ERP肯定会死”

◆ 实施不力。流程重组的终极目的是使企业业务运作效率最大化，消除一切低效率的行为，但流程优化本身只能实现纸上的规划，并不能解决问题。新流程的实施者往往发现虽然流程的审批环节减少，但决策速度还是跟不上市场需求的变化速度。即使在流程优化后，一个订单变更的流程还是需要走过生产部门、仓储部门和工艺设计部门三个环节，而一个大型企业往往同时面对成百上千的订单，在信息系统缺位的情况下，通过电话、传真的方式沟通明显不够经济。

当然，上述症状一般是在企业业务达到一定规模时才会发生，而有此规模的企业一般都部分实现了信息化，但是缺乏集成的各系统就有如汪洋中的孤岛，难以发挥效用，小凌所在公司在ERP上线前就面临流程实施不力的问题，其原因主要在于新的流程没有与原有的信息系统实现对接，而且原有的信息系统本身也未能实现集成。

以上问题其实都反映了一个共同的原因：BPR仅仅是规划，在实施过程中需要企业从全方位提供有效支持，而完整的信息系统才是高效实现新流程的前提。

BPR：上马ERP的充分必要条件

对于小凌所在的公司而言，BPR不但是ERP的充分条件，更是必要条件。ERP项目前的BPR虽然未能实现其全部目的，但是在以下几个方面是成功的：

◆ 通过BPR实现了内部的管理变革，BPR后的企业至少初步拥有了接受进一步变革的企业文化，使得ERP具备了成功实施的关键前提。

◆ 通过BPR，企业才真正发现了自身的准确需求，那就是对于企业全部流程进行重组的需求，而不是部分流程优化的需求;基于原有的信息系统实施新的ERP模块的需求，而不是盲目地接受自己不需要的ERP模块，大大提升了ERP项目的投资回报率。

在BPR之后，企业必须完成以下几个方面的调整来实现与原有信息系统的对接：

◆ 将公司原有的组织结构的层级设置、岗位编制和岗位职责按照新流程的要求进行相应调整，真正实现流程导向型的扁平化组织(小凌所在公司发生的20名高管在BPR后只剩下6名的情况并不意外。

◆ 基于新的流程，将原有的信息系统进行重新设置，包括：用户的权限级别、系统的角色定义、新功能的开发、报表和单据的格式。

◆ 信息录入人员的数量应根据新流程的要求进行调整。

◆ 静态主数据(包括物料、供应商、客户、BOM等等)的重新定义和动态数据的重新测试和转换。

◆ 在系统调整后，还需针对调整的内容对企业员工进行必要的培训。

◆ 若现有信息系统的功能已经无法满足新的流程体系，企业则应该考虑上一套全新的系统。

就像企业追求基业常青的可持续发展理念一样，BPR和ERP的升级改造将在企业的生命周期中不断上演

企业对IT咨询的需求分两种：知道自己应该做什么，但缺乏流程优化或重组的能力;或者能够完成流程优化，但缺乏将优化后流程的实施能力，如案例中小凌所在的公司;前者对咨询的需求将包括BPR和ERP实施，而后者的需求仅仅是ERP实施;显然，前者应付出的成本将比后者高;所以，企业若能在实施ERP之前就完成或部分完成BPR将大大降低信息化的成本。

世界上各大ERP产品都有其一套通用的流程体系，然后在实施的过程中视不同行业、不同企业的具体情况进行客户化开发。作为ERP产品供应商或咨询公司的实施顾问，他们的优势在于对产品本身通用流程的熟悉，但是对各行业和企业的流程体系熟悉程度较低，故无论是国际“四大”还是国内的ERP咨询公司，几乎所有的ERP实施项目都需花费大量时间去进行企业流程重新疏理和客户化流程重组。

此时，若企业自己缺乏流程文档的积累，那么花费大量的成本替咨询公司交学费的情况就难免会发生;但是，若企业有着明确的战略规划，而且对业务模式对应的管理流程和业务流程有着明确的认识，将大大减少提高ERP实施项目的时间，同时提高项目的效率。

ERP项目实施方式可分为两种，由咨询公司以实现产品功能为导向的实施方式，或者由企业以实现个性化需求为导向的实施方式，不难想像前者的风险和失败的可能性;导致前者发生的主要原因来自咨询公司与企业之间的信息不对称，尤其是对企业流程信息的不对称，所以，企业在实施ERP项目前就自己对流程体系进行一定的疏理，将大大提高ERP项目的成功率。

BPR：革命尚未成功

上世纪由西方发起轰轰烈烈的流程再造被视为一场颠覆性的革新运动，到目前为止可谓毁誉参半。有“BPR之父”之称的哈默教授在其《X-再造》一书中已承认BPR尚未成功，同志还需努力。究其原因，有如下几点：

◆ 多数BPR运动准备不足。一方面，BPR的目的是为了重塑企业业务模式，构建企业新的核心竞争力;而另一方面，完整的BPR不啻于掘地三尺，需耗费企业大量的人力物力，而开始从事BPR的企业大多将此当成可有可无的鸡肋。

◆ 企业高层重视不够。就理论而言，技术革新应由下而上，而管理革新必须由上而下。但在BPR掀起波澜的初期，企业领导人对BPR普遍缺乏足够动力和危机意识，于是BPR往往半途而废。在2000年联想BPR项目后的总结中有这样一个教训：讨论流程的业务人员层次低，变换频繁，业务部门主要负责人审核、把关投入的精力不足，导致组织结构只是初步结果， 业务流程没有覆盖到全部业务情况。

◆ 遭遇传统势力的阻力。BPR在提高业务运作效率的同时，也将彻底颠覆企业传统的权力结构，由臃肿的金字塔高度集权式企业改造为扁平化和分权式的企业，受冲击最大的是企业的中高管理层。在强大的阻力下，BPR面临较高的风险。摆在企业最高领导人面前的往往是一道两难的题目：是选择刮骨疗毒还是任由企业自身的免疫系统缓慢起效。小凌所在的公司应该是幸运的，因为该公司在咨询公司进入前，已经完成了部分BPR的工作，也正是这部分的BPR使公司完成了风险最大的内部管理变革，当年联想在花费了数千万元的咨询费启动了ERP项目后，遭遇内部一系列阻力，项目险些搁浅。为此，柳传志曾发出过那句广为流传的感叹：“上ERP也许会死，但不上ERP肯定会死”

◆ 实施不力。流程重组的终极目的是使企业业务运作效率最大化，消除一切低效率的行为，但流程优化本身只能实现纸上的规划，并不能解决问题。新流程的实施者往往发现虽然流程的审批环节减少，但决策速度还是跟不上市场需求的变化速度。即使在流程优化后，一个订单变更的流程还是需要走过生产部门、仓储部门和工艺设计部门三个环节，而一个大型企业往往同时面对成百上千的订单，在信息系统缺位的情况下，通过电话、传真的方式沟通明显不够经济。

当然，上述症状一般是在企业业务达到一定规模时才会发生，而有此规模的企业一般都部分实现了信息化，但是缺乏集成的各系统就有如汪洋中的孤岛，难以发挥效用，小凌所在公司在ERP上线前就面临流程实施不力的问题，其原因主要在于新的流程没有与原有的信息系统实现对接，而且原有的信息系统本身也未能实现集成。

以上问题其实都反映了一个共同的原因：BPR仅仅是规划，在实施过程中需要企业从全方位提供有效支持，而完整的信息系统才是高效实现新流程的前提。

BPR：上马ERP的充分必要条件

对于小凌所在的公司而言，BPR不但是ERP的充分条件，更是必要条件。ERP项目前的BPR虽然未能实现其全部目的，但是在以下几个方面是成功的：

◆ 通过BPR实现了内部的管理变革，BPR后的企业至少初步拥有了接受进一步变革的企业文化，使得ERP具备了成功实施的关键前提。

◆ 通过BPR，企业才真正发现了自身的准确需求，那就是对于企业全部流程进行重组的需求，而不是部分流程优化的需求;基于原有的信息系统实施新的ERP模块的需求，而不是盲目地接受自己不需要的ERP模块，大大提升了ERP项目的投资回报率。

在BPR之后，企业必须完成以下几个方面的调整来实现与原有信息系统的对接：

◆ 将公司原有的组织结构的层级设置、岗位编制和岗位职责按照新流程的要求进行相应调整，真正实现流程导向型的扁平化组织(小凌所在公司发生的20名高管在BPR后只剩下6名的情况并不意外。

◆ 基于新的流程，将原有的信息系统进行重新设置，包括：用户的权限级别、系统的角色定义、新功能的开发、报表和单据的格式。

◆ 信息录入人员的数量应根据新流程的要求进行调整。

◆ 静态主数据(包括物料、供应商、客户、BOM等等)的重新定义和动态数据的重新测试和转换。

◆ 在系统调整后，还需针对调整的内容对企业员工进行必要的培训。

◆ 若现有信息系统的功能已经无法满足新的流程体系，企业则应该考虑上一套全新的系统。

就像企业追求基业常青的可持续发展理念一样，BPR和ERP的升级改造将在企业的生命周期中不断上演

　　流程拥有者 　　

　　即利用工作流程，以便更有效率执行工作职责的人。他们对工作流程感兴趣，但并不注重所使用的工具。他们只想改善流程并证实其效果，可说是联系 BPM 团队与工作流程实际需求间的重要环节。企业主可从图形流程设计工具获益良多，这套简单的工具可帮助他们发展最初始的详细的流程图，与分析师紧密合作。完成部署之后，流程拥有者可重新检讨该流程相关的报告，并对工作流程提出改进的建议。总而言之，流程拥有者拥有工作流程、重视结果，但不想花心思在相关技术面上。

　　业务流程分析师　　

　　业务流程分析师是执行团队的重要成员，也是流程设计的专家。他在执行团队中并非软件开发者，因此使用的工具必须是直觉式操作，或具备基本、甚至毋需具备程序设计的专门知识。分析师需要整合的环境来进行下列事项：

　　勾勒或规划工作流程；

　　定义必须由自动化流程处里的特定情况及例外事项；

　　模块化流程，以工作周期展开前测试并界定潜在问题；

　　了解组织架构及从属关系；

　　提供团队成员、使用者及新进员工所属工作流程的各式文件；

　　在工作流程开始运行之后分析其产生的结果；以及

　　持续进行工作流程的改善。

　　IT 设计师　　

　　他们与流程分析师紧密合作，建立自动化流程。IT 设计师最了解 IT 环境的功能架构，但他们不是程序设计师，他们须具备下列能力，进行相关事项：

　　轻易存取流程设计师建立的工作流程及流程的文件 (直接让他们分享分析师权限更佳)；

　　设计表单或使用现有电子表单，及定义表单的数据项，但不需专精于数据库设计；

　　设计工作流程路径的规则及异常情况的处理，但不需撰写程序；

　　与目录、其它应用程序、Web Services及数据库进行整合；以及

　　在工作流程正式上线前，先行测试及模拟。

　　为使流程获致最佳性能及灵活度，任何 BPM 解决方案皆应是 IT 设计师及分析师的工作目标及责任，而不是开发人员。

　　软件开发人员　　

　　他们在 BPM 团队中扮演着重要角色，但是，除非整合情况复杂，或有其它必须透过程序解决的问题，否则不一定需要开发人员。需要开发人员时，他们需要相关工具进行下列事项：

　　在检视流程内容后，使用他们了解且惯用的开发工具；

　　开发程序代码及模块，方便日后只须简单使用 XML、Web Services或其它标准方法，就能呼叫表单或工作流程；以及

　　轻而易举就能在 BPM 应用程序及 ERP、CRM与其它功能所用的后台系统之间建立数据交换。

　　我再重复一个重点，软件开发人员应对 BPM 具贡献，但不是实施流程管理的主要焦点。唯一例外的情况是，若整个工作流程是企业应用程序整合 (EAI) 所带动，而不需太多、甚至不需人力的投入及具有高复杂度的整合。

　　IT 管理人员 　　

　　只要 BPM 系统开始执行，他们在维护管理上，就扮演着举足轻重的角色。他们需要能在其它管理控制环境下使用的工具，来进行下列事项：

　　监督系统的执行性能；

　　设定服务器环境；

　　管理磁盘空间及数据库使用情形；

　　授权企业使用者更多的流程行政管理责任；

　　分析日志文件；以及

　　建立系统使用率及使用者作业的报表。

　　总结　　

　　在选择并执行 BPM 系统时，您无疑必须考虑 BPM 团队。藉由结合团队能力及界定完整 BPM 系统的必备要素，您即可以部署符合所有使用者需求的解决方案、实现符合预期的投资报酬率 (ROI)，并为企业创造其它无形的利益。

武汉远纺工贸有限公司是远纺工业（上海）有限公司投资新建的子公司，设立公司主要目的让公司成为远纺工业（上海）有限公司的华中区物流中心，全部销售上海母公司生产之产品，所售产品主要是聚脂切片、涤纶纤维等工业原料，仓库的吞吐量非常大，由于母公司十分重视企业信息化建设，在武汉远纺工贸ERP系统上线之初，母公司已成功上线SAP R/3 系统，公司考虑到全局发展以及成本，选型SAP Business One 系统在武汉试点，以便将来复制到全国其它的分支机构、关系企业中。

　　实施初期，公司考虑的主体架构中，希望将武汉物流中心纳入上海母公司系统管理中，以便实现母公司对客户、销售、库存、财务的统一管理，带着这些问题，和合作伙伴不断的资讯沟通， 进行SAP Business One系统二次开发程序，由于国内没有现成的案例,只能进行大量的测试，在全公司各部门努力配合下，终于成功上线，使公司进入了管理流程化、信息共享化、资料集中化、资讯及时化。使用一年多以来，使上海母公司对武汉的客户、销售、库存、财务情况了如指掌，起到资料共享和稽核的作用，同时也不影响武汉公司的业务运转情况。

由于使用了SAP Business One 系统和SAP R/3 系统的连接性，使整个公司的各种业务基本实现的无纸化办公，除公司各部门之间的沟通和必要系统单据外，排除了很多人为因素干扰。经营活动的每个环节，基本都实现了系统管理，感觉就像是为我公司量身订做一样，给客户、外界良好的企业形象。同时，由于SAP Business One 系统比较小巧，系统维护也比较简单，上线至今，没有出现问题。在公司全力推行ERP 系统管理后，现在全公司的感觉SAP Business One 系统就像公司的生命线，维系着全公司的发展，提升了整个公司制度化和流程化的思维。系统中设计的流程随各自独立，确又环环相扣，紧密结合，使公司各部之间的合作、沟通也有加强，提升了团队协作能力。

SAP's original business model for R/3 was developed before the idea of an object-oriented model was widespread. The transition to the object-oriented model reflects an increased customer demand for it. ABAP Objects uses a single inheritance model and full support for object features such as encapsulation, polymorphism, and persistence.

SAP's original business model for R/3 was developed before the idea of an object-oriented model was widespread. The transition to the object-oriented model reflects an increased customer demand for it. ABAP Objects uses a single inheritance model and full support for object features such as encapsulation, polymorphism, and persistence.

SAP's original business model for R/3 was developed before the idea of an object-oriented model was widespread. The transition to the object-oriented model reflects an increased customer demand for it. ABAP Objects uses a single inheritance model and full support for object features such as encapsulation, polymorphism, and persistence.

2007年，专注于磁盘备份及灾难恢复业务的Data Domain公司正式进入中国市场。首次访问中国的Data Domain公司销售副总裁David Schneider在接受记者采访时也表示：“中国市场是Data Domain公司未来成长的关键点。”

竞合

在各种关于2007年中国存储市场热点的预测中，重复数据删除技术都是不可或缺的一项。近两年，基于磁盘备份的技术和产品开始大行其道，而重复数据删除技术的引入，无疑将大大增强磁盘备份的优势。

如今，越来越多的企业已经认识到信息数据的重要性，因此数据备份成了企业的基本应用需求。据专业市场分析机构预测，全球数据备份及容灾市场总额达50亿美元。传统上，人们习惯使用磁带产品进行备份。但是，随着备份的数据量成倍增加，人们对备份的可靠性、速度以及数据的恢复提出了更高的要求，而磁带备份在这些方面显得有些捉襟见肘。备份的目的是为了更有效地恢复数据，因此，数据恢复是否可靠、安全和快速就成了用户选择备份产品时的一个重要依据。

磁盘备份的兴起确实给磁带产品的生存和发展带来了冲击，尤其是重复数据删除技术的应用，客观上大大降低了磁盘备份的成本。即使是这样，磁盘并不能完全取代磁带，两者间是一种竞合的关系。在某些要求快速恢复的应用中，磁盘是比较理想的选择；在数据的长期保存和归档应用中，磁带则是十分必要的；而由磁盘与磁带构成的解决方案可以为用户提供更完善的数据保护。

近期，许多存储厂商纷纷推出具有重复数据删除功能的磁盘备份产品，而作为这一领域的先行者，Data Domain的产品已经是第三代，其技术成熟度和可靠性毋庸置疑。David Schneider表示：“对于备份产品来说，可靠性是第一位的。为了保证数据的安全和可靠，Data Domain的磁盘备份设备采用了RAID 6技术，而且所有硬件都是冗余的。此外，在数据压缩的过程中，Data Domain的磁盘备份产品会不断地从头检测被压缩的数据是否正确，从而保证了备份数据的安全。”

专注

Data Domain公司成功的关键在于专注，多年来在磁盘备份技术方面的积累，使得Data Domain在此细分领域保持着技术优势。这种专注同样表现在市场开拓方面。David Schneider表示：“对于刚刚进入中国市场的Data Domain来说，最紧迫的任务是建立良好的声誉，在用户和合作伙伴的心目中树立高可靠、高可用的品牌形象，而不是急于发展代理商。”Data Domain选择合作伙伴的首要原则就是专注，因此与同样专注于数据安全领域的解决方案和服务提供商威视数据合作可谓水到渠成。2006年下半年，双方就开始了合作，短短几个月时间，Data Domain在中国的客户数就从零增加到5个，覆盖金融、政府、制造、教育等行业。

据悉，Data Domain公司的全线产品都可以向中国市场供货，而Data Domain公司的北京代表处也在积极筹建之中。

【发表评论 1条】

如今这个ERP盛行的年代，对于企业和学术界，该不该使用ERP这类问题，我想已经不再是一个很好的讨论话题了。随之而来的是"ERP普及化"、"ERP个性化"、"将ERP进行到底"等一系列高昂的口号。我们在赞叹ERP实施人员勇气的同时，更应该以我们尽可能的热情去支持"ERP事业"，毕竟它是一项"全员"参与的事业。
　　企业在ERP应用的过程中，有经历成功的喜悦，也有遭遇失败的痛苦。我们暂且不需要讨论企业应用ERP成功与否，更不能以成败论英雄，因为每一个ERP应用者面前永远都有一个很实际的需要解决的问题：对于ERP上线后的企业，如何让ERP与企业业务流程更好地集成，从而提升系统效率？
  一直以来，ERP的存在就注定了它与BPM(业务流程管理)的渊源，一方面是ERP系统本身固有的流程与企业现有组织与流程变革之间的冲突和磨合；另一方面是随着企业和软件商在ERP深入应用和研究，一体化和自动化的要求与ERP目前面向功能的事务处理系统还存在着矛盾，它对整个业务流程缺乏有效的控制和管理，企业在不断地流程管理和优化中，对ERP系统的柔性适应性也提出了挑战和要求。
　　当前，不少ERP供应商也已经将工作流程系统作为他们产品的一部分，还有一些厂商在此基础上提出OA或者BPM与ERP集成的解决方案。流程管理是企业管理的基础，而ERP是运用了信息技术的信息流程，无论是用何种解决方案,都不能忽视BPM和ERP之间的密切联系。
　　BPM与ERP，如何集成？
　　我们将企业流程管理的英文缩写BPM拆开来看，B、P和M分别指企业的业务、企业的流程和企业的管理，虽然涉及的范围很宽泛，但有一点始终离不开那就是组织的业务，因为只有搞好了组织的业务这一利润来源的基础，才谈得上组织的绩效和组织的发展。可以这么说，企业流程的优化、增值作为一条主线构成了整个BPM的核心。
　　ERP涉及的内容包括企业的人、财、物、产、供、销等方面，内容丰富且非常的复杂，到现在为止ERP发展到了新的阶段ERPⅡ，这不仅深化了ERP的内涵而且扩大了ERP的外延，从以前的局限于企业的内部资源延伸到了企业的外部，供应商、客户联系更加紧密，逐渐模糊了供应链管理(SCM)和客户关系管理(CRM)之间的界限，这样一来也形成了ERP族群的概念。
　　如果将BPM与ERP按照结构化与非结构化以及数据化与非数据化进行分类；那么BPM较多地体现了非结构化、非数据化的特征，ERP则体现了很强的结构化和数据化特征。这两种本就"碰"不到一起的类别，如何集成？如何结合并优化？这好像不现实，但是恰恰由于此种原因则更需要集成。很显然，BPM与ERP之间有一个集成的前提问题。
　　那么，什么是BPM与ERP集成的前提呢？至少有这六个方面的前提：
　　● 组织具有集成的意愿；
　　● 良好的组织内部环境、企业文化；
　　● 组织最高管理者的决心和推动力；
　　● 务实、专业、高效的流程"诊治"团队，包括外部专家和组织内部业务骨干；
　　● 流程存在不断优化的可能；
　　● 具有平台化技术的ERP系统。
　　流程管理贯穿ERP始终
　　企业的布局
　　记得第一次去杭州，杭州的美景就不用说了，我想去过的人都能感受到；可给我印象更深的是杭州的道路很通畅，车开得很快，况且那天还是周日。我们想到的车能开得快的正常要素有：道路宽阔、地势平缓、人流量少、车少、指挥的交警多等。可是这与杭州的实际情况恰好相反，杭州的道路特别是西湖边的偏窄；杭州的城市多山，道路大多数起伏不定；杭州是旅游城市，人流量很大、车也少不了哪里去；可是为什么道路如此通畅呢？我想这与杭州的城市规划、城市发展综合布局也就是整体架构密切相关。
　　一个组织的流程和ERP系统应用之间集成的紧密与否，首先也应该从该组织的结构是否合理上找原因。我们知道，一个组织的战略方向决定了它的业务模式，业务模式决定了组织的结构，而流程从属于组织架构；也就是说，流程管理的好坏、组织能否对流程管理赋予足够的重视，其直接的决定因素就是组织的结构。
　　正如上面我们提到的‘杭州道路为何如此畅通’这个例子中所体现的，杭州的城市布局、城市规划就像企业组织的架构，而车流、人流就像组织的流程，对道路通畅直接起决定因素的是杭州的城市架构、规划布局，只有合理的布局和架构才能从根本上改变组织的流程。
   众所周知，有关组织流程方面的变革或优化，大致经历了BPR(流程重组)-BPI(流程优化)-BPM(流程管理)三个发展阶段。从这三个阶段可以看出，对于组织流程方面的工作，业内一直都在研究探索更好的方式方法；然而无论是组织流程的改革、优化还是管理，对于组织流程的变动都不是轻易能办得到、办得好的事情，一点很很重要的原因就是：变动流程往往需要牵动或影响组织的结构。
　　为此，有些组织在考虑架构、设置职能部门的时候，就单独设立了一个"流程管理部门"或"流程管理专员"的岗位，并逐步淡化以往以职能部门为中心的组织模式。例如，在某著名家电集团的组织架构中，在营运管理部门中就设置了"流程管理专员"一职，以提高组织的整体运作效率为目的，专门处理企业流程方面的事务诸如组织流程的制定、修改、优化。"流程管理专员"的直接领导是营运管理部经理，营运管理部经理的直接报告对象是集团总裁，可见"流程专员"这一岗位的高度。
　　所以，现代组织在制定管理架构时，往往在组织架构中预先定义了"流程管理部"或"流程管理专员"，作为整体架构的一个组成部分，为组织的BPM和ERP之间的集成提供了一种不断优化的可能与愿景。　
　　在企业不断变化和调整组织的同时，ERP的架构也正在酝酿着变化。如果说之前ERP的实施是为了固化企业的管理流程，后续ERP将会考虑到基于流程方向的发展，使得IT方案更加灵活，随时适应企业组织结构的变化，那个时候， BPM将成为ERP方案的"心脏"。当然，这需要一个很长时间的探讨和应用实践过程。
　　ERP与组织流程
　　事实上，企业及其IT系统面临的最大挑战来自于企业的业务流程。对于企业的流程来说，高度不确定性是其最本质的特点之一。现在，大多数企业的流程已经成为业务环境中的一个组成部分，这并不是企业经过周密的计划得到的，而仅仅是对做好事情的一个自然的反应。企业的流程一般都是贯穿于企业系统之中的，通过流程加强系统与企业中个体员工之间的联系。并且流程通常都是按照一定的规律来进行调整以便满足新的客户和新的业务环境要求。
　　为了让组织的BPM和ERP之间能够更好地结合，企业应当从组织流程上考虑需要注意的几点：
　　● 培养组织的流程管理意识，制定切实可行的流程；
　　● 企业领导层首先要意识到流程优化的价值；　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　● 一定时期内，组织的流程要相对固化；
　　● 组织的所有成员都要牢记组织的每一个流程，这是工作效率不断提高的保障之一；
　　● 流程不是制度，不要将流程管理做成企业管理规范；
　　● 将对流程的管理看成是对流程的优化，特别是要区分流程变化前后的差别。
　　"目标明确、执行到位、不断优化"贯穿组织BPM和ERP之间集成的始终。在整个过程中，整个组织的流程意识、相对固化可行的流程、流程优化的价值、流程优化如何衡量、流程化的ERP这些都是需要重视的问题。
　　我们可以从三方面来考虑：改变企业业务流程适应ERP系统流程、改变ERP系统流程适应企业业务流程、企业业务流程和ERP系统流程都有所修改达到集成优化的目的。
　　我们知道，从早期的订货点法开始到企业资源计划管理系统，在ERP的形成发展过程中，始终围绕着一个核心就是降低成本、增加利润来展开的。组织在采购、研发、设计、生产、销售、储运等各个环节流程的合理性与可行性，直接影响到整个组织的价值。实际上，再先进的ERP系统或多么优秀的组织都存在这样或那样的问题。
　　某变压器生产企业，在成功上线了某ERP软件之后发现有的企业流程在ERP中无法实现。例如"在接到一批销售订单后，该变压器生产企业为了保证客户所需变压器产品的及时交付，计划部门进行计划分解、采购部门准备物料、生产部门排产并做生产上的相关准备。
　　当该生产任务进行到一定程度这批订单还没完工的时候，销售部门又接到了第二批销售订单，可是第二批销售订单所要求的产品交货期比上一批正在组织生产的订单交货期还要早，而事实上，该变压器生产企业的生产能力有限，无法同时组织这两批订单的生产。
　　为了满足第二批订单的交货期要求，手工操作的解决办法是：实际生产中停下第一批还没完工的订单产品而转向组织第二批的订单生产；这样一来，订单处理上要求的流程或实际生产中要求的流程与ERP能实现的流程之间产生了难以调和的矛盾"。
??? 为什么出现了这种情况？我们可以做如下的分析：该变压器生产企业经常出现这种情况吗？销售部门签订合同、拿到订单需要经过审批环节吗？销售部门和生产部门之间经常沟通交流、互通信息吗？正在组织生产的第一批订单的半成品全部或部分可以直接作为第二批订单的半成品吗？是否可以增加机器设备和工人？是否可以和客户交涉修改交货期？整个生产环节的时间可以缩短吗？可以减少生产环节吗？......（转自支点网）
　　解决这些问题的办法可以从改变企业原来的业务流程上考虑、改变ERP系统的流程或两者都有所改变来考虑。如何改变企业业务流程，我们可以考虑对整个企业供应链优化或者对其中的销售、生产、研发、采购等其中之一作为切入点进行优化调整，甚至例如从销售环节中的订单审批子项作为优化调整的切入点；对于如何改变ERP系统的流程来说，一方面是ERP系统的设计思想、整个ERP系统的架构、是否可灵活配置业务流程、是否可简便二次开发或客户化等这些都是作为ERP系统需要考虑到的；对于有些特别复杂或不容易从企业业务流程或ERP系统流程单方面来优化的，可以考虑两者都做适当的调整来实现。
   流程引擎与新一代ERP
　　企业管理个性化与传统ERP系统功能相对固化之间的矛盾是企业信息化面临的最大问题。
　　迈克尔.哈默把流程定义为一系列业务活动，但在传统的ERP中，我们只能看到活动，而看不到流程。所以，在传统的ERP中看不到一项业务最后是如何完成的？参与者有哪些人？各个环节在任务中是如何协作的？这个流程占用了哪些资源？这个流程创造了多大的绩效？如何评价这个流程的绩效？如何评价一个流程与其他流程之间的联系？如何进一步改进这些流程？这些问题是新一代ERP需要考虑的问题。
　　所谓流程驱动的ERP是相对于数据驱动的传统ERP而言的；两者的本质区别是，传统ERP的业务活动实际都是和数据模型绑定在一起，新一代ERP的业务活动则与流程模型绑定在一起。新一代ERP的业务活动与业务流程、业务处理、业务数据、组织架构串连在一起，并通过统一的流程驱动引擎牵引流程到各个节点的用户界面。这样，用户就可以在"常用流程"界面直接进行流程处理，或查看相关流程的处理状态。
　　那么新一代ERP如何做到随需应变的？
　　● 支持自定义的业务单据；
　　● 通过工作流，实现流程的灵活定义，随需调整；
　　● 通过软件平台工具，支持合作伙伴与客户的二次开发。
　　在新一代ERP系统中，流程管理员可以采用可视化的流程配置器对业务流程进行管理。
　　流程管理员主要管理四个流程要素，即"活动"、"路由"、"审核单元"、"流转线"。"活动"对应各项业务活动，如：提货单维护、凭证维护等；"路由"对应流程的条件判断，如：移库单维护后既可能维护运输单也可能维护出库单，这里的判断就是通过"路由"来判断；"审核单元"对流程进行审核；"流转线"则是对应流程方向。通过这四项元素的合理配置，便可组成新的业务活动流程，简单明了。
　　近几年，欧美国家对企业进行过一项调查，结果显示在已经上了ERP等信息系统的公司中，有80%的企业反映如果给他们一个机会重新再做ERP，他们将首先优化生产和管理流程。企业对流程的认识，已经不是个新话题了。
　　可是，为什么还是有那么多的企业在实施了ERP之后才会回过头来反思实施之前的流程优化之痛？这个调查不仅仅反映了企业在实施ERP之前对流程认识的不足，而且更多地提醒我们，不仅对于企业实施ERP之前，对于所有已经上线ERP的企业，都应当认识到企业业务流程管理从来都不是一劳永逸的事情，企业真正需要的是一种持续优化的意识。而对于ERP软件商和实施顾问来说，对流程管理与ERP应用道路的探索依旧漫长。

开源技术可能不会统治整个世界，但是它将发现适合自己的一个非常广阔的舞台。可以确信的是，现在不管是大型企业还是小型企业都更喜欢在它们的服务器上实施开源技术。
　　业界分析家说，越来越多的软件公司开始把开源的目光转向了企业的关键业务系统－－ERP和BI系统。

　　开源技术开始融入ERP和BI
　　ERP是一套信息系统，它把公司内所有部门和业务功能整合到了一个计算机系统中。ERP运行在单一的数据库上，使不同的部门可以通过它来共享信息和互相交流；商业智能系统则用于对数据进行挖掘，大多数商业智能系统都具有相同的基本功能：从数据库中提取数据，然后提供分析报告。
　　现在不仅仅是最终用户开始使用开源ERP和商业智能系统，ERP厂商也开始在其产品中试验开源技术。如，SAP和甲骨文正在把目光投向Linux，希望以此降低系统的总拥有成本。分析家Albert Pang表示，支持Linux和JBoss应用服务器的ERP系统已经变得非常普遍。“过去的ERP系统实施中存在如此多的缺陷，以致于ERP系统经常超出原先的预算或实施时间。开源技术的到来极大减少了与建立大型架构ERP系统相关的一系列令人头疼的问题。”
　　开源商业智能软件开发公司MarvelIT的CEO Rick Mortensen说：“中小企业因为成本过高通常不去考虑实施ERP和商业智能系统。现在，开源技术使软件和支持成本极大降低，中小企业可以考虑实施一些典型的企业功能了。因此，开源系统将是天生的最佳选择，尤其对中小型企业来说。”
　　除了成本因素外，部署开源ERP和商业智能系统还有一些实际的理由，包括可修改源代码、维护和服务能得到来自开源社区的支持。
　　不管开源专家承认与否，开源ERP系统和BI系统还不会在短时间内大范围地占领市场。不过，这些应用程序的影响力正在不断变大。至于大型企业是否能大范围地采用，所面临的不确定因素还有很多。“开源ERP和商业智能应用没有通过测试阶段，它们能不能满足业界的特殊需求还有待考验。但如果你感觉系统的维护费用在不断上升，不妨试验一下开源技术。”Pang说。

　　开源ERP面临个性化和人才挑战
　　毫无疑问，开源ERP解决方案将会从传统软件应用市场分得一杯羹，尤其是从那些使用C++或Java编写的软件应用程序中。Pang表示，这时候将会有一些重要的开发者乐意围绕开源技术作出改革和创新。但问题是，这些开源ERP和商业智能解决方案已经做好进入黄金时期的准备了么？
　　企业应用顾问公司首席分析家Joshua Greenbaum认为，开源技术适合只需要基本通用功能的所有领域，因此它已经广泛地应用到各个行业，同时还有一些开源社区技术专家乐意参与到开源的过程中。
　　但是，ERP系统并非普通的通用系统，要根据不同公司的业务需求进行大量的定制并且实施，而可以创建开源ERP系统的行业专家的数量是非常有限的。“今天的ERP世界还存在一个巨大的金库，相关的顾问和开发人员可以得到很好的报酬，因此他们没有足够理由跳到开源这艘船上。”Greenbaum说。
　　尽管还没有大量开发者加入到开源ERP项目中，基于Linux的ERP系统的部署近两年依然增长了9个百分点，现在该系统大约占了ERP市场的1%。据IDC预计，到2008年非商业化ERP应用的整体市场将达到360亿美元。
　　“当业界开始更广泛地使用XML标准后，通过一大批技术厂商，用户将能很好的解决支持问题，而且启动投资也将最小化，”Pang说：“它由此产生的市场影响决不是一个开源ERP项目能带来的，因为单一的开源ERP系统无法满足数百万客户的需求。”
　　这反过来也说明，开源ERP系统还有很长的路要走。目前很多开源ERP系统已经开始尝试运行，包括Compirere、ERP 5、OpenMFG和Fisterra。来自CTG的信息化顾问Geert Claes说：“这3个项目都具有潜在的大范围的功能，但是开发者可能还需要花费更多时间来使它们的工具更友好。”
小企业成开源BI最大受益者
　　BI与ERP系统所面临的情况则有所不同，目前很多的开发者和实施者已经表示愿意参与到商业智能系统的开源过程中。Greenbaum表示：“假若你想为特殊的行业建立商业智能系统，就不得不面临和开源ERP一样的困境，没有太多的专家可以咨询；但是，开源模型中的基本报表工具用起来还是非常不错的。”
　　商业化的商业智能软件和相关的咨询服务通常需要高额的费用，因此廉价的开源商业智能系统得到迅速发展。Red Hat和JBoss的开源商业智能（BI）项目不会对用户收取授权费用，但Red Hat还是在咨询、支持和培训方面收入不菲，因为客户需要对开源的商业智能解决方案进行定制，以满足自己的特殊要求。这再一次证明，开源软件并不是免费的午餐。
　　Claes预测：“由于开源商业智能软件不够成熟，还不足以被大型企业广泛采用。需要进入商业智能领域的中小型企业是其早期的用户。随着开源商业智能项目变得越来越成熟，它将给那些商业智能软件巨头们带来压力——像Cognos和Hyperion等。”
　　Pentaho是最被看好的开源商业智能项目之一，也是专家建议关注的开源商业智能项目之一。Pentaho的核心团队是由具有成功创建过商业智能系统的技术专家组成的，他们大多来自顶级的商业厂商，例如Business Objects、Cognos、Hyperion、IBM、甲骨文和SAS等。
　　Greenplum、JasperSoft和Kinetic网络三个公司在2005年8月通过一个叫做Bizgres的项目发布了一套完整的开源商业智能程序。JasperSoft还提供了一个叫JasperReports的基于Java的开放性报告工具，它可以在Java软件环境中创建简单报告。至今为止，该报告已经被下载了100多万次。另外，像MarvelIT和Actuate也正在开源商业智能系统领域获得更多的注意。

北京 2007-01-08(中国商业电讯)-- 2006年,连锁零售业主力企业完成了40多次兼并重组,为2007零售业大规模的IT系统整合埋下了伏笔。
　　12月24日,首次提请全国人大常委会审议的企业所得税法草案明确规定:内资、外资企业适用统一的企业所得税法,新税率确定为25%。若审议通过,本土零售企业的利润率将显著改善,其在IT建设方面的投资比例也有望提升。
　　易观观点
　　2007年零售业将以信息化带动产业升级,总IT投资预计将超过一百亿元。POS-ERP是IT建设的重点,对其总投资预计可达15亿元。
　　易观分析
　　1. 零售业增长势头良好,且明年可能有并税的重大利好,IT总支出将随之增长
　　2007年是我国“十一五”规划的第二年,从改革开放以来的历史看,每个“五年规划”第二年的经济和投资都快于上一年(1987年和1997年例外)。而从我国近几年物价指数和商品供求关系上看,投资较快增长没有对居民生活造成不良影响,投资没有挤消费,这种情况在2007年仍将继续下去。预计零售业销售总额也将随之提升,IT总支出的绝对值必然增长。
　　此外,全国人大常委会审议通过内外资并税的可能性非常大,国内零售业的利润率有望明显改善。
　　因此,即便IT支出占销售总额的比例无显著变化,IT总支出的绝对值也将增长。
　　2. 兼并重组产生IT系统整合需求,IT支出占销售总额的比例可望提高
　　目前,我国零售行业的IT投资占零售总额的平均比例不到0.2%,连锁百强此比例约为0.5%,而国际零售巨头则普遍在2%以上。
　　2006年,中国流通领域频繁发生大规模、大范围的“兼并重组”共计40多起,包括全球最大的家电企业百思买兼并五星,国美兼并永乐,王府井全额收购长安商场,物美兼并美廉美和新华百货等。
　　零售业兼并重组的动机是想通过整合资源实现优势互补、实现规模效益,达到做大做强的目的。而并购之后的整合,信息系统必然先行,尤其要解决异构的信息系统的整合。但是,单凭升级原有的管理系统、或依靠EAI集成难以达到预期目的。
　　事实上,维护多个陈旧系统的成本往往比建设ERP新系统成本更高。首先,各异构系统在不断升级,相应的接口也要不断改变。其次,不同的系统输出的数据不一致,同一个数据在不同的系统会出现不同的结果。第三,旧系统的维护成本持续增高,在硬件、机房等设备上的成本也非常高。
　　因而,预计这些完成并购的企业将选择基于新的技术体系架构的ERP系统来做升级和整合。例如物美集团,2006年完成多项并购之后,选择了国际领先的ERP软件来整合集团内的异构的核心IT系统,从而成为国内首家考虑实施国外大型套装ERP系统的以连锁超市为主要业态的零售企业。预计,国美在顺利完成与永乐的公司层面的整合之后,明年也将升级原有的、武汉金力提供的ERP系统。
　　综上,兼并重组产生的IT系统升级将使IT支出占销售总额的比例显著提高。
　　3. 业内信息化标杆项目显现效果,零售企业对IT投资的回报更信服
　　易观国际曾预测: 2006年零售业IT总投资规模将达84.31亿元,而POS-ERP约占1/8,达10.8亿元。截至目前的不完全统计,实际零售业IT投资已达到或超过这一预期。苏宁电器SAP/ERP项目投资即达八千万人民币,是SAP在全球零售业签下的规模最大的项目。图:易观国际预计连锁百强2006年销售额将达9907亿
　　按照以上连锁百强销售额的预期,按照0.2%的比例估算,仅连锁百强2007年的IT投资就将达到 27.938亿,而零售业IT总投资预计超过一百亿元。
　　物美集团的ERP项目将成为明年零售业信息化的又一亮点。受苏宁、物美等业内信息化标杆项目的影响,以连锁百强为代表的零售企业将加大以POS-ERP为核心的IT投资。
　　对于家电连锁、连锁超市、连锁品牌专卖店:
　　对IT咨询实施方要深入了解和慎重评估,尤其应考察同业态的实施案例。实施过程应遵循“分阶段、从试点向全国推进”的稳健策略。已完成兼并重组的企业,应当比较两种IT整合路径的投资回报率:整合异构系统,或者实施全新的ERP系统。
　　对于为零售企业提供POS-ERP的厂商:
　　应着重关注四类业态:家电连锁、连锁超市、连锁品牌专卖店、百货业。受标杆企业的信息化项目的引领,这四个业态明年将有更多企业部署或升级POS-ERP。

狮子和基督徒

一个很虔诚的基督徒到非洲丛林探险, 不幸脱队迷失在丛林中, 接著更悲惨的事发生了。一只狮子发现他, 便开始追杀他, 他没命的跑啊跑啊！ 终于让他逃到一棵树上, 可是那狮子也不愿放弃的在树下等。天黑了，他又饿又渴, 于是他开始向上帝祷告: 上帝啊! 请您将这只噬血的狮子变成基督徒吧！话刚说完, 树下的狮子说话了: 亲爱的上帝, 谢谢您赐给我这顿丰盛的晚餐吧！

Job Description:

Key responsibilities may include:

Performing application design and architecture components
Performing process and functional design activities
Creating functional requirements as an input to application design
Developing and testing detailed functional designs for business solution components and prototypes
Performing application build, test, and deploy activities
Planning and executing data conversion activities
Driving test planning and execution

Professional Skill Requirements
University education background, bachelor degree above
Proven success in contributing to a team-oriented environment
Proven ability to work creatively and analytically in a problem-solving environment
Desire to work in an information systems environment
Excellent communication (written and oral) and interpersonal skills both in English and Chinese.
2 to 10 years implementation experience in SAP FI/CO/MM/SD/PP/BW/HR/PS/PM/CS/BASIS
Welcome to online apply our position via www.accenture.com.cn or send your CV to lu.you@accenture.com directly

Job Description:

Key responsibilities may include:

Performing application design and architecture components
Performing process and functional design activities
Creating functional requirements as an input to application design
Developing and testing detailed functional designs for business solution components and prototypes
Performing application build, test, and deploy activities
Planning and executing data conversion activities
Driving test planning and execution

Professional Skill Requirements
University education background, bachelor degree above
Proven success in contributing to a team-oriented environment
Proven ability to work creatively and analytically in a problem-solving environment
Desire to work in an information systems environment
Excellent communication (written and oral) and interpersonal skills both in English and Chinese.
2 to 10 years implementation experience in SAP FI/CO/MM/SD/PP/BW/HR/PS/PM/CS/BASIS
Welcome to online apply our position via www.accenture.com.cn or send your CV to lu.you@accenture.com directly