大数据中心平台项目实施及售后服务方案文档格式.docx
- 文档编号:20600641
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:21
- 大小:155.33KB
大数据中心平台项目实施及售后服务方案文档格式.docx
《大数据中心平台项目实施及售后服务方案文档格式.docx》由会员分享,可在线阅读,更多相关《大数据中心平台项目实施及售后服务方案文档格式.docx(21页珍藏版)》请在冰豆网上搜索。
职称资格
主要资历经验及
承担过的管理项目
人数
项目经理
项目经理整个项目组织中的核心角色,负责整个项目的实施;
指导、控制、管理和调整项目进行构造软件或硬件/软件系统工作的个人
具备2个以上的大型集成项目负责人资历的项目经理
1
系统分析师
了解客户新的需求,受理需求及合同变更,系统整体架构设计
理解行业术语和行业业务,同时精通技术发展趋势,富于沟通技巧
质量保证人员、配置管理员
负责本项目的质量管控,控制软件产品的状态和一致性,确保产品的有序变更和发布
熟悉标准化质量管控;
熟悉公司的质量管理流程
开发人员
负责编码实现客户的定制需求
3年以上的软件开发工作经验
2
测试人员
负责监督和检验软件过程与标准的符合性以及软件产品生产规范的符合性
3年及以上的软件测试相关工作经验
系统实施及售后维护
负责系统部署,网络建设,设备和软件安装,基础数据导入,负责本系统相关的运行和维护工作
2.2.2.项目过程管理
2.2.2.1.项目沟通管理
沟通是人际之间传递和沟通信息的过程,对于项目取得成功必不可少,而且非常重要。
沟通的主旨在于互动双方建立彼此相互了解的关系,相互回应,并期待能经由沟通的行为与过程相互接纳及达成共识。
我公司的沟通管理体系包含以下内容:
沟通计划编制、信息分发、绩效报告和项目干系人管理。
针对项目特点,结合相关的战略,我司建议采用如下策略进行沟通管理:
1、建立清晰的沟通管理计划,实现可管理的沟通
项目沟通计划是项目整体计划中的一部分,它的作用非常重要,也常常容易被忽视。
计划前,团队里应建立起一种相对稳定的、可以重复执行的沟通管理计划,只要能训练成员重复执行,沟通过程必然能逐渐演化和成熟,沟通就有实现可管理的可能。
沟通计划包括:
确定文件资料保存方式、项目相关人员联系方式、项目成员间的工作汇报方式和项目统一文件模板。
首先,根据本项目特点,组织团队成员分析客户方的组织结构,根据摸底,确定各干系人分别对其组织、对项目的影响度,形成“项目干系人影响度分类表”;
再进行各干系人信息需求分析,确定“项目关系人信息需求表”,确定此表时对关键项目干系人进行了意见征求,目的是判断能否满足其需求并确定合适的信息格式、报送方式。
影响度分类表和信息需求表的结合,可以提供项目关系人的需求和预期,以及用于沟通的信息的格式、内容与细节水平。
根据此工作方法,再分别确定本项目公司管理层、外部其它项目干系人等,通过这些工作则基本完成了沟通管理计划的主体工作。
这个分析确认过程项目管理团队需要全部参加,以加强对项目干系人特性了解及沟通时的敏感性。
沟通矩阵帮助了团队理解如何以标准而连贯的形式定期就项目进展进行沟通,促使沟通系统化;
团队成员有清晰的沟通模式,知道自己“什么时候”该向“谁”以“哪种”形式沟通“什么”信息。
沟通管理计划的强化执行使项目的沟通逐渐朝有序化发展。
2、内部沟通注重文档化,实现团队及组织经验的有效积累
对于较新型的项目,由于项目经验非常缺乏,那么通过对项目的建设,把项目成员个人的成功经验通过信息共享、传递和使用转化为团队以及整个项目公司的组织经验,是我们在项目沟通管理中要考虑的重要问题。
特别是针对IT行业人员流动大,对信息管理缺乏重视的现状,加强项目团队经验的积累,更显急迫。
在项目管理过程中,为了贯彻沟通注重文档化思想,我们需要建立规范的文档管理规范,主要包括三点:
1、信息格式规范化。
要求制作的文档格式符合项目团队规定的文档模板要求,以统一文档风格。
此举主要目的是用相对固定的格式统一语境平台,令沟通更为便捷、准确,防止各人随意发挥,文档百花齐放。
2、保证数据的真实、准确。
在项目建设中,即使是一些普通的业务,也涉及到大量的数据工作,还要提交一些必备材料,这些业务流程图、输入输出表格、必备材料以及相应的法律法规,在项目的需求过程中都需要作真实、准确的记载。
一是为了提高技术沟通的准确性,减少冲突。
二是方便项目新成员学习及日后的维护;
3、文档的共享与学习。
文档存在的目的之一在于在团队中快速共享技术经验,避免成员间的重复沟通、反复沟通,增加沟通成本。
如一些项目带有一定的研发性质,有大量的新知识需要学习,那么可以安排一些技术较好的项目组成员预先进行了较深入的研究,然后在成员之间进行了深入的沟通和交流,较快地掌握技术的核心。
然后他们把掌握到的知识要求编制成规范统一的技术文档,通过文档的共享,加上一定的培训,所有成员都能很快掌握这些技能,避免了重复沟通和“知识专有”,加速知识和经验在团队中的传播。
3、早沟通、主动沟通,把握沟通原则
项目实施中最怕沟通得晚,问题暴露得迟。
为提高沟通的效率和效果,主要有以下基本原则:
1)团队整体意见一致,一个团队要用一种声音说话。
2)非正式的沟通有助于关系的融洽。
比如在需求获取阶段,采用非正式沟通的方式,可以拉近距离,反而能获得更多的信息。
3)采用对方能接受的沟通风格。
注意肢体语言、语态给对方的感觉。
4)沟通的升级原则。
当沟通上出现困难时,可以采用沟通升级原则,即第一步,和对方沟通;
第二步,和对方的上级沟通;
第三步,和自己的上级沟通;
第四步,自己的上级和对方的上级沟通。
5)扫除沟通的障碍。
职责定义不清、目标不明确、文档制度不健全、过多使用行话等都是沟通的障碍。
在平常的项目进行过程中,必须尽量避免出现这样的情况,逐步清除一些不良的沟通习惯。
4、项目实施情况的汇报
项目实施情况报告通过三种形式:
定期报告,阶段审查,紧急报告。
1)定期报告,就是在某一特定的时间内将所完成的工作量向上级汇报。
在实际的项目管理中项目人员对项目经理按周报告,对于客户和项目经理的直接上级是按阶段或月进行统一的进展报告,从项目管理上讲,项目定期报告的主要内容就包括:
当前是什么状态,在什么阶段,进度完成情况,当前有什么问题请上级(用户)协助解决,下周(下阶段或下月)的计划是什么等等。
从而规范项目组织间工作交流、任务传递、消息共享、问题商讨的方式方法,包括但不限于:
邮件沟通机制、周例会机制、专项会议机制、周报机制、月报机制、工作联系单机制及联络机制等。
确保各种通知、工作计划、会议纪要、重要提示、调整方案、需协调解决的问题、上级最新指示和要求能够顺畅地上传下达,确保重大事项及时向客户通报和汇报。
2)阶段评审:
在项目进行到重要的阶段或里程碑似的项目发展阶段,就要进行阶段评审。
阶段评审的意义就在于评审当前的项目情况,迫使人们对其工作负责;
阶段评审可以提前发现问题,提前将问题解决在初期阶段。
不过阶段评审也是最容易产生争执的地方,这主要是针对于问题严重性的定级,项目经理或项目管理委员会必须在全面了解项目发展进展的情况下及时找到问题的重点,从而就事论事的解决问题的真正症结所在,并进行后面的项目。
3)紧急报告:
在出现意外情况下,进行紧急报告。
紧急报告包括以下内容:
当前发现的问题,相关影响,如何解决(动用什么资源),问题紧迫性(必须什么时间内进行反馈)。
以上最终目的是为提高客户满意度,与客户建立长期良好的合作关系,实现共赢。
2.2.2.2.进度管理说明
项目启动后,我司将与采购人共同确定详细的项目进度安排,以采购文件为基础,结合我司的投标书,明确每个阶段的阶段目标、阶段应交付的成果、验收依据、双方的责任和义务,经采购人认可后,以合同或会议纪要形式加以明确。
我司的项目进度管理应该遵循以下原则:
(1)项目进度管理的依据是项目合同所约定的工期目标;
(2)在确保项目质量和安全的原则下,控制项目进度。
我司的项目进度管理应该至少包含以下内容:
(1)我司在了解项目特点的前提下,根据工期目标,提交总体进度计划,以及定期提交阶段性工作计划;
(2)制定详细的项目建设进度计划,定期跟踪检查,对可能发生的工程延误提出相应对策;
(3)定期或不定期地召开或参加项目例会、协调会议等,向采购人汇报项目进展情况,提交进度报告,及时解决相关问题;
(4)建立项目变更流程,记录项目变更情况。
2.2.3.质量管理
2.2.3.1.质保管理体系
在项目实施期间,质量保证组负责质量保证工作。
质量保证组由质量保证人员负责,由各组指定的质量保证人员组成。
各组质量保证人员在业务上受质量保证组领导,在行政上受各组负责人领导。
质量保证组和质量保证人员必须检查和督促质量保证工作的实施。
各组质量保证人员有权直接向质量保证组报告各组质量状况。
各组的质量保证人员应该根据对项目该阶段的具体要求,制订质量保证的规范标准和组织措施,以确保完全遵守规定的所有要求。
质量保证工作涉及项目生命周期各阶段的活动,贯彻到日常的开发活动中。
本公司质量保证措施特别注意软件质量的早期评审工作及进度质量保证。
对新开发的或正在开发的各子系统,需要按照本措施的各项规定进行各项评审工作。
质量保证组要派成员参加所有的评审与检查活动。
评审与检查的目的是为了确保在项目开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。
在项目开发实施过程中,应当进行以下三次评审:
第一次为项目概念阶段的需求评审;
第二次为项目设计开发过程中的过程评审,并对第一次评审结果进行复核;
第三次为项目验收阶段的验收评审。
阶段评审:
要组织阶段评审小组,原则上由项目管理组成员或特邀专家担任评审组长,评审小组成员应该包括项目委托单位或用户的代表、质量保证人员、上级主管部门的代表,其他参加人员视评审内容而定。
每一次评审工作都应填写评审总结报告、评审问题记录、评审成员签字与软件问题报告单等四张表格。
日常检查:
在项目的开发过程中,各子项或子系统应该填写项目进度报告。
项目状态报告的格式与附录B中的规定相一致。
项目验收:
要组织专门的验收质量保证组对项目中交付的软件系统及其所属各个子系统进行质量验收。
以下是项目组织架构(成员)的质量保证职责和权限。
项目管理组
●由项目经理、技术总监、测试经理组成,对公司及客户负责
●组织制定和批准发布本项目的质量保证规范标准和组织措施,管理、监督和考核质量保证措施的实现
●组织监督项目质量保证工作实施,确保客户满意
●负责项目的资源管理,为质量保证工作配备符合要求的资源
●监控项目组、质量保证组的活动
●安排质量保证人员和技术保证人员对项目做相应的检查
●达到项目质量控制计划所规定的项目质量
质量保证组
●由质量保证人员及各组指派质量人员组成,对项目经理负责
●根据工程实施进度,定期提出相应的质量审计计划
●定期或不定期召集质量保证组会议,商讨工程实施中的质量问题,听取小组成员对当前质量状态的观点及质量监督工作的建议,提交会议纪要给项目管理组
●按照审计计划,组成审计组(审计组成员由质量管理组邀请用户、第三方或内部专家构成),对集成工程及其子工程进行定期或不定期的不同规格的审计,并向项目管理组提交审计报告,及时发现质量问题,及时解决
●质量保证人员领导质量保证组的工作,对工程实施过程进行全方位的监督(包括从设备到货开始的工程实施全过程,设备的保管,文档管理控制等)
●及时向项目管理组反映质量问题,向项目各组提出改进质量的建议与计划
●保证质量体系贯穿于整个项目开发实施过程中
需求预研组
●由系统分析师组成
●负责收集需求信息资料、分析整理、提交评审
●参加质量保证会议并提出项目各阶段需求质量保证建议,编制需求质量保证措施并实施
●负责项目各阶段与需求项目中不合格项的控制、检查、监督、跟踪和管理工作
项目开发组
●由系统设计人员、开发人员、配置管理员组成
●负责项目开发阶段质量保证措施具体实施,编制、完善公司开发工作规范、操作规程、作业指导书
●参加质量保证会议并提出项目各阶段开发质量保证建议,编制开发质量保证措施并实施
●协助质量保证组对项目开发范围内重大质量事故的调查,分析原因并提出处理意见
●按照公司文档规范,编写项目开发相关文档、提交评审并针对评审意见修改,按照文档相关内容监督开发,保证开发质量
项目测试组
●参加质量保证会议并提出项目各阶段测试工作质量保证建议,编制测试质量保证措施并实施
●参与需求、设计、开发评审工作,做好与开发人员沟通,保证测试方案质量
●按照公司文档规范,编写测试相关文档、提交评审并针对评审意见修改,按照文档相关内容监督测试,保证测试质量
项目实施组
●由部署人员组成
●参加质量保证会议并提出项目各阶段实施工作质量保证建议,编制项目实施质量保证措施并实施
●按照公司文档规范,编写实施相关文档、提交评审并针对评审意见修改,按照文档相关内容监督实施过程,保证实施质量
●监督控制项目工程的实施环境准备、建设,配合客户完成现场环境准备
●协助项目实施过程问题调查及解决方案提交
●参与测试评审,积极与开发人员沟通,保证实施计划质量
售后服务组
●由售后维护人员、培训讲师组成
●负责收集项目各实施阶段客户意见及满意度,定期对服务过程进行分析总结,参加质量保证会议并提出客户质量反馈意见
●按照公司文档规范,编写服务相关文档、提交评审并针对评审意见修改,按照文档相关内容监督售后服务,保证服务质量
2.2.3.2.质量保证工作规范标准
本公司的质量保证工作措施以项目实施计划为依据,以进度质量保证为重点,包括项目实施过程的质量保证措施及售后服务质量保证措施。
项目实施过程质量保证措施分三阶段对包括需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查、实施验收评审等8个方面进行质量评审及检查。
售后服务质量保证措施根据ISO9001:
2000质量管理体系制定,对服务过程进行监督和考核,关注客户满意度,定期对服务过程进行分析总结,持续改进,服务质量能够得到保证。
2.2.3.3.项目实施过程质量保证
项目实施质量保证工作贯穿整个项目生命周期,包括三个阶段:
项目概念阶段的需求质量保证工作、项目设计阶段的过程质量保证工作、项目验收阶段的验收质量保证工作。
质量保证措施贯穿整个项目流程图如下:
各阶段质量保证措施流程中,质量问题处理流程类似。
当质量保证人员发现质量问题,由技术总监主持评审工作,由项目经理分配人员解决问题,如问题处理并关闭,需要相对应的质量保证人员完成问题记录及质量报告。
下面给出三阶段质量保证措施应该进行的具体工作。
2.2.3.4.售后服务质量保证
售后服务从项目实施验收后开始直至项目合同结束,售后服务质量保证措施包括服务质量监督、质量考核内容。
1)服务申诉处理
售后服务技术支持中心处理服务反馈及申诉,并保证反馈的最及时处理。
客户满意度调查
针对服务支持情况做调查及回访。
履约保证
与客户商定在服务中的承诺履行是否达到服务标准的履约保证方式。
本司有严格的服务质量考核标准要求,包括维护支持&
现场支持。
中标后将与用户共同制定双方认可的服务质量考核标准,在考核方面将与用户方考核要求达成一致,这样更有利于质量监督控制。
服务质量监督
本司按照相关质量体系认证,对服务管理及地区分公司有严格的质量监督流程,确保服务管理达到本公司整体服务质量要求。
2)质量考核依据
客户可以将对每次服务的满意度及投诉数量作为对本公司服务水平监督的指标。
其中:
服务满意度:
是指根据客户与本司共同制定的满意度指标计量标准,由客户组织相关人员对本司服务的各部门用户进行调查、统计后形成的统计结论。
投诉数量:
是指用户直接向本公司提出的对本公司服务表示不满的次数。
本公司承诺的服务满意度:
达到服务次数的90%以上。
本公司承诺的投诉数量:
占总服务次数的5%以下。
3)质量考核内容
考核分类
考核定义
描述
响应时间
响应速度
从上报问题起到有工程师与用户联系处理问题的反馈时间
服务承诺
本公司对用户的承诺不能兑现(包括响应时间或承诺的其它时间等)
联络问题
热线电话长时间无人接听
服务运做
支持管理
由于服务项目组日常管理不善而造成客户投诉
违规操作
违反流程、规定进行的操作服务
服务态度
在服务过程中不礼貌的言行
服务技能
检测故障不准确
工程师判断故障不准确及其它因技术水平欠佳导致故障不能及时修复
沟通能力
因工程师沟通问题引起客户投诉,公司内部各部门之间因协调不畅而延误服务
4)热线质量考核
本公司具有严格的质量考评、奖惩标准,以帮助本公司对服务质量做管理。
在本公司热线和现场支持中通过质量体系中要求的各类指标完成奖罚。
而考评依据要依靠有效、严格的标准和数据采集手段。
在本公司质量控制流程中通过《维护报告》、HelpDesk记录、《客户满意度调查》等收集相关考评数据。
具体格式应与附录C中的规定相一致。
热线电话接听规范
Ø
为了超越客户满意度,达到标准,服务人员必须做到以下几点:
熟悉服务运作流程,达到客户满意的同时,提高工作效率,迅速找到解决方案,减少每个电话的占线时间,尽快应答队列中下一客户的电话。
杜绝强迫挂断客户电话。
不可将与工作无关的电话占用热线,使客户长时间不能接通。
接受保修服务后,无论是否范围内,都应态度热情,耐心听取客户问题,提供积极建议。
在调度服务商提供服务前,应问清客户故障现象、联系人、多种联系方式等,确保工程师与客户进行有效联络。
根据故障设备和数量,判断故障级别;
对在规定时间内难以达到要求的请求,根据规定做升级处理。
对新增或改变的流程规范要求,不能擅自承诺,要通知项目经理与客户协调。
工作时间内调度人员需暂时离开时,必须有1人职守热线,不可出现热线无人接听状态。
在工作中与客户出现分歧,不可以用不文明语言对待客户,应耐心向客户做解释,消减对立情绪寻求沟通。
对不可避免接触到的客户内部信息,不应随意向客户以外人员透露。
5)质量持续改进
定期的服务总结将收集服务过程形成的《维护报告》、HelpDesk记录、客户投拆、《客户满意度调查》等信息,并对这些信息进行分析处理,找出工作中可改进的地方,优化服务流程,持续提高、改进服务质量。
2.3.项目供货方案
云环境管理平台是纯软件系统,在客户的硬件设施到位的情况下,我司提供云平台软件集成安装光盘,并由我司安装部署的工程实施人员到现场进行安装供货。
提供的安装光盘至少包括:
DVD光盘:
CentOS-6.3-x86_64
ISO镜像
CentOS-6.3-x86_64-bin-DVD1.iso
CentOS-6.3-x86_64-bin-DVD2.iso
(备注:
ISO镜像用于创建本地YUM源。
)
2.4.业务应用云迁移方案
我司对于客户方已有的应用系统的云化迁移,可以提供相应的P2V迁移工具来帮助客户实现业务应用的云上迁移方案。
但因为迁移本身存在文件迁移,业务迁移,数据迁移等多种类型,因此需要结合实际情况进行casebycase地分析。
总体来说,应用只要是主流的web应用,只要与操作系统兼容,则可进行云化操作。
在业务应用云化过程中需要考虑两方面:
是否兼容、性能是否满足要求。
在迁移过程中可能会需要对现有业务应用进行部分改造,特别是应用会话的无状态化改造、外部对接系统的接口改造等。
具体的工作可由我司研发人员给出指导意见,由原业务系统厂商进行修改调整,我司现场实施人员进行系统集成和测试,通过多方协作共同完成业务系统的云化迁移。
建议迁移到云平台的业务有:
分类
考虑因素
说明
系统应用和业务系统
资源需求
业务对资源有大规模、海量的需求。
如分布式存储、分布式计算等
业务特点
业务量较少,短时间内有突发性大业务量。
如OA系统在上下班会有高峰使用情况,计费系统在月初和月末会业务量会很大。
此类系统需要利用云计算的资源池共享来实现错峰填谷。
特定需求
对IT基础设施有特定的要求,需要通过云计算来解决关键技术问题。
如IPTV热点问题,可以通过分布式存储来分散系统对磁盘的访问
硬件需求
系统和应用不依赖于特殊的外部设备或者无法虚拟化的硬件
系统资源负载变化大
系统CPU、内存、I/O利用率波动非常大,可以通过云计算的资源池共享来实现错峰填谷,本条关键点和业务访问周期性具有相同本质,但视角不同
系统资源平均利用率较低
-
业务增长快平台频繁扩容
业务量不断的增长,平台需要经常扩容,采用物理机扩容,周期会比较长,采用云计算的自动化部署,能大大提高部署效率
较低成本,提高系统可用性和可靠性
如异地容灾,对于部分已经有主备容灾的系统,如果系统没有故障,备机永远空闲。
如果迁移到云平台,则也可大大提高资源利用率
系统迁移工作量在可承受范围之内
系统从物理机迁移到虚拟化平台的工作量也是需要综合考虑的因素之一
异构平台(非跨平台产品)
异构平台迁移可以分为2种类型:
跨平台和非跨平台产品迁移。
非跨平台的可以迁移,例如Windows到Windows
2.5.项目验收方案
2.5.1.验收总体说明
云环境管理平台在安装交付给客户后,我司会进行软件功能套件整体测试,以完成隐患问题处理或缺陷处理,在确定系统达到设计要求并具备稳定运行条件后,由现场实施人员填写软件项目验收申请单,并提供齐全的验收资料。
采购人通过审核验收资料,开展必要的测试、核查工作,对软件平台的实现功能和性能,确定项目是否具备验收条件。
2.5.2.交付过程
为确保工作成果的标准化和规范化,便于本平台的运行和维护工作,正式的交付机制和交付流程是必需的。
本项目的交付将按以下交付流程进行:
本项目的交付成果包含最终交付软件及用户使用文档。
2.5.3.验收安排
本项目的具体验收方式及时间安排如下:
(1)初期验收:
云环境管理平台软件安装部署完成后1周内,内测通过后,提请客户方参与,对软件平台的功能、性能等进行初步的检查、确认;
(2)最终验收:
云环境管理平台试运行1个月后,根据江苏省公安厅科技项目管理办法要求,开展项目最终验收;
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据中心 平台 项目 实施 售后服务 方案
![提示](https://static.bdocx.com/images/bang_tan.gif)