在委外合同中加入体验水平协议(XLA)并不像听起来那么简单，但成功的项目往往始于小步快跑、建立基准，并在随后的过程中逐步走向成熟。
在面对XLA时，企业通常都会遇到同样的问题：我们应该衡量什么?谁拥有数据?激励机制该如何运作?以及合同签署后这会如何改变服务商的行为?
这些问题没有简单的答案，但在为客户与主要服务商的MSP(托管服务提供商)合作关系提供咨询后，我看到了哪些做法有效，哪些做法无效。成功的XLA项目很少一上来就搞宏大的转型，也不会等到万事俱备才在合同中加入体验问责制。
从正确的指标开始
我听到的第一个担忧是衡量什么，MSP往往会引导讨论去选择他们现有报表系统里已有的指标，这是一个陷阱。
与衡量运维输出的SLA不同，XLA应该关注员工体验和业务成果。最强大的项目始于三到五个高信号指标，这些指标与造成最多摩擦的员工日常旅程紧密相关。指标再多的话，项目还没取得成效就会失去焦点。
我通常建议从员工满意度得分、感知的生产力损失时间、重复事件发生率、任务完成成功率以及获取支持的难易程度开始，然后，将早期的衡量重点放在常见的员工体验上，例如服务台互动、员工入职、应用可靠性和设备性能。
试图衡量一切的想法可以理解，但这通常也是让XLA项目停滞不前最快的方式之一。
明确定义角色与职责
这是我在与客户设计XLA合同时花费时间最多的部分，也是如果企业放任不管，大型MSP最容易含糊其辞的部分。Accenture和TCS都拥有成熟的商务团队，他们精通在原则上达成一致，同时在书面协议中规避具体的问责，千万不要让这种情况发生。
员工体验不仅仅是服务商的责任，它确实是双方共同承担的，相比于纯粹由服务商承担责任，这是一种更有效的设定方式——但前提是必须明确划分职责，以下是我在实践中发现行之有效的做法：
客户职责
• 挑选工具与平台
• 管理数据基础设施
• 与服务商公开分享体验数据
• 支持服务商提出的内部改进举措
服务商职责
• 执行定期测量流程
• 交付月度体验报告
• 从数据中发现并提出改进机会
• 在约定的时间内执行运维改进
如果缺乏这种级别的具体化，XLA项目几乎无一例外会变成单纯的报告提交工作。数据被收集了，计分卡被展示了，但实际上什么改变都没有发生。
制定灵活的目标
XLA设计中最大的错误之一就是像对待传统SLA那样对待体验目标——在合同签署时设定一次，然后多年保持不变，毕竟，员工的期望、工作模式和技术环境都在不断演变。在第一年看起来雄心勃勃的目标，到了第三年可能就变得毫无意义。
最强大的XLA合同包括每三到六个月进行一次正式评估，以重新校准目标，与业务优先级保持一致，并随着体验的提升而提高期望值，这可以防止服务商锁定轻松的胜利然后躺平。当服务商抗拒评估周期时，这通常表明他们认为这些目标可以自动完成，这在任何XLA项目中都是一个危险信号。
使用正确的计分方法
一个被忽视的XLA最佳实践是体验得分的计算方式，特定时间点的得分可能会因宕机、孤立事件或低调查参与度而失真，服务商有时会利用这种波动性。
我建议客户使用滚动的两个月平均值来计算正式的XLA得分，而不是采用快照数据，这能为体验趋势提供更稳定、更准确的视角，并且让操纵运维时机的把戏更难得逞。最重要的是，在合同中明确界定计分方法，不要留到签署后在运维执行时再去解决。
精心设计激励机制
完全依赖惩罚性的激励机制是代价最昂贵的XLA错误之一，纸面上看，这个模型很简单：未达目标，接受惩罚，但在实践中，它会引发错误的行为。服务商会专注于自我保护，而不是改善员工体验;他们会优化问卷调查的时间点，管理平均值，而不是通过协作来解决问题。
我在与Infosys、HCL和TCS的合作关系中屡屡看到这种情况，最强大的XLA结构将风险与回报相结合，服务商若能超越目标、创新并改善成果，就能获得丰厚的收益。惩罚依然重要，尤其是在成熟的项目中，但它们不能是唯一的杠杆，否则合同就会变成另一个换了更好包装的SLA模型。
定义升级流程
当体验得分跌破门槛时，合同需要明确规定下一步会发生什么，这听起来显而易见，但我审查过许多客户现有的MSP合同中的服务交付衡量框架，它们规定了经济后果，却没有定义任何协作流程来解决底层问题。
我促使客户加入的升级条款明确规定：
• 当得分跌破门槛时，触发联合审查流程。
• 根因分析的预期与时间表。
• 双方指派负责人的补救计划要求。
• 纠正措施与进度报告的时间表。
定调与机制同样重要，升级应该被定位为协作解决问题，而不是归咎责任。如果合同把每一次失分都变成商业纠纷，就会在最需要服务商投入时损害双方的关系。最好的MSP会将升级视为一项共同的诊断工作，而不是合同对抗。
建立运维节奏
签署合同是开始，而不是结束。根据我的经验，从XLA项目中获益最多的企业是那些建立了严格的运维节奏并坚持执行的企业，而那些把XLA当成报告工作的企业，几乎从未见过有意义的改善。
这是我推荐的节奏：
每日：双方维护实时看板，展示体验趋势、应用性能、区域问题和特定角色洞察，以捕捉新出现的问题。
每周：客户和服务商团队举行聚焦的工作会议，确定本周有哪些提升体验的因素、有哪些损害体验的因素、完成了哪些补救措施，以及下周的优先事项是什么。
每月：正式的治理会议，审查体验得分、改进措施、根因讨论以及需要升级的跨职能问题。
每半年：领导层指导会议，评估整体体验表现，重新校准目标，并使XLA项目与不断演变的业务优先级保持一致，从而诚实地评估该项目是否真正带来了企业真正关心的成果。
企业常犯的错误
在与客户共同完成各MSP关系中的XLA设计与实施后，失败的模式是可预测的，以下是需要注意的事项。
在建立基准之前设定目标
在了解当前状态之前盲目推进目标设定，是引发纠纷最快的方式之一。先花前三到六个月的时间收集基准数据，然后基于证据而非猜测来谈判目标。
衡量过多
更多的指标并不能带来更多的洞察，包含20个数据点的框架很少能经受住运维现实的检验。从聚焦开始，逐步扩展。
隐瞒数据
透明度是XLA的基石。掩盖糟糕得分的服务商(尤其是在他们控制测量平台时)会破坏整个模型，而将数据武器化的客户也会制造同样的问题，在合同中确立共同的透明度义务。
过度依赖惩罚
仅有惩罚的结构会重蹈传统SLA行为的覆辙，平衡的激励机制能带来更好的长期成果。
将XLA视为一成不变
员工期望、技术和业务优先级都在不断演变。缺乏正式的评估周期，XLA项目很快就会变得过时。
从比你预期更小的规模开始
把XLA做好的企业很少是那些拥有最先进工具的企业，他们是那些不再等待完美项目，而是利用现有条件在合同中引入真正问责制的企业。
最有效的起点通常很简单：商定一组聚焦的体验指标，确立六个月的评估周期，承诺共享可见性和数据透明度，并为持续改进建立共同的责任制。
由此，成熟度会随着时间推移而不断提升，治理建立信任，数据变得更具可操作性，目标也随着业务优先级的变化而演进，双方的关系将从合规管理转向成果驱动的伙伴关系。
根据我的经验，成功的企业是那些不再一味接受表面亮眼的绿色计分卡，并要求获得更有意义的成果的企业。
