信息系统变更管理制度.docx

信息系统变更管理制度

篇一：信息系统配置、变更和发布管理制度
信息系统配置、变更和发布管理制度
1.目的
为规范信息系统的配置、 变更和发布的流程， 使系统配置 和变更等工作能顺利实施， 保证硬件设备和软件系统的正常 运行。
2.标准
2.1 信息系统的定义：计算机软件系统、硬件设备以及数 据。 2.2 信息系统配置、变更和发布管理的范围
2.2.1 核心设备的配置和变更， 包括服务器硬件变更、 服务 器操作系统配置和变更、各级交换机的配置和变更。
2.2.2 业务数据库的配置和变更。 2.2.3 应用软件的配置、 变更和发布。 2.2.4 终端计算机的配置和变更。 2.3 配置、 变更和发布的流程 2.3.1 计划和申请
2.3.1.1 对于新上线的信息系统，应根据实际需要制定配置 和实施计划，确保系统能顺利投入使用。
2.3.1.2 对于在用的信息系统，因管理工作需要进行变更 的，应调研变更的涉及范围和实施过程中可能出现的问题，

1
涉及面广影响较大的需填写《信息系统变更申请表》 ，并制
定变更实施计划。
2.3.1.3 对于在用的软件业务系统，科室因业务工作需要， 要求对软件系统进行系统缺陷修改或功能完善的，须填写 《信息系统软件功能新增修改申请表》 。
2.3.2 审批
2.3.2.1 涉及面小且影响轻微的或必须立刻实施的信息系 统变更，可由信息科负责人审批。
2.3.2.2 涉及面广且影响较大的信息系统变更， 先由信息科 负责人审批，再上报主管院长审批。
2.3.2.3 对于科室提交的软件系统功能的修改变更， 先由所 属的主管职能部门审批，再由信息科负责人审批，如涉及开 发费用的需由主管院长审批。
2.4 实施和发布
2.4.1 对于新上线的信息系统， 按照制定的计划方案进行实 施。
2.4.2 对于在用的信息系统，信息科需细化实施方案，必 要时制定风险应对计划， 通知本次变更所涉及的科室和人员 作好相应的准备工作，再按照实施方案进行具体的变更实 施。
2.4.3 软件系统的发布，按照《信息系统软件版本变更管 理制度》 的有关规定执行。 2.4.4 对于新安装的计算机终端，

2
在投入使用前应由所涉及到的业务系统的责任维护人员进 行检查和配置，再进行分发使用。
2.5 记录
2.5.1 信息系统配置或变更实施完毕， 持续正常运行后， 需 进行相关配置的记录，填写《信息系统配置记录表》 。
3.文档
3.1 《信息系统变更申请表》
3.2 《信息系统软件功能新增修改申请表》 3.3 《信息系统
配置记录表》
信息系统变更申请表
信息系统软件功能新增修改申请表
信息系统配置记录表
篇二：信息系统变更和发布管理办法
信息系统变更和发布管理办法
第一章 总 则
第一条 目的： 本管理办法规定了 XX 银行(以下简称 “我
行”)信息系统的变更
和发布管理，变更和发布管理作业操作流程和控制要点， 确保变更需求的受理符合业务的优先需要， 并使变更和发布 过程规范化，控制变更对银行业务和已投产系统安全运行的 不利影响。达到降低信息系统变更和发布风险的目的。保障 信息系统的安全稳定运行，特制定本管理办法。

3
第二条
第三条
第四条
(一) 目。
(二) 生产业务系统：指我行从事金融服务的应用网络系 统，包括综合业务系统、国依据：本管理办法根据《 XX 银 行信息安全管理策略》制订。 范围：本管理办法适用于我 行信息系统变更和发布管理。 定义 软件产品：泛指信息技 术开发的生产业务系统和管理信息系统等应用软件项际业 务系统、支付系统等银行对外营业的各种核心业务系统。
(三) 管理信息系统：指我行信息管理的计算机网络系统， 具体指 OA 办公系统、信贷管理、报表系统等用来进行内部 管理的应用软件系统。
(四)
第五条
(五) 遵循原则 业务部门： 指我行总部相关业务部门。 监 督制约原则：针对信息系统变更和发布管理工作中各个环 节，建立相应的监督检查机制。
(六) 计划性原则： 信息系统发布应纳入每年计算机应用计 划，确保全行计算机系统资源、应用环境、维护力量、操作 技能能满足系统安全、可靠运行的要求。

4
(七)
(八) 可行性原则：具有普遍适用性和可操作性。 风险控 制原则：
若为新项目或新业务功能变更和发布， 需进行以下风险分 析：
1. 备份机建设情况；
2. 应用系统投产后的集中监控方案；
3. 生产数据备份方案；
4. 程序及系统备份方案；
5. 数据库建库 /建表/建索引方式等；
6. 对其他系统的影响。 第二章 组织与管理 第六条
(一) 职责划分 需求部门：
1. 提出需求，并确认《用户需求说明书》 ；
2. 用户测试阶段确认用户测试计划、记录用户测试问题、
确认用户测试报告；
3. 接受用户培训并提出反馈。
(二) 科技信息部安全科：
1. 在需求阶段审阅和提出 IT 风险控制、 IT 合规和 IT 稽 核方面的要求，在项目开发阶段
对有关 IT 风险控制、 IT 合规和 IT 稽核方面的测试结果

5
进行审阅；
2. 在项目实施后审阅阶段对有关 IT 风险控制、 IT 合规和 IT 稽核要求的实施效果进行审
阅。
(三) 科技信息部运行维护中心：
1. 负责受理所有变更和发布需求，会同 IT 其他相关部门 (IT 软件开发中心、安全科
等)对变更和发布需求进行评估，并将评估意见向 IT 部
门领导、业务部门领导汇
报沟通，获取所需的授权；
2. 在详细设计阶段审阅和提出网络、 硬件、 操作系统和数
据库等方面的配置和容量
要求；
3. 在设计与编程阶段提供网络、 硬件、 操作系统和数据库 的参数配置；
4. 在测试阶段配合项目组设立网络、硬件、操作系统和数
据库环境；
5. 配合项目组对系统进行联合测试，把信息系统版本软
件、相关配置文件、标准数
据和相关文档提供给测试评估中心；
6. 将信息系统发布到使用部门， 系统上线时会同项目组搭 建生产系统并进行程序移

6
植，组织定期对变更和发布效果进行分析和总结。
7. 接收管理和备份软件开发中心提供的源程序、 相关标准 数据、配置文件、相关文
档；
(四) 科技信息部软件开发中心：
1. 负责设计、编程、纠错和开发质量控制，编制《系统设
计规格书》；
2. 落实项目管理制度和业务操作手册的编制工作， 参加制
定上线方案制定，编制《上
线实施计划》；
3. 负责系统切换上线的技术支持工作；
4. 负责项目验收资料整理汇总，配合项目验收工作。
(五) 科技信息部测试评估中心：
1. 负责对需要测试评估的软件进行分析测试；
2. 负责提交测试分析报告。 第三章 信息系统变更
第七条 信息系统变更， 指由于新增信息系统功能、 系统 逻辑改变、系统错误修正、系统补丁安装及版本更新、系统 配置修改及业务参数修改等原因，而对已投产系统进行局部 改变的一切活动。已投产系统变更需求主要来源于以下几种 情况：
(一) 由于业务快速发展， 业务部门对现有已投产系统的功

7
能或设置进行变更或通过新增功能来满足需求；
(二) 用户在使用过程中发生的一些操作错误，或技术人 员、监控管理软件自动发现的故障或事件，需要通过安装程 序补丁或修改配置等操作进行修改；
(三) 厂商定期发布的系统补丁，涉及系统的功能、性能、 安全漏洞，需要在已投产系统中进行安装；
(四) 由于系统容量扩充或与已投产系统存在数据交换或 数据共享的其他已投产系统发生变化后引发的已投产系统 变更。
第八条 信息系统变更的提出， 必须由申请部门 (用户部 门或 IT 部门)填写《已投产系统变更流程单》 (附件 1)第 一部分，申请信息。在申请信息填写阶段的主要工作内容包 括：
(一) 申请人需选择变更类型；
(二) 描述变更内容和目的；
(三) 是否存在其他措施满足变更需求；
(四) 如不实施变更可能对客户、合规、外部利益相关方、 内部管理和操作、安全控制、系统可用性和数据准确性的影 响；
(五) 选择变更的急迫性。
第 九 条 申 请 部 门 主管 审批 签字 后提交 IT 运 行 ( 来 自 :WWw.xlT 小龙文 档网:信息系统变更管理制度 )

8
维护中心进行处理。
第十条 IT 运行维护中心收到变更申请后，和变更申请 部门充分沟通，理解变更需求的合理性，审阅变更的影响和 急迫性，并会同 IT 其他相关部门( IT 软件开发中心、安全 科等)对可行的变更实施方案和变更对已投产系统的影响做 出评估，最终形成建议的变更日期，填写至《已投产系统变 更流程单》第二部分，变更需求评估信息，交 IT 运行维护 中心负责人进行审批。
第十一条 IT 运行维护中心组织变更需求评估时，应充 分考虑系统是否已存在满足变更需求的功能或设置； 是否存 在其他操作手段，能达到同样的变更需求效果。
第十二条 IT 运行维护中心组织变更需求评估时，了解 实施变更：
(一) 是否需要进行 IT 开发，以及 IT 开发的工时；
(二) 是否需要进行操作系统、数据库系统、中间件、硬件 和网络的变更；
(三) 是否需要进行后台数据变更；
(四) 是否存在信息安全控制的考虑因素；
(五) 结合 IT 部门现有的 IT 资源， 统筹安排变更实施时间 表；
(六) 实施相关变更时， 可能导致的业务中断或客户服务水 平下降。

9
第十三条 综合对变更需求合理性的评估和变更实施影 响的评估， IT 运行维护中心在 《已投产系统变更流程单》 的 第二部分提出变更的建议日期，并进行资源协调。在 IT 运 行维护中心负责人进行审批后，通知相关部门：
(一) 如不建议实施变更，则向变更申请部门说明理由；
(二) 如建议实施变更， 则告知建议变更的时间及对客户服
务和内部操作的影响，要求变更申请部门和相关部门进行准 备；
(三) 如变更规模超过《 XX 银行 IT 项目管理指引》规定 的项目受理标准，则依据该指引有关规定执行。
第十四条 对涉及软件开发的需求变更，参照《 XX 银行 IT 开发方法指引》的要求执行。
第十五条 对不涉及软件开发的需求变更， IT 运行维护 中心根据需要，提交 IT 测试评估中心相关人员负责制定变 更的测试步骤，落实测试人员在测试环境中对变更进行测 试，测试人员对测试结果进行记录并签字确认。
第十六条 信息安全人员对变更进行上线前审阅， 确保系 统变更过程中的系统安全。信息安全人员完成上线前审阅 后， IT 运行维护中心进行上线处理。信息安全人员根据变 更的风险程度，进行上线后审阅，确保达到变更目标。
第十七条 为控制已投产系统的变更对客户服务和业务 操作带来的影响， 确保生产环境的完整性和可靠性， IT 部门

10
应制定一系列控制 IT 变更的策略和制度，严格控制变更的 规模、涉及面及信息安全风险。包括：
(一) IT 运行维护中心负责人每周对集中的变更工作计划 进行审阅，确保充分有效的 IT 技术资源或系统供应商 /开发 商技术资源，保证变更的有序进行；
(二) 除非是需要立即实施的特急变更， IT 运行维护中心 应选择非业务繁忙时间，如凌晨、周末或公众假期进行变更 上线；
(三) IT 运行维护中心进行周密计划， 包括制定意外应急措 施；
(四) 分离已投产系统与开发或测试系统的管理职责；
(五) 保证已投产系统和开发或者测试系统相分离， 禁止开 发人员在未经授权的情况下进入已投产系统；
(六) 只有在得到管理层批准执行紧急修复任务时， 开发人 员才能访问已投产系统， 所有的紧急修复活动都应立即进行 记录和审核；
(七) 开发人员对已投产系统进行变更必须经过严格的审 批和控制；开发人员访问已投产系统时必须由 IT 运行维护 中心系统管理员对其访问进行监督和记录， 并在访问结束后 系统管理员及时禁用或删除开发人员在已投产系统中使用 的账号；
篇三：信息系统变更、发布、配置管理制度

11
信息系统变更、发布、配置管理制度
第一条 为规范信息系统变更、发布、配置与维护管理， 提高软件管理水平，优
化软件变更与维护管理流程，特制定本制度。
第二条 信息系统变更、发布、配置工作可分为下面三类 类型：功能完善维护、
系统缺陷修改、 统计报表生成。 功能完善维护指根据业务 部门的需求，对信息系统进行的功能完善性或适应性维护； 系统缺陷修改指对一些系统功能或使用上的问题所进行的 修复，这些问题是由于系统设计和实现上的缺陷而引发的； 统计报表生成指为了满足业务部门统计报表数据生成的需 要，而进行的不包含在应用系统功能之内的数据处理工作。
第三条 信息系统变更、发布、配置工作以任务形式由需
求方(一般为业务部门)
和维护方 (计算机中心和软件厂商)协作完成。信息系统 变更、发布、配置过程类似软件开发、发布、配置，大致可 分为四个阶段：任务提交和接受、任务实现、任务验收和程 序下发上线。
第四条 需求部门提出系统需求，并将需求整理成《信息 系统变更申请表》 (附件
一) ，由部门负责人审批后提交给计算机中心。
第五条 计算机中心负责接受需求并上报给信息主管院

12
长。主管院长分析需求，
并提出系统变更建议。 计算机中心根据变更建议审批 《信 息变更申请表》。
第六条 计算机中心根据部门提供的需求与软件开发商联 系协同实现信息系统变
更需求，产生供发布的程序。
第七条 计算机中心组织相关业务部门的信息系统最终用 户对系统程序变更进行
测试。
第八条 信息系统变更程序测试完成后，由计算机中心配 置完善信息系统，正式
发布并通知需求部门。
第九条
计算机中心出具信息系统变更验收报告 (附件二)， 需求 部门签字验收。
附件一 信息系统变更申请表
信息系统变更申请表
附件二 信息系统变更验收报告
13