为什么数字化项目的甲方总对交付质量不满?
灵魂拷问:做数字化的甲方朋友,遇到过超出预期的乙方吗?
至少小蒋听到的,更多的都是对交付服务质量的吐槽和抱怨:顾问水平不行、项目计划延期、交付物质量稀烂、屎山运维优化难度大……
这也是为什么在BEST选型法中会提到:既要选产品(T),更要选服务(S)。
当然,评价服务质量要比评价产品质量更复杂。纵使有关键节点的交付物,也可能有过程的服务标准,服务更多时候依然是无形的,客户对服务的评价也更多是基于主观的。
为什么客户会对服务质量不满?
80年代初,Gronroos等学者就提出了感知服务质量(Perceived Service Quality)的想法,即:
客户眼中的服务质量 = 客户感受到的服务 - 客户期望的服务
当感受低于预期,就会觉得质量差、就会对服务不满。
感知到的服务与预期中的服务,差异来自哪里?
80年代末,美国市场营销专家Valarie Zeithaml, A. Parasuraman, and Leonard Berry提出了SERVQUAL服务质量,并对两者的差异来源进行解释:
我针对数字化系统实施交付服务,对这个模型略做调整:
图中的差异5,即是前面所说的客户感知到的服务质量。
在图中上半部分——甲方企业侧,对于数字化实施交付服务的预期来源于:
-
业务需求:企业对数字化的愿景、业务目标、对项目的规划、对功能的设想等 -
与供应商的沟通:系统厂商、实施咨询公司给出的方案、承诺,产品的市场宣传等 -
市场调研:了解市场上供应商的背景、了解同业标杆、真实客户的实施效果和服务口碑等 -
过往经验:过往项目经验和服务体验(包括好的体验和不好的体验)
-
在需求管理方面,搞清楚自己的业务需求及紧迫性、重要性 -
在项目管理方面,要清楚项目范围、项目计划对于数字化成功落地的重要性 -
在产品选型中,将场景验证做扎实,而不是未经深入交流就轻信厂商的肯定答复 -
在供应商选择中,首先要知道完美的供应商/顾问是不存在的,好的顾问是非常稀ang缺gui的;要清楚自身当前更需要的是哪些方面的支持和建议,以及最大的阻力来源是什么?是组织变革、人力业务、功能应用、开发技术还是数据治理?或者其他。但这些问题,基本是不可能能靠单一顾问甚至单一供应商搞定。 -
在人员投入上,要对本方的人员投入提前做好沟通和准备,最好尽早配备具备数字化落地项目经验、有乙方背景或者有与乙方合作经历的人员。
-
沉淀经验,深入理解客户预期,制定完善、可执行、同时有一定灵活度的服务质量标准 -
让听得到炮火的人确定服务质量标准,减少信息传达需要经过的层级,在内部梳理并分享客户预期的数据、案例等信息 -
交付项目遵照服务质量标准来交付,保证服务水准 -
用科技创新、流程优化、交付物标准化等手段,实现服务质量标准执行的降本增效 -
招募、培养、保留具备较高能力、素质的服务交付人员 -
激励交付团队提供更好的服务,加强内部沟通分享 -
惩罚过度承诺,加强对市场、营销团队与交付团队的沟通、加强对实际产品能力和服务体验的了解。 -
保证及时的客户沟通和畅通的客户投诉渠道 -
在服务中,强调容易被客户忽视的投入 -
通过营销活动增加客户可感知的价值,比如客户社群、交流活动等等。
-
有形设施 Tangibles,服务供应商的资质强、硬件好。对于系统实施服务,主要包括使用的软件工具,顾问的硬件设备和精神面貌等。官网做得好、办公室风景好当然也能加印象分。 -
可靠性Reliability,能够履约,靠谱、可信赖,言必行、行必果,能够长期提供服务,不用担心跑路、倒闭。 -
响应性 Responsiveness,对于服务及时性和耗时,能让客户心理有预期;能够按标准和沟通情况,及时响应客户的需求。 -
保障性Assurance,员工和顾问值得客户信赖,展现出足够的专业水准,包括行业知识、专业技能、沟通能力、经验和信心,让客户放心托付、推心置腹。 -
同理心Empathy,能够从客户的角度换位思考,理解提出需求的原因,考虑客户的利益、主动关心客户,并能够根据客户的情况提供部分个性化的服务。
-
更容易理解当初的设计、回想到当时设计背后的业务需求和业务背景 -
知道哪些设置的调整要慎重,会有什么风险、有哪些要注意的步骤和要点 -
形成规范、严谨的需求管理、测试管理、问题管理、变更管理、知识管理、数据管理方法和习惯 -
培养内部人员的系统专业知识和能力 -
留下系统培训推广的基础材料 -
提升对企业内对于数字化价值、规划思路和落地方法的认识