资源描述
前 言
目前《企业信息化技术规范》系列标准由以下6个部分组成:
第1部分:企业资源规划系统(ERP)规范;
第2部分:办公自动化规范;
第3部分:电子交易规范;
第4部分:呼叫中心规范;
第5部分:CRM规范;
第6部分:SCM规范。
本部分由信息产业部电子工业标准化研究所归口。
本部分起草单位:中国生产力促进中心协会、中国电子技术标准化研究所。
本部分主要起草人:
企业信息化技术规范
第1部分:企业资源规划系统(ERP)规范
1 范围
本规范给出了企业资源规划系统(以下简称 ERP)的相关软件功能、开发管理、实施管理的基本要求和方法、适用于企业ERP产品与服务选型工作。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用不着文件,其随后所有修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准确达成协成协议的各方研究是否使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
GB/T 8566-2001 中华人民共和国国家标准 信息技术 软件生存周期过程
GB/T18491-2001 中华人民共和国国家标准 信息技术 软件测量 功能规模测量 第1部分:概念定义
GB/T 18492-2001 中华人民共和国国家标准 信息技术 系统及软件完整性级别
GB/T 18493-2001 中华人民共和国国家标准化指导性技术文件 信息技术 软件生存周期过程指南
SJ 20778-2000 中华人民共和国电子行业军用标准 软件开发与文档编制
企业会计制度财会(2000)25号
3 定义
本标准采用下列定义
3.1 验收 acceptance
需方授权代表一项活动,通过该活动,需方接受履行合同的部分或全部的软件产品的所有权。
3.2 需方 acquirer
为自已或为另一个组织采购软件产品的组织。
3.3 批准approval
需方的授权代表对开发方的项目计划、设计或其他方面表示满意并可能作为一阶段工作基础而签署的书面文件。这种批准并不能解除开发方对满足合同要求的责任。
3.4 体系结构architecture
一个系统或CSCI的组织结构,标明它的组成,这些组成的接口和它们之间的操作概念。
3.5 相关开发方 ASSOCIATE DEVELOPER
一个既不是主承制方也不是开发方的分承制方的组织,但它在同一个或相关的系统或项目承担开发工作。
3.6 行为设计 BEHAVIORAL DESIGN
从用户观点出发,对整个系统或CSCI的行为进行的设计,它只考虑满足用户需求而不考虑系统或CSCI的内部实现。这种设计与体系结构设计不同,后者要标明系统或CSCI的内部部件,并有这些部件的详细设计。
3.7 开发阶段 BUILD
(1) 软件的一个版本,它满足完整的软件所要满足的全部需求的一个特定的子集。
(2) 开发满足特定需求子集的软件版本所经历的时间。
注:术语“开发阶段”和“版本”之间的关系依赖于开发方:例如,可以通过几个版本来实现一个开发阶段,一个开发阶段也可以发行几个并行的版本(如在不同的地点),或者将它们作为同义词。
3.8 计算机数据库 COMPUTER DATEBASE
见数据库
3.9 计算机硬件 COMPUTER HARDWARE
能接收和存储计算机数据的,对计算机数据的,对计算机数据执行一系列系统性的操作的,或能产生控制输出的设备。这类设备能实现基本解释、计算、通信、控制或其他逻辑功能。
3.10 计算机程序 COMPUTER PROGRAM
能使计算机硬件实现计算或控制功能的计算机指令和数据定义的集合。
3.11 计算机软件 CPMPUTER SOFWARE
见软件
3.12 计算机软件配置项 COMPUTER SOFTWARE CONFIGURATION ITEM(CSCI)
满足最终使用功能的软件集合,而且它由需方指定进行单独的配置管理。CSCI应从下列诸因素中进行折衷选择:软件功能、规模、宿主机或目标计算机、开发方、支持概念、重用计划、关键性、接口考虑、需要单独编写文档和控制以及其他因素。
3.13 配置项 CONFIGURATION ITEM
能满足最终使用功能的硬件集合、软件集合或者软、硬件两者的集合,且由需方指令进行单独的配置管理。
3.14 数据库 DATEBASE
以一种能被用户或计算机程序通过一个数据库管理系统进行访问的方式,存储在一个或多个计算机文件中的相关数据的集合。
3.15 数据库管理体系统 DATEBASE MANAGEMENT SYSTEM
是一整套计算机程序,它提供为建立、修改、使用和完整性维护一个数据库所需的功能。
3.16 可交付的软件产品 DELIVERABLE SOFTWARE PRODUCT
合同要求交付给需方或其他指定的接受方的软件产品。
3.17 设计 DESIGN
开发方为响应一定的需求而对一个系统或CSCI选取的一些性能/规格。这些特性中有些是与需求相匹配的;有一些是需求的精细化。如为了响应显示错误信息这一需求而定义所有的错误信息;有一些则是有关的实现,如为满足需求,决定选用哪些软件单元和逻辑。
3. 18 开发方 DEVELOPER
开发软件产品的组织(“开发”包括新的软件开发、合修改、重用、再工程、维护或产生软件产品的任何其他活动)。开发方可以是一个承制方或者政府机构。
3. 19 文档/文当编制 DOCUMENT/DOCUMENTATION
能供人或机器阅读的,一般具有永久性的一套资料(不管它们记录在什么媒体上)。
3.20 评价 EVALUATION
确定一个项目获一项活动是否满足制定准则的过程。
3.21 固件 FIRMWARE
硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和。或计算机数据的组合。
3.22 硬件配置项HARDWARE CONFIGURATION ITEM(HWCL)
满足最终使用功能并由需方指定进行单独配置管理的一套硬件.
3.23 独立验证确认 INDEPENDENT VERIFICATION AND VALIDATION (IV&V)
由一个机构对软件产品和活动所作的系统的评审,这个机构不负责该产品的开发或被评审的活动。IV &V不在本标准的范围内。
3.24 接口 INTERFACE
在软件开发中,两个或多个实体(如CSCI-CSCI,CSCI-HWCI,CSCI-用户,或软件单元软件-软件单元)之间产关系。这些实体依据这种关系共享、提代或交换数据。接口不是CSCI、软件单元或其他的系统部件;接口是这些实体间的一种关系,而不是接口的实现。
3.25 联合评审 JOINT REVIEW
由需方和开发方双方的代表参加的对项目状态、软件产品/或目中的问题进行检查和讨论的活动或会议。
3.26 非交付的软件产品 NON-DELIVERABLE SOFTWARE PRODUCT
不是合同中要求交付给需方或其他指定接受方的软件产品。
3.27 过程 PROCESS
为实现某个既定目的而进行的一组有组织的活动,例如:软件开发过程。
3.28 合格性测试 QUAKIFICATION TESTING
为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。
3.29 再工程 REENGINEERING
为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程式。再工程可包括逆向工程(分析一个系统并产生更高一级的抽象来表示它,如从代码到设计),重构(在同一个抽象级上把系统从一种表示形式转换到另一种表示形式),重编文档(分析一个系统并产生用户文档或支持文档),正向工程(从现有的系统的软件包产品结合新的需求,产生新系统)重定目标系统(对系统进行转换以便将其安装到不同的目标系统上)和翻译(将源码从一种语言转换到另一种语言或者从一种的某个版本转换成另一种版本)。
3.30 需求 REQUIREMENT
(1) 为了使需方能够接受一个系统或CSCI所必需具备的特性。(2)本标准或合同中规定的必须遵守的陈述。
3.31 可重用的软件产品 REUSABLE SOFTWARE PRODUCT
是一种用于开发的软件产品,但还具有别的用途,或者专门为了用于多个项目而开 发的软件产品,或者在一个项目中有多种作用的软件产品。例子包括(但不限于)上市的商品,需方已装备的软件产品,重用库中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分,也可以涉及到它的修改部分。这个术语可以应用于任何软件产品(例如需求,体系结构等)而不只限于软件本身。
3.32 软件 SOFTWARE
计算机程序和计算机数据库。
注:虽然有些软件的定义中包括文档,本标准把这个定义只限于计算机程序和计算机数据库。
3.33 软件开发 SOFTWARE DEVELIPMENT
产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件产品的其他活动。
3.34 软件开发文件 SOFTWARE DEVELOPMENT FILE(SDF)
与特定软件实体开发有关的资料库。其内容一般包括(直接的或引用的)有关需求分析、设计和实现的考虑、原理和约束条件;开发方内部的测试资料;进度和状态资料。
3. 35 软件开发库 SOFEWARE DEVELOPMENT LIBRARY (SDL)
一套受控的软件、文档,其它中间的和最终的软件产品,以及相关的用以促进软件的
有序开发和后续支持的工具和方法。
3. 36 软件开发过程 SOFTWARE DEVELOPMENT PROCESS
为了把用户的需求转换在软件产品而进行的一系列有组织的活动。
3.37 软件工程 SOFTWARE ENGINEERING
一般情况下,它是软件开发的同义词。要本标准中,软件工程是软件开发全部活动(合格性测试除外)的一个子集。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命旬。
3.38 软件工程环境 SOFTWARE ENGINEERING ENVIRONENT
实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于)计算机辅助软件工程(CASE)的工具、编译程序、汇编程序、连接程序、装载程序、排错程序、仿真程序、模拟程序、文档工具和数据库管理系统。
3.39 软件产品 SOFTWARE PRODUCT
为了满足一个合同而建立、修改或组合成的软件或相应的资料。例子包括计划、需求、设计、代码、数据库、测试资料和手册。
3.40 软件质量 SOFTWARE QUALITY
软件满足所规定的需求的能力。
3.41 软件支持 SOFTWARE SUPPORT
为保证软件安装后能继续按既定目标运行而且在系统的运行中能起到既定的作用而发生的一系列活动。软件友持包括软件维护、用户支持和有关的活动。
3.42 软件系统 SOFTWARE SYSTEM
只由软件组成的系统,有时可能还包括该软件赖以运行的计算机设备。
3.43 软件测试环境 SOFTWARE TEST ENVIRONMENT
为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括(但不限于)仿真程序、代码分析程序、测试用例产生程序和路径分析程序,还可能包括在软件工程环境下用到的要素。
3.44 软件移交 SOFTEWARE TRANSITION
能使软件开发的责任从一个组织转交给另一个组织一系列活动。一般说,前一个组织是实现初期软件开发,而后一个组织是进行软件支持。
3.45 软件单元 SOFTWARE UNIT
CSCI设计中的一个基本单位;例如,CSCI的一个主要构成部分,这种构成部分的一个组成部分,一个类,对象,模块,函数,子程序或者数据库。软件单元可以出现在层次机构的不同层上并可以由其他的软件单元组成。设计中的软件单元与实现它们的代码和数据实体(子程序,过程,数据文件等)之间的关系也是这样。
3.46 (软件的)支持 SUPPORT (OF SOFFTWARE)
见软件支持。
3.47 (软件的)移交 TRANSITION (OF SOFTWARE)
见软件移交。
3.48 咨询 CONSULT
通过对客户方业务、经营等各种情况的了解、分析,基于自身的知识和经验,提供合理化建议的一种行为。
3.49 实施 IMPLEMENT
通过一定的手段将一项计划实现的过程,在ERP领域特指将ERP软件经过科学地配置、调整用于客户日常管理的过程。
3. 50 顾问 CONFIGERATION
有相关经验,为客户就行业特色提供咨询服务的人
3. 51 维护 SERVICE
对设备、系统的工作状况进行监视、维修,保证系统的正常运转的工作。
3.52 流程 PROCESS
完成一项工作所要经过的各个步骤,按照一定的先后顺序执行的完整过程
3.53 配置 CONFIGERATION
(1) 硬件配置:根据硬件系统要求,对相关的硬件进行规格搭配
(2) 软件配置:根据软件系统运行要求,对软件参数进行设
3. 54 数据 DATA
在流程中处理的各种信息对象,数据可以有多种存储方式
3.55 上线 go-life
让设备或者是软件系统正式运行
3.56 选型 MAKE CHOICE
根据实际业务管理的需要,对硬件、软件进行规格选择
3.57 模块 MODULE
按照业务功能划分的各个子业务系统,如销售、采购、仓库等子业务
3.58 BOM
产品结构的英文缩写,又称为物料清单,是对产品生产所需的材料、工序进行描述的一种文件记
3.59 MRP
物料需求计划的英文缩写,是企业根据生产、销售、采购、预测等需求对物料进行的一种规划
4 总则
围绕ERP产品应该包含以下要素:
底层设计高度集成化,各类数据、计算、共享高度统一,不同于单类应用的简单连接
产品采用先进和稳定的IT开发平台,系统稳定、安全、灵活、可扩充耳不
在各种行业有丰富的实用案例
软件提供者本身的业务保持持续健康的发展,保证产品持续发展,服务持续提供
符合相关制度和法规,适合企业管理和人文文化特点。
为满足以上各项要素,必须在产品研发、实施、服务、产品功能各方面建立相关的标准工作方法和内容。
5 ERP产品研发技术要求
产品研发是非常严谨、科学的一系列工作的组织,整个体系应具有完整、灵活、严谨、高效的特性,进行严格的管理控制,以确保产品的质量和市场反应的速度,保证工作的延续性,保证各类产品问题的可追溯性,尤其是各类过程控制文档与记录的保存。以下为产品研发最基本流程的框架描述,过程中的文档模版未提供,可根据需要由各公司自行自行设计确定。下面将以流程图的方式阐述主要工伯的过程,并分别配有表格形式的说明。
5.1 术语和定义:
单位:在公司组织架构中独立的实体,由工作内容划分为面向销售或面向技术的相关组织。
事业群:以产品划分,主要面向明确的产品和用户群的确良公司见风使舵组织架构,对该产品的营销全面责任。
事业单位:事业群中的某个单位。
5.2 研发循环总流程图
质量文件管理作业程序
新产品规划提案作业程序
新产品开发作业程序
设计变更作业程序
产品功能异常处理作业程序
5.3 新产品规划提案作业程序
各单位 事业群 总裁室
开 始
新产品规划提案表
新产品规划提案表
审查
修订/退件
审查
评估报告
修订
评估报告
审查
审核
评估报告
新产品开发作业程序
新产品提案作业程序
作 业 系 统 及 控 制 重 点
依据资料及流程图中各项窗体
一、 目的
为标准化及落实新产品规划过程的所有程序、文件及记录,特定本程序。
二、 权力与责任
本作业程序由研发部门负责维护,经总裁审核批准后勤部实施,其修订亦同。
三、 作业程序
1、 新产品规划提案
公司人员对新产品有新构思或提案,可填写[新产品规划提案表],由提案单位主管审查后转呈事业群负责人及总裁室审查及批准。
2、 总裁室审查批准的[新产品规划提案表]应由事业群负责人委任适当人员进行新产品开 发的评估。
3、 新产品开发评估完成后,应撰之一评估报告,评估报告内容含日程,成本及人力规划。评估报告经事业群负责人审查后交总裁室批准。
4、 决议开发的提案,由事业群负责人成立开发项目依[新产品开发作业程序]进行产品开发;决议不开发者,评估报告应归档妥善保存。
四、 控制重点
1、 新产品规划提案表是否经过适当的管理。
2、 新产品的开发是否可追溯[新产品规划提案表]
3、 新产品的形式发是否具备开发评估报告。
4、 新产品评估相关报告及记录是否经适当的保存。
新产品规划提案表
新产品开发作业程序
5.4 新产品开发案作业程序
事业单位 项目小组 销售及服务单位
成立项目小组
开 始
进行项目控制
制定各项标准
系统分析
修订
审查
N
Y
系统设计
修订
N
审查
Y
程序设计
测试
■ 新产品开发作业程序
作 业 系 统 及 控 制 重 点
依据资料及各项窗体
一、 目的
为落实新产品及子系统在开发过程中的所有程序,文件及记录标准化。特定本程序。
二、 权力与责任
本作业程序由研发部门负责维护,经总裁审查批准后实施,其修麻亦同。
三、 作业程序
1. 新产品开发应成立项目小组,决定项目负责人及组织分工,由项目负责人负责项目控制,协调及程序管理。
2.若新产品开发工作决定委托公司外部资源进行是,应由项目小组拟 定[外包契约],经总裁室审查批准。由项目负责人监控
3.新产品使用新技术前应经过适当的评估。
4.新产品开发过程使用各项标准应经过适当的规划及测试。
5.系统分析
产品开发应具备系统分析文件,系统分析文件撰写完成后,应经过适当审查,审查结果应保留记录。
6. 系统设计
系统分析完成后,进入系统设计阶段,系统设计文件撰写成后,应经过适当审查,审查应保留记录。
7. 程序设计
程序人员,根据系统设计文件及各种标准撰写程序。
8. 产品测试
产品开发完成应经过严谨测试,以确保产品质量,测试应保留测试记录。
9. 产品开发执行过程的版本及开发环境应适当管理。
10.开发过程的开发文件保管及管理依[质量文件管理作业程序]所规范的内容执行。
外包契约
质量文件管理作业程序
四、 控制重点
1. 开发中项目是否定期监控进度及预算执行。
2. 产品开发中使用的各项标准是否经过适当管理。
3. 系统分析是否经过适当审查。
4. 系统设计是否经过适当审查。
5. 软件开发的产品识别方式是否明确制订。
6. 是否保留开发记录,证明产品开发的著作所有权。
7. 产品开发完成,是否具备测试记录,以验证产品质量。
8. 开发过程的文件及记录是否依据质量文件管理办法妥善的保存及管理。
依据资料及流程图中各项窗体
5..5设计变更作业程序
变更需用求单位 项目小组/产品维护单位
产品提交
械 我
会议记录或建议信息
程序修改与测试
审 查
修订
项目管理
规格变更
项目控制
审 核
修订/退件
会议记录或建议信息
开 始
■设计变更作业程序
作业系统及控制重点
依据资料及流程图中各项窗体
一、 目的
为落实新产品在开发过程及产品维护阶段的设计变更管理与控制,特制定本程序。
二、 权力与责任
本作业程序由研发部门负责维护,经总裁审查批准后实施,其修订亦同。
三、 作业程序
1、 产品开发过程的设计变更,可则设计单位或业务或服务单位于相关项目会议中提出变更需求,经项目负责人审查批准确性后,进行设计变更。
2、 产品维护阶段发生设计变更需求时,应由需求单位提出系统功能建议,经产品维护单位主管审查或经产品相关会议审查批准决议后,交由产品维护人员进行产品功能修改。
3、 变理幅度较大时,由产品维护单位的负责人视项止规模判断是否需要成产项目进行项目控制。
4、 设计变更应规划可识别的版号,以作为产品质量及功能的追溯。
5、 设计变更完成的产品应经过适当的测试验,以验证产品的质量及功能的完整性
6、 产品变更文件依[质量文件管理作业程序]所规范的内容执行。
四、 控制重点
1、 设计变更是否经过适当的审查。
2、 设计变更完成,是否经过适当的测试。
3、 开发过程的文件及记录是否依据质量文件管理办法妥善的保存及管理。
质量文件管理作业程序
3.1 产品功能异常处理作业程序
发起单位 产品维护单位
开 始
产品功能异常信息
验证错误
程序修改与测试
程序更新
产品功能异常信息
产品更新
■ 产品功能异常处理作业程序
作业系统及控制重点
依据资料及流程图中各项窗体
一、 目的
确保产品程序异常处理的质量及提出供有效的产品服务特制定本程序。
二、 权力与责任
本作业程序由研发部门负责维护,经总裁审查批准后实施,其修订亦同。
三、 作业程序
1、 异常的提出
销售、服务单位或产品维护单位于产品或维护过程是发现功能异常时,应提出产品功能异常反应,将异常信息或描述以FAX或MAIL邮件通知产品维护单位处理。
2、 程序修改完成,应经适当测试。
3、产品维护单位应建立维护记录,便于是 产品追溯及信息查询。
四、 控制重点
1、 产品功能异常反应是否经过适当的处理。
2、 异常程序修改完成是否进行适当测试。
3、 程序修改是否保存修改记录。
3.2 质量文件管理作业程序
文件需求单位 文件管理与控制单位
开 始
文件公布
文件质量收发录表
业务联系单
文件资料查收
文件质量收发录表
退 回
审 核
业务联系单
特殊文件需求
■质量文件管理作业程序
作 业 系 统 及 控 制 重 点
依据资料及流程图中各项窗体
一、 目的
为使本公司的文件管理与控制能落实执行,制定文件的建立、发行、变更及保密与安全的程序,以有效管理各项质量文件,特定本程序。
二、 权责
本作业程序由研发部门负责维护,经总裁审查批准后实施,其修订亦同。
三、 管理内容
1. 开发阶段所完成的各项技术资料及质量记录、产品功能建议单、产品功能异常单及会议记录等资料,应视资料储存特性由项目负责人或产品维护负责人定义储存资料方式,并妥善保存。
2. 为了让全体员工充分分享现有信息,项目小组及产品维护单位可将分享统一公布。
3. 非分享的记录或资料,若属技术机密文件者,发生调阅需求时,应由需求单位填写[业务联系单],并由资料保管单位主管授权批准,才能取得资料。资料若有归还的必要性,则保管单位应登录于[质量文件收发登录表]中进行追踪管理。
4. 资料文件归还时,应于[质在文件收发登录表]做出记录。
四、 控制重点
1. 产品文件是否定义储存方式,并根据储存方式落实执行。
2. 是否设置文件管理与控制人员,负责质量文件的管理。
3. 属于技术机密文件的申请是否具备申请记录,申请是否具备适当审核。
4. 管理与控制文件的收发是否登于[质量文件收发登录表]中。
业务联系单
质量文件收发登录表
6ERP产品服务技术要求
6.1基本组织架构
应至少建立独立的“ERP服务部“,区别于产品研发部门
6.2基本人员组成
工程师、顾问、服务专员、系统分析师、程序员
6.3各项工作概述
服务名称
适用阶段
服务提供者
服务对象
服务内容及目的说明
系统集成与安装
实施阶段
ERP服务部工程师
用户信息部门技术工程师
将ERP安装至用户的服务器里,并调试网络及周边设备等,以确保软件能够正常在用户的整体环境中顺利执行
教育培训
实施阶段维护阶段
ERP服务部顾问
用户使用部门信息部门人员
通过事先设计好的教材及步骤,让学员了解ERP的标准功能及操作方式,以便学员学成之后能够顺利操作系统并有助于系统实施工作的执行
系统实施
实施阶段
ERP服务部顾问
用户使用部门信息部门人员
通过事先设计好的实施辅导流程及信息工具的协助,以科学的、有系统的方法,按照计划使用户可以顺利将ERP导入在企业内使用
热线服务
维护服务阶段
ERP服务部服务人员
用户使用部门信息部门人员
以训训练有素的服务人员,接受用户对于软件使用方面的种种询问,为用户解答问题,提供指导,以确保ERP在用户处可以顺利使用
二次开发
实施阶段维护阶段
ERP服务部系统分析师、程序员
用户使用部门信息部门人员
因用户企业本身的特殊情况导致标准软件功能无法满足需求时,由专门的技术人员与用户讨论并确定其需求的内容,将需求转化为程序规格后,拟定出适合该用户使用的个性化程序,以弥补标准软件无法满足用户的情况
线上诊断
维护阶段
ERP服务部工程师、服务人员
用户信息部门技术人员
通过调制解调器及遥控软件,以在线方式为用户软件运行环境进行必要的检查,以判断异常发生的原因后,采取必要的措施为用户排除软件使用上的各种疑难问题,使ERP能在用户处顺利运行
服务名称
适用阶段
服务提供者
服务对象
服务内容及目的说明
版本更新
维护阶段
ERP服务部服务人员、ERP产品研发中心
用户信息部门技术人员
因法令的修改,经营环境的变化或软件技术的进步所导致的ERP软件在功能及技术上无法满足用户的需求,由产品研发部门针对用户的需求,事先研究开发出新版本的软件,然后再为用户更新软件,使用用户处的ERP维持最新的状态,确保ERP在用户处顺利运行
技术培训
维护阶段
ERP服务部系统分析师、程序员
用户信息部门技术人员
针对规模较大,购买ERP程序源代码及开发技术培训课程的用户,针对其信息部门的技术人员,提供经过设计的完整培训课程,使得用户的技术人员也拥有ERP系统的技术能力,以便就近为用户提供各种服务,使得ERP在用户处能更顺利的运行
6.4 各种工作具体评估准则
为保证产品上线成功,并持续稳定运行无误,必须建立相关的服务保障机制,必须有明确的流程规范,并有明确的责任人进行有效的执行,并保持必要的有效记录。其内容与评估范围大致如下:
6.4.1 安装集成服务:针对客户所购买的软硬件加以集成,以保障客户软硬件能顺利运作,以提高运作效能。
□ 是否提供安装集成服务
□ 软硬件安装集成前是否提供规划建议与报告
□ 请提供集成前的规划建议纪录
□ 软硬件安装集成后是否提供完成报告,并取得客户确认
□ 请提供集成后完成报告纪录
□ 请提供软硬件安装集成服务的操作规范
6.4.2 顾问实施服务:针对客户的ERP项目能进行规划,主导推动、进度监控与阶段报告反馈,并且在项目进行中进行工作协调、组织分工与专业的编码建议、流程规划、与软件运作规划,以保障客户ERP项目顺利上线运行,以达到项目目标致。
□ 是否提供顾问实施服务
□ 派任实施顾问的专业资历:
□ 派任实施顾问主导实施的客户数:
□ 实施过程中是否提供数据搜集的文档模板,请提供文档模板样张
□ 实施过程中是否提供标准流程的文档模板,请提供文档模板样张
□ 是否在实施的重要步骤中规范产出文件,请提供产出文件纪录
□ 在实施过程中是否详实记载实施纪录与会议记录,并取得客户确认,请提出相关纪录
□ 是否提供实施结项报告,请提相关报告
□ 实施步骤是否有明确的工作规范,请提供实施的操作规范
6.4.3 模块功能培训:针对ERP各模块的功能说明、操作培训、使用时机、管理目的与导入程序,便于用户能深入了解每个模块的详细功能与熟练操作。
□ 是否提供例行的功能培训
□ 同一模块开课周期
□ 是否提供培训成果的考核
□ 请提供培训服务的操作规范
6.4.4产品升级服务:软件供应商推出新版本时,能针对客户使用的旧版本予以软件升级服务,以便于客户能使用更先进的功能,或符合新的相关法令。
□ 是否提供产品升级服务
□ 产品升级服务的收费方式:
□ 产品升级前是否针对客户说明差异的部分,以便客户使用更先进的功能,请提供产品升级相关文件
□ 产品升级是否能保障客户原始的数据能不被破坏,且能适合新版本的功能
□ 请提供产品升级服务的操作规范
6.4.5 二次开发服务:对于客户的业务流程或行业特性,在标准ERP模块无法满足时,针对差异的部分进行二次开发,让ERP更贴近客户需求,并满足其行业特性。
□ 是否提供二次开发服务
□ 二次开发服务的收费方式:
□ 二次开发前是否针对功能差异进行分析,请提供差异
展开阅读全文