为什么数字化项目的甲方总对交付质量不满?

蒋祎 Johnny
+ 关注
2024-02-28 15:33
2772次阅读

灵魂拷问:做数字化的甲方朋友,遇到过超出预期的乙方吗?

至少小蒋听到的,更多的都是对交付服务质量的吐槽和抱怨:顾问水平不行、项目计划延期、交付物质量稀烂、屎山运维优化难度大……

这也是为什么在BEST选型法中会提到:既要选产品(T),更要选服务(S)。

当然,评价服务质量要比评价产品质量更复杂。纵使有关键节点的交付物,也可能有过程的服务标准,服务更多时候依然是无形的,客户对服务的评价也更多是基于主观的。

为什么客户会对服务质量不满?

80年代初,Gronroos等学者就提出了感知服务质量(Perceived Service Quality)的想法,即:

客户眼中的服务质量 = 客户感受到的服务 - 客户期望的服务

当感受低于预期,就会觉得质量差、就会对服务不满。

图片

感知到的服务与预期中的服务,差异来自哪里?

80年代末,美国市场营销专家Valarie Zeithaml, A. Parasuraman, and Leonard Berry提出了SERVQUAL服务质量,并对两者的差异来源进行解释:

图片

我针对数字化系统实施交付服务,对这个模型略做调整:

图片

图中的差异5,即是前面所说的客户感知到的服务质量。

在图中上半部分——甲方企业侧,对于数字化实施交付服务的预期来源于

  • 业务需求:企业对数字化的愿景、业务目标、对项目的规划、对功能的设想等
  • 与供应商的沟通:系统厂商、实施咨询公司给出的方案、承诺,产品的市场宣传等
  • 市场调研:了解市场上供应商的背景、了解同业标杆、真实客户的实施效果和服务口碑等
  • 过往经验:过往项目经验和服务体验(包括好的体验和不好的体验)
在此前的选型分享中,小蒋一直强调甲方企业的预期要合理,为此,甲方企业需要:
  • 在需求管理方面,搞清楚自己的业务需求及紧迫性、重要性
  • 在项目管理方面,要清楚项目范围、项目计划对于数字化成功落地的重要性
  • 在产品选型中,将场景验证做扎实,而不是未经深入交流就轻信厂商的肯定答复
  • 在供应商选择中,首先要知道完美的供应商/顾问是不存在的,好的顾问是非常稀ang缺gui的;要清楚自身当前更需要的是哪些方面的支持和建议,以及最大的阻力来源是什么?是组织变革、人力业务、功能应用、开发技术还是数据治理?或者其他。但这些问题,基本是不可能能靠单一顾问甚至单一供应商搞定。
  • 在人员投入上,要对本方的人员投入提前做好沟通和准备,最好尽早配备具备数字化落地项目经验、有乙方背景或者有与乙方合作经历的人员。

 

在图中下半部分是乙方供应商,如果由软件厂商负责实施则是指软件厂商;如果是由第三方咨询公司负责软件的实施交付,则主要是指第三方。
成熟的供应商,都会从实施项目中积累的经验中提炼出交付方法论、沉淀出交付服务标准
在供应商内部,会有管理层对这些标准的方向、内容进行决策。但决策者能全面、正确地理解客户的预期吗?假如不能,服务标准就会跑偏。这也就是差异1:认知差异
假如管理者正确理解了客户的预期,又能很好地细化成为服务质量标准规范(例如SoW、交付物模板等)吗?这就是差异2:标准差异
有了服务质量标准,每个项目的实施顾问能够按标准执行吗?这就是差异3:交付差异
有了服务质量标准,销售人员、项目经理能够充分理解标准吗?能够按实际的服务能力、交付水准来跟客户沟通、宣传吗?会过度承诺吗?这就是差异4:沟通差异
差异1-4都会导致差异5被拉大,造成客户对于交付服务的质量更为不满。
为了让客户感受到更好的服务,供应商需要
  • 沉淀经验,深入理解客户预期,制定完善、可执行、同时有一定灵活度的服务质量标准
  • 让听得到炮火的人确定服务质量标准,减少信息传达需要经过的层级,在内部梳理并分享客户预期的数据、案例等信息
  • 交付项目遵照服务质量标准来交付,保证服务水准
  • 用科技创新、流程优化、交付物标准化等手段,实现服务质量标准执行的降本增效
  • 招募、培养、保留具备较高能力、素质的服务交付人员
  • 激励交付团队提供更好的服务,加强内部沟通分享
  • 惩罚过度承诺,加强对市场、营销团队与交付团队的沟通、加强对实际产品能力和服务体验的了解。
  • 保证及时的客户沟通和畅通的客户投诉渠道
  • 在服务中,强调容易被客户忽视的投入
  • 通过营销活动增加客户可感知的价值,比如客户社群、交流活动等等。

 

那么,服务质量要如何评估呢
SERVQUAL模型认为应考虑5个维度:
  1. 有形设施 Tangibles,服务供应商的资质强、硬件好。对于系统实施服务,主要包括使用的软件工具,顾问的硬件设备和精神面貌等。官网做得好、办公室风景好当然也能加印象分。
  2. 可靠性Reliability,能够履约,靠谱、可信赖,言必行、行必果,能够长期提供服务,不用担心跑路、倒闭。
  3. 响应性 Responsiveness,对于服务及时性和耗时,能让客户心理有预期;能够按标准和沟通情况,及时响应客户的需求。
  4. 保障性Assurance,员工和顾问值得客户信赖,展现出足够的专业水准,包括行业知识、专业技能、沟通能力、经验和信心,让客户放心托付、推心置腹。
  5. 同理心Empathy,能够从客户的角度换位思考,理解提出需求的原因,考虑客户的利益、主动关心客户,并能够根据客户的情况提供部分个性化的服务。
模型还设计了一个问卷,来评估这5个维度。之后数十年,也不断有学者在SERVQUAL模型和问卷的基础上进行优化,提出更完善、适合特定服务的服务质量评估模型。
对于数字化系统实施项目,服务质量不只影响这个项目的成功和系统的上线,更会对上线后长远的运维和优化产生深远的影响。高质量的交付服务,能够帮助甲方在运维优化中:
  • 更容易理解当初的设计、回想到当时设计背后的业务需求和业务背景
  • 知道哪些设置的调整要慎重,会有什么风险、有哪些要注意的步骤和要点
  • 形成规范、严谨的需求管理、测试管理、问题管理、变更管理、知识管理、数据管理方法和习惯
  • 培养内部人员的系统专业知识和能力
  • 留下系统培训推广的基础材料
  • 提升对企业内对于数字化价值、规划思路和落地方法的认识
    图片
在交付项目过程中,供应商服务质量有哪些的具体体现?有经验、有水平的顾问会注意哪些细节?甲乙双方如何配合才能低痛、高效实现上线?
欢迎大家在留言区讨论,大家有兴趣未来可以专门再写一篇~

[免责声明]

原文标题: 为什么数字化项目的甲方总对交付质量不满?

本文由作者原创发布于36氪企服点评;未经许可,禁止转载。

0
消息通知
咨询入驻
商务合作