IT关系的条款通常是由供应商决定的，但我们的IT系统对我们的业务至关重要。现在是革新这种关系的时候了--《客户宣言》告诉你如何...
我们已经给了我们的技术供应商对我们组织的权力。看看当一个关键任务系统出现故障时会发生什么--企业会有心脏病发作。ERP系统崩溃了--我们的生产线停止了。计费系统故障--我们无法向客户收费。数据库崩溃--我们甚至不知道我们的客户是谁。
这种权力的不平衡存在于整个供应商/客户关系中。我们在项目中看到它，因为我们在等待供应商告诉我们新系统何时可以上线。在人员方面，我们在招聘技术人员时看重他们的技能，而不是他们是否适合我们的业务。在金钱方面，我们被锁定在会让守财奴羡慕不已的价格安排上。
我们正在成为供应商的受害者。随着我们对IT的依赖越来越多，情况会越来越糟--除非我们对此有所行动。
我们能做什么？首先要认识到，大多数IT供应商的关系只是在销售之后才建立起来--当供应商支持他们所销售的系统时。然而，谁来制定支持关系的条款？很多时候，是供应商。
我们在这里谈论的不是服务水平协议或合同--尽管这些东西很关键。这里的关键词是关系。这是关于设定行为的期望值，并且不接受任何不足。这是关于期望我们的供应商是专业的 - 但向他们解释这意味着什么。
七条规则支配着有效的关键任务支持关系。我们通过密切观察客户和供应商双方的支持关系来确定这些规则。客户之所以升级，是因为供应商违反了这些规则中的一条或多条。
任何关键任务的客户都应该合理地期望他们的技术供应商能够。
- 支持客户
- 持续交付
- 引导客户
- 准确地排除故障
- 要快
- 证明这一点
- 抢占先机
这七条规则共同构成了一个客户宣言--客户控制关系和恢复权力平衡的蓝图。怎么做？
1.支持客户。
在关键任务的世界里，供应商支持你的业务，而不仅仅是你的系统。当一个系统发生故障时，你需要供应商做任何需要的事情--不仅仅是让你的系统恢复，而是帮助你的业务恢复和运行。
例如，一家分销公司的仓库服务器断断续续地崩溃。每次崩溃都使该公司损失了数万英镑的业务。他们的硬件供应商证明，问题既不是硬件也不是应用程序。尽管如此，供应商继续支持客户解决这个问题--并帮助证明问题的真正原因：破坏。
让供应商支持你的业务。向你的供应商提出好问题。
- 在支持一个事件时，他们会在什么时候拔掉插头？(这可以接受吗？)
- 如果一个事件跨越了几个技术，他们是否会为你管理事件，无论哪个供应商最终负责？
- 他们能否与你一起练习/演练管理重大事件--并因此而改变他们的流程？
这可能是他们的系统，但这是你的业务。提醒他们。
2.2.持续交付。
如果我得了心脏病，我的存活率不应该取决于我是否由史密斯医生而不是琼斯医生治疗。我期望每一位医生都能始终如一地为我提供良好的治疗。当我们的组织发生心脏病时，我们是否应该对我们的供应商有更高的期望？特别是，他们有什么具体的、明确的和有效的程序来使我们的业务恢复和运作，不管是谁在处理它？
例如，一家系统供应商，每当一个关键任务的客户发生故障时，就会建立一个 "作战室"。房间里的每个人都有一个特定的角色，他们在这些角色中系统地工作，诊断问题并恢复服务。无论谁担任什么角色，作战室的工作方式都是一样的--通过数字。
提高标准。问吧。
- 你的供应商对事件管理有什么标准？
- 他们知道你期望他们达到的标准吗？
- 他们有什么程序可以确保他们的支持成功不只是取决于一两个人？
这是你的生意。你应该制定标准。
3.引导客户。
在电视上，当警察想在审讯中提高嫌疑人的焦虑水平时，他们会问一个问题，得到一个答案，什么也不说，然后离开房间。随着沉默的加深，嫌疑人会担心很多事情，但主要是 "还有什么？接下来是什么？"当警察回来时，嫌疑人因担心而爬墙，不顾一切地想要坦白。
令人惊讶的是，许多供应商采取了类似的 "提问/沉默 "的做法。他们问了一些关于严重崩溃的问题，然后就下线去 "处理问题"。你不知道他们为什么要问他们做了什么，他们对答案做了什么，或者他们接下来会做什么。难怪你会升级!
然而，有些供应商却能很好地指导他们的客户。一个软件供应商使用一个一致的故障排除过程来构造对关键任务崩溃的诊断，他们与客户分享。这意味着在每次与客户接触时，他们都会解释他们需要什么信息，为什么需要这些信息，他们将用这些信息做什么，以及他们下一步要去哪里。
减少焦虑。改进你的供应商在重大事件中指导你的方式。询问他们。
- 他们的人在诊断问题时接受了哪些问题的培训？
- 在事件中，他们的人将如何解释他们需要什么信息，为什么需要这些信息，他们将用这些信息做什么，以及他们接下来将做什么？
- 他们的诊断路线图是什么--他们能分享吗？
你希望他们诊断的每一步都是透明的。没有惊喜。
4.准确地排除故障。
许多关键任务的问题被升级是因为供应商的知识用完了。他们可能以前从未见过像我们这样的问题，或者问题可能异常复杂。通常情况下，供应商会对这些问题进行一系列的修复，希望能有一个能坚持下去。大多数修复方法都失败了。更糟糕的是，他们可能会造成比原来的问题更多的麻烦。
始终如一地解决关键任务的问题是可能的。一家金融服务公司有一个系统，在日终对账期间间歇性崩溃。崩溃迫使他们每晚雇用数百名临时工手工完成工作，以便第二天能够合法交易。这是一项重大的工作，他们不希望重复。这个问题很复杂，所以供应商使用了一个诊断协议，并与他们的客户分享。该协议指导他们尽量减少不必要的系统变化，他们有效地解决了这个问题。
引导客户。帮助你的供应商解决这个问题。询问他们。
- 他们如何防止自己的员工采用散兵游勇的方式--发射一个又一个失败的修复方案？
- 每当有重大事件发生时，他们需要你提供哪些标准信息？
- 当他们捕捉到问题信息时，他们能否立即以结构化的形式与你分享？(这可能会让你纠正错误的信息，提高快速成功的机会）。
每个事件都是用类似的问题以一致的方式进行管理吗？没有吗？那么他们还有一段路要走。
5.要快。
应急服务部门争分夺秒地拯救生命--但他们不能出错。这两种相互冲突的压力意味着他们在大多数常见的情况下使用一致的程序，并严格遵守这些程序。时间太紧，赌注太大，无法随机应变。遵循他们的流程是完成工作的最快方式。
我们需要我们的供应商有同样的纪律。当问题很关键时，我们不能让他们出错。
例如，有一家硬件供应商要求将超过两小时的关键客户问题上报给他们最资深的工程师。为了帮助这些工程师快速处理问题，并尽量减少他们花在旧问题上的时间，该公司坚持要求向他们传递一套标准的问题信息。这一步骤将他们解决客户问题的时间平均提高了52%。
让你的供应商进入快车道。问他们。
- 当你通知他们发生重大事件时，哪些自动程序会启动？(想想消防队或一级方程式赛车的工作人员。)
- 他们多长时间练习一次这些？
- 他们多长时间审查一次这些流程以使其更快？
- 你能帮助他们更快地解决你的问题的最好方法是什么？
追踪关键任务事件的平均持续时间。如果没有下降，那么他们就没有回答这些问题。
6.证明一下吧。
在此向奥斯卡-王尔德表示歉意，"崩溃一次可能是不幸，崩溃两次是粗心"。如果我们的业务受到了损害，那么我们应该期望我们的供应商证明为什么会发生这种情况--以及为什么它不会再次发生。许多供应商一旦解决了眼前的问题，就把脚从油门上挪开。
然而，有些供应商做得很好。在任何重大事件发生后，一家系统供应商都会给客户一份标准的分析报告，其中不仅描述了根本原因是什么，还描述了如何证明它，以及他们正在做什么以确保它不会再次发生。
让你的供应商承担举证责任。问他们。
- 他们怎么知道自己已经找到了根本原因？
- 他们对所谓的根本原因做了哪些假设？
- 他们还考虑了哪些可能的原因？
追踪你的问题中随着时间的推移反复出现的数量。如果这个数字没有下降，那么这些根本原因就不是根本原因。
7.抢占先机。
许多问题是可以预防的：也许我们需要做一些不同的事情；也许我们可以从别人的问题中学习。我们需要我们的供应商帮助我们避免问题，甚至可能比我们需要他们的帮助来解决这些问题更重要。因此，很遗憾的是，供应商支持组织往往很少提供主动的帮助。
也有一些例外情况。例如，一家服务器公司建立了一支技术专家队伍，他们唯一的工作就是帮助防止客户出现问题。他们的客户有更少的问题，他们得到更少的升级。
预防胜于治疗。问问他们。
- 他们的支持工作中有多大比例是用于预防问题，而不是对事件作出反应？(这个比例你能接受吗？）
- 当他们提出改变时，他们建议如何防止这些改变可能引起的问题？
- 当他们修复他们的问题时，他们怎么知道这是唯一需要修复的系统？
供应商的支持是出了名的被动反应。他们需要提前思考。不要害怕帮助他们这样做。
客户支持的七条规则并不能解决所有支持方面的问题，也不容易实现。但是，如果我们不与供应商合作以改善他们的表现，那么我们就必须接受事情的现状，包括停机时间、业务影响和所有问题。
许多供应商在这些原则中的某些方面做得很好。然而，很少有人能在所有七个方面都取得成功。这还不够好。我们已经把我们企业的生命托付给我们的技术供应商。我们已经接受了他们的支持规则。现在不行了。我们的企业太重要了，不能再这样了。现在是改变规则的时候了。