青岛机场ERP项目方案书.docx

客户
青岛机场集团
文件名
项目方案
项目
青岛机场ERP管理平台项目
版本
V1.0

青岛机场集团

ERP管理平台项目

方案书

德勤管理咨询(上海)有限公司
2016年5月目 录
1 综述 3
2 德勤对青岛机场集团发展的理解 4
2.1 机场行业的业务发展现状 4
2.2 青岛机场集团的业务发展理解 4
3 青岛机场集团ERP管理平台项目目标与范围 5
3.1 本次项目实施的目标 5
3.2 本次项目实施的范围 5
4 青岛机场集团ERP管理平台的设计思路 6
4.1 “战略驱动，业务引领”，打造卓越型ERP管控平台 6
4.2 “顶层设计、流程驱动”的ERP建设总体思路 10
5 青岛机场集团ERP管理平台解决方案 13
5.1 青岛机场集团ERP管理平台业务解决方案综述 13
5.2 青岛机场集团ERP管理平台业务解决方案 13
5.2.1财务管理解决方案（广峰） 13
5.2.2人力资源管理解决方案（王密） 13
5.2.3资产管理解决方案（李洪枫） 13
5.2.4全面预算管理解决方案（陆沛） 13
5.2.5技术解决方案（叶骅） 13
6 项目实施管理方案（闵捷-侧重于实施保障） 14
7 项目报价（王会利） 15
7.1 软件报价 15
7.2 实施报价 15

第 31 页
1 综述
本文件是由德勤管理咨询（上海）有限公司（以下简称：德勤公司、德勤咨询或德勤），向内蒙古青岛机场资源集团股份有限公司（以下简称：“青岛机场集团”）提供的方案建议书。
我们非常荣幸收到青岛机场集团的邀请。针对“青岛机场集团ERP管理平台项目”的需求，基于德勤的理解和分析，结合德勤公司在国内外实施ERP系统的实践经验，德勤咨询提供了此项目建议书，其内容专供青岛机场集团用于评估德勤为其提供信息系统实施服务的能力。
本文档中Oracle产品介绍基于德勤咨询顾问对OracleE-Business Suite产品套件的了解和Oracle公司发布的产品标准介绍信息。
本文件推荐和说明的方案以及相关信息的所有权均属于德勤公司。因此要求在收到本文件后至中标结论公布日期间，对本建议书内容应予以保密；除非根据法律要求，不得用于除本项目评估之外的任何目的，以任何形式向任何第三方提供本文件内容；并同意采取所有合理的步骤，保证其接触本文件的人员不对外披露或散布本文件内容。
2 德勤对青岛机场集团发展的理解
2.1 机场行业的业务发展现状

2.2 青岛机场集团的业务发展理解

3 青岛机场集团ERP管理平台项目目标与范围
3.1 本次项目实施的目标
3.2 本次项目实施的范围

4 青岛机场集团ERP管理平台的设计思路
4.1 “战略驱动，业务引领”，打造卓越型ERP管控平台
德勤团队认为本次青岛机场集团的大ERP平台建设应该满足以下四点要求：
· 满足机场业务经营特点的需要
· 满足煤化工业务经营特点的需要
· 满足集团管控与实际业务管理的需要
· 满足企业远景战略目标的需要
为此，青岛机场集团的大ERP建设首先应致力于机场及相关化工产品生产、运销、财务、人力资源、办公协同的业务管理需要的全面型操作型大ERP系统，一个操作型的大ERP系统必须具备以下三个方面的能力：
· 支撑机场生产和运销的业务运作能力： 即能通过系统，有效支撑机场业务管理需求，实现业务财务一体化；
· 支撑数据服务能力：即能通过系统，实现数据共享，信息贯通，快速查询等需求；
· 支撑业务流程能力：即能通过系统，实现业务流程在系统内的固化，通过流程驱动业务处理过程。

在满足操作型大ERP要求的基础上，青岛机场集团的大ERP系统还应重点满足集团管控与实际业务运作的需要，致力于建设成一个服务于管理的集中管控型大ERP平台。管理型大ERP平台将管控要点融入于系统建设之中，在服务于业务的同时，能够帮助企业更好地建立流程化管控体系，并能够将集团管控要点与业务流程相结合。

同时，不仅要考虑青岛机场集团目前的信息化建设现状，也要综合考虑到ERP系统建设未来的发展方向，德勤建议，大ERP系统在整合当前各独立系统及在服务业务和支撑管理的同时，还应该充分考虑战略管理的需求，需要能支撑远景战略目标的落地，即成为一个服务于战略的卓越型大ERP平台。一个卓越型的大ERP平台不仅能有效支撑业务运行和集团管理，同时还能基于战略的高度和企业未来发展的角度去设计、优化系统方案，并予以系统实现考虑。通过系统的建构，为远景战略目标的落地提供科学可靠的决策支持，以此促进企业的长远发展。

作为一个具有丰富行业经验及战略远见的大ERP系统实施团队，德勤不会满足于成为一个操行型和管控型ERP的实施方，德勤愿意并且能够站在青岛机场集团集团未来战略发展的角度，基于青岛机场集团的发展现状，结合青岛机场集团战略发展的基本诉求，通过打造青岛机场集团卓越型大ERP系统。

4.2 “顶层设计、流程驱动”的ERP建设总体思路
在本次青岛机场集团大ERP系统建设中，我们将引进“顶层设计、流程驱动”的总体思路，帮助青岛机场集团打造卓越型大ERP管控平台。
“顶层设计、流程驱动”的总体思路，主要包括三个方面：
· “以流程为导向”的工作方法：从梳理端到端流程入手，梳理流程各个要素，包括岗位职责、业务规则、业务数据、系统集成关系等；流程梳理和优化将充分考虑未来战略发展和企业管理需要，满足服务战略的设计要求；
· “以流程为导向”的项目组织：成立专门的流程设计团队，流程设计团队覆盖财务、物流、工程、销售、设备等不同业务版块，保障端到端流程设计的完整性和统一性；
· “以流程为导向”的项目计划：充分考虑流程设计与系统方案之间的衔接关系，流程设计成果，将是系统方案的重要输入依据，并充分融入系统方案中，使得流程设计成果在系统中得以实现。

（一）工作方法：
以业务需求为导向的流程化管理，承载了组织、岗位、信息、风险、控制、IT系统等现代企业管理的全部要素和手段。通过建立以流程为导向的管理模式，能够推动公司组织、流程、制度、系统、文化等的全面融合。

（二）具体工作步骤
可分为以下几个步骤执行：
1. 梳理端到端业务流程：从青岛机场集团核心业务范围入手，全面分析整体业务流程
2. 梳理流程关键要素，主要包括：
· 流程环节：包括节点、任务、输入输出等
· 业务数据：流程节点所产生的结构化信息
· 职能定位：不同层级公司、部门在流程中的管理职能定位
· 流程改进点：流程设计主要优化考虑点
3. 整理端到端流程业务规范，主要包括：
· 业务规则：流程节点对应的业务规则
· 职责分工：明确流程节点管理责任主体
· 风险控制点：内部管控风险点
· 管理制度：配套流程落地的管理制度
4. 整理全业务流程集成方案，包括：
· 系统定位：各系统在流程中的定位
· 集成要点：以流程梳理推导出的集成点
以机场生产运销流程为例，界定不同业务流程不同业务管理的不同信息化系统的关系和界定。

（三）项目各阶段的规划
德勤建议青岛机场集团大ERP平台建设分三期进行建设，第一期为基础平台建设，主要实现人、财、物的集团集中管控，依托基础平台，实现业务、财务、人事一体化管理。在此基础上开展二期建设，主要对现有平台进行深化应用、优化及功能扩展，逐步实现预算控制，数据分析等管理提升功能，提升集团积分子公司的整体的管理水平，第三期是稳步推进信息化的发展，建立完善的运行维护体系，对现有系统进行进一步完善，逐步形成青岛机场全局的，统一的，真正的融合管理理念、高效流程的大ERP平台体系，各阶段建设计划如下：
5 青岛机场集团ERP管理平台解决方案
5.1 青岛机场集团ERP管理平台业务解决方案综述
德勤在充分考虑到青岛机场

5.2 青岛机场集团ERP管理平台业务解决方案
5.2.1财务管理解决方案（广峰）
5.2.2人力资源管理解决方案（王密）
5.2.3资产管理解决方案（李洪枫）
5.2.4全面预算管理解决方案（陆沛）
5.2.5技术解决方案（孙洪祥）
5.2.5.1 接口
5.2.5.1.1 Oracle集成实现方法
Oracle与其他软件系统集成从集成紧密程度来讲分几种模式：
1．数据库层的相互间的非实时数据传送（单向或双向）；
示图如下：

2．应用操作层（或仅数据库层）分别与第三方软件（或中间件软件）的联接；
示图如下：

这两种种集成方法，集成度逐步提高，而随之相应的集成复杂度也大幅提高。
一般经常用第一种方法来实现简单的、集成度要求不是很高的集成需求，因为是点对点的集成方式，适合需要集成的系统不多，实时性方面没有特殊要求的集成。
第二种集成方式对应用层来说联接度有所提高，两种ERP软件分别与第三方中间件进行整合，第三方中间件如oracle的Fusion MiddleWare做为信息交换的总线，通过适配器的方式与ERP软件或其它应用系统进行集成。这种方式要求中间件产品支持多种技术平台，支持多种数据库的适配器，文件适配器，消息适配器，而且能够支持通信协议如Https以及PKI安全证书等。

企业服务总线集成架构模型：
SOA是在面向对象体系结构基础上扩展的新体系结构，以服务为核心来封装业务流程和应用系统，服务具有更高的抽象层次，可以实现更高级别的重用，并解决了IT系统与业务流程的相关性。
与传统构建系统的方法比较，SOA更强调标准化应用，更加重视系统的层次架构。SOA特性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要遵循SOA的理念，采用统一的标准，任何现有技术都能用来开发SOA系统。
企业服务总线集成架构与传统架构的区别在于系统均是基于“服务”构造，“服务”之间的交互和组合实现了系统之间的松耦合关系。
企业服务总线集成架构遵循SOA理念，企业服务总线集成架构中的构件包括：
（1）服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。
（2）服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量（Q0S）级别。
（3）服务使用者（服务消费者）：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对企业服务总线的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。
（4）服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到企业服务总线，以便服务使用者可以发现和访问该服务。
（5）企业服务总线：企业服务总线充当SOA中服务提供者和服务使用者之间的连接服务的中间层。企业服务总线“虚拟化企业里的服务”， 也就是所有的服务会由企业服务总线里的一个虚拟端点来表示，而服务消费者只需要连接在企业服务总线里的虚拟服务端点，由企业服务总线在运行的时候来定位实际的服务在哪里。
企业服务总线核心是一个消息处理引擎，对于服务使用者的请求（典型的如SOAP消息），按照正确的规则去了解消息的内容，处理之后把消息发给正确的服务提供者，然后需要记录处理的中间结果，再协调服务使用者和服务提供者的关系，在两个或者多个本来没有设计为互相调用的服务间提供互相调用并监控他们的相互调用。

企业服务总线集成架构示意图
企业服务总线集成架构中的每个实体都扮演着服务提供者、使用者这两种角色中的某一种（或多种）。
企业服务总线集成架构中的操作包括：
（1）发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。
（2）发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
（3）调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

5.2.5.1.2 关于数据和信息接口方案的两种模式

* 其中：Interface 至Oracle产品的标准接口，关于产品的接口后文将进一步描述
业务系统适当加工后导入

这种方式使业务数据能够在迅速及时地在财务系统中反映，尽可能地使差错在第一次加工就被排除。这种模式在管理上流程上也比较合理，即业务系统导出数据，财务系统直接进行检查和引入，错误可以在导入接口前或从接口引入时马上被排除。
2）间接加工和导入

这种方式存在两个主要问题：
这种流程将信息的传递人为地分三段，虚增了进一步加工的步骤，一方面增加了出错的机会，另一方面增加了业务操作。
由于第二阶段的存在，增加了一个管理步骤，使管理流程不合理，大大增加了不可知因素（如可能是操作失误或数据本身的错误）。

5.2.5.1.3 与协同办公系统集成（致远A8-V5）：
ERP系统与OA系统可以采用多种方式进行集成，以下是以采购和销售流程进行集成的举例：
采购管理与OA系统的集成主要体现了采购相关单据（采购申请、采购订单等）通过OA进行审批。借助OA强大灵活的审批工作流和更贴近领导审批习惯的方式，提升企业采购业务审批管理水平。
ERP系统主要负责管理业务单据。
OA系统主要负责管理审批结构层次和实际审批业务。
ERP向OA系统传递需要审批的单据。
OA向ERP传递审批结果。

销售管理与OA系统的集成主要体现了销售相关业务（销售订单审批、销售定价审批、销售出库审批）通过OA进行审批。借助OA强大灵活的审批工作流和更贴近领导审批习惯的方式，提升企业采购业务审批管理水平。
ERP系统主要负责管理业务单据。
OA系统主要负责管理审批结构层次和实际审批业务。
ERP向OA系统传递需要审批的单据。
OA向ERP传递审批结果及回写数据。如价格审批时需要将审批人同意的价格回写到销售订单上。

5.2.5.2 硬件配置建议方案
根据我们对本次项目的理解，基础设施的网络设计要满足如下条件：
Ÿ 集中化部署，统一管理
Ÿ 充分考虑网络的安全性，充分发挥防火墙和入侵检测等作用
Ÿ 合理架构ERP系统的网络，保证网络的速度和高可用
软硬件的设计要满足如下原则：
Ÿ 先进性原则
采用先进的信息技术构建系统平台，建设100%基于Internet的，以流程为核心，面向服务（SOA）的信息架构和系统。通过该原则，实现业务系统和信息平台的生命周期最大化。
Ÿ 集成性原则
采用一个集成平台，来完成所有业务系统的数据交换和流程衔接。只有确保业务流程在各个业务系统间完整而顺畅的运转，信息在各个业务系统间的安全共享，数据才能够及时、丰富和准确。技术层面提供丰富的符合IT标准的接口，比如XML，EDI，Web Services，Java API，SQL，SOAP，BPEL等技术接口。
Ÿ 可靠性原则
应用系统必须保证顺畅运行，使最终用户有良好的体验，满足日常业务处理的需要。
Ÿ 高可用性原则
7x24小时可访问。
Ÿ 可扩展性原则
按需配置，同时随企业发展而水平扩展，保护现有投资。
Ÿ 安全性原则
要求能确保企业数据的安全。

5.2.5.2.1 Oracle EBS部分：

Oracle EBS硬件需求

名称
主要技术指标
数量
单位
用途及推荐理由
1
生产环境

1.1
正式环境数据库服务器
CPU：至少2颗8核心，主频高于2.0GHz
内存：最低64G，建议128G以上
本地磁盘：至少2*500G
HBA卡：2块
SAN存储：本地文件系统300G
共享SAN存储：600G以上，如果数据库归档日志保存在ASM中，建议分配1TB。
2
台
部署R12.1.3数据库节点，构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。

1.2
正式环境应用服务器
CPU：至少2颗8核心，主频高于2.0GHz
内存：最低32G，建议48G以上
本地磁盘：至少2*500G
HBA卡：2块，可选
挂载SAN存储500G，可选
2
台
部署R12.1.3应用节点。如果使用SAN存储，建议配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。

1.3
网络负载均衡器

1
台
参考设备：F5

1.4
SAN存储（可选）
至少3TB空间
1
台
如果现有存储设备可以满足要求，可以不必另行采购。

1.5
备份服务器（可选）
CPU：至少1颗8核心，主频高于2.0GHz
内存：最低8G
本地磁盘：至少2*500G，建议组成Raid至少保证500G可用空间。
HBA卡：可选
SAN存储：可选，如使用存储，建议500G以上空间
1
台
如生产数据库服务器可以直接连接磁带机或者虚拟带库，则不必使用备份服务器。

1.6
光纤交换机（可选）

2
台
建议使用2台光纤交换机实现高可用，如现有设备可以满足要求，则不必另行采购。
2
开发环境

2.1
开发服务器
CPU：至少2颗8核心，主频高于2.0GHz
内存：最低32G，建议48G以上
本地磁盘：至少2*500G
HBA卡：至少1块，可选
SAN存储：本地文件系统500G，可选
1
台
部署开发环境数据库和应用。建议本地文件系统使用lvm管理，利于扩展。
3
演示和测试环境

3.1
测试服务器
CPU：至少2颗8核心，主频高于2.0GHz
内存：最低32G，建议48G以上
本地磁盘：至少2*500G
HBA卡：至少1块，可选
SAN存储：本地文件系统500G，可选
1
台
部署测试环境数据库和应用，用户功能演示、业务测试和用户培训。建议本地文件系统使用lvm管理，利于扩展。
5.2.5.2.2 PeopleSoft 硬件需求如下：
服务器用途
CPU
内存
本地硬盘
存储
数量
双机热备
备注
应用服务器（含Web服务器）
2.4GHz/24核
96G
400G

2
集群
同时部署Web和App，且根据需要可配置多个Web或App Domain
数据库服务器
2.4GHz/24核
96G
400G
3T
2
集群

培训/测试环境
2.4GHz/16核
96G
500G

2

5.2.5.2.3 Hyperion部分：
生产环境：
服务器
用途
安装产品
CPU
说明
操作系统
Server1
HFM应用服务器、FDM应用服务器
Hyperion
32 Core CPU 2.4GHz
64G 内存
500G (RAID0+1)硬盘
HFM需要进行多架构、多层级的合并抵消汇总，对内存、CPU的计算要求较高
Windows Server 2008 R2 Enterprise
Server2
关系型数据库服务器
Oracle DB 11g R2
32 Core CPU 2.4GHz
64G 内存
2 TB (RAID 5)硬盘
Oracle DB 需要进行数据多维计算，因此对CPU和磁盘读取速度较高，同时考虑数据的增量，及数据安全存储的需要
Windows Server 2008 R2 Enterprise或
Red Hat EL 5.8

开发与测试环境（PC服务器或性能相当的虚拟机）：
服务器
用途
安装产品
CPU
说明
操作系统
Server1
HFM应用服务器、FDM应用服务器
Hyperion
16 Core CPU 2.4GHz
32G 内存
200G (RAID0+1)硬盘
HFM需要进行多架构、多层级的合并抵消汇总，对内存、CPU的计算要求较高
Windows Server 2008 R2 Enterprise
Server2
关系型数据库服务器
Oracle DB 11g R2
32 Core CPU 2.4GHz
64G 内存
500 TB (RAID 5)硬盘
Oracle DB 需要进行数据多维计算，因此对CPU和磁盘读取速度较高，同时考虑数据的增量，及数据安全存储的需要
Windows Server 2008 R2 Enterprise或
Red Hat EL 5.8
5.2.5.3 网络带宽需求：
用户使用Web Client时，网络带宽平均大约需要100K/Client。使用Java Client时，网络带宽平均大约需要25K/Client。如果数据的平均传送率为100KBps，那么Web客户端页面下载的平均时间为一秒。带宽总量的计算公式为：
带宽总量 = 每位用户的传送率 x 登录用户的数目 x 并行率
对于100名登录用户，如果都是使用Web Client，假定并行率为10%，那么对带宽总传送率的要求为1MBps（兆字节每秒）或8Mbps（兆比特每秒）。如果有一半用户使用Java客户端，则对带宽总传送率的要求将降到5Mbps。
实际网络带宽需求，需根据实际在线用户人数及访问数据量大小做进一步的评估。

5.2.5.4 软件配置建议方案
以下是Oracle电子商务套件的服务器端软件需求：
软件需求

名称
主要技术指标
数量
单位
用途及推荐理由
 服务器端

Oracle电子商务套件
（Oracle E-Business Suite）
R12.1.3
1
套

Oracle数据库
Oracle Database 64位 11.2.0.4版本以上
Oracle Real Application 11.2.0.4以上
Oracle ASM 11.2.0.4以上
2
套

Linux操作系统
64位Redhat 6以上或Oracle Linux 6以上
6
套
可以免费使用，官方技术支持需要另行购买。

PC端 

 操作系统
 Windows 2000 以上

 浏览器
 IE6.0+， firefox 4.0+

 内存
 256M 以上

 CPU
 233MHz 以上

Peoplesoft软件详细清单
软件名称
版本
备注
Oracle数据库
11g或12c
安装在数据库服务器上
PeopleTools
8.54
安装在应用和WEB服务器上
PeopleSoft HCM
9.2
安装在应用和WEB服务器上
PeopleSoft HCM(多语种)
9.2
安装在应用和WEB服务器上
Oracle Tuxedo
11cR1
安装在应用和WEB服务器上
Weblogic
12.1.2.0.0
安装在应用和WEB服务器上
Oracle SES
11gR2
独立安装或安装在其中一台应用和WEB服务器上
Cobol编译器
5.1
安装在应用和WEB服务器上
Microsoft office（客户端使用）
Microsoft office 2003软件，或以上版本
安装在客户端
CA数字证书
可选
WEB服务器部署https协议使用

5.2.5.5备份策略
5.2.5.5.1 Oracle 备份和恢复
Oracle应用系统提供完善的备份和恢复机制，利用Oracle数据库的强大技术优势，Oracle应用系统可以提供热备份、冷备份、EXP/IMP逻辑备份和基于RMAN备份恢复管理软件的联机备份和恢复，能够允许在联机环境下对数据库和日志进行备份和恢复，同时Oracle的合作伙伴Xpress Archiver、Outerbay等都提供针对Oracle应用系统的归档备份解决方案，可以将Oracle应用的历史记录进行归档存放，保证在系统运行多年后不会由于数据量的大幅增长而降低性能。

5.2.5.5.2 Hyperion 备份策略：
为了防止计算机硬件故障或其他人为因素造成的系统崩溃或者合并或预算系统数据丢失，必须充分考虑系统数据安全性，重视日常的系统备份工作以及系统恢复准备。
· 数据安全性：
从数据安全性角度出发，在正式环境系统硬件配置时，考虑到应用服务器和数据服务器的差异后，在应用服务器的磁盘配置时可以使用RAID0+1，数据服务器的磁盘配置可以使用RAID5。这样的设置可以在很大程度上提高了系统的稳定冗余性，同时也有效保障磁盘数据读写的效率。

· 系统备份策略
HFM合并系统的备份：合并系统的备份主要包括2 个部分：合并应用服务器的备份，和合并应用中的数据备份。 前者可以通过对应用服务器的文件系统备份来完成； 而后者是对Oracle DB中的应用数据库的备份。 根据生产环境和开发与测试环境的硬件配置情况，可以将生产环境中的备份数据存放在开发测试服务器的指定文件夹下。测试服务器也可做为生产服务器的应急还原点。

· 备份频率
对不同备份内容应考虑适合的备份频率。
具体备份频率策略参照下表：
项目
备份频率
备份期间
操作系统备份
1次/变动
操作系统安装完成后及每次操作系统更新
应用程序备份
1次/变动
应用程序安装完成后及操作系统备份时
数据库备份
关系型数据库备份
1次/天
HFM系统开发与调试阶段
1次/天
HFM系统正常使用时
不低于1次/月
其余时间

6 项目实施管理方案（闵捷-侧重于实施保障）
7 项目报价（王会利）
7.1 软件报价
7.2 实施报价