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系统配置不匹配，将给运维支持带来困难和危害。