针对本项目,我司认为项目的目标是在合理的成本范围内最大限度的保障企业的业务运营,同时为业务创新提供必要技术支持,并建立一套可以持续改进的机制满足未来发展的要求。
1.1PPTPI运维目标
我司基于业内领先的ITIL最佳实践,结合专业厂商的MSF服务框架,建立了一套符合中国企业的IT系统运维服务体系,从技术视角、业务视角和服务视角来分析IT运维的目标,满足企业全方位的运维需求,助力于企业的IT系统级别、业务连续性、安全可靠性及用户满意度等多方面提升。
我司IT运维体系的目标
项目运维的目标是在合理的成本范围内最大限度的保障企业的业务稳定运营,同时为业务创新提供必要技术支持,并建立一套可以持续改进的机制满足未来快速发展的要求。
1.2PPTPI体系框架
P-服务流程
Process服务流程对运维服务的工作内容及作方法提供指导并提出明确的规定,运维管理工作在相关服务流程的指导和约束下,才能有效的为信息系统提供运维服务。服务流程包括技术服务和流程规范两大部份,技术服务定义工作内容,流程规范定义工作方法。
我司日常运维服务内容与流程
P-运维服务人员组织
运维管理工作必须由人来执行,People人员组织定义了执行运维管理工作的人员组成架构,以及人员的工作职责、工作技能要求,并对人员的绩效考核提出明确的指标。
T-项目平台涉及的技术
Technology信息技术是信息系统运维工作中涉及到的技术,包括支撑信息系统运行的软硬件和运维管理工作所需的管理工具。对信息技术的熟练掌握是信息系统运维的前提。
P-跨厂商的合作伙伴
在信息技术高速发展的时代,信息系统变得越来越庞大和复杂,单靠企业内部人员及平台运维人员,不可能解决信息系统运行过程中的所有问题,必须借助于外部力量,也就是Partner合作伙伴。
I-企业信息系统
Information信息系统是IT运维服务的对象,是整个运维体系的核心,运维工作的最根本目的就是保障信息系统正常稳定运行,从而保障业务连续性。
企业通常包含的信息系统如下:
2.项目管理方案
2.1项目范围管理
项目范围管理包括确保项目做且成功完成项目所需的全部工作的各过程。管理项目范围主要在于定义和控制哪些工作应包括在项目内,哪些不应包括在项目内。图概述了项目范围管理的各个过程,包括:
1.收集需求——为实现项目目标而定义并记录干系人的需求的过程。
2.定义范围——制定项目和产品详细描述的过程。
3.创建工作分解结构——将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。
4.核实范围——正式验收项目已完成的可交付成果的过程。
5.控制范围——监督项目和产品的范围状态、管理范围基准变更的过程。
上述过程不仅彼此相互作用,而且还与其他知识领域中的过程相互作用。基于项目的具体需要,每个过程都可能需要一人或多人的努力。每个过程在每个项目中至少进行一次,并可在项目的一个或多个阶段(如果项目被划分为多个阶段)中进行。
在项目的环境中,“范围”这一术语有两种含义:
1.产品范围——某项产品、服务或成果所具有的特性和功能。
2.项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
管理项目范围所需的各个过程及其工具与技术,因应用领域而异,并通常作为项目生命周期的一部分加以确定。经批准的详细项目范围说明书以及相应的工作分解结构、工作分解结构词典,构成项目的范围基准。然后,在整个项目生命周期中,对这个基准范围进行监督、核实和控制。
●收集需求
收集需求是为实现项目目标而定义并记录干系人的需求的过程。仔细掌握和管理项目需求与产品需求,对促进项目成功有重要作用。需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始,就应该足够详细地探明、分析和记录这些需求,以便日后进行测量。收集需求旨在定义和管理客户期望。需求是工作分解结构的基础。
●定义范围
定义范围是制定项目和产品详细描述的过程。详细项目范围说明书的编制,对项目成功至关重要。应该根据项目启动过程中记载的主要可交付成果、假设条件和制约因素,来编制项目范围说明书。在规划过程中,由于对项目有了更多的了解,所以应该更具体地定义与描述项目范围。应该分析现有风险、假设条件和制约因素的完整性,并在必要时补充其他的风险、假设条件和制约因素。
●创建工作分解结构
创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构是以可交付成果为导向的工作层级分解,其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。
●核实范围
核实范围是正式验收项目已完成的可交付成果的过程。核实范围包括与客户或发起人一起审查可交付成果,确保可交付成果已完成,并获得客户或发起人的正式验收。
●控制范围
控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。对项目范围进行控制,就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时,也要采用范围控制过程来管理这些变更。控制范围过程需要与其他控制过程整合在一起。未得到控制的变更通常被称为项目范围蔓延。变更不可避免,因而必须强制实施某种形式的变更控制。
2.2项目沟通管理
项目沟通管理包括为确保项目信息及时且恰当地生成、收集、发布、存储、调用并最终处置所需的各个过程。项目经理的大多数时间都用在与团队成员和其他干系人的沟通上,无论这些成员和干系人是来自组织内部(位于组织的各个层级上)还是组织外部。有效的沟通能在各种各样的项目干系人之间架起一座桥梁,把具有不同文化和组织背景、不同技能水平以及对项目执行或结果有不同观点和利益的干系人联系起来。下面概述了项目沟通管理的各过程,包括:
1.识别干系人——识别所有受项目影响的人员或组织,并记录其利益、参与情况和成功的影响项目的过程。
2.规划沟通——确定项目干系人的信息需求,并定义沟通方法的过程。
3.发布信息——按计划向项目干系人提供相关信息的过程。
4.管理干系人期望——为满足干系人的需要而与之沟通和协作,并解决所发生的问题的过程。
5.报告绩效——收集并发布绩效信息(包括状态报告、进展测量结果和预测情况)的过程。
识别干系人
识别干系人是识别所有受项目影响的人员或组织,并记录其利益、参与情况和对项目成功的影响的过程。项目干系人是指积极参与项目,或其利益可能受项目实施或完成的积极或消极影响的个人和组织,如客户、发起人、执行组织和公众。他们也可能对项目及其可交付成果施加影响。
规划沟通
规划沟通是确定项目干系人的信息需求,并定义沟通方法的过程。规划沟通过程旨在对干系人的信息和沟通需求做出应对安排,如谁需要何种信息,何时需要,如何向他们传递,以及由谁传递。虽然所有项目都需进行信息沟通,但是各项目的信息需求和信息发布方式可能差别很大。识别干系人的信息需求并确定满足这些需求的适当方法,是决定项目成功的重要因素。
发布信息
发布信息是按计划向项目干系人提供相关信息的过程。在整个项目生命周期和全部管理过程中,都要开展本过程。这里重点讨论执行过程中的信息发布,包括执行沟通管理计划以及应对未预期的信息需求。
管理干系人期望
管理干系人期望是为满足干系人的需要而与之沟通和协作,并解决所发生的问题的过程。管理干系人期望涉及针对项目干系人开展沟通活动,以便影响他们的期望,处理他们的关注点并解决问题。
报告绩效
报告绩效是收集并发布绩效信息(包括状态报告、进展测量结果和预测情况)的过程。绩效报告过程包括定期收集、对比和分析基准与实际数据,以便了解和沟通项目进展与绩效情况,并预测项目结果。
2.3项目现场行政管理及安全管理
管理要求
我司服务人员到场服务时,需严格遵守甲方公司的相关行政管理和安全管理规定。包括不限于在规定的固定区域办公,需佩戴工牌等。
安全管理
我司严格遵守甲方公司的安全管理规定,如出现包括安全生产事故和其它影响到中国移动的事件。发生下列情形之一的,甲方有权终止本合同,扣除合同预估总价的10%作为考核款:
●乙方在维护过程中未遵照安全生产条例规范操作,发生安全生产事故;
●发生人员伤亡安全责任事故;
●发生严重违约行为;
●因乙方原因导致重大IT系统故障;
●因乙方维护不当导致的大面积投诉;
●因乙方原因发生媒体曝光事件、影响到我公司的劳资纠纷;
●发生代维人员偷盗通信设备;
●乙方人为阻挠考核人员进行现场检查或者采取欺骗、作弊等手段误导考核结果致使维护考核工作无法正常开展。
我司承诺遵守上述安全管理要求。
2.4项目变更管理方案
在项目实施过程中,如果需要进行项目的范围、时间计划、人员等方面的变更,需要由变更发起人提交变更申请单给到项目的变更委员会;
项目的变更委员会由甲乙双方的项目总监或业务主管、项目负责人等组成,项目经理与项目变更委员会共同评估项目变更可能带来的工作量的变化,并商讨出执行项目变更的方案,例如是在本期项目中增加成本、置换某些功能来实现,还是将变更的内容延后到项目二期中实现,等等。
以下为我司项目变更流程书,我司在项目中完全找该变更管理书进行实施;此外,在我司项目质量保障实施中,也有针对项目中变更而实施的质量保障措施。
变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。
对项目的变更管理是通过对以下五个关键步骤的实施引入的。
✓提交和接收变更申请
✓审核和记录变更申请
✓确定变更申请的可行性
✓批准变更申请
✓实施和结束变更申请
变更流程
提交变更申请
本步骤中项目团队中的任何成员都可以提交项目变更申请,需要完成以下工作:
✓变更申请人识别项目中任何方面的变更需求(如范围、可交付成果、时限、组织).
✓变更申请人完成变更申请表(CRF),并将其呈交变更经理。变更申请表对需要进行的变更做一概述,包括:
●变更描述
●变更原因(包括商业驱动)、变更利益、变更成本
●变更带来的影响、支持性文件
审核变更申请
本步骤授权变更经理对变更申请表进行审核,以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是:
✓呈交的可选择变更数目
✓申请变更可选反性的复杂程度
✓提出的变更解决方案的衡量
变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。
识别变更可行性
本步骤涉及完成一份完整的变更可行性研究,以确保对所有的变更可选项进行调查并上报,变更可行性研究包括对以下各项的定义:
✓变更需求
✓变更可选项
✓变更成本及利益
✓变更风险及事项
✓变更带来的影响
✓变更的建议和计划
对对可行性研究进行认真审核以确保研究是切题的,同时确保(经过变更后的)最终的可交付成果是可以通过的—那研究报告就可以上报变更审批小组了。变更经理将整理所有变更文件并报变更审批小组做最终审核。这些文件包括:
✓原始的变更申请表
✓已通过的变更可行性研究报告
✓所有支持性文件
批准变更申请
本步骤涉及变更审批小组对变更申请的正式审核。变更审批小组可能做出下列任何一种结论:
✓拒绝变更
✓要求与变更相关的更多信息
✓批准变更申请
✓在特定条件下批准变更
决定是否变更的标准大致为:
✓实施变更给项目带来的风险
✓不实施变更给项目带来的风险
✓实施变更对项目产生的影响(时间、资源、财务、质量方面)
实施变更申请
本步骤涉及对变更的全面实施,包括:
✓确定变更进度(如:实施变更的日期)
✓实施前对变更进行测试
✓实施变更
✓对实施变更的成功度进行审核
✓就实施变更的成功度进行沟通
✓在变更日志中结束变更
实施变更申请
对项目中启动、审核和实施变更所涉及的所有资源(包括项目中或项目之外的资源)的职责和责任进行定义。
变更申请人
变更申请人最初意识到对项目进行变更的必要性并就此需求与变更经理进行正式沟通。其主要职责为:
✓及早识别对项目进行变更的需求
✓通过完成变更需求表来完成对更申请的正式文件 将变更申请表提交变更经理以供审
变更经理
变更经理对一个项目中所有的变更进行接收、记录、监测和控制。其主要职责为:
✓接收所有的变更申请并将其记录于变更登记簿中
✓将所有的变更申请进行分类、优选
✓审核所有变更申请以确定在提交变更审核小组前是否还需增加有关信息
✓确定是否需要进行一个正式的可行性研究并提交变更审核小组
✓通过委派变更可行性研究小组来启动变更可行生研
✓对所有的变更申请进展情况进行监测以确保项目按时完成
✓将所有的变更申请问题和风险上报变更审批小组
✓就变更审批小组做出的所有决定进行下达和沟通
变更可行性研究(可研)小组
变更可行性小组负责完成由变更经理签发的对于某变更申请的正式的可行性研究,主要职责为:
✓通过进行摸拟研究来确定变更可能的要素:成本、利益和变更带来的影响。
✓将变更可行性研究报告中的所有发现形成文字
✓对报告进行认真审核并批准交其上报。
✓将报告转变更经理以提交变更审批小组
变更审批小组
变更审批小组决定是否批准变更经理转来的所有变更申请。其主要职责为:
✓审核变更经理转来的所有变更申请
✓考虑所有变更支持性文件
✓根据每个变更申请的相关价值决定批准还是拒绝
✓解决变更争议(当两个或两以上变更撞车时)
✓解决变更问题Resolving change issues
✓决定实施变更时间表
变更实施小组
变更实施小组对项目中所有变更的实施进行计划、落实和审核。变更实施小组主要负责:
✓计划所有变更的进度(在变更审批小组提供的总体时间框架范围内)
✓在实施前对所有变更进行测试
✓实施项目中的所有变更
✓实施后审核变更的成功度
✓在变更日志中请求结束变更
变更登记簿
变更登记簿是用于登记、跟踪变更申请进展情况的日志/数据库。描述项目变更登记簿的目的和用途,在下面插入一个真实的变更登记文本
变更模板
插入所需的每个模版(如变更申请表)以对项目中变更的效果加以启动、执行、实施和考量。
2.5信息安全管理
驻场人员须与企业签订保密协议,约束驻场人员的行为,防止企业重要数据或信息外泄。
如果因为我司原因发生重要文件泄密事件或引发重大安全事故,企业有权立即中止合同并保留追究相关法律责任的权利,自合同终止起不再支付费用。
相关秘密资料包括以下由企业向我司通过口头、书面、电子或其他方式提供的关于技术和系统安全及其他方面的一切数据、报告、信息、翻译资料、预测和记录等内容:
企业的机构设置和运行机制。
企业的电子设备及其它辅助产品、安全产品的型号、数量、配置、运行状态、交易日志等资料。
企业应用系统名称、功能、业务类型、交易量、交易特征、交易方式、交易数据、系统测试及试运行期间的客户资料等信息。
企业的现有网络拓扑结构及其相关资料,包括网络参数,如IP地址,命名规则等。
企业的业务流程、逻辑流程、规章制度等资料。
企业计算机系统的漏洞信息。
企业现有安全机制及规划目标、所有系统的应急方案。
企业的技术方案、项目文档及工程文档。
企业的应用系统接口程序与文档。
企业与我司的合作信息、合同。
员工信息意识建立及信息安全培训
1)遵守安全使用信息设备规则
员工能够遵守安全使用信息设备的规则,是维护企业信息安全性的基石。我司在丰富的项目实施中,已积累了一套成熟的信息安全管理规程。在此基础上,我司将定期对团队成员进行信息安全管理规程办法考察,使我司员工持续了解并遵守安全使用信息设备规则。
2)树立员工企业信息安全意识
我司根据员工岗位的特点,有针对性的进行安全信息的宣传。从员工入职开始一直到项目实施,持续进行专项培训。
我司团队定期组织信息安全意识培训,同时树立并且落实监督奖惩机制。在主动预防意识和被动防范意识两方面树立起员工的安全意识。
3)明确企业安全事故的后果和责任
我司除了在培训时,明确并强调安全事故的责任及后果。并且不定期向所有员工宣传说明近期业内的信息安全事故,引以为戒。如果出现信息安全事故,我司将严格按照规章执行,在员工意识中树立了深刻的事故后果责任意识。
我司信息安全管理规程
我司为加强人员信息安全的管理,甲方信息安全,特制定如下信息安全管理规程。
1)工程师须严格遵守公司的安全管理规范。
2)公司IT项目将签订保密协议。
3)对需要保密的技术资料、数据应加强保管,避免无关人员接触。
4)不得擅自向外传播和介绍客户和项目情况。
5)明确职责,对于非本人工作职权范围内的机密,做到不打听、不猜测,不参与小道消息的传播。
6)非经发放部门或文件管理部门允许,外包人员不得私自复印和拷贝有关文件。
7)树立保密意识,涉及开行秘密的书籍、资料、信息和成果,应妥善保管,若有遗失或失窃,应立即向公司主管领导汇报。
8)发现其他员工有泄密行为或非本公司人员有窃取机密行为和动机,应及时阻止并向公司主管领导汇报。
9)不在非工作计算机设备中存放涉及公司秘密的文件。
信息安全保障技术防范
对于企业IT基础架构相关系统建设的安全管理,我司有以下建立和规范需要双方共同努力执行:
1)网站服务器和其他计算机之间设置经认证的防火墙, 并与专业网络安全公司合作,做好安全策略,拒绝外来的恶意攻击,保障网站正常运行。
2)在网站的服务器及工作站上均安装了正版的防病毒软件,对计算机病毒、有害电子邮件有整套的防范措施,防止有害信息对网站系统的干扰和破坏。
3)做好生产日志的留存。网站具有保存60天以上的系统运行日志和用户使用日志记录功能,内容包括IP地址及使用情况,主页维护者、邮箱使用者和对应的IP地址情况等。
4)交互式栏目具备有IP地址、身份登记和识别确认功能,对没有合法手续和不具备条件的电子公告服务立即关闭。
5)网站信息服务系统建立双机热备份机制,一旦主系统遇到故障或受到攻击导致不能正常运行,保证备用系统能及时替换主系统提供服务。
6)关闭网站系统中暂不使用的服务功能,及相关端口,并及时用补丁修复系统漏洞,定期查杀病毒。
7)服务器平时处于锁定状态,并保管好登录密码;后台管理界面设置超级用户名及密码,并绑定IP,以防他人登入。
8)网站提供集中式权限管理,针对不同的应用系统、终端、操作人员,由网站系统管理员设置共享数据库信息的访问权限,并设置相应的密码及口令。不同的操作人员设定不同的用户名,且定期更换,严禁操作人员泄漏自己的口令。对操作人员的权限严格按照岗位职责设定,并由网站系统管理员定期检查操作人员权限。
9)公司机房按照电信机房标准建设,内有必备的UPS不间断电源、高灵敏度的烟雾探测系统和消防系统,定期进行电力、防火、防潮、防磁和防鼠检查。
2.6项目交付管理
项目交付要求
我司科技在合同规定时间内,向企业提供相应资料及服务报告,包括:每日和每月巡检报告、故障分析报告、漏洞整改报告、系统配置表、日常维护记录等。
并在项目结束后,整理好文档并打包移交给企业。
序号 | 工作类别 | 维护内容及维护方式描述 | 交付物 | 频率 |
1 | 日常服务支持 | 工作日驻场维护服务,提供平台软硬件系统测试、调优、变更等服务,系统健康状态检查、系统故障诊断及处理。 | 变更方案,工作报告,运维服务审计相关文档,保供电和运维提升专项服务材料 | 按照具体工作项 |
2 | 定期巡检 | 按照甲方要求的频率对不同的运维对象进行定期巡检。 | 巡检报告 | 按照甲方具体要求 |
3 | 故障处理 | 提供故障支持服务,10分钟内可以远程VPN响应,60分钟内到达现场的技术支持。 | 故障处理报告 | 按照故障提供 |
4 | 安全漏洞处理及修复服务 | 根据公司定期的漏洞通报及时开展漏洞整改工作。 | 漏洞整改报告 | 按照安全科通报漏洞提供 |
5 | 系统配置维护 | 定期维护维护范围内CMDB、资产配置表、设备物理标签、ITSM系统等配置信息的准确。 | 系统配置表 | 按照维护对象提供 |
项目实施完成后,我司科技将向企业提交项目所要求的各项文档内容,包含如下文档:
2.6.1.1巡检报告样例(健康检查工作记录)
以下是VMware月度巡检报告部分样例:
2.6.1.2项目管理计划
我司提供项目启动管理计划样例如下,实际为企业提供的项目启动管理计划将依照企业实际情况编写:
我司项目管理计划组图
2.6.1.3系统试运行报告
我司提供系统试运行报告样例如下,实际为企业提供的系统试运行报告将依照企业实际情况编写:
我司系统试运行报告样例
2.6.1.4系统测试报告
我司提供系统测试报告样例如下,实际为企业提供的系统测试行报告将依照企业实际情况编写:
我司试运行报告样例
2.6.1.5阶段性总结报告
我司提供系统实施阶段性总结报告样例如下,实际为企业提供的系统实施阶段性总结报告将依照企业实际情况编写:
项目阶段性总结报告样例
2.6.1.6系统问题跟踪列表
我司提供系统问题跟踪列表样例如下,实际为企业提供的系统问题跟踪列表将依照企业实际情况编写:
问题跟踪列表样例
2.6.1.7项目总结报告
我司提供项目总结报告样例如下,实际为企业提供的项目总结报告将依照企业实际情况编写:
项目总结报告样例
2.6.1.目回顾总结
我司提供项目验收报告样例如下,实际为企业提供的项目验收报告将依照企业实际情况编写:
2.7项目验收管理
验收标准
项目结束后,企业应在收到我司验收申请后十个工作日内答复我司并组织验收,验收通过后提供验收报告。
双方确定以下列标准和方式对我司的维护服务工作成果进行验收:
1)我司完成维护服务工作的形式:我司应按照验收标准的要求对每月(或每季)的维护工作内容进行小结,编写小结报告并提请企业确认;对于重大的维护工作内容,我司也应及时提请企业确认,相关文档作为验收的重要凭据。
2)维护服务工作成果的验收标准:见项目的合同条款。
3)维护服务工作成果的验收方法:本维护项目按合同规定完成后,企业应当及时进行验收。我司应当以书面方式向企业递交维护项目验收申请书,企业在收到验收申请书后的10个工作日内,确定具体日期,由双方按照项目合同规定的验收标准完成验收。
4)验收的时间和地点时间由甲方确定,地点在维护服务对象所在地范围内。
验收过程
验收能检验投标方提供的项目成果和交付件是否能符合企业的需要,验收将在投标方按计划提交成果后,按照客观性、完整性和可行性标准进行验收;如果验收不合格,投标方将按照企业提供的意见进行修改,直到再次验收合格。
各阶段的成果在各阶段结束提交企业后,由企业组织验收。验收依据为本招标文件和中确定的具体验收标准。
项目验收及承诺
我司承诺,按照企业招标书的验收标准和过程启动项目验收工作,完成相关项目的交付物提交。
项目文档和知识移交
序号 | 服务内容 | 工作文档交付物 | 交付时间 | 频率 |
1 | 故障处理及分析服务(监控、检查发现问题的处理以及受理的问题处理) | 《操作系统故障处理报告》 | 故障发生2个工作日内 | 按需 |
2 | 系统部署、升级(包括硬件扩容、更换,操作系统升级引发的应用软件重新部署及相关配合工作。) | 《操作系统部署报告》 《操作系统升级操作报告》 | 操作完成3个工作日内 | 按需 |
3 | 巡检服务(系统例行巡检) | 《巡检及性能分析报告》 | 每月10日前 | 按月 |
4 | 其他文档(配合其他工作,如安全检查或分析系统故障或问题等) | 《操作系统补丁故障等检查建议和操作步骤报告》 | 不定期 | 按需 |
5 | 月维护报告(包括系统优化、运行状况等在内的整体工作总结报告) | 《月度维护报告》 | 每月10日前 | 每月 |
如果项目结束后需要更换服务商,我们将严格按照项目移交管理规范来实施交接,秉承一切以客户为中心的宗旨。
现以我司作为新的服务商角色来描述整个交接的管理(项目结束后如果要更换服务商,则我司的角色改为现维护商)
交接目的:
根据项目规范化管理的要求和信息化项目的持续发展,本标准意在进一步规范项目与运维的顺利交接,及提高交接效率,提高客户满意度;
交接参与人员:
原企业运维团队、现维护商、企业主管部门、PMO(交接项目管控组,由三方项目经理或高层组成);
交接原则:
✓项目交接前,入场维护商项目经理必须按照项目性质制定交接内容,交接计划;
✓PMO审核项目交接内容和计划,并通知原企业运维团队配合完成交接;
✓交接期间如出现纠纷,由PMO协调处理;
✓原企业运维团队项目经理及成员必须认真对待项目交接工作,按照交接要点进行内容交接;
✓原企业运维团队项目经理和成员要无条件的担负与运维人员的交际的责任,如出现交接争议,需及时反馈到PMO组进行裁定;
✓由原企业运维团队每天反馈交接进度,并汇报给企业交接部门;
✓原企业运维团队交接内容必须得到现维护商和企业交接部门认可签字,方可通过;
✓现维护商有义务和责任积极了解现有IT架构、运维内容等信息,并主动配合参与交接内容的商定;
✓交接工作需严格遵守交接计划安排,原则上不超过1个月;
✓交接期间,IT系统正常稳定运行仍然有原企业运维团队负有直接责任,现维护商协助运维,并在交接完成后承担IT系统正常运行的直接责任;
交接内容至少包含如下模块:
✓IT系统配置信息交接;
✓日常维护工作交接(包含流程、制度、具体维护事项、方法等);
✓遗留问题交接;
✓专项工作交接;
✓IT系统账号交接;
✓介质、物品交接;
✓文档交接;
服务交付目标
一套理念
学习客户现有的运维体系和战略,从IT服务出发支撑客户精细化、标准的运维需求
一套体系
结合客户环境建立一套知识传递、能力转移体系,保证服务团队稳定和可持续性发展
一种机制
通过IT服务团队与客户管理团队的融合,形成一个完善的沟通、管理和问题处理的高效管理机制
一个团队
配备优秀的服务团队,通过理念、体系和机制的三方面统一,跟客户IT团队形成一个一体的服务团队,从而实现服务能力最大化
服务交付整体规划
工作交接详细方案
我方认为,一个完整的工作交接方案包含两个阶段的工作,一是运维接管期阶段的工作方案,二是运维试运行期的工作方案。
2.8.1.1运维交接准备期
交接时间:2个星期,10个工作日内
交接地点:企业运维办公室
工作内容:进行运维对象及运维流程的交接准备,本阶段企业现有IT运维人员和我司驻场运维团队及部分二线专家人员共同在运维现场进行工作交接。
人员投入:
●我司驻客户运维团队人力
●我司二线咨询技术支持团队人力
职责说明:原企业运维团队为主;我司驻场运维团队为辅,主要进行观摩学习
序列 | 交接模块 | 具体内容 | 交接方式 | 参与人员 | 备注 |
1 | IT系统配置信息交接 | IT组织架构; 网络架构及设备配置信息; 服务器信息; 客户机信息 活动目录(AD)架构; 基础网络服务; 企业消息系统; 文件与打印服务; 业务应用系统; External应用系统; 数据库系统; 终端应用服务; 网络安全系统; 备份与存储系统; 病毒防护系统; 补丁修补管理系统; 客户机管理系统; 服务器管理及监控系统; | 文档、讲解、演示 | 原企业运维团队 现维护商 企业项目接口人 | 原企业运维团队应尽可能对已有的配置整理形成文档交付给现维护商,无法交付的配置,双方合作完成 |
2 | 日常维护工作 | 流程与制度; 日常维护工作事项; 系统监视与控制; 维护工具的使用; 数据备份与还原; 故障响应与处理; 用户请求的满足; 问题管理; 巡检; 变更管理; 系统测试与发布; | 文档、讲解、培训 | 原企业运维团队 现维护商 | 原企业运维团队应尽可能对已有的日常维护工作形成文档交付给现维护商,无法交付的配置,双方合作完成 |
3 | 遗留问题交接 | 现有系统运行问题; 未处理或待解决问题; 其他配合事项; | 文档、讲解 | 原企业运维团队 现维护商 企业项目接口人 | 原企业运维团队应尽可能详尽汇报现有问题情况、跟进情况、待协调资源等;并一定程度上配合现维护商进行解决 |
4 | 专项工作交接 | 现有专项工作内容; 专项工作事项背景; 进展情况; 后续支持工作安排; 专项工作项目风险点和难点; | 文档、讲解 | 原企业运维团队 现维护商 企业项目接口人 | 原企业运维团队应尽可能详尽汇报现有专项工作情况、跟进情况、待协调资源等; |
5 | IT系统账户交接 | 各个IT系统维护帐号; 各个IT系统的服务账号; | 加密文档资料 | 原企业运维团队 现维护商 企业项目接口人 | 此交接尽可能放置在最后部分,账号交接完成后,现维护商应尽可能快速修改,原企业运维团队不得私自新建其他账号并遗留系统风险或漏洞; |
6 | 介质、物品交接 | 各个软硬件、驱动的安装介质; 维护工具及脚本; 相关物品; | 文件、文档、物品 | 原企业运维团队 现维护商 | 原企业运维团队应尽可能详尽交付相关的介质、工具和物品; |
7 | 文档交接 | 环境检查及评估报告; 系统管理标准、制度、规范; 系统配置文档; 各个IT子系统维护手册、故障处理手册; 系统的优化建议及方案; 运维人员工作日报、周报、月报、季度巡检报告; 技术支持报告; 重大事项处理报告; 知识传递文档及讲义; | 文档、讲解、培训 | 原企业运维团队 现维护商 企业项目接口人 | 原企业运维团队应尽可能详尽交付相关的文档; |
8 | 其他 | 其他企业强调或现维护商需要的与维护相关的内容; | 不限 | 原企业运维团队 现维护商 企业项目接口人 | 三方本着优质完成交接的目标,互相配合协调; |
●驻场运维服务团队
●维护范围内系统、资产检查清单
●交接文档,系统监控检查记录,日常维护报告,维保服务记录,系统管理手册
●服务规范标准及团队服务考核机制
风险规避:
人员:学习熟悉运维规范和系统情况
规范:设计严谨交接规范,确保接管过程平稳、安全
项目管理
负责服务团队和项目交付管理工作,根据情况协调现场团队或者其他资源,保证本项目的服务交付。
项目总监:项目总协调
项目经理:与客户负责人对接,管理服务交付团队协调资源
PMO:管控整个项目的质量及进度
技术管理
设专业能力强的工程师为组长,负责项目中具体人员、技术管理, 还负责各服务范围内容事务管理、人员培训等
一线驻场支持:
负责本项目中的具体服务日常交付工作,负责具体工作执行,按照规范、流程和指引工作
IT驻场运维组:7人,详见驻场人员角色分工
二线支持:
由专业技术人员组成,为一线人员提供远程的顾问和技术支持服务,本阶段主要的参与主要为了更快更全面的阶段外包服务的内容和范围,也为将来的顾问支持打好基础。
二线专家:10人以上,涉及不同领域的专家
其他支持:
在资源范围内,提供对服务项目所需要的一切支持
ITSM咨询:为项目提供IT服务管理规范、流程方面的指导
原厂商支持:必要时可以通过的产品代理部门向对应的原厂商购买技术支持相关服务
2.8.1.2运维交接过渡期
在这个阶段,我司驻场项目团队开始接受IT系统的运维,运维服务进入试运行阶段
持续时间:约2个星期,10个工作日内
交接地点:企业运维办公室
工作内容:根据运维情况,调整并优化项目服务团队,完善团队主备人员机制
●7*24小时值守数据中心、完成IT系统基础运维日常工作
●熟悉各类服务流程、面向服务的KPI考核制度和服务水平目标
●深化各项管理,并与客户制定应急预案和演练计划进行运维对象及运维流程的交接
人员投入:
●我司驻客户运维团队人力
●我司二线咨询技术支持团队人力
职责说明:我司驻场运维团队为主;原企业运维团队为辅,并提供必要的指引,说明和支持
阶段交付:
熟悉运维规范,了解运维流程,将现有的流程文档消化吸收,必要时提出优化建议
了解各项系统的SLA
风险规避:
人员:通过交叉培训和人员主备机制确保团队运维能力增强
规范:通过流程和KPI考核制度,流程化、规范化运维过程
一旦试运行期完成,且驻场团队能够胜任现场的系统运维,那么将进入正式的运维及优化期
工作交接时间计划
交接工程需要进行严格的控制,并遵循如下时间计划(示例),待三方确认签字后代表对应内容交接完成:
项目计划 | 计划完成日期 | 完成描述(要求:完成结果情况的简略描述,如交付结果、出现问题、后续跟进、正在进行内容的完成百分比等) | 责任人 | 实际完成日期 | 签字(原企业运维团队、现维护商、企业接口人) |
1. 操作系统配置信息 | 2020/10/10 | 示例:已完成,XX已对企业相关操作系统做了初步介绍 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
2. 日常维护工作交接 | 2020/10/15 | 示例:已完成,交付物《SEP运维工作文档交接表》 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
3. 遗留问题交接 | 2020/10/20 | 示例:现有操作系统运行缓慢问题,《操作系统运行缓慢事件进展描述》 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
4. 专项工作交接 | 2020/10/20 | 示例:现有监控平台优化事项,《优化方案》 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
5. IT系统账号交接 | 2020/10/30 | 示例:已获取,管理维护人员账号及密码。 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
6. 介质、物品交接 | 2020/10/25 | 示例:已完成,安全扫描工具介质; | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |
7. 文档交接 | 2020/10/28 | 示例:已完成,交付物《操作系统运维工作文档》 | (企业现有各运维组主管、入场维护商项目经理) | N/A | N/A |