企业信息化系统集成方案.docx
《企业信息化系统集成方案.docx》由会员分享，可在线阅读，更多相关《企业信息化系统集成方案.docx（41页珍藏版）》请在冰豆网上搜索。
企业信息化系统集成方案
企业信息化系统集成方案
1项目概述3
2详细规划方案4
2.1技术实现方案4
2.1.1集成方案4
2.1.1.1技术管理建议方案4
2.1.1.2统一用户方案29
2.1.1.3统一认证（单点登陆）方案30
2.1.1.4统一待办任务集成方案33
2.1.1.5消息集成方案34
2.1.1.6移动集成规范方案36
2.1.1.7UI规范方案38
1项目概述
通过架构顶层设计和统一管理，加强数据共享和业务协同、支撑未来业务快速上线。
对于财务核算系统建设的总体目标，理解主要包括以下两个方面：
▪提升集团“财务服务能力”：
基于统一核算规则，全流程贯通，全面协同，提升管理效率，降低管理成本，支持财务转型；
▪提升集团“财务管控能力”：
一套系统、集中部署，落实全集团核算过程的统一，利用主数据、合并报告等手段，整体提升集团层面集中管控能力。
具体来看，本期工程重点要达成以下目的：
▪建设集中化的财务核算系统，通过集团统一核算规则及管控规则的集中固化，替换原总部及各工程局、专业公司、设计院等子属分散部署的财务核算系统；
▪与资金系统、报账系统集成，形成业财协同和财财融合体系，实现核算自动化，提升交易处理效率；
▪实现总部、各工程局、专业公司、设计院等子属之间的关联交易协同，提升对账准确性和及时率；
▪与合并系统集成，实现对外披露报表的自动化，实现全集团报表一点出具；
▪与预算系统、资金系统、税务系统集成，提升财务专业运营能力，支撑管理会计体系的构建，助力财务转型。
通过上述目标的达成，最终实现“纵向上，集团管理贯穿所有组织层级，实现纵向信息穿透、管理一体化；横向上，业务横向贯穿业务部门，实现业财协同；决策上，实现一个、一副面孔，一个数据口径、一套决策体系”的集中化财务管理平台。
2详细规划方案
2.1技术实现方案
2.1.1集成方案
2.1.1.1技术管理建议方案
客户化开发工具及擅长的开发内容建议：
ORACLE开发工具
优点
劣势
XMLPUBLISHERE
1.擅长报表格式比较固定的报表；
2.可以提供多种输出方式：
EXCEL,PDF,WORD,HTML等；
3.可以做出与所提供报表格式比较一致的报表
1．不擅长维度分析型报表；
2．需采用请求方式提交报表，查询结果不是很直观
BIEE
1．擅长分析型报表，可对各分公司或项目放在一张报表中进行分析；
2．多种展现形式：
仪表盘，图表等
3．可导出成EXCEL
4．可以使用ORACLEERP一些内置模型进行报表开发和展现；
5．标准的数据仓库技术
1．需进行数据的ETL转换将数据抽取到数据仓库
2．数据建模、开发工作量比较大
3．一般不用来展现实时数据
4．得单独购买硬件、软件。
DBI
1．擅长非复杂结构的报表展现，如一些单个指标类的数据；处理格式简单的二维表比较容易。
2．支持图形和报表相结合进行展现
3．可以输出成excel
4．数据展现部分开发方式容易掌握，业务人员都可进行报表展现调整。
5．商务智能模块已经预置一些指标和报表
1．不支持格式复杂的固定报表如贵公司提供样例中的项目成本管理报表；
2．不支持多维度分析型报表，不支持维度拖拉拽的方式，如多个分公司或多个项目的数据横行展示。
3．输出数据不是很直观，操作者需改变查询习惯。
另外，ORACLE自带的查询可能与企业需求不相符。
WEBPAGE（OAF）
1．符合ORACLEERP产品未来发展趋势；
2．纯WEB操作，简单易用；
3．查询和展示比较灵活；
4．可以在展示时进行复杂的业务逻辑转换和运算；
5．适合实时数据的查询；
6．可以开发出进行数据追溯等的复杂功能
7．可实现对于一些需要进行数据录入才能出来的报表的数据录入和维护
8．输出界面比较直观，与ORACLE标准功能界面也比较一致。
1．开发的工作量比较大
2．对于多维度分析型报表不支持需转换展现方式
3．对于输出格式的支持力度不强，需要额外的进行开发。
客户化开发管理：
（1）需求调研
需求调研的最主要目的是明确开发内容，其次是评估开发耗费的人工时，并做出合理的开发计划。
其间应当遵循以下基本出发点：
•以实施方案为基准
•满足方案中确定的流程需求
•技术可行性
参与人员与职责
调研工作需要由开发人员、实施顾问、关键用户、最终用户完成。
其中职责分配如下：
•关键用户、最终用户按照业务情况提出需求
•实施顾问对照实施方案确定该需求是否符合方案要求，是否必要
•开发人员确定该需求在技术实现上的可能性，做出初步实现方案，并对耗费的人工时作出预估
需求一般是由关键用户、最终用户提出的。
但在项目实施的初期，用户由可能并不是完全对方案确定的流程、系统能够提供的功能有透彻的了解，故此提出的需求往往是基于以往的工作经验，以及原有系统的功能。
对此，需要实施顾问按照实施方案的要求来判断该需求是否合理、必要。
这一步骤上，实施顾问应从满足最基本的业务流程出发，对需求作出过滤，减少开发不必要、或者是不是很迫切的功能。
在经过实施顾问的过滤后，开发人员应对其技术实现的可能性、风险性作出评估。
一般来说，只要需求是在逻辑上合理的，在技术上就有实现的可能。
但开发人员应当注意到某些开发的风险性，如对底层数据库的直接操作、对原有程序的修改等。
由于没有使用标准的接口、修改后程序可能被PATCH覆盖等因素，我们不能支持此类开发能够在任何时候支持百分之百的正确，故此应当作为潜在风险向客户提出，并要求获得客户的确认。
在确定开发内容后，开发人员应初步确定技术实现的大致方案，如整体框架、实现工具，并对需要的人工时作出预估，进而作出开发计划。
调研文档
需求调研的结果体现为调研文档，其中包含2项内容：
开发方案及人工时预估、开发计划。
开发方案及人工时预估
此文档应涵盖以下方面：
•开发整体构架
•开发项目列表
•实现工具
•人工时预估
•潜在风险
此文档需要经过实施方、客户方项目经理的签字认可后才可生效，并转入下一步的开发工作。
开发计划
开发计划基于前一文档中对开发人工时的预估。
在考虑实际投入的开发资源后，排出具体的进度，用以控制开发的正常进行。
此文档中应明确：
•开发工作的结束时间。
由于系统上线可能分若干个阶段，故此也可再进行细分，并据此对每一时间段的开发工作进行明确，即为支持该阶段系统上线所需要的开发任务能够完成，将次要的开发任务推迟或取消。
•每一项开发任务的起始日期和结束日期。
•每一项开发任务上投入的人力资源（即指定开发人员）。
此文档推荐使用MSPROJECT编写。
调研阶段的结束
调研工作以提交调研文档，并获客户签字认可为结束标志。
实际开发工作开始后，应支持方案的稳定性、权威性，不得随意修改。
任何涉及整体构架、流程的变更需按照需求变更流程实现。
（2）功能设计
在经过调研阶段的初步讨论和最终方案的指导下，需要将需求以尽可能详尽的文字表达出来，即形成功能设计。
参与人员与职责
此文档要求编写者对ERP系统有较深入的了解，熟悉系统的操作风格，并按照ORACLEAPPLICATION的标准术语来对希望实现功能进行描绘。
功能设计需要由实施顾问完成，或者在实施顾问的指导下由关键用户完成。
文档要求
此文档的基本要求是：
详尽、准确、用语标准。
此文档应当向它的阅读对象，即技术设计人员，描绘以下信息：
•该程序的业务背景（实施方案）、业务目的
•该程序的主要功能，如分析打印目标数据、生成目标数据
•该程序的界面表现，如输出纸张大小、字段格式、排序方法、参数内容
•该程序的操作步骤
此文档中的用语应当符合原有系统程序的标准，并在操作风格上与之保持一致。
功能设计的确认
功能设计需要由技术设计人员审阅，确认其提出的每一细节均符合整体方案规范、符合程序标准、可以在程序中实现。
对于技术设计人员认为可能引起歧义的地方，需要修改文档，作出明确解释。
确认无误后，须由客户方和技术设计人员签字人可，并将此文档归档。
已归档的功能设计在技术设计开始后，除非逻辑结构有重大变化，否则不得随意更改。
其更改办法参见需求变更流程。
在以上基础上方可转入下一开发阶段。
（3）技术设计
按照需求设计的要求，以程序的语言描述该功能是如何实现的，即形成技术设计。
参与人员与职责
此文档的编写者应当是有开发经验的技术人员，并应具备以下条件：
•了解ERP系统的构架
•了解ERP系统的程序实现方法
•了解ERP系统的各种开放接口
•了解Developer10g、SQL等开发工具
编写者应结合功能设计的具体要求，选择合适的开发工具，设计合理的逻辑结构，并对实现中的细节作出说明。
文档要求
技术设计文档应当涵盖以下几方面的内容：
•使用的开发工具
•程序的标准命名（如程序名、参数名、对象名等）
•程序所需参数的设置（如类型、长度等）
•程序的逻辑流程（如流程图、伪代码等）
•细节功能的实现（如对象属性设置、某字段的取值方法等）
•数据库中所需的对象（如新建的VIEW、SEQUENCE等）
•ERP系统中必要的设置（如参数所用值集、预置文件等）
开发工具的选择主要基于实现的难度、与ERP系统的整合性。
一般来说主要使用原有ERP系统的开发工具（Developer10g,PL/SQL,java等）。
ERP系统中的程序命名均有一定的标准，客户化的程序也应当遵循，以保持与原系统的风格一致。
技术设计中要使用尽可能详细的程序语言来表述逻辑设计思想。
其中可是用流程图等工具，此外还可以编写伪代码。
需要注意的是，伪代码并不需要详细到每个SQL语句的具体写法，而只是需要表明设计意图即可。
设计人员应当给代码编写人员留出一定的空间，方便其在实现代码时作灵活的修改。
对于需要在数据库、ERP系统中新建对象、做必要设置等工作，技术设计应当做出详细的描述。
代码编写人员不得对此部分内容进行修改。
此文档对应于AIM中的MD070，并以此编号，可参照其标准格式。
技术设计的确认
技术设计文档完成后，交开发人员确认，并转入代码编写阶段。
（4）代码编写
依据技术设计所示的逻辑结构，将其翻译成真正的程序，即代码的编写。
参与人员与职责
代码编写人员应具备以下条件：
•对ERP系统的构架有一定的了解
•熟悉Developer2k/6i、SQL等开发工具的使用
代码编写人员应遵循技术设计中明确的逻辑结构，将其用具体的真实代码再现。
程序要求
代码编写人员在具体的开发工作中应遵循以下要求：
•严格遵循技术设计中的逻辑结构
•在代码的实际写法中可有灵活的修改
•代码规范应符合“ORACLEAPPLICATION开发员手册”中的要求
•注意代码的性能
代码编写的完成
程序开发完成后，开发人员须作初步的测试，支持程序可正常运行后，再交由测试人员进行测试。
（5）代码测试
参与人员与职责
参与代码测试的人员主要为提出需求的关键用户或实施顾问、代码开发人员。
参照功能设计文档，需求提出人员检查程序是否符合所提出的要求；当发现问题时，及时反馈给代码开发人员，由其负责修改代码。
整个测试过程按照“测试-修改-再测试”的循环进行，直至问题均解决。
文档要求
测试文档应当涵盖如下内容：
•测试方法
•测试数据
•测试日志
测试方法与测试数据将依据功能设计、技术设计而编写。
根据程序的复杂程度，测试方法与测试数据的内容详细程度可不同，简单的程序只要阐述出测试方法和所预期的结果既可；复杂的程序则要设计详细的测试步骤、测试数据。
测试日志用于记录测试中出现的问题，以及解决结果。
测试人员与开发人员循环检查该文档，并根据需要进行修改、填写。
此文档对应于AIM中的TE020/TE040，并以此编号，可参照其标准格式。
测试阶段的结束
测试阶段将以所有测试均顺利通过、所有发现的问题均解决为结束标志。
（6）安装手册及用户手册
参与人员与职责
安装手册由技术设计人员或代码开发人员编写。
用户手册由功能设计人员编写。
文档要求
安装手册应当涵盖以下内容：
•安装环境
•必要的application设置
•必要的数据库对象
•代码的复制、编译
•其他的注意事项
安装手册对应于AIM中的MD120，并以此编号，可参照其标准格式。
用户手册依据功能设计编写，应当涵盖以下内容：
•相关的业务背景
•运行程序的步骤
用户手册对应于AIM中的DO070，并以此编号，可参照其标准格式。
（7）需求变更
变更流程
需求的变更往往是造成开发任务无法及时完成的重要原因，所以在前期应充分全面地考虑开发需求及方案，尽量避免在开发过程中对需求进行反复的修改。
在必须进行变更的情况下，则按照以下原则、流程进行：
•已确认的方案、设计不可随意更改
•需求的变更申请须使用标准文档提交
•变更申请文档需要经过客户、顾问双方的经理签字确认后，方可实施修改
•需求变更后，必须按照以下顺序逐个修改相应文档、程序：
a.修改整体方案
b.修改功能设计
c.修改技术设计
d.修改程序代码
e.修改测试文档，重新测试
f.修改安装手册、用户手册
文档要求
需求变更文档对应于AIM中的CR060，并以此编号，可参照其标准格式。
（8）相关工具的使用
本节讲述在二次开发工作中可使用的若干工具。
开发计划及进度控制软件
目前使用的开发计划及进度控制软件为MicroSoftProject。
使用该软件可方便地进行维护开发列表、跟踪开发进度等工作。
开发汇总表
为了更好的管理开发项目中的文档和代码，要求各个项目均有一份开发汇总表。
该文档用EXCEL编写，其包含如下列内容：
•所属模块（如PO、FA、GL等）
•程序中文名、中文描述
•程序类型（如FORM、REPORT、SQL脚本、PL/SQL存储过程等）
•程序名（程序文件名、相关脚本文件名等）
•总体方案文档名
•功能设计文档名
•技术设计文档名
•安装手册文档名
•用户手册文档名
（9）编码标准
本节讲述在OA开发中应遵循的编码标准。
具体内容分以下3部分：
•CODING原则
•标准开发环境
•命名标准
CODING原则
进行OA开发，首先必须遵循以下原则：
•代码要保持良好的可读性和可维护性
•代码要支持在繁忙网络条件下仍然拥有良好的性能
•代码要有良好的可重用性
•代码要有良好的跨操作平台能力
•尽量使用FORM、PL/SQL等工具完成所有的编码（尽量避免使用其它编程语言编写复杂的用户出口函数）
代码要保持良好的可读性和可维护性
在FORM的开发过程中，对TABLE、ITEM等对象尽量地使用HANDLER进行操作。
使用HANDLER可以避免代码分散在大大小小的TRIGGER中，对代码进行集中管理。
有利于开发、维护及调试。
代码要支持在繁忙网络条件下仍然拥有良好的性能
在网络条件下要支持程序的良好性能，其关键在于减少网络流量。
–代码尽可能地在服务器端完成
–尽可能地在本地取得所需变量
代码要有良好的可重用性
–将可重用的代码以库的形式保存在数据库中
–FORM中，可重用的代码应尽量写成单独的PROCEDURE
代码要有良好的跨操作平台能力
–避免直接对操作平台中的对象进行操作
–使用APP_STANDARD.PLATFORM函数包校验是否存在依赖操作系统平台的代码
标准开发环境
OA为开发者提供了一系列的工具，并用丰富的预定义资源组成了便利的开发环境。
开发者在工作中需要加以注意使用，以加快开发速度和提高代码质量。
命名标准
良好的命名方法能够使得程序保持良好的易读性，便于后期的维护工作。
所以在开发过程中，必须依据以下规则对各个对象命名，尽量避免使用如misc、common、other等笼统的对象名。
2.1.1.1.1技术文档交付和管理方案
技术文档管理原则
技术文档特指与项目有关的各类资料，包括文件、通知、项目交付品、会议演示资料、发放的资料、宣传资料、录像、录音等；技术文档的管理遵循如下原则：
•技术文档特指与项目有关的各类资料，包括文件、通知、项目交付品、会议演示资料、发放的资料、宣传资料、录像、录音等；
•必须基于项目的标准模版、命名规则和存储要求；
•分发的确认和会签的文件，必须建立跟踪记录；
•所有文件创建人、审核人、修改人都必须在文件的修改记录内登记；
•所有签字的文件必须完整地保留在项目的文件夹内；
•所有文件模板的建立与改动集中管理，实施文档和日常项目管理文档模板及其命名规则的建立和改动分别由专人负责；
•文档存储要求：
应使用光盘或纸张（硬拷贝）等介质进行应用程序、数据及相应文档的存储；
•文档编写要求：
文档的编写应符合中国国家标准及集团制定的有关标准和规定的要求；
•提交数量：
根据要求提交纸质文档若干份，和一份以光盘为介质的电子文档。
技术文档工具
本项目将主要使用以下版本的文档处理与查看软件，以支持项目管理：
1.MicrosoftWord2010——文本文档；
2.MicrosoftExcel2010——表格/数据文档/项目计划；
3.MicrosoftPowerpoint2010——演示/汇报；
4.MicrosoftProject2010——项目计划；
5.MicrosoftVisio2010——流程描述；
技术文档安全
技术文档将在项目共享目录下保存。
技术文档将作为项目工作成果，由项目管理小组指定专人负责备份。
技术文档一旦通过批准，则被标记为Final版本，将被保存。
Final版本的文档如需变更，应按照严格的变更管理程序执行，并由项目管理小组负责管理文档编码的控制。
技术文档清单
整个项目实施过程中，项目组提交的文档以简体中文编写。
阶段名称
呈交文件/成果
内容
文档编码
一
建立实施策略
质量计划（包括范围，目标，和方法）
这份文档概括描述了项目的各项工作的构成和总体框架。
包括：
系统结构、培训、设计、数据转换、项目组织、变更流程、项目风险与规避以及项目的关键目标
CR.010/SOA
项目工作计划
项目计划：
包含项目明细任务、资源分配、各里程碑的目标日期和关键路径
CR.PMP
二
业务流程分析
未来业务流程模型
未来业务流程图定义了每个业务的流程及其子流程。
主要为了定义远景目标、重要特点和未来的业务流程蓝图。
BP.080
业务要求差异文件
所有业务需求和已定流程的汇总
BR.030
三
设计解决方案
系统设置文件
根据方案匹配结果，满足需求的Oracle产品各模块功能设置明细记录文档
BR.100
四
建立应用系统
个别程序测试计划，数据，与结果
按照数据转换和技术规格说明书的要求，每个程序完成后进行单元测试（包括测试数据和结果），要求是很完整的单元测试
TE.020
集成测试计划，数据，与结果
类似于单元测试报告的内容
TE.040
用户测试认可证明书
来自用户的满意度（对单个模块）测试证明
TE.UAC
五
系统切换
系统切换方案
新旧系统切换的方案、失败回退方案
系统切换计划
详细切换步骤、时间安排
系统切换报告
切换后的成果报告
六
运行维护
培训手册
类似于用户手册，但内容侧重在培训方面
DO.070
用户手册
用户手册包含的内容：
系统实施后，买方要进行的日常操作流程的描述
TR.010
系统投产验收清单
清单内容包含：
所有的可提交结果或推广前要达到并接受的所有里程碑
PM.PAC
实施推广计划
一份计划：
包含实施时间、过程、期限、数据转换计划和验收方法
PM.010
系统转换计划与数据
一份计划：
包含所有转换数据的提取时间、转换次序和验收方法
CV.010
系统投产验收测试
在数据转换完成，系统已准备就绪，准备切换上线的验收测试
PM.PAT
七
项目结束
项目实施总结报告
系统实施后，实施回顾和用买方数据来验证的一份总结报告
项目初验报告
初验运行情况、存在问题及其解决时间安排
项目初验证书
项目已通过初步验收的证书
项目终验报告
系统运行及试运行情况、初验遗留问题解决情况
项目终验证书
项目已通过最终验收的证书
八
项目管理
变更申请表
项目周工作进度报告
项目月工作进度报告
会议纪要报告
工时表
项目管理过程文件
CR.CRF
CR.PWS
CR.PMS
CR.PMI
CR.PWS
文档传递规则
为规范技术文档的传递，建立完整、统一的文档发出、接收、抄送程序，以方便项目人员参考，特制定本规则。
本项目所进行的文档传递须按此规则执行。
项目组在项目管理过程中指定一名项目文档管理员，具体的工作职责如下：
∙负责项目文档的收集和汇总；
∙负责项目文档的分类整理，并根据编码规则对项目小组成员交付文档的命名进行审核和修改；
∙负责项目文档按类别和编码进行存档和更新，并做好文档记录工作；
∙根据项目经理的审核，进行项目文档的相互传递和确认工作；
∙负责项目文档编码的维护，包括编码新增、删除和更改，并及时进行相互间的通报；
∙根据项目经理的审核，进行项目文档的内部传递或抄送工作；
∙项目小组的各级成员都必须积极配合项目文档管理员的工作。
文档查阅管理
凡涉及项目有关的文档均属于保密范畴。
文档资料按照公开的对象不同分为三级：
项目经理及以上人员可以查阅且不能公开的资料为第一级；项目组成员可以查阅且不能公开的资料为第二级；公司所有员工均可以查阅的资料为第三级。
项目相关的资料统一存放在公共服务器上，指定专人负责维护服务器，支持稳定运行、足够的存储空间和数据安全。
公共服务器上的资料按照级别对用户进行管理。
公共服务器上的资料由项目管理小组专人负责维护，需要及时更新。
项目小组成员应严格遵守保密制度。
2.1.1.1.2技术开发流程
公司的OracleERP客户化开发方法论如下：
为了支持客户化的开发质量，减少不必要的开发成本，加速知识转移的进程度，所有的客户化的开发都必须遵守下面的具体开发流程。
每一个客户化都有完整的生命周期，在项目的实施过程中，我们采用EXCEL模板方式的客户化清单来评估开发的工作量，管理和控制开发的进度，根据项目实施的具体要求来调整客户化的优先级等。
模板示例如下：
在ERP系统的开发工作中，客户化开发将根据需要进行四个层面的测试。
∙单元测试
尽管不要单独交付，开发者还是需要对每个客户化开发做单元测试。
开发者将负责定义单元测试的CheckList。
单元测试将验证程序的功能符合功能需求文档，以及适当的异常操作。
单元测试重点在从各个方面测试一块代码。
开发者应该将重点放在错误处理。
比如，当测试定制表单时，开发者应该放些特殊字符到所有字段尽可能让表单去处理。
单元测试一般由开发者自己执行。
∙集成测试
将客户化开发放到业务流程中，进行端到端的测试，支持整个流程产生的结果是正确的。
集成测试一般由功能顾问、关键用户和开发人员共同执行。
∙用户接受度测试
用户接受测试执行一个“生命中的普通一天”的测试场景。
例如，用户执行每天，每星期，每月的普通工作流程。
用户接受测试将验证客户化功能符合功能需求文档。
用户接收测试通过后，客户化开发才可以部署到生产环境。
∙技术层面测试
技术层面的测试包括：
压力测试和补丁程序测试。
这些测试一般不针对某个具体的客户化程序
升级会员 