企业信息化系统集成方案Word下载.docx

企业信息化系统集成方案Word下载.docx

《企业信息化系统集成方案Word下载.docx》由会员分享，可在线阅读，更多相关《企业信息化系统集成方案Word下载.docx（34页珍藏版）》请在冰豆网上搜索。

一套系统、集中部署，落实全集团核算过程的统一，利用主数据、合并报告等手段，整体提升集团层面集中管控能力。

具体来看，本期工程重点要达成以下目的：

▪建设集中化的财务核算系统，通过集团统一核算规则及管控规则的集中固化，替换原总部及各工程局、专业公司、设计院等子属分散部署的财务核算系统；

▪与资金系统、报账系统集成，形成业财协同和财财融合体系，实现核算自动化，提升交易处理效率；

▪实现总部、各工程局、专业公司、设计院等子属之间的关联交易协同，提升对账准确性和及时率；

▪与合并系统集成，实现对外披露报表的自动化，实现全集团报表一点出具；

▪与预算系统、资金系统、税务系统集成，提升财务专业运营能力，支撑管理会计体系的构建，助力财务转型。

通过上述目标的达成，最终实现“纵向上，集团管理贯穿所有组织层级，实现纵向信息穿透、管理一体化；

横向上，业务横向贯穿业务部门，实现业财协同；

决策上，实现一个、一副面孔，一个数据口径、一套决策体系”的集中化财务管理平台。

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）代码测试

参与代码测试的人员主要为提出需求的关键用户或实施顾问、代码开发人员。

参照功能设计文档，需求提出人员检查程序是否符合所提出的要求；

当发现问题时，及时反馈给代码开发人员，由其负责修改代码。

整个测试过程按照“测试-修改-再测试”的循环进行，直至问题均解决。

测试文档应当涵盖如下内容：

•测试方法

•测试数据

•测试日志

测试方法与测试数据将依据功能设计、技术设计而编写。

根据程序的复杂程度，测试方法与测试数据的内容详细程度可不同，简单的程序只要阐述出测试方法和所预期的结果既可；

复杂的程序则要设计详细的测试步骤、测试数据。

测试日志用于记录测试中出现的问题，以及解决结果。

测试人员与开发人员循环检查该文档，并根据需要进行修改、填