Red Hat 的全球支持服务 (GSS) 组织负责客户忠诚度。在这个职位上，我们致力于解决客户遇到的复杂技术问题。在 2009 年 2 月，GSS 管理团队开始了一段旅程，以确定我们是否可以通过提高我们训练有素的技术支持专员彼此协作的能力来更好地服务我们的客户，并最终提高客户忠诚度。其基本思想是，如果我们能够消除分隔不同专员群体之间的某些结构性、文化性和程序性障碍，我们就可以增加知识的流动，减少重复工作，并最终为客户提供更准确、更一致和更快速的结果。
踏上这段旅程最终教会了我们意想不到的经验教训——不仅是如何管理专员日常工作的协作，还包括如何使用开放协作作为管理团队在组织中创新流程设计。
决定增加协作是一回事，但实际启用增加的协作，然后鼓励专员使用它是绝非易事。虽然我们的专员一直以来都在小组内自由协作（例如，坐在附近的人或从事类似技术的人），但我们的愿景是利用我们组织的集体知识，在全球范围内促进协作。这意味着将来自三个不同职能角色、分布在十几个国家、使用八种语言和掌握数十个领域知识的人员联系起来。
事实证明，弄清楚如何设计一个可以容纳这一雄心勃勃的目标的工作流程非常困难。我们组建了一个项目团队，并进行了多次迭代，但感觉我们没有足够可靠的东西来完全实施。我们从几个试点小组的小规模协作开始，但发现后勤以及基本的态度问题阻碍了我们设想的开放协作。虽然我们已经成功地阐明了我们努力的目标，但我们在解决方案方面没有取得进展。
然后，在经历了几个月的虚假开始之后，我们终于取得了突破。如果我们解散主要由来自组织不同领域的经理组成的项目团队，而是请专员们自己聚在一起，找出实现目标的最佳方法，会怎么样？
现有的项目团队变成了我们所说的“核心团队”。该团队仅由经理组成，他们的角色将从实际设计解决方案转变为更像是项目的顾问委员会。然后，我们为一个新的团队征集志愿者，我们称之为“设计团队”。该团队由大约 15 名技术专员组成：来自每个地区、每个团队和每个技能水平的代表。这些专员都对项目充满热情和活力——但这并不意味着他们都认为这是一个好主意或同意如何实施它。
我的角色是使用设计思维技巧来促进设计团队会议，确保对话保持富有成效和步入正轨，并确保所有声音都被听到。
设计过程并非易事。我们在清晨和深夜之间轮流安排会议，以适应不同的时区。一些专员在凌晨 5:00、凌晨 2:00、晚上 11:00 或其他奇怪的时间加入我们的电话会议。情绪激动；一些讨论质疑某些角色的有效性，并为重大变革敞开了可能性之门。人们担心失去他们的相关性，牺牲他们作为特定主题专家的独有地位，不得不承担比以前更多的工作，不得不花费更多时间与团队成员讨论问题，而不是自己完成工作。技术领域许多人的隐含理解是知识就是力量。增加协作和知识共享是否意味着你放弃了这种力量？
打破孤岛并改进协作将是一项重大的文化变革，需要全面的变革管理工作，可能需要数年才能完全实现。远远超出最初愿景的范围，我们在接下来的十二个月中设计和修订了将成为新工作流程的内容，基于我所说的“智能集群”，适用于我们在全球范围内的所有技术专员。在此过程中，设计团队解决了数十个问题、艰难的对话、激烈的辩论和分歧。
当我们倒计时启动新流程的日子时，新流程还涉及一套新工具，管理层开始为最坏的情况做好准备。确定了风险和缓解策略，起草了应急计划，制定了昼夜不停的管理监控计划。肯定有漏洞，并且有很多小故障和粗糙的地方。但总而言之，变革最终进行得非常顺利。
最终，我们提出了一个概念，该概念通过允许来自不同办公室、不同技能水平和不同职能部门的专员“集群”围绕客户案例进行协作，最终让合适的人员更快地处理合适的案例并更快地解决客户问题。与此同时，以前不协作的专员正在共享知识并互相学习。
早期结果表明，以知识为中心的支持（一种将知识创建和重用纳入解决客户问题的工作流程的方法）和我们的新智能集群模型使我们能够在不增加员工的情况下处理更大的呼叫量。这些效率提升是积极投资回报率的早期指标，并且是授权我们的专员在设计自己的流程和程序中发挥主导作用的直接结果。
我们的新协作工作流程远非完美。仍然存在棘手的问题、我们遇到的问题以及我们认识到需要进行的改进。在接下来的几个月中，我们将专注于衡量我们新的智能集群模型的有效性并提高其效率。为此，我们将继续借鉴我们在开发该计划中吸取的教训：抵制自上而下应用变更或改进的诱惑，让做工作的人员透明地设计和改进流程。
10 条评论