[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放[p=30,2,center]
[p=30,2,center]
1.缘起
半年来一直想把ITSM方面的认识写一篇总结性的文章，但太懒了就一直没有写，加上兴趣精力多花在其它方面了，搁太久又怕以后不会写了。想着这些思考还是留一个记录为好，给自己给别人以后可以看看，因为5年前我一直想看到这种文章的。正好近期公司办了一个市场活动，讲的ITSM的实践，跟我想写的东西有一些类似，在活动花了一点时间讲了这方面的东西，但由于时间太短，没有完整的表达完，于是决定写下来。
网络上的一些豪无主见跟思想的文章极多，加上百度够烂，基本上一个想研究ITSM的人难以找到这方面的有提炼的材料，中国充满太多讲故事的人，太多背诵、转述与抄录的人，这些人只是以此为生计或手段，他对这个东西本身是没有兴趣与感情的，又或者是脑子缺乏一些深度，通过这两年看到的情况，估计真正深刻理解ITSM的理论与实践的人不超过10个人，中国真正实现了IT服务管理的企业一家也没有，这是这个国家跟产业的悲哀，再火热的概念，大家只是一窝风的拥上去，不敢独立去思考，每个人都等着别人去做标杆，问别人怎么做，那些拥有最大的数据中心与最多的IT人员的公司，无法在ITSM实践上有所作为与建树，都应该感到惭愧。
废话几句，发发牢骚，入题
1.ITSM的基本状况
开始还是简单的介绍一些ITSM外围的一些情况，
1.ITSM与BSM与云计算
云计算近几年很火热，炒得一塌糊涂，云计算是ITSM无法回避一个课题，任何一种新的技术或产业模式的调整，必须会对管理理论带来挑战，我们必须需要考虑云计算与ITSM的关系问题，云计算到底是一种架构模式？一种产业方式？一种新的技术？又或是一种运营理念？，当一个数据中心已经实施了ITSM之后，引入云计算，应该如何将两者进行整合？，云计算的实现依赖于两个技术基础，一个是虚拟化，一个是自动化，前者主要是VMware、Citrix、Microsoft提供的虚拟软件及平台，这一方相对稳定成熟了，后者自动化分为二个层面，一个是针对具体服务对象的操作动作自动化，比如对服务器、网络设备、中间件、数据库等，这好比人的手与脚，另一个是指跨对象、跨事务的自动化，它通过调度连接一系列的动作来实现某一个流程链条，这好比是人的神经系统。可以想象一下，当虚拟化技术发展成熟后，各种原来固定的架构对象，将会高度动态的做自我调整，这导致原来的配置管理流程或CMDB技术完全无法应对，而自动化技术发展成熟，原来需要依赖大量业务逻辑的活动，完全会被封装在自动化软件本身，这同样会对管理流程带来极大的冲击，这些应对，没有哪个人或组织已经做好准备。
前段讲的是云计算的两个技术基础，云计算的同样需要依赖扎实的管理基础，没有管理的云，那是风云，仅仅技术的封装是不够的，从管理体系而言，它必须统摄云计算，自动化的前提是标准化，而标准化依赖于流程的设计，当我们把架构的动作分散成标准的之后，通过自动化技术把这些动作进行重复与组装，这跟T型车的生产线一样，服务将以流水线的方式被生产出来，这预示着大批量的服务将不再依赖人类的参与，在一个数据中心的IT架构每天在执行自动化的操作，这对管理的要求将比以前高很多，尤其是在变更与配置的部份。云带来的收益与风险是成正比的，IT服务管理是实现云计算的基石。用一句话来总结，管理是云计算的体，技术是云计算的相，服务是云计算的用。
从模式而言，IT服务的模式有三种：
◦面向对象：传统上的IT运维事实就是一种面向对象的服务模式，它关心的是IT架构中的一个个独立的对象（可能是一个服务器，或一个软件，或一件网络设备），把这个对象修复好为主，这种形态下的作业模式，组织体制一般以专业为主导，所以它的行政单位多是按专业技能划分的，服务目录按对象进行设计，这种类型的公司一般对手册很重视，对比较牛X的技术人员也很重视，因为手册解释了怎么搞定这些对象，而救火时工程师很容易表现立功。
◦面向服务：面向服务关注的是一个个服务，通过目前的企业中，服务是以软件的方式呈现的（SaaS），此时服务团队关注的将是单位将更加完整，他们会关注系统级或一个完整的服务，这种类型的公司一般对流程建设很关注，服务目录也会面向整个服务去考虑，所以服务范围将会更广，此时的企业多半已实施了ITIL或ISO20000，组织层面，已经开始突破专业团队的单纬结构，服务层面的建制开始完善，形成一个矩阵的组织形式或，再加上流程管理的三权分立的组织模式。
◦面向业务：面向业务的模式则范围更广，它不再从IT本位的角度考虑，而是从业务需要的层面考虑，一切非业务的都打包成服务的形式以支持业务，而这些服务一旦标准化之后，将进行打包再外包，这样企业只关注自己的核心的业务与竞争力，所以整个服务目录的范围将会更加广阔，此时IT战略才有可能真正与企业的战略完全对接，IT与业务已不再可分，从严格意义上来说，BSM（业务服务管理）它是一种企业的管理方式或运营模式，它不是IT视角的，说它是IT管理的一种方式，是对BSM的弱化与局限。
诸有智者，要以譬喻，而得开悟。上面讲的几种模式用比较通俗的方式打个比方，IT架构好比是素材，好比是各处做菜的材料，比如蔬菜、豆腐啊鱼啊肉啊。面向对象的模式呢，就好比做一道菜，一个香煎豆腐（最爱呀），或者糖醋鱼（最恨呀），你点一个菜我做给你吃就完了；面向服务呢，就好比做一个满汉全席，把你吃得爽是我的责任（冯小刚说成功是他的责任）；而面向业务呢，就不再这样看问题了，我得看你缺什么营养，从你的健康角度出发，不但只是考虑味道好的层面了。值得注意的是，这几种模式之间并不是一种互斥的关系，而是互为基础的，从面向对象到面向服务，最后到面向业务，层层螺旋上升。
1.ITSM项目情况
国内的ITSM项目以两类为主，一类的ITSM咨询项目，一类是ITSM软件项目，有时这二者会合二为一在一个项目中操作。为了讲述的方便，还是分开说明：
ITSM咨询项目：国内的ITSM咨询项目多以管理体系规划设计或灌标为主（ISO20000），流程的规划设计相对成熟了，毕竟咨询公司或顾问有一些类似的沉淀与积累，ISO20000的灌标在中国的数量怕是最多的了，国人热衷于标准认证，因为容易出政绩，前年时在ITSMF的网站上查到中国认证的企业家数已有100多家了，比美国与日本的总数还要多，二年前已经有的咨询公司敢十几万去做一个ISO20000的咨询项目，还包认证的费用，想一想就知道多可怕了，这就好比九十年代伯ISO9000一样，很快就稀烂了，标准是一个好标准，奈何没有好的咨询公司与认证机构，当然归根结底是由于客户的不切实际与超级实际所致。咨询项目在中国的效果并不好，最终的交付都是一堆的文档，这些文档最终有几个人真正去阅读都难说，现要一个可笑的情况是，咨询项目做得好不好，很多时间是根据咨询顾问的个人魅力或交际沟通所决定的，以致于现在的咨询顾问的软能力超强，而硬能力没有什么建树，咨询项目可能会帮客户梳理一下流程，做得再好一些的就是再弄一些岗位角色、职责方面的东西，更好一些就是弄一些KPI绩效方面了，但这些往往只是在设计阶段完成后，咨询顾问就离场了，最后的落地实施咨询顾问们是很少参与了。我很怀疑去靠一些方法论去操作一个咨询项目能做出怎样的质量，因为绝大多数成熟些的咨询顾问，都是依靠方法论、模版来打天下的，说到服务，他们是真正把服务做成生产线模式了，既要考虑不影响项目验收与时间，又要考虑不触及各方的反对与矛盾，同时又把活能交付得出去，而且把方法论说得头头是道，这才是现在一个咨询顾问的最核心的能力。一个没有真正理解ITSM的人，如果没有足够的洞悉分析能力，靠标准的问卷、访谈，去听听各方的要求与建议，最后综合妥协出一个报告出来，这是绝大多数的情况，只依赖方法论而没有真正属于自己的理解与认知，最终这种东西可以放诸四海，对一个特定的组织并没有什么实质意义，这就跟每年的政府工作报告一样，说得都对，路线图也不错，但是你总觉得缺一些真正该有的东西，有形无神。这些能怪咨询公司与咨询顾问吗？，也该怪也不该怪，早期的麦肯锡有一点是相当有力的，他们只为CEO服务，现在购买ITSM咨询多是比较大型的企业，尤其是国企占多数，咨询顾问能见到几次CIO呢，这些报告真的为CIO们所关心与重视吗？，我看未必，许多时候这些事务多是委派给一个并不掌握权力的人对接，中国所谓的CIO们在关心什么？，他们可能很多都是嘴里最喜欢说流程与规则，却自己不参与游戏的人。任何一个有效的管理体系，它一定会限定所有角色的权力与活动边界，包括顶尖者，一如宪法会约定总统的权力边界一样，在中国，往往领导是最大的流程或规则破坏者，你只有到国企真正走了一遍后，才明白为什么官僚系统可以多大程度影响人们的思考能力，那种对领导的尊重与敬畏，让很多人无法独立思考，许多你看起来很荒唐的东西很正常的出现，构建一个良好的管理体系是如此困难，而却有太多因素就可以造成体系的变形与扭曲了，有时会让你觉得这个世界，这家公司，这个部门，这件事情真是豪无希望的，如此没有效率及不合理，但奇怪的它们存在在，而且还将持续的存在着，也许就是这种不效率养活了这么多地球人，事物的存在只需要很低的标准就可以了。
ITSM软件项目方面，国内基本上成规模的IT部门或数据中心都上了ITSM的软件了，基本上服务支持端的流程已经利用软件进行管理，从效果上来说，一个软件项目要比一个咨询项目会更能实质的影响一个IT部门或数据中心，因为文件比软件需要更多的外在条件与强制力量，现在ITSM软件的实施方面，大部份成规模的用户已经把事件与变更这些流程弄完了，这一两年内服务请求流程与发布流程实施越来越多了，CMDB也越来越重视，服务支持真的扎根成熟，估计还需要两年的时间，从实际角度出发，云计算的出现，分散了数据中心的领导们的精力与关注度，把这些精力扎扎实实花在ITSM的建设上，反而容易见实效一些。国内的ITSM软件项目有几个常见的问题：
1.不知道是买的是什么：国内的ITSM选型，多是焦点于功能之上，甚至绝大多数的产品测试，也是综合厂商们的建议，很多企业并不知道自己要什么，安排的选型人员也不专业，连ITSM的基本知识都不具备，一个管理软件的价值在于它背后的管理逻辑与思想，很多时候买了成熟的ITSM软件，却把它当开发平台来用，这是典型的买珠还椟。
1.国内还不重视服务的价值，甲方处于强势的地位，所以对于软件项目的服务人天，在一开始的商务报价中压得较低，加上在项目过程中无谓的使用与浪费，导致最终咨询与实施顾问只能把验收项目置于第一位考虑，因为每一个公司都必须考虑成本问题。这样的局面下，咨询顾问们会想办法把一些规避一些难度的事情，这是一个死循环，目前还没有看到解，ITSM软项目超期的很多，很难挣到钱，因为咨询顾问与开发人员把绝大多数的精力花在一些细节功能层面，项目管理方面做得不好，现在的厂商能否做好一个ITSM软件项目，很大程度上取决于甲方了，更确切的说取决于甲方配合的人员。
2.权责不对等，一个ITSM软件项目，最终软件的反应不好，责任往往怪在咨询顾问身上，做咨询实施的人比较可怜的一点是，他们无法决定这个软件的需求，但要承担这些需求的后果，你会活活的看一个林志玲被改成芙蓉姐姐，你却无能无为，还要被人说这是你整的。咨询顾问虽然沟通说明能力会强一些，但实际上也说服不了多少人，人是很难被说服的，一开始有所坚持的咨询顾问，最后都会被打磨成一个很顺客户意见的顾问，因为你没有办法牺牲个人利益去跟去为一个跟你争论的人的利益服务。
3.每个企业的IT部门都认为他们很特殊，他们的IT运维跟别的公司或别的行业是不一样的。其实真的有差吗？当你面对的都是同样的服务对象时，系统的SLA也差不多时，本质上其实是一致的，一个金融行业与制造业的数据中心运维，他们的IT运维差别并不会比同一家公司的不同系统的运维差别来得大。但是许多人不会这样认为，他们会以他们所谓的特殊来改造软件，而不是按软件来改造自己，最终越定制越个性化，越个性化越定制。一个ITSM软件往往是从一些不起眼的地方被改起的，然后慢慢的越来越多，要知道乔布斯是极少极少的，当没有人可以控制这个软件的发展时，最终软件只是成了一个追随企业的工具，而不是一个引导管理的平台。我们发现那些以标准的管理套件为主的客户，反而得到是最多的，那些一开始恨不得厂商开发一个超级系统的客户，反而是得到是最少的，与厂商配合的甲方人员的职位高低跟项目的收益是成正比的，绝大多数项目的绝大多数时间都花在讨论无关紧要的一些按扭功能上了，这些其实对功效可以忽略不计，毕竟这是一个管理软件不是Iphone。
4.ITSM的实施要点
5.规划设计的全面性
对于一个事物而言，规划与设计会先天的决定它的质量，对于一个产品或一种管理方法体系更是如此，一个管理体系本身是存在结构的，什么是结构，当一个对象与一个对象存在关系时，最终一群对象会构成某种结构，什么是对象，对象就是你的流程，你的服务，怎样去组织这个结构，去定义这些对象的关系，去定义这些对象是什么，这就是规划与设计。现在国内的ITSM实施时，在规划设计时，只考虑了流程层面，但忽略了服务层面，我们一定要深刻理解一句话，管理是体，流程是相，服务是用，这三者缺一不可，没有流程，没有服务，管理是不存在的，体靠相与用来体现，同样的，没有用，相本身只是表层，所以在规划设计时，流程只是一极，服务是另一极，这是车之双轮，鸟之双翼，缺一不可。ITILV3在很大的篇幅在谈服务设计，那只是理论的层面，具体到实践层面来说，服务设计是做什么？，这不是空谈与玄思，它一定有实实际际的动作与载体的，详细的后面再展开说明。
6.体系与平台的整合
如何是去管理一个企业，或影响一个企业，大概有两种路数，一种是通过控制人来实现，即我要这些人干嘛就干嘛，还有一种路数，是通过控制流程来实现，比如我们管一个外包商，最有效的方法，是我们来决定了他们每一件事情要按怎样方式与步骤来做。这就好比苹果要富士康来生产Iphone，苹果如果把制程的每一个工序都约定死了，这样是最有效且够深度，而不仅仅通过最后的QA来把关。通过控制游戏规则来影响别人或别的组织，这条路是可行的，但问题是这些规则往往存在于文件之中，行动由每一个人去执行，业务体现在每一件事情上，没有一个全知全能者可以洞悉到所有的文件的要求，是不是被遵守于所有人与所有的事，这就导致了管理软件平台的产生，由于在现实中无法全能监测，所以通过管理软件或管理平台去建立一个”场”，让这些业务逻辑规则、业务人员、业务事务在这个场中去运作，这就是管理软件的一个根本目的，但是怎样把体系或流程的逻辑消化到软件功能上，这是一个复杂的课题，经过不同的人层面转化、传递，最终知识剩余无几，只有真正能抓住本质的人，才能洞悉根本，把业务抽象出来。当体系与平台真正实现融合后，以后任何流程政策的变更都需要经过考虑是否需要做软件的相对调整，对流程的审计转变成对平台的审计，这样可以把一个相对空洞的东西用一个有现实对象的来替代，这就是为什么许多公司管理外包商或供应商，要他们用统一的管理平台的原因，这是最省力的一种方式。
7.组织建设的重要性
许多ITSM咨询项目也好，ITSM软件项目也好，最终的效果不明显，有一个比较重要的原因就是因为没有对客户的组织进行一些改革，因为一谈到组织，就好象是雷区一样，咨询顾问都不愿意去碰这个，都怕引火烧身，这基本上都成了做咨询的人的潜意识了，但现实的情况是，中国的组织设计很糟糕，从政府到企业都是如此，越是国企越明显，这些组织或部门形态都不是规划设计的结果，而是随着某些人员的能力或某些项目的发展，某个领导的拍脑袋的结果，它经过比较长时间的发展，有它的合理性，但那只是维系现状的，如果真的走向面向服务的管理模式，没有组织的相应设立，是会事倍功半的。
对于一个IT组织而言，第一纬度往往是专业技能的，即某一种专业技能的人形成一个团队，安排一个主管来管理，比如系统管理、网络管理、存储管理、软件开发等。仅仅单靠这一个纬度的组织来应对服务运行是不绝对不够的，因为是服务不以专业来划分，一个服务有可能会横穿所有IT技能，比如一个ERP系统服务，它既需要主机、也需要网络，也需要存储，也需要开发，这个时候传统的技能型组织结构应对这个服务就很困难，没有谁来主导这服务的过程，谁来承担这个服务的质量责任，谁来思考这个服务如何改进，此时就会出现主体缺位的现象，那些说依赖流程把行政部门隔阂打破的咨询顾问，是没有理解这个流程的背后是业务，这个业务需要一个主体来推动的，流程本身只是逻辑，业务才是流动的，所以此时需要在传统的IT部门模式下（事实上大多数的专业技能部门划分本身也有许多病态的地方，这里就不展开了），再建立一层服务组织模式，这二者是一个交叉的矩阵模式，这意味着每一种专业技术有一个管理者，每一个服务也有一个管理者，而每一名工程师，他从属于两个领导，一个专业技术上的，一个是业务服务上的，这样做的目的在于，必须要让承担服务结果的人掌握着服务资源的调度能力，许多公司的人员，系统运维出了问题要背责任，但是他却根本调不动涉及到这个服务的专业人员的，调度他们以前需要靠找对方的领导或组长，这非常没有效率，而且造成管理者缺乏主动性了，而工程师也缺乏责任认知，因为他的KPI是行政主管说了算，服务这一续度的组织设立是关键性的，它直接决定了这个企业的资源配置的方式，这也决定了效率，我深信，如果一个IT服务的公司如果组织上完成转型成功的话，同样是１００个的人公司，它要比传统的行政结构的IT服务公司效率提高50%以上，且人员的干劲会强很多，因为没人在扯皮、混乱、官僚的环境中可以一直保持热情与责任感。以上说的是建立专业与服务的矩阵模式的组织结构，但这还不是终极的情况，要做得更好，还需要另外一个纬度的权力参与，即流程，最终专业、服务、流程会形成三权分立的模式，原因是，当专业力量与服务力量成长之后，对于游戏规则的制订是非常重要的，让专业管理者或服务管理者去制订游戏规则，会导致这样的局面，专业管理者会无视业务的现实与效率，盲目的追求技术规范与安全，服务管理者会无视专业标准与规范性而追求服务效率，最终这两者会形成对立，一旦让在场上踢球的人来制订规则并做裁判，就容易出问题，企业一如国家，需要有独立的立法机构，管理管理者就是集立法与司法于一身的单位，他们会负责建立一个企业的IT服务管理体系，并对专业与服务进行审查，以保障有效落实到位，最终专业、服务、规范三者都各有其目的，但是这个博弈的过程会带来一种企业的平衡。
8.关注完整生命周期
在接触ITILV3之前，从ITILV2与ISO20000的理论与条文中，我在思考IT服务管理体系时就感觉到一个问题，它们好象认为服务就是“存在”着，既没有说服务如何创生，也没有说它如何终结，这就带来一个问题，当我们在实际应用这些理论时，我们需要从无到有进行逻辑演译，我们把管理体系想象成一个机器，我们就得考虑如何让原料（服务）如何进入这个机器，如何让原料（服务）从这个机器出来，正是在这个思考过程中我意识到服务设计的过程的重要性，没有它，我们无从下手把服务装入到那个管理体系之中，只是后面ITILV3出来之后有一个明确的叫法，叫生命周期管理，那时我就更加坚信当时的思考是正确的。
生命周期主要有二个要点，一是在什么时候展**务设计，二是什么时候结束服务。
现在大部份的服务其实是软件系统了，SaaS其实可以抽象的理解为任何一个软件或系统就是一个服务，这不是技术层面的理解而是管理哲学层面的理解，现在许多公司比较痛苦的一点是研发与运维的对接问题，任何一个系统的开发，一旦上线之后就进入了生产环境了，但是此时运维这个概念其实并没有产生，因为开发型项目与运维团队在现实之中产生了大量的重叠活动，当开发型项目结束之后，运维团队面临时系统已经运行较久的局面，此时非常容易出问题，开发团队争于脱手，运维团队准备不足，迫于商务或时程原因，项目经理们或领导会倾向于把系统早一些甩给运维团队，这从一开始就造成了混乱，这是运维团队最痛苦的事情之上，现在许多公司的研发部门仍负责主导一些系统的运维，其实跟这一现实有很多关系，原因是这类公司的领导没有意识到运维的资源需要包括研发力量的，他们还是停留在传统的专业组织结构上，而研发体系多是走CMMI的路线，而运维体系多是走ITIL路线，夹在中间的运维负责人与开发工程师就苦逼了，所以运维团队与研发团队的对接，项目开发过程与IT服务过程的对接，就需要一个专门的流程或活动来负责，这个过程就是服务设计，依靠它来对接CMMI与ITSM，具体服务设计做什么，后面再详细说明
前面说的是服务的开始，现在说服务的结束，服务的结束有两层意思，一是服务周期的结束，但在下一个服务周期开启后，服务依然存在，二是服务真正的终结，比如系统最后退役了，这二点其实都可以按服务周期的模式来看待，当一个服务周期结束时，需要审查每一个服务的服务设计是否按预期的执行，即对服务进行审计，事实上对服务进行审计也就是对流程进行审计，因为流程审计的结果必须体现在服务之上，无论是流程设计还是服务设计，最终都需要建立PDCA的闭环，所以在服务周期结束时，要展开一次全面的审查活动，测量出当前的流程成熟度与服务成熟度，以及其中存在的流程问题与服务问题，有可能是需要改变流程或改变服务设计，也有可能是加强监管与执行力，这些信息是帮助我们做每年的总结或明年的规划的，这就是完整的生命周期的概念，现在绝大多数的IT服务部门或公司，都不重视规划与总结，每年年初跟平时没有什么两样，每年结束时搞一个皆大欢喜的总结，这种总结基本上跟政府工作报告一样，形势很困难，取得成果很不容易，问题挑战仍然有，一个服务管理成熟的组织，我认为它在运作时必然有一种节奏感，每年有年度的节奏，每月有每月的节奏，每周有每周的节奏，每天有每天的节奏，这就象一个生命体脉动一样。
9.ITSM的体系规划
在在一个组织里实施ITSM，首先要进行规划，就好比一个产品设计之前的构思，体系规划的意思是，得把流程框架建立起来，在大脑中得把这个各个流程的宏观结构做一下构想，如果把一个流程理解成一栋楼，规划的动作就好比在一个区域想好要建多少栋楼，每栋的基本外观与间距等等，但是每栋楼的内部结构是具体的设计工作，后面再谈。体系规划的工作相对不那么复杂，因为ITIL的理念也好，ISO20000的条文也好，已经帮助我们将流程切分得相对清楚了，要做的就是根据企业的特性，做一些合并或细分的工作，然后把流程的接口定义清楚。在体系规划的层面，就需要树立服务与流程的矩阵的视角，这是最大的宏观结构。另一个问题是每个组织运作较久后，会有一系列的文档手册。许多手册与文档的边界并不清楚，需要重新考虑这些文档的定位，在一个规划良好的体系中，任何一份文档与记录，一定归属于某一个流程的，而且清楚了定义在流程的什么阶段由什么人产生。在咨询的时候，我们有时候只考虑了全新的构建流程，没有帮客户把以前的手册文档进行整理，导致这些现实中发挥作用的“地方法规”没有整合到“宪法”之中，最后“宪法”（管理体系）越走越空，流于形式了。理念是最空易空谈的东西，但也是最有力的东西，一旦头脑里面建立了真正的“面向服务”的概念与精神，这个管理体系本身就有了内核，也就是有了方针，这个东西会让我们面临复杂的问题与局面时，相对清晰的看清楚方向，一是指南针。每一个流程最后以文档的形式呈现出来，需要事先约定好二、三、四级文件的颗粒度与形式。
经过这些年在这个社会的生活与工作，我发现最喜欢谈规则的人最无视规则，这多数是领导了，这些人在谈这些时，他是把自己超脱于这个体系的，而当你跟很多的领导交流过，见识过他们开会与决策的情形时，你就会明白，把这些人装进一个框架里是多么重视，所以一个全面的管理体系必须考虑领导的活动问题，管理体系规划设计得好，它会制造合格的CIO与IT服务经理，因为它规范了、指导、要求了这些管理者做什么，因为对于管理体系而言，这些只是角色，对于它来说，CIO与事件管理员并没有什么不同，只是需要完成某个目标才设立的角色，这些都只是抽象的存在，管理体系不认为有超越它存在的任何活动、过程、角色、信息，它是一，也是一切。如果秉持这样的思路去规划设计，你会发现只需要从基本的问题开始，就可以把许多无用的角色与活动废除掉，因为这些角色的存在本身不带来价值的活动，它只是为了活动而存在，当我们用一种生冷客观的眼光去看待事物时，一切会更加清楚，领导们干着的工作其实比我们想象的要容易简单得多，许多我们不敢去改变的规则背后，其实躲着一个可笑的产生原因。管理体系许多时候跟宪法有很多相似的地方，有时想你看到的许多问题，你会发现无论是在国家的层面，还是在企业的层面，其实问题都是相似的，或者说是同一种或同一个问题。
10.ITSM的流程设计
流程设计就是需要解释、定义、描述一个流程的要求、触发条件、过程活动、角色岗位、关闭条件、过程记录、以及对流程的测量要求。最终这些其实是体现在文档之上的，现在许多公司的流程文档一蹋糊涂，模版糟糕不说，连二、三四级文件都没有做区分，里面的文字描述不知重点的罗嗦，法律的每一句话是用特定的用意与目的的，在一个流程文件中写一堆不知所谓的废话，唯一起到的作用就是让看文件的人失焦，找不到要遵守的点是哪一些或者要干嘛。流程文件不是培训与宣传用的，每一句话就是一个要求或指导，精炼很重要，而且要有层次感，动则上十页的流程文件往往都是有问题的。
11.流程政策：流程政策是指针对这个流程的一些要求，事实要求绝大部分都会体现在某一个流程活动之中，但有一些总体性或特殊的要性无法放在某一个流程活动里的，这样就会抽到流程政策中进行统一定义了。比如变更管理流程政策里有一条，要求每一个月需要对变更的成功率进行统计分析，这样的一个作业要求，它无法与变更流程的某一个流程活动相关联，所以在流程政策里说明了，流程政策的每一条都是强制性的，在任何服务之中都不得排它，如果流程政策中有一条适用于59个服务，但有一个服务由于服务特性所不能适用的话，就必须更改流程政策，或者删除此条款或者特别注明引用限制。
12.流程的触发条件：流程在什么时候启动，这个听起来好象很简单，但其实非常复杂与重要，尤其是象信息安全管理流程、可用性管理流程这类流程时，许多时候人们不知道什么时候什么状况下要走这个流程，最常见的事件管理流程，到底什么时候触发？，比如我们会写“用户通过热线电话、电子邮件等方式提交故障说明”，这一条很可能是不够的，因为监控的运行人员会发现故障，一个系统管理员也可能会主动发现一些故障，用户有可能是当面的方式说一个故障发生了，或者用户不是提交一个故障，而是一个要求帮他装一个系统，这些如何应对（假设没有独立的服务请求流程的话）。再比如变更管理流程的触发条件，当我们实施ITSM久了之后，我们会发现变更管理的范围仅仅覆盖到IT架构的变更是绝对不足以控制服务质量的，许多流程的变更、服务设计的变更、服务体制人员的调整都会引发风险，此时我们可能需要把变更管理的控制范围扩大为所有服务变更，而不仅仅是架构层，这会比较有效的控制管理层面的无序与错误的资源配置方式。
13.流程的过程描述：管理体系是流程的总和，流程是活动的总和，流程最终是依靠一系列的活动来体现的，所以把每一个活动定义清楚很关键，在每一个活动中问是谁？要得到什么？要做什么？要留下什么？，这样才能把活动写得清楚明白。但现在的情况是有一些相反，流程图被搞得过于复杂了，一个事件流程被分成一个主流程与若干个子流程，流程图最终搞得象电路图一样，把每一个可能的逻辑都弄明白、走到底了，但带来的问题仍然是难以阅读，看这个文件的人无法在大脑之中组织出他要遵守什么要做什么，当一个流程文件最终只有编制者能看懂时，这个文件是没有价值了。
14.流程的关闭条件：流程最终关闭的准则是什么，比如事件流程，事件得到用户的确认，这就是一个关闭条件。
15.流程的记录：最终这个流程跑完之后，会留下哪一些记录与证据，这个需要在流程的过程描述中写出来。
16.流程的测量：流程的测量是指流程管理员或流程经理们需要做的事情，即要定制对流程的指标进行分析，这完全是流程层面的与服务层面无关，比如想知道事件流程的改进情况，把上个月的事件按时解决率与本月进行对比。
17.ITSM的服务规划
服务规划全组织的，不是针对单一服务的，在每年的年初都应进行此项工作，目的是理清当前的服务情况，包括目前提供的服务有哪一些、每个服务的编号名称、开始时间与结束日期，对应的合同号，它的责任人。要对目前所有的服务做一些分类，甚至要考虑好哪一些可以独立成服务，比如可以把所有的监控工作打包成一个服务，它向所有的应用系统服务提供服务，这样就从应用系统服务中把监控的内容剥离出来，比如某一些系统有着强相关性，属于某一个业务线的或某一个业务部门的，那么这些服务可以归为一类（不是一个），这样在安排服务经理时，可以按业务性质或分类来配置。要树立一个意识，在面向服务的理念中，不再有业务与IT的二元对立，只有服务方与被服务方的考虑，对于一个提供监控服务的团队而言，应用系统运维团队就是他们的客户，每一个服务只需要考虑你的服务对象是什么，你的服务客户是谁，你提供怎样的服务级别与服务目录，这样可以清理掉所有的灰色空间，最终业务可以由若干个服务所组成，每一个服务之间存在着关系，构成一个服务网络，每一个服务都以统一的模式去管理与运作，无论是这个组织是承担着50个服务，还是承担着200个服务，要做的就是增加服务资源即可，一切都只是复制的，这才是集团作战的模式。所以服务规划的重点在于确定服务的条目与模式。另外一方面，要明确当前的服务资源，到底现在有多少服务资源、他们被分配到哪一些服务之中，现在的行政组织是怎样的模式。基本上是明确我们要做什么与我们有什么的问题。再细一些还可以把当前的供应商明确列出来，把今年的预算情况也列出来，把今年的工作重点与计划列明出来，这些都是整个组织级的，每年年初这些会形成一个规划文档进行公布，同时需要进行受控管理起来，基本上一个新来的CIO是需要首先读这份文档的，它从最大的层面描述了组织的业务情况。
18.ITSM的服务设计
服务设计会形成一份文档，它相当于一个服务操作指导的手册，它产生于服务开始之前，可以利用它来将开发型项目与服务型项目对接，只有当服务设计通过评审后，才能开始开启服务窗口与交接，评审服务设计的人有可能包括开发方、服务方、客户方，当这三者同意设计时，按这个要求来操作，服务是有保障的。主要包括以下内容：
19.服务说明：介绍这个服务的基本情况，如果是一个系统，就介绍这个系统的基本功能与之关的项目状况，这有些类似一个服务的历史档案说明，让读者能搞明白这个服务到底是干嘛用的。
20.服务主体：谁是享受服务的人，是哪一些公司、哪一些部门、哪一些人员。这些信息最终进入ITSM平台的客户资料库
21.服务对象：对于IT服务而言，最基本就是要把涉及的设备对象服务好，精确一些说是配置项，它可能是一个硬件、一个程序，要把这个服务相关的对象全部提列清楚，如要是系经则把拓扑图画出来，再以列表形式把每一个配置项的情况描述清楚，这些信息最终进入CMDB
22.服务目录：针对这个服务而言，为服务主体（客户）提供哪一些服务目录，比如密码修改？功能增强？权限修改？数据导出？，这些会将客户的服务范围要求与服务提供方梳理一致。
23.服务级别：定义可用性、事件或服务请求的解决时间要求等。甚至包括回访比率与满意度。如果与客户有商业合同，此处则输入合同的级别信息即可。要注意的是要把测算的公工、方法、频率与周期约定清楚，这里面藏着大量的陷阱，尤其是可用性的定义。
24.服务日历：服务是5*8，还是7*24，甚至约定变更的日历与发布日历，它会带来服务团队一种周期节奏，尤其是开发人员，当每月只有两个发布点时，开发与测试会更加有序。
25.服务体制：承担这个服务的人是哪一些人，一线、二线、三线、N线分别是谁，服务经理是谁，谁是客户的业务代表，甚至包括分包商与供应商，这些角色要全部用一个组织架构图画出来，并列明每一个有的联系信息与职责分工。
26.关联文档：与这个服务相关的文档，比如前期的开发过程文档，各种操作、维护手册、甚至介质、代码库。如果公司的文档管理成熟，会形成一个公司级的文档库，每一个服务的文档与记录会有条理的储存在其中。
27.服务报告：这个服务多久要向客户的业务代表做汇报，汇报的内容有哪一些，谁去负责编制审核，什么时候来汇报，这一块对应业务关系管理，报告的内容可事先与业务进行约定。
28.备份计划：对应持续性管理流程，列明哪一些东西需要备份（程序与数据），用怎样的方式备份，备份到什么地方，由谁责任执行。
29.恢复计划：对灾难的事件预先分析会出现哪一些，用怎样的方式应对，需要多久时间、
30.监视计划：所有服务对象中，到底哪一些对象的哪一个些指标需要监视，用什么方法或工具，阀值是多少，产生什么记录。有些信息可以输出给监控工具。
31.事件定义：针对这个服务而言，一、二、三、四、五级事件到底是什么故障现象，避免事件管理员不知事件定级。注意，此处的事件级别是针对这个服务而言的，许多公司从总体层面来考虑每一个服务的事件定级，其实是一种误区，每一个服务的事件可以有等级之分，每一个服务本身也可以有等级之分，你不需要站在整体的角度去考虑所有事件的定级，这会造成统计的失真。一个一级的服务也可以有五级的事件，一个五级的服务也可以有一级事件，当你要站在整个组织的视角来统计事件的重要性与影响度时，你需要将事件等级这个变量与服务等级这个变量进行计算才行。
32.变更定义：针对这个服务而言，重大变更、标准变更、紧急变更是什么情况，很大程度上这是为了弥补流程政策的不足，如果你的变更管理程序定义很明确了，是不需要做这种设计的。
33.信息安全：当我们接手一个新的服务时，需要对这个服务的所有对象进行一次信息安全评估，然后把风险与处置计划列明清楚。
34.服务改进：针对这个服务已知的缺陷，列明处置的计划
35.能力计划：针对目前资源能力，这个服务可以承载的业务量或服务量的预算
36.持续性计划：持续性的测试或演练的计划安排
37.可用性计划：此服务相关的服务对象的加固或优化的计划安排。
38.IT成本。。。。。。
以上只是列举了一些例子，并不全面与精细，重点在于这种设计模式，可以想象一下，当一个全新的系统或服务交给我们运维时，我们用这样的方式去全盘把这个系统剖析了一遍，这些设计的成果最终会指导约束服务过程，当我们把每一个服务如要严谨的管理时，是很难有灰色与纠结的地方的，流程的设计是抽象的，服务的设计是切实的，这二者最终构成一个扎实的管理基础。服务设计最终是一个文档，事实上上面的每一个要点，都可以用一个表格来设计记录下来，当评审通过之后，赋予它一个版本号，并纳入变更管理的控制，任何对它的调整都需要经过审查与授权。服务设计适用于一个服务周期，在下一个服务周期开展前，需要重新进行审查。
39.ITSM的内部审核
当我们把每一个流程设计完成后，把每一个服务设计完成之后，当运作了一段时间后，往往这是一个服务周期，或者是一个自然财年，我们需要知道当初的设计是否被执行，也就是PDCA的过程，这就是靠审计，或者叫内部审核，目的是检查设计是否被执行，过程中是否存在问题，并进行分析总结，以为明年或下一个服务周期的服务设计提供参考。
做内部审核的依据来源于两个方面，一方面是流程文件，即那些流程政策与活动、记录中的要求，一方面是服务设计文件，即那些要求做的操作与要求执行的计划、指标。最终会形成一个审核表，按流程提炼出审核要点，然后针对每一个服务做审计，正常来说，每一个服务每一年至少要做一次，如果发生重大故障的话，还可能需要加做一次，因为重大故障往往是体系性失效的呈现，此时可以在事件流程文件的流程政策中列明，当发生重大故障后，必然重新审查此服务的服务设计结果。
可以设计一个算法，每一个审查点的得分，由于每一个审查点会与一个流程相关（活动必然属于某一个过程或流程），也会与一个服务相关（活动必然属于某一个服务的），最终我们会计算出每一个流程与每一个服务的管理成熟度，最终的计算结果会帮助我们确定自己的位置与目标，以及找出薄弱点与问题并做相应的服务改进。
内部审核以流程管理部门主导，会临时组织一个审查团队，为了避免利益关系，会做一些交叉的人事安排，以我的经验看，一个5人的团队二周之内是完全可以审查完100个服务的，所以前面提到说工作的节奏，每年把最后一个月安排做总结月，是比较合适的，这样把一年的执行情况做一下审查，并分析总结为明年的计划安排做准备。一旦这种运作模式得以执行之后，对流程的设计与执行的促进力量，以及对服务的设计与执行的促进力量是非常大的，它有力的推动一个组织真正走向成熟，我想任何一个组织一旦把这种模式实施完成，运行三个服务周期之后，最长五个周期之后，就会彻底脱胎换骨。
40.小结
管理其实也是可以抽象成一种哲学的，而哲学是可以多种视角的，我所说的只是我的现在的认知，我不认为我说的是唯一的路，只是这条路我走过一些，我想过一些，我认为它是相对可行的，有可能达到目标的方式有很多种，但最终我们需要明确判断一家企业的IT服务管理成熟与否，这个条件是应一致的：
1.有基于服务的组织设计
2.有基于服务的流程管理
3.有基于服务的统计分析
4.有基于服务的内部审计
5.有基于服务的绩效指标
6.有基于服务的管理平台
要深刻理解服务是什么，理解流程是什么，找到一种真正面向服务的管理模式，你的管理单位不是一个数据中心，而是一个个的服务，去定义他们，给予它们资源，去测量它们，去改进它们，不要去寻求参照系，真正的管理体系不是外源性的，你引入的任何方法与工具都应有效的组织在同一个框架之中，商业的管理是相对简单的事情，不是让你去制造火箭，只要我们独立认真的思索，必然是可以找到解的。
原文地址：xqscool/A1517552.html |
jadeloyalbird
发表于 2012-3-20 08:42:37
转播
分享
淘帖
()
