企业信息系统开发工作标准.docx

北京xx集团信息系统开发工作标准
（A-0）
一、总则
1.目的和作用
为加强公司信息系统开发过程的管控力度，进一步提高系统开发的质量和水平，根据公司《信息系统建设管理办法》及相关规定，制定本标准。
2.适用范围
本标准是公司范围内信息系统开发的指导性文件。
本标准适用于公司范围内企业管理信息系统的开发工作，包括不同类型、不同规模的城市事业部、控股公司所建立的不同系统。公司所属子公司、下属分公司或分支机构（以下简称所属机构）、控股公司在贯彻执行本标准过程中可根据自身的特点对标准的有关内容进行适当的调整和补充。
本标准所推荐的文档，在使用过程中可根据实际情况进行选择和调整。
3.主要内容
根据管理信息系统开发特点，将系统开发工作划分为:项目启动、项目计划、项目执行、项目结束四个阶段。也对建设方与开发方在各阶段的工作内容、文档要求等做出了相应的技术及管理约定。同时，对于不同信息系统间进行集成时的数据接口开发工作也规定了相应的技术标准。
4.规范性引用文档
GB/T 8566-2007《信息技术软件生存周期过程》
GB/T8567-2006《计算机软件文档编制规范》
二、术语定义
1.企业管理信息系统
企业管理信息系统是综合利用计算机技术、通信技术、管理科学，对企业内外部管理信息进行收集、加工、存储、传输、维护和使用，辅助企业的各级管理人员控制、决策及趋势预测，以实现企业管理目标的计算机系统。
2.信息系统开发周期
根据信息系统项目开发的管理特点，科学地将开发周期分为项目启动、项目计划、项目执行、项目结束四个阶段，内容上涵盖可行性分析、需求分析、总体设计、详细设计、编码、测试、验收等工作。
3.系统测试
针对整个信息系统，即将已经确认的软件系统、计算机硬件、外设、网络等相关元素结合在一起进行测试，目的是验证系统是否满足需求规格的定义，找出与需求规格不符或与之矛盾之处，从而提出解决方案的过程。
4.数据接口
软件开发商向用户或者第三方提供的一系列的数据标准规范，其作用是进行不同软件系统间特定数据的交流及转换。其形式可以是经过封装的应用程序的接口函数，也可以是一些固定格式的数据文件，或是数据库的某种具体形式。　　
三、系统开发工作
1.系统开发周期
信息化项目系统开发周期应分为启动、计划、执行、结束四个阶段（如下图）。
各阶段工作应按顺序依次完成。建设方应对每个阶段工作任务完成情况进行验收确认，原则上不允许在未对上一阶段成果进行确认与验证的情况下，进入下一阶段。可根据项目实际情况对此阶段划分进行调整。
2.启动阶段
2.1项目启动阶段，建设方首先应进行目标系统的领域研究工作，对项目进行可行性研究，从而明确信息系统开发建设目标，同时确定系统开发项目工作的范围，评估所需资源、风险、预算等条件。具体工作如图2.1所示.
图2.1启动阶段工作任务及文档

2.2在系统开发之前，建设方应对所开发系统的行业领域状况进行背景研究工作，为项目论证提供依据，研究内容应包括：
（1）开发系统所在领域的现状和前景；
（2）开发系统普遍采用的商业模式和业务流程；
（3）行业内各开发商的现状；
（4）开发系统的特性和复杂度。
2.3建设方应基于商业和技术等因素，对目标系统进行可行性论证，确定项目是否开展。论证的内容包括：
（1）商业可行性；
（2）技术可行性；
（3）与行业内类似系统的比较；
（4）与本单位已有系统的集成可行性；
（5）开发的成本和风险；
（6）项目开发的总体方案 。
具体内容请参考附件1《项目可行性分析报告》。
对于重大或复杂项目，建设方可酌情聘请专业信息化咨询方介入，协助把控项目论证及以后各阶段的具体工作。
2.4项目启动阶段，建设方应组织各相关方对项目的目标范围进行确认，形成《项目开发大纲》向开发方交底，并为项目开发的计划阶段做准备。《项目开发大纲》的内容如表2.4所示。表2.4
内 容
说明
概 述
明确系统目的。
核心功能
描述系统每个核心功能。
一般功能
描述系统通用的非核心功能。
相关方
基于建设方管理模式，明确系统开发所涉及到的各个相关方（如主责部门、需求部门、咨询方、开发方等）。
项目需求
描述总体的项目需求。
项目风险
对可预见的风险进行分析，并提出规避风险的主要措施。
项目回报
系统上线后的成果性预测。
结 论
将上述所有部分联系起来，明确项目的需求和风险，确定项目可以最终成功的论点与论据。
3.计划阶段
3.1项目计划阶段，建设方应与开发方一起确定项目的功能范围、质量与进度目标，开发方评估每项工作的工作量及所需资源；双方在此基础上共同制定整体的项目管理计划，应包括：项目开发计划、风险管理计划、质量保证计划及开发进度计划。具体工作如图3.1所示。
图3.1计划阶段工作内容及文档

3.2在计划阶段，建设方应要求开发方对项目的规模、工作量等进行评估，并进行确认。开发方应出具工作量评估报告。评估的内容包括：
（1）模块数量、复杂度、质量目标；
（2）输入、输出和对外接口数量与复杂度 ；
（3）重要功能点 ；
（4）开发工作量（人/月或人/天） ；
（5）进度与里程碑 ；
（6）进度风险。
3.3开发方出具的《项目开发计划》内容见下表3.3。

表3.3
内容
说明
概 述
描述系统目标、功能、平台、客户、大体进度和开发职责。
系统功能
建设方概述系统的功能，包括这些功能的附加信息，以便开发方根据这些的信息来了解并实现需求。
项目成员
确定软件工程职能角色，以及分配到这些角色的人员数量。
系统开发过程
概述这个项目中所应用的软件开发过程。
系统开发方法
概述这个项目中所应用的软件工程方法和技术。
进度和工作量
描述整个项目进度和工作量，明确标明各里程碑和关键结点的工作成果。可用甘特图等工具图展示。
软件工具
列出将使用的每一项软件工具，以及该工具所支持的任务。
项目支持
硬件支持--明确所需的硬件，包括需要移动、获取或升级的硬件。
软件支持--明确所需的软件，包括需要获取、安装或升级的软件。
人力支持--明确建设方哪些人员为开发方的哪项任务提供支持。

3.4建设方与开发方应共同制定《风险管理计划》，主要内容包括风险识别、风险分析、化解方案等，详见表3.4：
内容
说明
概 述
用文字和图表概述风险管理任务的总体执行流程。
风险识别
详细说明“风险识别”任务的实施细节和各项工作的负责人。
风险分析
确定风险优先级，明确“风险分析”实施细节和各项工作的负责人。
风险化解方案
描述当风险发生时，化解工作的操作规范和流程。
风险监控
详细说明风险监控任务的实施细节和各项工作的负责人。

3.5建设方与开发方共同制定《质量保证计划》，内容见下表3.5.
表3.5
内容
说 明
概 述
简单说明编写的目的、适用范围以及对相关人员的要求等。
软件开发过程
详细说明这个项目中所应用的软件开发过程。
软件工程方法
详细说明这个项目中所应用的软件工程方法和技术。
工作规范
对软件工程方法中的各种工作任务进行规范，明确执行的时间、流程和准则等。这些工作任务规范包括但不限于：
---需求分析、架构设计、详细设计、编码和测试、验收等常规开发活动规范；
---工作例会、进度会议、审查会议等会议规范；
---方案评审、技术评审、质量评审等评审工作规范；
---系统规模评估、进度评估、缺陷评估、测试覆盖率评估等评估工作规范；
---技能培训、资料收集、客户沟通等其他工作。
3.6建设方应重点审查开发方提交的《开发进度计划》，主要内容包括工作任务项、任务描述、开始时间、完成时间、工作量、责任人、交付成果等。详见附件2《项目开发进度计划表》。
4.执行阶段
4.1项目执行阶段，建设方应根据项目管理计划配合开发方完成需求规格说明，监督开发方按照需求实现具体功能，并在过程中协调一切所需资源，如人员、设备、费用、技术、信息等，同时跟踪各项工作的完成质量，把控项目整体进度。具体工作如图4.1所示。
图4.1执行阶段工作内容及文档

4.2开发方应以建设方《项目开发大纲》等需求文档为依据，进行详细的需求梳理，直到细化的程度可以开展架构设计及界面原型设计工作，形成《需求规格说明书》，内容见表4.2。《需求规格说明书》的编制方式可根据实际情况进行调整或扩充，但必须包含以下内容：

表4.2
内 容
说 明
业务需求
归纳描述建设方提出的业务内容、必须实现的功能、需要达到的性能及质量等要求。
功能需求
根据上述建设方列出的业务需求，详细列出开发商必须实现的功能。
性能需求
（1）描述对运行速度、容量、并发性能的要求。
（2）描述对资源的利用率的要求。
（3）描述对外界输入的反馈速度和准确性的要求。
（4）描述对差错的负荷能力的要求。
系统需求
（1）描述目标系统必须适应的运行环境的要求 （包括运行平台、网络及其他硬件要求）。
（2）描述与其他系统兼容的要求 （包括与操作系统、数据库、浏览器及其他已有应用软件的兼容要求）。
（3）描述与外部其他系统和组件的接口要求。
质量需求
（1）约定对建设方重要的质量标志 （可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性）。
（2）约定对开发方重要的质量标志（可维护性、可扩展性、重复使用性、可测试性）。
其他需求
不属于上述需求范围的，但受到其他因素影响的要求，如：
--国家或地区的任何特别的标准。
--软件使用界面的特别要求。
--与知识产权有关的要求。
--软件所面对的市场和行业的规范。
--建设方的特别要求等。
需求规格说明书的具体内容，可参考附件3《需求规格说明书模版》。
4.3开发方应主导完成系统总体设计，并应在第一时间完成系统原型实施工作，以验证设计思路的可行性，同时提交《系统原型设计概要》文档，内容主要包括设计的理念、核心功能的设计与实现及与类似系统界面的对比等。开发方应与建设方一起对原型的界面设计及核心功能等进行开会讨论及确认。
4.4开发方根据需求分析及系统原型设计所确定的系统核心功能进行系统详细设计。对于重要的功能、算法、公共模块和外部接口等，建设方应要求开发方必须以模块设计说明书的形式进行详细描述，内容包括系统核心模块功能名称、设计思想、设计图表（类图、流程图等）、要点描述（包、接口、类、方法、算法、设计模式）及测试方式等。
4.5开发方在系统编程阶段应遵守行业编码规范，应充分考虑异常情况和临界条件，并对测试中产生的BUG进行记录。
4.6开发方在系统编程过程中应以功能增量的方式执行阶段的开发任务，每个阶段结束后应发布软件中间版本。阶段周期一般不超过两星期。对于每一个中间版本，由开发方负责主导测试工作，建设方配合参与，做到问题早发现早解决。测试发现的问题应留待下一周期中间版本解决。对每一中间版本的测试工作，开发方应总结形成《中间版本测试报告》的内容包括：
（1）测试用例汇总（用例数量、通过的用例数量、未通过的用例数量等）；
（2）BUG汇总表（BUG描述、BUG状态等）；
（3）测试计划执行情况等。
4.7项目执行过程中出现的多种变更，如：需求变更、设计变更等，建设方与开发方应共同评估变更风险及制定解决方案，并对变更处理过程进行跟踪，最后形成变更处理报告，具体格式及内容请参考附件4《变更处理报告》。
5.结束阶段
5.1系统开发的结束阶段，建设方应确保开发方所提交的目标系统达到需求的要求，进行整体测试与验收，归档各种项目文档，对整个项目过程进行总结等工作，具体工作如图5.1所示。
图5.1结束阶段工作内容和文档

5.2系统正式发布之前，建设方必须组织自身相关人员对产品进行完整测试，开发方随时根据测试结果对产品进行修改，当产品质量达到建设方预期后才能发布。建设方与开发方在测试结束后应发布《系统测试报告》。测试工作包含但不限于以下内容:
（1）易用性测试
建设方应检查：系统用户界面是否友好，避免出现中英文混杂的界面；信息是否清楚、易理解；系统中各个模块的界面风格是否一致；系统中的查询结果的输出方式是否直观、合理等。
（2）功能项测试
建设方应对信息系统需求规格说明书中的所有功能项进行测试，确保各项功能与需求规格说明书中的功能相符，确保功能点全部开发完毕。
（3）业务流程测试
建设方应对系统的业务流程进行测试，确保系统业务流程符合企业实际管理流程，公文流转准确、高效。
（4）容错测试
建设方应检查系统输入界面，确保系统对用户常见误操作进行准确、清晰的提示，如对重要数据的删除有警告和确认提示，以及确保系统对用户输入数据进行有效性检查，及时屏蔽用户的错误输入，识别非法值的同时，有相应的错误提示。
（5）安全性测试
开发方应向建设方证明系统中的密钥是以密文方式存储，展示系统保存用户操作日志的功能，以及当前系统中各种用户的权限分配设定。
（6）性能测试
开发方应根据需求规格说明书中的性能要求，对系统进行测试。可采用LOADRUNNER等压力测试软件对系统进行大用户数并发、数据库频繁存取等压力测试，分析测试结果，并及时向建设方反馈。如遇性能问题，开发方应确定原因，及时修改。
（7）适应性测试
开发方应参照建设方用户软、硬件使用环境和需求规格说明书中的规定，列出系统所适应的软、硬件环境，并对每个环境进行测试。
5.3开发方应针对不同的使用者角色，编制相应的用户文档，对管理员用户至少应提供《系统安装、维护指南》，对普通用户至少应编制《用户使用手册》。
5.4《系统安装、维护指南》的内容应包括：系统各组件的说明、系统部署架构、系统权限配置、安装、配置和卸载等步骤、启动、停止和重启等操作及其它操作，包括日志、备份、还原等内容。
5.5《用户使用手册》的内容包括系统介绍、各个功能的介绍及通过实际案例介绍各个功能的使用方式和操作步骤。
5.6开发方在正式发布前应对系统进行最后的修订，内容包括开发文档修订、用户文档修订、代码整理等。修订工作完成后，发布系统正式版，项目进入试运行阶段。
5.7建设方应对运行期间发现的每一个错误确定相应的严重性等级（见表5.7），并制定相应的处理措施。开发方应在规定的时间内对系统进行全面整改,整改后需再次进行完整的系统测试工作。
原则上系统出现下表所列一级或二级错误的情况，无论数量多少，建设方不予验收。具体错误等级对应表如下：
序号
级别
内容
1
一级
错误
（1）没有实现或错误地实现重要的功能；
（2）业务流程存在重大隐患；
（3）信息系统在操作过程中由于自身的原因自动退出系统或出现死机的情况；
（4）信息系统在操作过程中由于自身的原因对系统或数据造成破坏；在现有的软、硬件环境下不能实现应有的功能；
（5）特殊信息系统在操作过程中可能危及系统和人身安全等。
2
二级
错误
（1）没有实现基本功能，并且不存在替代办法；
（2）没有实现重要功能中的部分功能，并且不存在替代办法；
（3）业务流程衔接错误；密钥以明文方式存储；
（4）用户的权限分配不合理；
（5）没有满足系统的性能要求。
3
三级
错误
（1）没有实现基本功能，但存在替代办法；
（2）没有实现重要功能中的部分功能，但存在替代办法；
（3）对误操作或错误操作没有提示，导致非法数据进入数据库。
4
四级
错误
（1）界面不友好、前后风格不一致；
（2）中英文混杂；
（3）查询结果输出不直观等。
5
五级
错误
通常为文档方面的错误，如安装手册、操作手册、维护手册中的描述错误。
表5.7
5.8建设方应在系统稳定运行至少三个月后，方可进行系统验收。验收时应注重对系统开发文档的收集整理，验收文档包括但不限于：
（1）系统开发可行性研究报告；
（2）系统需求规格说明书 ；
（3）系统详细设计说明书，其中涉及核心功能数据库设计内容，应详细列出数据库设计概要与库表详细字段；
（4）系统安装、维护指南用户使用手册；
（5）要求的其它材料。
5.9项目结束后建设方需要对整个开发阶段的工作进行总结，形成《项目总结报告》，内容见表5.9。

表5.9
内容
说明
项目背景
开发目的、背景、参与人员、参考资料。
总体评价
开发效率评价、系统功能评价、技术方法评价。
重要心得
整个开发过程中的心得体会。
管理总结
其中涉及团队建设、沟通交流、需求调研、风险管控等管理总结。
技术总结
技术创新应用、疑难攻破办法、引用插件等。
四、系统集成数据接口标准
1.数据接口是开发方为实现不同系统间的数据交互所制定的标准数据规范。数据接口在设计时，应按照具备高容错性、可扩展性并尽量与行业内的标准数据接口规范相符的原则进行设计。
2.开发方在数据接口设计时，应尽量降低与系统各功能的依赖程度，从而降低接口开发的耦合性及复杂性。
3.数据接口可采用文件交换模式、应用程序接口函数模式、中间数据库等模式。开发方应综合考量建设方不同系统的架构特点、数据交互的复杂程度、数据安全性等因素，最终制定接口实现模式。同时将实现方式与建设方进行深入交底，详细阐明接口方案的利弊，在获得建设方的同意后，方可进行后续工作。
4.建设方在实施新老系统集成时，应明确告知开发方在目标系统中最大程度地遵照《北京xx集团信息编码系统》中的数据编码规范进行数据编码，以保证公司范围内各信息系统平台数据字典的总体一致性及数据存贮、交换格式的统一。
5.开发方在集成工作具体实施之前，应详细考虑不同系统间数据的匹配程度，对于含义相同但存储形式及规范不同的数据应事先建立一套数据映射标准，主要内容为：
---对于系统内字典信息，如工程项目名称、合同名称等，应采用集团《信息编码系统》所约定的规则将原数据进行转换，存储于目标系统中；
---对于系统其他信息，如货币、自定义字段类型等，根据目标系统数据的定义方式转换成文本、数值或二进制等数据类型。
6.开发方应对目标系统所接收的数据进行数据校验，在判断数据为合理有效的情况下，才可将数据录入目标系统数据库。数据校验工作内容包括但不限于数据约束校验及数据有效性校验。
7.建设方应要求开发方在数据传输过程与存储过程中采取以下措施以保证数据安全：
（1）在数据传输过程中，可采用密钥技术对数据进行双向加密解密操作，以保证敏感数据不被窃取。具体采用何种加密技术，经双方商定后，应严格保密，杜绝外泄。
（2）在数据存储过程中，应设定复杂的数据库访问密码，且定期更换新密码。对于传输的数据应做好数据库备份工作，在数据发生损坏或丢失时，可迅速恢复数据。
8.公司应根据数据中心建设情况，定期发布数据接口标准。其中数据中心工程立项及物资数据接口标准见附件5公司《xx平台立项及数据接口规范》。

附件：1.《IT项目可行性研究报告》模板
2.《系统开发进度计划表》
3.《XX系统规格说明书》模板
4.《变更处理报告》
5.《xx平台系统集成方案》

附件1：《IT项目可行性研究报告》模板
1.引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2.可行性研究的前提
2.1要求
2.2目标
2.3条件、假定和限制
2.4进行可行性研究的方法
2.5评价尺度
3.对现有系统的分析
3.1数据流程和处理流程
3.2工作负荷
3.3消费开支
3.4人员
3.5设备
3.6局限性
4.所建议的系统
4.1对所建议系统的说明
4.2数据流程和处理流程
4.3改进之处
4.4影响
4.4.1对设备的影响
4.4.2对软件的影响
4.4.3对用户单位机构的影响
4.4.4对系统运行的影响
4.4.5对开发的影响
4.4.6对地点和设施的影响
4.4.7对经费开支的影响
4.5局限性
4.6技术条件方面的可行性
5.可选择的其他系统方案
5.1可选择的系统方案(A)
5.2可选择的系统方案(B)
6.投资及收益分析
6.1支出
6.1.1基本建设投资
6.1.2其他一次性支出
6.1.3非一次性支出
6.2收益
6.2.1一次性收益
6.2.2非一次性收益
6.2.3不可定量的收益
6.3收益/投资比
6.4投资回收周期
6.5敏感性分析
7.社会条件方面的可行性
7.1法律方面的可行性
7.2使用方面的可行性
8.结论

附件2：《系统开发进度计划表》
项目名称：
编制日期： 编制人：
序号

工作任务项
任务描述
开始时间
完成
时间
工作量
责任人
交付
成果
备注
1

2

3

4

附件3：《XX系统规格说明书》模板
一、概述
1.总体要求
2.文档编写约定
3.系统介绍
4.系统用户
5.任务描述
6.系统总体设计要求
7.系统拓扑结构图
二、功能性需求
1.需求一览表
2.子系统需求一览表
3.模块关系图〔功能结构图〕
4.关键数据元素描述
5.关键数据状态转移图
6.关键数据元素状态
7.功能概述
8.业务处理流程描述
9.输出结果详细描述
10.与其他模块的相关性
三、性能需求
1.系统容量要求
2.系统响应时间要求
3.系统健壮性要求
四、用户界面需求及界面原型
1.用户界面设计原则要求
2.易用性、易操作性要求
3.界面原型
五、安全性需求
1.系统安全性需求
2.数据安全性需求
3.权限需求
六、接口需求
附件4：《变更处理报告》模板
申请人

申请部门

填写时间

项目名称

变更类别
（功能、页面设计、表单样式、表单流程）
变更操作
（新增、编辑、删除）
原因及内容

处理方式

造成影响

执行人

变更
时间

变更
结果

附件5：
xx股份有限公司
xx平台系统集成方案
一、前言
xx股份有限公司拥有多家供货商，存在多种系统进行物资采购信息的收集与管理。为达成统一管理的目标，需要将分散的采购信息数据按照统一的标准收集到公司。因此，为实现快速的将数据上报，特制定本集成方案。
本文的阅读者主要为物资采购相关业务系统的供应商。
二、数据集成流程说明
2.1集成流程总体介绍

针对公司已建物资采购相关业务系统的集成，主要采用二级单位推送数据到中间库的方式，中间库将创建一套符合公司业务标准的接口表，二级单位需将数据推送到接口表中。中间库利用基于平台开发的接口工具将数据传输到北京xx集团的中央库中。在向公司传输数据之前，接口工具会利用特定的校验程序，对接口表中的数据做一定的业务校验，校验不通过的数据将会被写入异常表中，供二级单位修正参考。
二级单位向接口表所推送的数据，需要符合北公司采购信息平台的业务标准规范，并满足相应的内容、格式、类型等要求，具体要求详见后续章节。
2.2数据校验说明
对接口表的合法性校验，主要包括两类校验机制：
（1）数据约束校验
通过数据库自身的机制（主外键约束）及时进行校验，拒绝不合理的数据写入到接口表中。在接口表创建的同时，创建业务表和基础资料字典表主外键关联关系，确保写入业务表中的基础资料编码是字典表中的数据。例如：项目立项表中的项目性质字段，与项目性质字典表创建主外键关联关系，则这个项目性质字段的值只允许输入项目性质字典表中存在的项目性质编码。
（2）数据有效性的验证
通过接口工具的业务校验程序，对接口表的数据进行有效性的验证，对于不符合业务要求的数据，将写入到相应的异常表中，在异常表的异常原因字段中会描述具体的原因。
2.3数据推送方式及数据验证处理说明
（1）传输方式
在向接口表推送数据时，可依据本单位的实际情况自行选择合适的实现方式。如：可采用特定的数据库抽取转换工具将本单位物资采购信息数据写入到接口表中。也可以自行开发一段数据写入程序，将本单位业务系统中的物资采购信息数据按照要求写入到接口表，或者采用其它的可行方式。但是，不管采取何种可行方式，一定要确保在接口表中的数据与自身业务系统物资采购信息数据在业务上的一致性。
（2）数据验证
A、对业务数据中的编码（如：项目立项信息中的项目性质、地域范围等）进行有效验证，异构系统把业务数据写到“BCEER_”前缀的表中时，如果编码在对应的数据字典表中不存在，本条记录将报违反主外键约束而报错，异构系统要对这些非标准的编码进行处理，处理后重新更新到对应的“BCEER_”前缀的表中。
B、接口工具进行数据集成前，接口工具先调用验证程序对“BCEER_”前缀的表的业务数据进行一定的业务合法性的校验，并将不符合业务要求的数据写入对应的“ERR_”前缀的表中，同时注明异常原因，如：对项目立项信息接口表中的工程名称进行验证，如果本条记录的工程名称验证失败，则把整条记录及验证失败原因（工程名称不可为空）保存到对应的异常表，验证通过的集成到中央数据库中。
2.4数据推送时间要求
为保障在xx股份有限公司的中央库中能及时获取到业务系统中物资采购信息数据，以及考虑到网络传输等因素的影响，系统的业务数据将在晚上非工作时间从中间库通过接口工具传输到公司的中央库。
二级单位要在每天晚上23点之前，完成对接口表的数据推送工作，并保证接口表中的数据与本单位的业务系统数据的一致性。在每天的23点至次日的早5点之间，不能对接口表进行新增、修改、删除操作。
在集成的各项工作准备就绪后、数据集成正式启动前，二级单位需要一次性的将现有业务系统中的物资采购信息数据插入到接口表，保证接口表中的数据与现有业务系统的有效数据是一致的。随后，将接口表中的数据通过接口工具传输到中央库中。
在后续的日常工作中，当二级单位的业务系统中的物资采购信息数据发生变化时，需要利用本单位的数据推送方式，将变化数据以天为单位及时更新到相应的接口表中。
2.5上报处理结果检查
在接口表中，每个表都有字段“是否已集成”、“集成时间”，用于标识该条记录是否已被处理及集成处理的具体时间，二级单位可以通过查看该字段的值来确定数据上报处理情况。另外，对于当天通过校验程序但校验没有通过的记录，会写入异常表中，在异常表中也会有“是否已集成”、“集成时间”记录数据写入异常表的时间，供修正时参考。
2.6数据存放时间说明
中间库中的接口表数据和异常表数据都长期保留，不进行清除操作，以备今后进行问题排查核对，同时要保障接口表中的数据与原业务系统中的物资采购信息数据一致。
2.7异构系统在集成中的操作流程
2.7.1流程图

备注：流程图中，红色背景的是异构系统要处理的流程。
2.7.2流程说明
（1）数据准备：按照中间库中“BCEER_”前缀的表提供的表标准，整理异构系统的业务数据。
（2）数据推送：每天的5点到23点时间内，异构系统按照自己的方式，把整理后的业务数据保存到中间库的“BCEG_”前缀的表中。
（3）数据校验，分二种情况：
（1）对“数据约束校验”的处理：对违反主外键约束的记录，异构系统要对这些非标准的编码进行“异常数据处理”，使之符合集团统一编码标准，处理后重新进行“数据推送”。如果本编码是新增编码，应及时告知集团业务人员进行处理；
（2）对“业务数据校验”的处理：接口工具数据集成操作完毕，在5点到23点之间，异构系统可以查看中间库异常表，对这些异常数据进行“异常数据处理”，处理后重新进行“数据推送”。
（3）继续执行步骤（1）。
三、接口表数据填报说明
3.1中间库表设计规则说明
中间库主要包含三类表：业务数据接口表、异常表和基础资料字典表。其中“BCEG_”为前缀的业务数据接口表，存放异构系统插入的业务数据的接口表集合。“ERR_”为前缀的异常表，存放集成时验证失败的数据的接口表集合。“BCEG_”为前缀的业务数据接口表与“ERR_”为前缀的异常表是一一对应的。
基础资料字典表：主要存放集团统一规范的基础资料数据，项目上线实施启动将统一初始化，以后如基础资料有调整，将由集团统一进行数据更新。
“BCEG_”为前缀的业务数据接口表与基础资料字典表之间存在主外键约束。
3.2中间库数据写入特殊说明
各接口表中“来源单位”字段，中间库建库时默认使用一个和本二级单位对应的组织编码，具体值详见，在对接口表数据插入或更新时，可不处理此字段。
各接口表中“更新时间”字段，中间库建库时默认使用系统当前时间，在对接口表数据插入或更新时，应保证此字段与业务数据的更新时间一致。
各接口表中的“异构系统主键”字段，要填写二级单位业务系统对应表的业务主键值，方便今后查询或更新数据使用。
各接口表中的数据在进行删除时，都要进行逻辑删除，同时更新“删除标志”字段为1，原默认值为0。接口表中的数据不能进行物理删除。
异常表中提供一个字段“是否已处理”FIsUpdate标识，（默认值为0），供二级单位处理异常数据时参照，处理完该异常数据后可更新为1，避免重复处理。
异常表中的字段“异常原因”供二级单位处理异常数据时参照，校验程序校验不通过时，将原因写入此字段。
3.3接口表的调整及变更处理说明
在项目集成实施和开发的过程中，由于采购信息平台业务需求的变更和新增，将会造成中间库接口表、字典表在个数及表字段上进行变更调整，集团根据系统需求保障中间库接口表、字典表完整性正确性，并做好变更记录。
需求变更信息由集团下发通知给各二级单位，再由二级单位与各自的业务系统软件开发商进行协商处理。