企业信息化技术规范-企业资源规划系统(erp)规范.doc

企业信息化技术规范

第1部分：企业资源规划系统（ERP）规范

目次

前言................................................................................ III 1范围. (1)

2术语和定义 (1)

3总则 (5)

4ERP产品研发技术要求 (6)

4.1研发循环总流程 (7)

4.2新产品规划提案作业程序 (8)

4.3新产品开发作业程序 (10)

4.4设计变更作业程序 (13)

4.5产品功能异常处理作业程序 (15)

4.6质量文件管理作业程序 (17)

5ERP产品服务技术要求 (19)

5.1基本组织架构 (19)

5.2基本人员组成 (19)

5.3各项工作概述 (19)

5.4各项工作具体评估准则 (21)

6 ERP产品功能技术要求 (24)

6.1总体说明 (24)

6.2环境与用户界面 (26)

6.3系统整合 (30)

6.4系统管理 (34)

6.5基本信息 (37)

6.6库存 (39)

6.7采购 (45)

6.8营销 (51)

6.9产品明细表BOM (62)

6.10车间任务管理 (64)

6.11工艺 (67)

6.12物料需求计划MRP (70)

6.13成本 (74)

6.14人力资源 (80)

6.15质量保证 (94)

6.16经营决策 (97)

6.17总帐 (103)

6.18自动分录 (108)

6.19应收 (110)

6.20应付 (112)

6.21固定资产 (115)

参考文献 (117)

前言

《企业信息化技术规范》系列标准目前由以下部分组成：

——第1部分：企业资源规划系统（ERP）规范；

——第2部分：产品数据管理系统（PDM）规范；

——第3部分：客户关系管理系统（CRM）规范；

——第4部分：协同产品商务系统（CPC）规范；

——第5部分：供应链管理系统（SCM）规范；

——第6部分：办公自动化系统（OA）规范；

——第7部分：企业信息化监理规范；

…………

本部分为第１部分。

本部分由中国电子技术标准化研究所（CESI）归口。

本部分起草单位：中国生产力促进中心协会、中国电子技术标准化研究所。本部分主要起草人：

本部分主要参与起草单位：

企业信息化技术规范

第1部分：企业资源规划系统（ERP）规范

1范围

本标准给出了企业资源规划系统（以下简称ERP）的相关软件功能、开发管理、实施管理的基本要求和方法，本标准适用于企业ERP产品与服务选型工作。

2术语和定义

下列定义适用于本标准。

2.1

验收acceptance

需方授权代表的一项活动，通过该活动，需方接受履行合同的部分或全部的软件产品的所有权。2.2

需方 acquirer

为自己或为另一个组织采购软件产品的组织。

2.3

批准 approval

需方的授权代表对开发方的项目计划、设计或其他方面表示满意并可能作为下一阶段工作基础而签署的书面文件。这种批准并不能解除开发方对满足合同要求的责任。

2.4

体系结构 architecture

一个系统或CSCI的组织结构，标明它的组成，这些组成的接口和它们之间的操作概念。

2.5

开发阶段 build

1）软件的一个版本，它满足完整的软件所要满足的全部需求的一个特定的子集。

2）开发满足特定需求子集的软件版本所经历的时间。

注：术语“开发阶段”和“版本”之间的关系依赖于开发方；例如，可以通过几个版本来实现一个开发阶段，一个开发阶段也可以发行几个并行的版本（如在不同的地点），或者将它们用作为同义词。

2.6

计算机数据库 computer database

见数据库。

2.7

计算机硬件 computer hardware

能接收和存储计算机数据的，对计算机数据执行一系列系统性的操作的，或能产生控制输出的设备。这类设备能实现基本的解释、计算、通信、控制或其他逻辑功能。

2.8

计算机程序 computer program

能使计算机硬件实现计算或控制功能的计算机指令和数据定义的集合。

2.9

数据库 database

以一种能被用户或计算机程序通过一个数据库管理系统进行访问的方式，存储在一个或多个计算机文件中的相关数据的集合。

2.10

数据库管理系统 database management system

是一整套计算机程序，它提供为建立、修改、使用和完整性维护一个数据库所需的功能。

2.11

设计 design

开发方为响应一定的需求而对一个系统或CSCI选取的一些性能/规格。这些特性中有些是与需求相匹配的；有一些是需求的精细化。如为了响应显示错误信息这一需求而定义所有的错误信息；有一些则是有关的实现，如为满足需求，决定选用哪些软件单元和逻辑。

2.12

开发方 developer

开发软件产品的组织（“开发”包括新的软件开发、修改、重用、再工程、维护或产生软件产品的任何其他活动）。开发方可以是一个承制方或者政府机构。

2.13

文档/文档编制 document/documentation

能供人或机器阅读的，一般具有永久性的一套资料（不管它们记录在什么媒体上）。

2.14

评价 evaluation

确定一个项目或一项活动是否满足制定准则的过程。

2.15

固件 firmware

硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和/或计算机数据的组合。

2.16

接口 interface

在软件开发中，两个或多个实体（如CSCI-CSCI,CSCI-HWCI,CSCI-用户，或软件单元-软件单元）之间的关系。这些实体依据这种关系共享、提供或交换数据。接口不是CSCI、软件单元或其他的系统部件；接口是这些实体间的一种关系，而不是接口的实现。

2.17

过程 process

为实现某个既定目的而进行的一组有组织的活动，例如，软件开发过程。

2.18

合格性测试 qualification testing

为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。

2.19

再工程 reengineering

为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程（分析一个系统并产生更高一级的抽象来表示它，如从代码到设计），重构（在同一个抽象级上把系统从一种表示形式转换到另一种表示形式），重编文档（分析一个系统并产生用户文档或支持文档），正向工程（从现有的系统的软件产品结合新的需求，产生新系统），重定目标系统（对系统进行转换以便将其安装到不同的目标系统上）和翻译（将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本）。

2.20

需求 requirement

1）了使需方能够接受一个系统或CSCI所必需具备的特性。

2）标准或合同中规定的必须遵守的陈述。

2.21

软件 software

计算机程序和计算机数据库。

注：虽然有些软件的定义中包括文档，本标准把这个定义只限于计算机程序和计算机数据库。

2.22

软件开发 software development

产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件产品的其他活动。

2.23

软件开发过程 software development process

为了把用户的需求转换成软件产品而进行的一系列有组织的活动。

2.24

软件工程 software engineering

一般情况下，它是软件开发的同义词。在本标准中，软件工程是软件开发全部活动（合格性测试除外）的一个子集。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名。

2.25

软件工程环境 software engineering environment

实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括（但不限于）计算机辅助软件工程的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序、文档工具和数据库管理系统。

2.26

软件产品 software product

为了满足一个合同而建立、修改或组合成的软件或相应的资料。例子包括计划、需求、设计、代码、数据库、测试资料和手册。

2.27

软件质量 software quality

软件满足所规定的需求的能力。

2.28

软件系统 software system

只由软件组成的系统，有时可能还包括该软件赖以运行的计算机设备。

2.29

软件测试环境 software test environment

为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括（但不限于）仿真程序、代码分析程序、测试用例产生程序和路径分析程序，还可能包括在软件工程环境下用到的要素。

2.30

软件单元 software unit

CSCI设计中的一个基本单位；例如，CSCI的一个主要构成部分，这种构成部分的一个组成部分、一个类、对象、模块、函数、子程序或者数据库。软件单元可以出现在层次机构的不同层上并可以由其他的软件单元组成。设计中的软件单元与实现它们的代码和数据实体（子程序、过程、数据库、数据文

件等）之间有也可以没有一一对应的关系，或包含这些实体的计算机文件之间的关系也是这样。

2.31

咨询 consult

通过对客户方业务、经营等各种情况的了解、分析，基于自身的知识和经验，提供合理化建议的一种行为。

2.32

实施 implement

通过一定的手段将一项计划实现的过程，在ERP领域特指将ERP软件经过科学地配置、调整用于

客户日常管理的过程。

2.33

顾问 consultant

有相关经验，为客户就行业特色提供咨询服务的人。

2.34

维护 service

对设备、系统的工作状况进行监视、维修，保证系统的正常运转的工作。

2.35

流程 process

完成一项工作所要经过的各个步骤，按照一定的先后顺序执行的完整过程。

2.36

配置 configueration

1）硬件配置：根据硬件系统要求，对相关的硬件进行规格搭配。

2）软件配置：根据软件系统运行要求，对软件参数进行设置。

2.37

数据 data

在流程中处理的各种信息对象，数据可以有多种存储方式。

2.38

上线 go-life

让设备或者是软件系统正式运行。

2.39

选型 make choice

根据实际业务管理的需要，对硬件、软件进行规格选择。

2.40

模块 module

按照业务功能划分的各个子业务系统，如销售、采购、仓库等子业务。

2.41

产品明细表 BOM

产品结构的英文缩写，又称为物料清单，是对产品生产所需的材料、工序进行描述的一种结构性件。

2.42

物料需求计划 MRP

物料需求计划的英文缩写，是企业根据生产、销售、采购、预测等需求对物料进行的一种计划。

3总则

ERP产品设计遵从以下原则：

——底层设计高度集成化，各类数据、计算、共享高度统一，不同于单类应用的简单连接；

——产品采用先进和稳定的IT开发平台，系统稳定、安全、灵活、可扩充；

——在各种行业有丰富的实用案例；

——软件提供者本身的业务保持持续健康的发展，保证产品持续发展，服务持续提供；

——符合相关制度和法规，适合企业管理和人文文化特点。

为达到以上各项原则，应在产品研发、实施、服务、产品功能各方面建立相关的标准工作方法和内容。

4ERP产品研发技术要求

产品研发是非常严谨、科学的一系列工作的组织，整个体系应具有完整、灵活、严谨、高效的特性，进行严格的管理控制，以确保产品的质量和市场反应的速度，保证工作的延续性，保证各类产品问题的可追溯性，尤其是各类过程控制文档与记录的保存。以下为产品研发最基本流程的框架描述，过程中的文档摸版未提供，可根据需要由各公司自行设计确定。下面将以流程图的方式阐述主要工作的过程，并分别配有表格形式的说明。

4.1 研发循环总流程

研发循环总流程见图1。

新产品规划提案作业程序

新产品开发作业程序

质量文件管理作业程序

设计变更作业程序

产品功能异常处理作业程序

图1

4.2 新产品规划提案作业程序

a) 新产品规划提案作业程序见图2;

各单位 事业部 总裁室

图2

开 始 审查 Y N 修订/退件

新产品规划提案表

评估报告

审查

N Y 审核

Y Y

审查 新产品规划提案表

N 评估报告

新产品立项任

务书 新产品开发作业程序

b) 新产品规划提案作业程序解释见表１。

表１

作业系统及控制重点依据资料及流程图中各项窗体

１目的

为标准化及落实新产品规划过程的所有程序、文件及记录，特定本程序。

２权力与责任

本作业程序由研发部门负责维护，经总裁审核批准后后实施，其修订亦同。

３作业程序

a) 新产品规划提案

公司人员对新产品有新构思或提案，可填写「新产品规划提案表」，由提案单位主管审查后转呈事业部负责人及总裁室审查及批准。

b)总裁室审查批准的「新产品规划提案表」应由事业部负责人委任适当人员进行新产品开发的评估。

c)新产品开发评估完成后，应撰写评估报告，评估报告内容含日程、成本及人力规划。评估报告经事业部负责人审查后交总裁室批准。

d)决议开发的提案，由事业部负责人成立开发项目依『新产品开发作业程序』进行产品开发；决议不开发者，评估报告应归档妥善保存。

4 控制重点

a) 新产品规划提案表是否经过适当的管理。

b) 新产品的开发是否可追溯「新产品规划提案表」。

c) 新产品的开发是否具备开发评估报告。

d) 新产品评估相关报告及记录是否经适当的保存。新产品规划提案表新产品开发作业程序

4.3 新产品开发作业程序

a) 新产品开发作业程序见图3；

事业单位 项目小组 销售及服务单位 图3

开 始

成立项目小组

系统分析

审查

系统设计

审查

程序编码

制定各项标准

Y

N

N

Y

修订

修订

测试

进行项目控制

产品发表

b) 新产品开发作业程序解释见表２。

表２

作业系统及控制重点依据资料及各项窗体１目的

为落实新产品及子系统在开发过程中的所有程序、文件及记录标准化,

特定本程序。

２权力与责任

本作业程序由研发部门负责维护，经总裁审查批准后实施，其修订亦同。

３作业程序

a) 新产品开发应成立项目小组，决定项目负责人及组织分工，由项目

负责人负责项目控制、协调及程序管理。

b) 若新产品开发工作决定委托公司外部资源进行时，应由项目小组拟定「外包合同」，经总裁室审查批准，由项目负责人监控。

c) 新产品使用新技术前应经过适当的评估。

d) 新产品开发过程使用各项标准应经过适当的规划及测试。

e)系统分析

产品开发应具备系统分析文件，系统分析文件撰写完成后，应经过适当审查，审查结果应保留记录。

f)系统设计

系统分析完成后，进入系统设计阶段，系统设计文件撰写完成后,应经过适当审查，审查应保留记录。

g)程序设计

程序人员，根据系统设计文件及各种标准撰写程序。

h)产品测试

产品开发完成应经过严谨测试，以确保产品质量，测试应保留测试

记录。

i)产品开发执行过程的版本及开发环境应适当管理。

j)开发过程的开发文件保管及管理依『质量文件管理作业程序』所规范的内容执行。外包合同

质量文件管理作业程序

作业系统及控制重点依据资料及流程图中各项窗体

４控制重点

a) 开发中项目是否定期监控进度及预算执行。

b) 产品开发中使用的各项标准是否经过适当管理。

c) 系统分析是否经过适当审查。

d) 系统设计是否经过适当审查。

e) 软件开发的产品识别方式是否明确制订。

f) 是否保留开发记录，证明产品开发的著作所有权。

g) 产品开发完成，是否具备测试记录，以验证产品质量。

h) 开发过程的文件及记录是否依据质量文件管理办法妥善的保存及管理。

4.4 设计变更作业程序

a) 设计变更作业程序见图4；

变更需求单位 项目小组/产品维护单位

图4

Y 开 始 规格变更 审核

程序修改与测试 修订/退件 Y N N

会议记录或建议信息

审查 修订 项目控制

Y

Y

N

项目管理

会议记录或建议信息 产品提交

b) 设计变更作业程序解释见表３。

作业系统及控制重点依据资料及流程图中各项

窗体

１目的

为落实新产品在开发过程及产品维护阶段的设计变更管理与控制，特

制定本程序。

２权力与责任

本作业程序由研发部门负责维护，经总裁审查批准后实施，其修订亦

同。

３作业程序

a) 产品开发过程的设计变更，可由设计单位或业务或服务单位于相关

项目会议中提出变更需求，经项目负责人审查批准后，进行设计变更。

b) 产品维护阶段发生设计变更需求时，应由需求单位提出系统功能建

议，经产品维护单位主管审查或经产品相关会议审查批准决议后，交由产品维

护人员进行产品功能修订。

c) 变更幅度较大时，由产品维护单位的负责人视项目规模判断是否需

要成立项目进行项目控制。

d) 设计变更应规划可识别的版号，以作为产品质量及功能的追溯。

e) 设计变更完成后的产品应经过适当的测试，以验证产品的质量及功

能的完整性。

f) 产品变更文件依『质量文件管理作业程序』所规范的内容执行。

４控制重点

a) 设计变更是否经过适当的审查。

b) 设计变更完成，是否经过适当的测试。

c) 开发过程的文件及记录是否依据质量文件管理办法妥善的保存及管

理。

质量文件管理作业程序

4.5 产品功能异常处理作业程序

a) 产品功能异常处理作业程序见图5；

发起单位 产品维护单位

图5

开 始 程序修改与测试 验证错误 产品功能异常信息

程序更新 产品功能异常

信息

修改文档

产品更新

b) 产品功能异常处理作业程序解释见表４。

表４

作业系统及控制重点依据资料及流程图中各项

窗体

１目的

确保产品程序异常处理的质量及提供有效的产品服务特定本程序。

２权力与责任

本作业程序由研发部门负责维护，经总裁审查批准后实施，其修订亦同。

３作业程序

a) 异常的提出

销售、服务单位或产品维护单位于产品服务或维护过程中发现功能异常时，应提出产品功能异常反应，将异常信息或描述以FAX或MAIL邮件通知产品维护单位处理。

b) 程序修改完成，应经适当测试。

c) 产品维护单位应建立程序维护记录，便于产品追溯及信息的查询。

４控制重点

a) 产品功能异常反应是否经过适当的处理。

b) 异常程序修改完成是否进行适当测试。

c) 程序修改是否保存修改记录。

4.6 质量文件管理作业程序

a) 质量文件管理作业程序见图6；

文件需求单位 文件管理与控制单位

图6

Y 开 始

文 件 公 布 特殊文件需求

业务联系单

审核 文件质量收发

登录表 文件资料查收

业务联系单

文件质量收发登录表

N 退 回