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

蒋祎 Johnny

+ 关注

2024-02-28 15:33

2499次阅读

灵魂拷问：做数字化的甲方朋友，遇到过超出预期的乙方吗？

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

这也是为什么在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个维度：

有形设施 Tangibles，服务供应商的资质强、硬件好。对于系统实施服务，主要包括使用的软件工具，顾问的硬件设备和精神面貌等。官网做得好、办公室风景好当然也能加印象分。
可靠性Reliability，能够履约，靠谱、可信赖，言必行、行必果，能够长期提供服务，不用担心跑路、倒闭。
响应性 Responsiveness，对于服务及时性和耗时，能让客户心理有预期；能够按标准和沟通情况，及时响应客户的需求。
保障性Assurance，员工和顾问值得客户信赖，展现出足够的专业水准，包括行业知识、专业技能、沟通能力、经验和信心，让客户放心托付、推心置腹。
同理心Empathy，能够从客户的角度换位思考，理解提出需求的原因，考虑客户的利益、主动关心客户，并能够根据客户的情况提供部分个性化的服务。