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

德信诚培训网
更多免费资料下载请进: 好好学习社区 信息系统变更和发布管理办法
第一章 总 则
第一条 目的:本管理办法规定了公司信息系统的变更和发布管理,变更
和发布管理作业操作流程和控制要点,确保变更需求的受理符合业务的优先需要,并使变更和发布过程规范化,控制变更对银行业务和已投产系统安全运行的不利影响。
达到降低信息系统变更和发布风险的目的。
保障信息系统的安全稳定运行,特制定本管理办法。
第二条 依据:本管理办法根据《公司信息安全管理策略》制订。
第三条 范围:本管理办法适用于公司信息系统变更和发布管理。
第四条 定义
(一) 软件产品:泛指信息技术开发的生产业务系统和管理信息系统等应用软件项目。
(二) 生产业务系统:指公司从事金融服务的应用网络系统。
(三) 管理信息系统:指公司信息管理的计算机网络系统,具体指OA 办公系统、信贷管理、报表系统等用来进行内部管理的应用软件系统。
(四) 业务部门:指公司总部相关业务部门。
第五条 遵循原则。
酒店重要信息系统投产及变更管理办法模版

酒店重要信息系统投产及变更管理办法模版1. 引言为了确保酒店重要信息系统的正常投产和变更,保障信息系统的稳定性和安全性,制定本办法。
2. 范围本文档适用于酒店所有重要信息系统的投产和变更。
3. 定义- 酒店重要信息系统:指对酒店整体运营具有重要影响的信息系统,包括核心业务系统、客户关系管理系统、财务管理系统等。
- 投产:指酒店重要信息系统从开发、测试环境转移到生产环境并正式投入使用的过程。
- 变更:指对酒店重要信息系统进行更新、修复、扩展或优化的行为。
4. 投产管理流程4.1 需求确认阶段1. 需求确认:与业务部门共同确认酒店信息系统的需求,并编制需求文档。
2. 设计评审:对需求文档进行评审,确保需求的准确性和完整性。
3. 系统开发:根据需求文档进行系统的开发和测试。
4.2 测试阶段1. 单元测试:开发人员对系统进行单元测试,确保各个模块的功能正常。
2. 集成测试:将各个模块集成起来进行测试,确保系统的各部分协调运行。
3. 系统测试:对整个系统进行测试,涵盖各种场景和异常情况。
4.3 系统准备阶段1. 系统准备:在生产环境中进行系统的安装、配置和数据准备。
2. 用户培训:对用户进行培训,使其熟悉系统的操作和功能。
3. 数据迁移:将测试环境中的数据迁移到生产环境中。
4.4 系统投产阶段1. 投产计划:制定详细的投产计划,包括投产时间、人员和资源安排等。
2. 投产验证:在生产环境中进行一次全面的系统验证,确保系统的稳定性和可用性。
3. 投产上线:按照投产计划进行系统的上线,并对系统进行监控和排除故障。
5. 变更管理流程5.1 变更申请阶段1. 变更需求:用户提出系统的变更需求,并编制变更申请文档。
2. 变更评审:对变更申请文档进行评审,评估变更对系统稳定性和安全性的影响。
5.2 变更执行阶段1. 变更计划:制定详细的变更计划,包括变更时间、变更内容和风险评估等。
2. 变更测试:在测试环境中进行变更的测试,确保变更的可行性和稳定性。
零售企业重要信息系统投产及变更管理办法模版

零售企业重要信息系统投产及变更管理办法模版零售企业重要信息系统投产及变更管理办法模板1.引言本文档旨在规范零售企业重要信息系统的投产及变更管理流程,确保系统安全稳定运行,并提供一个标准化的管理模板,方便项目团队使用。
2.定义重要信息系统:指对零售企业核心运营和业务决策具有重要影响的系统。
投产:指将系统正式投入生产环境,供企业使用。
变更:指对系统进行功能增加、修改或修复等操作。
3.投产管理流程3.1 系统投产准备阶段3.1.1 需求确认:确保系统的功能和性能符合业务需求,由项目团队进行评审。
3.1.2 系统测试:对系统进行全面的测试,包括功能测试、性能测试等,确保系统质量。
3.1.3 安全评估:对系统进行安全评估,包括数据安全、网络安全等,确保系统的安全性。
3.1.4 投产策划:制定系统投产计划,确定投产时间、投产范围等信息。
3.1.5 准备系统环境:准备投产所需的硬件设备、网络环境等。
3.2 系统投产执行阶段3.2.1 数据迁移:将生产数据从测试环境迁移到生产环境。
3.2.2 系统安装:在生产环境中安装系统,并配置相应的参数。
3.2.3 系统配置:根据实际需求进行系统配置,包括用户权限、数据字典等。
3.2.4 测试验收:对投产后的系统进行验收测试,确保系统正常运行。
3.2.5 系统上线:将系统上线,开始正式运行。
4.变更管理流程4.1 变更申请4.1.1 变更需求评审:对变更需求进行评审,确保变更的合理性和必要性。
4.1.2 变更风险评估:评估变更可能带来的风险和影响。
4.1.3 变更计划制定:制定变更计划,确定变更的时间、范围等信息。
4.1.4 变更审批:由相关管理人员进行变更审批。
4.2 变更执行4.2.1 变更准备:收集变更所需的资源,包括人员、设备等。
4.2.2 变更实施:按照变更计划进行变更操作。
4.2.3 变更验证:对变更后的系统进行验证测试,确保变更成功。
4.3 变更评估4.3.1 变更评估:对变更的效果和影响进行评估,收集用户反馈。
公司信息系统变更和发布管理办法

公司信息系统变更和发布管理办法一、引言随着信息化时代的到来,公司的信息系统已经成为了各大企业最为重要的组成部分之一,因此,对于公司信息系统的变更和发布管理办法变得越来越重要。
信息系统变更和发布管理办法,可以帮助公司更好地保证信息系统的随时稳定运行,减少信息系统出现故障的概率,同时也可以避免信息泄露等安全问题的出现。
本文将从信息系统变更和发布管理的概念、管理的目的、变更和发布流程以及实施管理等方面来进行介绍。
二、信息系统变更和发布管理的概念信息系统变更和发布管理,是指对于公司信息系统进行升级、更新、修复、调整等操作时,需要对这些操作进行深入管理的一种方法。
主要目的是为了确保公司信息系统的运行稳定、可靠,同时也可以避免公司因为信息系统出现问题而产生的损失等问题。
三、管理的目的信息系统变更和发布管理的主要目的在于:1. 确保信息系统的安全性在信息系统变更和发布管理中,首要的目标就是保证信息系统的安全性。
因为公司的信息系统涉及到公司的核心机密,如果信息系统出现了安全问题,将会给公司的经济利益带来重大损失。
2. 确保信息系统的运行稳定性信息系统是公司生产经营的重要工作平台,信息系统变更和发布的过程可能会带来系统不稳定的问题,而不稳定的信息系统将会影响到公司的生产经营工作,从而导致经济损失。
3. 保证信息系统的可靠性信息系统变更和发布管理,其核心意义在于确保信息系统的可靠性。
如果公司的信息系统不可靠,那么势必会影响公司的工作效率,从而带来企业的重大损失。
四、变更和发布流程信息系统的变更和发布流程,通常分为以下几个步骤:1. 变更和发布审批在进行信息系统变更和发布之前,需要进行审批。
审批的目的是为了保证变更和发布的方案是符合公司的规定和标准的,同时也可以避免可能带来的风险和影响。
2. 测试和验证变更和发布计划中,必须考虑到变更和发布后可能带来的影响,以及如何应对这些影响。
因此,在变更和发布之前,需要进行测试和验证,确保变更和发布的方案能够正常工作。
信息系统变更管理制度

信息系统变更管理制度一、目的为规范信息系统变更、发布、配置与维护管理,提高软件管理水平,优化软件变更与维护管理流程,特制定本制度二、适用范围本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理部门后,所发生的生产应用系统运行支持及系统变更工作三、变更管理细则(一)信息系统变更工作可分为一般变更工作和重大变更工作,一般变更工作(如设备配置信息变更)需提交变更申请,对变更内容进行记录,并及时更新基本配置信息库;重大变更工作特指发生以下条件任意一条的变更工作1.系统拓扑结构改变;2.系统网络或安全设备变更;3.系统关键主机变更;4.系统数据库变更;5.系统应用软件变更;6.系统网络、主机、数据库、应用系统等安全策略或安全配置发生重大变更;7.系统数据备份设备变更。
(二)信息系统重大变更实施工作由需求方(一般为业务部门)和维护方(信息系统运行管理部门)协作完成。
(三)需进行系统重大变更的部门根据实际应用情况提出变更需求和变更方案(变更方案中必须包含变更前数据备份方案,以及变更成功和失败时系统恢复的方案),填写《系统变更申请表》(见附件一),并向提交变更申请,若未申请通过,而擅自进行重大变更,将根据规定进行处罚。
(四)参照国家信息系统等级保护的相关标准,由组织相关单位和信息安全专家讨论方案的安全性,根据讨论结果修改和审批方案。
(五)系统取得变更申请审批后,信息系统运维管理部门根据《系统变更申请表》中描述和变更方案,进行系统变更。
(六)系统重大变更前必须按照变更前数据备份方案进行关键数据的全面备份,系统变更成功或失败时,应立即根据系统恢复方案进行系统恢复。
(七)系统重大变更后必须进行信息系统基线检测并合格后方可上线运行。
(八)系统重大变更后应重新对系统等级进行评估,并根据评估结果依据《备案管理制度》进行重新定级备案和等保测评。
(九)系统重大变更成功后,系统运维管理部门应根据系统变更情况对系统各项信息安全管理实施细则进行修订,并报审核。
系统变更管理办法

系统变更管理办法
编制:日期:
审核:日期:
批准:日期:
版本:V1.0 2025年8月10日发布
版本更改记录
*修订类型分为A - ADDED M - MODIFIED D– DELETED
注:对该文件内容增加、删除或修改均需填写此记录,详细记载变更信息,以保证其可追溯
第一章总则
第一条本办法用于规范系统运行过程中可能影响系统安全状态的变更过程。
本办法适用于***********信息系统的设备变更、设备配置变更、系统账户变更、用户授权变更、访问控制策略变更等系统变更过程。
第二章细则
第二条明确系统中要发生的变更,根据变更类型,制定变更方案。
第三条系统变更前,要向主管领导提出申请,经领导批准后,制定变更方案。
第四条变更方案要经过主管领导及变更相关方的评审和审批,方案获得评审通过,并经领导批准后才可实施。
第五条变更方案中要明确中止变更的条件,以及从失败变更中恢复的文件化程序,明确过程控制方法和人员职责。
必要时对恢复过程进行演练。
第六条变更实施完成后,要将变更内容及变更情况向相关人员进行通告。
第七条系统变更前,应对系统进行备份,并确保系统变更失败后能恢复到变更前的状态。
第八条应对变更过程进行控制,对变更影响进行分析并形成文档,要对变更实施过程进行记录,并妥善保存所有文档和记录。
第三章附则
第九条本规定由***********信息中心负责解释。
第十条本规定自发布之日起实行。
信息系统变更管理办法

附件2:系统变更管理办法第一条为规范信息化系统变更管理,确保集团信息化管理系统有效运行,制订本办法。
第二条本办法适用于集团公司总部,所属各公司可参照本办法,结合公司实际制定相应管理制度。
第三条下表所示的操作都视为系统变更行为,应遵照本办法执行。
按照对系统的影响程度对变更进行分类:大型★中型☆小型◇1/ 3第四条角色和职责(一)变更申请人:负责申请变更,配合相关人员进行变更需求调研,并确认变更需求。
在执行计划中,确认变更实施计划满足时间、成本和质量等要求.(二)系统运维专员:负责对用户进行变更需求调研,根据需求给出初步的解决方案,并组织变更评审.在执行计划中,负责制定和组织执行变更实施计划。
(三)变更评审小组:由信息部门负责人根据变更内容确定人员组成,负责对最终是否进行变更给出评价,并确定最终变更方案。
(四)运维支持团队:分为内部支持团队和外部支持团队,分别负责公司内部和厂商的具体实现。
第五条变更管理变更管理流程分为:变更申请、变更需求调研、变更方案建议、变更评审、制定变更计划、确认变更计划、执行变更计划、变更交付八个步骤:1.变更申请:由变更申请人根据变更类型进行变更申请,并2/ 3将变更申请发送给系统运维专员。
2.变更需求调研:由系统运维专员组织调研,在变更申请人配合下,完成对变更需求的调研分析。
3.变更方案建议:由系统运维专员根据变更需求,给出初步的方案建议。
4.变更评审:由信息部门负责人确定变更评审小组成员,评审中修改并确定变更的实施方案,小型变更由部门负责人审批,大、中型变更由信息分管领导审批。
5.制定变更计划:由系统运维专员根据已审批的方案,联系内部或外部支持团队,共同评估和协商,制定变更实施计划.6.确认变更计划:由变更申请人对计划中的功能、性能、时间、成本等进行确认。
7.执行变更计划:由运维支持团队执行系统变更的具体实现工作.8.变更交付:在进行测试后,由系统运维专员进行成果交付。
信息系统管理办法

信息系统管理办法信息系统管理办法是指企业或机构在管理和运营信息系统过程中所必须遵守的规范和标准。
本办法旨在确保信息系统的安全可靠运行,保护信息资产的机密性、完整性和可用性,规范信息系统的使用行为,提高企业或机构的信息化管理水平。
一、管理范围1. 信息系统管理办法适用于所有企业或机构的信息系统管理工作,包括但不限于硬件设备、软件系统、网络设施、数据库等。
二、组织架构1. 设立信息系统管理部门,负责制定和落实信息系统管理办法及相关政策和流程。
2. 配置专职人员负责信息系统的运维和维护工作,并确保其得到必要的技术培训和技术支持。
三、信息系统安全1. 建立完善的信息系统安全策略和技术措施,保护信息系统免受未经授权的访问、篡改、破坏等行为。
2. 制定严格的访问权限管理制度,确保只有经授权的人员才能使用和操作信息系统。
3. 定期进行信息系统安全风险评估和漏洞扫描,并及时采取相应的措施进行修复和改进。
4. 建立信息系统安全事件应急预案,对各类安全事件进行有效处置,并及时报告上级主管部门。
四、信息资源管理1. 对信息资源进行分类和管理,确保其安全可控和合理利用。
2. 建立信息资源获取和分发机制,对信息资源的流通进行有效监管和管理。
3. 加强对信息资源的备份和恢复工作,定期进行数据备份,并对备份数据进行存储和管理。
五、网络管理1. 建立网络设备的监控和管理机制,确保网络的稳定运行和安全防护。
2. 限制或禁止员工未经授权的上网行为,严禁访问、传播和发布涉及违法、淫秽、暴力等信息。
3. 建立网络安全检测和防护机制,定期进行网络安全漏洞扫描和入侵检测,及时修复漏洞和防范攻击。
六、员工管理1. 对员工进行信息安全教育和培训,提高员工的信息技术意识和信息安全意识。
2. 明确员工对信息系统和信息资产的责任和义务,并约定相应的违规处罚措施。
3. 建立员工离职时的信息系统权限撤销机制,避免离职员工对信息系统的滥用和非法操作。
七、监督检查1. 定期进行信息系统管理的自查和内审工作,确保信息系统的合规运营。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
信息系统变更和发布管理办法第一章总则第一条目的:本管理办法规定了公司信息系统的变更和发布管理,变更和发布管理作业操作流程和控制要点,确保变更需求的受理符合业务的优先需要,并使变更和发布过程规范化,控制变更对银行业务和已投产系统安全运行的不利影响。
达到降低信息系统变更和发布风险的目的。
保障信息系统的安全稳定运行,特制定本管理办法。
第二条依据:本管理办法根据《公司信息安全管理策略》制订。
第三条范围:本管理办法适用于公司信息系统变更和发布管理。
第四条定义(一)软件产品:泛指信息技术开发的生产业务系统和管理信息系统等应用软件项目。
(二)生产业务系统:指公司从事金融服务的应用网络系统。
(三)管理信息系统:指公司信息管理的计算机网络系统,具体指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和相关业务部门负责人签署意见的《用户测试验收报告》给项目管理科进行审核。
(二)项目管理科审核通过后,将上线申请材料交科技信息部安全科及科技信息部负责人审核。