应用系统变更申请表

河北一卡通应用系统变更申请表

编号： 20141001 （变更申请部门填写）变更申请人部门* 技术保障部申请人联系方式* 67306166-8029 变更申请人* 申请日期* 2014/10/13 变更系统名称* 河北一卡通清分系统及缴费通系统数据库巡检优化

系统版本* 河北一卡通3.1

变更计划起始时间* 2014年10月14日21:30分至 2014年10月14日24:00分系统变更申请

部门领导审批* 签字：日期：

变更系统所需的软、硬

件环境*(可附件）

可连生产网络的系统并安装有TELNET软件。

系统变更需提交的

文档*(可附件）

系统变更风险评估

* 所影响的系

统和应用

期间系统会短时间内停止服务，届时无法响应客户及商户所有一卡通卡相关服务。业务风险短时间内无法进行业务处理。

技术风险微小

系统变更实施方案* (可附件）见附件：

《清分系统数据库巡检整改方案.docx》《缴费通系统数据库巡检整改方案.docx》

领导审批意见

技术专家评审意见：

评审人：日期：领导审批：

签字：日期：

*系统变更结果确认

系统变更是否成功：是否系统变更人员签名：

变更总结（成功/失败原因）

系统变更实际执行时间：From： To：

领导确认变更结果签名：日期及时间：

信息系统变更、发布、配置管理制度

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

附件一信息系统变更申请表信息系统变更申请表

软件项目变更管理流程

变更管理流程 1概述 ....................................................................................... 错误！未定义书签。2变更流程 .. (2) 2.1摘要 (2) 2.2提交变更申请 (2) 2.3审核变更申请 (2) 2.4识别变更可行性 (2) 2.5批准变更申请 (3) 2.6实施变更申请 (3) 3变更任务 (3) 3.1变更申请人 (3) 3.2变更经理 (3) 3.3变更可研小组 (3) 3.4变更审批小组 (4) 3.5变更实施小组 (4) 4变更登记 (4) 5变更模板 (4)

1 概述描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如：变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。对项目的变更管理是通过对以下五个关键步骤的实施引入的。，: 提交和接收变更申请审核和记录变更申请确定变更申请的可行性批准变更申请实施和结束变更申请 2 变更流程对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project. An example follows: 2.1 概要下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。 2.2 提交变更申请本步骤中项目团队中的任何成员都可以提交项目变更申请，需要完成以下工作：变更申请人识别项目中任何方面的变更需求（如范围、可交付成果、时限、组织）. 变更申请人完成变更申请表（CRF），并将其呈交变更经理。变更申请表对需要进行的变更做一概述，包括： ?变更描述 ?变更原因（包括商业驱动） ?变更利益 ?变更成本 ?变更带来的影响 ?支持性文件 2.3 审核变更申请本步骤授权变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是：呈交的可选择变更数目Number of change options presented 申请变更可选反性的复杂程度Complexity of the change options requested 提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required. 2.4 识别变更可行性本步骤涉及完成一份完整的变更可行性研究，以确保对所有的变更可选项进行调查并上报，变更可行性研究包括对以下各项的定义：变更需求变更可选项Change options 变更成本及利益变更风险及事项Change risks and issues 变更带来的影响

账户信息变更申请表

账户信息变更所需材料清单一、银行账户信息变更 1、个人投资者《账户信息变更申请表》（投资者本人签字）身份证件复印件（投资者本人签字）变更后银行卡或存折复印件（投资者本人签字） 2、机构/产品投资者《账户信息变更申请表》（加盖公章、经办人签字）企业法人营业执照或民政部门等颁发的注册登记证书复印件（加盖公章）经办人身份证正反面复印件（加盖公章）新账户的银行开户回单复印件（加盖公章），若没有开户回单，请提供加盖公章的账户证明文件。二、机构投资者法定代表人/负责人变更《账户信息变更申请表》（加盖公章、经办人签字）企业法人营业执照或民政部门等颁发的注册登记证书复印件（加盖公章）新法定代表人/负责人身份证件正反面复印件（加盖公章）经办人身份证正反面复印件（加盖公章）机构账户印鉴卡（变更印鉴）机构投资者授权委托书（加盖公章、法人签章、经办人签字）三、投资者经办人变更 1、个人投资者《账户信息变更申请表》（投资者本人签字）个人投资者授权委托书（投资者本人签字、新经办人签字）经办人（新）身份证正反面复印件（新经办人签字） 2、机构/产品投资者《账户信息变更申请表》（加盖公章、新经办人签字）机构投资者授权委托书（加盖公章、法人签章、新经办人签字）企业法人营业执照或民政部门等颁发的注册登记证书复印件（加盖公章）新经办人身份证正反面复印件（加盖公章、新经办人签字）四、机构投资者名称变更《账户信息变更申请表》（加盖公章、经办人签字）企业法人营业执照或民政部门等颁发的注册登记证书复印件（加盖公章）法定代表人/负责人身份证件正反面复印件（加盖公章）经办人身份证正反面复印件（加盖公章）变更后的银行账户信息文件（指定银行开户许可或机构出具的账户证明文件，并加盖公章）工商局开具的准予变更登记通知书机构账户印鉴卡（变更印鉴）机构投资者授权委托书（加盖公章、法人签章、经办人签字）

账户变更申请书

账户变更申请书中融国际信托有限公司：【□本人/□我司】____________（以下简称“申请人”），证件/证照类型: _________，证件/证照号码：__________________，联系地址：_____________，联系电话：____________，与贵司签订了《_________________________________信托合同》（编号： _______________）（以下简称“《信托合同》”），是该信托计划项下的委托人/受益人，享有____________份信托单位所对应之信托受益权。现特向贵司申请变更该信托合同中约定的收益分配账户信息。原信托利益分配账户信息：账户名称：_____________________ 开户银行：______银行______省______分行______支行银行账号：_____________________ 变更后信托利益分配账户信息：账户名称：_____________________ 开户银行：______银行______省______分行______支行银行账号：_____________________ 请贵司根据前述信息对收益分配账户予以变更，并于变更确认后将信托利益支付至变更后的账户。申请人保证上述信息的真实性和准确性，并承诺对上述信息的真实性和准确性承担一切责任。如因申请人提供的账户信息有误或其他非归因于贵司的原因，导致申请人在该

信托计划项下的利益或权利受到任何损失、损害或产生任何纠纷的，均由申请人自行承担，贵司对此不承担任何责任。申请人姓名/公司名称：（签名或公章）法定代表人/负责人或授权代表（签章）：申请日期：______年___月___日账户变更面签声明书

需求变更的代价

需求变更的代价让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。对软件需求和需

信息系统变更管理办法

附件2：系统变更管理办法第一条为规范信息化系统变更管理，确保集团信息化管理系统有效运行，制订本办法。第二条本办法适用于集团公司总部，所属各公司可参照本办法，结合公司实际制定相应管理制度。第三条下表所示的操作都视为系统变更行为，应遵照本办法执行。按照对系统的影响程度对变更进行分类：大型★中型☆小型◇

组成，负责对最终是否进行变更给出评价，并确定最终变更方案。（四）运维支持团队：分为内部支持团队和外部支持团队，分别负责公司内部和厂商的具体实现。第五条变更管理变更管理流程分为：变更申请、变更需求调研、变更方案建议、变更评审、制定变更计划、确认变更计划、执行变更计划、变更交付八个步骤： 1．变更申请：由变更申请人根据变更类型进行变更申请，并将变更申请发送给系统运维专员。 2．变更需求调研：由系统运维专员组织调研，在变更申请人配合下，完成对变更需求的调研分析。 3．变更方案建议：由系统运维专员根据变更需求，给出初步的方案建议。 4．变更评审：由信息部门负责人确定变更评审小组成员，评审中修改并确定变更的实施方案，小型变更由部门负责人审批，大、中型变更由信息分管领导审批。 5．制定变更计划：由系统运维专员根据已审批的方案，联系内部或外部支持团队，共同评估和协商，制定变更实施计划。 6．确认变更计划：由变更申请人对计划中的功能、性能、时间、成本等进行确认。

软件开发项目需求变更管理及应对之

软件开发工程需求变更经管及应对之道研究变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。需求变更经管的需求需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。需求变更的出现主要是因为在工程的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想

到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来经管需求变更，那么很可能造成工程进度拖延、成本不足、人力紧缺，甚至导致整个工程失败。当然，即使按照需求变更控制流程进行经管，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更经管的目的所在。六大原则实施需求变更经管需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

软件项目-变更管理规程-模板

变更管理规程变更管理规程版本：V1.0

变更管理规程目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 1.3参考文档 (1) 2角色和职责 (1) 3流程图 (2) 4入口准则 (2) 5输入 (2) 6任务描述 (3) 6.1TCC010提交变更申请 (3) 6.2TCC020变更影响分析 (3) 6.3TCC030变更审批 (3) 6.4TCC040组织实施变更 (4) 6.5TCC050确认实施结果 (4) 6.6TCC060更新基线 (4) 7输出 (4) 8出口准则 (4)

变更管理规程1 介绍 1.1 目的本文件的目的是描述项目变更管理应遵循的规程，以确保项目的变更被控制和管理起来。 1.2 范围本文件适用于公司软件开发项目的变更活动。 1.3 参考文档《配置管理过程》《配置管理规范》 2 角色和职责

变更管理规程3 流程图 4 入口准则 1、软件开发过程之中的工作产品（如：需求设计文档、设计模型、代码及测试脚本等）有变更需求； 2、里程碑预计延期超过项目进度偏差的阈值；（项目进度偏差阈值根据组织级进度阈值制定，组织级进度阈值为±20%） 5 输入 1、变更需求 2、进度计划 6 任务描述 6.1 TCC010提交变更申请 1. 变更申请人根据变更情况详细填写《变更申请表》提交给项目经理。

6.2 TCC020变更影响分析 1. 项目经理判断申请是否有效、是否存在类似申请，并指定相关人员对变更进行影响分析； 2. 项目经理根据影响分析的结果对变更申请进行初步审核，决定是否需要提交给CCB批准，并填写《变更申请表》的审批意见： ?如果变更预计工作量导致在总工作量的2.5%以内，且变更不涉及到优先级为一级的需求变更，项目经理可直接通知实施人进行实施，在变更前应确定变更方案；这种变更一般不会导致基线版本的变更、且对其他配置项影响不大； ?如果为影响项目进度、影响项目重要需求的变更，将此表送交CCB，进行审批。重大变更主要是正式基线的变更、该配置项变更将引起其他配置项的变更； ?如果是进度变更，一旦超过项目进度阈值，必须提交CCB审批； ?如果项目经理不能决定变更并填写《变更申请表》中相应的栏目，提交CCB进行评估； 3. 如果项目经理拒绝变更申请，则项目经理将结果反馈给变更申请人，流程结束。 6.3 TCC030变更审批 https://www.360docs.net/doc/b79424634.html,B分析变更申请，，并将审批意见填写在《变更申请表》里“CCB审批意见”栏。审批意见分为以下三种： ?同意变更：同意此次变更申请，项目经理组织实施； ?推迟变更：变更被搁置，留作将来实施； ?拒绝变更：不同意此次变更申请，变更流程结束； 2. CCB负责人将《变更申请表》反馈给项目经理； 3. 对推迟变更和拒绝变更的申请，项目经理反馈给配置管理员和变更申请人；对同意变更的申请，项目经理组织实施变更。 6.4 TCC040组织实施变更 1. 项目经理安排实施变更任务； 2. 项目经理通知配置管理员开放要实施变更的基线的权限，配置管理员填写《变更跟踪表》； 3. 变更实施人按照批准的《变更申请表》实施变更，变更完成后更新《需求跟踪矩阵》，并通知项目经理；

IT项目需求变更表申请表(实例)

需求、设计和开发变更表产品名称龙岗政府在线升级改造项目项目名称龙岗政府在线升级改造项目项目经理霍军良变更申请人郭昊申请时间2007年7 月19 日变更类型 □新增需求需求变更□内部改进□产品缺陷 □系统环境变更□其他变更描述变更前的描述（若是新需求，则不需填写此栏）：区长信箱的管理部门（区长专线办）只能指定一个部门处理区长来信。新需求或变更后的描述：区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果要求集中在前台按照各个部门的处理结果按照列表显示。变更影响的配置项序号配置项影响描述当前版本需求变更受影响的文档版本号的更新 2.0.1 变更评审方式项目组裁决□召开评审会议□会签评审评审负责人霍军良评审成员宋雷鸣、郭昊、卞兆洋、梁伟评审意见更改对产品组成部分的影响：在区长信箱多了一些功能操作。增加了多部门处理方法！更改方案描述：在页面中选择好要分发的部门，然后在后台将部门数据传入到集合内，循环遍历集合中数据属性存入数据库相关表中。并删除原来数据。最后在系统的工作任务中建立任务调度时间设置在每天22：00。变更对进度的影响（天）由于工作量不大，而且通过加班工作，对进度的影响可以忽略不计。第1 页共2 页

变更对成本的影响由于工作量不大，而且通过加班工作，对进度的影响可以忽略不计。变更对质量的影响添加这个新的需求会对系统测试案例等文档产生影响。对配置库的影响是：受影响的文档版本号的更新。变更引起的风险无技术评审结论可以更改□拒绝变更是否属不合格□是不是评审人员签字评审负责人评审人评审人评审人评审人评审人评审人霍军良郭昊宋雷鸣卞兆洋梁伟 CCB意见立即更改□推迟更改□拒绝变更签字林文涛日期2007年7 月19 日项目经理确认卞兆洋、郭昊在2007-7-18中午晚上加班修改完成。签字霍军良日期2007年7 月19 日变更当前状态□已指派□已打开□已更改已验证更改情况已经对区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果集中在前台按照各个部门的处理结果显示在列表中。更改人签字郭昊、卞兆洋日期2007年7 月19 日更改验证情况通过任务调度，已经测试通过，实现了分发给多个部门处理。验证人签字刘艳君日期2007年7 月19 日变更配置项验证变更的配置项责任人完成日期版本CMO审核结论需求变更宋志强2007年7月19 日 1.01 已更改完成第2 页共2 页

信息系统配置、变更和发布管理制度

信息系统配置、变更和发布管理制度 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 对于在用的信息系统，因管理工作需要进行变更的，应调研变更的涉及范围和实施过程中可能出现的问题，涉及面广影响较大的需填写《信息系统变更申请表》，并制定变更实施计划。 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.5 记录 2.5.1 信息系统配置或变更实施完毕，持续正常运行后，需进行相关配置的记录，填写《信息系统配置记录表》。 3. 文档 3.1 《信息系统变更申请表》 3.2 《信息系统软件功能新增修改申请表》 3.3 《信息系统配置记录表》

商业客户信息变更申请表

PUBLIC To: The Manager 致: 经理 HSBC Bank (China) Company Limited. 汇丰银行（中国）有限公司 ___________________________________Office 分行 Date 日期 ____________________________ Business Customer Information Change Application Form 商业客户信息变更申请表 Note 注意: 1. Please tick ( √ ) where applicable and complete this form in BLOCK LETTERS. 请在适当的方格内划上钩号( √ )，并用正楷填写。 2. Please cross out those not applicable. 请划去所有不适用的部分。 3. Please provide relevant documentation necessary for information change and attach after this form. 所提交的新/修改后的资料请附于本表后。 Customer Name 客户名称 Customer Number 客户号码 A O C -C U A -024_b (061113) P.T.O 请转背页

Notes 签署说明： 1.For Changes in Part I: Domestic entity/representative office should sign this Form by Legal Representative/Person-in-Charge/Chief Representative’s Signatory plus Company Chop; Overseas entity should sign it by any group of authorized signatory(ies)/Chop(s). For mere change of domestic entity/representative office’s company chop/financial chop, any group of authorized signatory(ies)/Chop(s) plus company chop is also acceptable; for change of English name,the direction of Part III can be followed if the signatory of the company remains unchanged. 第一部分若有变更：境内机构/代表处应由法定代表人/单位负责人/首席代表签字并加盖公章；境外机构应由任意一组授权签字人签章。对于境内机构/代表处仅变更公章/财务章样本，也可由任意一组授权签字人签署并加盖公章；对于企业英文名称变更，若其预留印鉴并未发生相应更改，则可遵循第三部分的签署要求。 2.For Changes in Part II: The authorized signatory should give his/her previous signatory(ies)/chop(s) in Part II; if he/she cannot provide previous signature/chop, the authorized signatory should come to any branch in person with the application form on which company chop has been stamped or Legal Representative/Person-in-Charge/Chief Representative has signed. 第二部分若有变更：该签字人本人应在第二部分相应栏位中留下原有签章；若无法提供原有签章，需签字人本人亲临办理，并在客户签章处加盖公章或法定代表人/单位负责人/首席代表签字生效。 3.For Changes in Part III: Domestic Entity/Representative Office could sign the Form by Legal Representative/Person-in-Charge/Chief Representative’s Signatory plus Company Chop OR any group of authorized signatory(ies)/Chop(s); Overseas Entity should sign it by any group of authorized signatory(ies)/Chop(s). 第三部分若有变更：境内机构/代表处可由法定代表人/单位负责人/首席代表签字并加盖公章或由任意一组授权签字人签章；境外机构应由任意一组授权签字人签章。 __________________________________________________________________ Customer Signatory(ies)/Chop(s) 客户签章 PUBLIC

信息系统变更管理规定

信息系统变更管理规定 Corporation standardization office #QS8QHH-HHGX8Q8-GNHHJ8

第四条角色和职责（一）变更申请人：负责申请变更，配合相关人员进行变更需求调研，并确认变更需求。在执行计划中，确认变更实施计划满足时间、成本和质量等要求。（二）系统运维专员：负责对用户进行变更需求调研，根据需求给出初步的解决方案，并组织变更评审。在执行计划中，负责制定和组织执行变更实施计划。（三）变更评审小组：由信息部门负责人根据变更内容确定人员组成，负责对最终是否进行变更给出评价，并确定最终变更方案。（四）运维支持团队：分为内部支持团队和外部支持团队，分别负责公司内部和厂商的具体实现。第五条变更管理变更管理流程分为：变更申请、变更需求调研、变更方案建议、变更评审、制定变更计划、确认变更计划、执行变更计划、变更交付八个步骤：

1．变更申请：由变更申请人根据变更类型进行变更申请，并将变更申请发送给系统运维专员。 2．变更需求调研：由系统运维专员组织调研，在变更申请人配合下，完成对变更需求的调研分析。 3．变更方案建议：由系统运维专员根据变更需求，给出初步的方案建议。 4．变更评审：由信息部门负责人确定变更评审小组成员，评审中修改并确定变更的实施方案，小型变更由部门负责人审批，大、中型变更由信息分管领导审批。 5．制定变更计划：由系统运维专员根据已审批的方案，联系内部或外部支持团队，共同评估和协商，制定变更实施计划。 6．确认变更计划：由变更申请人对计划中的功能、性能、时间、成本等进行确认。 7．执行变更计划：由运维支持团队执行系统变更的具体实现工作。 8．变更交付：在进行测试后，由系统运维专员进行成果交付。如果交付的成果未达到申请人要求，再重新申请变更。第六条本办法由集团公司办公室负责解释。第七条本办法自发布之日起执行。

信息化系统变更管理规定

信息化系统变更管理规定文件编码（GHTU-UITID-GGBKT-POIU-WUUI-8968）

信息系统变更管理办法 1、目的与依据：依据《信息化管理控制程序》文件要求，为规范信息系统变更与维护管理，提高信息系统管理水平，优化信息系统变更与维护管理流程，特制定本办法。 2、使用范围：信息系统有了新的IT特性和服务可用性，或显露新的威胁和脆弱性的一个后果，如：新规程、新特性、软件更新、硬件更新、新用户及附加网络和互连。 3、术语/定义：信息系统变更：由软件变更和硬件变更组成。软件变更：软件已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理组织之后，所发生的软件系统运行支持及变更工作。硬件变更：当硬件设备采购完成并安装调试完成后，所发生的硬件系统运行支持及变更工作。 4、职责分工： 4.1企管信息部： 4.1.1负责信息系统变更过程的组织、实施及培训。 4.1.2负责规划和分配变更所需的基础设施资源； 4.1.3负责制定系统变更风险控制管理； 4.2 科技管理部 4.2.1 负责对信息系统变更过程中产生的资料进行归档保存； 4.3 业务单位 4.3.1 负责整理信息系统变工需求并填写《系统变更申请表》；

4.3.2 负责配合信息系统变更测试并填写《用户测试报告》； 4.3.3 负责配合完成信息信息系统变更相关培训。 5、工作程序： 5.1 信息系统变更需求由业务单位提出《系统变更申请表》（附件一）交主管部门审批； 5.2《系统变更申请表》审核完成后由由企管信息部和业务部门共同完成变更前期准备工作并； 5.3 企管信息部根据相关需求编制变更计划或方案，组织业务部门在测试环境中完成测试工作； 5.4信息系统变更提出单位根据变更计划或方案填写《用户测试报告》（附件二），提交业务部门负责人和IT主管领导签字确认通过； 5.5 在进行软件变更前必须对原系统进行文件级冷备份； 5.5 信息系统变更过程根据变更范围参考相关管理办法执行：软件变更依据《信息化软件开发管理办法》或《信息化系统实施管理办法》执行，硬件变更依据《信息化硬件设备管理办法》或《信息化设备维修工作流程》执行； 5.6 在信息系统变更完成后，系统管理员和业务部门的最终用户共同撰写《程序变更验收报告》（附件三），经业务部门负责人签字验收后，报送主管部门审批。 5.7 组织业务部门对新的信息系统进行相关培训； 5.8 信息化系统变更过程中产生的资料（如：参数配置、变更记录等）交科技管理部进行归档以备查询。 5.9 信息系统变更流程示意图： 6、相关支持性文件： 6.1 《信息化软件开发管理办法》 6.2 《信息化系统实施管理办法》

软件需求开发申请表

软件需求申请表申请单号：________________ 申请日期：__________________ 部门：________________ 负责人：__________________ 需求类型：□新增□变更□删除□其他_________________ 需求详细内容：附件截图：

甲方单位意见：期望完成日期：______________ 需求描述是否准确：□是□否负责人签字确认：______________________ 备注：__________________________________________________ 项目组意见：预完成时间：________________ 预测试日期：_______________ 项目组负责人签字：_____________________ 备注：__________________________________________________ 研发部回复：预计完成时间：_______________ 预计测试时间：______________ 需求是否可行：□是□否需求描述是否准确：□是□否负责人签字确认：__________________________________________ 备注：___________________________________________________ 项目组测试意见：功能测试情况：□非常不满□不满意□满意□非常满意测试意见：_________________________________________________ 测试人签字：_______________________测试时间：______________ 甲方验收意见：功能测试情况：□非常不满□不满意□满意□非常满意验收意见：_________________________________________________ 验收人签字：_______________________验收时间：______________

软件需求变更

编号：XZ174 软件需求（变更）通知书委托方项目责任人签字：受托方项目责任人签字：＿＿＿年＿＿月＿＿日＿＿＿年＿＿月＿＿日说明：该变更通知书一式两份，委托方、受托方各执一份。

附件：清欠车辆录入模块：录入界面 1、其中，基本情况栏中的内容为自动获取，清欠情况为手工录入且非空。 2、清欠情况中，清欠方式为单选项。 3、当选择为开元汽车清欠时，清欠单位显示为：风险部，当选择为省公司清欠时，通过录入该信息的账号获取其所属省公司，当选择为异地协助清欠、本单位清欠时，获取录入该信息的账号所属的单位。此处添加确定、取消按钮。清欠车辆确认模块：该模块以列表形式显示，显示内容为：清欠车辆审核模块：该模块以列表形式显示，显示内容为： 1、只显示已经确认过的信息，未确认信息不显示。 2、可通过清欠单位、车辆所属单位、清欠方式、清欠时间段、风险等级、是否放车、车辆处置结果进行查询。 3、可导出查询后的结果，或导出所有明细。 4、列表显示规则为以时间排序，以降序排列。该模块点击查看后，显示内容为：

就地全面销售管理

自清欠之日（确认后）起10日内未完成销售（未审核），自第11日，该车辆资料自动转到车辆就地全面销售模块，同时增加销售价格项及车辆处置方式。所属省公司销售管理自清欠之日（确认后）起30日内未完成销售（未处置），自第31日，该车辆资料自动转到车辆省公司销售模块，同时增加销售价格项及车辆处置方式。移交车辆自清欠之日（确认后）起90日内未完成销售（未处置），自第91日，该车辆资料自动转到移交车辆模块，该模块可使用目前ERP中的移交车辆管理模块。中心销售管理待移交车辆审核确认后，该车辆信息转到中心销售管理模块下。统计汇总模块以省公司为单位，统计各阶段车辆数量，并允许导出所有车辆明细（清欠阶段为已确认车辆）具体显示表格如下：

个人基本信息变更申请表

个人基本信息变更申请表单位名称（公章）：单位编号：申请人：经办人：填表日期：年月日说明：一、单位为职工更改基本资料，请填写本表“变更项目”的“原内容”栏和“变更后内容”栏。二、所需材料 1、变更参加工作日期：提供《广州市养老保险被保险人视同缴费年限审核表》或《广州市职工连续工龄审核表》(原件,或托管部门加盖公章，注明“与原件相符”的复印件，并经托管部门的主管人及经手人签名，用信封密封后加盖骑缝章）。 2、如变更档案出生年月：提供参保人的人事档案中最早记载该参保人出生年月的档案材料，无人事档案的，由社保经办机构开具《人事档案协查函》或《户籍档案协查函》（原件，《人事档案协查函》或《户籍档案协查函》须经协查部门加意见并盖章）。 3、如变更参加养老保险时间：提供职工首次投保的《增减员表》或有效证明首次参保时间原始材料（原件） 4、如变更法定退休日期：提供提前或延迟退休的批文原件。 5、如变更军转干部身份：提供《军队干部转业审批报告表》原件。 6、如增加或修改技术职称、技术等级：提供《技术职称资格证书》原件；如不能直接认定需提供《专业技术资格评审表》原件。 7、如变更退休人员的证件号码、姓名：提供有效身份证明原件，有效身份证明，具体包括具体包括居民身份证、社会保障卡、港澳居民来往内地通行证、台湾居民来往大陆通行证、护照等任意一种。 8、如变更退休人员的户口性质：提供《户口簿》原件。 9、如变更参保状态：提供有效身份证明及地税参保或停保凭证原件，有效身份证明，具体包括具体包括居民身份证、社会保障卡、港澳居民来往内地通行证、台湾居民来往大陆通行证、护照等任意一种。 10、如变更个人身份：提供有记载参保人个人身份的《劳动合同》或《变更劳动合同协议书》，无记载的，提供单位出具的个人身份证明材料(原件)；改变股东身份的，提供股权变更证明（原件）；机关、事业单位干部、工勤人员变更身份，需带人事局确认其身份的批准文件（原件）。 11、如变更联系方式、居住地址、邮政编码、电子邮箱：可自行在网上办事大厅修改，或填写申请表由前台办理。

系统变更申请单

CMMP系统变更申请单

任务完成描述：（对完成任务的正确性和质量进行检查） 2013-4-16 1、菜单【检验员维护】，只能更改（维护）检验员列，其它信息不能更改，尤其保管员等不能更改。复测：没有完成，保管员照样可以修改。（我后台做了设置，可以更改，但是不会保存的）复测：完成 2、将菜单【不合格原因维护】改为，【不合格分类】。复测：将“原因”改为“分类”；如下图复测：完成 3、【待检送验单】选中某送检单双击后，在进行检验时，在列“不合格原因”前增加“不合格分类”列，其中不合格分类列通过不合格分类表下拉列表进行选择；不合格原因手工输入。不合格数量+合格数量不一定=送检数，在此不要做限制。要求数量都大于0，且为整数，但合格数量+不合格数量不能大于送检数。复测：缺少bhjyy列，SQL代码呢？？（在cl_sjd中加入bhgyy字段varchar（100））复测：不合格数量+合格数量不一定=送检数，在此不要做限制。要求数量都大于0，且为整数，但合格数量+不合格数量不能大于送检数；此功能没有实现。复测：列明xh1无效，是不是又缺字段啦（不好意思，好忘，在cl_sjd里面要加入一个字段 xh1,char(20)）。Jysj datetime 复测：不合格数量+合格数量不一定=送检数，在此不要做限制。（已经实现）要求数量都大于0，且为整数，但合格数量+不合格数量不能大于送检数；此功能没有实现。

复测：当不合格品数大于0时，必须输入不合格分类和原因；当为0时，不能不合格分类和原因，否则会影响后面的统计。复测：完成 4、【不合格品处理】的处理方式，通过下拉列表的方式实现；且将【送检】按钮放在【保存】的前面。本界面的数据提取时，只提取不合格数量＞0的，不要把过检数据全部提取出来。复测：解决；另再增加一个菜单【不合格品处理查询】，内容为只读，以便划分权限。复测：完成 5、【过检待记账】，双击后要把单号带出来；带出来的合格数量、不合格数量不正确。其中实收正品数量的默认值为合格数量。复测：没有解决；若很难修改，建议只带出送检单号也可以；另合格数量、不合格数量信息带出来的不对，和当时的过检数量不一致。（就是因为带出送验单号后，回车带不出相关单号的信息，所以我又去掉了，得改动很大，要真想改的话我仔细看看代码改改，改好后发给你）复测：弹出的界面如下图所示，没有将过检后的合格数量、不合格数量带出来；且实收正品数的默认值=合格数量。实收正品数不能大于合格数量。点击记账时，弹出如下界面，不允许记账。复测：实收正品数量的默认值应该=过检后的合格数量。复测：完成。 6、“不合格信息汇总”还没有做。复测：不合格信息汇总要严格按照需求中提供的格式罗列。另：编号要系统自动生成。格式为：2011-08-001，系统自动判断，为主键。目前系统中提取的数据不对，应该只提取不合格数大于0的数据。复测：完成

信息系统变更发布配置管理制度及相关记录

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

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