信息系统变更和发布管理办法

2024-05-01

信息系统变更和发布管理办法(共6篇)

篇1:信息系统变更和发布管理办法

信息系统变更和发布管理办法

第一章 总 则

第一条 目的:本管理办法规定了XX银行(以下简称“我行”)信息系统的变更和发布管理,变更和发布管理作业操作流程和控制要点,确保变更需求的受理符合业务的优先需要,并使变更和发布过程规范化,控制变更对银行业务和已投产系统安全运行的不利影响。达到降低信息系统变更和发布风险的目的。保障信息系统的安全稳定运行,特制定本管理办法。

第二条 第三条 第四条(一)目。

(二)生产业务系统:指我行从事金融服务的应用网络系统,包括综合业务系统、国依据:本管理办法根据《XX银行信息安全管理策略》制订。范围:本管理办法适用于我行信息系统变更和发布管理。定义

软件产品:泛指信息技术开发的生产业务系统和管理信息系统等应用软件项际业务系统、支付系统等银行对外营业的各种核心业务系统。

(三)管理信息系统:指我行信息管理的计算机网络系统,具体指OA办公系统、信贷管理、报表系统等用来进行内部管理的应用软件系统。

(四)第五条(五)遵循原则 业务部门:指我行总部相关业务部门。

监督制约原则:针对信息系统变更和发布管理工作中各个环节,建立相应的监督检查机制。

(六)计划性原则:信息系统发布应纳入每年计算机应用计划,确保全行计算机系统资源、应用环境、维护力量、操作技能能满足系统安全、可靠运行的要求。

(七)(八)可行性原则:具有普遍适用性和可操作性。风险控制原则:

若为新项目或新业务功能变更和发布,需进行以下风险分析: 1.备份机建设情况;

2.应用系统投产后的集中监控方案; 3.生产数据备份方案; 4.程序及系统备份方案;

5.数据库建库/建表/建索引方式等; 6.对其他系统的影响。

第二章 组织与管理

第六条(一)职责划分

需求部门:

1.提出需求,并确认《用户需求说明书》;

2.用户测试阶段确认用户测试计划、记录用户测试问题、确认用户测试报告; 3.接受用户培训并提出反馈。(二)科技信息部安全科:

1.在需求阶段审阅和提出IT风险控制、IT合规和IT稽核方面的要求,在项目开发阶段对有关IT风险控制、IT合规和IT稽核方面的测试结果进行审阅;

2.在项目实施后审阅阶段对有关IT风险控制、IT合规和IT稽核要求的实施效果进行审阅。

(三)科技信息部运行维护中心:

1.负责受理所有变更和发布需求,会同IT其他相关部门(IT软件开发中心、安全科等)对变更和发布需求进行评估,并将评估意见向IT部门领导、业务部门领导汇报沟通,获取所需的授权;

2.在详细设计阶段审阅和提出网络、硬件、操作系统和数据库等方面的配置和容量要求;

3.在设计与编程阶段提供网络、硬件、操作系统和数据库的参数配置; 4.在测试阶段配合项目组设立网络、硬件、操作系统和数据库环境;

5.配合项目组对系统进行联合测试,把信息系统版本软件、相关配置文件、标准数据和相关文档提供给测试评估中心;

6.将信息系统发布到使用部门,系统上线时会同项目组搭建生产系统并进行程序移植,组织定期对变更和发布效果进行分析和总结。

7.接收管理和备份软件开发中心提供的源程序、相关标准数据、配置文件、相关文档;(四)科技信息部软件开发中心:

1.负责设计、编程、纠错和开发质量控制,编制《系统设计规格书》;

2.落实项目管理制度和业务操作手册的编制工作,参加制定上线方案制定,编制《上线实施计划》;

3.负责系统切换上线的技术支持工作;

4.负责项目验收资料整理汇总,配合项目验收工作。(五)科技信息部测试评估中心:

1.负责对需要测试评估的软件进行分析测试; 2.负责提交测试分析报告。

第三章 信息系统变更

第七条 信息系统变更,指由于新增信息系统功能、系统逻辑改变、系统错误修正、系统补丁安装及版本更新、系统配置修改及业务参数修改等原因,而对已投产系统进行局部改变的一切活动。已投产系统变更需求主要来源于以下几种情况:

(一)由于业务快速发展,业务部门对现有已投产系统的功能或设置进行变更或通过新增功能来满足需求;

(二)用户在使用过程中发生的一些操作错误,或技术人员、监控管理软件自动发现的故障或事件,需要通过安装程序补丁或修改配置等操作进行修改;(三)厂商定期发布的系统补丁,涉及系统的功能、性能、安全漏洞,需要在已投产系统中进行安装;

(四)由于系统容量扩充或与已投产系统存在数据交换或数据共享的其他已投产系统发生变化后引发的已投产系统变更。

第八条 信息系统变更的提出,必须由申请部门(用户部门或IT部门)填写《已投产系统变更流程单》(附件1)第一部分,申请信息。在申请信息填写阶段的主要工作内容包括:

(一)申请人需选择变更类型;(二)描述变更内容和目的;

(三)是否存在其他措施满足变更需求;

(四)如不实施变更可能对客户、合规、外部利益相关方、内部管理和操作、安全控制、系统可用性和数据准确性的影响;

(五)选择变更的急迫性。

第九条 申请部门主管审批签字后提交IT运行维护中心进行处理。

第十条 IT运行维护中心收到变更申请后,和变更申请部门充分沟通,理解变更需求的合理性,审阅变更的影响和急迫性,并会同IT其他相关部门(IT软件开发中心、安全科等)对可行的变更实施方案和变更对已投产系统的影响做出评估,最终形成建议的变更日期,填写至《已投产系统变更流程单》第二部分,变更需求评估信息,交IT运行维护中心负责人进行审批。

第十一条 IT运行维护中心组织变更需求评估时,应充分考虑系统是否已存在满足变更需求的功能或设置;是否存在其他操作手段,能达到同样的变更需求效果。

第十二条 IT运行维护中心组织变更需求评估时,了解实施变更:

(一)是否需要进行IT开发,以及IT开发的工时;

(二)是否需要进行操作系统、数据库系统、中间件、硬件和网络的变更;(三)是否需要进行后台数据变更;(四)是否存在信息安全控制的考虑因素;

(五)结合IT部门现有的IT资源,统筹安排变更实施时间表;(六)实施相关变更时,可能导致的业务中断或客户服务水平下降。

第十三条 综合对变更需求合理性的评估和变更实施影响的评估,IT运行维护中心在《已投产系统变更流程单》的第二部分提出变更的建议日期,并进行资源协调。在IT运行维护中心负责人进行审批后,通知相关部门:(一)如不建议实施变更,则向变更申请部门说明理由;

(二)如建议实施变更,则告知建议变更的时间及对客户服务和内部操作的影响,要求变更申请部门和相关部门进行准备;

(三)如变更规模超过《XX银行IT项目管理指引》规定的项目受理标准,则依据该指引有关规定执行。

第十四条 对涉及软件开发的需求变更,参照《XX银行IT开发方法指引》的要求执行。

第十五条 对不涉及软件开发的需求变更,IT运行维护中心根据需要,提交IT测试评估中心相关人员负责制定变更的测试步骤,落实测试人员在测试环境中对变更进行测试,测试人员对测试结果进行记录并签字确认。

第十六条 信息安全人员对变更进行上线前审阅,确保系统变更过程中的系统安全。信息安全人员完成上线前审阅后,IT运行维护中心进行上线处理。信息安全人员根据变更的风险程度,进行上线后审阅,确保达到变更目标。

第十七条 为控制已投产系统的变更对客户服务和业务操作带来的影响,确保生产环境的完整性和可靠性,IT部门应制定一系列控制IT变更的策略和制度,严格控制变更的规模、涉及面及信息安全风险。包括:

(一)IT运行维护中心负责人每周对集中的变更工作计划进行审阅,确保充分有效的IT技术资源或系统供应商/开发商技术资源,保证变更的有序进行;

(二)除非是需要立即实施的特急变更,IT运行维护中心应选择非业务繁忙时间,如凌晨、周末或公众假期进行变更上线;

(三)IT运行维护中心进行周密计划,包括制定意外应急措施;(四)分离已投产系统与开发或测试系统的管理职责;

(五)保证已投产系统和开发或者测试系统相分离,禁止开发人员在未经授权的情况下进入已投产系统;

(六)只有在得到管理层批准执行紧急修复任务时,开发人员才能访问已投产系统,所有的紧急修复活动都应立即进行记录和审核;

(七)开发人员对已投产系统进行变更必须经过严格的审批和控制;开发人员访问已投产系统时必须由IT运行维护中心系统管理员对其访问进行监督和记录,并在访问结束后系统管理员及时禁用或删除开发人员在已投产系统中使用的账号;(八)对已投产系统进行变更必须经过严格的授权之后才能进行操作实施,操作实施过程必须受到严格监控。

第十八条 变更实施上线前需进行用户测试,并在变更上线后由变更申请部门负责人对变更进行签字确认。

第十九条 对于上线过程可能导致业务暂时中断或导致业务操作发生重大变化的IT变更,IT运行维护中心必须在上线前以书面方式告知相关业务部门(至少包括行长办公室和客户服务中心)影响的业务范围和时间,并提供相关技术支持。

第二十条 IT变更上线执行的工作内容和相关要求参照《XX银行IT开发方法指引》中对上线的要求和描述。

第二十一条 变更计划与步骤、回退计划与步骤、IT测试步骤与结果、信息安全审阅意见、用户测试确认等变更实施信息记录在《已投产系统变更流程单》第三部分,变更计划和测试接受信息。IT运行维护中心负责人负责对变更实施信息进行审阅。

第二十二条

急变更是指在某些紧急情况下,对已投产系统需要在没有完整的系统测试,或无法完成正式审批流程的情况下进行的变更。如:因系统缺陷需要对已投产系统进行立即修补,或突发的监管要求对已投产系统进行紧急变更(如利率的紧急调整)。

第二十三条 紧急变更应由变更申请部门相关负责人提出,获得IT运行维护中心负责人的审批或者授权方可进行。可以接受的审批方式或者授权是IT运行维护中心负责人的口头授权或邮件授权等,并在紧急变更实施之后,补足相应的《已投产系统变更流程单》并由相关负责人员签字,进行备案。

第二十四条

在紧急变更实施前,须进行测试。紧急变更前未能实现测试的,须事后补足相应的测试及测试文档,并由相关测试人员签字。

第二十五条

紧急变更应记录日志,由IT运行维护中心和变更申请部门共同审核和签字确认,并进行程序和数据备份,以便必要时可以恢复到原来的程序版本和数据版本。

第二十六条

变更实施后,IT运行维护中心组织IT其他相关部门(IT软件开发中心、安全科等)对变更实施的结果进行定期集中评估,主要应从以下几个方面对变更实施的情况进行总结:

(一)(二)(三)(四)施;

(五)变更回退的数量及其原因。

《已投产系统变更流程单》填写完整后由IT运行维护中心进行整变更是否达到预期目标; 变更是否存在负面影响;

一段时期内实施的变更数量(包括总量以及按变更类型分类的数量); 变更以及变更请求的理由清单和类型分析、以及未来控制变更数量的跟进措第二十七条

理,并由IT部门负责人安排人员进行定期审阅,最终交IT综合科归档。

第四章 软件上线流程和控制要求

第二十八条 上线受理(一)项目开发和测试工作完成后,项目组提交《软件产品上线申请表》附件2和相关业务部门负责人签署意见的《用户测试验收报告》给项目管理科进行审核。

(二)项目管理科审核通过后,将上线申请材料交科技信息部安全科及科技信息部负责人审核。审核后在上线申请书上写明上线意见并签名盖章。

第二十九条(一)上线准备

项目组提交通过审核的上线材料给运行维护中心。运行维护中心配合项目组制定上线实施计划,项目经理提交部门负责人进行审批,上线实施计划的主要内容包括:

1.历史数据、配置参数、应用程序等的备份方案

2.上线环境的搭建(项目经理协调运行中心搭建生产环境)

3.上线执行的内容和步骤、各项工作任务责任人、人员组织和具体时间安排等 4.上线回退计划

5.确定上线时可能出现的问题及解决方案(二)项目组配合业务主管部门编写项目上线后的业务管理办法和操作细则,完成相应的培训工作。对新项目,要求相关业务部门提供相关核算办法、管理办法、下发文件。

(三)项目组向系统应用维护人员提供维护手册;向后台操作人员提供操作手册,并完成相应的培训工作。

(四)项目组提交《软件版本管理表》给版本管理部门,完成上线版本的制作。

第三十条

上线与试运行

系统切换发布按照上线实施计划步骤进行;

(一)安全科负责检查项目的安全性,是否符合国家和上级单位的有关安全规定;(二)生产系统版本管理员在程序正式迁移至主机之前,首先完成生产系统的备份,对上线所涉及的程序进行新老版本比对,同时根据上线步骤所定的时点完成程序的编译,制作新版本,并使新程序生效;

(三)系统管理管理员根据上线步骤所定的时点,负责对数据库进行新增、修改、删除等维护工作;(四)系统管理员根据上线步骤所定的时点,提供所需的系统资源、定义系统参数、定义各类文件;并做好基础资料建档;

(五)网络通讯技术人员根据上线步骤所定的时点,负责网络通讯有关参数的设置,将通讯接口切换到生产系统;并做好基础资料建档;

(六)前台版本管理员根据上线步骤所定的时点,负责下发新的前台版本至各支行、网点,并跟踪各支行、网点的版本安装和生效情况;

(七)前置机系统技术人员根据上线步骤所定的时点,负责变更前置机系统的程序版本、数据库信息等,并负责与主机的交易联动;

(八)项目建设部门、各相关业务部门配合系统切换上线的具体实施;

(九)对于只涉及主机日终批处理程序变更的应用项目,在上线当日及相应关键日期(如月终、结息日等)的批处理时段,批处理技术人员应提供技术支持,并负责跟踪试运行的结果;

(十)对于只涉及前台版本更新的应用项目,在上线后下一个营业日及关键日期(如下一个对公营业日等)的联机时段,前台技术人员负责跟踪试运行的结果;

(十一)对于只涉及主机联机交易变更的应用项目,在上线后下一个营业日及关键日期的联机时段,相关主机技术人员应提供技术支持,并负责跟踪试运行的结果;

(十二)对于同时涉及主机联机交易、前台版本和/或前置机版本改动的应用项目,在上线后下一个营业日及关键日期的联机时段,相关主机技术人员、前台技术人员、主机接口术人员及前置机系统技术人员应提供技术支持,并负责跟踪试运行的结果;

(十三)(十四)试运行中发现问题时通知项目组技术人员对系统进行修改;

系统上线后,项目组还需要在上线后为用户提供一段时间的上线后支持服务,对系统运行状态进行监控,保证系统在使用后能够有一个稳定、良好的状态。在此期间,运行维护中心在项目组的指导下执行系统的日常维护和批处理。

第三十一条 上线运行(一)项目系统上线试运行3个月以后,根据试运行情况,项目组提交项目正式上线验收申请报告;

(二)(三)科技信息部审核并确认验收报告及相关项目资料后,牵头组织验收; 经验收合格后的项目转正式运行,运行维护管理由运行维护中心按《IT运行维护指引》要求进行管理。

第五章 系统发布流程和控制要点

第三十二条

系统发布申请

系统项目组实施和测试工作完成后,项目组提交《系统发布申请表》(附件4)和相关业务部门负责人签署意见的《系统测试验收报告》给项目管理科进行审核。项目管理科审核通过后,将系统申请材料交科技信息部安全科及科技信息部负责人审核。审核后在发布申请书上写明意见并签名盖章。

第三十三条

系统发布准备(一)项目组提交通过审核的发布材料给运行维护中心。运行维护中心配合项目组制定系统发布计划,项目经理提交部门负责人进行审批,发布计划的主要内容包括:

1.所涉及系统的历史数据、配置参数、应用程序等的备份方案;

2.系统发布执行的内容和步骤、各项工作任务责任人、人员组织和具体时间安排等; 3.回退计划;

4.确定发布时可能出现的问题及解决方案;(二)项目组配合业务主管部门编写系统发布后的的系统管理办法和操作细则,完成相应的培训工作。

(三)项目组向系统维护人员提供维护手册;向操作人员提供操作手册,并完成相应的培训工作。

第三十四条

系统发布及试运行

(一)系统更新或者发布按照发布实施计划步骤进行;(二)科技信息部安全科负责检查项目系统的安全性,是否符合国家和上级单位的有关安全规定;

(三)运行维护中心系统管理员首先完成相关系统的数据或配置等备份;

(四)运行维护中心网络管理员根据发布计划所定的时点,负责涉及系统的网络通讯有关参数的设置,将通讯接口切换到发布系统;并做好基础资料建档;

(五)项目建设部门、各相关业务部门配合系统发布及运行的具体实施;(六)运行维护中心在试运行期间中发现问题时通知该系统项目组技术人员对系统涉及的产品进行修改;

(七)系统发布后,项目组还需要在发布后为用户提供一段时间的支持服务,配合运行维护中心人员对系统运行状态进行监控,保证系统在使用后能够有一个稳定、良好的状态。

第三十五条 系统发布运行(一)申请报告;

(二)(三)科技信息部审核并确认验收报告及相关项目资料后,牵头组织验收; 经验收合格后的系统转正式运行,运行维护管理由运行维护中心按《IT运行维系统发布试运行3个月以后,根据试运行情况,系统项目组提交项目正式验收护指引》要求进行管理。

第六章 检查监督

第三十六条 检察监督

(一)科技信息部版本管理员在系统切换发布前对系统切换发布的版本进行检查控制;

(二)科技信息部系统管理员在系统更变和发布前对系统进行检查控制;(三)科技信息部每季度对项目文档的完整性、规范性进行检查监督;(四)科技信息部安全科至少每季度进行一次检查。

第七章 附 则 第三十七条 第三十八条 本管理办法由科技信息部负责解释和修订。

本管理办法自发布之日起施行。

篇2:信息系统变更和发布管理办法

第一章 总 则

第一条 目的:本管理办法规定了我区信息系统的变更和发布管理,变更和发布管理作业操作流程和控制要点,确保变更需求的受理符合业务的优先需要,并使变更和发布过程规范化,控制变更对银行业务和已投产系统安全运行的不利影响。达到降低信息系统变更和发布风险的目的。保障信息系统的安全稳定运行,特制定本管理办法。第二条 依据:本管理办法根据《高新区信息安全管理策略》制订。第三条 范围:本管理办法适用于我区信息系统变更和发布管理。第四条 定义

(一)软件产品:泛指信息技术开发的生产业务系统和管理信息系统等应用软件项目。

(二)生产业务系统:指我区从事金融服务的应用网络系统。

(三)管理信息系统:指我区信息管理的计算机网络系统,具体指OA办公系统、信贷管理、报表系统等用来进行内部管理的应用软件系统。

(四)业务部门:指我区相关业务部门。

第五条 遵循原则

(五)监督制约原则:针对信息系统变更和发布管理工作中各个环节,建立相应的监督检查机制。

(六)计划性原则:信息系统发布应纳入每年计算机应用计划,确保全行计算机系统资源、应用环境、维护力量、操作技能能满足系统安全、可靠运行的要求。

(七)可行性原则:具有普遍适用性和可操作性。(八)风险控制原则:

若为新项目或新业务功能变更和发布,需进行以下风险分析: 1.备份机建设情况;

2.应用系统投产后的集中监控方案; 3.生产数据备份方案; 4.程序及系统备份方案;

5.数据库建库/建表/建索引方式等; 6.对其他系统的影响。

第二章 组织与管理

第六条 职责划分(一)需求部门:

1.提出需求,并确认《用户需求说明书》;

2.用户测试阶段确认用户测试计划、记录用户测试问题、确认用户测试报告;

3.接受用户培训并提出反馈。

(二)信息化管理与服务中心:

1.在需求阶段审阅和提出风险控制、合规和稽核方面的要求,在项目开发阶段对有关风险控制、合规和稽核方面的测试结果进行审阅;

2.在项目实施后审阅阶段对有关风险控制、合规和稽核要求的实施效果进行审阅。

3.负责受理所有变更和发布需求,会同其他相关部门对变更和发布需求进行评估,并将评估意见向部门领导汇报;

4.在详细设计阶段审阅和提出网络、硬件、操作系统和数据库等方面的配置和容量要求;

5.在设计与编程阶段提供网络、硬件、操作系统和数据库的参数配置; 6.在测试阶段配合项目组设立网络、硬件、操作系统和数据库环境; 7.配合对系统进行联合测试,把信息系统版本软件、相关配置文件、标准数据和相关文档提供给信息化管理与服务中心;

8.将信息系统发布到使用部门,系统上线时会同项目组搭建生产系统并进行程序移植,组织定期对变更和发布效果进行分析和总结。

9.接收管理和备份软件开发中心提供的源程序、相关标准数据、配置文件、相关文档;

10.负责设计、编程、纠错和开发质量控制,编制《系统设计规格书》; 11.落实项目管理制度和业务操作手册的编制工作,参加制定上线方案制定,编制《上线实施计划》;

12.负责系统切换上线的技术支持工作;

13.负责项目验收资料整理汇总,配合项目验收工作。14.负责对需要测试评估的软件进行分析测试; 15.负责提交测试分析报告。

第三章 信息系统变更

第七条 信息系统变更,指由于新增信息系统功能、系统逻辑改变、系统错误修正、系统补丁安装及版本更新、系统配置修改及业务参数修改等原因,而对已投产系统进行局部改变的一切活动。已投产系统变更需求主要来源于以下几种情况:

(一)由于业务快速发展,业务部门对现有已投产系统的功能或设置进行变更或通过新增功能来满足需求;

(二)用户在使用过程中发生的一些操作错误,或技术人员、监控管理软件自动发现的故障或事件,需要通过安装程序补丁或修改配置等操作进行修改;

(三)厂商定期发布的系统补丁,涉及系统的功能、性能、安全漏洞,需要在已投产系统中进行安装;

(四)由于系统容量扩充或与已投产系统存在数据交换或数据共享的其他已投产系统发生变化后引发的已投产系统变更。

第八条 信息系统变更的提出,必须由申请部门填写《系统变更流程单》(附件1)第一部分,申请信息。在申请信息填写阶段的主要工作内容包括:

(一)申请人需选择变更类型;

(二)描述变更内容和目的;

(三)是否存在其他措施满足变更需求;

(四)如不实施变更可能对客户、合规、外部利益相关方、内部管理和操作、安全控制、系统可用性和数据准确性的影响;

(五)选择变更的急迫性。

第九条 申请部门主管审批签字后提交信息化管理与服务中心进行处理。第十条 信息化管理与服务中心收到变更申请后,和变更申请部门充分沟通,理解变更需求的合理性,审阅变更的影响和急迫性,并会同其他相关部门对可行的变更实施方案和变更对已投产系统的影响做出评估,最终形成建议的变更日期,填写至《系统变更流程单》第二部分,变更需求评估信息,交信息化管理与服务中心负责人进行审批。

第十一条 信息化管理与服务中心组织变更需求评估时,应充分考虑系统是否已存在满足变更需求的功能或设置;是否存在其他操作手段,能达到同样的变更需求效果。

第十二条 信息化管理与服务中心组织变更需求评估时,了解实施变更:(一)是否需要进行开发,以及开发的工时;

(二)是否需要进行操作系统、数据库系统、中间件、硬件和网络的变更;(三)是否需要进行后台数据变更;(四)是否存在信息安全控制的考虑因素;

(五)结合信息化管理与服务中心现有的资源,统筹安排变更实施时间表;

(六)实施相关变更时,可能导致的业务中断或服务水平下降。

第十三条 综合对变更需求合理性的评估和变更实施影响的评估,信息化管理与服务中心在《系统变更流程单》的第二部分提出变更的建议日期,并进行资源协调。在信息化管理与服务中心负责人进行审批后,通知相关部门:

(一)如不建议实施变更,则向变更申请部门说明理由;

(二)如建议实施变更,则告知建议变更的时间及对客户服务和内部操作的影响,要求变更申请部门和相关部门进行准备;

第十四条 对涉及软件开发的需求变更,向信息化管理与服务中心提出申请。

第十五条 对不涉及软件开发的需求变更,信息化管理与服务中心根据需要,提交信息化管理与服务中心相关人员负责制定变更的测试步骤,落实测试人员在测试环境中对变更进行测试,测试人员对测试结果进行记录并签字确认。

第十六条 信息安全人员对变更进行上线前审阅,确保系统变更过程中的系统安全。信息安全人员完成上线前审阅后,信息化管理与服务中心进行上线处理。信息安全人员根据变更的风险程度,进行上线后审阅,确保达到变更目标。

第十七条 为控制已投产系统的变更对客户服务和业务操作带来的影响,确保生产环境的完整性和可靠性,信息化管理与服务中心应制定一系列控制变更的策略和制度,严格控制变更的规模、涉及面及信息安全风险。包括:

(一)信息化管理与服务中心负责人每周对集中的变更工作计划进行审阅,确保充分有效的技术资源或系统供应商/开发商技术资源,保证变更的有序进行;

(二)除非是需要立即实施的特急变更,信息化管理与服务中心应选择非业务繁忙时间,如凌晨、周末或公众假期进行变更上线;

(三)信息化管理与服务中心进行周密计划,包括制定意外应急措施;(四)分离已投产系统与开发或测试系统的管理职责;

(五)保证已投产系统和开发或者测试系统相分离,禁止开发人员在未经授权的情况下进入已投产系统;

(六)只有在得到管理层批准执行紧急修复任务时,开发人员才能访问已投产系统,所有的紧急修复活动都应立即进行记录和审核;

(七)开发人员对已投产系统进行变更必须经过严格的审批和控制;开发人员访问已投产系统时必须由信息化管理与服务中心系统管理员对其访问进行监督和记录,并在访问结束后系统管理员及时禁用或删除开发人员在已投产系统中使用的账号;

(八)对已投产系统进行变更必须经过严格的授权之后才能进行操作实施,操作实施过程必须受到严格监控。

第十八条 变更实施上线前需进行用户测试,并在变更上线后由变更申请部门负责人对变更进行签字确认。

第十九条 对于上线过程可能导致业务暂时中断或导致业务操作发生重大变化的变更,信息化管理与服务中心必须在上线前以书面方式告知相关业务部门影响的业务范围和时间,并提供相关技术支持。

第二十条 变更上线执行的工作内容和相关要求进行。

第二十一条 变更计划与步骤、回退计划与步骤、测试步骤与结果、信息安全审阅意见、用户测试确认等变更实施信息记录在《系统变更流程单》第三部分,变更计划和测试接受信息。信息化管理与服务中心负责人负责对变更实施信息进行审阅。

第二十二条

急变更是指在某些紧急情况下,对已投产系统需要在没有完整的系统测试,或无法完成正式审批流程的情况下进行的变更。如:因系统缺陷需要对已投产系统进行立即修补,或突发的监管要求对已投产系统进行紧急变更。

第二十三条

紧急变更应由变更申请部门相关负责人提出,获得信息化管理与服务中心负责人的审批或者授权方可进行。可以接受的审批方式或者授权是信息化管理与服务中心负责人的口头授权或邮件授权等,并在紧急变更实施之后,补足相应的《系统变更流程单》并由相关负责人员签字,进行备案。

第二十四条

在紧急变更实施前,须进行测试。紧急变更前未能实现测试的,须事后补足相应的测试及测试文档,并由相关测试人员签字。

第二十五条

紧急变更应记录日志,由信息化管理与服务中心和变更申请部门共同审核和签字确认,并进行程序和数据备份,以便必要时可以恢复到原来的程序版本和数据版本。

第二十六条

变更实施后,信息化管理与服务中心组织其他相关部门对变更实施的结果进行定期集中评估,主要应从以下几个方面对变更实施的情况进行总结:

(一)变更是否达到预期目标;(二)变更是否存在负面影响;

(三)一段时期内实施的变更数量(包括总量以及按变更类型分类的数量);(四)变更以及变更请求的理由清单和类型分析、以及未来控制变更数量的跟进措施;

(五)变更回退的数量及其原因。

第二十七条

《系统变更流程单》填写完整后由信息化管理与服务中心进行整理,并由信息化管理与服务中心负责人安排人员进行定期审阅,最终交信息化管理与服务中心归档。

第四章 检查监督

第二十八条

检察监督

(一)信息化管理与服务中心管理员在系统切换发布前对系统切换发布的版本进行检查控制;

(二)信息化管理与服务中心系统管理员在系统更变和发布前对系统进行检查控制;

(三)信息化管理与服务中心每季度对项目文档的完整性、规范性进行检查监督;

(四)信息化管理与服务中心安全科至少每季度进行一次检查。

第五章 附 则

篇3:论信息系统项目变更管理

传统的检验检疫监管方式, 以书面申报、现场检验检疫、书面通知放行等形式为主, 而通过电子视频监控和电子数据监控的有机结合和相互印证, 提高了检验检疫有效性, 节约了企业成本。本项目工程量大, 涉及监管企业多、监控关键点及流程各不相同, 从人工处理模式转变为信息化处理模式。工作人员要求多变, 导致实施过程中需求几经变更。在这种情况下采取以下几方面措施对项目变更进行有效管理尤为重要。

1 选择有效的配置管理工具, 制定配置管理计划

在初始阶段制定项目计划时, PM选择了配置管理工具, 制定了配置管理计划。选择了Hansky工具, 它包括配置管理工具Firefly、变更管理工具Butterfly和需求管理工具Dragonfly。Hansky可以在不同的网络环境中使用并完成各种配置管理工作。在配置管理计划中, 项目组着重制定了变更控制流程, 并与甲方通过会议形式讨论, 最终达成对变更控制流程的一致意见, 由CCB负责人签字认可。除制定配置管理计划外, 还通过hansky统一了变更管理文档的模板, 所有变更均需要使用此模板, 便于识别与管理。

2 启用动态的多层的变更控制委员会 (CCB)

在项目初期, 项目组启用动态的多层的变更控制委员会 (CCB) 。CCB由PM、用户代表、业务专家、质量管理员、配置管理员、系统总设设计师、测试组长组成, 加入人员不固定, 根据变更性质及涉及的部门进行调整。

对于设计文档、核心模块关键代码、关键测试用例等由开发人员或系统集成员提出的变更需求, 由SCCB (软件变更控制委员会) 审核并决定是否批准, 配置管理员根据SCCB的决定临时开放相应的权限, 并备案。为此, PM做了如下规定:处于工作状态的产品开发人员可对其修改, 而作为基线进入配置库的产品, 则不允许开发人员对其进行修改。对于设计文档变更首先要做同行评审, 评审内容一般是文档的规范性以及是否符合需求分析的要求, 同行评审后由系统总设计师来做专家评审, 评审的内容是设计是否符合业务需求。核心模块关键代码的变更需要通过同行评审, 评审内容是代码的编写是否符合编码规范、是否具有可读性和可维护性, 检查代码是否正确完成设计要点、有没有理解错误。关键测试用例的变更由测试组长审核, 审核测试用例的数据是否典型, 某些特定的测试数据需要与客户代表进行协商。

而对于客户提出的需求变更, 为了防止出现变更信息不一致的现象, 项目组采用“窗口机制”, 即双方规定特定的人全权负责客户变更接口, 未经此两人确认的变更视为无效变更。“窗口”负责人先对客户提交的变更内容进行分析, 形成分析报告再提交给PM。PM根据报告决定临时CCB人选, 必要时还将邀请电子监控行业技术专家、业务专家及甲方领导进行联合评审, 并将评审专家意见以会议纪要的形式及时发布在检验检疫局内部网站上。将评审专家意见同时递交至项目组, 执行变更, 并再次测试, 无误后建立基线, 发布新版本。

3 规范变更控制流程

软件开发项目, 无控制的变更将迅速导致混乱, 变更须是有序的、可控的, 必须制定计划使变更对成本、工期和质量的影响降到最小。在本项目中, 由项目组提出变更控制流程初稿, 交公司高层及甲方联合讨论修改, 形成共识, 最终CCB审核通过。该变更控制流程确定了所有变更都要遵循变更请求, 受理变更, 变更方案讨论, 变更控制委员会审查, 发布变更通知并开始实施, 变更实施监控, 变更效果评估, 判断变更是否已纳入正常轨道的步骤。

在本项目建设初期, 甲方觉得需要将重点敏感进出口商品的生产加工企业等纳入电子视频监管的范围, 这个功能起初不在项目范围之内的, 增加该功能项目进度和范围严重受到影响, 用赶工等方式, 项目的质量又会大打折扣, 于是通过变更控制委员会 (CCB) 和使用变更控制系统, 来决定是否实施这个客户需求变更。

首先, 要求通过“窗口机制”甲方接口人确定这个变更需求, 并填写变更申请表, 提交项目组方“窗口”接口人。接口人先对变更内容进行分析形成分析报告, 提交给PM初审并进行备案。

其次, PM根据分析报告, 决定临时变更控制委员会组成人员, 在会议上与相关项目组成员一起分析, 得出最终变更方案, 提交CCB最终评价。CCB收到变更方案后, 开会对此方案进行讨论。估算了实现变更需要的人力、时间和增加的成本, 由于影响较大, 否决了这个变更请求。

最后, 如果CCB批准这个变更请求, 根据变更产生的影响程度, 适当调整项目的进度和成本基线。并通知相关干系人。同时通过Hansky下达变更指令, 实施变更。并要求做好变更记录, 对变更实施进行监控。在变更处理完成后, CCB对变更实际引起的影响进行分析评估, 得出经验教训。经测试通过, 及时更新和发布版本。

通过有效的变更控制流程以及耐心的解释, 甲方终于同意不增加重点敏感进出口商品的生产加工企业等纳入电子视频监管的范围, 在甲方领导申请后, 敏感进出口商品的生产加工企业监管计划作为第二期项目上线, 并给予资金和时间上的支持。

4 结语

“全球眼”在建设和使用过程中, 运行稳定, 效果良好, 先后通过国家质检总局多位领导的审查, 他们对该公司提供的“全球眼”视频业务在检验检疫、把好国门中所发挥的提速、减负、增效、严密监管作用表示肯定。正是由于在“全球眼”信息系统项目的建设中良好的变更管理, 才能保证项目如期按质完成。

摘要:笔者以自己参与过的某大型综合性信息化建设系统为例, 探讨了信息系统项目的变更管理, 指出项目变更管理在信息系统项目实施中具有重要地位和关键作用。在项目实施过程中, 综合运用项目管理理论、技术并结合实际项目情况采取措施对变更进行有效管理, 控制好项目实施过程中出现的各种变更, 保证了项目质量、进度、成本, 完成项目预定目标。

篇4:信息系统变更和发布管理办法

作为中国-荷兰企业社会责任项目第二期的核心成果,这项可在线应用的企业社会责任绩效衡量与信息披露系统已搭建完成,进入测试运行阶段,可为政府部门、行业协会和各类企业,提供社会责任绩效、透明度和公众口碑的自我评测及对比分析。

3大核心模块 325个三级指标

该系统由三大核心模块组成:指标体系、指数模型和口碑监测。在此基础上,系统开发了五个主要的应用系统,包括信息采集、信息管理、指数评价、口碑监测及交流展示。

指标体系模块以GRI可持续发展报告框架为主要参考依据而设计,同时吸收了国内研究机构和各行业协会发布的指南,涵盖公司治理、经济责任、环境责任、员工责任、人权责任、社会责任和产品与服务等7个一级指标,下设49个二级指标以及325个三级指标。

绩效指数模型在指标体系已有的325个三级指标基础上,选取25个有较好的代表性和数据可获得性的指标作为核心计算指标。

口碑监测模块运用网络智能抓取技术,通过设置行业、地区、企业以及社会责任指标分类的关键词,分析从互联网公开渠道获取的大量有关企业社会责任的动态信息,实现实时监测目标企业、地区和行业的社会责任口碑状况,自动判断和分析其对企业、地区和行业的正负面影响。

在线应用 面向三类核心用户群

企业、行业主管机构和协会、各地政府,这是上述系统的三个核心用户群。用户可以登陆在线监测和评价系统,按照提示逐项完成,整个使用过程简洁、高校。

对企业用户而言,系统的主要价值在于四个方面:进行社会责任绩效的自我评测与标杆比对,为绩效改进提供依据;了解和掌握潜在供应商和合作伙伴的社会责任状况,防范供应链责任风险;实时监控社会口碑,有效优化公众形象;与同行交流履责经验,提高实践水平。

对行业主管部门和协会来说,通过本系统提供的行业间、行业内地区间、行业内不同指标属性乃至具体企业间的社会责任指数分析,用户可以了解本行业与其他行业的对标状况,还可以监测本行业社会责任相关的舆论动态和社会影响,从而制定清晰有效的社会责任推进战略,树立示范区域和标杆企业,引导行业履责水平持续提升。

从地方政府部门的角度,用户可以了解本地区与其他地区相比,在社会责任表现上的优点和弱点,掌握本地区不同行业间的社会责任绩效和透明度对比状况,了解本地区内优秀的社会责任实践企业,监测本地区社会责任有关舆论动向,以便制定有效的地方政策,引导和推进本地区的社会责任实践,防范社会责任风险。

篇5:变更管理办法(发布)

第一章

总 则

第一条 为加强中国石油管道建设项目经理部(以下简称项目经理部)项目变更管理,依法合规处理项目变更,规范项目变更管控过程,提高变更审批效率,实现工程投资、工期和质量等管理目标,特修订本办法。

第二条 本办法适用于项目经理部承建的油气管道建设项目变更管理工作。

第三条 项目变更管理遵循事前预控、严格限制、尊重设计、一事一议、保持合同严肃性的基本原则,项目变更管理采取分级、分类的管理方式。

第二章

术语解释及变更分类

第四条 项目变更是指由于项目环境或其他原因,对已批复用于工程建设的规范标准、设计文件、施工方案的调整,或是对合同约定事项的调整。项目变更包括设计变更、施工变更、合同变更,设计变更和施工变更统称为工程变更。

(一)设计变更是指对已批复使用设计方案、标准规范的变更,设计变更主要可划分为可行性研究变更、初步 1

设计变更和施工图设计变更,承包商依照批复的设计方案和设计变更完成工程实体建设。

可行性研究变更和初步设计变更,是指在可行性研究报告或初步设计报告批复后,由于项目资源、市场、功能、范围、方案、地方规划、投资等发生重大变化,需修改已批复的可行性研究方案或初步设计方案,并通过地区公司报股份公司批准的变更。

(二)施工变更是指在施工过程中对合同约定的或经批准的施工方案、施工工艺、施工组织设计等的变更。

(三)合同变更是指项目经理部与合同相对人对于已签订合同条款的调整和修改,对于合同中约定延期服务、工程量增加等条款的执行,不属于合同变更。合同变更按《合同管理办法》规定执行。

第五条 变更提出方的变更分类

(一)股份公司提出的变更。

(二)地区公司提出的变更。

(三)调控中心等中石油内部单位提出的变更。

(四)项目经理部各处室及项目部提出的变更。

(五)初步设计服务商提出的变更。

(六)承包商提交的变更:

1.实施阶段工程EPC/PC承包商接收的地方政府、公路、沿线群众、铁路、河流、电力、军队等中石油外部单位提出变更要求,工程范围调整导致的变更;

2.实施阶段EPC/PC承包商根据现行法规、条例要求及详细勘察情况,采取合理工程方案造成的施工方式调整或工程实体功能、结构变更。

(七)地方政府、公路、铁路、河流、电力、军队等中石油外部单位提出的变更。

第三章 管理部门及职责

第六条 计划处是项目变更的综合协调部门,变更管理职责如下:

(一)负责项目变更管理办法的编制、修订和解释。

(二)接收股份公司或地区公司提出的设计变更、变更批复,发布变更通知,统一安排变更实施计划和相应的投资控制指标。负责项目变更管理办法的编制、修订和解释

(三)根据工程技术处审核确定的变更方案,在初步设计编制阶段,共同向地区公司提交对批复可研的变更申请;在项目实施阶段,向地区公司提交对批复初设的变更申请。

(四)接收业务处室及项目部提出的变更,组织协调相关业务处室进行变更审查,并提出审查意见;对工程技术处、工程管理处、项目部明确的线路管材数据调整意见进行分析,明确最终执行意见。

(五)组织建立各项目变更管理台账(附表6、7),组织变更审查会,跟踪落实会议安排和要求。

第七条 造价与法律事务处是合同变更管理,及变更费用审查、结算的管理部门,变更管理职责如下:

(一)根据合同约定、定额及有关规定,对承包商和服务商提出的变更费用进行复审。

(二)根据变更工程量确认表,以及变更审批单确定的变更费用,进行变更结算。

(三)负责合同工程报价内容的界定,明确变更费用的计价原则。

第八条 工程管理处变更管理职责如下:

(一)负责审查项目变更的施工可行性和对施工组织影响,包括变更引起的工序改变、施工工艺调整、重大施工方案调整等,审查承包商提出变更工程量的合理性,分析项目变更对工期的影响。

(二)界定项目变更中施工、投产有关问题涉及承包商的责任,并根据合同条款组织项目部启动索赔。

(三)负责变更引起建设模式调整和承包商的确认,根据规定向招标管理处提出招标需求。

(四)施工图设计完成后,负责组织项目部落实项目实际管材需求及与施工图数据的差异。

(五)负责核实工程变更的实际完成工程量,以及项目变更的竣工资料管理。

第九条 工程技术处变更管理职责如下:

(一)负责组织对批复可研方案的变更申请,落实批复可研调整后初步设计调整工作。组织审核变更设计方案,提出审查意见。

(二)对于批复初步设计后的变更,组织初步设计服务商按照要求编制变更方案和概算,审查变更设计方案,提出审查意见。

(三)负责组织分析初步设计批复后,变更对专项评价的影响,组织开展补充评价。

(四)组织审查承包商提出的施工图设计变更方案。第十条 质量安全环保处变更管理职责如下:

(一)分析变更对已批复除工程技术处负责外的环评、安评、职评、水保评价方案、安全设施专篇的影响,提出开展补充评价的意见。

(二)审核变更引起的HSE风险及应对措施方案,提出审核意见。

第十一条 物资采办处变更管理职责如下:

(一)审核变更引起设备、材料的采购到场时间的可满足性,提出和审查变更引起的物资采购、到场时间、费用变化、物资生产与施工需求调整平衡等意见。

(二)对于已经批复实施的工程变更,按照工程技术处提交的设备材料调整数据,组织变更物资的平衡调剂或增订。

(三)组织开展变更增订物资监造工作,负责监控乙供物资变更执行情况。

第十二条 公共关系处变更管理职责如下:

(一)负责进行工程变更项目用地预审的合规性分析。

(二)负责审核工程变更对规划、建设用地、林地、文物保护区等影响。

(三)负责组织工程变更后的用地标准确定、永久用地、林业的征用和补偿等工作。

第十三条 招标管理处负责按照各职能处室的招标需求,组织变更引起的采购招标工作。

第十四条 财务处负责分析变更对工程保险的影响。第十五条 审计监察处参加变更审查会,负责监督变更管理过程的及时性、合规性。

第十六条 项目部代表项目经理部在现场处理项目变更,变更管理职责如下:

(一)组织EPC承包商按批复的初设方案和审批的施工组织设计开展现场工作,严格控制项目变更。

(二)负责现场接收承包商、现场服务商和工程建设相关第三方提出的项目变更申请,组织分析变更的原因、责任,以及对工程建设合规性、现场可行性、工期、费用、设备材料和HSE的影响。

(三)负责按照合同约定处理项目变更,对承包商提交变更的合同允许调价内容进行初步判定,明确审查意见。

(四)负责对同时具备如下条件的项目变更进行审批:不影响工程质量、安全,不影响合同价格调整,不影响工 6

程合同及综合计划工期目标,不影响初步设计方案调整,不影响专项评价,不影响建设用地。

(五)负责建立并定期提交项目变更管理台账。第十七条 项目部、本部处室均有义务根据项目建设环境、条件变化,提出工程变更申请。

第四章 变更管理要求及流程

第十八条 对于项目前期成果的审核和调整。计划处接收项目前期资料后,组织业务处室和项目部根据职责分工,对前期资料进行审查,针对批复可研方案与专项评价、用地预审、路由规划等不一致内容提出审查意见;计划处梳理汇总后,提交地区公司开展补充评价或修订可研方案。

第十九条 对批复可研方案的变更。在初步设计编制过程中,针对已批复可研方案,包括设计方案、线路路由、站场/阀室选址等的变化,工程技术处组织初步设计服务商提出调整方案,以及变更依据、对投资、工期和专项评价的影响,形成申请报告,经计划处会签后提交地区公司;在与地区公司达成共识后,开展相应初步设计工作;对于没有形成共识、无法按原可研方案实施的工作,提交股份公司前期工作衔接会,按会议安排开展相应初步设计工作。

工程技术处组织初步设计咨询商将补充评价要求落实到初步设计方案中。

第二十条

工程变更审查会

计划处组织造价与法律事务处、工程管理处、工程技术处、质量安全环保处、公共关系处、物资采办处、财务处、审计监察处等处室参加工程变更审查会。会议主要对工程建设实施期间的工程变更进行审查评估,各业务处室根据部门职责分工,讨论分析变更的合法合规性、变更原因、变更责任、变更方案合理性、可行性,以及对工期、费用、专项评价的影响等,审议确定需提交地区公司审查并报股份公司批准的变更,以及需要报投资管理委员会批复的项目变更。

在工程变更审查会7个工作日前,计划处向业务处室提供工程变更申请资料,在会议2个工作日前,业务处室将审查意见提交计划处组织上会。如相应处室书面意见未明确,工程变更会取消。

工程变更审查会每两周召开一次,由计划处编写会议纪要,参会处室汇签,主管领导签发。对于单项变更费用增加费用200万元及以上的(不包括需提交地区公司审查并报股份公司批准的变更),提交投资管理委员会审批。

第二十一条 对于集团公司、股份公司提出变更的处理。集团公司关于工程建设规模、工程建设范围、工艺技术方案、工程建设标准等方面提出的变更,计划处接到变更通知后,组织工程技术处、工程管理处、物资采办处、质量安全环保处、公共关系处,按职责分工进行分析后,发布变更通知。对于工程变更审查会审议后确认现场无法实施的变更,业务处室提交原因说明,计划处拟函报告。

(一)计划处发布变更通知,明确投资渠道和费用确定原则,提出设计、采购、用地、施工、补充评价等业务活动的综合计划安排。

(二)工程技术处组织初步设计服务商编制变更技术方案(含投资),并组织该项目原专项评价单位开展补充评价,相应费用增加按原合同约定执行。

(三)物资采办处根据工程技术处提交的数据单,组织剩余物资的平衡使用后,再在原采购合同基础上增订物资,对于需要重新招标采购的物资,执行《招标管理办法》。

(四)工程管理处、造价与法律事务处、项目部按照原工程建设承包和服务合同约定,启动相应调整工作,项目部组织现场实施。

(五)公共关系处安排建设用地、林地、文物等方面等相关工作。

(六)质量安全环保处分析变更对环评、安全、水保、职评等方面影响和HSE风险,提出是否补充评价。

(七)对于不承担变更工作内容的原承包商或服务商,业务处室在执行合同约定条款的同时,通过谈判或招标选择新的承包商或服务商。

(八)各业务处室梳理按原批复方案已经开展工作、采购物资和发生的费用,提出处理意见,形成报告提交计划处,计划处统一报告股份公司。

第二十二条 对于北京调控中心、地区公司等中石油单位提出变更的处理。计划处接收北京调控中心、地区公司 9

等中石油单位提出的设计变更要求后,提交工程变更审查会审议。

(一)对于不需要股份公司批复,经分析后同意实施的设计变更,业务处室按与承包商和服务商的原合同约定,组织开展相关工作,工程技术处分析设计原因和责任。

(二)对于需要股份公司批复的设计变更,业务处室提交原因说明,计划处致函北京调控中心或地区公司,在取得股份公司批复后执行。对于需要初步设计服务商编制设计变更方案的,工程技术处按照地区公司要求做好安排和配合。

(三)现场项目部不接收地区公司未经项目经理部各处室确认的变更通知。如地区公司现场派驻机构提出变更要求,项目部应向其明确需由其上报该上级单位,由相应地区公司与项目经理部联系变更事宜。

第二十三条 对于项目经理部处室和项目部提出变更的处理。业务部门提交计划处,在工程变更审查会审议。

(一)对于不需要股份公司批复,经分析后同意实施的设计变更或施工变更,业务处室按与承包商和服务商的原合同约定,组织开展相关工作,工程技术处分析设计原因和责任,工程管理处分析施工原因和责任。

(二)对于需要股份公司批复的设计变更,工程技术处分析设计原因和责任,并组织初步设计服务商编制设计变更方案(含费用),经工程技术处审查设计方案、计划 10

处审查投资后,计划处致函地区公司,在取得股份公司批复后执行。

第二十四条 对于初步设计服务商提出变更的处理。工程技术处组织审查设计变更方案,并分析初步设计服务商责任。

(一)对于不需要股份公司批复,经分析后同意实施的设计变更,业务处室按与承包商和服务商的原合同约定,组织开展相关工作。

(二)对于需要股份公司批复的设计变更,计划处审查变更费用,并致函地区公司,在取得股份公司批复后执行。

第二十五条 EPC承包商应严格按照初步设计批复方案组织开展施工图设计,严格按照经批准的施工图设计、经批复的“施工组织设计组织”施工。对于EPC承包商提交的工程变更。

(一)承包商编制书面变更申请单及变更材料(包括电子版),具体见附表1至附表5,提交工程监理审查,工程监理结合现场实际,针对变更依据、变更方案(设计或施工)、变更工程量、调整费用、对工期、专项评价、质量安全等影响内容进行全面审查,对照项目经理部与EPC承包商合同约定,提出处理意见,报项目部审查。

(二)项目部对通过工程监理审查的工程变更进行复审,对于材料不完整、依据不充分、不同意实施的变更予以退回;对于处理权限内的变更进行审批,审批后及时组 11

织存档,同时提交计划处备案;对于需要提交工程变更审查会审查的变更,通过工程OA系统提交计划处(涉密资料按照涉密管理规定执行,相关方案可单独上报)组织审查。

(三)计划处对项目部提交的工程变更进行初审,对于上报材料不满足下步审查要求的项目变更予以退回。计划处初审后,在变更审查会一周前,发送至相关处室提前审查;业务处室按照职责分工,在工程变更审查会上提出审查意见。

(四)按照会议审查内容,计划处形成工程变更审查意见。

(五)对于不需要股份公司批复,经分析后同意实施的设计变更或施工变更,业务处室按与承包商和服务商的原合同约定,组织开展相关工作。

(六)对于需要股份公司批复的设计变更,工程技术处分析设计原因和责任,并组织初步设计服务商编制设计变更方案(含费用),经工程技术处审查设计方案、计划处审查投资后,计划处致函地区公司,在取得股份公司批复后执行。

(七)没有通过变更审查会审查的项目变更,不予实施,变更流程关闭。

第二十六条 对于项目沿线地方政府、公铁路、河流、部队等中石油外部机构或单位提出变更的处理。在工程建设实施期间,上述机构或单位向项目部、EPC承包商提出变更要求。

(一)对于增加分输口、功能调整的变更要求,项目部取得地方政府书面文件,向计划处提出变更需求,经工程变更审查会审议并函交地区公司,在取得股份公司批复后,计划处安排实施。

(二)对于上述机构或单位提出的不能落实线路路由或站址的变更,工程技术处、项目部组织设计服务商取得相关机构或单位的书面意见,经工程变更审查会审议并函交地区公司,在取得股份公司批复后取消。各业务处室梳理按原批复方案已经开展工作、采购物资和发生的费用,提出处理意见,形成报告提交计划处,计划处统一报告股份公司。

(三)对于上述机构或单位提出路由改线、站址改变、设计方案等的变更要求,工程技术处、项目部安排EPC承包商编制设计变更方案,按承包商提出变更的流程组织审查。

第二十七条 工程变更审查要求

服务商提交工程变更材料,须依据充分、时效合理,同步分析工程量与费用变化,界定工程变更与合同关系,体现工程变更对费用、工期等关键因素的影响。工程变更提出部门应对照合同约定条款分析,变更审批意见要明确合同依据条款意见,否则接收部门有权退回。

(一)工程变更合规性审查。工程变更合规性审查包括:变更依据的合理有效性,变更方案用地是否符合用地预审意见,地方主管部门关于是否需要开展补充评价的初 13

步意见,变更费用计价符合合同条款约定。

对于涉及建设用地、林地、文物保护区,变更材料须提供与已批复建设用地、林地、文物保护区真实现状情况。

对于改线、改址、改动穿越方案的变更需取得相关行政环保、防洪、安监、规划等管理部门的明确书面意见。

(二)工程变更方案审查。工程技术处审查设计变更方案,工程管理处审查施工变更方案,变更方案审查包括变更原因分析、方案可行性分析、变更方案比选和变更工程量审查。

涉及对批复施工图或初步设计调整的方案,必须由具备设计资质单位编制设计方案,项目主管经理签字外,须有原设计负责人签字确认。

(三)变更影响工期审查。在承包商变更申请资料中,应详细分析变更对工期的影响,明确对后续工作及其他服务商工作的影响,提出对《项目综合计划管理程序》中要求的紧后里程碑节点计划及工期目标的调整建议。计划处综合平衡各业务部门关于影响工期的审查意见,按《项目综合计划管理程序》要求,纳入综合计划季度或工期目标管理。对于影响工期目标的变更,计划处报上级单位或项目业主审批。

(四)变更费用审查

1.变更费用包括变更事项自身发生的费用及由此引起的相关工作所产生的费用;

2.费用变更审查首先判别变更费用承担主体,判别依据是合同相应条款和变更原因,对由于承包商本身责任造成的工程变更,由承包商承担费用;

3.变更费用计算规则是合同相应条款中费用调价条款;

4.承包商变更申请资料中,应包括变更费用预算,造价与法律事务处对于申请变更费用的审查作为变更的最高限价,变更实际实施后,按现场签证进入工程结算;

5.对于需要股份公司批复的设计变更,造价与法律事务处暂不审查费用;取得股份公司批复后,计划处发布投资控制指标,造价与法律事务处对应合同约定,提出承包商费用审查意见;

6.对于变更减少费用的,承包商应按合同条款提出;对于变更应增加费用,而承包商变更申请资料中未提交费用预算的变更,视为无费用变更。

(五)变更申请资料及审批说明

1.承包商提交变更申请资料时,应填写“变更申请单”,体现变更影响分析结果(附表1至附表5根据说明使用);工程变更资料必须齐全,资料不全不清,视为无效变更。

2.变更申请资料,必须依据充分、时效合规,同步分析费用变化与工程量变化;对于涉及永久用地、林地使用面积的,变更材料必须提供与已批复用地、林地指标的对比分析。

(六)对照合同审查工程变更。EPC承包商在提交的工程变更资料中,应包括对照合同条款关于工程范围、计价依据和责任的相关说明,工程监理、项目部对照项目经理部与EPC承包商的合同约定条款进行审查,明确提出审查意见;工程变更是否引起合同调整,由合同执行单位发起,对于引起的原合同造价调整意见,造价与法律事务处明确。

第二十八条 对于现场紧急变更事项的处理。为避免现场发生安全、质量、环保事故,减少工程经济损失,以及为保证工程按期投产,对于现场需要紧急处理的变更事项,项目部组织相关方形成共识并签署书面意见后,可以作为紧急事项在现场紧急组织实施。EPC承包商和工程监理做好现场记录,在后续提交的变更资料中,除项目部组织的审查材料,还应包括紧急变更事项说明和各方签署意见和变更工程量签证确认单,审查完成后直接进入工程结算。

对于隧道围岩变化、不良地质等变更资料由现场监理证明现场变化属于危及安全须及时处理,并出具书面意见,由监理项目部总监审核确认。对于围岩变化的情况,上报资料中对围岩变化的确认工作,需具有勘察资质的监理或设计单位出具书面围岩鉴定意见。

应急变更包括:

(一)在危及人员和财产安全的紧急情况下,启动应急抢险管理流程,事后履行变更流程;

(二)隧道围岩等级与项目经理部提供的地质勘察资料不一致,工期或质量安全要求及时处理的;

(三)隧道或其他地下工程遇溶洞、断层破碎带等不良地质,需要及时处理的;

(四)其他紧急情况,为保证工期目标,经变更审查会审查确认属于紧急事项的变更。

第二十九条 工程变更的执行与监控

(一)工程变更审查会会议纪要、变更实施通知由计划处统一发布,未得到批准的工程变更不准实施(对于紧急事项变更除外)。

(二)计划处发布工程变更通知后,项目部向承包商、服务商发布变更通知并组织EPC承包商对已批复的施工图设计或施工组织设计进行调整或补充,完善设计和施工组织文件,履行审查手续,按修订后的施工图设计或施工组织设计组织现场工程建设。

(三)项目部、工程监理做好过程监控管理,每月将工程变更执行情况,完善进变更管理台账并提交计划处,计划处汇总后通报各相关处室。

(四)变更实施完成后,项目部组织现场工程监理对变更实际工程量进行确认并审核费用,填报变更工程量确认单,工程监理、项目部签字确认后提交工程管理处审查,造价与法律事务处按照《工程竣工结算管理办法》进行工程变更结算。

(五)工程技术处界定工程变更中初步设计服务商、EPC施工图设计承包商的责任,并根据合同条款启动对初步设计服务商的索赔,为项目部提供对施工图设计责任方的索赔依据;项目部根据确定的项目变更中承包商的责任,依据合同条款启动索赔。

(六)对于超出时效且已实施的工程变更,如因项目经理部原因造成,计划处组织调查并说明原因,涉及相关处室、项目部原因导致变更工作出现问题,相关意见反馈人事处纳入绩效考核。如因服务商自身原因造成的违反工程变更审批要求行为,对于确有必要实施的工程变更,只对技术方案审查,对增加费用不予审查。对于没有必要实施的工程变更,如承包商已经组织实施,由项目部安排对已经实施的变更工程返工,并根据与承包商合同条款约定进行处理或索赔。

(七)由于承包商原因造成的工程变更,由承包商承担变更工程及相关费用,造成工期延误的,项目部按照《索赔与反索赔管理办法》启动索赔。

第三十条 关于管材、设备的变更管理。EPC承包商必须严格按照批复的初步设计组织开展施工图设计,按照经过批准的施工图设计组织施工。对由于设计变更造成的管材、设备规格和数量的调整,严格履行调整手续。

(一)初步设计方案批复后,工程技术处组织初步设计服务商提交不同种类和规格的管材和设备数据单,招标 18

管理处、物资采办处按照数据单组织或委托管材、设备采购。

(二)施工图编制完成后,工程技术处、项目部组织EPC承包商统计归0施工图中管材、设备数量对比批复初步设计的数据单的差异,向计划处提交分析报告,说明差异原因和相应变更依据,经工程变更审查会审议后,按会议确定的意见安排后续工作。

(三)施工图编制完成后,对于施工图进行调整的变更,项目部每月对管材需求变化进行统计报告,同时将对照施工图需求变化情况报送工程管理处。对于非急需物资每3个月随季度更新计划进行调整。

(四)对于没有批复的设计变更,EPC承包商提交的甲供物资调整,项目部不予提交管材、设备需求报告,对于EPC承包商超出初步设计批复数据单数量的乙供物资,由EPC承包商自行承担。

第三十一条 承包商对已批复工程变更存在异议的处理。承包商对工程变更计划安排有异议的,在收到工程变更通知后7个工作日内提出,履行综合计划调整流程;对工程变更审核费用存在异议的,在收到工程变更通知后14个工作日内提出,按原合同约定进行协商;对工程变更计价原则存在异议、需要修订原合同关于变更的计价原则条款,按原合同约定并执行《合同管理办法》。

如果承包商拒绝执行工程变更通知安排的工作内容,在项目经理部与承包商合同内有明确规定,项目部按原合 19

同规定执行;如原合同中无相应规定,项目部向工程管理处提交报告,由其确定承包商组织模式。

第五章 其他管理要求

第三十二条 对于项目经理部领导班子会、投资管理委员会、外协审批会、变更审查会等由项目经理部领导确认的事项发生调整,按照变更处理,提交原会议审查、确认,并在变更审查会上进行通报。

第三十三条 工程变更管理的时限要求

(一)对于涉及需要开展补充评价和管材规格、数量调整的变更,项目部在变更实施前3个月提交审核。

(二)项目部收到经过工程监理或第三方审查后的工程变更,7个工作日内完成审查、报批,审查方式项目部确定。

(三)工程变更审查会后2个工作日内,计划处组织编制会议纪要,各处室3个工作日内完成会签。

(四)对于批复可研和初步设计的调整变更,计划处在收到股份公司批复后,5个工作日内发布工程变更实施通知。

(五)对于批复初步设计的设计变更,工程技术处收到计划处变更(包括费用)工作通知后,20个工作日内组织编制完成设计变更方案(包括费用);若涉及补充评价,60个工作日内提交设计变更方案(包括费用);计划处在 20

收到设计变更方案后5个工作日内提交地区公司。

第三十四条 变更问责

(一)工程变更提出部门应对照合同约定条款进行分析,否则接收部门有权退回,另相应审查部门承担相应专业审查责任。

(二)对于因提交工程变更资料不完善或质量不符合要求,无法提交会议审查,或是未能通过会议审查,相应项目部或发起变更部门承担工程变更审批延误的相应责任。

(三)由于勘察设计服务商原因造成的设计变更,勘察设计服务商应无偿进行设计变更,并按照设计合同约定承担赔偿责任。

(四)对于未按照工程变更审批流程申报的工程变更不予认可。

(五)项目部未按期报告管材变化,相应物资计划不予调整,因此计划滞后责任由相应项目部承担。

(六)对于以下情况,计划处统计后,纳入人事处绩效考核:

1.项目部没有通过工程变更批复,现场实施的; 2.项目部和业务处室没有对照合同约定进行审查或未提出明确意见,被退回的;

3.项目部审核后经造价与法律事务处审核费用偏差超过10%的;

4.未按要求对项目变更进行统计备案的项目,按照 21

变更未及时处理纳入绩效考核。

5.未按时限组织各处室进行审查的,计划处承担组织协调责任;相关处室未按时限进行审查的,按考核要求对及时性进行考核。

第三十五条 工程变更文件归档按照《档案管理办法》执行。本变更管理办法中所有表格及文件作为竣工资料中变更部分文件相应支持性附件,具体组卷表格和要求按照工程管理处和造价与法律事务处相应竣工资料归档要求执行。

第六章 附 则

第三十六条 本办法由计划处负责解释。

第三十七条 本办法自发布之日起执行。原《项目变更管理办法》(管建〔2013〕247号)同时废止。

第三十八条 本办法的相关记录表单 附表1:变更申请单

附表2:变更情况说明,方案及支持性文件 附表3:变更工程量申请确认表 附表4:变更实施后工程量确认表 附表5:变更申请预算表 附表6:管理台账

篇6:信息采集形成和发布管理办法

第一章 总 则

第一条 为保证XX局信息形成、审核、发布、应急处置等工作规范化、制度化、科学化,符合《中华人民共和国政府信息公开条例》和自治区以及桂林市政府信息公开相关规定的要求,进一步提高公开信息工作的质量和效率,特制定本办法。第二条 本办法所称政府信息包括:

1、机构职能;

2、法规规章;

3、领导动态;

4、工作动态;

5、决策信息;

6、规划信息;

7、统计信息;

8、财政管理;

9、人事信息;

10、行政职权;

11、信息公开指南;

12、信息公开工作报告;

13、应急监察;

14、其他依照法律、法规和有关规定应当让公众知晓的政府信息。

第三条本办法所称信息形成和发布包括信息采集、内容保障、保密审查、公开审核、形成信息、录入和录入审核、应急处置七个阶段;前四个阶段属采集信息,后三个阶段属发布信息。

第四条政府信息发布渠道:

1、XX政府或政府信息公开统一平台;

2、XX市政府信息公开统一平台;

3、市政府政务信息报送平台;

4、市政务服务中心网站;

5、相关媒体(报纸、电视、电台);

6、其他合法渠道。

第五条信息发布遵循合法、及时、真实、“涉密信息不公开,公开信息不涉密”、“不审核不公开”和“谁主管谁公开,谁公开谁负责”的原则。

第二章信息采集

第六条局属各单位、机关各科室根据实际工作情况采集、加工、整理信息。

第七条局办公室负责对本局信息采集、加工、整理工作进行管理。

第八条信息采集的内容应当符合国家的法律、法规及其他有关规定,内容全面、信息真实、表述规范、结构严谨,并有时效性和内部控制。

第三章内容保障

第九条局政府信息公开领导小组对已采集的信息进行审核修改,保证信息内容和数据具有真实性、客观性和完整性。

第十条局政府信息公开领导小组应对已采集的信息提出公开或不公开意见。

第四章保密审查

第十一条局保密工作领导小组对已审核的信息进行保密审查。

第十二条保密审查工作应当依据《中华人民共和国保守国家秘密法》和《中华人民共和国政府信息公开条例》

以及《桂林市政府信息公开保密审查制度》中相关规定进行。

第十三条保密审查工作应在公开审核工作之前进行。

第五章公开审核

第十四条指定专门负责人(或业务主管领导)担任信息公开与储存审核人,明确已采集信息公开属性。

第十五条信息公开的属性包括:主动公开、依申请公开、不予公开三种。

第十六条属于“三密”信息或涉密特别敏感信息为不予公开信息,应注明不予公开的原因。

第十七条已采集信息公开审核工作依据《桂林市容局政府信息公开保密审查制度》中相关规定进行。

第六章信息形成第十八条公开审核后的已采集信息经法律法规或组织授权的行政机关领导审阅、修改、确认信息属性、签发即形成政府信息。

第十九条签发日期为信息的生成日期。

第七章录入和录入审核

第二十条属于主动公开的政府信息,指定专人在信息形成二十个工作日内完成信息录入工作,确保信息录入正确、完整、及时。信息录入完成后,录入人对信息的内容再次确认没有错误方可发布,属于重大或紧急事件处置的政府信息需通过新闻媒体向社会公布公开的,按其他管理办法执行。

第二十一条主动公开的信息第一发布渠道为指定的网站,第二渠道为政报和合法的媒体,第三渠道为合法报栏等。

第八章应急处置

第二十二条以下两种情况应当采取应急处置:

(一)公开的信息造成公众错误理解或影响社会稳定、扰乱社会管理秩序;

(二)公开突发公共事件相关信息,包括突发公共事件预测、预报、预防和实际灾情、应急救援、善后处理等方面的信息。

第二十三条应急处置工作应当遵循及时、准确、客观、全面的原则。信息发布单位应成立常规化的应急处置机构,专门采集和处理信息发布后公众和社会的反应程度以及提出应对措施。

上一篇:全会结束时的讲话下一篇:办土地证流程