抱怨在不同工具之间频繁切换会引发问题是没有意义的。关键在于用数据和事例来证明这一点，以确凿无疑的证据。
翻译自 How to Tackle Tool Sprawl Before It Becomes Tool Hell 。
如今，以数字为先的公司知道他们的客户要求无缝、引人入胜的体验。但事故是不可避免的。这给已经忙于沉重工作负担的运营团队带来了压力。
寻找解决这些挑战的新方法的团队通常会在工具泛滥的形式上遇到强大的障碍。当世界处于混乱之中时，试图在不同工具之间来回切换以获取完整信息，是事件响应人员在解决事故并提供出色客户体验时最不需要的事情。但是抱怨将毫无意义。关键在于能够向高级领导呈现改变的商业理由。
数字运营团队可能在其环境中拥有一大堆互不相连的工具，用于处理事件关联、内部沟通、协作、工作流程、状态页面、客户服务案例管理、工单等等。在每个类别中，也可能存在执行类似任务的独立工具。而且它们可能是根据不同的标准构建或管理，进一步隔离了运营并减慢了速度。
事故响应是一个协作过程。这也是一个延迟几秒钟或几分钟可能对客户体验、最终对收入和声誉产生现实影响的过程。
网络团队、高级开发人员、数据库管理员、客户服务和其他利益相关者可能需要迅速汇聚在一起对事故进行筛选和处理。当必须花费大量时间和精力来在不同工具之间跳转以让每个人都在同一页并在同一地方来解决事故时，他们的能力受到损害。更不用说额外的许可成本、管理和维护工具的人员以及需要额外的安全补丁等问题了。
事件响应人员需要一个统一的平台来解决问题，但无需不断切换上下文。集成和整合工具可以减少泛滥，实现端到端的简化，以一个单一的标准集为支撑。我们正在谈论一个通用的数据模型和一个数据流 - 这使得团队能够在规模上降低成本并更快地前进。
这样的平台是存在的。然而，工程师和开发人员通常没有权力要求改变和推动采用。但这不应该阻止他们要求改变。为此，他们必须制定一个更长期的计划，旨在影响那些掌握资金的人。这是用高级管理人员能够理解的语言讲述一个故事的方法。这意味着要关注业务影响。
人类天生是受故事驱动的生物，因此高级领导者可能会对切实证明切换上下文会产生破坏性影响的实际示例做出积极回应。当与高级领导人交流时，团队应该努力用故事将问题栩栩如生。
考虑一下最近影响客户的事件。您的团队如何识别和筛选事件？在许多情况下，团队没有一个集中的地方来记录事件的上下文。这导致他们不得不在系统之间追踪信息，以了解发生了什么，以及获得开始纠正问题所需的上下文。这会为流程增加关键的时间，并在更大的事件中失去客户的信任。
一旦问题被识别出来，然后您必须将信息传达给正确的人员。这涉及到许多工具来吸引事件响应人员和专业知识专家。除此之外，团队还需要将有关事件的信息传达给业务和客户利益相关者，这再次需要在不同系统之间切换以制作和发送消息。
这其中有很多可以自动化的手工工作，但这只有从一个地方才能实现，而不是来自分散的系统。意图不是要实现单一的显示窗格，因为工具和流程会不断发展，这可能是一种愚蠢的任务，而是建立一个具备立即解决问题所需上下文的第一个显示窗格，这是一个很好的目标。
在这种情况下，不要害羞地列举团队为达到正常运行目标所不得不在之间切换的所有具体工具和系统。建立一个您必须同时处理的工具数量的图像。还要强调工具泛滥对业务的影响是非常重要的。
一个很好的起点是计算管理这些不同解决方案所需的时间增加了上一次 SEV 1 事件的解决时间。然后将该数字乘以过去 12 个月内发生的类似事件的数量，然后计算出这如何转化为团队成本。
这些是可以对高级决策者产生重大影响的计算。它关键在于展示工具泛滥对事件响应以及最终对业务的财务和时间影响。如果这个数字有冲击力，那可能足以启动与能够产生影响的人进行对话。然后，相同的能力可以应用于发生频率更高但严重性较低的问题，这可以巩固您的立场。
通过将问题生动化并展示对业务，尤其是对客户的影响，团队可以与决策者进行实际对话，帮助推动变革，并将事件响应流程汇聚到一个地方。
工具泛滥的境地已经够糟糕了。但是如果再加上大量手动流程，就会导致工作过于繁重，存在多个故障点。维护和管理多个工具需要耗费时间、笨重且昂贵。这需要不断培训员工，并在经常需要秒计时的关键工作流程中干扰。在这种情况下，一个如简化操作的云操作系统来捕获来自多个记录系统的事件上下文并自动化事件工作流程的简单方法可以极大地提高响应者的生产力。
集中在一个单一的数字运营统一平台上应该是理所当然的。但要实现这一点，团队必须与高级决策者接触。抱怨在不同工具之间切换上下文会引发问题是没有用的。
关键在于用数据和故事来提供不可辩驳的证据。这是赢得人们的心灵、思想和钱包的方式，也是走出工具泛滥境地，迈向优化运营的路径。