【IT168 技术文章】

    ERP项目的实施和推广，是这几年国内很多企业信息化工作的重要内容，目前已经有很多成功案例。这种形势下，是否应该上ERP系统的概念之争，已经不再是企业领导或者CIO们考虑的核心问题，他们更加关注ERP系统的实施效果和运维。如何更快更好地实施ERP项目，如何提供可靠的运维保障，充分挖掘ERP系统的潜力和价值，已经越来越成为ERP项目管理的关键命题。

    保持实施和运维的一致

    笔者所在的某大型国有企业A自2005年开始，在集团总部的统一部署下，成功进行了横跨多个业务版块，纵跨多级管理组织的SAPERP项目实施，形成了集团内部不同的标准业务蓝图模板，培养了大量具备实施能力的内部顾问，取得了诸多成绩。三年后集团下属的各业务单元都已在SAP平台的支撑下进行业务的经营管理。同时ERP实施团队的主要业务由实施转变为运维支持。

    A集团的SAPERP实施，采取的是大集中策略——服务器和数据库资源都集中在集团总部，且所有上线单位的业务并存于同一个生产系统环境中。相应的，系统的配置和定制开发也完全由集团总部集中控制和管理。随着数批ERP项目的滚动实施和成功上线，A集团的ERP系统越来越庞大复杂，对集团的项目实施、运维能力两个方面都提出了更高的要求。

    通过各种渠道反馈的信息，A集团意识到，必须找到对策，解决如何更好更快实施ERP，提供可靠的运维保障等问题。并且，这已经成为国内大型企业实施和运维ERP过程中的共性问题。

    从2008年初开始，A集团总部成立了专门的项目组，在外部咨询力量的配合下，结合自身特点，升级改造了与SAP系统集成的ERP项目管理平台，对ERP项目的实施和运维管理进行了初步的探索和实验。

    ERP项目的实施和运维构成的是一个闭环的生命周期，理应实现良性的互动和可靠的管理。但实际情况却是，企业难以保证实施和运维的一致性。换句话说，运维当中存在的问题，有些是实施过程存在先天不足造成的。反过来，如果实施的工作能扎实，运维就能更加轻松和规范。项目实施是全周期的起始，也是最基础的部分。因此，着眼于完整周期，A集团提出了以流程驱动的SAPERP实施方法。

    别身在聚宝盘还捡不到宝

    一般来说，在ERP项目实施完成后，成果会以海量文档的形式保存下来。进入运维阶段，虽然对于系统变更有流程管控和记录，但难以及时回滚到已归档的成果文档中，这样就可能造成管理文档与SAP系统之间不完全匹配。这样，不仅给运维工作带来了隐患，更可惜的是，不能对ERP系统解决方案的全生命周期进行有效跟踪和管理，无法形成集团ERP系统有关的知识库，无法为运营维护和推广实施积累经验。这种情况就如同一个人身陷在聚宝盆里，双腿被埋难以动弹，目力所及满箱子都是珍宝，却只能够到手边的那一点点。更糟糕的是，新的宝物还在不断地生成，眼看不断溢出箱子掉落一地，他却毫无办法。

    因此，企业必须将前期ERP项目实施的成果和经验固化下来，构建一个先进的项目实施、支持运维平台，满足全面管控的需要。从长远考虑，企业有着滚动的ERP项目实施和推广应用需求，如果充分复用前期成果，建立起适合集团各专业产业链的SAP实施标准模板，将会降低应用深化的难度，从而减少对外部资源的依赖，大大加速未来新增及推广项目的实施进度，将直接为企业节约成本，创造价值。

    因此，我们必须在ERP项目的实施和运维阶段具备管理能力，能够对于任何业务需求及时做出反应，始终记录并优化需求导致的系统变更。

    这种随需而变的管理能力，应该是企业需要具备的。根据我们的经验，企业想要掌握这种高级能力，首先必须在组织内部确定以业务流程为实施导向的指导思想，继而优化工作模式，借助于SAP其他的信息系统来强化其应用，逐步形成有企业自身特色的工作模式。这种模式，我们将其定义为流程驱动的SAPERP实施方法。

    有效的工具和方法论

    A集团ERP项目组在项目管理和运维方面已经使用了一系列的管理工具，但无法深入到业务和系统的层面，因此我们需要引入新的工具。经过反复咨询，考察比较当前的技术状况及成熟解决方案，我们根据集团的需求，制定了将业务流程管理和SAPERP系统的项目管理和解决方案实现集成的框架目标，并通过招标最后确定了以IDSARIS流程管理平台和SAPSolutionManager系统相结合的技术方案。该方案充分利用了两个成熟管理平台各自的强大功能，并定义它们在SAPERP项目实施和运维工作中的角色分工和工作界面，保证了其成为一个有机的整体，以实现流程驱动SAPERP实施方法的有效执行。

    这种组合方案突破了ERP系统实施和运维管理难点的关键需求。我们通过引进流程管理平台、SAP项目实施支持工具、SAP平台运维支持工具，完善ERP项目和系统维护管理体系，为企业流程管理做出一定的技术和人才准备。

    在需求管理和变更管理方面，我们规范了现有的支持和运维工作流程，将业务需求、解决方案、系统实现的业务链有机连接，便于控制和追溯，以逐步适应企业内部控制的需要。

    这种组合方案提供了ERP项目实施的项目管理模板，以及一整套业务流程建模的规范，可以逐步固化ERP项目实施和运维的经验，加速实施推广。

    同时，它也完善了知识管理，能够实现ERP项目交付的集中管理，搭建易于管理的、可实时更新的完整的项目文档结构，并进行版本管理，有效减少文档维护的工作量。同时，它还可以集中控制并分发业务人员需要的各类文档和操作指南，实现可靠的知识转移。

    这种组合方案也降低了SAPERP实施与运维成本。引入ARIS和SAPSolutionManager可以帮助企业有效降低在SAPERP实施后期以及上线运行过程中，因业务需求不透明而产生的重复和冗余的工作。例如，在测试阶段，由于流程不易于被理解，产生的重复测试和遗漏测试的现象。对于SAPERP实施项目来说，使用ARIS和SolutionManager是在蓝图设计后，系统配置阶段开始，可以更明晰和明确地管理业务需求，开始发挥其有效控制SAPERP实施项目成本的作用，特别是在系统上线和持续改进的过程中，非常有利于SAPERP的运维与升级。

    这种组合方案为A集团建立了初始的业务流程地图，为今后内控和其他管理项目奠定了应用基础。利用ARIS业务流程建模系统和工具，A集团实现了业务流程与SAPERP系统SolutionManager模块中相关流程结构的双向同步，实现业务流程与系统配置的统一管理，达到了公司业务流程与ERPSAP系统正确挂接的目的。建立的测试体系为今后项目实施单位的回归测试、系统升级测试打下了基础，能够提高系统的测试效率。通过SolutionManager平台建设，A集团对ERP实施单位的系统变更和解决方案进行了全生命周期的集中管理，包括需求变更、业务蓝图变更、方案监控、配置变更以及测试管理等。A集团应用SolutionManager模块进行ERP项目实施及系统运维管理，指导并协同完成了公司的标准模板，便于未来在ERP项目实施和运维中推广应用。

    以上是对于工具选择的介绍，对于方法论而言，一般来讲，ASAP实施方法论是业内几乎所有人都知道的SAP项目实施方法论，但它在流程规划、流程搭建及上线后的优化和监控等方面存在不足之处。而流程驱动的SAP实施方法以AVE(ARISValueEngineering)方法论为基础，进行企业的全面信息化实施工作。

    AVE模型是在全球大量的ERP实施项目中提炼出的标准模型，通过这套已经在ARIS中进行建模的控制体系，我们可以完全转变以往的“IT驱动项目”的模式，达到“业务流程驱动项目”的模式。这也完全符合正在席卷全球的BPM/SOA(基于服务的架构)组合理念，SAP公司也已经将ARIS作为自己前端的BPM平台，将流程与IT更加紧密地集成在一起。

    AVE方法的主要特点如下：

    ·管理闭环：从客户期望看到的业务远景到信息化实施方案的产生、发展以及持续改进的整个过程，都是基于流程优化进行管理的。

    ·模型驱动：流程驱动SAPERP实施，是通过建立企业相关的业务模型，描述一系列相互关联的输入输出关系，这种关系的描述最终会成为对于一个完整的实施方案的描述。

    ·体系架构完整：AVE实施方法是从不同的角度处理客户需求，如流程、组织、应用系统和数据，保证体系架构的完整性。

    ·项目管理量化：通过模型状态如何有效反应客户需求和客户预期来对流程改进的结果进行量化。

    ·实施过程全线跟踪：需求和系统特征结合起来，最终提供的系统方案能够追溯到具体的业务需求。

    ·实施架构可以裁减：AVE工作包和交付物可以根据不同的项目特点进行客户化、定制化。

    流程驱动的SAPERP实施方法在横向时间轴上，主要由战略、业务蓝图设计、实施上线和运行控制四个阶段构成，项目实施工作内容由表及里、由此及彼不断扩展。同时在各个阶段对前一阶段进行检查，为SAPERP实施提供有效可控的实施方案。

    双向同步匹配业务和系统

    工具和方法都已准备妥当，那如何将其与企业的独特需求结合起来并落地实现呢？需求的实现将通过ARIS系统平台与SolutionManager系统协同应用来实现。在图1所示的流程图中，红色边框区域表示在ARIS软件平台中实现的业务功能，蓝色边框区域表示在SolutionManager中实现的功能，背景为浅蓝色的区域是ARIS与SolutionManager共同应用，协同完成的功能。ARIS与SolutionManager的协同是通过双向同步的方式来实现两个系统间的有效集成，进而满足业务和系统实现匹配和实施的需求。

    在使用如上所述工作模式的前提下，Solution是一个非常重要的概念。企业使用的SAP系统(包括所有组件，ECC/BW/EP/XI，包括所有已经上线的单位和未来要实施的单位，包括各种业务流程、业务模块、功能)总体就是一个SAP解决方案，一个只有该企业独有的SAP解决方案。从静态的层面出发，我们可以把解决方案理解为一个相对稳定的业务流程和配置的仓库，而我们所常说的项目，实际上只是用来形成解决方案的一个过程。从企业实施SAP的第一天开始，SAP解决方案就已经存在，随着SAP的各个项目的不断实施，解决方案就不断地成长，最终成为一个解决方案库。从动态的层面出发，解决方案本身在不断地变化，变化的方式有两种，一种是项目的变化(整体打包的、有计划的、目的明确的变化)，一种是运维的变化(小的、零散的、非计划性的、按用户需求的变化)。企业的SAP管理功能实际就是围绕着解决方案及其两种变化方式而展开。

    “我们的工作分工是按模块划分的，但建模从业务出发，我们的工作范围该如何划分？为什么还要搭建流程架构，只把详细的流程图画好不就可以了吗？为什么要将配置和流程挂接起来，之前我们只写一份配置清单就可以了啊？”……

    实施顾问在了解到工作模式的内容后，提出了一系列尖锐的问题。但是当大家意识到这样做带来的价值时，都认可了这种工作模式。同时在ARIS中基于最底层的流程搭建了两套流程体系，一套依据企业的实际业务，一套依据SAP的功能划分。当企业的管理者和业务人员看到层次明确、切分清晰的流程体系时，都认为这就是自己想要的东西。而SAP顾问从流程中过滤出了自己熟悉的T-CODE。

    A集团使用上述工作模式，是AVE方法论的一次完整而全面的使用，对AVE方法论的推广使用具有切实可行的借鉴意义。总结起来，它具有四大突出特点。

    第一，严密的项目实施逻辑。

    在项目实施路线上，分四个大的步骤，架构、设计、实施、控制，延续了ARIS一贯的从战略到设计、实施再到控制的整体思路，体现了循环管理的思想，既使得项目能够有条不紊地实施，又能够对项目质量进行监督和保证。另外，在实施步骤上，业务逻辑清楚，21个环节环环相扣，保证了项目的连贯性。

    第二，业务与技术的有效结合。

    该方法十分注重业务与技术的结合，且二者有主有次，首先从业务着手，然后落实于技术，最后再回馈到业务。在企业实践中，业务运行质量的好坏始终是上至管理者、下至普通员工关心的第一位的问题，而技术和系统只是实现业务绩效的有力工具。A集团本项目的21个详细的实施步骤正是这种思想的直接体现。

    第三，强调系统的动态和持续优化。

    在项目实施和运维工作中不仅仅追求在系统上线时系统内流程与业务流程的一致性，而且希望通过流程管理制度来实现二者长期的一致，即每当实际业务流程出现变化时，应触发ERP系统随需求而改变，以此来保证系统长期跟上业务变化的步伐，实现系统的持续优化以及跟踪。

    第四，重视知识的固化。

    实施过程中涉及到的建模规范、系统配置手册、流程管理制度等都以文档的形式加以保存，可以用于项目的跟踪管理，也可以用于指导其他相似的项目。

    但是该方法在实施过程中还存在一些不足，比如：

    ·蓝图设计文档的全部内容都维护在ARIS系统中时，自动生成的蓝图文档格式难以满足实际要求。　　·在SolutionManager中维护IMG配置项时，由于SolutionManager对蓝图架构的限制，无法精确对应。

    ·变更管理的刚性审批流程难以与企业的变更管理流程契合。

    ·它增加了ERP实施项目的内容，引入了新的应用管理平台，增加了实施步骤和难度，对于项目资源和实施顾问的能力有着更高的要求。短期内ERP项目的实施成本将提高，有一定的风险和阻力。但是从长远看，在打好基础后，回报会逐步显现。

    A集团的经验是，对于应用该方法中的一些不足和缺陷，还需在后续的项目和运维工作，逐渐加以改进和完善，使该方法切实地实现其提出的初始目标。

    1

    [商用频道] [企业采购] [办公打印] [投影机] [服务器] [网络与安全] [电脑][软件及服务]

    链接：ERP实施运维六大悬疑问题

    “我们提出的需求到底实现了没有？最新的设计文档是否包含了最近的变更需求？为什么要做这样的配置？测试是否覆盖了预设的业务范围？”

    在ERP的实施和运维工作中，我们经常会听到类似疑问和困惑。A集团以他们的实际经验总结了ERP项目实施过程中六大问题。

    问题一：难以保障企业的流程地图和SAP系统的完全匹配。

    ERP项目实施过程中，业务蓝图及其对应的需求和SAP系统中的业务对象没有完全对应，存在事实上两张皮的现象。而实际上，各层级业务流程地图应该得到准确描述，业务需求和SAP系统实现完全匹配。

    问题二：难以保障需求变更和系统变更的完全匹配。

    需求变更导致了系统配置的更改。而且，受其影响所致的操作步骤、流程、业务场景、项目蓝图等的变更无法准确评估，会导致测试范围过大或过小。

    问题三：项目成果未能集中管理、持续更新，也没有转化为模板进行推广。

    项目结束后蓝图设计、系统配置、测试文档等关键交付品都被束之高阁，运维过程中的更新与修改没有融入到原先的交付品文档中。正确的做法是启用解决方案记录实施成果，在SAP项目管理系统中建立集团标准模板，以及不同行业的应用模板，各下级单位应在标准模板和行业模板的基础上进行推广实施；实施结束后，将成果回滚，更新优化标准模板和行业模板支持运维工作在解决方案基础上进行。

    问题四：企业的信息化建设只重系统功能，忽略业务需求的问题。

    业务驱动、IT引领，使信息系统以满足公司业务需求、服务工作流程为首要任务，应该将传统的信息化建设“IT驱动项目”的模式，转变为“业务流程驱动项目”的模式。

    问题五：难以满足ERP项目对质量控制的特殊要求。

    目前，项目管理在ERP实施中已得到了充分的重视，但对IT类项目的质量控制要求，却缺少有效的管理手段。其实，可以借助于统一的SAP实施和运维管理平台，控制好关键路径的里程碑，来引导调整项目跟随路径的状态，从而满足项目管理的严格要求。例如，业务蓝图审批签署前，应锁定SAPECC开发系统，不允许将SANDBOX的配置传输进去。

    问题六：难以满足ERP项目对SAP系统配置管理的特殊要求。

    在SAP项目实施过程中，一般都启用了多个SAP系统(DEV/QAS/MOCK/PRD)，以达到充分测试检验系统功能和流程的目的。但是，缺少方便快捷的技术手段，让配置和系统管理人员直接检查比较各个目标系统配置。而且，系统配置文档记录的内容可能与当前SAP系统配置不匹配，将给运维支持带来困难和危害。