学习资料： ITIL培训基地专家讲堂直播 300期视频回放

体悟之一：以前目标管理，现在流程管理;

       服务管理实施前后主要的变化，表面看增加了一些流程经理，增加了一些“领导”——事件经理、变更经理，配置经理，问题经理。其实公司的业务没有发生变化，以前做什么现在还做什么。以前什么事情自动默认“目标管理”——最快最短流程的完成目标结果。效率很高 ，但有时候会出错，事件缺乏跟踪的事情时有发生，总有愤怒的客户出现。

有了流程管理增加了关键质量监控点
目标管理和流程管理区别是什么呢？   能够理解流程管理和目标管理的请跳过

       大家都在饭店吃过饭。客人少服务员多的时候，直接目标管理即可。下菜单准确，收银准确，客人有求必应。但客人多服务员少的情况下，同样要满足同样的服务质量，就需要按流程管理，虽然适当影响响应时间，但可以保障有求必应，下菜单准确，上菜顺序不出错 ，做菜口味不会出错，不漏单，不会有客人没有人服务，或者客人需求无人响应，导致客人受到冷遇而投诉。
       目标管理都是客户满意。中间过程不关注，这就是目标管理；分成几个过程关注，就是流程管理。分析客户满意一般需要9个方面，比如，1）预约，2）停车，3）进门找座位，4）点菜，5）上菜，6）就餐环境，7）菜品，8）收银，9）即时需求相应。如果客户不满意，那么那里不满意就调整这9个流程的质量，直到客户满意，这就是流程管理。当然这是人人都能看到的流程，还可以细化每个流程的详细步骤，比如菜品制作流程中，大厨自行制作，负责菜品质量，那么就是目标管理，如果把某个菜品细化成100个步骤制作，就像典型的肯德基制作方式，细化到切块大小，加多少克盐，油温1200度，时间20秒，那就是流程管理。
       IT服务环境中，比如处理服务器某僵死进程重启问题。目标管理的情况下，一般是管理员和主管直接沟通，批准后重启，以业务正常为目标。
       现在，目标没变还是要“业务正常”，先走事件发现流程，僵死事件自动发给快速响应人员，如果快速响应人员在以前的知识库中没有发现处理办法，转向问题流程。问题流程分析原因，判断出原因和解决方法，转变更流程。变更流程就此召开变更评审会，通过后发送变更实施人员重新启动僵死进程。变更成功，转配置流程的同时，通知快速响应人员监督到变更完毕，问题解决，关闭事件。这就是流程管理。


体悟之二：流程管理是目标管理风险的“晴雨表”；
        当流程管理遇到困扰时，就会有人不知不觉的讲，“以前一直是搞人性化管理，做的很好，现在把人困在流程上，太呆板、不灵活 。 ”其实我们恰恰忘了为什么要实施流程管理，忘掉了出发时的目标“控制目标管理的风险”，典型的在过程中迷失了出发时的目标。在不需要协作，且质量可预见的前提下，流程管理确实是没用。但往往我们做的是复杂的任务，需要很多的协作，且结果质量还不确定。为了保证目标达成，才选择的流程管理。
       目标管理是直接负责的管理员第一时间接受任务，处理问题。现在时快速响应（监控人员第一时间接受任务），问题专家研究方案，变更实施者实施方案。
       目标管理时，“问题分析工作”直接由管理员负责，现在由问题流程负责，理论上因为问题流程中的专家相对能力强，处理问题质量高 。虽然初次处理慢一些，但质量有保障，简单问题通过知识库处理反而快了，解放了能力强的人员低水平重复劳动。发展了分工，充分发挥资源优势，避免了资源浪费，提高资源利用率。
       如果事件和问题都是由同一个人担任。流程管理相比目标管理起了反效果。增加了流程工作量，同一人处理，质量监控点形同虚设。)
       变更流程处理在目标管理时，仅仅需要和主管沟通协商，现在需要和变更评审委员会沟通，沟通人员数量增加。增强了安全性同时不可避免的延长了时间。如果变更委员会成员太多，比如多于3人，沟通时间会更长。如果只有一人而且就是之前的主管，那么和以前一样 ，不一样的地方就是增加了额外流程工作量。
       变更实施如果是事件处理人员实施的话，那么有问题，他会在变更实施的时候降低实施质量，因为下一个流程是他自己管理。因为不需要再审阅实施内容，关闭工作单会掩盖实施的质量。
       变更实施人员如果是问题专家实施的话，实施过程有可能不按问题流程结果进行，问题流程的质量将得不到监督和控制。为了掩盖问题流程的错误，变更过程中的新的修改，虽然解决了问题，将不会被修改到以前的问题单子中，也不会在变更和配置中体现，因为会考核问题解决能力。
      少有人会说，“我发现一个我没有看到的问题，这是我犯的错误，但是我解决了，没什么影响，请大家放心使用。”绝大多数领导都会说，“再找找看。”——因为开始怀疑你的能力啦。问题很明白，而且被解决了，但至于是不是按问题方案做的，鬼知道，反正解决啦，下次再出同样问题，别人发现时已经晚了。这样，配置管理，文档管理，知识库管理全部收到了直接的影响。变成了不准确的内容。常此以往，流程还能正常运行吗？


体悟之三：“流程管理”中的“三权分立”；
       悟到这样一个道理，所有的流程经理都有管理流程质量的职能，但经理不可能面面俱到了每一个质量细节。因此肯定有没有查到的角落，角落里面往往就隐藏着魔鬼。质量管理岗位设置再多也不能根本解决质量问题。副作用就是成本急剧上升，而且你有100种检查方法 ，就会有101种规避检查的办法。一般工作流程管理不可能全覆盖的，普通工作一定是目标管理和流程管理相结合进行的，流程管理全覆盖只有航天之类最高安全、不计成本的工作才可能做到。
       要根治这个问题，只有从源头解决。
       “一次就把事情做对”，把“一次通过率”当成主要的考核指标才能节约质量管理成本。而且对于相连流程，下一道流程默认检查上一道流程的质量，一旦发现质量问题，“源头”工序以下相关工序按递减比例承担连带责任。“连带责任发生率”成为考核指标。最好的办法是先有规章制度形成企业文化，把质量观注入到公司员工的“血液”中。
       以前做什么，现在还做什么。以前服务质量以前是直接主管负责监督，流程管理实施之后有了专门经理监控，更多的可能是双重管理 。目的是什么呢？希望“质量可以预期”。
       质量监督的成本很大的。先假定人是自私的，在没有监控，检查的条件下，不能自我约束。这样资本拥有者为了资本的效益，雇职业经理人制定各种流程和规范来约束，以便生产出来的产品和服务质量是处于一个可以预见的范畴。这也是实施服务管理的目的。
鉴于服务管理的特点，ITIL最佳实践在理论上设置了一个相互制衡的组织结构。目前看来结构是没有发现弱点。刚才提到监督成本大，消减成本的办法就是使用流程制衡。
       事件流程，问题流程，变更流程，配置流程独立性是制衡的基础。实现流程制衡，需要流程配置专门的人员，而且人员在流程角色之间的重叠程度尽量满足没有衔接关系。
       往往单位里面实施流程一个目的就是为了“降低成本需要”，原来人力就显不足，还希望通过流程实施，把人员解放出来。对于人力资源按“目标管理”都不足的单位来说，人员增加是不可避免的。

体悟之四：妥协的流程管理——“捡芝麻丢西瓜”；

       在这个实际的案例中：组织为了节约人力，可能主观上是为了推动工作开展，让原来熟悉业务，原负责的人推动变更流程，结果变更经理直接由原来的组织负责担任，配置经理和问题经理直接受变更经理领导。
       变更经理实际就是原组织的领导，以前需要关注资源协调，客户沟通，还有问题的处理，还关注事件的响应，还负责所有数据中心管理。但往往对变更关注不够，批复不及时，跟踪不够，难以评估、审查完成情况。在这种情况下，配置管理根本不能制衡更变管理流程，经常性滞后。
       问题管理流程也糟糕，按说问题管理最容易做好。实际上，该案例中快速响应以前就是具体系统管理员（系统管理员、网络管理员、邮件管理员等），刚建立的专家组实际是原来的几个方面技术相对较好的主管。这些主管原来的工作继续保留。因问题分析需要经过长期的分析跟踪，研究过往历史记录，长时间的分析不可能，而这些新的问题专家各管一方，日常事务杂且多。过往记录、厂商资源、运维经验、系统的基本状况基本上都掌握在原来快速响应工程师手中，没有形成共享资源，这些人对系统最了解，但仅限于他们自己的大脑中。相反问题专家要是研究的话，反而延误时间，协调不力。何况还没有时间做这个事情。因此问题管理始终还是以快速响应工程师为主在做 ，那么效果不可能好，自然大打折扣。另外，问题管理流程刚出来的时候，大家一下子就觉得——好啊，把以前的历史问题，新发生的不加严格筛选的问题，一股脑全部推给问题流程，问题管理流程根本就没有力量来处理这么多问题，结果也是不了了之。不了了之的根本原因是没有人关注问题经理的考核。变更流程不要求问题流程，事件流程不升级到问题流程。所以问题流程在“众人合谋”中“瘫痪”。
       配置管理在系统宣导的时候，客户发现这太好了。可以把涉及系统的所有的参数都管理起来。但实际发现，CMDB付出的时间与管理详细程度成几何级关系。每多管一个配置项，将增加成倍的管理成本。尤其是经常变化的项，难以用流程控制的项。惠普的CMDB查看管理非常不方便，尤其是关联关系表现非常不好。而且真正需要管理的，比如系统的关键参数，配置文件，表现为管理不到位，经常性滞后 。客观原因是参数各系统差异性太大，就硬盘分区表示来说就好多种，比如Windows是一种，AIX是一种，Solaris又是一种。那么怎么办 ？使用文档附件，那么文档格式，及时更新，版本控制等等一系列的问题都需要大量的工作来做。主管原因是发现及时更新实在太困难 ，就放弃了配置管理中这个最有用的作用。因为变更不能正常进行，所以配置管理自动降低档次，只能做一个加强版的资产管理。配置的考核等等逐渐废弛，因为每次要核对配置管理都需要普查，难度越来越大，越来越难以准确。最后，配置管理没有了流程，仅保留配置经理一个岗位，同时兼任配置管理员，配置管理最终堕落为资产管理。

体悟之五：流程废弛的根本原因——**“变更经理”；

       流程管理是一个最佳实践，是和管理需要分不开的，流程管理是理想化的管理办法。  
       我们如何做适合自己的流程管理呢？任何单位都有这个需求，那么需要从目标管理过渡。流程管理的人员设置一定要符合权力制衡。
刚开始时，人员增加是可行的。因为你原来没有多余的人，坚决不建议**做流程关键点的控制，那样他们会有选择，有选择就不是流程管理，有选择就有“权力腐败”的可能。
       变更管理的权力大，危险性大。各组织默认的就是原来谁负责，现在谁还继续负责变更管理，忽略了其他流程所对应的制衡关系。原来变更对管理者来说是一个不受监督的权力，现在继续拥有这个权力。在没有好处的情况下受到了其他流程的监督。以最基本的常理逻辑来推断，变更经理会努力的推动流程良性执行吗？因为原来的方式已经习惯啦，习惯的力量有多大，没有人会反对吧？
       把原来的集中的总负责权力分开成配置经理、变更经理、问题经理，这样便于流程制衡。定义变更经理为纳入变更流程范围配置项的变更才需要进入变更流程，没有纳入流程管理的人事、工作分派、绩效考核等等原来怎么管还是怎么管。这样分解了原来总负责的工作内容，减轻了负担，“配置、变更、问题流程”各司其职，相互制衡。这才是服务管理的精髓。

体悟之六：剧终篇——人的问题选人来解决；
       服务管理实施就是服务业的ERP。一把手亲自负责，或者一把手指定专门的特派员负责，拒绝一把手挂名实际不参与开会。要求有一个就是能够协调流程涉及资源的人做项目总负责，最好是CIO。
       招聘或抽调普通员工，脱离原工作岗位做独立流程经理。原管理人员工工作能力强，现在还需要发挥重大作用，精英员工需要让他们有时间处理普通员工离岗后的工作空白。
岗位要求如下：
事件经理：平时婆婆妈妈，大事小事不分轻重，客户的事情放在心中的人即可；
配置经理：平时小心谨慎，管仓库的水平足够；
变更经理：不要独断魄力，喜欢推诿，不愿意承担责任。仅要求喜欢沟通，善于协调的人即满足；
问题经理：万事喜欢刨根问底的，情商不高的技术通就可以。
       当然啦，以上说明了部分特征，相信单位里面比这个条件优秀的人有的是。为什么这么讲呢？因为不管是什么单位，招聘人的时候总是要求说得“此人只应天上有，人间哪有几回闻”，既要出得厅堂，又要入得厨房，我出这个条件讽刺一下，不切实际的招聘内容。
       这些人有一个特点，就是会非常忠诚的执行新的流程，因为在这些流程中他们“对事不对人”，他们会客观的发现问题，解决问题。他们从没有任何地位获得一些提升，也算是一种激励认可，没有过往历史比较容易把流程执行得一丝不苟。
       这些人培训完毕之后，严格按照理论模型执行流程，哪怕是一个案例，他们都会非常认真。开始把公司的业务逐步的纳入流程，编入新的角色人手，逐步的把所有的流程涉及的配置项纳入CMDB，这样能确保流程发挥最大作用。原来公司肯定有人力资源管理这条线，逐步把原来管人的领导，纳入变更管理委员会，把技术能力好的精英纳入问题专家组，把技术一般的推向“快速响应”，建立知识库，提高一线事件解决率。
       当流程执行比较顺畅的时候，再决定是否把原来的比较优秀的管理者替换流程经理。如果一开始不下决心，那么习惯的力量会毁坏的流程最初的成长机会。最终流程会在妥协中成长为“四不像”，打破原来流程之间的“权力制衡”。就像案例中单位那样的结果。

E8.ITSM 天然支持精细化流程管理；强大的自定义流程引擎、可视化实施IT服务管理流程；灵活的自定义、参数化配置机制；零成本的管理改善和分支机构差异化管理。

顶起来。支持一下

自己顶一下