STE ERP系统升级项目-项目方案书-V1.0

客户深圳证券交易所文件名项目方案书项目ERP系统升级项目版本V1.0正本深圳证券交易所

ERP系统升级项目项目方案书 德勤管理咨询（上海）有限公司2013年6月28日

目录TOC\o"1-5"\f\u1. 证明文件 61.1. 公司概况简介 71.1.1. 德勤全球 71.1.2. 德勤中国 111.2. 营业执照 181.3. 项目咨询及实施人员简历 201.4. 税务登记证副本 211.5. 公司经营相关项目业绩和类似合同完成简况 221.5.1. 竞价单位业绩表 221.5.2. 德勤咨询在OracleERP相关领域部分大型案例介绍 221.6. 投标方近两年经审计的财务报表 311.6.1. 财务状况及资信说明书 311.6.2. 近两年的财务报表 331.7. 认证或其它资质证明 341.7.1. 德勤获奖情况（部分） 341.7.2. Oracle原厂授权证明 371.7.3. Oracle高级实施合作伙伴资质证明 381.7.4. 合同范本 381.7.5. 投标方认为有必要提供的声明及文件 511.7.5.1. 德勤OracleERP实施及支持服务能力 511.7.5.2. 德勤咨询业务能力特色和方法论 531.7.5.3. 德勤知识管理体系 542. 项目实施方案（技术参数） 562.1. 功能方案 572.1.1. 总体概览 572.1.2. 多组织访问 582.1.2.1. R12新功能 582.1.2.2. 升级考量要点 582.1.3. 法律实体 592.1.3.1. R12新功能 592.1.3.2. 升级考量要点 602.1.4. 子分类帐会计 612.1.4.1. R12新功能 612.1.4.2. 升级考量要点 622.1.5. 税务管理 622.1.5.1. R12新功能 632.1.5.2. 升级考量要点 642.1.6. 高级公司间管理 642.1.6.1. R12新功能 652.1.6.2. 升级考量要点 652.1.7. 应付管理 652.1.7.1. R12新功能 652.1.7.2. 升级考量要点 672.1.8. 总帐管理 682.1.8.1. R12新功能 682.1.8.2. 升级考量要点 692.1.9. 资产管理 692.1.9.1. R12新功能 692.1.9.2. 升级考量要点 692.1.10. 现金管理 702.1.10.1. R12新功能 702.1.10.2. 升级考量要点 702.1.11. 应收管理 702.1.11.1. R12新功能 702.1.11.2. 升级考量要点 702.1.12. 采购管理 712.1.12.1. R12新功能 712.1.12.2. 升级考量要点 712.1.13. 库存管理 712.1.13.1. R12新功能 712.1.13.2. 升级考量要点 712.1.14. 订单管理 722.1.14.1. R12新功能 722.1.14.2. 升级考量要点 722.1.15. OPM升级步骤举例 722.2. 技术方案 742.2.1. 系统升级方案 742.2.1.1. 背景 742.2.1.2. 前提 742.2.1.3. 要求的范围和目标 752.2.1.4. 升级技术方案 762.2.1.5. 技术方案概览 762.2.1.6. 技术方案阐述 782.2.1.7. 技术方案补充 822.2.1.8. 升级方案风险与应对 822.2.2. 客户化迁移方案 842.2.2.1. 客户化总览 842.2.2.2. 功能迁移（Form） 842.2.2.3. 报表迁移（RDF类型的报表） 852.2.2.4. 报表迁移（WEBPL/SQL报表） 862.2.2.5. 客户化开发工具 862.3. 关键需求点对点应答 902.4. 升级测试策略 932.4.1. 制定升级测试计划 932.4.2. 细化测试内容 952.4.3. 技术层面数据检查 952.5. 系统切换方案 962.5.1. 第一次模拟切换 962.5.2. 第二次模拟切换 962.5.3. 上线切换 972.6. 项目实施方案 982.6.1. 项目组织架构 982.6.2. 服务排期（项目计划） 992.6.3. 项目任务分工 1002.6.4. 项目交付物清单 1032.6.5. 服务承诺及优惠内容 1042.6.6. 项目实施方法 1092.6.7. 附：项目关键成员简历 1133. 竞价文件 1253.1. 附件一、竞价函 1263.2. 附件二、法人代表授权书 1273.3. 附件三、竞价一览表 128

概述需求分析和理解（Henry）项目难点分析（Henry）技术应答（功能顾问/技术顾问）财务管理功能模块需求主要功能需求要求实现方式相关模块备注说明1.FSG财务报表改进借助FSG行集和xmlpublisher,对FSG进行开发，保证报表运行速度快，美观总帐人力资源功能模块需求主要功能需求要求实现方式相关模块备注说明技术需求主要功能需求要求实现方式相关模块备注说明多组织功能修改修改客户化form，workflow，package，table，view中的代码，增加多组织安全代码二次开发提供ERP数据脱敏解决方案，建立满足脱敏要求的开发测试环境。系统技术方案参考克隆环境脱敏方案Discoverer报表100多张系统技术方案参考技术方案中的Discoverer迁移方案历史数据迁移标准模块的数据在11i升级时，Oracle补丁会自动转换；对应客户化数据表，在数据迁移过程中会具体根据功能方案，考虑转换策略系统技术方案整体技术解决方案功能方案总体概览在ERP升级过程中，如何保持原有系统功能可用性和历史数据准确性，是最核心的要求，因此，本次ERP升级，我们建议在立足“平稳过渡”的基础上，以“保证数据融合”为目标，通过多种应对策略，实现功能的平移和数据的融合。平稳过渡，需要把握三个原则：保持功能完整性：原系统所用的功能，在升级后的系统中，应保持完整可用；保持系统稳定性：升级后的系统，在系统性能方面，应具有一定的稳定性，确保日常业务正常处理；保持数据准确性：系统升级是数据库底层技术架构的问题，应不能对历史数据的准确性产生影响。在以上原则下，要实现从R11“平稳过渡”到R12.1.3的跳跃，将会面临多方面的难题，如所有原客户化程序需要重新移植；如此升级，功能范围涉及非常广，测试很难保证全面性等。针对这多方面的问题，德勤建议从“功能匹配，差异分析”和“多次模拟升级切换”两个方面去考虑。“多次模拟升级切换”的方式。系统标准功能随着ERP应用系统版本升级而升级，无需另外进行移植安装。为检验标准功能是否完整可用，需要对升级后的系统，进行完整的测试。为确保测试的完整性，我们建议对所用到的系统进行，进行完整的功能匹配，对每一项原有功能，明确列出新系统功能，新旧系统功能间是否存在差异，差异是什么，并对该差异的合理性进行评估。通过完整的《ERP升级功能匹配清单》，检查升级后的系统对原有功能的支撑情况。多组织访问R12新功能多组织访问控制（MOAC）是R12一项重要的新功能，通过多组织访问控制实现允许单一职责访问不同业务实体的权限控制，用户在权限范围内可以不必再申请多职责即可访问多业务实体的应用。通过将“安全性配置文件”分配给用户，限定用户可访问的数据权限，用户无需切换职责即可执行多业务实体的应用，用户可通过单一职责，在应用界面中，根据指定的业务实体进行数据输入、处理、提交请求等操作。升级考量要点设置多组织控制，需要定义包含多业务实体的安全性配置文件，分配至系统配置文件“MO:安全性配置文件”。通过定义系统配置文件“MO:默认的业务实体”可指定在表单或页面应用中的默认业务实体。11到R12的升级，需要考量用户多组织访问的业务需求，补充相关设置和验证数据迁移。法律实体R12新功能在R12版本中，法律实体在ORACLEEBS中由隐含的定义转为明确的法律实体。可以通过法律实体定义来应对不同国家法规和报告需要。法律实体结构允许分离于业务组织结构而表现法律组织结构。R12的新功能是具有指引用户创建法律实体流程的法人主体管理器。法人主体管理器，可以通过定义法律实体以应对多国家或法律制度的法规和报告需求。法律实体定义应用于以下业务处理：基于法律实体的付款公司间事务处理（法律实体间的贸易往来）税计算（基于税务的权限而登记的法律组织）银行帐户的所有权子分类帐事务处理的所有权（例：应付或应收）法律实体层的报告子分类帐事务处理题头除标识业务实体以外会额外标识法律实体。法律实体由以下信息确定：每一笔事务处理都会存在于一个业务实体，该业务实体归属于当前事务处理记帐的分类帐。如果该分类帐具有一个以上的法律实体与之关联，那么，法律实体层次结构会用于默认的法律实体。例如：在AR中法律实体层次结构应用于事务处理：事务处理类型批来源分配法律实体至事务处理类型或批来源是可选择的，只有映射至与业务实体关联的分类帐的法律实体才可以用于分配。如果没有其他的法律实体存在，业务实体的法律实体上下文中默认当前的法律实体。在默认法律实体上下文的值列表中显示的值（法律实体）必须关联了业务实体关联的分类帐。如果任何来源都无法找到默认的法律实体，用户在输入事务处理时需要明确提供法律实体。升级考量要点配置变更：移值当前数据到法律实体创建法律实体并分配至会计科目设置。'GRE/LE'类型的组织在R12升级中将做为创建法律实体的来源。数据迁移之后与'GRE/LE'类型的HR组织之间不存在链接，应用法人主体管理器创建法律实体。虽然作为法律实体升级的来源，在R12K,HR组织不能用于创建新的法律实体。配置现有的组织成为法律实体或适当的组织。使用法律实体的关联来维护业务架构（业务实体，库存组织、库存地点等）和法律架构间的关联。分配法律实体至公司间组织（如果使用AGIS）11到R12的升级，需要考量数据迁移的验证和相关设置补充。总帐和资产模块未涉及法律实体，而是应用帐簿或平衡段值。事务处理仍然基于分类帐排序，而非基于法律实体。如果多个法律实体共享相同的分类几属性（如：会计科目表，日历，会计方法），这些法律实体——根据业务需要共用相同的分类帐。可以为共享同一分类帐的法律实体分配平衡段值——推荐的，易于区分事务处理和报表。注意：共享相同分类帐的法律实体间的内部帐户要求标识公司段。如果法律实体的4Cs或分类帐选（如：日平均额，日记帐审批或序列）不一致，则必须分离主分类帐。如果基于法律的原因需要设置多个分类帐，也可以将多个分类帐组成分类帐集以便于事务处理。在R12中，业务实体与法律实体没有直接关系。通过分类帐同时关联法律实体和业务实体来确定业务实体与法律实体的关联。注意：法律实体与业务实体间没有单独的关联关系。子分类帐会计R12新功能Oracle子分类帐会计（SLA）在子分类帐应用中提供了一个通用的会计引擎以代替当前的会计处理流程。SLA升级包括从从11至R12迁移当前数据以确保业务操作的连续性.子分类帐会计的由11中各子模块的会计规则设置变更为统一在SLA进行设置，会计规则、事务处理创建会计科目的产生、标准报表等都有相应的变化。此功能有如下优点：会计科目产生的规则，在11中的部分客户化程序解决的问题可以通过应用层的设置完成，不必再进行客户化开发。会计科目的创建，11中基于各子模块创会计分录传送至总帐，在R12中,基于统一的SLA的共用程序创建并传送会计分录至总帐。系统预置的SLA的设置与11相同，用户的特殊需求，可以复制体系统标准设置而进行必要的修改。能够按照不同的会计事件自定义不同的会计科目组合，实现原先EBS无法实现会计分录个性化（如应付发票负债科目带上发票上的供应商信息）在子模块便能生成基于单据的会计凭证信息(如一张发票一张凭证的需求)以预付款举例，实施流程如下：以往来段为例说明SLA的优势，在原来11i中负债和预付的往来段科目需要在供应商地点单个维护，现在只需要设置SLA规则即可以自动生成。升级考量要点11中，有部分需求是通过客户化开发实现的(应收、应付、资产等)，基于R12中的SLA的新功能，11到R12的升级完成后，，需要考量新功能对客户化开发的影响和取舍、适当的方案优化以及数据的融合。高级公司间系统（AGIS）会计科目生成规则需要根据SLA的功能变化而进行相应的调整。SLA的变化对标准报表、客户化表、BI等的影响。税务管理（吴伟）11中的税，分别在应收、应付模块中设置税码，由应收、应付税务引擎在产生事务处理时进行计税。R12新功能R12中，统一在税务管理中完成税的相关设置，税务相关事务处理调用统一的税务引擎进行计税。税务的应用和税务信息产生的规则更加灵活。固定的计税规则变化为由用户可配置的计税规则；由各应用产品的单独设置变化为跨应用产品的设置；由各组织的单独设置变化为跨组织的设置；由多税务引擎变化为统一的税务引擎；由多个数据存储结构变化为统一的数据存储结构R12的税务管理的主要组成：税务配置选项和补充税务配置管理器税务确定处理税报表税模拟升级考量要点税的功能不会从11迁移至R12，在R12中税的相关设置需要补充：基于11中的税务需求，补充R12中的税相关设置；测试税务相关的业务流程，如采购到付款、销售到收款等税的相关标准报表的变化税的相关客户化报表的调整高级公司间（吴伟）R12新功能在R12中，高级公司间系统是一个新的模块（AGIS），取代了11中的公司间系统(GIS)，其主要组成部分如下：公司间平衡公司间事务处理公司间开票公司间调节升级考量要点高级公司间管理，匹配R12的新功能功能，根据业务需求完善系统设置和新功能的应用方案。根据SLA的新功能的变化：应用事务处理会计科目生成器定义事务处理默认帐户；将通过SLA事务处理会计科目生成器定义的默认帐户分配至应用的分类帐。高级公司间系统相关设置的补充标准报表的变化客户化报表的调整客户化功能的调整应付管理（Maozhimin）R12新功能应付模块相关的银行信息、供应商信息、应付选项、财务选项、付款等在R12中都有相应的变化，根据具体业务需求，需要完善相关设置和数据迁移和验证。银行信息：财务选项：供应商信息：应付模块的功能变化：供应商信息在交易社区进行管理发票行的功能变化应收－应付的对冲付款的功能变化由ORACLE报表技术实现到标准的XML支付格式由多模块管理的银行帐户信息变化为统一的银行帐户管理由多模块管理的信用卡信息变化为统一在付款中管理多组织访部控制的功能应用由基于外部系统的付款管理变化为内部的付款控制升级考量要点11中的供应商和供应商地点信息会自动在R12交易社会中创建供应商信息；数据库中供应商信息存储的表和相关视图的变化对客户化报表的影响；R12中供应商和供应商地点的变化，对应的交易方和交易方地点的影响(供应商合并)；供应商合并对合同管理的影响；员工供应商数据的迁移；供应商的开放接口仍然可用；11中的系统预置的自动付款程序和付款格式在R12中已失效，需要在R12中通过的付款设置完成；电子支付安全性控制的功能变化对相关应用产品的影响发票行的功能变化，数据库相关表的变化对客户化开发的影响汇兑损益和发票价格差异的分配行的变化发票中费用型分配行的数据迁移的变化数据库中的费用分配表已失效付款的功能变化对标准功能和报表的影响客户化的单据类别不能自动升级支付类型已失效，对所有报表的影响自定义的付款格式须修改为XML以适用于R12在R12中检查付款和电子支付的单据类别，需注R12中不再支持的单据类别；应收-应付对冲功能的应用总帐管理（吴伟）R12新功能总帐模块在系统设置、数据访问、事务处理等方面都有功能加强：集中的会计科目设置分类帐和分类帐集的应用数据访问权限集和访问权限集的应用替代帐户的应用内含标准的现金流量表解决方案R12中新增了基于直接法出具的现金流量表功能，此功能：通过在不同的现金相关的会计单据（应付发票、应收发票、总帐凭证、银行手续费等）上标识现金流量表识，对表识的记录进行分类汇总后，出具现金流量表；基于系统中记录的现金流量表识，能方便地进行现金流量对帐，支持出具例外核对报表；出具符合国家审计署出具的（核算软件数据接口国家标准）的现金流量表（需结合XmlPublisher）。升级考量要点单据序列（凭证编号）在R12中的变化报告币种设置的变更及相关测试运行预升级诊断报表以检查总帐、多报告币种、应收、应付、资产、财务模块的相关设置数据访问权限集的应用对于安全性控制的影响访问权限集的应用对于安全性控制和影响和表单个性化的调整分类帐、分类帐集的应用对会计期的管理、运行标准报表和FSG报表的安全性控制、对客户化报表的影响替代帐户的应用对于相关需求方案的影响资产管理（吴伟）R12新功能资产管理在R12中的功能改进点：会计科目的生成完全基于SLA；成批增加功能的加强；自动准备成批增加自动的折旧回滚报表的发布等升级考量要点对固定资产类帐默认帐户的检查、调整R12可延用11的帐簿设置，特殊的帐户生成需求可通过调置SLA实现现金管理(Maozhimin)R12新功能现金模块的新功能：集中的银行帐户管理模式银行帐户的传送银行帐户余额管理等升级考量要点升级时，系统会自动迁移在11中定义的银行信息至R12对于在11中在各业务实体分别定义的相同的银行帐户信息，需要考虑数据问题，以便在R12中进行银行帐户的统一管理和数据统计银行对帐的客户化功能的迁移应收管理（Maozhimin）R12新功能现金模块的新功能主要体现在：收入的管理客户信息接口表升级考量要点收入、未获收入的应用及报表的影响SLA的应用对应收模块会计分录的影响客户的功能菜单在升级中会被自动替换成R12的功能客户信息在升级中不会受到影响项目会计（吴伟）R12新功能升级考量要点采购管理(分销顾问)R12新功能采购模块的新功能主要体现在：采购协议的功能变化税务管理的功能变化对采购模块的体现升级考量要点采购协议的数据迁移税务管理的功能变化对采购模块的影响库存管理（分销顾问）R12新功能库存模块的新功能主要体现在：ORACLE库存模块取代了OPM库存管理，R12中，ORACLE库存模块同时支持流程制造和离散制造的库存管理（包括OPM特殊的业务功能，如双计量单位等）；销售成本的确认；挑库存规则功能的加强；库存保留功能的改进；升级考量要点OPM库存管理的功能变化对OPM业务的影响；销售成本的确认的功能变化的应用挑库规则的应用库存保留功能的应用人力资源管理（Jacky）R12新功能订单管理模块的新功能主要体现在：部分系统配置文件选项的变化订单管理模块的部分默认规则的失效升级考量要点系统升级数据迁移对配置文件选项的影响订单管理模块的部分默认规则的失效的影响库存模块挑库规则的功能变化对订单发运的的影响技术方案(苟林/孙洪祥)系统升级方案背景目前伊利集团使用的OracleEBS版本为11.5.10.2，OracleEBS使用的数据库版本10g。使用的EBS生产服务器操作系统为AIX。在目前的情况下，伊利集团希望升级OracleERP到最新的OracleEBSR12。以更好更方便的实现各种功能。前提为确保升级项目能够顺利开展和进行，有一些前提条件必须满足。• 配备有测试机，磁盘空间可以做2-3套测试环境• 测试机的操作系统应该与将来要上线的正式环境的正式机的操作系统保持一致• 如果需要测试与别的系统的接口，外围系统同样需准备测试环境• 现有系统数据库做了RAC,为了将来的正式环境能够实现同样的功能，需要保证一定的硬件资源进行RAC的测试工作要求的范围和目标根据前期的调查情况，本升级项目的范围如下：OracleEBS系统升级,从OracleEBS11.5.10.2升级到OracleEBSR12.1.3,由于R12的要求其中包括数据库的升级，另外如果需要还有操作系统的升级。系统升级• 将OracleApplications由R11.5.10.2升级到R12.1.3• 将数据库由版本10g升级到11gR2• 需要实施方提供相关文档根据我们团队在其他客户那里丰富的升级经验，我们觉得企业在升级OracleEBS的项目中的难点和重点有：（一）客户化开发的部署与修改由于从R11.5.10.2升级到R12,标准对象变更很大,可能会导致很多的客户化开发对象无效。这样就会导致大量的客户化开发对象的修改，这项工作内容非常难以在事先估计清楚。所以，基于旧版本OracleEBS的客户化的开发的是否规范与文档是否齐全，对此升级项目是非常重要的。（二）测试的全面性与准确性对于升级与升级项目来说，测试的全面性与准确性是具有决定意义的。这里测试包括标准功能的测试和客户化开发的测试，如果上面一项里关于客户化开发的相关文档不够齐全和完备的话，测试的全面性和准确性就显得尤其重要了，甚至关系到项目的成功与否。所以测试的全面性与准确性是项目中的一个重点。（三）历史数据的影响在升级过程中，需要打一系列的Patch，这些Patch可能会对历史数据有些处理操作，如果历史数据有异常，可能会在Patch过程中出错，对于这些错误的处理，有时是比较复杂的。升级技术方案目前，对于OracleEBS的升级Oracle提供的标准方法是通过Oracle标准的官方文档UpgradeGuide:Release11toRelease12.1.1里的方法具体实现的。对于OracleR12,可以从OracleRelease11直接升级上来，所以对于深交所的版本升级，可以直接升级到R12,这里我们先升级到R12中的初始版本R12.1.1,然后再安装RUP包升级到最新版本R12.1.3。概括的讲，我们的升级方案是这样的:先安装R12.1.1环境的一套代码，然后在此机器上通过打12.1.1MaintenancePack的补丁实现数据库的数据升级到12.1.1，然后用安装的R12.1.1的应用代码连接此数据库，实现整个EBS系统升级到R12.1.1，紧接着应用最新的R12.1.3补丁包和后续系列补丁。先安装一套Database11gR2并配置好RAC环境，通过DBUA完成EBS数据库的版本升级，并进行应用和数据库的RAC转换，实现整个EBS系统升级到R12。通过上面的2个升级步骤，实现OracleEBS从R11.5.10.2到R12的升级。技术方案概览根据Oracle的技术方案以及我们实施过的成功案例，我们推荐下面的升级方案：应用从R11.5.10.1到R12.1.3步骤号内容预先步骤1用Rapidinstall安装R12.1.1代码Pre-Update步骤2判定需要的升级前步骤3执行升级前的各项工作，包括前补丁与各模块业务准备OPM模块的历史数据需要预处理参照OPMRelease12Migration(DocID:376683.1)应用升级步骤14执行adpatch升级EBS的版本到12.1.15应用系统中间件升级和代码合并应用升级步骤26执行adpatch升级EBS的版本到12.1.3Post-Update步骤7执行升级后的各项工作，启动环境数据库从10g升级到11g，并进行RAC转换步骤号内容预先步骤8安装并配置RAC环境Pre-Update步骤9判定并执行需要的升级前步骤数据库升级步骤10升级数据库RDBMS的版本到11gRAC转换步骤11数据文件转换到ASM中12Adconfig配置，系统运行参数修改Post-Update步骤13实现已升级完成的R12应用代码和RAC数据库的合并14执行升级后的各项工作，启动环境技术方案阐述下面将针对技术方案概览的关键点进行较详细的说明：步骤1：Rapidinstall-安装12.1.1代码操作目的：安装出一套R12.1.1的代码操作方法：根据环境配置（如文件系统位置、TCP/IP端口等）安装新的12.1.1的代码，安装完成后通过备份或移走的方式，将其暂时保存。Rapidinstall的代码包括：[SID]appl->OracleEBS产品文件(如Form,Report文件)[SID]ora->OracleEBS应用层technologystack（如formserver,reportserver,iAS等）[SID]comn->OracleEBScommon文件(如一些java文件和脚本文件)步骤2：判定需要的升级前步骤操作的目的是判断升级技术步骤。Oracle提供了一个脚本运行后输出的tums.html可以供用户判断哪些升级操作是需要做的，哪些操作是不需要做的。对后面的升级操作具有基本的指导意义。步骤3：执行升级前的各项工作，包括前补丁与各模块业务准备此步骤是根据tums.html的结果，执行升级前的各项必须的准备工作，其中有一些是需要打一些先补丁，也有一些是业务上的准备。这其中包含很多的内容，根据伊利集团的实际情况，我们只选取了系统共通部分与财务部分，具体包括SystemAdministrationTasksApplicationObjectLibraryTasksOracleFlexBuilder/AccountGeneratorTasksOracleAlertTasksOracleWorkflowTasksOracleCashManagementTasksOraclePayablesTasksOracleReceivablesTasksOracleFinancialsforLatinAmericaTasksOracleGeneralLedgerTasksGlobalAccountingEngineTasksOracleiPaymentTasksOracleFinancialsforAsia/PacificTasksOracleFinancialsCommonCountryTasks这上面的准备工作有些根据tums.html的结果和实际业务情况，是不用做的。下面举两个例子，说明升级前大概都有哪些工作需要做:OraclePayables1:导入所有接口表数据2:确认/取消所有未完成的批ProcessManufacturing参考文档OPMRelease12Migration(DocID:376683.1)。1:预处理OPM的基础数据（库存组织和物料的调整）2:对未完成的批进行快照记录，升级完成后重建这些批3:处理所有未结业务（完成或取消），并记录，升级完后继续处理步骤4：升级ADPATCH升级EBS的版本到12.1.1升级ORACLEERP数据库内的数据从R11.5.10.2到R12.1.1的版本升级。经过此步骤后OracleEBS内部的数据结构已经完全升级到R12.1.1。步骤5：应用系统中间件升级和代码合并升级ORACLEERP应用的中间件到所需的版本，并进行R12.1.1应用系统和10g数据库的代码合并，启动应用系统，进行简单的集成测试和升级确认。步骤6：执行ADPATCH升级EBS的版本到12.1.3升级ORACLEERP数据库内的数据从R12.1.1到R12.1.3的版本升级。经过此步骤后OracleEBS应用层已经完全升级到R12.1.3。步骤7：执行升级后的各项工作，启动环境升级后的工作主要包括在线帮助，环境配置，启动，基本检查等等。然后就可以开放供测试使用。步骤8：安装并配置RAC代码操作目的：安装并配置出一套可用的11g数据库的RAC代码操作方法：根据环境配置（如文件系统位置、TCP/IP端口等）安装并配置新的11gRAC的代码，步骤9：判定需要的升级前步骤操作的目的是判断升级技术步骤。Oracle提供了一个脚本运行后输出的tums.html可以供用户判断哪些升级操作是需要做的，哪些操作是不需要做的。对后面的升级操作具有基本的指导意义。此步骤是根据tums.html的结果，执行升级前的各项必须的准备工作，其中有一些是需要打一些先补丁，也有一些是业务上的准备。这其中包含很多的内容，根据伊利集团的实际情况，我们只选取了系统共通部分与财务部分，具体包括SystemAdministrationTasksApplicationObjectLibraryTasksOracleAlertTasksOracleGeneralLedgerTasksOracleiPaymentTasksOracleInternetExpensesTasksOraclePayablesTasksOracleSubledgerAccountingTasks这上面的准备工作有些根据tums.html的结果和实际业务情况，是不用做的。步骤10：升级数据库RDBMS的版本到11g安装一套新的11g数据库代码，并通过DBUA来完成数据库升级操作。步骤11：RAC转换步骤--数据文件转换到ASM中将所有文件系统下的数据文件通过RMAN转换到ASM中。步骤12：RAC转换步骤--adconfig配置，参数修改该步骤安装并配置数据库的adconfig工具。经过此步骤后OracleEBS数据库层可通过一些简单的工具/命令进行日常维护，这些工具亦可配合EBS的应用系统，进行系统层的管理维护。步骤13：实现已升级完成的R12应用代码和RAC数据库的合并此时实现R12.1.3代码和已经升级过的RAC数据库层结合在一起。实现数据库层的系统升级，这样使整个OralceEBS系统升级到R12步骤14：执行升级后的各项工作，启动环境升级后的工作主要包括在线帮助，环境配置，启动，基本检查等等。然后就可以开放供测试使用。技术方案补充在测试环境实现从R11.5.10.2升级到R12后，测试过程中很可能会发现BUG，需要操作PATCH，这些PATCH将会被增加到后面的二次升级或正式升级技术升级方案中。升级方案风险与应对根据我们的技术升级方案，主要的风险如下客户化开发的部署与修改的风险由于在升级后，以前所有的客户化开发需要重新的部署，大量开发需要修改，所以以前客户化开发的文档与规范就很重要，如果以前的文档不完整或做的不够规范的话，客户化开发在升级后的风险就比较大。而且由于伊利集团的实际情况是采用了大量的在客户端运行的报表，这些报表现在由于升级很有可能都无法再使用，需要修改或重新开发，而这些报表很多现在也没有设计文档，给将来的理解与修改带来很大的工作量。应对的方案就是对客户化开发进行全面细致的测试工作，不管以前的文档是否齐备，开发是否规范，如果有全面细致的测试，就可以发现并解决问题，避免正式上线后客户化开发无法使用的风险。同时针对不同类型的报表在新不版本制订出不同的解决方案。测试不足带来的系统性风险对于这个升级项目来说，对标准功能和客户化开发功能的测试是非常重要的，如果测试不足，就不能及时发现问题，如果问题在上线后暴露，就产生了巨大的风险。应对的方案就是采用各种措施进行全面准确的测试，测试要有测试的方案，测试后要留下结果备案，测试要有责任人等等。用上面的方法来避免测试不足带来的系统性风险。异常数据的风险由于种种原因，在数据库中可能存在一定的异常数据，这种异常的数据很可能在打Patch时报错，如果不能正确处理，可能产生系统的数据问题，如果不处理，打Patch无法继续进行，如果这种情况在正式升级时出现，就会对项目的正常上线产生很大的影响。应对的方案就是在测试升级阶段，对打Patch中的数据报错都要高度的重视，进行足够的分析，弄清原因后再进行处理。另外就是在正式升级前几天进行一次模拟升级，防止在项目进行期间可能产生的异常数据没有在测试升级时被发现。客户化迁移方案客户化总览为保持客户化程序在新环境能够正常使用，我们建议对所有的客户化程序，按三种情况进行分析：可以用新功能替换的程序：在升级后通过实施新功能，替换原有客户化根据R12的新功能，原系统的一部分客户化功能可能可以由标准功能涵盖。考虑到未来系统的维护及可持续性，建议对可以用新功能替代的客户化程序，通过启用新功能实现。比如与账户生成、会计凭证等有关的开发，可通过R12子分类账会计方法功能实现。需要修改原开发设计的程序：在升级后根据新的表结构重新开发这部分主要涉及到对原有标准功能的完善，因为系统升级，系统标准Forms，Package，Workflow，Reports等也会随着升级，对这些内容的客户化，需要在升级后，根据新的表结构，全部重新开发。可以保留的原开发：在升级后通过重新编译，直接移植到新系统对于完整新增的功能，或者因升级变化较少的那些报表，系统升级后，一般不需要重新开发，只要重新检查编译即可。为确保功能可用性，这部分客户化也需要进行完整测试。基于深交所ERP现状，有关客户迁移将主要包括以下三种类型：功能迁移（Form）表单的迁移总体思路：从R12.1.3下载模板，在该模板的基础上，把客户化的代码迁移到新版的模板中，完成迁移后、测试，最后编写移植脚本。下载模板直接从R12.1.3服务器上下载，路经：$AU_TOP/forms/US/template.fmb客户化代码迁移有关UI布局部分，需要在新的模板基础上，重复老版本的布局。有关客户化代码部分，可以通过文本编辑器比较得出客户化代码。比较的对象为需要迁移的表单和EBS11的模板作比较，在比较之前需要将二者编译生成文本文件。将找出的客户代码迁移到新的表单中。添加多组织架构相关代码由于R12版的ERP增强了多组织架构这一功能，所以需要在新的表单中增加、修改相关代码。如界面的布局上需要新增一个关于OU的下拉列表，以及在相关的几个触发器中需要增加相关的代码等。测试当完成代码的迁移后，需要进行测试，在测试的过程，根据实际情况，项目统一安排相关功能顾问和用户参与进来。迁移当完成测试后，我们需要考虑如何将代码移植到SIT/UAT/PROD等环境中，即需要编写移植脚本。报表迁移（RDF类型的报表）在移植过程中，根据业务特点结合整体解决方案，大多数报表将采用R12集成的BIPublisher重新定制并发布出来。对于XMLPublisher发布的报表移植主要侧重点在数据源着一块，老版本的RDF报表对应的布局我们将通过RTF模板的方式实现，我们就不需要花大量的时间来重复报表的布局，只需要通过xmldesktop工具就可以快速的实现报表的布局。移植过程如下：JDeveloper10g开发工具新建一张报表，将老版本报表相关的查询、数据列、占位列、参数、触发器等相关代码迁移到新报表中，如果用到临时表、包或者存储过程，需要将相关的数据库对象也移植到R12.1.3平台上。完成上述代码的迁移后，需要在R12.1.3完成注册，完成相关RTF模板的制作（可以借助前文提到的xmldesktop工具）、注册相关的XMLPublisher报表。提交给相关功能顾问和用户测试后，需要编写移植脚本。报表迁移（WEBPL/SQL报表）由于在R12版本中，EBS不支持WebPL/SQL，为了实现系统功能的平移，可以参考OracleMetalink(DocID726711.1)启用该功能，需要打一个patch，就可以启用mod_plsql这一子模块。打好相关的patch之后，WEBPL/SQL报表的移植工作就比较简单了，只需要将相关的包和存储过程在R12.1.3这一平台上重新编译就可以了，如果需要的话，在编译之前，需要将数据表等相关的数据库对象移植到新的ERP系统中。报表迁移（Discoverer报表）由于深交所的Discoverer主要用于HR模块，而11.5.10.1升级到12.1.3版本中，HR基础表修改结果较多，所以所有的现有Discoverer报表都需要重新筛选，确认功能是否还能使用，如果不能使用，就需要在Discoverer重新定制开发。原有的Discoverer的BA层需要重新定制，EU层模型改写会较多，Desktop如果EU层变化不大，只需要把定制文件复制上传就可以了。数据库客户化开发代码11.5.10.1升级到12.1.3的过程中，标准功能涉及到的后台表和程序都会通过Oracle升级patch自动升级，但是客户化代码不能自动修改，需要技术开发人员重新检查筛选和调整。大部分的程序在重新编译的过程中就能发现差异并修改完成，在增加新的多组织结构代码就能使用。极少功能需要经过功能测试，在升级测试过程中调整并迁移到新环境中使用。客户化开发工具在ERP系统的实施过程中，由于本土化、个性化,以及集成上的需要,必然存在对标准产品的客户化开发。在此我们对OracleEBS客户化工具、技术,客户化，集成技术以及我们将来可能面对的部分接口做一下说明:客户化开发工具－ORACLEDEVELOPERSUITEOracleDeveloperSuite提供了很多功能，用以构建各种互联网应用程序和由商务智能功能增强的Web服务。OracleDeveloperSuite可满足所有事务处理应用程序开发和商务智能的需要。如何使用OracleDeveloperSuite和使用哪些工具，这取决于终端用户的需要、开发人员的技能和技术背景等。该套件中所包括的各个具体组件列于图2，并将在下面各节具体介绍。图2图：OracleDeveloperSuite的各个组件应用程序开发：OracleJDeveloper是一种结合了Java、XML和SQL技术的，用于开发高质量的J2EE应用程序和Web服务的集成开发环境（IntegratedDevelopmentEnvironment，IDE）。OracleJDeveloper支持完整的开发生命周期，包括：建模、编码、调试、性能剖视、优化和部署。OracleJDeveloper还可以作为单独的产品，用于满足Java开发人员的需要。OracleJDeveloper是Oracle应用服务器Java版的一个组成部分。OracleFormsDeveloper是一种说明性的快速应用程序开发（RapidApplicationDevelopment，RAD）工具，PL/SQL开发人员在无需用Java编码的情况下，可以使用它构建高度交互式的基于Java的Web客户端程序。OracleDesigner是一种用于构建完整的应用程序和数据库的建模和生成工具。它还能够逆向设计现有的Oracle和非Oracle数据库，来创建Oracle数据库模型。Oracle软件配置管理器（OracleSCM）是一种用于存储所有与应用程序开发过程相关的文件和对象，并进行版本控制的软件配置管理资源。OracleSCM与OracleDeveloperSuite中的所有开发工具集成在一起。商务智能：OracleDeveloperSuite包括各种通过商务智能功能增强事务处理应用程序的性能，以便更深入地理解有关数据的商务智能工具。OracleWarehouseBuilder（OWB）是一种企业数据集成工具，它提供一种经济有效、可伸缩和易于使用的数据提取、转换和加载工具，使数据库管理员和开发人员能更快、更高效地设计和构建商务智能应用程序。OracleReportsDeveloper是一种说明性的企业报表编制工具，可用于通过使用能够以任何形式安全地发布到任何目的地的数据源来创建精确的报表。OracleDiscoverer提供一种直观的特定查询、报表编制和分析工具，用以满足终端用户简化信息访问的需要。OracleBusinessIntelligenceBeans（OracleBIBeans）提供一套基于标准的可重复使用的JavaBean组件，用于快速用Java实现高级分析型应用程序。OracleWorkflowbuilder提供了一个察看，修改，建立工作流的图形化工具（不是developersuite的组件）．OracleXMLPublisher是Oracle提供的报表开发工具，将数据逻辑，版式和页面翻译分离开来，技术人员专注数据逻辑的实现，业务人员可使用OFFICE工具进行版式的设计更加贴近用户的需求。同时提供多种输出方式EXCEL,PDF,WORD,HTML等，适应不同用户的需要。OracleDeveloperSuite的主要优势OracleDeveloperSuite具有以下主要优势，以支持更好、更快、更经济高效地开发互联网应用程序和Web服务：完整性集成化基于标准OracleDeveloperSuite提供一整套功能，可以满足多种要求。它基于最新的行业标准，是一套集成化的、可协同工作并与Oracle数据库和Oracle应用服务器高度集成的组件。完整性OracleDeveloperSuite以单一套件的形式提供一套最完整的工具。其所提供的工具能够支持任何语言（Java、XML和SQL），以及从建模、说明性方法到3GL编码的任何开发风格。本产品覆盖开发生命周期的所有阶段：建模、设计、编码、编译、调试、源控制、部署、调优和监控。OracleDeveloperSuite还可以用在任何操作系统平台上，包括Windows、Unix或者Linux。使用这个套件构建的应用程序能够运行在任何类型的设备上，如台式机、浏览器、移动电话或者掌上设备。集成化OracleDeveloperSuite提供了三种类型的集成：OracleDeveloperSuite提供的各种工具之间的集成、与Oracle应用服务器的集成，以及与Oracle数据库的集成。OracleDeveloperSuite中有大量的集成。OracleDesigner能够生成包括OracleForms在内的完整的应用程序。现有的Forms能够被逆向设计成Designer环境。OracleDesigner生成BusinessComponentsforJava，以便用于OracleJDeveloper项目。OracleJDeveloper已集成了对OracleBIBeans的支持，以便在J2EE应用程序中实现强大的商务分析功能。除了与OracleDesigner和OracleFormsDeveloper的集成以外，OracleSCM还与OracleJDeveloper集成，从而使开发人员能够只需一次点击即可实现对源的控制操作，如版本控制和依赖性管理等。这种集成使开发团队能够很容易做到组织有序，并能够甚至在最分散的开发项目中密切合作。尽管OracleDeveloperSuite对其他遵循JDBC和ODBC的数据库是开放的，但是，它是完全重新开发的，以便与Oracle数据库协同工作并充分利用Oracle数据库的独特功能。可以使用Oracle开发人员早已熟悉的诸如SQL、PL/SQL、Java和XML等语言和工具来构建数据库驱动的网站和商务应用程序。OracleDeveloperSuite已经过测试并通过了Oracle数据库各个版本的验证，并且由一个单一的支持机构进行支持。作为应用程序部署平台，OracleDeveloperSuite还提供与Oracle应用服务器的在线集成。通过一次点击部署的方法，Oracle使得在其平台上构建高性能应用程序的工作变得简单易行。此外，使用OracleJDeveloper构建的应用程序能够轻松地部署在任何其他符合J2EE规范的应用服务器上。这是Oracle对开放性作出贡献的集成优势的真实写照。基于标准OracleDeveloperSuite是根据Oracle对开放式体系结构的承诺以及通过支持标准和趋势推动互联网发展的承诺而开发的。Java的可移植性和通用性是OracleDeveloperSuite的核心。此外，经过认证OracleJDeveloper符合最新的J2EE规范。OracleDeveloperSuite支持的标准包括J2EE、XML、SQL和Web服务标准（即：SOAP、UDDI、WSDL和JAXR），以及其他诸如UML、XMI和WebDAV等重要的行业标准。克隆环境脱敏方案克隆过程中的敏感信息保护和管理由于深交所系统中存在大量敏感数据，在开发、测试过程需要及时脱敏，以防止信息泄露。需要脱敏的主要包含用户密码，现有业务报表，以及后台表中的敏感数据字段。德勤根据深交所升级项目特点，认为脱敏主要存在于从生产环境克隆数据到开发和测试环境的过程中，根据之前大量项目实施经验，建议深交所采取以下方案进行数据脱敏。通过完善和制定关键数据使用管理制度，明确EBS系统中敏感信息数据范围，明确脱敏过程的职责分工，在克隆过程中严格按照脱敏方案执行，完成后安排人员检查脱敏结果，在确认满足数据安全要求后再提供用户和开发人员使用。通过规划，执行，检查确认，有效的防范生产数据泄露等安全隐患。定制脱敏需求列表根据用户调研确定数据脱敏范围，比如：全部的用户密码数据HR业务信息：包括人员职位，证件，薪资等隐私信息财务模块敏感的价格和金额信息编制脱敏CheckList和ActionList根据脱敏需求列表编制检查列表，一一列举系统中对应的脱敏项和脱敏措施，同时分别列出每个步骤的对应负责人。编制数据脱敏变形脚本通过后台更新数据表进行脱敏的数据，定制开发脱敏脚本，通过变形公式，执行SQL更新所有的敏感数据为普通测试举例数据，比如员工职位，工资，财务模块等信息。执行脚本并检查脱敏结果克隆完成后，只启用数据库，暂时不把应用服务器上线。然后按顺序执行脱敏脚本，并记录运行结果，确认数据修改结果后，再启动应用服务器，提供环境给用户和其他开发人员使用。关键需求点对点应答序号需求需求匹配的项目任务、交付物描述1.1本次项目分为两个阶段，首先进行供应链系统11版本的优化，其次进行11版本至R12版本的升级。《升级分析评估报告》《升级解决方案》1.2在充分了解我公司现有系统架构的基础上，对目前11版本系统的使用情况进行全面评估。《升级分析评估报告》1.3对我公司使用的11版本系统功能进行全面梳理，按照R12版本功能应用需求编制系统优化工作任务清单。《升级分析评估报告》《客户化开发清单》1.4按照业务流程要求，对任务清单进行优先级排序，按照优先级顺序制定工作计划。《项目实施计划》1.5系统优化实施过程中需要针对目前系统中的垃圾数据进行清理，最大限度减少系统备份及数据转换时间。《升级分析评估报告》《升级解决方案》1.6对于目前使用的11版本中的客户化功能，如过R12版本标准功能能够满足，则在R12中通过启用标准功能实现，达到去客户化的目的。《升级分析评估报告》《升级解决方案》1.7对于11版本系统中的客户化功能，如果在R12版本中仍需要进行客户化才能实现的，需要进行客户化的移植工作。《升级分析评估报告》《升级解决方案》1.8项目实施过程中，对于目前11版本中存在的，但经过详细论证后确定不再使用的客户化予以清理。《升级分析评估报告》《升级解决方案》1.911版本升级至R12版本后中标方移植的报表/单据在性能要有提升，原运行时间在1分钟以上的报表/单据每张性能需要提升20%以上，原运行时间1分钟以内的报表性能可以上下浮动20%。《升级分析评估报告》《升级解决方案》1.10充分了解我公司系统情况的基础上，借鉴同行业丰富的优化升级经验，有效控制项目风险。《项目实施计划》1.11项目实施过程中，系统优化工作要与升级工作协调配合，针对系统优化过程中客户化移植与系统升级所需要的系统停机时间进行科学规划，保证系统升级计划的可执行性。《系统切换策略方案》1.12系统优化、升级前需要对目前系统中相关数据结果进行备份，系统优化、升级后需要提取相关数据与优化升级前进行校验，保证系统优化、升级对系统数据没有影响。《升级分析评估报告》《升级解决方案》《系统切换策略方案》1.13按照各事业部具体业务流程进行客户化功能移植及系统升级的协同测试，测试过程中存在的问题进行详细记录并处理。《系统测试脚本》分析测试、功能测试、模拟测试、用户接受测试1.14系统测试工作需要进行全真模拟升级测试，即以实际真实数据为基础进行。《项目实施计划》《系统测试脚本》分析测试、功能测试、模拟测试、用户接受测试1.15为了能够保证系统升级后各项功能的成功应用，系统优化实施人员需要在系统升级后进行后续支持，解决系统出现的异常问题，保证系统优化结果成功应用。《项目实施计划》上线后的运行支持（现场+远程）1.16项目实施过程中，需要针对11版本及R12版本系统功能的不同点进行全面梳理，以便更新用户手册及开展最终用户培训。内部顾问培训、关键用户培训、最终用户培训、用户手册编写或更新1.17在项目实施过程中，我公司会安排相应的IT人员参与项目的实施，必须完成对参与项目实施人员的R12版本标准功能培训，包括R12版本的设置、操作、日常问题的处理、报表及客户化的开发等。内部顾问培训、协助内部顾问完成模拟测试和用户接受测试的系统升级(以上两次模拟测试由内部顾问主导完成)、客户化开发工作由伊利内部顾问和德勤顾问共同完成。1.18项目实施人员要求：实施顾问、开发人员的行业工作经验必须在3年以上，项目经理在5年以上，要求对11环境和R12环境都非常熟悉。在投标时需要附实施人员（包括项目经理）的人员简历，简历中必须包含近2年内实施的项目及在项目中所承担的工作内容。项目经理、实施顾问的行业工作经验在6年－10年；开发人员的行业工作经验3年-5年；项目成员对11环境和R12环境都非常熟悉。项目成员简历包含近2年内实施的项目及在项目中所承担的工作内容.升级测试策略制定升级测试计划全面的测试对于成功升级起着非常重要的作用，我们要规划好测试分哪几轮，明确每一轮的测试类型和侧重点，安排测试的时间，参与的人员，并准备好测试脚本或测试的内容，以及测试结果的反馈表格模板。通常客户化测试分为如下三类：单元测试技术顾问逐个对每个客户化开发做单元测试。技术顾问将负责定义单元测试的CheckList。单元测试将验证升级后的客户化是否能正常使用，以及适当的异常操作。单元测试重点在从各个方面测试一块代码。技术顾问应该将重点放在错误处理。比如，当测试定制表单时，技术顾问应该放些特殊字符到所有字段尽可能让表单去处理。单元测试一般由技术顾问自己执行。集成测试将客户化开发放到业务流程中，进行端到端的测试，确保整个流程产生的结果是正确的。集成测试一般由功能顾问、关键用户和开发人员共同执行。用户接受度测试用户接受测试执行一个“生命中的普通一天”的测试场景。例如，用户执行每天，每星期，每月的普通工作流程。用户接受测试将验证客户化功能符合功能需求文档。用户接收测试通过后，客户化开发才确认为完成状态。用户接受测试一般从头开始，不使用集成测试的脚本，重点去确认客户化是否满足业务需求。细化测试内容以新功能，新特性为主线，以客户化功能为重点，结合业务流程，验证数据的正确性，及界面之间的数据传递的准确、无误。具体内容包括：多组织访问分类帐数据安全性现金流量表银行对帐单财务凭证生成与打印帐户生成器…客户化程序代码中，要针对新的变化作出相应的修改：GL_SET_OF_BOOKS中的sob_id变为R12中GL_LEDGERS的ledger_id。组织安全性fnd_client_info.set_org_context(Org_id)变成mo_global.set_policy_context('S',Org_id)。…技术层面数据检查在升级过程中，可能存在数据一致性被破坏或因为数据表结构的变化而导致的数据丢失，为了能监控到这类情况的发生，可以在技术层面对数据进行检查，对比和修复。在进行升级前，清除或归档老的不必要的数据。在升级前收集原系统的表和索引的统计信息。升级收集新系统的表和索引的统计信息。比较分析升级前后表和索引的统计信息的变化情况对于一致性被破化的数据要分析原因，进行修补；对于因升级导致的数据丢失，重新导入缺失数据。系统切换方案结合系统解决方案和项目计划安排，在上线之前会有3次切换：第一次模拟切换、第二次模拟切换、上线切换，前两次切换对应技术升级模拟切换和UAT切换。第一次模拟切换这次模拟切换不需要用户的参与，技术顾问、功能顾问以及伊利IT内部顾问需要完成数据的验证和流程测试，重点涉及老系统二次化开发相关的程序。本次模拟的目的是验证历史数据、数据修复脚本，验证老系统的关键二次化开发程序迁移结果。数据验证升级完成后，顾问验证历史数据，更具验证结果，编写数据修复脚本，运行脚本，测试、验证修复结果，在测试的过程如果发现问、需要及时更新数据修复准备。老系统关键二次化开发的迁移整理移植清单，完成相关二次化开发程序的代码迁移、运行相关移植脚本，技术顾问测试，每问题后提交给功能顾问测试，在测试的过程，如果发现问题、需要修改更新代码或者系统打补丁、或者相应的修改移植脚本等。第二次模拟切换由于是UAT的测试，这次模拟切换需要关键用户的参与。这轮切换的主要目的是从用户的角度功能的可用性以及数据的一致性、准确性。验证第一次模拟切换的数据修复脚本、老系统二次化开发移植程序。这轮模拟测试主要包括下述四个部分：历史数据验证升级完成后，运行第一轮模拟测试时验证过的数据修复脚本，顾问验证数据修复结果，然后交给用户验证。在测试的过程如果发现问、需要及时更新数据修复脚本。老系统二次化开发移植执行移植脚本，完成移植，顾问测试（重点测试二次化开发程序），然后交给用户测试。在测试的过程中如果发现问题、需要及时修改相关程序、移植脚本等。上线切换在系统正式上线之前，完成系统设置后，为了确保上线的顺利进行，需要对设置好的产品环境克隆、进行数据验证和流程测试，如果发现问题需要更正，从而确保系统顺利上线。本轮切换的目的很明确，就是确保产品环境可以顺利上线，在克隆的环境上进行必要的数据验证和流程测试，需要用户的参与。本轮切换主要包括下面几个部分：系统设置、程序移植系统完成升级后：首先，运行修复数据脚本，完成历史数据的修复；运行移植脚本，完成老系统的二次化开发程序的移植；由于上述步骤在第一轮和第二轮的切换中已经验证过，所以这一轮只需要执行相关的脚本、按部就班的执行就可以了。克隆完成系统设置、程序移植，以及相关数据的导入、更新后，就可以克隆产品环境，供顾问和客户进行数据验证和流程测试。克隆的目的是：如果发现问题，及时的在克隆环境解决掉，测试没问题后，再应用到产品环境中，这样可以确保顺利上线。数据验证相关数据的验证，可以导出生成文件提交给用户验证，也可以让用户直接在克隆环境中抽查、验证。需要相关用户签字确认。数据的验证包括历史数据的验证。如果发现批量的数据问题，需要编写数据更新脚本，先在克隆环境中执行、测试没问题后，才能在产品环境中执行。流程测试在这部分的测试过程中，功能顾问会协助用户完成测试（在克隆环境）：如果在测试的过程中发现问题，需要修改相关的程序、测试没问题后，再将相关的修改应用到产品环境中；如果发现是系统设置问题，功能顾问需要更新相关的系统设置，测试没问题后，再将相关的修改应用到产品环境中。上线当上述2个测试（数据验证和流程测试）都走完后，发现的相关问题也都解决了，我们就可以上线了。项目工作量估算（Henry）项目管理（Henry）项目组织架构深圳证卷交易所ERP升级项目需要根据项目建设需求构建完整的项目团队以支撑项目建设，项目团队包括企业高管和各部门的领导和核心业务骨干，各个层面的人员充分发挥作用推动项目建设；德勤针对深圳证卷交易所ERP升级项目建设成立完整的项目团队确保项目的顺利推进和执行。具体组织结构与人员安排如下图：服务排期（项目计划）德勤针对本次伊利集团ERP实施项目整体计划如下图：项目里程碑如下：本次伊利集团ERP系统实施项目关键里程碑点主要包括以下几个方面；里程碑1：项目启动会，2012年4月初完成启动；里程碑2：升级评估，完成升级的评估报告，2012年4月中旬完成；里程碑3：方案完成，2012年5月中完成方案设计；里程碑4：开发迭代测试完成，2012年7月下旬完成集成测试；里程碑5：升级模拟测试，2011年8月中旬完成；里程碑6：UAT测试，2012年9月上旬初完成；里程碑7：系统上线，2011年10月初完成；里程碑8：系统运维，2011年12月完成。项目任务分工主要工作任务分工以下为是项目中不可缺少的重点工作内容，但不是全部，更具体的工作内容可以在未来的项目实施计划中体现项目准备阶段主要工作任务德勤职责伊利职责说明项目章程编制配合项目实施计划编制配合确定项目组织确定顾问组织架构确定甲方组织架构启动大会文档参与编写项目启动会议材料；参加项目启动会；编写项目启动会议材料；主持项目启动会；升级分析评估阶段主要工作任务德勤职责伊利职责说明升级分析评估计划编制参与编写，并确认；内部顾问标准功能培训执行参与；执行升级分析评估执行；配合并参与调研，安排调研部门参与调研；关键用户标准功能培训协助内部顾问负责培训升级分析评估报告编制参与编写，并确认明确项目范围升级方案、系统测试阶段主要工作任务德勤职责伊利职责说明升级解决方案编制参与编写，并确认；分析评估测试执行升级，编写测试脚本、环境设置、主讲、更新升级解决方案内部顾问参与系统准备、测试；确认CRP1测试结果和升级解决方案更新内容.功能测试执行升级，更新测试脚本、更新环境设置、主讲、更新升级解决方案内部顾问参与系统准备、测试；确认CRP2测试结果和升级解决方案更新内容.客户化清单编制；参与编制，并确认；客户化开发：开发规范编写参与编写、确认；客户化开发：开发编写；占工作量的50%参与编写、确认；占工作量50%迭代开发测试执行升级、更新测试脚本、更新环境设置、更新升级解决方案内部顾问参与系统准备、测试；关键用户参与测试内部顾问确认CRP3测试结果和升级解决方案更新内容.模拟测试协助内部顾问、更新升级解决方案内部顾问执行升级、测试；关键用户参与测试；确认升级方案更新内容，测试结果系统切换策略方案编制；参与编制，并确认；培训：最终用户培训手册编制、用户培训协助内部顾问关键用户（内部顾问协助）用户接受测试协助内部顾问、更新测试脚本、更新升级解决方案内部顾问执行系统升级、主讲；关键用户参与测试内部顾问确认CRP3测试结果和升级解决方案更新内容.系统切换准备阶段主要工作任务德勤职责伊利职责说明业务规范制定或更新协助编写上线支持方案编写参与编写、更新、确认；正式系统切换主要工作任务德勤职责伊利职责说明生产环境系统升级前准备协助执行生产环境系统升级协助执行生产环境系统升级后系统设置协助执行上线支持阶段主要工作任务德勤职责伊利职责说明运行支持协助解决系统问题主导系统方案调整内部顾问和关键用户为主；上线报告编写参与编写，确认；上线两个月月结完成报告编写参与编写，确认；项目总结及总结报告(上线四个月月结)编写参与编写，确认；项目验收及验收报告编写确认；项目交付物清单项目阶段交付物清单交付物说明项目准备项目章程包括总体目标、阶段性目标、项目范围、项目管理、变更管理等，是项目实施的指导性文件，是项目实施的“宪法”；项目实施计划项目实施的详细计划安排，任务颗粒按天进行安排，是项目明细任务的执行计划；升级分析升级分析评估报告作为升级分析阶段的成果物；升级方案、测试升级解决方案R12升级方案，包括系统设置的调整、方案优化、数据融合、数据清理、数据验证等；客户化开发清单需要修改的客户化开发清单；系统测试脚本系统测试清单、测试要求、结果系统切换策略方案系统切换策略方案，包括切换步骤、分工、数据验证；上线支持上线报告用于确定升级项目系统切换完成、用户开始正式使用；上线两个月月结完成报告项目上线后两个月月结完成情况报告；项目总结及总结报告(上线四个月月结)项目上线后四个月月结完成情况报告；项目验收及验收报告项目验收，项目整体完成情况报告；服务承诺及优惠内容后续支持服务概述系统实施完成后的运行适应阶段是一个漫长的阶段。在这一阶段中，伊利集团可能仍然需要德勤提供一些可能使用到的、技术方面的支持。我们为伊利集团提供以下几种具体的支持服务内容，帮助伊利集团在应用维护阶段也能够得到我们的全面、周到的支持服务。后续支持服务内容和方式应用健康检查；定期的系统优化分析；现场支持服务（天）；远程登入支持；电话支持系统优化分析随着应用系统的长期使用，经常会出现系统参数不再适应系统新的运行状态的情况；也会出现某些应用由于数据量的增加，速度变得越来越慢的情况。我们可以提供下列定期的系统优化分析服务，帮助伊利集团避免因为长期的使用而可能出现的系统性能降低的危险。系统优化分析将包含下列内容：监测并报告系统运行的情况；对客户所提出的系统性能方面的疑问提出解释和建议；提议关于改进系统运行的技术策略。备注：这些任务将由我们每月一次远程执行；它将包括可以令系统以更好的状态运行的分析和建议，但不包括实施这些建议，是否实施以及最终实施哪些建议将由伊利集团选择，我们将对实施这些建议所付出的额外劳动以优惠价格收取维护费用；我们将不对由于硬件故障所造成的数据丢失承担责任。应用健康检查随着实施阶段的完成，管理系统的应用进程的控制权就完全转移到了伊利集团用户手中。而业务的发展则往往需要系统能够处理一些新生的业务。企业信息管理系统完全可以承受绝大部分这样的业务，但伊利集团单位的直接支持人员却可能由于未必完全了解系统的功能特点，在针对新业务时，可能使用了不是最恰当的实现方式。这时，如果有顾问公司可以定期地上门，对管理系统的使用情况作定期的应用是否继续健康的检查，那么，伊利集团就可以更加放心地使用管理系统了。应用健康检查将包含下列内容：调研客户在应用上线之后的运行情况，新业务的发生情况；分析客户对各类业务的处理是否恰当；制订关于用户处理不当的业务的正确流程；提交用户应用健康检查报告。备注：这些任务将由我们每年一次远程或现场执行；客户应该提供在实施上线起的所有相关的业务变化或/和新业务的文档；它将包括各类的应用不当的分析和建议，但不包括实施这些建议，是否实施以及最终实施哪些建议将由客户选择，我们将对实施这些建议所付出的额外劳动以优惠价格收取维护费用；用户支持中心在系统的使用过程中，难免会碰到这样那样的突发问题。我们为了避免用户由于突发事件造成系统不可用，从而导致伊利集团业务受到影响，特推出用户支持中心的服务，提供下列服务：提供正确的系统操作流程的指导分析系统应用中发现的错误并诊断原因制定解决错误和问题的流程记录请求支持服务的电话并记录结果报告支持服务的运作情况。系统安装和升级我们可以提供给伊利集团有偿的系统后续升级服务，前提需要伊利集团必须拥有合法的介质和使用许可。我们将不对由于介质和安装程序本身所引起的问题承担责任。此时，如果伊利集团需要我们解决此类升级问题，我们将根据实际情况，在可能的范围内帮助解决，但需要根据实际升级使用天数和有关费率收取系统升级实施费用。现场咨询和支持我们可以根据伊利集团的要求，在任何伊利集团需要的时间提供现场的应用咨询和技术支持服务。伊利集团的需求可能是来源于：需要实施系统优化的建议；用户支持中心所受理的问题需要现场的服务；系统的安装和升级的需要；其它认为需要时。其它服务没有在上述定义的任务。如果伊利集团要求我们提供这些服务，在这种情况下我们会基于伊利集团的需求作出评估。双方协商认同后，服务工作将会根据项目支持服务流程和项目实施方法论的指引下进行实施。问题优先级后续支持服务体系决定问题能够得到及时和有效处理的一个重要因素就是问题优先级，德勤针对后续支持服务中出现问题划分不同的优先级，优先级按对伊利集团的业务所造成的影响来决定，进而根据问题处理