[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

[p=30,2,center]

首先祝贺本次企业数据中心顺利搬迁到东莞，大家不要认为这只是一次简单的搬迁，而是一次升级换代，将在公司未来发展中发挥重要作用。

过去几年，质量与流程IT支撑了公司业务的高速发展，取得了一些成绩，比如：建成了覆盖全球业务的网络，构建了8个100ms业务圈，建立了IT服务质量承诺，接受业务监督；通过“三朵云”部署，面向客户首次实现体验式营销；结束区域站点存货无法盘点历史，中心仓存货的帐实准确率99.89%，站点存货的帐实一致率98.17%；业务对流程IT的满意度达到87.22分历史最好，IT需求端到端交付周期也下降了3倍……

长河点评：
IT的价值在于促进和引领业务的发展，所以我们要建立端到端的IT服务绩效考核指标。IT管理要转向到IT服务对业务的服务上来，企业的信息中心首先是一个IT服务中心，需要敢于负责任地公开我们的服务承诺。IT服务的指标，最终要落实到对业务的促进和引领的绩效上，要尽量使用IT手段推进业务变革。IT发展到如今，IT部门再向业务部门宣扬我们的服务器性能提高了多少，我们实施了多少技术改造项目等，这种“自娱自乐”已经非常不够了。我们要勇于主动挑重担，参与到业务革新项目中去，让业务绩效来证明IT的价值。

虽然还有不满意，华为还是从“农民”公司走到现在的IT能对全球业务的支持，而且现在部分领域已经支持单兵作战，是我们很大的进步，一定要肯定。

金融危机可能即将到来，我们强调，一定要降低超长期库存和超长期欠款。以前我们的货款记录不清晰，客户来还欠款时，我们还莫名其妙，连合同和欠条都找不到了，如果客户不还钱，多少预备金都付诸东流。现在我们已经结束区域站点存货无法盘点的历史，货款记录开始清晰，进步很大。

你们还做出了很多成绩，我就不一一陈述。你们自己去评奖，想表彰多少人都行，奖牌可以从道德遵从委员会领取。今天我们主要谈谈下一步工作的要求和期望。

一、变革和IT也要聚焦，减少变革项目数量，IT不能遍地开花。每增加一段流程，要减少两段流程；每增加一个评审点，要减少两个评审点。
面向一线，要做好跨功能、跨部门的流程集成和IT集成，改变每个变革项目有自己专用IT系统的状况。从需求管理与结果评估入手来加强IT应用开发的有效性。对于生产IT，业务部门要承担决策责任，投入使用后，没有使用量的要建立问责机制并问责。对于办公IT，流程IT部要承担责任，并基于使用量来评价。我们要学习川普，每新增加一个流程节点，必须关闭另两个流程节点。流程必须持续简化，IT应用及文档文件要有日落法。

长河点评：

IT服务和ITSM流程的不同发展阶段会面临不同的问题，我们不可能在一个时间点将流程生命周期各个阶段的问题一次性全部解决，正如苏格拉底说，人不可能两次踏进同一条河流，同一个流程每个发展阶段会面临该阶段的特定问题，所以我们要阶段性地聚焦一些当前最主要的问题进行解决，而上升到下一阶段将会出现新的主要问题，再着手解决。IT服务人员的精力是有限的，非核心的问题可以先放一放，或者由解决核心问题来带动解决非核心问题。

一个企业各个部门可能都会建立BPM之类的流程改造项目，但是不应该缺少统一、协调、宏观的规划，之所以不少部门之间的协调工作水平差，可能不是流程建立的少了，而是多了，因为很可能同一件事各个部门都建立了画地为牢的断头流程，从大局来看，多个部门本应该统一建立一个流程即可。如：多个部门都有档案管理方面的流程规范，站在公司视角，就可以合并成一个，并指定由一个部门统一管理。流程是一个创造价值的网络，只有拉通各个部门的信息，才能真正创造新价值，而断头流程则完全无法做到价值的最大化。

流程的优化可以用雕塑来做比喻。我们可以塑造上新的流程活动，也可以雕去不必要的活动。一个流程在特定的阶段可能会定义特定的流程活动如某个特定的流程控制节点来保证流程的执行效果，但是如果流程的成熟度发展到新的阶段，此前定义的流程控制节点未必需要再保留。流程持续简化提高了流程的生产效率，但对流程的成熟度包括运行质量的控制上提出了更高的要求，对流程执行的岗位和个人也提出了更高的要求。一般来说，为了控制流程执行中出现的各类问题，我们往往首先想到的是增加某些节点来增强协调和控制力，这种打补丁的办法使得流程冗长拖沓，降低了执行效率。流程应该使用日落法设定定期的回顾和优化期限，使流程在发展过程中得到及时的调整，更好地促进业务发展。回顾中也可以将不必要的流程取消掉。

另外，我们还要防止新流程在设计和实施后，一些旧流程和配合这些旧流程的操作规程SOP和WI变成不明不白的搁置状态，人们不知道是否需要执行或是如何调整执行，这个问题在新流程上线前必须全部识别出来并妥善处理。

第一，不产粮食的流程是多余流程，多余流程创造出来的复杂性，要逐步简化。

回顾过去五年的变革，看看到底哪些流程使用量大。没有使用量或者使用量很少的流程，能否先把带宽供给压缩一半，支持流程的人员也减少一半；再过三个月，如果没有投诉，把带宽再压缩一半；如果还没有投诉，就只留下一名人员支持。不想升职升薪的人可以守在那里，希望进步、升职升薪的人都聚焦去消除流程断点。

流程是为作战服务，是为多产粮食服务。使用量少的流程是不是多余流程？当带宽不断减少时，可能会有人投诉，你们就去访谈，看看这个需求有无可能合并在其他流程中。当然，不能简单直接减掉一个流程，因为可能会产生断裂带，引发矛盾冲突，就不会成功。
不可持续的就不能永恒，繁琐的管理哲学要简化。有人说，已经走了很多复杂化道路。不经过复杂，也简化不了，如果一开始就能做出简化方案，那你是神仙。

长河点评：

流程是一种服务，它也要像其他服务一样需要了解服务的效果和价值产出情况。我们需要一个规范来调研流程的使用情况和成熟度情况，了解流程有哪些问题，如果某些流程已经随着业务的转变而无人问津，需要及时进行注销，否则将会持续占用资源。例如新OA系统上线后，老式的纸面审批流程就应该废除，当先进的APP、微信通知手段实施后，老式的电话或当面交流确认手段就应该废除。

流程的发展必定会经过一个曲折的过程，没有人能先知先觉地预先知晓流程执行过程中的所有问题，所以在一开始设计流程时我们往往会采用比较周全的办法来进行流程的管控，但在执行一段时间后我们将会了解其实只有其中一部分管控措施是必要的，这时我们就需要对流程做减法。这个是流程逐步完善的必由之路，不经过复杂的步骤和一段时间的试行观察，其实你就不知道到底应该简化哪里，除非你真的是神仙。流程的优化有很多方法，例如串行节点改并行，人工手段改为自动化处理等，当然，流程的优化也包括KPI的优化。KPI的优化有一个循序渐进的发展规律，例如，你要让员工走一个新的审批流程，我们可以先考核他有没有做，然后考核他有没有遵照规范做，再考核他做的对不对，最后考虑他做的快不快。你不能一开始就要求他做的又快又好，因为这样将会打击一大片，你也就无法将那些想做但是不会做的人与根本就不想做的区别开来做不同的处理，这样激化了矛盾，根本不利于流程的推行。

关于流程的成熟度评估，Cobit里面引用了一个国际标准ISO15504，提供了一套流程评估和改进的方法论，大家可以去学学。

第二，集中精力消除流程断点，打通信息流。

目前公司的架构流程乱、数据断点多。甚至有些业务流程，操作人员要跳过四、五段流程，才能达到最后目的。举一个例子，以前深圳有很多断头路，之所以堵车这么厉害，因为没有微循环，后来交通改革打通了断头路，让一些车辆不用绕到主干道上，交通就比原来通畅一些。

现在我们公司的流程也比以前好了一些，但还要精简无效流程，将减下来的人员集中精力去打通“断头路”。重点打通合同信息流，目前合同中的配置数据、价格数据依然存在断点。

长河点评：

职能本位思想导致部门画地为牢，流程在部门内运转流畅，一到外部就成了难关。以IT服务管理流程为例，我们经常说ITIL的流程落地一定是需要站在公司层面来规划，要得到公司一把手的支持，只有这样才能真正将ITIL流程在全公司贯穿落地。如服务热线的推广、信息安全管理流程和服务级别管理流程等的落地实施。

再举个例子，HR在雇佣了一个新员工后，会马上要求IT部门为员工开通各类账号和权限，但这个员工转岗或离职时，HR可能并不会及时告知IT部门来及时关停或调整这些权限。这还是职能本位思想在作怪，因为HR自己没有直接的信息安全管理的责任，他们不关心安全权限的回收问题。我们一定要尽快识别并打通这些断头路。

第三，IT应用开发投入使用后，没有使用量的要建立问责机制并问责。

对于五年内的无效流程清理，能否敢于实行问责制？谁提议开发这个流程，能否追溯他的责任？如果他提议开发，一直在使用这个流程，可以赦一半罪；如果他自己也不使用，能否狠狠处分两个人？有人在命令高级干部看无效视频，以撑大流量，这种人就是拍马屁的，一律免职。

我们不能满足客户需求多元化，每个人都会有需求也无法都满足。如果把所有个性需求上升到很重要的地步，那公司会乱成一团麻。

二、主业务流程和能力解耦，能力模块化、微服务化是方向。

第一，流程和能力解耦，IT部门最重要的职责是把“高速公路”修好，打通到前线、到战壕。

能力要和流程解耦，包括财务能力的优化。从单纯自建IT基础设施到自建与使用公有云服务相结合，把应用分类，涉及核心信息的应用部署在自建私有云上，不涉及核心信息的应用大胆使用公有云服务，以此来提升资源使用效率，减少运营、运维人员。有部分领域已经在支持单兵作战，这点非常好，我们要巩固。

IT部门最重要的职责是把“高速公路”修好，至于路上跑的是“轿车”、“卡车”、“牛车”……跟IT部门无关。如果流程和能力纠结在一起，“路”不通，能力也就不能用。

长河点评：

大家是否还记得ITIL教材中有一个流程原理图，上面是流程的控制部分，中间是流程的执行部分，下面是流程的使能部分，这个使能部分就是能力和资源，ITIL的九大战略资产中提到了5个能力：管理体系、组织、流程、知识、人才。我们可以举一个例子，如果一个8个人的IT部门没有固定的IT服务流程，但IT主管的个人能力很强，他每天都能看住另外7个人的工作，这时他个人能力强，但流程能力差。另一种情况是一个能力一般的IT主管，通过一个不错的、稳定运行的IT服务流程也可以管好工作。流程的好处之一就是能让一个能力平庸的执行者也能保证做出达到质量要求的结果。

另一方面，能力的不足例如技术力量薄弱、资金不足等也会造成流程产出率低下的问题。ITIL的问题管理流程就是一个典型。我在给很多客户做ITIL流程咨询时都发现问题管理流程往往流于表面，是一个空壳子流程，这里的根因有很多，其中一个就是IT技术人员的技术能力差，往往导致很多问题都没有解决方案，流程实际效果很差，继而让人怀疑问题管理流程是否有必要。其实问题管理流程是一个“功夫在诗外”的流程，这时，解决问题的能力比流程本身还要重要。

我们一定要聚焦主航道，以合同信息流为中心全打通，合同信息包括从合同生成到交付回款，其他先放一边。我在LTC会议上说过，我们就是将合同信息流打通，其他优化模块、能力模块，先放一边。现在GTS流程基本打通了，企业网流程阎力大也基本打通了。

我们打不通的是做了几十年的系统，为什么？因为不聚焦在主航道上，什么乱七八糟的都往主航道上放。流程要支持主航道主干体系，这个系统的人多提拔，优秀儿女都涌过来，怎么可能会打不通？打通了，再去挖小沟、小渠。大禹治水，如果大江大河都没有打通，难道把小沟挖完后就没有水灾了？现在流程IT之所以困难这么大，就是因为主航道没打通，导致投入了很多兵力，做几百个项目都没有用。

第二，能力要模块化。

我们不要有完美主义思想，流程与能力解耦。能力模块化以后，单个能力能及时、快速优化，不要因为这块能力优化，把其他能力也给拖住。以前华为公司存在那么多问题，也发展到了今天，所以能力即使达不到最优化，公司也不会活不下去。如果今天的能力能做到完全优化，那五年后我们做什么？

长河点评：

刚才讲过了流程和能力的关系，现在说说流程和能力的解耦。举个例子，我们在设计流程时会定义一系列流程角色，这些流程角色承担各个流程活动。但是，这些流程角色是虚拟的，在真实的职能岗位中是不存在的，我们需要将这些角色映射到现实的岗位上，也就是将流程活动节点的责任落实到真实的岗位和人员头上。这些岗位和人员的能力可能会支撑多个流程的活动，这就是流程和能力的解耦，相信大家很少看过某些岗位或个人仅仅只服务于一个流程的情况。还有，一些子流程也可以做成独立的可插拔能力模块，跟主流程解耦，来给其他多个流程来调用，例如ITILV3中的评估流程以及服务验证和测试流程就是例子。

第三，所有能力要有统一接口，IT应用坚持软件包驱动。

IT部门要与业务部门形成合力，重点突破，为一线作战队伍提供集成的IT平台。一线人员登录IT系统后，能够获得作战所需的资源、能力和服务，使得一线能够灵活作战，后方有力支撑前方，业务过程透明可视并监管有效。公司各种数据（如GTS数据、供应链数据、三朵云的数据等）要制定统一的规范接口，拉通互用，才能多维度关联建模分析，提升作战效率，数据资产价值最大化。
建立业务部门与IT部门的联席会议，重要问题在联席会议上讨论，一定要打通各个业务模块、信息模块、信息共享。

长河点评：

数据只有在流动中才会产生更大的价值，大数据分析往往有一个前提，就是要打造全局主数据，只有主数据通了才能更好地发挥数据分析的价值。主数据需要在PaaS层全域拉通，例如通过建立专门的数据共享交换平台，这样才能达到业务数据的贯通和业务流程的整合，才能实现更大的业务价值。举个例，大家都知道一个城市到处都有摄像头，如路口拍摄闯红灯、街头拍摄治安事件、路面拍摄扬尘泥头车等，这些数据如果不互相打通，那就要各建立一套摄像视频平台，既浪费又效率低，数据共享和治理是一个方兴未艾的话题，建议大家好好关注。流程优化的一个重点就是要打通流程之间的接口。现在的热门话题是自动化运维和Devops，但是如果流程之间的数据不打通，如配置信息没有拉通，将是不可能实现自动化运维。

IT是服务于业务的，IT必须随时了解它服务业务的效果和效率情况，同时IT的各类变更也要跟业务进行紧密的沟通。例如，ITIL变更管理流程的CAB会议就需要纳入业务部门的代表来评审。尤其是大的IT变革项目，如IT基础架构的大规模升级、应用系统的建设都需要IT部门主要跟业务部门沟通、主动了解业务需求，切不可闭门造车。

IT是服务于业务的，IT必须随时了解它服务业务的效果和效率情况，同时IT的各类变更也要跟业务进行紧密的沟通。例如，ITIL变更管理流程的CAB会议就需要纳入业务部门的代表来评审。尤其是大的IT变革项目，如IT基础架构的大规模升级、应用系统的建设都需要IT部门主要跟业务部门沟通、主动了解业务需求，切不可闭门造车。

IT部门是“万里长城”的主要建设者，需要建立自己的能力中心，坚持购买软件包驱动变革、驱动流程，不强调自主开发。前期公司已经将流程IT的开发部门全部切出去了，你们要学会当甲方，他们是乙方。如果你们自行开发出一个软件，无法想象五年、十年后还能不能使用，而且算算开发人员的股票、分红……成本多高，还不如从国外或企业BG购买。一方面他们已经构建了软件包的生命周期，另一方面他们会不断维护生命周期的循环。所以我们强调改变模式，减少自主开发，用美国砖、欧洲砖……来修建“万里长城”。

长河点评：

IT人员在面对一个问题时往往首先采用技术思路来解决，例如，如果IT部门服务效率低下，能力不足，成本过高等，作为IT部的负责人首先想到的是增加人手，让大家加班解决问题，他脑海里可能难以想到，其实很多企业在将IT服务外包出去之后这些问题都迎刃而解了。将IT服务外包出去，这个就是业务思路。

再比如ITSM工具，很多企业的IT部门首先想到的就是自己开发一套，因为它有现成的开发人员，其实管理者可能根本就没有掂量过自身的能力是否能够支持他开发出一套真正符合ITIL思想的工具，事实上很可能他对ITIL的精髓思想根本就没有领悟清楚，这样开发出来的ITSM工具其实并不是ITIL工具，效果肯定好不到哪里去。其实，他完全可以考虑采用开源ITSM工具如iTop这样的软件。所以说，跳出技术思维很重要。

三、未来五年，华为要自己实现ROADS，实现数字化转型，变革与lT要在夯实IPD/ISC/LTC/IFS的基础上围绕这个目标来展开。

公司提出了ROADS计划，要沿着这条路持续走下去。使能公司实现数字化转型和大平台下的精兵作战，在研发、销服、供应等业务领域要率先实现ROADS体验（实时、按需服务、在线、自助、社交化连接）。

长河点评：

ROADS是华为针对移动互联时代消费者行为模式的改变，提出的一项用户体验标准，也是一种业务转型战略，即实时（Real-time）、按需（On-demand）、全在线（All-online）、服务自助（DIY）和社交化（Social）。

在这里我们要特别讲一讲移动化对IT服务的改变。现在华为的移动化无处不在，例如手机电话会议、手机打卡、手机请假、手机填报工时、停车场自动收费等，大大方便了员工。对于IT服务的渠道来说，移动化让用户与IT更贴近，ITSM工具可以通过移动化手段来大大提升用户体验，如，我们可以提供微信报障，微信留言会自动转为报障内容，当事件单处理有了进展又会自动发微信消息给用户知晓。这样用户的体验肯定会好多了。

学习了