尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

ITIL 4实践选择不再难:三步定位核心落地清单

ITIL 4实践选择不再难:三步定位核心落地清单 做ITIL落地顾问这几年被问得最多的一句话就是“ITIL 4一共34个实践我们到底该上哪几个”问这个问题的从刚接触ITIL的运维主管到已经搞过一轮ISO 20000的IT总监几乎人人都有一段“看目录看得懂、做选择选不出的”经历。我并不意外因为ITIL 4本身的定位就是一本“实践菜单”不是一张“实施处方”。菜单写得越全选择就越难。但这件事真的有解而且并不需要你去读完ITIL 4那厚厚的几大本指南。我这些年帮企业做ITIL 4落地的过程中慢慢总结出了一套非常朴素、但每次都能把讨论拉回正轨的“三步走”策略先对齐业务价值再盘点现状差距最后排演进路线。这篇文章就把这套方法完整拆开把我踩过的坑、试过的工具、开过的会都一并写出来给正在从“茫然”走向“清晰”的你。1. 为什么ITIL 4实践选择让这么多人“抓瞎”1.1 ITIL 4到底给了我们什么34个实践的三层结构ITIL 4在2020年前后开始大规模推广和上一代ITIL v3最大的区别就是它把原来零散的流程体系重新归类成了34个“实践”。这里的“实践”不是过去的“流程”那么简单它把流程、人员、工具、供应商、数据全部搅在一起强调的是一整套组织能力的综合体现。这34个实践被官方分成了三类通用管理实践General Management Practices共14个比如战略管理、风险管理、组织变革管理、持续改进、供应商管理。这些不只在IT部门用得上全公司都用得上。服务管理实践Service Management Practices共17个比如事件管理、问题管理、变更使能、服务台、服务级别管理、可用性管理。这些是ITIL的“老本行”v3时代的大多数流程都迁移到了这里。技术管理实践Technical Management Practices共3个分别是部署管理、基础设施与平台管理、软件开发与管理。这三个实践把ITIL和DevOps、云原生那些话题直接打通了。很多企业刚接触ITIL 4时第一反应就是拿着这34个实践清单像围着一个自助餐厅从头走到尾什么都想夹一点。但问题就在于ITIL 4官方文档对每个实践都写得特别正规——目的、关键活动、角色、输入输出、相关实践一应俱全唯独没告诉你“该先上哪些、后上哪些、不上哪些”。这个决定权被官方刻意留给了企业自己。1.2 选择难的本质框架是“菜单”而不是“处方”为什么会这样因为ITIL 4在设计思路上继承了七大指导原则其中有一条叫“聚焦价值”还有一条叫“从你现在所在的地方开始”。这两条原则放在一起等于明说了没有放之四海而皆准的标准配置每家企业都要从自己的商业价值出发来做取舍。我常拿装修来类比。你拿到了一个非常全的建材商城目录里面有瓷砖、地板、乳胶漆、智能门锁、中央空调、地暖、新风系统。这些产品本身没有好坏之分但你不可能全装到一套100平米的房子里。装修公司给你出图纸不会把整个商场的货都塞给你他会问你住几口人、有没有小孩、做饭频率高不高、书房要不要留。ITIL 4的实践选择本质上就是同一个道理——你的“居住需求”是业务价值你的“户型”是组织现状你的“预算”是人力和预算约束。另外还有一点很关键ITIL 4反复强调四维模型也就是组织与人员、信息与技术、合作伙伴与供应商、价值流与流程。这四个维度意味着一次实践选择不是“上了一套流程文档”就完事而是要在四个维度同时动刀。很多企业一到这一步就开始打退堂鼓其实不是他们理解力不行而是没找到一套能把“选择”这个抽象问题拆成“可执行步骤”的办法。三步走策略解决的就是这个问题。2. 第一步从业务价值出发先画“价值地图”2.1 先别急着选实践先识别关键价值流我不管在哪个企业做咨询开场永远不是问“你们ITIL学到哪了”而是问一个问题“公司有哪些业务场景是一天不顺畅就会直接影响收入的”这个问题的答案就是价值流的起点。价值流在ITIL 4里是一个很核心的概念它是一系列步骤的编排通过组合不同的实践最终为客户创造价值。听起来很玄乎但实际例子特别简单。比如一家电商公司“新促销活动上线”就是一条典型价值流一家制造业企业“新品配方从研发到量产”也是一条哪怕是一个普通企业里“新员工入职开通账号”也是一条。我一般建议先挑两到三条最重要的价值流不要多画的时候甚至会简单到只用便签纸贴在墙上。具体做法是找业务方、IT运维方、开发方各一两个核心骨干花半天时间做一次工作坊把这条价值流从头到尾走一遍每一步都问三个问题谁在做用什么做做多久做完之后你会发现每个环节卡壳的地方都对应着某个ITIL实践的能力缺失。比如说促销活动上线这条价值流走到“变更审批”这一关发现要手工发邮件等三个领导签字一等就是两天。这时你自然就识别出“变更使能”实践是痛点。再比如新员工入职这条走到“服务台派单”发现系统没有自动化分类新人配一台电脑要三天那“服务请求管理”和“服务台”实践就浮上来了。所以我在第一步对客户反复强调一句话是先有价值流后有实践清单。不是倒过来先看自己缺哪个实践再编一条流程去套。方向反了后面全歪。2.2 把“客户旅程”当筛子反向找摩擦点价值流画完下一步是确认每条价值流中“客户”的体验这套方法在ITIL 4里叫客户旅程Customer Journey。这里说的客户不只是外部掏钱买东西的人也包括内部被IT服务的人群——员工、经销商、门店管理员全是客户。在实操中我常用一个很土但很有效的办法把每一条价值流的每个环节都贴一张“体验温度计”。绿色代表顺畅黄色代表等待红色代表返工或者完全没有通路。别小看这个土办法它能够非常直观地暴露出“摩擦点”在哪里。比如有一条价值流是“门店报修POS机”。客户旅程走下来你会发现门店在微信群里报障是绿色的服务台收到消息后手工登记工单是黄色的到了派工程师环节又是红色的——因为工程师只能线下看纸质排班表。这个时候你可以顺理成章地锁定一批实践服务台、事件管理、监控和事态管理甚至供应商管理因为外包工程师是第三方。客户旅程帮你做的不是“选什么”而是“排除什么”。如果一条价值流从头到尾都是绿灯那就不需要马上上对应的实践。这一步做完大概能把你纠结的实践数量砍掉一半。2.3 这一步最容易犯的错只听IT部门的需求我见过最典型的一个反例是某制造企业的IT经理一口气选了25个实践理由是“别的公司都这么建的”。我问他哪几个实践是业务方点名要的他答不上来。后来一调研业务部门最痛的根本不是IT技术问题而是IT响应太慢连一个简单的OA权限变更都拖三天。所以人家其实就要“服务请求管理”和“服务台”两块做好。你上25个实践对业务毫无感知运维团队反而累到崩溃。所以我在这一步会给客户一个非常明确的操作建议价值流工作坊必须邀请业务方参加并且让他们有“一票否决权”。业务方如果说这个环节“我们没觉得痛”那就不要在这个环节强行关联实践。这一步不是搞民主而是确保ITIL落地永远是从真实痛点上生长出来的而不是文档堆出来的。3. 第二步现状盘点用差距分析给实践排优先级3.1 现状摸底不要等平台上线再评估先给组织能力打分价值地图画完了你有了一个“该关注哪些实践”的初步名单。但这不等于可以立刻开工。你得先搞清楚这些实践在你组织里目前是什么水平这就是差距分析。很多企业一谈评估就头大总觉得要请外部机构来做一次大规模成熟度评测做半年出一本几百页的报告。我做的评估没那么复杂但能解决实际问题。核心是把每个候选实践拆成五个维度人员技能、流程规范、工具支撑、数据可用、治理机制。每个维度打1到5分1分是完全没有3分是基本可用但不稳定5分是行业领先。这个评估怎么做不需要全员调研我通常组织一个小范围座谈会包含IT运维、开发、业务对接人和一线执行人员对每个候选实践逐项打分。与其追求统计上的严谨不如先追求共识上的真实。只要会上大家能对“现状是几分”吵起来这个评估就已经成功了一大半。下面是一个我常用的评分表示例拿“事件管理”实践来做演示评估维度现状描述自评分1-5人员技能服务台能接电话但二线工程师缺少事件诊断技能2流程规范有初步的工单流程重大事件没有升级机制2工具支撑工单系统能用但没有和监控告警打通2数据可用事件记录关键词杂乱无法统计根因趋势1治理机制缺少事件复盘制度没人对SLA负责1这张表做完你不用问也知道这个企业的事件管理整体处于一个“原始但可用”的阶段要补的不是某个单点而是整套能力。反过来说如果某个实践五个维度平均分已经到4分以上它就暂时不该占用你的优先级名额。3.2 用“业务影响×实施复杂度”四象限给实践排序现状评估一出紧接着就是一个非常刺激的步骤把你候选名单里的每一个实践都放到一个“业务影响 vs 实施复杂度”的矩阵里去。横轴是实施复杂度从低到高纵轴是业务影响从低到高。四个象限对应完全不同的处理策略高影响、低复杂度这是“快赢”项目要优先做比如服务请求管理、服务台升级。高影响、高复杂度这种是“战略攻坚”项目值得投入但要充分准备比如变更使能、服务级别管理。低影响、低复杂度顺手做但优先级往后放不要占太多精力。低影响、高复杂度果断不碰属于“当前阶段应该明确放弃”的实践。我做过一个制造业客户他们当时纠结要不要立刻引入“持续改进”实践。从理论上看持续改进很重要是ITIL 4的指导原则之一。但放到矩阵上一看当时他们连事件都还没管起来持续改进的实施复杂度极高、业务影响当下根本释放不出来。于是我们把它放到了第二个波次而不是第一个波次。这就是矩阵的价值它逼着你承认“重要”和“紧急”不是一回事。排序这个动作不要一个人拍脑袋。我的做法是把候选实践写在大白板上团队所有人一起贴到矩阵的对应位置贴的过程中会有大量争论但这些争论本身就是一种共识输出。等争论结束你会得到一个非常清晰的分波排序。3.3 结合资源现实产出一份“不做清单”排序完成之后还差最后一步把“未来12个月不做的实践”白纸黑字写出来。这一步看似反直觉但特别重要。因为企业级项目最怕的不是“选得少”而是“选多了之后骑虎难下”。有了明确的不做清单团队才能把有限的人力集中到少数几个实践上做出真正可见的成果而不是每个实践都做得四不像。那么在实操里什么样的实践会被放进不做清单一般有三种情况。第一种业务影响低且复杂度高直接从清单里划掉第二种当前能力基础太差、且缺少工具支撑的实践可以先挂起等基础波次完成后再评估第三种组织文化完全不支持、需要长期潜移默化的实践比如组织变革管理不能当成一个短期项目来做反而应该跳出“选实践”的思路把它作为一种推动所有实践落地的方法论。这一步做完你的“实践清单”就从34个变成了10到15个甚至更少。这时候你心里应该已经清楚哪些是快赢、哪些是攻坚、哪些是明确不做。这就是从“茫然”走向“清晰”的关键转折点。4. 第三步形成可执行的落地计划让选择变成工程4.1 明确每个实践的范围先做“最小可用版本”很多企业落地失败不是选错了实践而是选了之后想一口吃个胖子。比如“事件管理”明明只需要先把工单流程和升级机制建立起来非要同时把所有事件的自动分类、智能派单、SLA自动化全部做完结果半年过去了什么都上线了又什么都没做好。我给客户的建议是每个实践在上线前必须定义清楚“最小可行范围”。这个词借自产品思维意思是这个实践发挥价值所必须的最小能力集合。拿事件管理举例子最小可行范围可以是一个统一的服务台入口、一套事件登记与分类规范、一条二线升级路径、一次重大事件复盘机制。就先做这四件事做好了再谈自动化。为什么要这么小因为ITIL 4实践不是纸面文章它是要被真实的人在真实的工作流里使用的。范围太大意味着改变太多人的接受度就会急剧下降。而范围小你可以在几周内看到效果团队也有正面反馈。从心理学上讲这是用小胜利换大胜利。4.2 设计12到18个月的分波演进路线分清依赖关系实践范围定完之后接下来要做的是把实践排到时间轴上。我一般推荐12到18个月的滚动路线按月为单位分成三个大的波次。第一波叫基础能力波通常是服务台、事件管理、服务请求管理、监控和事态管理。这波的目标是先把“接得住、记得下、跟得上”解决掉让业务方重新对IT建立信任感。第二波叫优化与协同波通常是问题管理、变更使能、发布管理、服务级别管理。这波的目标是从“被动救火”转向“主动管控”核心是减少重复事件和计划外变更。第三波叫价值提升波通常是持续改进、供应商管理、可用性管理、容量和性能管理。这波的目标是能主动为业务提供优化建议把IT从成本中心往价值中心转。每个波次的依赖关系要特别注意不能跳级。比如问题管理最好在事件管理稳定三个月之后再做因为问题的源头数据来自事件记录事件记录质量不行问题管理就是个空壳。再比如变更使能最好在发布管理之前做因为发布是变更的下游动作没有变更控制就谈发布控制等于盖楼不打地基。工具和资源分配上我建议每个波次最多并行推进三到四个实践。并行太多人员精力撕裂每个实践都会做成半成品。并行太少又出不了整体效果。三到四个是经过了多次实战验证的节奏。4.3 把治理和度量机制前置建立复盘节奏实践落地不是做一次培训、写一套制度就结束的。你必须从一开始就设计好如何度量这个实践的效果以及多久复盘一次。对于第一波实践每个都要定1到2个核心KPI。事件管理可以看“平均响应时间”和“重大事件数量”服务请求管理可以看“平均解决时间”和“业务满意度”变更使能可以看“变更成功率”和“计划外变更占比”。指标不要太多多了没人看看不过来等于没定。复盘节奏上我建议双周一次。组织一次“实践落地站会”看看每个实践的工具使用量、流程遵从度、指标走势以及一线反馈的痛点。别小看这个双周站会它其实就是在用ITIL 4的持续改进模型做持续优化我们期望什么现在发生了什么差距在哪下一步改进动作是什么。这个过程本身就是这个组织学习ITIL 4最好的方式。我以前有一个客户每次复盘会都开成了“批斗会”大家互相指责谁流程没走对。我的调整办法是把会议的话题从“谁出了问题”改成“什么环境导致了问题”。比如变更流程没人填单子不是执行者懒而是表单太复杂、审批人太多、操作路径太隐蔽。从这个角度看问题改进动作就变成了“简化表单、减少审批层级、优化系统入口”效率提升非常快。5. 企业落地中我亲身踩过的坑5.1 坑一想一口气吃成胖子选实践不看现状这个坑我在前面反复提过但它是所有坑里最常见的。有个零售企业客户一开始雄心勃勃选了18个实践组成三个项目组同时开工。三个月后三个项目组全都卡住了A组在给服务台提需求时发现系统不支持B组在梳理变更流程时发现业务部门根本不愿意配合C组更惨人都被借去救火烧业务了。最后我们做了一次削减从18个砍到6个才真正推进下去。所以我现在不会让任何客户在第一波次超过四个实践这不是保守这是对结果负责。5.2 坑二工具先行、实践后补流程反而拖累系统很多企业一谈ITIL落地就想到买软件这是人的惯性。但“工具先行”往往带来一个最尴尬的结果软件买了贵州的、流程还停留在原始阶段系统上线后大家发现按系统标准流程走实在太痛苦于是绕过系统用微信群协同形成了一个“线上系统线下小群”的双轨制。这个坑的根源在于工具是实践的载体而不是实践的源头。正确的顺序一定是先定义事件分类和优先级规则再在工具里配置相应的字段和流流转逻辑先明确变更审批矩阵再在系统里设置审批流先确定服务目录内容再开服务台门户。工具一定是在实践设计之后做的配置而不是反过来让工具来定义你的流程。5.3 坑三只有培训没有机制学完就忘ITIL 4落地总要配培训这没错。但很多企业把培训当成终极目标人考完ITIL 4 Foundation证书就算完成回去之后该怎么干还怎么干。我后来总结出一个规律每一次培训后面必须在两周内安排一次“用新方法做真实工作”的实践任务。比如培训完事件管理立刻让服务台按新的事件优先级矩阵对过去一个月的工单做一次复盘分类培训完变更使能立刻挑一个真实变更走一遍新的审批流程。不用这个办法你花在培训上的钱基本等于打水漂。培训只是知识输入机制才是行为改变。5.4 坑四把ITIL 4做成了纯粹的文档运动最后一个坑特别隐蔽很多团队辛辛苦苦写了厚厚的流程制度发布的时候贼有成就感但业务部门压根不看。什么原因因为文档和实际工作方式是割裂的。比如一个事件从报障到解决的路径系统里点几个按钮、填哪几个字段这才是员工真正使用的“流程”而写成的那种几十页的Word文档只是给审查员看的。我的建议是流程制度尽量以“步骤清单系统操作指引”的形式内嵌到工具里。让员工打开工单系统界面上该填什么一目了然审批流自动走到该批的人那里去状态变化自动触发通知。只有当流程长在工具上它才真正运转起来。那些厚厚的文档只保留一份“总纲”性质的东西就够了细节全部数字化。这一点对这代ITIL落地尤其重要因为ITIL 4本身强调的就是“信息与技术”维度没有工具支撑的实践很难算真正落地。6. 最后再分享一个我实际用惯了的组合技巧按惯例最后分享一个我这几年来用得最顺手的组合方法把“价值流工作坊”“差距评分表”“四象限优先矩阵”这三样工具常年放在一起使用。价值流工作坊负责让你找对方向差距评分表负责让你看清自己四象限矩阵负责让你砍掉虚火。不管企业规模多大、行业多不一样这三样东西组合在一起几乎都能在两周内产出一份让管理层和IT团队都认可的实践选择结论。具体到会议安排上我习惯第一天上午安排客户高管访谈快速识别两到三条最关键的价值流下午直接召集相关方做价值流工作坊当天画出客户旅程第二到第三天做实践现状评分把候选实践过一遍第四天上午开会贴四象限下午做分波路线。不要小看这个节奏它把看似庞大的ITIL 4决策压缩进一个可以重复执行的工作流且每一步都有可视化的输出物比任何大而全的咨询方案都更有说服力。最后说一句掏心窝的话我做了这么久ITIL落地最大的体会是实践选择这件事本身没有标准答案但它的过程一定有迹可循。只要你始终围绕业务价值做判断用现状数据讲道理别贪多求全你的ITIL 4落地就一定能从“看目录看得懂、选实践选不出”的阶段走到“知道为什么上、也知道为什么不上”的清晰状态。这才是比任何实践清单都更有价值的资产。
返回列表