通用投标资源分享福利--IT运维类(质保风控验收培训售后)
1 质量保障方案
1.1 质量保证方法论
我司将质量控制和过程改善工作放在突出位置,逐渐形成了较为完善的质量、成本和交付体系。我司承诺在本项目的开发过程中,将严格过程管理,对开发过程进行有效管理和监控,确保项目开发计划的有效性。
质量管理包括保证项目满足其需求所需要的过程,包括确定质量目标和职责并通过诸如质量计划、质量控制和质量改进等手段使其实施的全面管理职能的所有活动。
在项目策划阶段,项目经理和QA依据历史数据对项目的质量目标进行估计;在项目开发实施过程中,通过收集质量数据计算质量指标分析,以周例会或里程碑总结的频度监控项目的质量状况。为了保证质量目标的实现,采取缺陷预防、技术评审、同行评审和测试等多种手段来控制和确保质量。
1.1.1 质量保证原则
对于本系统主要有如下几点:
1) 在每个阶段开始时,需要对准备情况进行认真审查,并向工程领导小组汇报,确认已经具备了开始当前阶段工作所必须的条件后,才可开始该阶段的具体工作;
2) 实施中的每个阶段有阶段工作计划,具体工作中每周有工作周计划,所有计划需要经双方讨论确认并签字生效;
3) 实施中双方都应按时、圆满完成任务,并督促对方的工作;
4) 实施中每阶段结束,每周工作结束,需对原定计划进行双方参与的总结,形成总结报告,对其中未按时完成部分制定补救措施和整改计划,为下一阶段的工作做好准备;
5) 实施中所产生的需求分析文档、软件总体设计、数据库设计都必须进行评审,尽早发现问题所在,及时进行修改使后续工作能够正常进行;
6) 以上文件评审合格后由双方签署评审意见后生效,将作为下一步工作的规范和标准,用户需求原则上不应再发生变更;如遇特殊情况需要改变需求,届时由双方再协商解决;
7) 实施过程中加强沟通,包括现场工作周报,用户周报等,通过充分的信息交流了解彼此的进展情况,保证计划按时完成。
根据以上原则,在整个开发过程中,我司将运用一系列的质量保证手段保证开发质量。运用质量工具进行需求分析及软件设计,使软件易于理解、易于维护、易于测试。确保系统的正确性、完整性、实用性和高效性。
1.1.2 质量保证目标
我司承诺在本项目过程中,严格遵守国家、地方及招标文件中对要求遵循的各项标准,达到各项验收标准,实现保证合格,合格率100%,优良率95%以上。具体如下:
1) 确保软件系统的质量,能够通过专业软件测试部门的系统性测试,并达到验收标准、符合相关规范要求;
2) 确保软件质量满足系统要求,能够正常运行;
3) 确保集成工程能够满足各项指标要求,布线合理,易于维护;
4) 确保系统数据能够顺利采集,满足验收要求,满足各项标准;
5) 确保整个系统满足招标文件提出的各项标准及规范要求;
6) 确保项目保质、保量交付,并满足用户的单位的各项需求,稳定运行。
本项目的建设包括多个阶段。在每一个阶段内,用户和我司分别承担着不同的角色和任务步骤,如何保证整个工程项目能够按时、保质、保量完成是这其中最重要的问题,为此我司将全面引入CMMI5和ISO9001质量管理体系。
1.1.3 质量保证体系
1) 质量控制和保证的指导原则
(1)首先建立完善的质量保证体系,配备高素质的项目管理和质量管理人员,强化“项目管理,以人为本”。
(2)严格过程控制和程序控制,开展全面质量管理,树立创“过程精品”、“建设单位满意”的质量意识,使该项目成为我公司具有代表性的优质项目。
(3)制定质量目标,将目标层层分解,质量责任、权力彻底落实到位,严格奖罚制度。
(4)建立严格而实用的质量管理和控制办法、实施细则,在项目上坚决贯彻执行。
(5)严格执行质量检查和审批等制度。
(6)广泛深入开展质量职能分析、质量讲评,大力推行“一案三工序”管理措施即“质量设计方案、监督上工序、保证本工序、服务下工序”。
(7)利用先进的管理手段进行项目管理和质量管理和控制,强化了质量检测和验收系统,加强质量管理的基础性工作。
2) 建立有效的质量管理保证体系
按照企业的项目管理模式,以ISO标准建立有效的质量保证体系,并制定项目质量计划,推行ISO9001 国际质量管理体系标准,以合同为制约,强化质量的过程和程序管理和控制。项目经理部推行专业责任工程师负责制,在实施过程中对质量进行全面的管理与控制;使质量保证体系延伸到每个操作人员,通过明确分工,密切协调与配合,使质量得到有效地控制。
根据质量保证体系,建立岗位责任制和质量监督制度,明确分工职责,落实质量控制责任,各岗位各负其职。根据现场质量体系结构要素构成和项目施工管理的需要,成立由项目经理领导、技术负责人组织实施的质量保证体系。
1.1.4 质量保证方案
1.1.4.1 质量保证组织架构
质量保证组织架构包括项目经理、质量经理、软件测试组、软件架构设计师、设计师、实施经理、售后服务经理、以及作为公司职能部门的项目管理部。
质量保证应由项目经理全面负责,并配有专职的质量保证经理,工作职责为包括质量保证计划的制订、实施、监控等,并对质量保证过程中出现例外的仲裁。
软件测试组负责软件产品的测试流程,包括测试文档、测试工作、并监督发现问题的修改。
软件架构设计师保证系统总体架构的质量,并监督总体架构的具体实施。设计师负责各子模块的设计工作,落实软件总体架构,并负责监督设计工作的开发实现。
实施经理负责保证实施过程的质量。
售后服务经理负责保证售后服务过程的质量。
项目管理部指导项目质量保证过程,对项目质量计划的执行实施监控职责。
1.1.4.2 质量保证执行
质量保证经理会依据公司的项目工程过程裁剪工作表来确定计划中质量保证活动所参考的过程、规程、标准、方法、指南、模板、表格等等。
按照质量保证计划中确定的评审和审计方式来执行计划好的质量保证活动,在活动执行过程中,质量保证经理详细记载评审、审计活动情况、和发现的不符合问题等等。
在项目开发过程中,质量保证经理对负责向开发人员提供质量保证方面的咨询支持。
1.1.4.3 质量过程监控
在项目实施过程中,项目经理收集评审和测试过程的缺陷数据,在每周例会、里程碑总结、迭代结束、阶段结束以及项目结束时监控和评审项目的质量状况。方法如下:
l 同行评审或技术评审结束后,被评审工件的生产者将发现的缺陷数据记录在评审记录中;
l 开发人员或测试人员在完成相应的测试工作后,将缺陷数据记录在缺陷列表中;
l 模块负责人收集这些缺陷数据提交给项目经理供其进行项目级质量分析;
l 每周项目经理分析项目的质量状况,包括需求评审、设计评审、测试用例评审和测试结果。确定数量比例较大的缺陷类型,分析缺陷产生的原因,分析当前的对应措施以及今后的预防措施,并对缺陷进行横向展开;
l 在各里程碑点、迭代结束、阶段和项目结束时,项目经理总结项目质量情况,比较和预测四级质量目标的实现情况。对于目标没有或将不能实现的状况,项目经理要调整质量控制对策,分析原因启动应急措施进行处理,一般包括重新设定目标、再评审、再测试或者返工。
1.1.4.4 质量控制措施
为了保证质量目标的实现,需要从缺陷预防、技术评审、同行评审和测试几个方面加以考虑,以下分别详细进行介绍:
一、 缺陷预防
缺陷预防的目的是鉴别缺陷的原因并防止类似的缺陷再次出现,包括人工检查、自动化工具检查等,有效地实施缺陷预防包括以下几个活动:
1) 在项目策划阶段,项目经理在组织统一的缺陷预防措施基础上,根据本项目的具体情况进行调整,建立项目特定的缺陷预防措施,这些措施覆盖了项目开发的各个阶段;
2) 另外,在项目策划阶段,项目经理需要确定本项目原因分析会议的召开时机和参与人员。原因分析会议召开的原则是稳定的软件过程不能满足已确定的质量和过程性能目标;项目执行过程中,缺陷数目超出预定目标或发现大量问题;项目一个阶段完成或软件软件系统交给客户之后;
3) 在项目各项活动开展时,召开项目阶段启动会议,讲解本阶段的缺陷预防措施,确保项目成员正确理解并重视所执行活动的缺陷预防措施;
4) 按计划召开原因分析会议,分析本项目产生的缺陷数据,通过帕雷托方法和鱼骨图方法识别占有较大数量的缺陷类型的缺陷产生的根本原因,制定相应的行动计划,一方面完善软件开发过程,另一方面完善项目的缺陷预防措施。
二、 技术评审
本项目项目建立以技术骨干为核心的技术评审组,检查软件工件是否满足规格要求和相关的标准,是否能够完成预定的目标,是否可以作为下一阶段工作的输入。
技术评审组的人员包括但不限于以下人员:客户、项目经理、项目软件经理以及项目在需求分析和设计方面的技术骨干。
技术评审主要关注以下几个方面的问题:
l 软件系统能够完成预定的功能;
l 软件系统能够覆盖所有的需求;
l 软件系统符合相关的标准和规范;
l 软件工件是一致并且完整的等。
技术评审的对象主要包括需求分析报告、架构设计报告以及详细设计报告。以上软件系统只有通过技术评审才可以作为下阶段活动的输入文档。
本项目的技术评审要求召集所有技术评审组的人员开会的形式进行,会议可以现场、电话或者视频会议的形式。
三、 同行评审
同行评审的目的是为了确保及早地和高效率地从软件工件中消除缺陷, 提高软件系统的质量,降低软件开发的成本。技术评审和同行评审关注的都是技术上的问题,但技术评审的对象是一个完整的软件工件,从完备性和整体上检查软件工件。同行评审的对象一般是软件工件的部分,检查的目标是软件工件中存在的缺陷。不能通过同行评审来实现技术评审的功能,但充分的同行评审能够加快技术评审的进度,节省技术评审的时间。
为了确保评审的有效进行,本项目对同行评审的基本要求如下:
1) 指定专门的同行评审负责人,负责策划和协调同行评审活动;
2) 针对不同的软件工件设定合适的评审覆盖度和策略,如对重要模块的有关需求、设计文档以及源代码要达到100%的评审覆盖度。
3) 严格控制每次评审有足够的参与者,一般包括但不限于:客户、项目软件经理、上游活动责任人、下游活动责任人、有经验的同行。参与人员的数量保证在3-7人的规模;
4) 为提高评审效率,在同行评审会议上要集中精力讨论发现缺陷,而不是如何解决这个缺陷。
5) 为保证评审的效果,可采取在评审会议上阅读文档资料的方式,提高软件工件的可理解性。
6) 对于规模较大的工件采取分阶段或多次的评审方式,确保评审的效果。
7) 借助电话、视频等工具采用分布式评审方式解决异地开发的评审问题。
四、 测试
测试的目的是为了进行适当的质量评价,尽可能检出错误,并且对于未检出错误的部分,要保证一定的质量。从质量保证的角度,项目的测试活动与各项开发活动一一进行对应,下表描述了这一关系:
图 测试活动与各项开发活动对应图
为确保系统测试活动的有效进行,本项目开发项目组的针对测试活动的基本要求如下:
1) 建立独立的测试组,由系统测试经理负责策划和实施系统测试;
2) 建立单独的测试计划,包括策划项目的测试方法、测试类型、测试手段和测试内容、测试环境和测试工具、测试活动的进度和人员以及测试过程中的风险。
3) 建立不同测试类型的测试规范,针对不同测试类型选择合适的自动测试工具;
4) 建立明确的测试标准,包括测试入口标准、执行标准以及完成和成功的标准。
5) 不符合问题跟踪与解决
质量保证经理依据公司的项目工程过程裁剪工作表来确定计划中质量保证活动所参考的过程、规程、标准、方法、指南、模板、表格等等。按照质量保证计划中确定的评审和审计方式来执行计划好的质量保证活动。在活动执行过程中,质量保证经理详细记载评审、审计活动情况、和发现的不符合问题等等。在项目开发过程中,质量保证经理对负责向开发人员提供质量保证方面的咨询支持。
项目质量保证经理将评审或检查出的不符合问题报告给相关开发人员,一起协商问题解决措施,并将记录协商结果和措施。
与同开发人员一起协商之后也无法获得解决的问题将被提交给活动的上一级负责人,如果问题仍无法解决,以此类推,直到将问题提交给项目组、培训组、SEPG的负责人。
重大问题将会同客户和QAG专家一起协商,确定问题解决措施。质量保证经理将跟踪不符合问题的解决情况,直至问题解决。
1.2 项目质量保证措施
1.2.1 成立专门的QA组
项目设立专门的QA组,归属于领导小组,包括QA专员,项目经理等管理角色,整体负责项目质量。
QA组是独立于项目之外的过程管理人员,负责评审项目过程、审计系统工件、工具和设备,为项目过程状态提供可视性,向高层经理及项目经理提供QA报告。QA的工作不受项目经理的领导,具有独立的向高层经理汇报的途径。
QA组同时负责对分包方(如果有的话)相关过程和产品进行评审和审计,评价项目综合能力,为项目降低风险。
1.2.2 关键里程碑跟踪和控制
项目关键里程碑计划是项目管理的基准,现代质量管理认为“计划胜于检验”,“过程决定质量”,对于项目执行来讲同样是这样。计划是项目执行的指导,计划是控制的基准,计划是项目各方沟通的平台。计划制定的过程强调渐进明细和分解。
通常应用软件开发过程中项目计划容易出现的问题
l 项目计划凌乱、无序,也就是说不能从项目计划中看到项目执行全貌。对项目执行指导意义不大。
l 项目计划只是在项目开始时进行制定,在执行过程中不对计划进行及时管理,导致项目计划失效,同时失去对项目执行的指导意义。
l 项目计划不完整,只是在当前所关注的环节存在计划,导致项目执行工作不能整体上全面协调的推进。
本项目计划跟踪和控制建议:
1) 项目计划层次划分
项目计划可分为:项目里程碑计划、子项目计划、周项目计划3个层次。充分体现项目管理中渐进明细和分解的原则。
项目里程碑计划作为项目各参与方均认可的项目阶段目标指导性文件,项目各参与方均需对其负责。
对里程碑计划进行渐进明细形成子项目计划,子项目计划要说明里程碑计划中阶段目标的实现步骤和方法。
在子项目计划的指导下形成项目各参与方的周项目计划,周项目计划作为项目进度风险控制的最小单元,根据周项目计划的执行情况进行考核,并及时形成调整措施。
2) 项目计划有效性和完整性
“计划赶不上变化”,在项目执行的过程中必然会发生各种各样的情况变化,如各个层次的项目计划不能得到及时的变更控制和管理,项目计划将逐渐与项目执行情况脱节并失效。项目计划的有效性的丧失必然导致项目工作陷入无序状态,最终导致项目目标不能实现,造成项目失败。
在形成各个阶段或维度的子项目计划时,非常重要的一点是要保证项目计划的完整性。如果子项目计划存在缺失,会造成项目执行中的重大缺陷,对整体项目执行产生重大影响。
针对项目计划的有效性和完整性问题提出本项目中相关项目管理建议:
l 项目管理组承担项目计划的变更控制和管理职能,对项目计划的有效性负全面责任。
l 建立项目计划变更控制流程。在项目执行情况发生重大变更时,相关方必须向本项目管理组提出变更申请;项目管理组根据情况及时组织项目相关方审查项目变更,并进行风险分析,更新项目计划并通知项目各方。
l 项目总体计划和子项目计划制定,要进行相关评审,在评审通过后方可生效。
l 建立项目计划标识体系,包括项目计划版本标识。每次项目计划的变更均需更新标识,并说明变更原因和进行相关风险的说明。
l 项目计划的执行情况跟踪
本着及早发现问题的原则,定期的对项目计划的执行情况进行跟踪,并对跟踪结果进行公布。跟踪的频度与项目执行情况相关,可以以周、两周等频度进行。
1.2.3 关键里程碑评审及汇报
整个项目过程中,对于制定的质量保证计划中设定的关键里程碑,进行严格的评审机制,根据每个里程碑的特点,要求项目中不同角色的人参与评审活动,形成严格的评审会议记录和评审问题记录,发送项目相关干系者。
关键里程碑的评审应当邀请项目管理办公室参加;项目关键里程碑达成时,要按质量计划要求进行评审、形成评审记录或报告,并将相关评审记录和问题报告应当发送项目管理办公室;项目重大质量问题应当及时向项目管理办公室报告。
1.2.4 项目问题和缺陷跟踪机制
对于软件开发工程项目来讲,项目在执行的过程中会出现很多问题,同时在项目监控的过程中也会发现一些缺陷。这是由于软件开发项目不确定性大的自然属性所造成。
在本项目中,对于项目中的存在问题和缺陷,建立持续的跟踪机制,由项目管理组统一负责,项目管理组协调项目各方制定处理方案,并对处理方案的执行持续跟进。
1.2.5 服务过程质量监控
可以采取以下步骤实施全面质量控制:
一、 建立标准化工作程序
项目启动时,项目技术协调组应根据项目范围、项目要求,首先组织人力编制项目程序、工作标准及相应工作手册,形成工作方法体系,实现项目工作的程序化、标准化,并对项目人员进行培训,使他们了解和遵守项目程序和要求。
二、 实行阶段性成果提交与变更控制
项目具有生命周期,这就为我们划分项目阶段提供了依据。一个大项目可分成若干阶段,每个阶段有自已的任务和成果。这样一方面便于管理和控制项目进度,另一方面可以增强项目人员和用户的信心。
在每个阶段末要提交部分成果,作为下一阶段开发的基础。成果提交之后不是不能修改,而是其修改要经过一定的审批程序,并且涉及到项目计划的调整。
三、 实行里程碑式的审查与版本控制
里程碑式审查就是在项目生命周期每个阶段结束之前,都正式使用结束标准对该阶段提交的成果进行严格技术审查,如果发现问题,应及时在阶段内解决。
版本控制是保证项目部顺利工作的重要手段。版本控制的含义是通过给文档和程序文件编上版本号,记录每次的修改信息,使项目部的所有成员都了解文档和程序的修改过程。
四、 全面测试
要采用适当的手段,对系统调查、系统分析、系统设计、实现和文档进行全面测试。
五、 用户单位加强监督
为进一步加强项目质量控制,要加强用户方对项目质量的监督。
1.2.6 质量数据指标及分析
主要质量指标
指标 |
说明 |
|
主要指标 |
总缺陷密度 |
发现的总缺陷数与软件系统有效代码行数之比 |
过程内缺陷密度 |
软件系统提交之前发现的缺陷数与软件系统有效代码行数之比 |
|
提交后缺陷密度 |
软件系统提交之后发现的缺陷数与软件系统有效代码行数之比 |
|
阶段指标 |
需求缺陷密度 |
需求评审发现的缺陷数与估计的代码行数之比 |
分析设计缺陷密度 |
分析设计评审发现的缺陷数与估计的代码行数之比 |
|
代码评审缺陷密度 |
代码评审发现的缺陷数与实际评审的代码行数之比 |
|
测试用例密度 |
测试用例数与估计的代码行数之比 |
|
测试缺陷密度 |
测试发现的缺陷数与实际有效代码行数之比 |
项目执行过程中及时分析评审和测试过程中所收集的质量和缺陷数据,及时发现项目质量问题,以采取有效的质量控制措施。由项目经理和测试经理负责定期对缺陷数据进行分析,主要的分析包括:缺陷趋势分析、未对应完的BUG数分析、帕列托分析、缺陷等级分析和缺陷分布分析等。
缺陷趋势分析:如下图所示,用于分析测试过程中缺陷发现和修正的进展状况。项目经理跟踪项目当前缺陷实际发现和消除情况,包括发现的缺陷总数、需修改的和已修改的缺陷总数,比较需修改的缺陷数与已修改的缺陷数之间的差异。如果缺陷修正和发现数量的偏离趋势逐渐变大时,说明开发活动进展比测试活动进展慢,项目应分析原因并采取相应的措施以控制这种偏离趋势。
帕雷托分析:如下图所示,按照从大到小的顺序描述了各类缺陷的分布情况,按照帕雷托的原则分析占项目80%缺陷数量的少数几类缺陷,分析缺陷产生的根本原因并执行相应的预防措施以提高产品质量。Pareto的原则就是将大的问题分解成小的问题并识别出最重要的部分,使我们利用有限的资源集中解决关键的因素以得到最大的收益。
缺陷分布分析:描述项目各个版本、各个模块和阶段等多个角度考察缺陷分布情况,用于分析项目状态。下图为缺陷在各模块中的分布示意图。
质量保证经理参照我司的度量与分析规程,定期对不符合问题的数据进行统计分析,并记录解决措施,统计数据和措施,形成质量保证工作报告。
质量保证经理定期向项目经理、部门领导、客户方汇报质量保证工作状况。
1.3 项目质量保证承诺
1.3.1 项目质量保证
我司将对该项目实行以合同期为目标的项目责任制管理,全面履行项目合同,保证该项目质量优良、按期完工。
在项目实施过程中将开展质量保证活动,所提交的进度报告包括质量报告内容,对质量问题制定改进措施并有效执行。
具体措施如下:
l 将按ISO9001的质量管理体系规范要求,针对招标项目实施过程及交付结果进行质量规划、管理、控制。贯彻到项目实施管理、系统集成的每一个过程节点,保证项目安装实施的质量。
l 我司将建立严格的质量保证体系,指定项目开发建设质量控制方案和实施措施,并督促落实各环节质量控制内容合目标;保证总体规划设计、开发与实施、系统运行与验收各个阶段工作满足招标方对质量的要求。
l 严格按照规范对业务应用系统开发项目进行全生命周期的管理。根据整个开发的工作计划,对阶段性工作成果进行审查和测试,并向项目单位提交里程碑式工作成果。通过保证各阶段性成果的质量,最终保证整个系统开发的质量。
l 设立强有力的项目领导班子,组织具有丰富经验和一流素质的专业队伍,建立合理的项目组织结构。
l 本项目的具体安装实施工作包括需求分析、系统设计、应用系统开发、系统集成等。具体而言,我司负责如下方面任务的项目安装实施管理。
l 系统深化设计要求详细到位。
l 组件供货要求按预期规定时间送达客户现场,以免担误整体进度。
l 应用系统开发应保证软件运行流畅,业务流程清晰,操作易上手,零BUG。
l 系统集成要求软、硬件完美整合,系统试运行后零故障交付。
l 信息安全系统建设及评测顺利通过。
我司将全力与用户配合,根据用户的详细需求,提交实施方案得到用户确认后实施,保证系统按时、正常地投入运行。
我司承诺将与用户方签订项目管理保密协议,并按照相关安全保密的要求,对项目负有规定的保密责任。
我司将接受采购单位的质量监督检查,提供真实有效的相关质量活动记录、证据,无条件接受采购单位提出的质量问题整改要求,承担质量责任及因质量问题导致的进度延迟责任。
1.3.2 项目质量应急方案
为建立健全对产品质量安全事故的救助体系和运行机制,提高我司对产品质量处理的能力,规范和指导应急处理工作,最大限度地减少质量事故的危害,根据有关法律、法规结合我司实际,制定本预案。
l 质量事件处理制度
1)建立事件应急值班制度,小组成员的通讯工具,要保证24小时开机状态,应急人员随时待命。
2)要为应急工作配备必备技术、处理人员必须在最短时间内赶到现场,确保应急工作的需要。
3)经常保持与用户的联系,确保在应急机制启动时,与各有关单位之间的联络畅通和积极配合。
l 现场应急处理
应急人员到达地点后,按照分工立即开展工作。
1、及时传达贯彻领导指示,随时报告事件处理情况,完成领导交办的各项任务。并进行现场检查。
2、现场处理必须做到步调一致、各负其责,任何人都不得因为工作的疏忽导致不应有的损失和对用户的损害。
l 后期处理
1、突发事件处理完毕后,领导小组必须对质量事件的处理情况进行总结,分析原因,提出预防措施。
2、各级处置领导小组要建立落实责任追究制度,明确责任,落实到人。对坚持原则、处置得当、沉着果断的有功人员给予通报表扬和奖励;对迟报、谎报、瞒报和误报事件重要情况以及玩忽职守、推卸责任造成不良后果的相关人员给予通报批评并依法追究责任。
l 日常应对措施
1、对突发及重大事件的应急预案及时修订、补充和完善,确保应急预案切实可行。
2、总结经验教训,防止类似事件的重复发生;及时发现质量问题和可能出现的事件。
3、采取切实有效措施,防止质量事件发生。
4、加强检测能力的评审,定期检查计量设备的效验情况。
5、加强相关人员的业务理论及专业知识学习,提高事物的观察力、判断力和突发事件快速反映与处置能力。
2 风险管控方案
在软件开发中,风险是某种不确定因素,在其正常分布范围内,它可以危及项目成功或导致项目失败。因此有效的管理项目风险是项目成功的关键。
2.1 项目风险管理策略
根据风险发生的可能性和对项目影响的严重程度,定义风险等级:高、重大、中等、较小、低。
风险对策:主要描述应对风险的策略。风险管理的核心思想不是被动地等待(等到风险变成现实、成为问题或导致项目失败),而是决定如何对付风险。对于每个风险,有 3 种主要的可行措施:
ü 风险规避:重新组织项目,使风险无法影响项目。
ü 风险转移:重新组织项目,让其他方承担该风险(客户、厂商、银行、其他主体等)。
ü 风险接受:决定接受这种可能发生的风险。监视风险征兆,如果风险出现,则制订应急计划,决定要采取的措施。
如果接受风险,还要采取两种措施及:风险减轻:采取一些及时的、正面主动的步骤来减小风险发生的可能性或影响。制定应急计划:如果风险变成实际问题,应当采取的措施。
2.2 项目风险开发策略
迭代开发比瀑布式开发可以更早的缓解风险。在瀑布开发过程中,只能在最后的集成中发现和解决风险。而在迭代方法中,通过尽早构建架构、迭代不断的集成、客户尽早的参与检验并反馈等方式,在早期展开迭代过程时就已接触到所有的过程构件并检验了项目的各个方面,包括工具、现成的软件和人员技能。已发现的风险将不再是风险,新的、未检查的风险将在以后被发现。
项目生命周期风险图
在系统迭代开发过程中,项目经理需要维护一张风险列表,来对风险进行跟踪并评估风险的优先等级。
风险管理活动主要包括:
ü 识别出潜在的风险
ü 分析并确定其优先级
ü 确定风险对策
ü 持续的检查评估风险
ü 及时更新风险列表
2.3 项目风险应急策略
以下提出项目可能的风险及应急策略:
2.3.1 软件需求侧
涉及业务的软件系统,经常会出现这样的问题:系统开发完成了,但没有满足客户的业务需求;需求经常发生变化,导致开发范围的蔓延。避免软件需求的风险,才能项目成功。化解风险的策略:
ü 理解客户需要解决的问题:通过业务建模,了解客户的业务流程和业务需求
ü 增强与客户的沟通:用例建模立足用户角度描述,为具体的需求提供了充分的上下文信息,是衔接用户和开发者的纽带和沟通方式。
ü 及早收集客户的反馈:每次迭代都会产生系统可执行的部分,通过及早部署演示来挖掘用户的反馈意见,改进对于需求理解的偏差。
ü 控制需求变更:变更请求可能来自于客户和最终用户、设计人员、开发人员、测试人员、技术支持部门等,建立变更控制流程管理变更。
2.3.2 技术架构侧
可执行构架指的是系统的部分实施,该构架用于演示选定的系统功能和特征,尤其是那些满足非功能性需求的功能和特征。利用该构架可以降低性能、吞吐量、容量、可靠性以及其他方面的风险。
迭代开发在精化阶段的关键活动是确定架构并为构架建立基线,在该阶段经过几次的迭代和测试修改,到精化结束时稳定的架构基线已经建立,性能等主要技术风险尽早的被发现和解决。从而在构建阶段可以在一个稳固的基础上完成系统功能的全面添加,而不用担心破坏系统。
2.4 组织风险识别与分析
2.4.1 人力资源投入不足
项目的实施建设需要投入大量的合格的实施技术人员和业务人员,实施组织队伍庞大,大型组织的管理与培训将是一个挑战和风险。
为避免此风险可按下列方法实施:
l 加强项目的管理力度。
l 强化项目中的成果管理和知识积累管理。
l 从人力资源规划方面,储备备用人力资源。
l 提前进行人员的储备和培养。
l 完善培训机制和手段。
l 充分培养后继人才。
2.4.2 用户不能准确表达需求/用户技能的限制
在系统实施时,首先要对用户的现状及用户需求做详尽的描述。通常由于用户人员对自己的业务理解还在不断的深化,因此往往在实施应用系统时用户对需求的描述会随着实施的不断深入而有所改变,造成系统需求的不稳定。
为避免此风险可按下列方法实施:
l 在其它类似项目上的设计和经验的再利用。
l 在项目实施过程中,将技能传授给项目组和建设单位方。
2.4.3 实施范围的不断扩大导致项目延期
大型项目实施周期较长,因此通常在实施过程中,用户会对项目开始时所提出的目标和要求有所变化,造成实施范围的不断扩大和项目实施的不断延期,最终使项目搁浅。
为避免此风险可按下列方法实施:
l 建立项目实施领导小组,明确项目的目标和各自的权限。
l 成立项目实施领导小组,处理项目实施的成本和账目──明确预算控制。
l 配备经验丰富的项目经理。
l 定期向项目的高层管理部门和用户报告项目实施的进展及存在的问题。
l 控制实施范围的变化 ── 形成书面文档、陈述更改原因,待高层管理部门批准后方可实施更改。
l 建立当项目实施出现问题时进行汇报和解决的标准工作流程
2.5 过程风险识别与分析
2.5.1 领导层的全力支持
领导层的全力支持是必不可少的,必须尽一切可能争取他们的关心和支持;定期或不定期,口头或书面向领导层汇报;在考虑解决方案时要兼顾信息共享和数据的安全保密性,既要保证上级机关及时准确地得到需要的数据,又要兼顾机构业务活动的相对独立性等。
2.5.2 主要项目人员缺位
主要项目人员对于整个项目的进展起着关键的制约作用、促进作用,是项目进展中人员因素的重点,要特别重视:
为避免此风险可按下列方法实施:
l 审阅提名项目主要人员的专业能力和质量,是否有全面的项目管理、实施能力。
l 关键人员要建立A、B角色工作机制,确保全面支持能力和工作保证。
l 对主要项目人员工作内容进行知识跟踪和积累,确保知识可追溯,不损失。
2.5.3 实施人员的专业能力和人员的数量
实施人员在实施过程中起很大的作用,因此,要对实施人员做重点考虑,为避免此风险可按下列方法实施:
l 审阅提名项目实施人员的专业能力和质量。
l 是否有全面的项目实施技能和经验。
l 清晰的组织结构(无多重任务),清晰的责任。
l 实施人员的有效性和灵活性。
l 是否能将实施经验作为技能传授给建设单位。
2.5.4 项目实施人员的频繁更换
人员频繁更换,将导致项目工作计划的任务不能按时完成予,接替者需要额外的时间来熟悉项目和赋予他的工作,从而影响项目的进程和成本,要纳入风险管理中:
为避免此风险可按下列方法实施:
l 通过项目培训、项目工作磨合,培养实施人员事业心、责任心。
l 建立科学合理的项目管理制度,项目团队认可、接受项目管理模式。
l 建立项目中的工作激励制度,避免平均主义导致优秀人员流失,促进整体工作效率。
2.5.5 缺乏多厂商之间的相互协调和各厂商所负的责任不清
大型项目实施所涉及的厂商很多,包括硬件、数据库、应用软件、网络或集成商等,在项目实施过程中需要多方协调、通力合作,只有这样才能保证项目保质保量、如期完成。
为避免此风险可按下列方法实施:
l 为减少项目实施的协调工作,尽量减少供应商实施方数目。
l 在项目实施时,要分清实施项目的责任范围。
2.5.6 系统技能和技术风险
对项目实施而言,选择一个好的应用系统是十分重要的,一个好的应用系统的标准是:
l 该产品必须是灵活的,成熟的。
l 该产品有很好的系统性能,包括:有一个好的技术结构。
l 有良好的技术基础,建立在开放系统上,有先进的开发工具。
2.5.7 避免各类人员业务水平层次不齐对项目实施的影响
目前业务人员,技术人员的业务水平高低差别较大,这对项目的正确实施有相当的影响。
为避免此风险可按下列方法实施:
l 选择项目成员时强调项目成员应有较强的应急指挥管理业务背景,业务水平和较强的接受新事物能力。
l 在业务流程和需求分析时采取启发式询问,多人多岗位调查然后综合以及到业务现场调查等方法。
l 同时通过项目的实施,希望能培养出一支自己的既懂业务又有过硬技术的复合型人才队伍,通过他们来大幅度提高整体应用水平。
2.5.8 避免实施人员变更影响项目进度
由于本项目的实施周期较长,实施人员的变更是不可避免的。如何防止人员变更对项目实施的影响。
一、风险对策与管理
问题管理流程主要提供一种沟通的机制,保证项目双方在实施过程中就发生的各种情况进行提议或讨论。
提出问题主要是为了监控其后续的状态和结果,这些问题可以针对项目文档的内容、项目管理、测试结果或软件产品问题等,它与风险争议的区别在于问题主要是针对交付成果的不足之处。
1.详细记录问题
当发生问题时,任何一个项目组成员需填报《问题报告》,如果只是定制的软件产品的技术问题,则填报《产品问题记录》。所有的问题报告须提交至项目经理;并由项目经理予以登记管理日志。
2.问题的调研
项目经理收到问题报告后应及时或指派人员进行问题的调研;调研结果应由项目经理复核;如果确定不采取措施的,项目经理应在问题报告中详细说明理由并签署“不必采取行动”的意见。
3.解决问题
对复杂问题,应详细记录问题的解决进程;问题报告应同时发送到相关的问题责任人;当问题解决后,须将问题报告返还并由项目经理签字确认。
可能影响到项目成功的风险因素应在项目实施开始前做充分的估计。问题和风险管理流程将适用于任何在实施过程中产生的风险和争议,并采用日志管理在项目进度会议上予以讨论。在实施过程中,有些风险因素的缓解超越了项目组的能力范围,以下的流程确定了如何记录这些问题及其相应的手续措施。
4.详细记录风险和争议问题
每一个项目组成员都可以/有责任提出争议问题和揭示潜在的实施风险,并及时填报《风险报告》项目经理应及时对提出的问题进行调研并确定后续措施以避免风险和争议影响项目的进程。对于超越项目组权限之外的任何问题,应及时上报。
5.问题解决与风险防范
对较为复杂的问题,问题的解决过程应予以详细的记录;对有可选方案的问题,必须对各种情况进行讨论和记录,以便质量控制和检查;在解决措施中应对可能的实施进度和成本的影响进行充分的估计;双方项目组应讨论并形成推荐解决方案;所有的对策或推荐方案应在项目进度会议上审阅并形成变更申请或转换为问题报告等。
如果需要作为变更控制的,则风险报告将作为变更报告的附件资料;如果问题的解决不影响服务合同范围的,项目经理可以直接签署解决方案;如果不采取任何措施的,必须说明详细的理由。
3 项目验收方案
3.1 项目验收目的
为使本项目按照技术规范的要求进行,确保项目上线后达到有关要求和标准,并能正常投入运行,必须进行项目验收。
3.2 项目验收原则
为了保证本项目实施工作完全符合项目设计的要求与合同中相关条款的约定,确保系统开通后,可以顺利运行,需要在项目实施完毕,并进行了一段稳定的试运行后,进行本系统的验收工作。
本项目的验收工作,本着坚持实事求是、客观公正、科学简便、讲求实效的原则,进行全面、认真、系统地检查验收。
3.3 项目验收前提
我司完成项目试运行并通过对系统实施的自我检测后,应按照验收文件编制要求,编制《项目验收文档》,《应急计划建议书》。验收文档应满足完整性、一致性和可读性要求。
验收前提条件还包括:
1、所有功能需求按照合同要求全部建成,并满足使用要求。
2、已编制完成验收测试方案,并经过用户单位评审通过。
3、已经完成系统的开发、测试、实施工作,并经过用户单位确认。
4、已完成所有建设项目的软件测试、整体联调测试等方面的自测。
5、各种技术文档和验收资料完备,符合合同的要求和格式。
6、符合合同或合同附件规定的其他验收条件。
在项目实施完成,并符合上述验收前提条件后,由我司提出验收申请。相关的验收文档、验收规范应提前提交给用户单位评审。
3.4 项目验收阶段安排
验收阶段 |
阶段描述 |
验收交付物 |
需求调研和分析 |
开发商人员现场到位,制定需求调研计划,完成需求调研和需求分析工作。 |
《项目组织机构与人员安排》 《系统开发与实施计划》 《项目管理制度》 《项目风险管理》 《质量管理计划》 《总体设计方案》 |
系统设计 |
技术方案制定,完成系统架构和模块功能设计。 |
《概要设计说明书》 《系统框架说明书》 |
系统开发 |
完成系统功能编码和单元测试、内部测试用例编写等。 |
《详细设计说明书》 《数据库设计说明书》 《开发计划》 《工作周报》 《测试用例》 |
联调测试 |
开展内外部系统联调测试工作,编写用户操作手册、安装维护手册。 |
《用户操作手册》 《安装维护手册》 |
上线试运行 |
上线相关准备工作,包括软硬件环境清理、上线版本准备,文档审核。 上线部署工作。 |
《系统试运行报告》 《系统试运行和自测报告》 |
上线验收 |
上线运行情况跟踪分析,验收文档交付。 |
《工作总结报告》 《用户验收测试报告》 《系统上线详细计划》 《系统验收报告》 |
上线后保障及培训 |
提供上线后技术支持与保障,并对相关人员进行平台培训。 |
《操作手册》 《培训手册》 《培训计划》 《培训反馈表》 |
3.5 项目验收步骤
一.1.1.1. 验收组织确定
在正式进行系统验收之前,由我司及用户单位共同组织人员建立项目验收组织,对项目验收的内容、流程、标准及结论进行分析、确定,并达成一致。针对项目验收,我司需配备若干名有经验的工程师和用户单位的技术专家来组成项目验收团队,负责具体验收工作。
一.1.1.2. 编写验收测试方案
我司在对项目验收的内容、流程、标准及结论进行深入分析的基础上编写验收方案(计划书),并提交用户单位评审,评审通过后做为本项目验收测试的规范性文件。
一.1.1.3. 项目验收的实施
严格按照验收方案,通过用户指定的机构软件测试,对本项目的系统设计、功能实现、系统性能、系统文档资料等进行全面的测试和验收。
一.1.1.4. 提交验收报告
项目验收完毕,对项目系统设计、服务质量、系统运行情况等做出全面的评价,得出结论性意见,对不合格的项目不予验收,对遗留问题提出具体的解决意见。
一.1.1.5. 召开项目验收评审会
召开由验收小组全体成员(包含用户相关工作人员、我司工作人员)参加的项目验收评审会,全面细致地审核项目验收小组所提交的验收报告,给出最终的验收意见,形成验收评审报告提交用户单位。
3.6 项目验收总结
验收工作领导小组分析《用户验收测试报告》,对系统进行全面评估,最终确定系统是否可以通过验收,并制定《项目验收总结报告》。
如果发现由于递交的成果没有满足质量标准要求,或在评审周期结束之日我司没有解决评审人提出的意见而被拒绝,拒绝的递交成果必须退回给成果递交者进行修改。如果用户单位项目协调人与我司项目经理无法协商解决问题,将上报到相关部门解决。
3.6.1 递交成果的签署
3.6.2 签署的目的
签署指的是用户在验收文档上签字,表明用户已对递交的成果进行了评阅,并认为递交的成果满足要求,同时我司已解决用户对递交成果提出的意见。
3.6.3 评审和签署程序
本公司提出了以下评审和签署程序
1.在评审过程中,用户单位将完成以下各项程序:
- 检查递交的成果是否满足要求
- 在意见表中填写评审意见
2.在评审之后,用户将意见表交给我司项目经理。如果用户对递交的成果提出重要意见或需求,需要对递交的成果进行修改。递交的成果修改之后,用户将重新进行评审。对于每个评审循环,用户单位将完成上述的步骤1到2。用户单位将对递交的成果进行完整的评审,并在两个评审循环中完成评审。如果安排的评审周期结束,将不再重复这个过程。
3.在评审周期内任何时间,如果用户认为递交的成果已经满足所有需求,并提出了评审意见,用户将通知我司负责人。在这种情况下,用户单位项目负责人将签署递交的成果。
4.如果在评审周期结束后,递交的成果仍然不能满足规定的需求或不能解决用户提出的意见,评审人将把这种情况记录在意见表中,并将意见表交给我司负责人。评审人将认为递交的成果不可接受。
5.接收/拒绝表将由用户递交给我司项目经理。
4 项目培训服务方案
4.1 技术培训承诺
我司技术培训承诺:本项目的培训完成关键用户培训、最终用户培训、系统维护培训、技术开发培训等。各种培训对于项目建设的不同阶段和不同角色。我司按照不同培训的内容和目标提出相应的参训人员、场地、日程及目标等计划和方案,并给出相应的培训结果评估策略。每种培训提供有相应的培训手册、培训课件,培训讲师安排有相关的实践经验和授课能力。
(1)关键用户培训:在系统分析与设计、系统测试、系统试运行等阶段,应针对各个模块等相关业务的核心骨干人员进行重点培训,这些人员作为整个项目的关键用户要达到对系统相关功能熟练掌握灵活应用的目的。
关键用户将来作为商谈组织单位内部系统支持体系的重要组成部分,软件/商谈单位软件/商谈单位必须做好培训策略和计划。
(2)最终用户培训:在系统试运行和正式运行前,要针对系统的最终使用人员进行全面详细的业务功能培训。最终用户培训要安排合理,循序渐进,要根据用户规模和工作安排实际情况,合理安排培训时间和批次。最终用户要安排多次渐进式培训。
(3)系统维护培训:在系统试运行及正式运行前,要针对系统维护人员组织系统维护培训,重点要提升维护人员的系统的安装部署、配置调试、常见故障的排除、权限设置和分配、数据恢复与备份、应急处理等能力。
4.2 技术培训内容及计划
4.2.1 关键用户培训
在系统分析与设计、系统测试、系统试运行等阶段,通过此培训,针对各个模块等相关业务的核心骨干人员进行重点培训,作为整个项目的关键用户要达到对系统相关功能熟练掌握灵活应用的目的。
培训内容
培训对象 |
培训内容 |
培训方法 |
培训人员 |
核心骨干人员 |
云管平台建设背景、云管平台相关概念、云管平台相关功能 |
方案讲解及演示 |
产品经理 |
4.3 最终用户培训
在系统试运行和正式运行前,要针对系统的最终使用人员进行全面详细的业务功能培训。通过此培训,使得使用人员熟悉系统的日常功能操作,是保证平台功能顺利进行的重要保障,培训人员能够在操作文档的帮助下独立完成日常操作。
培训内容
培训对象 |
培训内容 |
培训方法 |
培训人员 |
系统使用人员 |
云管平台操作使用培训、常见问题及解决办法 |
操作使用讲解 |
项目资深专家 |
4.3.1 系统维护培训
在系统试运行及正式运行前,要针对系统维护人员组织系统维护培训,通过此培训,使得贵方技术人员具备独立系统日常操作与运维管理的能力,提升维护人员的系统的安装部署、配置调试、常见故障的排除、权限设置和分配、数据恢复与备份、应急处理等能力。
培训内容
培训对象 |
培训内容 |
培训方法 |
培训人员 |
贵方开发与维护人员 |
系统环境与配置信息培训:操作系统、中间件、网络等日常操作与配置 |
方法讲解、实际操作和维护 |
系统工程师 |
产品投产流程 |
环境部署人员 |
||
日常运行维护、数据备份与恢复、应急操作 |
维护人员 |
||
出错的处理与解决 |
维护人员 |
4.3.2 技术培训准备
为保证云服务平台培训工作有序开展,更好满足项目建设需求,提高人员的管理水平、业务水平和技术水平,制定如下培训流程。
4.3.2.1 技术培训目的
为了高质量建设本项目,更好的满足项目的建设需求,提高项目管理、建设、运维、技术人员水平,并保证项目建成后充分发挥效益,必须对关键用户人员、最终用户人员、系统维护人员进行培训。
技术人员经过培训应能进行软件运行维护工作,掌握软件操作,熟悉平台基本功能。能熟练地分析软件信息等工作,并具有组织和开展业务的应用能力。高级项目技术人员培训后,能够处理一般维护人员不能处理的技术问题。经培训后,应能负责全面的技术管理工作,了解系统建设的过程,系统功能及未来建设的规划。
达到“确保每一位系统使用人员能够独立、熟练的完成操作,保证系统用户能够独立处理突发事件和进行简单的功能调整”目标,同时在一定程度上提高整体业务人员信息化(IT)技术和能力,最终达到以下目标:
1、保证项目的顺利进行
本项目的顺利实施需要用户与我们的密切配合,用户技术人员对相关技术和方案的熟悉程度是项目能否顺利进行的重要影响因素。通过此次培训,我们将和用户的技术人员交流技术问题,提高他们的技术水平和对方案的熟悉程度,使他们能够顺利地承担起项目实施过程中的配合工作,保证项目的顺利进行。
2、建立专业化的信息管理队伍,保障系统的正常运行
为了保证系统正常地运行,需要一支有经验、专业化的维护队伍。系统的日常维护任务要求管理员必须具有较高的技术水平,因此有必要对用户技术人员进行专业化的培训。
通过对用户技术人员的培训,使他们精通系统、软件的概念和知识,熟悉相关管理技术,掌握软件的安装与调试方法,掌握系统的操作与日常维护。
对技术人员的培训不仅包括技术理论,更重要的是,我司提供全面、开放的实践交流环节,通过多种形式的技术交流与动手实践,掌握平台系统的安装与调试方法,更好地掌握系统建设中使用的软件与技术,顺利地承担本项目的维护管理工作。
3、充分发挥系统软硬件性能
在保障本项目系统正常运行的基础上,用户关注的要点是整个系统的运行效率,所以有必要结合实际项目经验对用户技术人员进行培训,使其掌握软件及系统整体的性能优化与调整方法,以便在系统运行过程中,针对业务特点,及时对系统进行优化工作,从而使系统及其服务发挥最大的效能。
4、为用户信息系统建设的发展奠定技术和人员基础
一支高水平的技术人员队伍是用户进行信息系统建设的重要资源和有力保障。通过这次培训,我们将帮助用户建立起一支高水平、专业化的技术人员队伍,为其今后信息系统建设的发展奠定良好的技术和人员基础。
4.3.2.2 技术培训调研
我司的培训课程将根据用户的实际需求和结合行业实施经验而定。在培训之前,将对用户相关人员进行调研,已制定最合理的培训课程和培训计划及相关的地点、时间安排。
本项目是一个完整的信息系统,为确保该项目的顺利完成,必须建立一套完善统一的建设、运营、管理、培训机制。培训是我司项目服务计划中的一个重要组成部分。培训计划的宗旨是通过制定出色的培训服务计划来确保我司提供的信息系统能够更好的被用户理解以及使用;另一方面通过将我司在相关领域内长期所积累的经验与用户共同分享。培训是一个系统提供商和用户共同交流的过程,通过正规的培训,我司也可以通过双方交流从客户中学到更多新的知识,从而为我司日后的培训积累更多的经验,从而为用户提供更出色的培训服务。
我司提供的客户培训调研目标是:
1、内容具有针对性
2、讲师深入浅出阐述培训教材内容
3、培训流程系统化
4、内容和方式体现务实、科学、易学、有用的特点。
4.3.2.3 技术培训准备
我司在为用户进行培训之前,必须与本次项目负责人进行深入的沟通,充分理解系统项目人员、管理人员以及其它IT人员的培训需求,以及信息系统的实施进度,然后有针对性的准备我司的培训教材内容。
在培训需求明确的前提下,我司需要与本项目负责人确定:
(1)双方联系人:我司和用户必须各为此培训指定一个联系人。我司可以指定培训人员为培训讲师或者由项目相关人员担任;用户可以指定项目经理人员作为培训联系人;
(2)培训时间:确定培训日期,时间周期以及备用方案;
(3)培训环境:线上会议或客户现场。
(4)培训地点:建议在用户本地或由双方协商确定;
(5)讲师和培训对象:我司必须明确授课讲师的组成名单及其简单介绍,用户需要提供培训对象的人数、职位以及主要专业技能。
在本次项目,我司将为所有培训人员提供培训用文字资料和讲义等相关用品。
同时,我司将根据以下计划指导培训工作的具体实施:
1)培训计划核实:培训计划需要经过我司和用户双方的核实,做到培训有的放矢,确保培训效率,为确保培训成功,制定备用计划。
2)培训计划执行:执行培训计划,在出现意外情况下,执行备用计划。
3)培训反馈:我司非常重视收集培训的反馈信息,培训小组是主要的反馈信息源。
培训计划、内容改进:根据反馈信息,我司将会对培训的计划和内容进行改进,以便更适合培训的目标要求。
4.3.2.4 技术职能分配
(一)项目办
发布培训管理相关规章制度和流程;
审批职能组、项目组提交的培训需求。
(二)项目办综合组
负责汇总各职能组、项目组的培训计划,检查是否符合招标文件/合同/协议中的培训要求;
负责协助职能组、项目组协调培训地点和时间;
负责监控培训计划的落实;
负责汇总各职能组、项目组的培训情况,每季度对培训情况进行总结。
(三)职能组、项目组
负责整理培训需求,对于组间培训或外请讲师培训,需提交培训申请至项目办审批;
负责制定培训计划、收集培训课程、实施培训;
负责培训后完成培训小结,提交项目办综合组,并向项目办汇报;
负责培训资料的归档。
4.3.3 技术培训流程
培训流程图如下所示
4.3.3.1 整理培训需求
职能组、项目组整理培训需求。如属于组间培训或外请讲师,需编写《培训申请》,在项目办例会上由组长进行汇报申请;如属于组内培训。
培训申请包括以下内容:
培训目标
明确通过培训,期望达到的效果。
培训内容
明确具体的培训内容要求,包括流程、行业背景知识、IT能力以及各项目组工作所需知识、技能、成功案例等。
培训对象
明确准备参加培训的人员范围。
培训方式
明确期望的培训方式:
内部培训:由内部成员担任讲师;
外聘讲师:从外面聘请有经验的老师进行培训。
如选择“内部培训”,则要明确期望提供培训的职能组、项目组或具体人员。
培训时间
明确期望的培训时间和周期。
4.3.3.2 制定培训计划
职能组、项目组根据确定的培训需求,制定《培训计划》,并提交给项目办综合组。
项目办综合组负责汇总各职能组、项目组的《培训计划》,作为监控培训落实的依据,并检查是否符合招标文件/合同/协议中的培训要求。
4.3.3.3 获取培训资源
职能组、项目组负责收集课程资料和讲师名单。如果是外聘讲师方式,则须预先选择培训公司和讲师,并签订培训合同、获取培训材料。
4.3.4 确认参训人员
职能组、项目组在培训前确定参训人员名单,如需综合组协调培训地点和时间,须根据培训规模提前1-5个工作日通知综合组协助安排。
4.3.5 发出培训通知
职能组、项目组编写《培训通知》,发给讲师、卓望公司技术人员及相关人员。
4.3.6 准备培训环境
职能组、项目组在培训前1个工作日,准备培训环境,包括:调试环境、打印培训材料以及《培训签到表》、《培训技术人员意见反馈表》、《培训讲师意见反馈表》等。
4.3.7 实施培训
培训前,卓望公司技术人员在《培训签到表》上签到,领取培训材料;
培训中,讲师授课,并同卓望公司技术人员互动;
培训后,卓望公司技术人员填写《培训技术人员意见反馈表》、讲师填写《培训讲师意见反馈表》。
4.3.8 进行培训小结
培训完毕后,职能组、项目组需对培训情况进行小结,连同培训档案一起提交给项目办综合组,并向项目办汇报。
单项培训总结:统计培训出勤情况和培训效果,形成《培训小结》;
建立培训档案:将每个参与培训卓望公司技术人员、培训讲师的整体培训情况进行完整记录,形成《培训档案》;
4.3.9 培训的总结和回顾
项目办综合组负责汇总各职能组、项目组的培训实施情况。
每季度末,项目办综合组根据汇总的培训计划、培训计划落实情况等信息,进行培训总结和回顾,形成《培训总结》,向项目办汇报。
4.4 培训服务体系
对项目和服务质量的高度重视,在追求质量的过程中精益求精,这是我公司的一个重要的传统。对技术服务部门而言,不断强化质量管理,追求更高的服务质量,是一贯的目标。作为技术服务的重要组成部分,我公司一直将培训质量控制视为质量保证体系的重要组成部份,基于这种思路建立了一套完整的培训服务质量控制体系,收到了很好的效果。我们将以此培训服务质量控制体系为基础,针对本项目特点,来指导完成本项目培训工作。
针对本项目,我公司将在总体项目质量检验小组中建立一项专门针对技术培训的质量控制分组,以确保客户培训能够顺利实施,达到不同角色对培训质量的要求。
4.4.1 项目培训监督
培训期间,由专人负责密切监督培训的各个重要环节的运作情况。系统上线前,监督确保对相应的用户提前进行集中培训,包括关键用户、最终用户和系统维护的不同培训内容;项目维护期间,监督确保对由于人员或业务变动产生的新用户,能够按要求提供培训。一次培训的实施过程包括:联系用户、安排课程、指定讲师、卓望公司技术人员报到、授课、收集反馈、总结评定。质量控制小组有专人负责随时考查这些环节的实施情况,及时与用户进行沟通,纠正出现的错误和发现实施中的质量隐患。
4.4.2 定期汇报培训状况
在项目培训过程中,培训小组将定期向用户方负责领导以书面形式汇报项目培训进度,同样的报告也将提交给本项目经理和用户方培训负责人。根据双方领导的指示,通过协调行动,对项目的培训质量进行进一步控制,对项目培训进度进行调整。
4.4.3 培训项目初始阶段
根据预定的培训日期,项目经理在开课前与卓望公司项目经理联系,向其确认培训技术人员名单,名单中包含卓望公司技术人员详细信息。
得到用户确认信以后,项目经理将向客户发出情况说明函,说明函中包括:培训时间和地点、课程内容介绍、讲师介绍、培训材料介绍等。
在发出说明函后,项目经理将相应的卓望公司技术人员信息和其他文档(包括卓望公司技术人员签到表、卓望公司技术人员阶段反馈表和总结反馈表等)提交给讲师,由讲师主要负责后续的业务流程。
至此,培训项目初始阶段结束。
培训说明函格式如下:
培训说明函 |
|||
名称 |
|
||
目的 |
|
||
时间 |
|
地点 |
|
培训对象 |
|
人员要求 |
|
授课教师 |
|
培训材料 |
|
培训内容1 |
|
||
培训内容2 |
|
||
培训内容3 |
|
||
培训内容4 |
|
||
培训内容5 |
|
||
…… |
|
||
联系人 |
|
联系电话 |
|
4.4.4 项目培训实施阶段
项目培训实施阶段的主要执行人员是培训讲师。
授课过程是整个项目的核心步骤,也是质量控制的重点和难点所在。我们将按照标准要求,制订“讲师授课手册”等培训相关文档,对授课过程进行严格详尽的规定:
l 了解卓望公司技术人员情况
通过查看用户基本信息表以及与卓望公司技术人员交谈,了解卓望公司技术人员的工作任务、技术需求和知识基础,根据情况调整授课策略。
l 授课
这是讲师要完成的最主要的任务,主要包括以下内容。
(1)首先讲师要求卓望公司技术人员签到。
(2)开场白,作自我介绍,介绍课程基本内容、学习目标,授课日程、时间安排、系统环境。
(3)按章节授课,每一章节包括:说明本章的学习目标,按幻灯片逐张讲解,随时回答卓望公司技术人员提问,对无法立即回答的问题,记录到卓望公司技术人员问题表中,课后通过查阅资料或寻求技术支持获得解答,在下一次授课前必须向卓望公司技术人员做出回答,对卓望公司技术人员多次问到的问题,记录到常见问题表中。
在每一章内容讲授完毕后,指导卓望公司技术人员进行本章的操作。首先按操作步骤讲解需要卓望公司技术人员完成的操作,指出其中的要点。操作进行时,随时回答卓望公司技术人员提问或帮助卓望公司技术人员解决操作中遇到的操作问题。在卓望公司技术人员全部完成操作任务后,或规定操作时间结束时,结合本章的学习目标,进行操作总结。
根据卓望公司技术人员的精神状况灵活安排课间休息,连续授课时间最大不得超过一小时,以免卓望公司技术人员感到疲劳。
l 阶段回顾
在每天授课结束后,请卓望公司技术人员填写阶段反馈表,对当天的授课内容、讲师表现、日程安排、教学环境等所有关心的问题提出意见,对持有异议的部分提出修改建议。讲师在当晚与质量管理组召开阶段小会,向培训组组长和客户方代表汇报情况,对客户提出的修改意见进行协调,根据双方达成的一致意见修改课程安排(包括课程内容、讲师配置、培训日程、培训环境等方面的改动)。
l 授课总结
授课总结在所有章节讲授完毕及所有操作完成后进行。结合本课程学习目标,讲师提示卓望公司技术人员回忆课程中的要点,为卓望公司技术人员拟出复习提纲,对在课堂上提出的,超出课程范围的问题,建议卓望公司技术人员修习相关课程或求助公司相应部门的技术支持。授课过程至此结束。
l 授课反馈
课程结束后,讲师将要求每个卓望公司技术人员填写用户总结反馈表,由卓望公司技术人员在以下几个方面做出评价:
(1)讲师表现:讲师的课前准备、讲师的知识水平、讲师讲课是否清晰明了、讲师是否乐意帮助卓望公司技术人员解决问题、讲师的授课速度。
(2)教学内容:内容是否适应用户的实际需要、教材的难易程度、操作/练习对掌握课程内容的帮助、用户对操作/练习感兴趣的程度。
(3)其他内容:有具体意见或建议的,以及对以上没有提到的内容有意见或建议的。
4.4.4.1 培训项目总结阶段
讲师拟出总体报告,向项目经理作总结汇报,主要内容包括用户总体满意度,自我评估,培训改进建议等。
项目经理从讲师处获得用户反馈表,算出总体评分,制作出统计图表。
对用户在反馈表中的具体意见,向培训组组长报告。培训组组长查看评分,若发现某方面用户评分较低,针对问题分别处理。若“讲师表现”得分低,责成讲师本次教学的细化总结,要求讲师纠正问题后重新讲解讲,得到认可后方可重新参与该课程的培训。若“教学内容”得分较低,向教材编制小组报告用户意见,同时要求讲师适当修改或补充授课内容。若“其他”得分较低,责成相应的管理和支持人员做出整改。
讲师与项目经理协作,将本次培训遇到的问题作整理和提炼,形成“常用问题及解答”,加入到培训部门的内部资料库中,以备下次培训准备时使用。
由培训组组长主持的总结过程,主要目的是为了从本期的培训中归纳经验、纠正错误、听取意见、完善服务,在下一期的培训过程中,根据用户的要求进行改正和提高,以更高的质量为用户提供培训服务。
4.4.5 技术培训组织
4.4.6 技术培训组织原则
本项目涉及到的内容庞杂、面广人多、要求不同、培训任务重是本项目培训的特点。为使培训能顺利进行,并取得应有的效果,按以下组织原则开展有关培训:
1、培训的内容确保达到培训效果
2、实际应用与培训内容紧密结合
3、培训方式与培训要求合理搭配
4、培训计划与培训资源相互衔接
5、个人能力提升和发展适当兼顾
根据本项目培训工作的特点,需要遵循以上培训组织原则,保证培训工作落到实处,从而达到培训目标。
4.4.6.1 技术培训组织机构
我司拥有一大批教学经验丰富的技术培训人员,为了确保本次项目培训工作的顺利完成,我司将成立专业的、具有丰富经验的培训讲师和技术人员组成培训小组。
4.4.6.2 技术培训组织流程
本项目培训的流程是从培训计划的制定开始,确定培训计划和培训方案后,开始实施培训,然后对培训进行总结和回顾。
培训的计划:包括内容(课程)确定、授课师资的审核和落实、培训方式、培训人员、培训管理制度(包括作息时间)等。
培训的实施:包括确定培训的组织管理方式(如集中培训需建立临时的培训班委会)、培训情况调查(如培训感受)、培训情况检验(如培训情况的水平认证等)与鉴定、培训档案建立等。
培训的总结与回顾:主要是从培训计划制定和培训实施的各个环节进行总结和回顾,形成书面材料,与培训计划和培训实施过程中的文档一起形成一个完整的培训文档。
4.4.7 技术培训管理
在本项目培训的过程中,我司将注意不同阶段培训课程的重点,例如在项目运行前,我们将重点让经营端、管理端、及监管端的用户明确系统各端的定位及功能内容,让卓望公司技术人员能够对系统形成正确的认识,以便后续结合业务进行应用;而且在系统正式上线运行之后,对应人员或业务发生变动,我们能够根据新用户及系统功能变更的实际情况,进行针对性的培训,确保新用户能够尽快上手,老用户能够对系统新的业务功能实现无缝过度。同时,我们将在每次培训结束后,统计培训卓望公司技术人员的学习曲线和信息的反馈,及时听取培训技术人员的意见和建议,帮助提高今后的培训效果。
为保证培训取得良好效果,培训工作采取面对面集中授课的方式进行,配备专门的项目经理以解决授课过程出现的问题,制定相应的考核制度,考核合格才能从事培训工作。
对培训情况的反馈,可采取用户培训反馈表的方式对培训效果进行评价和监督,对卓望公司技术人员和教师进行意见反馈工作,既是对当前工作的考核,也是改进今后培训方式方法的有力依据。及时发现和控制在培训工作开展过程中出现的问题,并及时解决,为提高授课的质量,采用讲师备份、轮换制度,对讲师进行有效的监督和评价。
1、培训签到表
培训课程:时间:培训地点:
姓名 |
工作单位 |
联系电话 |
签到 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2、培训技术人员意见反馈表
培训课程:培训讲师:时间:
姓名 |
|
工作单位 |
|
|
授课能力 |
□优□良□中□待改进□差 |
|||
技术水平 |
□优□良□中□待改进□差 |
|||
工作态度 |
□优□良□中□待改进□差 |
|||
建议 |
|
3、培训讲师意见反馈表
培训课程:时间:培训地点:
姓名 |
|
工作单位 |
|
课堂纪律 |
□优□良□中□待改进□差 |
||
技术人员水平 |
□优□良□中□待改进□差 |
||
学习态度 |
□优□良□中□待改进□差 |
||
建议 |
|
4.5 技术培训方式
考虑到本项目面向用户众多且范围广泛的特点,因此在具体项目培训过程中我司也考虑到实际的情况和需求,认真分析和设计满足不同区域、不同层次的用户培训需求,将项目培训设计将主要体现“集中为主、本地化为辅、多种培训方式、丰富培训材料”的思路。
培训方式如下图所示:
为了达到确保用户能够顺利正常的使用本系统的功能特性和日常操作维护,我司将对培训材料进行细致的设计和制作,提供的培训材料类型包括:
1)电子文本材料(用户手册、操作手册、编程手册、培训手册等)。
2)视频音频材料(录制统一培训过程,便于用户能够在日常的学习中重复了解和熟悉系统)。
3)其他(常见问题解决材料FAQ等)。
集中培训
集中培训在客户要求的地点进行,我司的资深培训讲师将和客户相关部门的领导一起协同工作,共同完成培训任务:包括培训计划的制定、培训教材的制作和审核、培训讲师试讲、执行培训任务和满意度调查等等。
培训过程描述如下:
项目经理在项目即将进入试运行阶段时和用户商量排定整个项目的培训计划;
对于重要的集中大课培训,由项目经理亲自担任培训工程师。培训工程师接到培训任务之后,应填写培训计划表找相关的负责人审批;
培训工程师实施培训之前必须准备好用户手册、用户反馈单和用户培训反馈表,对于重要的培训,还需要准备专门的培训手册;
对于重要的培训,在实施培训之前,可以在公司内部进行培训演练;
培训过程中,在用户反馈单上记录用户提出的修改意见;培训结束之后,收集用户培训反馈表;
培训过程中,项目团队必须有代表人员在现场,以应对发生的意外事件;
培训完成后带回用户反馈单、用户培训反馈表交给项目经理。
现场培训
现场培训在实施现场进行,由我司的培训工程师担当。我司的培训工程师接到实施任务之后,到用户指定的现场给用户讲解系统原理和操作步骤,培训平台软件功能,并及时解答用户的疑问。
在系统试运行期间,如果用户需要,我司将派工程师常驻现场给用户进行功能培训和操作指导,最大程度的满足用户的培训需求。
4.5.1 技术培训地点
培训按照培训地点分为集中培训和现场培训,按照培训方式来分有理论培训、操作培训。针对不同层次的人员,开设不同的培训课程。
(1)集中培训
集中培训地点可设在用户指定地点,采用集中授课的方式进行培训。
培训地点:用户指定
(2)现场培训
现场培训又可以分为现场安装调试培训和现场集中操作培训
A、现场安装调试培训,在系统软件安装调试时进行,主要是针对业主系统维护人员和现场维修人员进行的。
培训地点:安装现场。
B、现场集中操作培训,在系统安装调试完成后,分别在各站点集中进行,主要培训对象是系统管理员、系统维护人员和系统操作人员。
培训地点:现场办公所在地。
4.5.2 技术培训规范
项目培训主要规范如下:
对培训方案、培训大纲请用户方评审,将充分尊重用户意见,并适度调整计划后实施。
培训前做好培训环境测试,确保培训时所有环境能够正常使用。
培训过程中,对于用户反馈的问题和需求,培训讲师需要详细记录,并与公司相关人员沟通后,采取合适方式较为及时的回复用户。
在培训时发现非技术性的重要问题后,需要及时记录,项目组讨论处理意见反馈问题提出者。
在培训数据录入时应注意保密,不要采用敏感数据;培训后及时清除培训所用的临时数据;
培训方案、培训大纲、培训讲义、培训参考资料、培训技术人员签到、培训技术人员反馈、培训技术人员考核均作为培训记录进行统一归档保存。
4.5.3 技术培训教材准备
培训所使用的培训材料和文件资料,将在培训开始之前2个星期提交给项目管理团队进行确认。
我司将提供给项目管理团队培训计划中每一课程的详细材料,包括系统操作手册,系统使用说明书、系统维护手册及系统宣传品、宣传资料等。
培训语言均采用汉语普通话,所有的培训材料,包括音像制品均应采用中文。所有与培训相关的外文资料译成中文,并以中文版本为准。
1、编写培训方案
培训方案的内容主要包括:
1)培训的目标;
2)培训的内容简介;
3)培训起止时间;
4)使用的培训设施;
5)培训的教材和文件清单;
6)培训对象;
7)培训地点;
8)授课人员的姓名及职称;
9)课程效果的评估方法。
10)培训过程记录表
2、撰写培训大纲
培训大纲是课程的初步设计,主要是针对课程的内容、知识深度、培训对象的知识和功能熟悉程度、培训对象的需求进行初步的设计。在培训前将提交用户方培训组织者审核,以保证培训的针对性、有效性、适用性。
培训大纲主要内容:
1)培训教师简介;
2)培训需要解决的主要问题;
3)培训内容提纲设计;
4)培训要点设计
5)培训练习设计
6)培训参考资料清单
7)培训效果评估方式;
8)培训对象的知识技能基本要求
9)其他
3、组织培训讲义
培训讲义是为卓望公司技术人员准备的正式课程内容,以培训大纲为依据,并增加参考材料,讲义编写采用中文,内容必须详实,易于卓望公司技术人员的理解,如果有合适的现成参考教材,也可当作培训讲义发给培训技术人员,但是要保证培训讲义上的内容和培训大纲的内容密切结合。与培训内容有联系的书籍可以作为培训的其它参考资料提供给培训对象。
4、培训材料的审核
各培训方案、培训教材由我司内部评审后,交用户方、监理方审核后,交付印制并发放。
4.6 技术培训考核
为使培训人员不断进步而达到培训计划要求,所有培训人员都应经常接受测验和考试,取得进展和足够的培训,并且在培训结束时通过考试,确定他们可否称职地完成将被赋予的任务和工作。
5 售后服务方案
5.1 项目售后服务方案
5.1.1 售后服务体系
我司已通过ISO9001:2015质量管理体系,长期坚持将该体系贯彻到整个运营、销售管理等过程中,建立完善的售后服务程序及项目专项文档管理制度,成立优秀的售后服务团队。
热线服务是我司在售后服务阶段提供的一种服务方式、一个统一的服务接口,相关服务人员均由具备丰富服务经验的技术人员组成。
售后服务实行专人建档负责方式,博云项目组在项目交付验收完成后,将根据项目的实际情况按要求向售后服务部门移交相关项目信息,在确保售后服务能及时了解客户方的平台功能需求、项目情况的同时,确保了售后服务人员能及时、高效解决用户提出的问题。
总部售后服务机构信息表
机构名称 |
XX客户中心 |
机构地址 |
XX省XX市XX路XX号 |
售后服务人员数量 |
XX人 |
电话 |
|
24小时服务热线
服务热线:400-685-3099(7*24小时不间断值班)
服务电话:0512-62968980
服务传真:0512-62968980
服务网址:http://www.bocloud.com.cn/
5.1.2 售后服务内容
5.1.2.1 售后服务原则
1、合规性
合规性,要求在运维管理过程中能避免违反任何法律、法规、标准与合约文件等规定。这里要求项目建设在运维管理的管理框架设计与执行全过程,能充分考虑有关文件的要求,并在运维管理过程中留下相应的记录,建立起相应的管理评估机制,以向相关方证明其能达到合规性的目标。
2、可用性
可用性,要求体系在运维管理过程中能保证体系各功能组件保持支持既定功能的能力。这里要求体系在运维管理过程中能准确识别相关功能组件,了解该组件的设计能力,定义与该组件技术特点相匹配的监控指标,并通过主动与被动的管理,最大限度地保证体系各管理组件的可用性。
3、服务性
服务性,指体系应建立服务导向型的运维管理框架。要从服务的角度出发,分析用户与体系的各种交互界面,以此为源头构建各种管理流程,最终形成整体管理框架。比如,体系在管理体系的设计上可以参考ITSM(IT服务管理体系)的要求,建立服务台、服务水平管理、业务关系管理等流程,以此来驱动后台运维管理工作。
5.1.2.2 售后服务标准
一、服务与技术支持保证
我司在产品维护期一年内提供每天24小时,每周七天,每年365日有技术工程师提供支持服务。
二、紧急情况服务保证
我司根据如下故障级别提供相应的服务并在故障修复后提供服务报告。
(1) 故障级别
l 一级故障:指系统崩溃或系统性能严重下降,平台系统无法正常运行;
l 二级故障:指系统性能有一定下降,平台系统受到干扰;
l 三级故障:指系统可以运行,但系统有不明原因的报错。
(2) 故障响应
在一级故障发生时,我司承诺在30分钟内提供电话支持, 本地2小时内到达现场;保证在到场后4小时内恢复运行,排除故障。
在二级故障发生时,我司承诺在30分钟内提供电话支持,本地4小时内到达现场;到场8小时内恢复运行,排除故障。
在三级故障发生时,我司承诺在30分钟内提供电话支持,本地8小时内到达现场;到场24小时内恢复运行,排除故障。
三、例行保养维护保证
我司提供本次购买保修期内的每月巡检。并在保修期过后,终身提供每月一次的巡检。巡检后我司提供现场用户签字认可的服务报告。巡检内容包括:
- 检查系统软件情况;
- 检查文件系统情况;
- 检查系统性能;
- 检查备份情况;
5.1.2.3 服务响应机制流程
5.1.2.3.1 技术咨询
(1) 服务提供方名称:我司项目团队&我司公司技术支持平台
(2) 服务内容:
(3) 我司售后服务工程师在接到项目各级用户要求时,即时向用户提供相关技术咨询,指导用户进行系统操作,对系统提供技术支持,为项目全天全年的不间断运行提供技术保障。
(4) 服务方式:热线支持、电子邮件支持、第三方通讯工具
(5) 服务人员技术要求:具备3年以上云管项目技术支持经验
(6) 服务响应时间:根据客户需要服务,热线及第三方通讯工具实时服务,电子邮件支持1~3个工作日答复。
5.1.2.3.2 重大时刻现场值守服务
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
(3) 对于通过热线及远程支持无法解决的故障,我们提供现场值守服务,在经过双方商议确定需要进行现场值守,保证系统平稳运行的情况下,我们将在约定的时间内委派专业的技术支持人员到达服务现场,提供现场服务响应,配合客户人员。保障系统平稳运行。
(4) 同时,根据最终用户的需要,在特殊时期(如节假日、重大变更等重要时期)免费为最终用户提供现场技术支持保障,并按最终用户要求提交技术支持报告。
(5) 针对用户支持工作,由专门设立的技术支持服务组承担,所有维护人员都是参与实施、维护和应用方面的有经验的服务工程师构成。
(6) 服务方式:派驻工程师现场支持;
(7) 服务人员技术要求:具备3年以上云管项目技术支持经验;
(8) 服务响应时间:故障影响支持,重要时间节点专人值守。
5.1.2.3.3 系统维护&故障响应服务
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
在质保期内,对于正常使用过程中出现的告警事件及故障,我们将会免费负责系统的调试或维护。为了保证大型项目的实施及运行,配置充足的技术支持人员是十分重要的。我司承诺向客户提供长期的技术支持。
系统运行维护的主要内容有:
- 系统运行状态
- 数据库系统运行状态监控
- 中间件系统运行状态监控
系统服务工程师填写《系统运行记录》,该记录主要内容包括系统的主要运行参数,如:系统的运行状况(用户登录情况、数据增长情况等)、中间件的运行状况(在线用户量、连接数、内存使用情况、CPU使用情况、Web服务会话情况、数据连接池等)、数据库服务器的运行状况(命中率状况、事件等待、数据字典使用状况、排序状况、会话状况、Rollback段使用状况、Redo Log使用状况、表空间使用状况、登录用户状况、Alert日志、内存使用状况、CPU利用状况)等等;
系统服务工程师每天必须查看相关的系统日志、应用日志、数据库日志等内容,判断在线系统的运行状态。
系统服务工程师每周根据《系统运行记录》,整理成《系统运行周报》,对运行状态进行分析,发现运行过程中的系统问题,并向用户运维机构汇报。
各系统接口运行状态监测,主要包括本项目中涉及到的与其他系统的接口和集成运行状态的监控,监控主要包括:接口状态、接口所涉及到对方服务器的运行状态、数据交换状态等。
运维工程师监测接口运行状态,并根据应用系统报警情况随时进行监控。
(3) 服务方式:工程师现场&远程支持;
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验;
(5) 服务响应时间:项目质保期内。
5.1.2.3.4 系统升级服务
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
为了提高系统的运行效率,或者增加系统运行的稳定性,或者提高系统承载应用的能力,需要对应用系统、应用系统相关接口、应用系统运行环境包括系统软件进行升级工作。
系统服务工程师和开发工程师将全面负责完成应用系统升级部署工作;系统服务工程师和应用服务工程师将全面配合和支持应用系统相关接口和应用系统运行环境包括系统软件升级。
系统升级的关键部位有:
² l 平台软件升级;
² l 应用相关接口
² l 数据库版本升级;
² l 中间件系统版本升级;
在系统升级过程中,将遵循如下的工作规范。
l 升级原因分析报告
升级原因分析报告将会详细分析升级的原因、升级过程、以及升级后平台性能监测数据,为后续系统建设和规划提供素材。
l 系统升级实施规范
- 《系统升级任务单》
主要是分解系统升级时的各项任务,包括各项任务的责任人和工作标准。
- 升级前的准备
主要的工作有:
l l 通知使用系统的相关单位;
l l 实施人员准备,应该是各个专业的专家级技术人员;
l l 参数准备,包括主机、数据库、应用系统等参数;
l l 系统升级实施计划;
l l 系统升级相关技术文档;
- 升级实施
按照升级计划准备相关人等,按照升级步骤进行升级工作。
- 系统测试与总结
按照配置管理规范,填写《配置修改记录表》,并认真编写系统升级的文档,包括升级步骤、备份操作、配置文档等。
(3) 服务方式:工程师现场&远程支持
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验
(5) 服务响应时间:质保期内,根据客户平台功能需求或定期(每半年/每年)进行系统升级。
5.1.2.3.5 系统性能调优服务
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
为了使本系统可以稳定和高效的运行,需要定时对整个系统进行性能调整和优化。
在系统性能调整的过程中,将遵循如下的工作规范。
l 性能分析报告
主要是性能分析,主要有:portal门户、后台应用软件、数据库及中间件系统、外部接口调用等,尤其是应用系统的性能分析,它可能是导致系统性能降低的关键因素。
l 性能调整实施规范
- 《系统运行性能报告》
主要是收集目前系统运行的性能参数和使用环境参数,作为系统性能的基线。详细分析系统运行过程中各个软件的性能参数对系统性能的影响,找出影响性能的关键因素,为系统性能调整做好准备工作。
- 《系统性能调优测试报告》
搭建测试环境,针对上面的《系统运行性能报告》的因素分析,对影响性能的关键因素进行调整,通过模拟系统的运行环境,对整个系统进行性能测试。系统性能影响的关键因素很多,既有单因素性能测试,也有多因素综合系统性能测试。
测试结果很重要,在系统正式调优前,必须要进行参数调整的测试工作。
此测试报告每次进行调优之前进行提交。
- 系统能调整准备
有了性能基线数据和测试报告,可以开始进行系统调优的准备工作了,准备工作可能包括:
² l 通知使用系统的相关单位;
² l 实施人员准备,应该是各个专业的专家级技术人员;
² l 参数准备,包括主机、数据库、应用系统等参数;
² l 性能调优实施计划;
² l 性能调优相关技术文档。
l 性能测试与总结
² 系统性能调整实施
按照实施计划和准备工作对整个系统进行调优工作;
² 《系统性能调整的总结》
系统性能调优完成后,收集平台系统运行参数、配置参数和调优过程中的相关信息,记录调优过程中的问题和解决办法,形成规范文档。此文档归档。
(3) 服务方式:工程师现场&远程支持、热线支持、电子邮件支持;
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验;
(5) 服务响应时间:平台试运行期间或质保期间,根据客户反馈的性能问题进行系统性能调优。
5.1.2.3.6 系统定期巡检
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
售后服务期内,我司每季度进行例行巡检(不收取额外费用),对用户的系统运行情况进行定期检查、优化,通过采取预防措施,对潜在的故障点进行分析诊断,达到预防目的。每次巡检后,我司都将提供《系统巡检报告》。
同时,针对每次例行巡检的结果和平时的累积故障报告,我司提供《系统故障统计分析报告》和《系统运维建议》,提供给用户评估维护工作的参考依据,帮助提高系统的维护水平。
巡检服务工作内容如下:
- 自服务合同签订日起,按照服务合同约定的服务期限,预先制定巡检计划。
- 巡检前,巡检人员前往客户现场,沟通巡检所需无故障检查的项目,例如:系统补丁更新等,制定详细的巡检计划和日程安排表,以方便客户配合我司的工作。
- 如当天无法准时到达巡检地点应及时和客户联系,并得到其谅解。
- 到达巡检地点后,先和客户见面,交代本次巡检的任务和目的,并了解巡检地点的环境,而后根据客户的具体需求和环境的客观因素进行巡检。
- 在巡检的过程中,应先得到卓望公司项目经理的同意,然后再进行具体的操作。
- 在巡检的过程中,应按照事先拟定的巡检计划中的内容,对每台巡检操作系统的运行状况进行记录并且让客户在服务单上签字确认。
- 某地点巡检完成后,应先通知客户,在得到客户的认可并在服务单上签字后才能离开。
- 巡检结束后,由巡检负责人收集相关数据,以书面报告的形式交给客户查阅,如果在巡检过程中存在问题,需及时配合客户制定补充方案,以保证高质量完成每次巡检工作。如果对本次巡检无问题,则请客户在巡检报告上签字确认。
(3) 服务方式:工程师现场&远程支持;
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验;
(5) 服务响应时间:根据客户要求,定期(每季度一次)进行系统巡检。
5.1.2.3.7 日志分析
(1) 服务提供方名称:我司项目团队
(2) 服务内容:
定期检查系统日志,及时预防处理潜在的问题形成日志检查报告。日志主要包括数据库日志与应用系统日志。
数据库日志:使得系统发生故障后能提供数据动态恢复或向前恢复等功能,确保数据的可靠性和一致性。
应用系统日志:通过记录应用系统中操作日志,为将来事后审计提供数据分析源,确保平台功能的可追溯性。
(3) 服务方式:工程师现场&远程支持、电子邮件支持
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验
(5) 服务响应时间:项目质保期内,定期进行系统日志分析,或根据客户反馈问题进行系统日志分析。
5.1.2.3.8 技术共享
(1) 服务提供方名称:我司项目团队,我司公司技术共享平台;
(2) 服务内容:
我司公司通过技术支持经验的积累,建立技术支持知识库对保证整个系统稳定运行至关重要。
项目的实施过程及技术支持与服务过程中,公司技术人员将在技术支持知识库中实时统计记录发生的技术问题,同时,在每季度末将安排资深技术支持人员将本项目中出现的技术问题及解决办法进行汇总分类、整理并发布。及时同步客户技术人员。帮助客户对知识库进行丰富和更新,以便客户技术人员能够了解和掌握最新的技术、产品信息。
(3) 服务方式:工程师远程支持、电子邮件支持、第三方通讯、公司官网在线文档库
(4) 服务人员技术要求:具备3年以上云管项目技术支持经验
(5) 服务响应时间:项目质保期内。
5.1.3 售后服务方式
我司在项目技术支持和售后服务方案的制订上,坚持“最强实施团队,最高级别要求,最全服务方式”的原则,尽最大努力做好技术支持和售后服务工作,免除各级用户的后顾之忧。在技术支持和售后服务方式的选择上,将处处从项目的特点出发,贴身定制,保证每一级用户、每一类用户都能够感受到最妥帖、最满意的服务!
5.1.3.1 热线支持服务
我司对客户提供长期的免费7*24热线支持服务。此外,全部技术人员的手机7×24小时开机,并且开通呼叫转移等服务,确保项目单位能够及时与技术支持人员取得联系。保证7×24小时实时响应客户的技术支持与服务需求。
接到客户的技术支持请求或故障报告后,项目经理将立即以电话方式详细了解其所需的服务内容,提供相应解答,并且填写详细的记录表单。
对于技术咨询,技术人员会结合实际情况及时为客户提供相应的答复。
对于系统运行故障,项目经理首先会了解与故障有关的详细情况,在技术支持人员的配合下进行系统分析,逐步排除故障。
5.1.3.2 远程支持服务
对于通过电话支持服务中不能解决的软件故障,在条件允许的情况下,征得客户同意后,以远程登录的方式进行故障诊断,目的在于尽早查找故障出现的原因,最大程度地缩短故障恢复的时间。
当我司工程师无法到客户现场时,可在客户授权下网络接入方式进入客户的系统网络中,直接对客户系统进行诊断分析及维护服务。
网络运行分析与管理服务是指我司工程师通过对网络运行状况、网络问题进行周期性检查、分析后,为客户提出指导性建议的一种综合性高级服务。
远程技术服务主要是通过电话或其他方式受理客户和驻点工程师的疑难问题,通过沟通来指导客户或驻点工程师解决问题,同时远程技术服务工程师还通过电话或者其他方式与客户主动沟通来提高客户管理和运维能力。
服务内容 |
服务优点 |
向客户提供技术专家电话号码 |
保证重大问题第一连线至技术专家。 |
技术专家组每周与客户进行不少于2小时的电话技术交流 |
以最小成本保证及时解答客户关心的技术问题,并就某一领域技术问题展开深层次沟通 |
每月向客户提交CASE汇总分析报告,并可扩展到季度 |
使客户了解历史故障情况以及故障预防建议,最大程度减少系统故障隐患,更高效的进行系统管理 |
5.1.3.3 现场支持服务
对于通过热线及远程支持无法解决的故障,在经过双方商议确定需要进行现场故障排除的情况下,将在约定的时间内委派专业的技术支持人员到达服务现场,提供现场服务响应,尽快解决问题。总之,我司承诺尽最大的努力解决系统的问题,保证在最短时间之内恢复系统正常运行或者提供应急策略。对于技术故障,我司保证故障不解决,技术人员不撤离。
当出现紧急情况时,可以通过电话、传真或电子邮件等方式告知我司,如果情况紧急或不便于使用远程手段解决,我司将指派具有丰富经验的技术人员赶赴现场,进行现场技术支持服务。
如果用户的系统软件出现故障,或通过电话等技术支持服务方式仍无法解决用户问题时,客户服务流程进入现场支持服务阶段。
本公司项目管理组将由技术支持服务人员,以最快的速度到达用户现场,分析原因、解决故障,保证用户整个系统顺利运行。
针对比较复杂的项目,我司的专业技术人员可以来到客户现场,通过仔细的调查研究,为客户解决实质问题。
对客户的系统进行现场维护和巡检,驻点工程师对各个应用系统完成定期巡检,同时输出巡检报告提交给客户。
5.1.3.4 电子邮件支持
在整个质量保证期内,我司为最终用户提供7×24的电子邮件支持服务,以书面形式告知最终用户有效的支持服务电子邮箱,以及提供支持服务过程中需要最终用户准备的信息,如电子邮箱有变动须提前书面通知最终用户。
电子邮件支持服务内容包含系统的所有软件和配置问题。
客户的技术或非技术问题及建议可以通过电子邮件方式发送给我司的技术支持人员并及时给予答复。
5.1.4 重要时刻专人值守服务
我司深刻知道保证重要时刻系统软件稳定运行对客户成功尤为关键,因此,我司可对客户提供重要时刻的专人现场值守支持,如客户的重大会议期间或其它任何客户认为可能对其平台功能运营产生重大影响的时刻。
5.1.5 定期巡检服务
公司技术服务中心将按与用户签订的支持服务协议规定,提供定期现场巡访或不定期电话巡访服务,与用户一起共同对系统进行性能调优、系统诊断,系统日常维护管理方面的交流,为客户进行定期的预防性维护服务。
5.1.6 售后质量保障
我司设有专业的质量控制管理部,负责制定各项详细的考核指标,并接受用户的投诉,同时对内部各专业部门进行严格的监督考核,以保证向客户提供高质量的服务。
5.1.6.1 服务考核评估
我司制定严格的服务考核评估体系,对运维服务质量进行考核,提高运维服务水平。
系统运行的主要统计:
- 系统可用率;
- 操作系统的可用率、CPU利用率,内存占用率、磁盘空间占用率;
- 系统发生故障的次数、类型和历时;
- 重大故障次数和历时;
- 用户申告次数和修复及时率;
- 发生安全事件的次数、类型和影响;
- 系统软件发生事故的次数和历时;
维护质量指标:
- 故障修复及时率——在规定时限内修复故障的次数与故障总次数之比;
- 重大故障、紧急故障发生次数——在统计时间内,重大故障发生的次数。
5.1.6.2 故障申报及处理
故障受理
项目经理负责统一受理客户故障申告。
故障转派
项目经理在受理故障申告后,及时进行故障转派:根据系统运行故障分类进行安排,由相应的维护人员接障。
故障解决
运维人员收到项目经理报障后,立即组织协调、解决故障。若维护人员如遇到重大故障和疑难问题则向项目经理提交,项目团队负责进行技术支撑;项目经理如遇到重大故障和疑难问题则向总经理助理提交,总经理助理负责进行技术支撑。
故障上报
各单位遇到重大故障在积极处理的同时上报项目经理,并由项目经理统一处理。
故障通报
当各类维护人员发现影响系统平台故障时及时通报项目经理。
故障分析报告
重大故障处理完毕后按相关维护管理规定向所属上级部门提交详细的分析报告。
故障维护考核
各类维护人员及时判断故障段落,指挥故障的修复,并清楚记录故障处理情况,按要求及时通知用户,在故障通报过程中,各工序间要进行横评配合度考核。
5.1.6.3 长期技术服务措施
5.1.6.3.1 长期技术服务措施
技术支持及售后服务内容应包括但下述内容:升级服务、定期巡检、性能调优、故障排除等。
1、技术咨询服务
提供终身的技术咨询服务,包括新软件新技术通报,软硬件技术咨询,系统改进意见,提供技术方案,项目长远规划,研究解决技术难题等。
2、维护服务
我司协助最终用户完成日常系统及应用的维护工作,保证系统的正常运行。
3、巡检服务
我司定期派合格工程师到最终用户现场对软件进行巡检,全面检查系统的软件运行情况,记录系统的错误,排除故障隐患,进行系统调优工作。在维护保修服务期内,巡检频率为1次/季度。每次巡检,我司分析系统运行情况,提供系统日常运行维护建议并形成巡检报告提交给最终用户,报告须经最终用户签字确认。
4、系统升级
我司配合最终用户分析系统运行状态,提出修正性软件安装的技术建议。我司根据最终用户的需要,结合系统的实际情况,向最终用户提供系统升级报告,提供相关的升级软件,制定升级方案,提供升级安装服务。
5、补丁安装
我司为用户的操作系统提供相关的软件更新信息通知及安装服务,对系统的新发现的BUG、新的补丁和故障隐患进行及时的通知,防止BUG和未及时打补丁造成的故障。并提供以下信息:补丁说明书的功能描述和目的;补丁的测试结果;补丁装入的计划、步骤,用户需做的准备工作,可能对系统造成的影响。
6、现场待命
我司根据最终用户的需要,在特殊时期(如节假日、重大变更等重要时期)免费为最终用户提供现场技术支持保障,并按最终用户要求提交技术支持报告。
7、故障修复
故障修复指当最终用户的系统出现故障(如服务中断、数据丢失、系统不能正常工作等)时,我司为最终用户提供系统修复及系统软件故障排除的服务。
在整个维护服务保修期内,我司为最终用户提供7×24的故障修复服务。当系统发生故障时,我司在接到最终用户申请后30分钟内作出实质性反应,并派出合格工程师在2小时内到达现场。
我司以书面形式告知最终用户故障申请的方式、申请的流程,以及申请过程中需要最终用户准备的系统信息(如软件序列号等)。
当系统发生故障时,我司启动公司的多层技术资源支持,帮助客户排查问题,直到问题最终获得妥善处理。对于客户系统的重要问题,至少每天汇报一次问题解决情况,须协助最终用户进行问题定位,就解决问题所需要相关系统信息的收集方法,指导最终用户的技术人员。
我司帮助最终用户进行问题根源的分析和诊断,提出解决问题的建议方案。
8、电话支持服务
在整个维护服务保修期内,我司为最终用户提供7×24的电话支持服务,受理故障报修,解答最终用户技术人员的技术咨询问题。我司以书面形式告知最终用户有效的支持服务联系电话,以及提供支持服务过程中需要最终用户准备的系统信息。服务支持联系电话除指定一个固定电话号码外,须另提供一个手机号码。如电话号码有变动,我司提前以书面形式通知最终用户。
电话支持服务内容包含系统的所有软件和配置问题。
9、电子邮件支持服务
在整个质量保证期内,我司为最终用户提供7×24的电子邮件支持服务,以书面形式告知最终用户有效的支持服务电子邮箱,以及提供支持服务过程中需要最终用户准备的信息,如电子邮箱有变动须提前书面通知最终用户。
电子邮件支持服务内容包含系统的所有软件和配置问题。
如果在系统运行过程中与其它系统无法共同正常稳定运行,我司积极配合其它系统的提供商,协助解决问题。
5.1.6.3.2 服务标准
一、服务与技术支持保证
我司在产品维护期内提供每天24小时,每周七天,每年365日有技术工程师提供支持服务。
二、紧急情况服务保证
我司根据如下故障级别提供相应的服务并在故障修复后提供服务报告。
(1) 故障级别
- 一级故障:指严重系统故障,系统宕机、崩溃,或关键部件损坏,主机无法工作,平台功能系统无法继续运行;
- 二级故障:指部分系统故障,系统性能严重下降,主机可以工作,影响和限制了平台功能系统运行;或系统在运行中出现的故障具有潜在的系统瘫痪或业务中断的危险。
- 三级故障:指一般性技术故障,整个系统的操作性能受损或性能下降,但系统仍可保持正常运转或最终用户平台运作仍可以正常工作。
(2) 故障响应
在一级故障发生时,我司承诺在30分钟内电话响应;本地2小时内到现场;都保证在到场后4小时内恢复运行,排除故障。
在二级故障发生时,我司承诺在30分钟内电话响应;本地4小时内到现场;到场8小时内恢复运行,排除故障。
在三级故障发生时,我司承诺在30分钟内电话响应;本地8小时内到现场;到场24小时内恢复运行,排除故障。
三、例行保养维护保证
我司提供本次购买系统软件维保期内的每月巡检。并在保修期过后,终身提供每月一次的巡检。巡检后我司提供现场用户签字认可的服务报告。巡检内容包括:
- 检查系统软件情况;
- 检查文件系统情况;
- 检查系统性能;
- 检查备份情况;