技术变更流程范例6篇

前言:中文期刊网精心挑选了技术变更流程范文供你参考和学习,希望我们的参考范文能激发你的文章创作灵感,欢迎阅读。

技术变更流程

技术变更流程范文1

关键词:载人航天器;软件需求;变更控制;改进流程

中图分类号:TP301文献标识码:A文章编号:1672-7800(2013)006-0023-03

作者简介:李皖玲(1980-),女,硕士,中国空间技术研究院载人航天总体部工程师,研究方向为载人航天器信息系统。

0引言

软件需求在软件产品的整个生存期中占有重要位置,是软件工程项目的依据和出发点,无论是软件开发还是软件维护,都是以满足软件需求为最终目的[1,2]。

在实际工程研制中,用户需求变更的现象不可避免。美国Standish Group 公司对8 400个软件项目的调查和研究指出3种最经常使项目遇到困难的因素,其中,不断改变的需求和规格说明占所有项目的12%[3]。同时,ESPITI机构根据3 800个调查人的回答,管理(更改)需求是被调查者回答的软件研制过程中最难解决的两个最大问题之一[4,5]。以航天某型号的某个子系统为例,共有软件配置项14个,全生命周期共发生需求变更34次,涉及软件11个,占到软件总数的78.6%,发生过4次及4次以上需求变更的软件有4个,占到软件总数的28.5%。

如何及时、有效地控制软件需求变更问题,已成为软件工程化管理不可回避的课题。如果不能对需求变更进行及时有效的控制管理,很可能对整个软件项目造成“牵一发而动全身”的影响[6]。

1需求变更原因及管理现状

1.1需求变更原因

载人航天器软件工程化的一项重要工作是对变更进行控制,以将变更对工作量、工期和质量的影响降低到最小。根据型号研制工作经验,造成需求变更的原因可总结为以下方面:

(1)系统复杂导致需求理解不完整、不明确。载人航天器研制是个庞大的系统工程,由13个分系统构成,一个系统级功能及任务需层层分解至某个软件或某几个软件来实现,带来软件内部、软件与软件之间信息流设计复杂、信息交互频繁。系统需求的复杂性,带来了对软件需求理解的不确定性及不完险。

载人航天器软件需求分析需经过系统级、分系统级、配置项级三级开展,在需求分析阶段,若系统级或分系统级未对软件需求进行深入论证、分析,软件研制人员也未重视分系统级及系统级人员的参与,导致需求分析工作各自独立,没有设计出良好的软件结构适应变化,造成后期频繁的需求变更。

(2)工程周期长导致需求不断加以完善。载人航天器的软件研制需经历初样、正样阶段,一般研制周期为2~3

年。在初样阶段,建立初步的软件功能基线后,开发工作即开始启动。随着软件研制工作的深入,分系统会提出新的需求。同时,载人航天器系统与子系统按照同一节点进行开发,即使建立的功能基线是无遗漏的、明确的,但随着工程深入,其中的某个子系统发生任务变更,由此带来该子系统软件或其相关软件需求发生变化。

(3)软件需求本身特点。软件需求作为整个软件项目的最关键的一个输入,同硬件产品不同,具有模糊性、不确定性、变化性和主观性等特点,它的自身特点就决定了变化的可能[5]。

1.2需求变更管理存在的问题

载人航天器软件工程化的需求管理方法经过近10年的运行和实践,确保了多艘航天器软件安全、稳定运行,详细流程见图1所示。但目前需求变更控制流程仍然存在待改进地方,主要体现在以下方面:

(1)需求变更控制方式单一。载人航天器软件工程化对需求变更的控制方式单一的主要表现,其一是未区分软件研制不同阶段需求变更的处理流程,对需求变更控制和管理均是按照图1所示的流程进行,实际上,初样和正样阶段的需求变更,对计划和质量的影响是完全不同的;其二是对所有的需求变更一视同仁,未区分关键性需求和改进性需求,致使需求变更频繁发生,导致工作量和资源投入的不理性增加。

(2)变更影响域分析滞后。对于分系统提出的变更,多是从技术的角度出发,经过系统级、分系统两级论证通过后,以技术要求方式下达。一旦软件研制单位接收到技术要求,按照软件工程化要求进行软件变更及影响域分析时,发现由于此次需求变更对软件架构和研制进度带来较大影响,并引入了质量风险,也只能按照影响域分析结果进行变更。

2需求变更管理流程改进

设计一个清晰的、明确的、可控的、有效管理的需求变更工作流程,有利于促进软件开发过程中的人员分工和合作;有利于对需求变更的处理阶段进行实时监控和跟踪[7]。

需求变更控制改进后流程见图2所示。

2.1变更申请

软件需求变更申请可由需求方(分系统级)提出,也可由开发方(软件研制方)提出。

提出的软件需求变更由开发方归入“需求变更池”进行管理,“需求变更池”由需求变更时间、需求变更定义、变更原因、提出变更人等信息组成。

根据软件研制特点和软件进展阶段,需求方定义需求变更周期,每一个需求变更周期对“需求变更池”的需求进行统一处理。如在初样尚未进入编码阶段,需求变更周期定义为两周,若在初样已完成编码阶段,需求变更周期定义为一个月,在正样阶段,将“需求变更池”的处理周期定义为事件驱动。在每一个需求变更周期内,需求方将与开发方一同,对“需求变更池”内的需求处理一次。

采取“需求变更池”管理的好处是将需求变更流程变为周期性,既能确保所有需求申请都能够得到及时处理并经历正规的需求管理流程,又能尽可能地减少对软件研制过程的干扰。

2.2影响域分析论证

当需求变更周期到达时,需求方和开发方将一同进行变更的影响域分析。

若需求方提出需求更改申请,需与软件经理共同编制需求更动论证及影响分析报告。需求方从更动的必要性、可行性及变更带来的影响方面进行论证,即是否必须进行设计变更才能满足预期的性能指标要求和使用要求,或是对此有明显改善、提出的变更技术上是否合理,工程上是否可行,变更对产品的可靠性、安全性及接口的影响。开发方根据需求跟踪矩阵,标识并实施因分配需求的更改而引起的项目计划、软件工作产品(包含文档和代码)和活动的更改。开发方的影响分析包含软件功能、性能等技术类分析,还应包含管理类的非技术影响分析。

若开发方提出需求更改申请,开发方单独编写需求更动论证及影响分析报告,需重点从软件配置项角度论述更改带来的影响。

在该流程中,影响域分析论证由需求方和开发方在申请得到响应的第一时间内共同完成,需求变更影响域分析将更全面、更系统也更具体。同时,通过影响域分析,将需求方变更也纳入到了工程化管理,既对需求方更改进行了控制,以减少不必要的软件变更,又使得开发方能够及早地参与影响域分析论证,及时应对需求变更。

2.3需求变更评审

软件配置控制委员会(SCCB)(组成人员中包含需求方、软件专家)评估需求变更论证及影响分析报告。

2.4需求变更分级管理实施

在进行需求变更评审时,需对需求变更进行定级,针对定级情况实行分级管理,以达到对需求变更的控制和管理。

根据变更影响域分析,可将需求变更定义为4个级别。一级为变更关键性需求,如若不变更,意味着整个项目不能正常交付使用,前期工作也会被全部否定;二级变更影响后续关键性需求,不影响前面工作内容的交付,但不变更,新的项目内容无法提交或继续;三级变更为后续重要需求,如果不被满足会令整体项目工作的价值和开发人员技术价值下降;四级需求是改良性或可选性需求,没有实施变更并不影响已有功能的使用,代表个人喜好[8,9]。

一二三等级变更,需实施更改;对于四级需求,如果时间和资源条件允许,可实施更改或是后续版本更改。

需求方提出的变更申请,需求方对分配需求进行更改,将变更后的《软件任务书》批准、受控,下发至软件研制单位。开发方接收到正式变更要求,类同开发方提出的变更申请,按照软件工程化管理规定,办理更改的三单审批流程,实施更改。

2.5通报和跟踪

SCCB确认需求已进行实际的变更。软件配置管理工程师通知所有受影响的小组和个人。开发方将因更改而引起的情况通报给受影响的组和个人,对已标识的相关更改进行跟踪,直到更改结束。

3需求变更管理实践

上述需求变更管理流程,已被成功应用到某型号某软件研制过程,该软件为嵌入式C程序,代码规模约为12 000~15 000行。在实践过程中,初样阶段 “需求变更池”处理周期为1个月,正样阶段处理周期定义为“新的需求提出”。至软件交付时,该软件共发生软件需求变更15项,需求方提出需求变更6项,开发方提出需求变更9项,通过需求变更评审,需求变更一级为3项、二级为4项、三级为2项、四级为6项。

通过需求变更管理,该软件共发生的15项需求变更中,实施了13项,有效地控制了软件需求变更比率。在未增加开发人员和资源情况下,同软件开发计划相比,软件过程文档编写数量减少了16份以上,初步预算节省软件工程组人员工时80人时以上;同时软件研制过程可见、受控,软件研制进展顺利,交付进度较计划时间提前了约60天;软件在交付使用后,其功能性能满足用户需求。

4结语

通过分析软件项目开发过程中需求变更产生的原因,提出了软件工程化管理过程中存在的问题,并在此基础上提出了需求变更管理主流程, 该流程保证变更实施在可控范围内进行,将影响域分析提至系统级层面,并将需求变更实施分级管理,从而将变更带来的影响尽可能地降到最小。需求变更管理流程真正将需求方、开发方与需求变化、变更请求和项目管理紧密结合在一起。通过某型号某软件3年的软件工程化管理实践,证实该管理流程使需求变更在项目开发中得到了有序有效管理, 保证了项目的顺利完成, 提高了项目的质量。

参考文献:

[1]韩万江,姜立新.软件项目管理案例教程[M].北京:机械工业出版社,2005.

[2]张海藩.软件工程[M].第1版. 北京:清华大学出版社,2006.

[3]ERACAR Y A, MIECZYSLAW. An architecture for software that adapts to changes in requirement [J] . Journal of System and Software,2000(50).

[4]STANDISH GROOP. User survey report[R]. European Software Process Improvement Training Initiative, 1995.

[5]秦众森,李娟.需求变更管理过程机器工具分析与展望[J].计算机工程与设计,2009(11).

[6]SUZANNE ROBERTSON, JAMES ROBERTSON.掌握需求过程[M].王海鹏,译.北京:人民邮电出版社,2003.

技术变更流程范文2

ArcGISServer;ArcGIS服务器;GIS;工作流技术;空间数据库技术

土地变更的过程中,一般涉及到地块地类属性的变更、地块面积的变更、地块所有权的变更等。采用传统的土地变更方案,首先需要测量外业部门到野外勘测,再由内业部门依据测量数据绘制变更地图,最后经过多个行政部门的确认和审批,整个过程步骤繁多,进度缓慢。本次根据土地变更各种环节设计了一个新型的土地变更服务方案,此方案将传统变更过程中的多个步骤采用一个统一的系统整合到一起,加快变更过程,同时也更好的确保了审批过程中各部门数据的一致。

1.关键技术

ArcGISServer系统套件。ArcGISServer是一个企业级GIS应用程序的综合平台,提供了创建和配置GIS应用程序和服务的框架,可以满足客户端的各种需求也可以处理地理资料。ArcGISServer是一个完整的GIS系统,不仅具有网络地图功能,而且具有数据管理、空间分析和可视化服务,它也是创建Web应用程序的一个完整体系。此设计选用ArcGISServer平台的主要原因有:

ArcGISServer不但有自身特有的各种服务功能,同时还支持额外的OGC服务,包括增强的WMS支持,以及新的WCS和WFS支持。

针对图像传输的新的图像服务优化。它支持客户端的采样压缩要求,并提供图像和数据进行分析。这个开放的服务支持SOAPXML、WCS和WMS。此外,用户可以存储在地理数据库或文件系统的栅格数据,还为需要大量基于图像文件的用户提供ArcGISServerImage扩展。

ArcGISServer可以对二维的地图服务进行按需缓存。通过ArcGIS服务管理器,用户可以定义缓存服务,使之满足按需缓存,也可以使用ArcCatalog和地理处理工具,以建立兴趣区的缓存和修改缓存以包括另外的规模水平。

利用ArcGIS服务器,用户使用ArcGISServerManager进行安全管理。基于角色的安全规则可以针对应用和服务,允许管理员分配不同水平的特定用户组的访问。

ArcGISServer包括一些增强的Web地图应用。这些改进包括创造一个更精简的用户体验、新地图、导航和更多的工具,也支持地图结果的提示和增加打印能力。

ArcGIS服务器包括针对使用JavaScript进行Mashup类型开发的API。它包括面向SOAP和REST服务的Web服务SDK,以及具备Ajax功能WebADFs,以进行高级的网络和企业应用开发。这些文档内容已被显著扩展,特别是针对WebADF、JavaScriptSDK、RESTAPI和SOAPWeb服务的文档内容。未来还会支持AdobeFlex的ArcGISAPI,这些API可用于创建种类丰富的Web应用程序。

工作流与工作流管理系统。工作流相关概念:工作流是一项借以在分布式办公环境中定义、执行、监督、协调工作项目流动的技术。工作流管理是一种统揽全局的过程管理工具,利用工作流管理可以对各个业务流程进行控制,并且能够将不同的业务流程纳入到一个总的计划中加以统一管理。工作流管理系统可以描述不同覆盖范围和不同时间跨度的经营过程,根据经营过程以及组成活动的复杂程序,工作流管理系统可以采取多种实施方式,在不同实施方式中,所应用的信息技术、通信技术和支撑系统结构会有很大的差别,工作流管理系统的实际运行环境可以在一个工作组内部,也可以在全单位所有业务部门。

工作流参考模型。工作流参考模型是国际工作流管理联盟为实现各种工作流管理系统软件产品之间的有效集成而定义的一个标准模型。它由过程定义工具、工作流引擎、管理监控工具、客户应用程序、被调用程序这5个标准接口组成。

工作流引擎,是为流程实例提供运行环境并解释执行流程实例的软件部件;过程定义工具,是管理流程定义的工具,它可能通过图形方式把复杂的流程定义显示出来并加以操作;流程定义工具同工作流执行服务交互;客户应用程序,是通过请求的方式同工作流执行服务交互的应用,也就是说是客户端应用调用工作流执行服务;客户端应用同工作流执行服务交互。被调用程序,是被工作流执行服务调用的应用;调用应用同工作流执行服务交互。为了协作完成一个流程实例的执行,不同的工作流执行服务之间进行交互。管理监控工具,主要指组织机构、角色等数据的维护管理和流程执行情况的监控;管理监控工具同工作流执行服务交互。

2.系统设计与开发

系统总体架构。根据土地变更业务工作的特点,土地变更信息系统主要具有如下几个特点:管理的动态性;管理的权限性;管理的网络化;管理多报表化;图数集成管理。

功能模块设计。变更项目模块:在“变更项目”模块中,分有“最新项目”、“项目申请”、“项目列表”、“项目查询”四个功能。通过对工作流引擎的调用,在“最新项目”和“项目列表”里面列出了登录者有权查看的项目。

用户角色模块:此方案引入了角色访问控制的思想,采用了“角色”的概念,目的是为了隔离“用户”与“权限”。

报表生成模块:在信息化还没有得到充分应用前,报表还是上级部门查阅和历史查询的主要手段。在变更项目得到批准之后,必须填写变更相关的报表,系统提供划定范围的统计二三级地类的标准报表查询分析及划定范围地类统计专题图查询。除了要生成政策文件上规定的报表外,系统应该能采用灵活快速的统计方式,可用结果表现形式来生成自定义报表。

历史回溯模块:在这个功能中,用户可以根据选择不同历史时刻的空间数据,浏览不同历史时刻空间数据的变化。所有的ArcSDEGeodatabase均具备Default版本,Default版本为ArcSDEGeodatabase最原始的版本,它是服务器中所有版本的父版本,可以在Default版本或是它的子版本下创建版本,也可以对此版本直接更新。需要注意的是如果要使创建的版本具备历史回溯功能,在创建版本时应该使数据集具有历史归档功能,这样才能通过历史归档的记录回溯到不同的历史版本。

GIS功能模块:GIS功能是土地变更服务系统的重要功能。此方案把GIS功能设计成WebGIS的形式,一方面可以有效的把GIS功能与其它Web功能集成在一起,另一方面可以达到“随时随地办公”要求。

此方案在充分分析了土地变更流程的前提下,将GIS、工作流技术、空间数据库技术相结合。ArcGISServer在本次设计的系统中处于核心地位,设计中将它提供的ArcSDE空间数据库引擎、时态数据库进行了实例化。交互方面采用WindowsWorkflowFoundation和组合在一起,提供了一个可测试、可伸缩、可维护的工作流应用方式。基于这些技术的工作流模型,使得用户界面的设计和后面工作流代码的设计分开,同时还使得长耗时的工作流可以使用WF的SQL持久化服务来长期保存。实现了地图历史回溯的功能,给土地管理工作带来了新的方法。

[1]贾勤学,张 玮,李建林,吴 楠,于丽君.基于遥感技术的耕地面积动态监测研究[J].中国农学通报,2006.07

[2]杜灵通.基于遥感技术的土地利用/覆被变化研究[J].国土资源信息化,2007.02

[3]沈小乐,王 璇,刘 倩.土地利用动态监测技术的研究[J].湖北民族学院学报(自然科学版),2007.03

[4]李懿麟.基于GIS与RS一体化的变更地块判别方法[J].测绘科学技术学报,2007.z1

技术变更流程范文3

4M变更管理办法最新版

1、目的

在生产过程中,对影响产品质量的4M要素(人、机、料、法)进行管理和控制,使

这四个因素在保证质量的范围内安全合理的变动,从而保证产品质量的稳定和提高,符合标准及客户要求。

2、适用范围

适用于批量产品生产过程中4M(人、机、料、法)要素的管理。

3、4M定义:

是指批量产品生产过程中,涉及的人(Man)、机(Machine)、料(Material)、法(Method),

(含环境场所)等给产品质量带来一定影响的变更。

人(Man):是指生产过程中作业者因缺勤、调动、离职、代岗或复岗时,由另一个新作业者代替进行作业时,所产生的变更;

机(Machine):是指生产过程中的设备、模具、工装、夹具、检具的新增、修理、代用变更; 料(Material):是指生产过程中的加工原物料、辅料、包装物资等变更。

法(Method):是指生产过程中的工艺流程、工艺参数(设备参数、材料配比等)、检验方法、作业方法(制造、整理、包装、周转等)变更。

4、职责

4.1变更提出

原则上公司内部变更各部门均可提出申请,并根据变更内容对产品质量的影响程度进行必要研讨,经评审后由实施部门负责执行变更;各4M变更实施部门要建立4M变更的台帐,记录变更的编号、产品型号和结果等。

4.1.1制造部技术组:负责产品工艺流程、模具、工装、检具及方法等变更的实施。

4.1.2制造部生产组:作业人员晋升变更的申请,并根据岗位技能要求进行资格验证,实施变更;内部变更引起的呆滞物料变更处理的申请,跟踪等。

4.1.3供应链:材料(含构成零部件)变更的申请提出和实施,及供应商的变更受理;

4.1.4工程部:机器,方法、设备变更的申请提出和实施;

4.1.5市场部:负责客户提出的变更受理,负责收集和内部反馈客户的评审结果;订单完成后库存呆滞料的变更处理的申请,跟踪等。

4.1.6体系:负责对所有变更事项进行监督及对变更的有效性进行跟踪确认。汇总4M变更结果,应建立4M变更总台帐。

4.2 变更评审实施

4.2.1 变更申请通过部门负责人审核后,由申请部门组织相关评审部门,根据变更内容对产品品质的影响程度进行必要的研讨;由各评审部门审查确认后,变更责任部门执行变更;或根据变更管理类别(送样、申请,记录)由市场项目收集客户意见后实施; 4.2.3 对相关部门进行变更培训,记录保存变更履历。

注:评审部门包括但不限于技术部门/生产部门/质量部门/采购部门/设备管理部门。

4.2.4 4M变更实施部门对变更过程中可能出现的意外要有应对预案;

4.2.5 4M变更实施部门及相关部门需修订变更涉及事项(如工程图纸、SOP、FMEA、控制计划,SIP,ECN,BOM,QC工程图,工艺流程图等);

5 4M变更管理类别:送样,申请,记录

5.1 送样:变更前须试制样品,并向客户送样认可。

5.1.1 变更前,需向部门内部提出变更申请,由实施部门组织评审部门评审,通过后由变更实施部门试制样品,并向客户送样,合格后客户认可,才能实施变更;

5.1.2 变更申请部门须填写《(4M)工程更改申请单》并执行4M变更管理流程。 变更实施部门审查后,由变更实施人将通过的《(4M)工程更改申请单》和其它相关评审报告记录在《(4M)工程更改通知单》中,客户评价结果由市场部项目收集客户评价结果反馈给变更实施部门等有关部门,批准生效后,实施工程变更。

5.2 申请:变更须启动4M变更管理流程进行评审实施。

变更前,需向部门内部提出变更申请,变更申请部门须填写《(4M)工程更改申请单》并启动4M变更管理流程。由实施部门组织评审部门评审,经客户或责任部门确认同意后才能实施变更;

5.3 记录:此类变更须责任部门记录并保存。

由责任部门管理记录相应变更,并保存相关记录。为了确保变更的履历(可追踪性),供应商应自从该变更品的交货日算起保管3 年。

6 变更管理内容

6.1 客户提出的4M变更

客户提出的4M变更由市场部向公司内部提出申请,按新产品管理流程进行;

6.2 供应商的4M变更

供应商提出的4M变更,由供应商向采购部门提出,向公司内部传达;

6.3 公司内部的4M变更

6.4 变更点的区分管理

6.5 变更品的首次交货

6.5.1变更品的首次交货,需在外包装箱加贴变更后首批次出货标签,并连续3批作出标识。

6.5.2变更品与原来产品在同一批交货时,需:

1.原来产品与变更品的外包装分开;

2.在外包装箱加贴变更后首批次出货标签,并连续3批作出标识。

技术变更流程范文4

关键词:电力物资采购合同;管理;流程控制

作者简介:董付梅(1976-),女,山东临邑人,山东省临邑县供电公司,助理工程师。(山东 德州 251500)

中图分类号:F272?????文献标识码:A?????文章编号:1007-0079(2012)33-0118-02

一、电力物资采购合同管理的意义

实施电力物资采购合同的有效管理能更好地防范电力物资采购风险,能提高物资管理部门的整体管理水平,能加强物资采购合同履行过程的控制,提高合同履约水平,能优化合同管理流程,提高合同管理效率。电力物资采购合同管理坚持依法从严管理,严格合同签约履约,深化“集中签订、集中结算”的合同管理模式,建立上下联动、统筹协调的物资现场服务和履约协调机制,通过对物资采购合同的签约、履约全流程管控实现物资管理的科学化、规范化、标准化、法制化,从而提高了企业的经济效益,提升了企业的社会形象。

二、电力物资采购合同管理的方法

临邑县供电公司电力物资采购合同管理以电子商务平台和ERP系统为基础,全过程控制物资合同的签约、变更、履约和资金结算业务,并采用流程控制方法进行管理。流程控制方法通过流程绘制管理工作的过程,全面描述如何从一个节点流向另一个节点,包括节点具体工作方法、工作工具等的描述以及关键节点、创新节点说明。采用流程控制方法,加强物资采购合同全过程管控,以达到标准化、科学化、规范化的要求。

三、物资采购合同标准化管理流程控制

1.流程控制

(1)电力物资采购合同签约管理流程控制。

1)市公司下发中标结果并确定是否需要签订技术协议。一般来说,对于新应用设备材料、技术复杂或项目实施的关键设备材料,可根据需要组织项目管理部门、物资需求部门、设计单位等相关部门进行技术协议的签订。

2)如果需要则组织签订技术协议,由市公司负责组织,县公司授权项目主管部门负责人与供应商代表签订技术协议。

3)县公司物流服务中心采购员在ERP系统中创建采购订单。

4)县公司物流服务中心主任在ERP系统中审批采购订单。

5)判断采购订单是否审批通过。

6)采购订单审批通过,县公司物流服务中心主任(公司委托授权人)与供应商代表签订物资采购合同。

7)县公司物流服务中心履约员上报合同签订资料。

8)省市公司合同专工汇总合同签订资料,提出考评意见并下达。

9)县公司物流服务中心履约员将合同相关资料归档。

(2)电力物资采购合同变更管理流程控制。

1)县公司项目主管部门根据设计变更通知单提出合同变更申请。根据项目实际要求,需对采购结果进一步补充说明或明确物资合同双方权利义务的事项,且不造成对采购结果实质性内容进行的更改。

2)县公司物流服务中心主任审核提报的合同变更申请。审核的依据是物资规格参数不变、单价不变,合同签订数量予以增加或减少,增减幅度是否超过招标文件或采购文件约定的15%执行,是否超过50万元。若合同签订数量增减幅度超过招标文件或采购文件约定的15%且超过50万元,则需重新纳入物资计划采购管理。

3)判断合同变更申请审核是否通过。

4)县公司物流服务中心主任审核通过后报县公司分管领导审批。

5)判断合同变更申请审核是否通过。

6)县公司分管领导审批通过后报省市公司物资部专工审批。

7)判断合同变更申请审批是否能过。

8)省市公司物资部合同专工审批通过后,县公司物流服务中心履约员根据审批结果确定合同变更方案并通知供应商。

9)县公司物流服务中心采购员根据合同变更方案在ERP系统内更改采购订单或增加采购订单。

10)县公司物流服务中心主任在ERP系统内审批变更合同或补充合同。

11)判断变更合同或补充合同审批是否通过。

12)县公司物流服务中心主任审批合同通过后,县公司物流服务中心履约员上报合同变更情况。

13)省市公司合同专工汇总合同履约信息,提出并下达考评意见。

14)县公司物流服务中心履约员将合同变更相关资料归档。

(3)电力物资采购合同履约管理流程控制。

1)县公司物流服务中心履约员在ERP系统内根据采购合同到货日期制订物资催交计划。重要设备材料要及时掌握供应商的生产准备和排产计划,按照关键生产节点,核实生产进度,及时协调解决生产中出现的问题。

2)供应商根据采购合同的到货日期制订生产计划。

3)县公司物流服务中心履约员对重点物资生产节点履约跟踪。

4)县公司物流服务中心建立交货配送制度。根据合同交货期和施工进度,履约员及时与物资需求部门确定物资到货需求,与供应商落实配送安排,编制配送计划。采用配送单的方式通知供应商发货和现场服务人员做好接货准备。

5)供应商按确定的时间和方式交货。

6)县公司物流服务中心履约员组织物资需求部门与供应商现场办理交接手续,并组织项目单位与供应商代表进行物资验收工作。

7)确定物资验收是否合格,相关验收人员在验收单上签字确认。

8)物资需求部门与供应商办理现场交接手续。

9)物流服务中心协调供应商按照合同规定和现场管理的要求安全、优质地完成技术服务、消缺补件、设备安装调试等工作。

10)县公司物流服务中心履约员上报合同履约信息。

11)省市公司合同专工汇总合同履约信息,提出并下达考评意见。

12)县公司物流服务中心履约员将合同履约资料归档。

(4)电力物资采购合同资金结算管理流程控制。

1)县公司物流服务中心履约员根据采购合同提交预付款申请,附物资采购合同、预付款保函和相应的收款收据。

2)县公司物流服务中心履约员提交到货验收款申请,附增值税发票、项目主管部门签字确认后的到货验收单和相应的收款收据。

3)县公司物流服务中心履约员提交投运款申请,附运维单位签字确认后的物资投运单和相应的收款收据。

4)采购物资质保期满无质量问题的,县公司物流服务中心履约员提交质保金申请,附项目单位签字确认后的质保单和相应的收款收据。

5)县公司物流服务中心核算员汇总履约员提交的预付款申请、到货款申请、投运款申请、质保金申请,在财务管控系统中编制物流服务中心月度现金流量预算(物资采购支出预算)。

6)县公司物流服务中心主任在财务管控系统中对物资采购支出预算进行审核。

7)判断物资采购支出预算审核是否通过。

8)物流服务中心主任审核通过后,县公司分管领导对物资采购支出预算进行审核。

9)判断物资采购支出预算审核是否通过。

10)县公司分管审核通过后,县公司财务部专工对物资采购支出预算进行审核、汇总。

11)判断物资采购支出预算审核是否通过。

12)各级审核通过后,财务人员实施预付款处理或应付账款处理。

2.关键节点及创新节点说明

(1)电力物资采购合同签约管理关键节点及创新节点。其中第3)点既是关键节点又是创新节点。采购员在ERP系统内创建采购订单,保存时系统会自动检查是否超预算。如果超预算,系统会提示并不予通过,此时由采购员联系采购申请的创建人进入项目变更管理流程调整预算,之后重新维护采购订单。如果不超预算,采购订单保存成功。

在ERP系统中采购订单维护成功后,采购合同、配送单、到货验收单、投运单、质保单在系统中以统一的文本格式自动生成,这5种单据可以根据业务进展情况在不同时期打印。为简化业务流程、提高工作效率,采购员在成功创建采购订单后将5种单据一次性全部打印,根据具体情况分发给买卖双方或存档,尤其是验收单、投运单、质保单,一次性打印全部由供应商留存,便于在不同时期提交进行资金结算,减少了供应商多次到物流服务中心打印单据的麻烦,为客户提供了便利。

第6)点既是关键节点又是创新节点。物资合同签订后,履约员要核实是否需要预付款。如果需要预付款,进入采购付款管理流程。如果不需要,则根据实际情况进入物资收货流程。

在ERP系统中采购订单维护成功后,市公司组织供应商与各县公司集中签约,严格使用国家电网公司物资采购统一合同文本,确保在中标结果后15日内及时完成合同签订。严格中标结果执行,合同签订不得更改中标结果或违背招标、投标文件实质性条款,逐步取消技术协议签订,进一步加快合同签订速度,大大提高了签约效率,降低了签约成本,方便了客户。

(2)电力物资采购合同变更管理关键节点。第9)点,集团公司物资部合同专工审核合同变更申请,若增幅度超过15%或超过50万,则需转入物资需求计划管理流程,新增物资需求计划;若增幅度不超过15%且不超过50万,允许合同变更。

(3)电力物资采购合同履约管理关键节点及创新节点。其中第3)点是关键节点。建立履约管理常态机制,实时监控供应商实际生产状况、项目进度对物资供应的需求,确保供应商按期供货、项目单位按期收货。

第5)点是关键节点。供应商是否按照采购合同约定的日期和方式交货是其履约水平的重要环节,是物资计划执行准确率的重要因素。

第6)点是关键节点。物资的验收是对物资的数量、外观、内在质量以及有关技术资料、凭证和物资标志等进行检查,以验证物资是否符合合同规定;物资的验收工作质量的好坏直接关系到整个电网建设和生产的质量。物资到货验收合格后必须在合同交货期满10日内办理ERP入库手续,确保计划执行准确率达到95%以上。

第12)点是创新节点。在合同履约过程中建立“一单(订单)一评价”的履约评价机制,及时采集供应商交货、产品质量和售后服务等信息,对供应商合同履约情况实行卡片式管理,并将结果及时上报。严格供应商违约处置,严格按照合同约定对供应商违约行为进行当期处理。建立诚信评价机制,对合同签订履约情况开展诚信评价,加大对失信行为的惩戒力度,营造诚实守信的良好氛围。

(4)电力物资采购合同资金结算管理关键节点。第1)点物资合同签订后,供应商提交预付款申请需出具预付款保函、收款收据和物资合同;若供应商放弃预付款,预付款可与到货验收款、投运款一起支付。

县公司物流服务中心核算员汇总供应商提交的付款申请,在财务管控系统中编制月度现金流量预算。预算编制及资金支付应按照合同相关条款及公司财务相关规定,在付款相应凭据汇集完成后进行。

技术变更流程范文5

【关键词】计算机软件;eTOM;ITIL;服务保障;生命周期

引言

随着互联网技术的迅速发展,通信行业网的业务已经从单一,简单的通信行业服务逐步过渡到内容增值服务的阶段,巨大的市场潜力正在改变整个通信行业市场的运营规则和供应体系,各个通信行业运营商因为竞争和业务发展的需要,都采取了非常积极的营销措施以提高市场占有率。这些服务和营销措施的实现都需要计费系统的支持,因此,计费管理平台面临巨大的挑战,需要加强计费系统的可靠性、精确性、高效率、灵活性。

一、计费服务保障生命周期模型设计基础

1.ITIL对服务支持过程的要求

ITIL(Information Technology Infra-structure Library)是信息技术基础设施库。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。ITIL的核心模块是“服务管理”,这个模块一共包括了10个流程和一项职能,这些流程和职能又被归结为两大流程组,即“服务提供”流程组和“服务支持”流程组。其中服务支持流程组归纳了与IT管理相关的一项管理职能及5个运营级流程,即事故管理、问题管理、配置管理、变更管理和管理。

2.eTOM对服务保障和计费的要求

eTOM(enhanced Telecom Operations Map)是增强的电信运营图,是信息和电信服务行业的业务流程框架,它为服务提供商提供所需要的企业流程。eTOM有三大流程区域:战略、基础设施和产品流程、运营)流程、企业管理流程。其中,运营区域是eTOM的核心。包含运营支持与就绪、业务开通、服务保障和计费三个流程组。服务保障流程组负责执行主动的和被动的维护活动,确保提供给客户的服务是持续可用的、能够达到SLA(服务等级协议)或QOS(服务质量)所要求的性能水平。计费流程组负责及时准确的账单,计算客户使用通信行业业务的应收费用,并完成应收费用的处理与征收。计费模块与服务保障模块联系紧密。这些联系可以分为计费模块报告给保障模块的事件和保障模块报告给计费模块的事件。计费模块将计费系统发生的故障和异常报告给保障模块处理。保障模块将服务的执行的相关信息报告给计费模块,以影响服务费用的计算和收取。服务保障模块保障了计费模块的质量。计费模块根据服务保障模块的要求进行处理或优化。在通信行业中,服务保障模块 “监视”着计费系统的质量水平,要求计费系统按照服务保障模块的要求建立计费系统内各功能模块,对计费系统中有问题的模块或不完善的模块提出要求。计费系统根据此要求不断完善系统,以达到服务保障的要求。

二、案例分析及研究

1.通信行业计费系统运营维护现状

本文借鉴某通信行业的计费系统来分析通信行业计费系统生产运营管理和维护支撑现状,并提出通信行业的计费系统服务保障生命周期模型。此计费系统是集采集、计费、账务,结算,统计等为一体的大型后台支撑系统。整个计费体系采取集团管控各省管理和生产的模式。

此计费系统在运营维护方面的五个环节存在以下不足:(1)事故管理方面:人员对故障的判断和定义不准确,网络故障定位困难,易受其他系统干扰,在故障处理的专业技术水平方面仍需加强。(2)问题管理方面:问题解决流程不够完善,系统接口多,难以统一管理,记录不够完整。(3)配置管理方面:重视度不足,没有配置管理方面的文件标准和规范。(4)变更管理方面:文档不完善,频繁的变更出现管理疏忽问题。(5)管理方面:单人负责风险高,文档不完善。本文对五个环节进行了研究,针对计费系统制定出了一套规范的维护流程,计费系统按照研究的流程来规范五个维护环节,将大大提高维护效率。

2.通信行业计费服务保障生命周期模型研究

研究计费系统服务保障生命周期模型,是为了通信行业计费系统能够按照此模型进行规范和完善。在软件生命周期的基础上加强服务保障,以延长和稳定软件系统。模型图如下:

图1 通信行业计费系统服务保障生命周期模型图

(1)开发

1)软件需求:软件的需求管理是整个软件生命周期的触发,它直接关系到最终产品的成型。在此阶段设计出《软件需求规格说明书》。

2)软件开发:在此阶段,开发人员根据《软件需求规格说明书》进行软件项目的开发。实际执行中,乙方的开发人员一般与甲方的使用人员要进行多沟通,交流,以便更好的了解软件的需求。

(2)测试

1)软件测试:软件测试是软件生命周期模型中决定软件质量保证的一个重要的阶段。它并不仅仅存在于软件开发结束以后,他应该伴随着软件开发阶段,直至软件的使用。在开发过程中,软件要进行单元测试、集成测试。在开发完成时,要进行系统测试和验收测试。验收测试决定着软件是否能通过验收。在软件使用阶段,由于需求的不断变更和程序漏洞的不断发现,要进行软件的回归测试。

2)软件试运行:经过软件测试合格后,软件进入试运行阶段。在此阶段,软件通过多个使用人员的不断使用,会涌现出很多漏洞或者新的需求。这一阶段是发现软件问题的重要环节,因为开发人员与使用人员的角度不同,共同讨论、协商、试用,会帮助软件更茁壮,更快速的上线。

3)软件正式使用:经过一个阶段的试运行,软件功能基本稳定,完全满足所有《软件需求规格说明书》的要求,满足全面上线的要求,软件开始正式使用。

4)软件验收:经过软件各个阶段的测试,确认软件满足《软件需求规格说明书》中的要求,并且满足项目开发前期预定的验收条件的情况下,软件进行验收。

(3)服务保障:根据ITIL中的服务支持流程,要设计计费服务保障流程,必须遵循ITIL中的服务支持流程里的这五个运营级流程,即事故管理、问题管理、配置管理、变更管理和管理。

图2 故障处理流程图

图3 问题报告单处理流程图

1)计费系统服务保障事故管理:通信行业计费系统在故障管理方面仍需要进一步加强和规范。要制定专门的计费系统故障管理制度。此管控制度应包含以下内容:A.故障时间。B.故障次数。C.故障定义:重大故障、严重故障、一般故障。D.故障响应时限,指故障发生至技术人员开始处理故障所经历的时间。E.故障处理时限,指故障发生至故障处理完成所经历的时间。F.故障处理的基本原则。G.故障处理要求。H.机房故障处理流程(如图2所示)。

2)计费系统服务保障问题管理:问题报告单是适用于计费系统内部管理的一种手段,它由产生问题的计费中心将本地网范围内的问题汇总、分析、过滤、整理后提交该本地网计费中心主任批准,并由其本人或指派专人提交省计费人员,由省中心统一进行管理。问题报告单处理流程如图3所示。

3)计费系统服务保障配置管理:计费系统在配置管理方面需要制定规范的配置管理流程和管控制度。配置管理的流程模块图如下:

图4 配置管理的流程模块图

4)计费系统服务保障变更管理

为规范通信行业计费系统软件变更管理,提高软件管理质量,需要下发《计费系统变更管理办法》。

A.主要目标:主要目标是规范软件变更管理的人员要求、阶段要求,各种形式的软件变更管理流程,版本管理、文档管理和进度管理的要求,变更过程中质量保证的要求。

B.制度建立与工位设置:省中心根据软件分类的不同,应设置以下工位或小组,负责整个软件变更过程中的管理和实施。软件变更审批组,软件变更管理组,软件变更测试组,文档管理工位,软件版本管理工位,软件质量管理工位。

C.软件变更管理维护流程

图5 计费系统服务保障变更管理流程图

5)计费系统服务保障管理

图6 计费系统的管理流程图

计费系统的管理需要有相关管理流程和管控制度,包含以下内容。

A.管理的目标是为了规范计费系统软件变更的管理。

B.成立专门的软件项目组。

C.文档管理要求:软件需求单,维护文档,稽核文档。

D.质量管理及考核。

E.计费系统的管理流程图(如图6所示)。

三、总结

通过ITIL对计费系统服务支持过程的要求,可以细化系统的运营维护流程和管控制度;相对于原有流程,工作效率有明显的提高。通过eTOM对服务保障和计费的支持,结合软件生命周期的定义,软件从开发到测试到上线进行规范系统的管理,提高了计费软件的效率。这两部分的优化改善完全遵循本文研究的通信行业计费服务保障生命周期模型,直接作用到对企业业务的强有力支撑,从而提高了企业的信息化服务水平,更提高了对客户的服务水平和客户的感知,在飞速发展的通信行业里,企业才具有强竞争力。

参考文献

[1](英)萨默维尔著.程成,等译.软件工程(原书第9版)[M].机械工业出版社,2011.

[2]刘通.ITIL V3服务管理与认证考试详解(第3版)[M].哈尔滨工业大学出版社,2012.

[3](荷)博恩著.章斌译.基于ITIL的IT服务管理基础篇[M].清华大学出版社,2007.

技术变更流程范文6

服务台有时也称帮助台,即通常人们所指呼叫中心或客户服务中心,它不是一个服务管理过程,而是一种服务职能。服务台经常与事件管理紧密结合,用来连接其他的服务管理流程,逐渐被称为一线服务支持的代名词。

服务支持

1、配置管理

配置管理是将一个系统中软件和硬件等配置项资源进行识别和定义,并记录和报告配置状态和变更请求以及检验配置项的正确性和完整性等活动构成的过程。

2、变更管理

变更管理是要确保在IT服务变动的过程中能够有标准的方法,以有效的监控这些变动,降低或消除因为变动所造成的问题。它的目的并不是控制和限制变更的发生,而是对业务中断进行有效管理,确保变更有序进行。

3、管理

管理是指对经测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程,目的是保障所有的软件组件的安全性,以确保只有经过完整测试的正确版本得到授权进入正式运行环境。

4、事件管理

事件管理指的是突发事件管理或意外事件管理,处理IT的危机并要从中恢复运转。即在出现事故的时候,能够尽可能地恢复服务的正常运作,避免业务中断,以确保最佳的服务可用性级别。

5、问题管理

问题管理是指负责解决IT服务运营过程中遇到的所有问题的流程。问题管理的主要活动实质上就是分析以被列出问题的事件的根本原因,找出解决方案,把事件的影响最小化,并通过找到已发生事件或潜在事故的根本原因来减少事件的数量或消除事件的再次发生。

服务提供

1、服务级别管理

服务级别管理是一种严格的超前方法论和处理程序,是定义、协商、订约、检测和评审提供给客户的服务质量水准的流程。

2、财务管理

财务管理是在提供深入了解IT服务管理流程的基础上,对IT恢复运作的费用及成本重新分配并进行正确管理的程序,其目标是帮助IT部门在提供服务的同时加强成本效益核算,以合理利用IT资源、提高效益及财务资源使用的有效性。

3、可持续性管理

可持续性管理是指确保发生灾难后有足够的技术、财务与管理资源来确保IT能持续服务的管理流程。

4、容量管理

容量管理是指在成本和业务需求的双重约束下,通过配置合理的服务能力来确保服务的持续提供和IT资源的正确管理,以发挥最大效能;以合理的成本及时提供有效的IT服务,以满足组织当前及将来的业务需求。