赤峰吉隆黄金矿业股份有限公司
   信息系统变更管理制度




           2022 年 12 月
1.0   目标

      本制度作为一项操作政策指导文件，目标是定义赤峰吉隆黄金矿业股份有
      限公司（以下简称“赤峰黄金集团”）的信息技术系统和其他有关系统的
      变更修改步程序。管理层应规范并确保执行该政策以保证整个公司的流程、
      控制和审查的步骤统一化。

2.0   范围

      赤峰黄金集团给员工提供信息技术服务是要帮助员工达到他们的运营及
      战略目标。鉴于服务所发生的成本，我们应确保能从这项服务上得到最大
      的价值。这份政策指导文件可以帮助赤峰黄金集团的员工们确保把这个目
      标和公司的商业要求相结合。

      该文件包含了变更修改赤峰黄金集团公司信息技术部所支持的商务应用
      程序、操作流程、有关工作文件和基本设施的内容。

3.0   开发和购买过程

      3.1    赤峰黄金集团自己不开发计算机程序。依靠顾问的帮助去选购及安
             装第三方提供的软件。

      3.2    大型项目需要经审批授权的资本性支出审批。

      3.3    大型项目制定项目章程时需要指定项目的性质、范围和项目对公司
             的影响。该项目章程需由项目发起人签字批准。

      3.4    大型项目里都需要进行影响分析。项目章程或类似的文件需要包括
             该项目带来的预计或潜在的对于公司其他系统的影响。影响级别请
             看附录 A -潜在影响分级别方针。如果影响分析的结果为“高”，在
             计划文件里一定要描述流程的完整性。

4.0   进行变更修改的申请程序

      4.1    在赤峰黄金集团的任何部门的有关信息技术的变更修改都要依照
             正式的修改的申请程序执行。
4.2     变更修改流程文件由申请部门组织编写和审批。

4.3     变更修改流程文件必须由业务部门及信息部审批。

4.4     变更修改流程文件的变动必须由管理部门批准。

4.5     任何与财务报告系统相关的变动（例如程序、运营应用系统、数据
        库、网络以及防火墙等）都应在信息技术变更修改操作政策指导文
        件所涉及的范围内。

4.6     所有变更修改的完整需求必须在变更修改表中清晰描述提出，经系
        统所有者及信息技术部负责人审批。

4.7     请求者通过在变更修改表格（附录 B）的第 1 至第 3 节中输入强制
        性信息来完成变更请求。

              4.7.1    第一节和第二节。定义-包含关于更改的一般信息

              4.7.2    第二节。影响分析——包含有关变更预期和潜在
                       影响的信息。变更优先级和潜在影响的条目决定
                       批准路由。

              4.7.3    第三节。构建/测试——包含已经执行的构建和/或
                       测试活动的详细信息，以及它们的结果。所需的
                       构建/测试的范围和深度取决于变更的类型及其
                       复杂性。

              4.7.4    第三节。部署计划——包含关于将变更部署到生
                       产环境的建议计划的信息。还应该提供详细信息
                       来描述从变更中的回滚计划。

  4.8     信息技术经理和应用职能经理审阅变更修改申请表

              4.8.1    评估内容是否有足够的详细信息，并验证变更内
                       容未超过申请范围。

              4.8.2    评估变更影响

              4.8.3    评估效果和成本
                     4.8.4    评估变更带来的风险

        4.9      拒绝变更：信息技术经理和应用职能经理拒绝变更从如下原因

                     4.9.1    需求没有被充分定义，或重复，或超出需求范围

                     4.9.2    成本效益不被认可

                     4.9.3    变更会给应用程序、操作系统或数据造成无法接
                              受的风险

        4.10     评审和结果记录在变更请求表中。变更申请单上显示“批准”或
                 “拒绝”状态，并由信息技术部经理和相关业务所有者签名。

5.0   系统测试

      5.1      测试 – 需要在测试计划或类似的计划内详细记载测试的步骤和结
               果。测试的范围和深度取决于修改的类型及复杂性。

      5.2      测试规则和测试种类 – 附录 C 描述的可能涉及到的常用测试种类。
               大型项目需要按照附录 C 里描述的测试计划进行。批准者有责任
               保证测试合理地进行并核对测试结果。

      5.3      在安装第三方提供的程序时, 至少要进行系统和终端用户的测试。

      5.4      配置与将修改移植到生产环境的配置计划相关的信息需要详细记
               录并得到项目发起人的批准。同时要阐述如果在修改移植到生产环
               境的过程中遇到了问题，需要怎样还原到初始状态的细节。

6.0   移植到生产环境

      6.1      任何应用程序的开发、测试和生产环境要保持隔离状态。

      6.2      当测试合格达到测试要求后，每一个移植到生产环境的修改都需要
               项目发起人或财务部门经理的许可才可以运行移植。

      6.3      对将修改移植到生产环境进行监督的人需与修改的开发和测试人
               员相独立。
7.0   修改记录

      修改记录需要妥善地保存在一个存放修改记录的文件夹里，由程序管理人
      或指定的人保管。

8.0   事件的管理

      8.1   信息技术部要求所有与财务报告系统相关的变动（例如程序、运营
            应用系统、数据库、网络以及防火墙等）都应保留相关日志文件，
            并至少每年一次由不同层面环节的信息技术部技术人员将日志文
            件下载保存并提交给信息技术部经理进行审阅，日志范围之内的事
            物（事件，问题和错误）被及时记录，分析和解决。

      8.2   信息技术部经理有权对日志文件中的重要操作进行回顾并提出相
            关意见与建议。

9.0   信息技术变更修改操作的审阅
财务总监每年至少一次对本年度信息技术变更修改所记录的变更事件进行审阅。
附录 A -潜在影响分级别方针

符合以下的任何一个条件的修改，其影响力为“高”：
    与财务系统相关的主要硬件的改变
    执行新的与财务报告相关的商业程序
    执行新的重要的信息技术服务
    与财务相关的应用程序的版本升级
    任何需要其它与财务相关的软件的版本升级来完成的版本升级
    任何按客户具体要求设计的与财务相关的软件
    当修改行动不属于员工本来的日常职责和权限下对生产环境中的数据修改




同时符合以下的两个条件的修改，其影响力为“低”：
    最小程度的功能性改变或对用户产生的影响
    最小程度的硬件改变

例如，针对所有软件用户的应用补丁，修改预先确定的报告输出设定，防火墙
设置的更改，仅为了美观而进行的显示外观配置的修改。
附录 B
                        赤峰黄金系统变更修改申请表
                                                                 编号:
                                                           年月序列号
1. 申请者信息
申请人姓名：                                        申请日期：
电话：                                              完成日期:


2. 变更需求描述
需求主题:
变更原因:
被影响系统:
变更种类:                          配置变更                      程序变更
                                   架构变更                      其他
变更优先级:                        紧急              高              中         低
潜在影响等级:                      高                 低
变更需求描述:



变更内容需求分析:



系统所有者批准意见：                          系统所有者签字：
批准日期：
信息技术部经理批准：                          信息技术部经理签字：
批准日期


3. 变更构建和测试
构建人：
构建细则和结果




测设人（2 人）：
测试细则和结果（测试结果需要有文档或相关可以证明测试结果的其他方式以供相关管理者和审计
检查）：




实施计划:
回滚计划:




4. 管理审批
系统所有者和信息技术经理
系统所有者和信息技术经理签字:

批准日期


5. 变更实施
变更实施人：
实施日期:


6. 实施后的结果审查
实施后审查结果：


结果审查日期:
系统所有者姓名:
系统所有者签字:
附录 C –测试步骤和测试类型

标准测试类型：

    单元测试

         在综合、系统和用户接受测试之前由信息技术经理做第一级的测试工
         作

         确保每一个模块和结构的改变达到了要求而且没有改变或破坏结构的
         内部

         包括测试用户登录或操作、商业规则、错误处理、计算和数据库操作



    综合测试

         保证改变的结构能在更大的系统里工作

         综合测试由可以执行转换程序的人员进行



    系统测试

         测试系统在不同的环境下的运作–- 例如不同的操作系统运行、远程或
         本地对系统的访问

         确保在各种系统里（例如 界面）保证必要的联络、链接和数据共享正
         常运行以及数据传输的精确和完整。

         如果适用，确保数据移动或数据转化的精确性和完整性。

         可以由测试人员执行，但是必须要由另外一个人对测试结果进行抽查。



    重压测试

         评价系统在极端使用后的功能并衡量其反应

         测试必须保证系统能够承受并可以产生正确的结果

         可以由测试人员执行，但是必须要由另外一个人对测试结果进行抽查。



    终端用户测试

         修改的测试者要对系统的正确运行和是否达到开始申请的要求进行核
         对；需要从修改的测试者那里确认确实得到了预期的结果

         不能由信息技术部进行终端用户测试


收集证据以证明测试验证的步骤以及达到预期的结果是很重要的。根据修改的潜
在影响和复杂性, 决定收集所需要的证据。




一个低级别的证据应该包括一个文件或者清单，在上面列出需要的测试、预期的
结果和实际的结果。

一个高级别的证据需要列出低级别证据所包含的实际测试结果，而且还要提供
“确凿的证据”,如屏幕抓图或者 Excel 的电子数据表。

不管提供的是哪一个级别的证据，测试者都有责任在测试结果上署名，这样才可
以确定测试已经完成并达到预期的效果，并有助于以后的审计或评价用途。