ITSM：IT 部门和业务部门为什么总在争论优先级，以及怎么解决

有一种会议是 IT 负责人的噩梦优先级排序会。业务部门带着一堆需求来每个人都说自己的事情最紧急。销售说 CRM 系统的新功能不上线影响季度目标财务说报表系统的 bug 不修月底对不上账运营说活动系统的性能问题不解决大促要出事HR 说招聘系统的流程不优化招人效率太低。IT 负责人坐在中间看着这四张脸知道团队只有资源处理其中两件但每一件都有充分的理由说自己最重要。最后的结果往往是谁嗓门大谁赢或者谁的上级级别高谁赢或者干脆按照提交时间先来先到。没有一种方式是真正合理的下次开会还是同样的争论。这个困境的根源不是 IT 资源不够多也不是业务部门要求太高而是缺少一套客观的、被双方认可的优先级决策框架。ITSM 体系里有这套框架但很多企业没有用起来。一、优先级争论的根本原因在深入讨论解决方案之前先把这个问题的根本原因说清楚。各部门的局部视角和组织的整体利益之间存在天然张力。每个业务部门的负责人站在自己部门的角度看到的是自己部门的问题最紧迫、影响最大。这不是他们不讲道理而是他们的职责就是最大化本部门的利益。销售负责人关心销售业绩财务负责人关心账务准确性没有人有义务在优先级争论里替其他部门考虑。但 IT 资源是全公司共享的IT 部门需要在全公司视角下分配资源而不是满足某一个部门的局部最优。这个视角的差异是优先级冲突的根本来源。没有共同认可的影响评估标准。这件事很紧急是一个主观陈述不同的人对紧急的理解不同。销售说的影响季度目标是多少金额的影响财务说的对不上账会带来什么后果这些影响如果没有量化就无法横向比较优先级排序就只能靠主观判断。IT 部门缺少说不的依据。在没有客观框架的情况下IT 负责人拒绝某个部门的高优先级请求容易被认为是偏袒或者不重视。有了客观的优先级评估框架IT 部门说你的请求重要但根据影响评估这两件事的优先级比你的高就有了依据不是主观判断是客观标准。二、ITSM 如何提供优先级决策框架ITSM 体系里有几个工具和机制可以直接解决优先级争论的问题。服务目录让 IT 服务可见、可申请、可预期。很多企业的优先级争论部分原因是 IT 部门提供哪些服务、每类服务的处理时限是多少业务部门根本不清楚。业务部门不了解 IT 的服务范围就只能靠争论来推动。服务目录解决的是这个认知问题把 IT 部门提供的所有服务用业务部门能理解的语言列出来每类服务有明确的申请方式、预计处理时间和服务级别。业务部门看到服务目录知道什么可以申请、申请了多久能得到结果预期管理就清晰了。SLA 优先级矩阵把影响量化为可比较的标准。优先级矩阵把所有 IT 请求按照两个维度来评估业务影响这件事不处理业务损失有多大和紧迫程度随着时间推移损失累积的速度有多快。两个维度的交叉给出客观的优先级影响大且紧迫的是 P1影响小且不紧迫的是 P4中间有 P2 和 P3。这个矩阵是提前和各业务部门一起定义好的什么情况对应什么优先级有明确的描述不是 IT 部门单方面的主观判断。有了这个矩阵当多个请求同时到来IT 部门可以客观地说这两件事都是 P2但这一件的业务影响评分更高所以排在前面。这个说法有矩阵支撑而不是 IT 负责人的个人判断。变更顾问委员会CAB的功能跨部门视角的优先级协调。CAB 的一个重要但经常被忽视的功能是在变更和需求之间做跨部门的优先级协调。当多个部门的高优先级请求同时到来超出 IT 部门的处理能力CAB 提供了一个正式的、有各部门代表参与的协商机制。在 CAB 里各部门负责人可以陈述自己请求的业务影响IT 部门陈述资源约束大家基于事实数据共同决定优先级。这个机制把优先级争论从各部门和 IT 部门之间的双边冲突变成了多方在同一个桌子上的协商更容易找到被各方接受的结果。三、ITSM 工具如何支撑业务和 IT 的对齐有了框架还需要工具来落实。ITSM 工具在支撑业务和 IT 对齐方面有几个关键作用。统一的工单系统让需求可见、可追踪。业务部门提交的所有 IT 请求进入统一的工单系统每个请求有记录、有状态、有预计处理时间。业务部门不需要靠追问来了解进展随时可以在系统里查到自己请求的当前状态。这个可见性解决了很多感觉被忽视的问题。很多优先级争论的背后不是业务部门真的认为自己的需求比别人更重要而是他们不知道自己的需求有没有被看到、什么时候能轮到。工单系统的透明度可以消除这种不确定感减少无谓的催促和争论。数据报表让优先级决策有据可依。ITSM 工具里的数据是优先级决策的重要依据。哪些业务系统的工单量最高、哪些系统的故障对业务影响最频繁、哪些部门的 SLA 达成率最低……这些数据可以帮助 IT 负责人在优先级会议上拿出客观的理由而不是靠感觉说话。比如IT 负责人可以用数据说过去三个月里财务系统的故障导致了总计十六个小时的业务中断单次平均损失最高所以在资源有限的情况下财务系统的稳定性改善应该排在最高优先级。这个说法有数据支撑比我觉得财务系统更重要有说服力得多。知识库减少重复需求释放 IT 资源。很多占用 IT 资源的请求其实是可以通过自助服务解决的常见问题。把这些问题的解决方案放到知识库和用户自助门户业务部门自己就能解决不需要提工单占用 IT 资源。自助服务分流了大量低价值的重复请求IT 部门的资源就可以更多地集中在真正需要专业处理的高价值请求上。优先级争论的紧张程度会随着 IT 有效资源的增加而降低。四、建立业务和 IT 的定期对话机制ITSM 工具和框架是基础但要真正解决业务和 IT 之间的对齐问题还需要建立持续的对话机制。季度 IT 服务回顾会。每个季度IT 部门召集各业务部门负责人开一次正式的 IT 服务回顾会。会议内容包括过去一季度的 IT 服务质量数据SLA 达成率、重大事件回顾、各部门工单处理情况下一季度的 IT 工作计划以及各业务部门的 IT 需求展望。这个定期会议有几个价值让业务部门定期看到 IT 服务质量的真实数据对 IT 的投入和产出有客观认知让 IT 部门提前了解业务部门的未来需求做好资源规划让优先级讨论发生在一个有数据支撑的正式场合而不是临时拍脑袋。IT 需求积压的透明管理。当 IT 资源不够处理所有需求时积压的需求清单应该是透明的。每个部门都能看到自己的请求排在哪里为什么排在这个位置前面还有哪些请求。这种透明度本身就可以减少争论业务部门看到自己的请求排在 P3前面有三个 P1 和五个 P2理解了为什么自己需要等就不会觉得被无视或被歧视。透明度是公平感的基础公平感是减少争论的前提。IT 投入和业务产出的定期对齐。每年至少一次IT 部门和业务部门共同回顾这一年的 IT 投入对业务目标的贡献有多大哪些 IT 项目达到了预期效果哪些没有下一年的 IT 投入重点和业务部门的战略目标是否对齐这个对齐过程让 IT 部门不是在真空里制定 IT 计划而是从业务需求出发让 IT 投入和业务价值直接挂钩。业务部门参与了 IT 投入的方向决策对 IT 资源的分配也会有更多的理解和认可。五、ITSM 对齐的最终目标从服务关系到伙伴关系IT 部门和业务部门之间有两种关系模式。一种是服务关系业务部门是甲方IT 部门是乙方业务提需求IT 来满足。这种关系模式天然产生优先级争论因为甲方之间会互相竞争有限的乙方资源。另一种是伙伴关系IT 部门和业务部门共同对业务目标负责IT 投入的方向由业务价值驱动IT 工作的成效用业务指标来衡量。这种关系模式下优先级争论的频率会大幅降低因为大家都在看同一个目标而不是各自捍卫各自的利益。从服务关系到伙伴关系的转变需要 ITSM 体系提供支撑统一的服务目录让服务边界清晰SLA 矩阵让优先级评估客观工单系统让进展透明数据报表让价值可量化定期对话机制让沟通常态化。这些不是一蹴而就的但每建立起一个业务和 IT 之间的关系就往伙伴方向迈进一步。ITSM 体系的核心价值不只是让 IT 部门自己运转得更好更是让 IT 和业务之间的协作变得更有效率、更少摩擦、更多信任。优先级争论只是这个协作问题的一个缩影解决了这个其他的协作摩擦也会随之减少。ManageEngineServiceDesk Plus提供了支撑 IT 和业务对齐所需的完整工具体系服务目录管理、多层级 SLA 配置、统一工单平台、跨部门数据报表、用户自助门户帮助 IT 部门在和业务部门的合作中从靠感觉说话转向用数据说话。对于正在解决 IT 和业务对齐问题的团队可以申请试用评估。