IT服务管理经典语录--上海翰纬--刘亿舟

IT服务管理经典语录--上海翰纬--刘亿舟

#亿舟语录#之 1： 信息化在给我们带来巨大的生产力提升的同时，也把我们引入到一个“唯技术论”的误区，即凡是遇到问题，首先想到的是如何从技术上加以解决。IT服务管理的 引入，开始逐步革新了大家的意识，将让我们认识到，搞好IT，不仅仅是从技术着手，而是需要同时从管理着手。管理也是第一生产力！

#亿舟语录#之2：信息化的本质是通过技术手段弱化或者消除信息不对称问题，信息化的结果则是实现了线下的工作线上化，信息传递容易化、信息共享便捷化，隐性的信息显性化。

#亿舟语录#之3：就IT服务管理的信息化而言，很多情况下，半自动化半手工化的解决方案也许比所谓的全自动化的解决方案更容易推行起来，也更容易见效。

#亿舟语录#之4：就IT服务管理而言，过分地追求信息化，意味着从心态上放弃从管理和配套规则上解决问题，这是很危险的。一味地寻求技术的解决方案，会让IT管理者走进技术的死胡同。当然从长远来看，能够通过技术解决的，应该尽量减少人工干预。技术上一小步，管理上一大步嘛。

#亿舟语录#之 5：管理大师亨利?明茨伯格说过，“未来的工厂只有两个雇员，一个人和一条狗。人负责喂狗，狗负责看住这个人不要去乱碰工厂的自动化生产线”。IT管理的 信息化理论上也应该是这样的,显然，现阶段是没有这个可能的。因此，只要有人的介入，就必须采用管理的思维，而不单纯是技术的套路。

#亿舟语录#之 6：有家制药厂经常发现有些包装好的药品是空盒子，于是试图通过技术手段解决这一问题。技术攻关小组尝试着对包装流线水线进行改进，花了很多钱但以失败告 终。而新来的主管在包装流水线边上架起一座电风扇就轻易将那些空盒子吹跑了。此事不知是真是假，但却很值得我们所有IT人员思考。

#亿舟语录#之 7：话说小小李小两口都是搞软件开发的也都很喜欢看书。小张（丈夫）提议开发一个小程序将所有的图书管理起来。小李表示赞同。于是夫妇俩决定将所有的 图书分成38大类、1236小类，并且买了买了很多书柜和标签。三年后你觉得会发生什么情况？启示：技术上能做到的我们就一定要做到吗？

#亿舟语录#之8：不考虑成本而一味地追求高技术解决方案，只能说明你是一位技术爱好者和技术发烧友，而不能说明你是一位合格的信息化的管理者。

#亿舟语录#之9：中国有很多技术管理者，但还远没有形成成熟的IT职业经理人群体。对技术和管理的深入理解和均衡驾驭是IT职业经理人走向成熟的体现。

#亿舟语录#之 10：对于IT管理者来说，管理和技术是他们看待问题的两个维度。在他们看来，技术是一项相对严谨而又简单的事情，而管理则是一项相对开放且复杂的事情。 因此，他们普遍认为，技术问题容易使得上劲，而管理问题很多时候使不上劲。对于中国的IT职

业经理人阶层而言，管理是一门必修课。

#亿舟语录#之 11：随着组织在信息化方面的投资不断增加，组织对IT服务管理提出了越来越高的要求，信息技术部门也需要逐步从“成本中心”向“利润中心”转化，如何 “像经营企业一样经营IT部门”是所有IT管理者必须要面对的课题。简言之，组织内部IT服务的商业化和市场化是一个不可逆转的趋势。

#亿舟语录#之 12：在IT服务领域，有三类公司：（1）卖人—“只唱戏、不搭台”，人才输出；（2）卖软件—“只搭台、不唱戏”，管理输出；（3）卖服务—“既搭台， 又唱戏”，价值输出。所有ITSP将来的方向必然是“既搭台，又唱戏”这样才能走出只收“卖人”的钱，却要对“卖服务”的结果负责的痛苦境地。

#亿舟语录#之13：卖服务就是卖保险！这是所有IT服务销售人员必须深入理解的一句话。中国IT服务外包商要着力提高服务的保障（Warranty）价值，获得甲方客户的信赖，才能从“卖人头”转变到“卖SLA”。

#亿舟语录#之 14：对于SI，我有一个新的解释，Service Integration（服务集成商）。对于选择多家IT服务外包商的甲方客户来说，各服务商技术上没有短板，但各家服务商之间存在诸多的“缝隙”。有效 地整合这些服务外包商的资源需要甲方自己或者服务总包商充当服务集成商（IT服务管理）的角色。

#亿舟语录#之 15：系统集成商向服务提供商实现战略转型的演进路径为：技术服务化（在提供技术产品的同时提供配套的增值服务）→服务产品化（基于服务目录和SLA的管 理实现服务契约化交付）→服务工程化（基于服务生命周期管理实现服务可大规模复制）。中国的IT服务商首先要实现的是服务产品化。

#亿舟语录#之16：乙方销售人员跟甲方领导谈的服务范围是A，合同里要求写明的是B，甲方IT用户要求的是C，乙方IT服务项目人员被要求做的是D，其实最后真正付费的服务范围是E，这就是中国IT服务外包市场的“韩乔生定律”。

#亿舟语录#之17：中国IT服务外包市场“韩乔生定律”现象背后折射的是，中国IT服务市场契约精神的缺失以及甲方客户对SLA的不信任，解决这一问题的根本在于乙方要建立完善的服务体系，实现“可预期、可承诺”的IT服务，而不是事前拍胸脯，事后拍脑袋，实在搞不定就拍屁股。

#亿舟语录#之 18：在中国IT服务外包行业，解决问题有两种方法:正法和“邪”法。所谓的最佳实践是正法，正法未必有用，但却是我们要努力的方向；“邪”法未必真邪， 这是“中国式管理”的需要。问题在于，以“邪”治“邪”多了，从短期来看是糊弄得过去，但从长期来看会陷入无序，市场发展也会碰到瓶颈。

#亿舟语录#之19：IT服务外包商在甲方客户处试图实施一个规范ITIL流程时，经常碰到这样的回答：你们别给我整这么多花里胡哨的，把服务做好就行了。可见，对于IT服务外包商来说，首先要做的是把自己打造成“音乐家”，其次是要把客户培养成“知音”，如此才能“琴瑟和谐”！

#亿舟语录#之 20：IT人员眼中业务部门有“五宗罪”：IT部门做了100件好事记不住，做了1件错事记得很清楚；认为“只有业务部门想不到的，没有IT部门做不到 的”；宁可浪费IT部门1个小时也不愿意浪费自己5分钟；认为流程是IT部门自己的事与自己无关；认为IT部门花了很多钱，却总是做不好事。

#亿舟语录#之21：业务人员眼中IT部门有“七宗罪”：花钱而不赚钱；态度生硬、冷淡、缺乏服务意识；没有明确的承诺，总是说“我尽快”、“我尽力”；自以为技术可以打天下，偏好技术，不懂业务还很“牛”；头痛医头，脚痛医脚；办事虎头蛇尾，“爱踢球”；加班还浪费电费。

#亿舟语录#之 22：国内有些IT经理告诉我，他们不得不故意“掐断”网络来证明他们存在的价值，否则业务部门和领导就会忘了他们的存在。这绝对是搞IT维护的悲剧！这 种状况表明，业务和管理层对于如何评价IT部门的价值是存在“价值观分裂”的：既要网络永不断线，又不能看到我们闲着，而这本身就是矛盾的。

#亿舟语录#之23：作为组织内部的IT部门，应当将业务部门视为我们的客户，客户就是我们的上帝，但我们需要学会为上帝立法！

#亿舟语录#之24：对于组织内部的IT部门来说，其定位应是双重的：服务+管理。光有服务意识强调服务职能还不行，还必须要通过建立一定的管理体系（话语权）对客户加以管理。过分地顺从和“溺爱”用户是一种“不作为”的表现，最终来看，业务和领导不会因为这点而高看IT部门。

#亿舟语录#之25：管理可以分为三种境界：“术”、“略”、“道”。“术”是操作层面的，“略”是方法论层面的，而“道”则是思想理念层面的。

#亿舟语录#之26：对于所有的技术专家来说，如何才能成功地转型为一位胜任的管理者呢？我的建议是，技术型管理者除了需要积累“术”方面的经验和功底之外，还应该多吸取一些“略”（方法论）方面的知识素养，在运用“略”的过程中实现“道”（理念和智慧）的修炼。

#亿舟语录#之27：如果说“术”是剑法，那么“略”就是心法，“道”则是“内功”。一位成功的IT管理者，应当加强IT管理理论方面的修养，并在此基础上结合自身的经验去推动实践的运用，并在此基础上修炼自己的“道”。

#亿舟语录#之28：在进行管理体系设计时，我们必须基于以下对“人”的假设：自私、惰性、惯性、忘性、易疲劳、情绪化。简单来说，在进行制度和流程设计阶段我们要假设人是不可被相信的，而在制度和流程执行阶段，我们又要假设人是可以被信任的。这是辨证的统一。

#亿舟语录#之 29：对于所有的管理者来说，都会面临两类因素：一类是可管理、可量化、可控制的因素；另一类是不可管理、不可量化、不可控制、不值得量化控制的因素。对 于前者，管理者应该尽可能采用制度化的管理手段，而对于后者需要通过建立组织文化来加以调节。组织文化是制度化管理不可缺少的补充。

#亿舟语录#之30：制度产生的是一种外驱力，具有立竿见影的效果，但制度必然会有照不到的暗角，从而导致“上有政策、下有对策”；文化是一种内驱力，一旦形成，具有很有的持久性和渗透性。对于IT服务组织而言，进行服务和流程文化建设是不可或缺的。

#亿舟语录#之31：对于所有的管理者来说，进行组织文化的建设绝不是一种盲目的“赶时髦、随大流”的行为，组织文化的建设是对制度建设的有效补充。通过组织文化的建设来弥补制度建设“鞭长莫及”的地方，不仅能够降低管理成本，而且能起到更好的效果。

#亿舟语录#之 32：我认为西方式的管理科学遵循两个基本逻辑：第一，“好记性不如烂笔头”。西方式管理强调文档、计划、记录的重要性，他们认为，“按照我所写的（计 划、制度）去做、按照你做的去写（记录）”是达到“可管理”状态的前提。第二，“用多拍几次脑袋代替拍一次脑袋”，尽可能精细化。

#亿舟语录#之33：一般来说，我们追求精细化管理，但在某个局部或者某个时间点上，我们未必需要追求绝对的精确化的管理，因为管理本身也是有成本的，不能把管理精细化的理念教条化。

#亿舟语录#之34：技术型人才的通常具有以下特点：具有强烈的技术情结；追求完美而无法忍受不确定性；过分关注小概率事件而不能从整体上考虑问题。当你和技术型人员讨论管理问题而无法达成一致时，给他们不断地灌输“以偏差代替无序”的思想。

#亿舟语录#之35：做管理和做技术本质上是不一样的，技术需要追求精确化，而管理只需要追求精细化。对于技术型人才向管理者转型时，通常不可避免会经历一段“思维冲突”的痛苦期和“自我洗脑”的思维转换期。

#亿舟语录#之36：从技术专家向管理者转型的五项基本修炼：习惯“以偏差代替无序”的管理智慧；“结构化思维、形象化表达”的文档能力；从证明自身的多能到证明自己的“无能”；从自身的完美执行到容忍下属的不完美执行；从管物到管人的转变：以人为本。

#亿舟语录#之 37：对于技术专家来说，一定要找到一个“万无一失”的解决方案才算是可行，而对于咨询顾问来说，一个好的管理方案也许只能解决95%的问题，另外5%只能留给“上帝”（或时间）去解决，这也是“以偏差代替无序”的管理智慧的运用。

#亿舟语录#之 38：ITSP应深入理解并与甲方达成以下IT服务质量观：（1）质量应具有持续性和一致性（Consistent）；（2）质量具有互动性：即质量是由甲方和乙方共同决定的；（3）质量具有相对性： IT服务质量是相对于SLA而言；（4）过程质量决定结果质量。

#亿舟语录#之 39：IT服务的无形性、不可封装性以及客户交互性决定了要提高服务质量，必须要建立良好的流程体系，而不能单纯地依靠对服务结果质量的定义，即必须通过提高过程质量来保证结果质量。

#亿舟语录#之40：“刘氏新木桶原理”：一个木桶所能装的水不仅仅取决于最短的那块板，更重要的是取决于板和板之间的缝隙。

#亿舟语录#之 41：新木桶原理对于IT服务管理的启示在于，仅仅关注IT服务人员个人的技术水平是不够的，如何确保IT服务团队之间无缝沟通和协作是非常关键的。从这个意义上来说，流程的价值在于有效地弥补了团队成员之间的“缝隙”。

#亿舟语录#之42：一群一流的工程师到了二流的企业，只能做出二流的服务，而一群二流的工程师到了一流的企业，却能做出一流的服务。一流的企业一定是建立了有效的管理体系来实现1+1＞2的效果。

#亿舟语录#之43：逆行超车是为了节省自己的时间，车流量小的时候通常是可以的，一旦车流量大，就会造成堵车，这样不仅不能节省自己的时间，还会浪费所有人的时间。不遵守既定的流程，也是这个道理。

#亿舟语录#之44：关于服务型团队协作的启示：团队协作需要规则；团队协作需要遵守规则；大规模、复杂的服务型项目更需要团队拥有并遵守共同的规则。

#亿舟语录#之 45：流程经理们最感到无奈的是：流程的执行者以其“不主动、不拒绝、不负责”的消极态度勉强应付着执行了流程，结果是可想而知的。而流程的执行者往往用这种“坏”的结果来向流程经理们“示威”：“我说在这里流程管理行不通吧？”。

#亿舟语录#之46：流程执行的质量会影响流程管理的效果，而流程管理的效果会强烈地影响整个团队对流程的认同，而流程执行的质量本身又取决于团队成员对流程的认同。于是，流程的推行往往会陷入“鸡生蛋、蛋生鸡”的悖论。因此，高层领导的支持是推行流程管理最强有力的支撑。

#亿舟语录#之47：在管理实践中，很多管理者往往习惯于采用以结果为导向的管理方式，而忽视流程规范。他们通常认为，采用流程化的管理方式把本来很简单的事情搞复杂了。事实上，对于管理方式的选择，并不能依赖于管理者自身的认识，而应当取决于管理对象本身的特征。

#亿舟语录#之48：如果管理对象满足以下四个条件，我们必须加强流程管理：1、无法直接通过结果约束到行为；2、从结果进行考核效果不佳或者结果测量（或测评）的成本太高；3、过程比较复杂、需要团队协作，且无法准确而方便地分解；4、可接受风险水平较低。

#亿舟语录#之49：关于流程的另类定义：流程是团队的游戏规则；流程是一堆人做事的协作机制；流程是一种预先设定的默契；流程是一种信息沟通机制；流程是一种执行力保障机制。

#亿舟语录#之50：流程管理的本质就是：用过程管理结果，用流程驱动人。这应当成为流程管理者的信仰，并尽可能成为整个团队的信仰！

#亿舟语录#之 51：很多人的潜意识中通常会默认一点，那就是流程重组后一定可以提高效率。而很多IT管理者在ITSM项目初期为了减少阻力，也会做出类似的暗示或者许 诺。而在新的流程推行之后很多人感觉“把简单的事情搞复杂了”，通常他们又会以新的流程导致

效率下降而拒绝执行。事实上这是一个很大的误区！

#亿舟语录#之 52：流程管理的目标是多元的，这些目标包括：效率、成本、质量、风险、合规性、客户体验等。也就是说，效率并不是流程管理追求的唯一的目标。而当流程的 执行者单纯从效率或局部的视角来看时，流程必然是有缺陷的。因此，不能因为流程降低了效率就认为流程是不好的就可以拒绝执行。

#亿舟语录#之53：即便是“绝对好的”流程从局部来看也未必一定可以提高效率，这取决于在这个局部的点上流程管理需要实现的首要目标是什么。因此，在推行ITSM项目时，有效管理各方在“效率”方面的期望是非常关键的。

#亿舟语录#之54：流程管理的要义在于：“不惜牺牲效率来保证质量、风险、合规等要求”、“不惜牺牲局部的灵活性来保证整体的统一性”、“不惜牺牲个人的效率来保证团队的效率”、“不惜牺牲当前的效率来保证长远的效率”。

#亿舟语录#之55：流程就是例行公事，“不怕一万，只怕万一”。因此，对于关键的操作，遵循既定的流程就是要牺牲9999次的效率来杜绝最后1次可能带来的风险。IT运维工程师们如果有这个认识，流程管理推行的难度将降低很多。

#亿舟语录#之 56：每个IT工程师都好比是一颗珍珠，而有效的流程就好比是一根华丽的绳子，可以将单个的珍珠串成珍珠项链，缺少了这根绳子，就只能是一盘散沙。

#亿舟语录#之57：流程建设的关键在于要在组织内培育流程文化。流程文化的核心在于，组织所有成员都能认可并不折不扣地执行既定的流程，而不是在自以为流程不合理的地方“自作聪明”地绕着流程走。

#亿舟语录#之58：推动流程文化形成的关键在于四点：1、高层认可并亲自推动；2、宣贯、宣贯、再宣贯！3、将流程执行情况与绩效考核挂钩；4、绝不姑息所谓的“善意”的流程违规者，并惩罚恶意的违规者。

#亿舟语录#之59：不同的岗位关注的焦点肯定是不一样的，因此流程管理得以有效推行的基础在于流程设计时需要充分考虑多方面的诉求，并在流程设计阶段尽可能让所有关键利益相关者参与讨论并相互“吵架”，事先达成妥协和一致。

#亿舟语录#之 60：很多人都存在这样的“人格分裂”：开车的时候讨厌别人乱穿马路，而不开车的时候又随意乱穿马路。在整个团队缺少超脱的认同感和公共理性的情况下，流 程机制很难推行下去。用局部利益代替公共理性的结果就是：大家不愿意为了整体利益最大化而做出妥协，从而最终导致“囚徒的困境”。

#亿舟语录#之61：执行力= 领导力（目标明确+质量要求+资源保障+执行力机制+组织文化）+被领导力（理解认同+合作精神+必备技能）。一句话，执行力不完全取决于被领导力，同时也取决于领导力。当我们要求下属的执行力时，先自检自身的领导力。

#亿舟语录#之62：流程设计时需要遵守的八项基本原则：可定义、可复制、可理解、可执

行、可计量、可改进、可追溯、可审计。

#亿舟语录#之63：“刘氏IT服务成熟度模型”：对于大部分的甲方内部IT运维部门来说，可以参照以下五个级别的成熟度去评估和规划其IT服务管理发展路径：1、无序的被动服务；

2、有序的被动服务；3、主动的预防性服务；4、可预期可承诺的服务；5、可财务计量的服务。

#亿舟语录#之 64：就IT服务管理而言，从用户满意度的角度来看，充分认识到以下三点是至关重要的：1、用户没有义务判断该找谁；2、用户怕的不是等待，而是处理过程 完全不透明情况下的焦急的等待；3、用户能够容忍技术上有难度而需要耗时较多，但无法容忍故障的解决时间只有3分钟，却等了3天。

#亿舟语录#之 65：在流程建设中下定义是一件看上去简单实则挺难的事情，定义不清则执行时会产生很多分歧。我推荐用用以下组合性的“下定义”的方法：1、描述法：通过 一段话概括性地对所要界定的“对象”进行描述性说明；2、列举法：采用穷举的方式进行举例，列举法又可以分为正向列举法和反向列举法。

#亿舟语录#之 66：绩效考核的基础是数据，而数据又可以分为结果测量数据和过程统计数据，如果是一项绩效考核不能完全通过结果测量数据实现，那么就需要进行过程数据的 采集。过程统计数据的采集，关键在于流程的设计，而流程设计的关键又在于表单的设计。表单设计直接决定了可获得的过程统计数据。

#亿舟语录#之67：表单的设计需要遵循以下原则：1、标准化原则（尽可能做选择题，实在不行，也应当给出填写规范和模板）；2、从管理需求出发原则（每一个字段都对应着管理需求）；3、成本效益原则；4、可归责原则；5、可执行原则。

#亿舟语录#之68：IT服务管理实施过程中会涉及各种分类，我总结的分类的基本原则是：1、从管理需求出发；2、完备性原则；3、互斥性原则；4、颗粒度适中原则；5、分层原则。

#亿舟语录#之69：ITSM与ITIL的关系：ITSM是目标，而ITIL只是手段之一。不能为了实施ITIL而实施ITIL，实现卓越的IT服务管理，需要IT管理者在人、流程、技术三方面设计可执行的管理体系方案，否则，不会取得好的效果。

#亿舟语录#之70：I IT服务管理的“六脉神剑”：1、团队思想统一；2、领导重视与参与；3、流程量身定做；4、执行量化考核；5、适当选用平台；6、持续改进优化。

#亿舟语录#之 71：ITIL中明确区分了用户（User）和客户（Customer）的区别，其中用户是指IT服务的最终使用者，而客户是指为服务付费的组织或者人， 用户提出的只是其个人角度的要求，而客户则要代表某个用户群体的有效需求。同一个组织或部门作为“客户”代表的只能有一个，而用户则可以有很多个。

#亿舟语录#之72：项目实践中，我们经常被迫跟着用户的“要求”而不是客户的“需求”在交付项目（产品或服务）。控制项目的风险关键在于区分谁是客户、谁是用户。遵照“客户”的需求、而不是听从“用户”的要求是项目经理需要掌握的第一要领。

#亿舟语录#之 73：从流程管理的角度来看，我们认为用户提出的是请求（request），而客户提出的是需求（Requirement）。ITIL V2服务支持（Service Support）流程组主要面向用户，负责受理用户的请求；而服务交付（Service Delivery）流程组主要是面向客户，负责管理客户的需求。

#亿舟语录#之 74：七句话帮你理解ITIL：ITIL是一套流程管理最佳实践指南；ITIL是一套IT服务质量控制体系；ITIL是一套IT服务风险控制体 系；ITIL是IT服务专业人士的“五线谱”；ITIL是IT服务管理者进行“流程架构设计的脚本”；ITIL是IT服务工程师的“通用语法”；ITIL 是IT服务领域的国际“工业标准”。

#亿舟语录#之75：ITIL就是众多方法论中的一种，理论上来说，它适用于各种IT服务组织。但当我们在具体实践时，就会碰到很多现实的困难。在实施ITIL时，需要根据组织的规模、人员结构、用户成熟度、IT管理目标等要素做出适当的裁剪。

#亿舟语录#之76：ITIL V2最大的价值体现在，帮助IT部门内部建立了一套“以流程为中心”的管理规范，但在实现“以业务为导向”的IT服务价值链体系方面缺乏指导。换言之，ITIL V2关注的是流程。而ITIL V3则强调服务要以业务为导向——“在你思考如何做之前，先停下来想想为什么要做”。

#亿舟语录#之77：ITIL V2的六大核心模块，用打麻将的说法就是：“东风”（ICT基础架构管理）、“南风”（应用管理）、“西风”（业务视角）、“北风”（服务管理实施规划）、“红中”（服务管理）、“发财”（安全管理）。

#亿舟语录#之 78：ITIL V2倡导的流程管理最佳实践消除了“职能式”管理模式下的职能“竖井”，促进了部门之间的流程化运作。但随着ITIL V2的深入运用，人们逐渐发现，基于ITIL V2的流程实践又产生了新的流程“竖井”，即流程与流程之间缺乏一套有效的核心逻辑来进行整合，ITIL V3弥补了这一缺陷。

#亿舟语录#之 79：如果说ITIL V2帮助我们实现了Managed Service，那么ITIL V3则有助于我们实现Designed Service。Managed Service意味着服务的交付是基于某一套标准的流程体系，如ITIL、ISO200000；而Designed Service意味着相比于Managed Service而言，更加注重强调围绕客户需求设计服务。

#亿舟语录#之 80：ITIL只不过是一个最佳实践的“工具箱”，IT组织完全可以根据自身的实际需要挑选必要和合适的流程进行实施。对于中国用户来说，我们通常推荐从 梳理事件管理和变更管理流程入手，这样可以快速地将组织从无序的被动维护转变为有序的被动维护。然后在此基础上扩展其他流程。

#亿舟语录#之81：ITIL实施的七大误区：1、ITSM＝ITIL；2、实施ITIL＝实施所有的ITIL流程；

3、全自动全集成才是最好的；4、当成一个IT部门内部的项目而不是作为公司层面的业务流程重组，未能争取到高层领导的支持，在IT部门内部“自娱自乐”；

#亿舟语录#之81（续）：ITIL实施的七大误区：5、忽略人的因素，相信“技术可以固化流程从而带来执行力”；6、项目野心勃勃，不能“沿途下蛋”；7、默认流程一定可以提高效率，

所以当流程局部地导致效率下降时，就会遭遇抵制，从而使辛辛苦苦建立的流程毁于一旦。

#亿舟语录#之 82：ITIL实施落地可以从三个方面进行：1、理念落地（将ITIL理念融入日常行为）；2、规则落地（制定制度性规范）；3、工具落地（将ITIL的 流程逻辑固化在软件平台上）。ITIL本身只是一套管理体系框架，并不是软件架构设计的脚本。因此，未必所有的ITIL流程都能够或都需要通过软件落地。

#亿舟语录#之83：ITIL软件实施的本质是实现IT部门的信息化。但ITIL软件实施绝对不是一个“交钥匙”工程，而是一个“技术+管理”的综合性解决方案。光有技术平台，缺少了配套的规则定义、角色定义、人员培训、审计监督和绩效考核，ITIL软件基本上无法用起来。

#亿舟语录#之84：什么叫解决方案？理论界和实践领域都没有确切的定义，就IT服务管理软件实施而言，我的理解是：解决方案= 软件平台+实施方案+配套的管理规则+培训与推广方案。

#亿舟语录#之85：针对ITIL V3在国内的实施，我有如下建议：1、带着ITIL V3的视角去实施ITIL V2；2、一次规划、分步实施；3、按需取用，无需追求大而全；4、不要过份依赖工具、加强配套的管理规则与人员意识培训；5、争取高层领导的支持。

#亿舟语录#之86：科学有效的ITSM项目实施过程必须至少包括以下六个环节：理念导入、现状评估、流程设计、工具实施、上线推广、持续改进。

#亿舟语录#之87：ITIL所引入的分级支持体系，相当于将IT组织从原来单纯“横向分工”（按职能分工）转变成“纵向分工”（按“流水线”分工）和横向分工相结合的矩阵式架构，即避免了“用大炮去打蚊子”的资源浪费，也保证了统一的跟踪和监控。

#亿舟语录#之 88：针对IT服务的管理，我们至少应设立四种角色分别从四个维度进行管理：

1、Product Manager（管理产品生命周期）；2、Process Manager（管理流程的运营效率和效果）；3、Account Manager（管理客户的需求以及相应的SLA）；4、System Manager（从技术的角度对IT组件进行技术维护）。

#亿舟语录#之89：职能（Function）是流程（Process）有效运行的重要保证基础，它为流程的流转提供必要的支持。区分流程和职能有一个非常便捷的方式，即职能通常可以在组织架构内找到对应的人员或者部门，而流程通常需要跨团队或者跨部门运作。

#亿舟语录#之 90：按照ITIL V3的理论，实现优秀的IT服务管理需要“能力”和“资源”两个关键要素。中国有句谚语叫做“巧妇难为无米之炊”，在这里，“米”属于“资源”，而“巧 妇”具备的是一种“能力”。没有米，巧妇很难做出香喷喷的米饭，而光有米，而缺少了巧妇，同样做不出香喷喷的米饭。

#亿舟语录#之 91：服务台运作模式的实质在于：1、知识前移和运维前移；2、将传统的横向分工拓展为纵向分工和横向分工相结合的模式；3、服务台作为一线支持实现了云 服务；

4、将原来“既当爹又当妈”的工程师从琐碎的沟通性工作中解脱出来专注于技术的处理；5、通过改变用户习惯而提高总体效率。

#亿舟语录#之92：典型的服务台结构有三种：集中式、分布式和虚拟式。在选择服务结构时需要考虑以下几个因素：1、最终用户的地域分布；2、各地用户请求的数量3、各地应用的同质性；4、服务台人力资源情况；5、语言和工作时段等个性化需求。

#亿舟语录#之 93：适宜建立服务台的基础条件：1、相对海量的终端用户（500人以上）；2、相对海量的故障请求和服务请求（日均100单以上）；3、用户地理位置较 为分散；4、用户请求同质性、重复性较高；5、经常出现丢单、串单等缺乏跟踪的情形；6、用户找不到正确的人，经常遭遇“踢球”的情形。

#亿舟语录#之94：服务台推广初期很容易出现用户绕过服务台的情形，我推荐以下解决办法：1、多途径立体式宣传；2、改善服务台的专业形象和服务意识；3、提高服务台解决故障的能力；4、基于服务台登记的工单对工程师进行考核；5、对用户进行培训和期望管理。

#亿舟语录#之 95：在ITIL V2中，服务请求被当作一类特殊的故障（Incident）而通过故障管理流程进行处理。而在ITIL V3中，服务请求通过请求履行流程单独进行处理。区分服务请求与故障有一个很简便的判定原则，即故障通常是一个意外的事件，而服务请求常常是能够事先定义 其操作路径和步骤的。

#亿舟语录#之96：有效地实施故障管理和服务请求履行流程，能够将IT组织的IT服务从“无序的被动维护”提升至“有序的被动维护”，但仍然没有实现“预防性的主动维护”，问题管理和配置管理的引入有助于实现这个目标。

#亿舟语录#之 97：ITIL流程成功实施需要抓住7个关键点：1、表单设计（决定能获取的信息）；2、角色定义与映射（决定流程的执行力）；3、判据规则（分类的判断 依据）；4、输入定义（触发条件及规格要求）；5、输出定义（KPI指标及规格要求）；6、工具实施（标准化、模板化、电子化）；7、培训与推广。

#亿舟语录#之98：表单是支撑流程有效运转起来的前提。表单设计的基本原则是：“能做选择题，就不要做填空题；能做填空题就不要做论述题；实在万不得已必须做论述题时，也应当定义论述题答案的模版和答题规范”。这样可以确保表单记录的标准化，并可增强表单的可统计性以及执行力。

#亿舟语录#之 99：故障管理在实践中最常见的问题有两个：不填单或者填写不符合要求（如在“解决方案”一栏中填写“已解决”敷衍了事）。这两个问题都无法通过软件来解 决，而必须辅之以管理手段。针对前者，需要明确定义故障的范围并纳入绩效考核；针对后者，需要制定细化的故障单填写规范同时加强审计。

#亿舟语录#之100：在实际工作中，很多人经常将“故障”与“问题”这两个概念混淆。事实上，故障和问题是看待同一件“事情”的两个不同的视角：故障是从“治标”的角度进行处理，确保“当前的”业务影响最小化，而问题则是从“治本”的角度进行处理，确保“长远的”业务影响最小化。

#亿舟语录#之 101：问题管理实施成功的关键在于解决好问题单的提交和创建。解决的办法

有两个：1、通过在故障管理流程中设定一系列的规则（“六个凡是”）而触发问题 分析线索；

2、通过设立“问题主动排查率”指标对问题经理强化考核，而促进主动性问题管理（“四个基于”）机制发挥作用。

#亿舟语录#之 102：知识库的构建和运营过程中必须要解决好以下三个问题：1、录入者和使用者的积极性问题；2、知识库搜索效率和定位准确性问题；3、知识库的及时更 新和质量保证问题。由于这三个问题没有有效地解决，很多IT知识库都经历了这样一个过程：积累期、推广期、享受期、苦恼期、颓废期、废止期。

#亿舟语录#之 103：变更管理、资产与配置管理以及发布与部署管理之间形成的是一个“铁三角”关系。这三者的关系有点类似于财务经理、出纳和会计这三个角色之间的关 系：变更经理（相当于财务经理）负责“权”，发布与部署管理（相当于出纳）负责“钱”，而资产与配置管理（相当于会计）负责“账”。

#亿舟语录#之 104：充分理解变更管理和发布管理的界限，有助于划分开发团队和维护团队之间的职责划分。从逻辑上来讲，IT生产环境的Owner应该是负责维护的团队 （开发部门也可能有维护团队），也就是说，对IT生产环境的变更控制应该由维护团队主导，而开发团队应当是充当发布实施的角色。

#亿舟语录#之105：变更管理是IT生产环境的“海关”，其使命在于确保IT生产环境的变更没有“偷渡者”和“走私犯”。有些开发团队或者开发人员，在没有通过变更流程的情况下对生产环境所做的各种操作其实就是一种“偷渡”行为。

#亿舟语录#之 106：有些公司在实施变更管理和发布管理时，将两者视为并行的两个流程，即变更管理负责处理基础架构硬件的变更，而发布管理则负责处理软件相关的变更。 从ITIL的角度来看，这是一种误解。变更管理侧重于审批、控制和协调，而发布管理侧重于实施和部署，发布管理应处于变更管理的控制之下。

#亿舟语录#之 107：发布的实施过程本质上是一个项目实施过程，因此对于大型的发布实施项目，运用项目管理的方法是可行的。ITIL的发布管理的核心目标是对发布实施 过程进行标准化和规范化控制，以确保每一个发布都遵循了标准的流程规范、实现了全面而顺畅的沟通、保持了良好的书面文档记录。

#亿舟语录#之108：由于每一个发布在规模、时间跨度、复杂度、测试要求、影响范围等方面都存在差异，因此，很难实施一套标准化的流程平台跟踪和管理不同类型的发布。因此，发布管理在实施落地时，通常并不单独实施一套软件平台，而是与变更管理结合起来实施。

#亿舟语录#之109：发布与部署管理在实施中通常通过以下两种方式落地：1、制定保障发布实施的制度性规范，以确保发布执行过程遵循标准的程序并维持必要的文档记录；2、在变更管理软件平台中创建一系列的任务项（Task）以跟踪和控制发布任务的执行。

#亿舟语录#之 110：CMDB是IT部门的“技术地图”，有效运作的CMDB可以实现几方面的价值：1、实现快速的故障诊断；2、准确地评估变更的影响；3、削弱人员 流动给IT运维所带来的风险；4、通过建立有效的IT资产台帐提高年度资产审计的效率；5、为实现主动

性、预防性维护提供基础。

#亿舟语录#之111：在进行CMDB建设时，识别CI的基本原则应包括：1、从管理需求出发；

2、颗粒度适中原则；3、可维护、可更新、可操作、可管理、可审计原则；4、“适当超前、够用就好”原则；5、成本效益原则。

#亿舟语录#之 112：CMDB实施咨询的核心是“六定”：1、定目标（CMDB要实现的管理目标）；2、定范围（纳入管控的IT资产的范围）；3、定颗粒度（纳入管控 的IT资产的颗粒度大小）；4、定属性（各种CI类别对应的属性字段）；5、定关系（CI之间的关系类型及含义）；

6、定流程规范（维护规范、角色与职 责）。

#亿舟语录#之113：对于CMDB的建设来说，“超前三年是前瞻、超前五年是找死、超前八年是犯罪”。过份超前有时候反而使项目陷入“植物人”状态。结合组织的需求、人员成熟度、组织文化做出适当超前的规划是保障CMDB项目成功的关键。

#亿舟语录#之 114：如何确保CMDB保持更新是确保CMDB项目最终成功的关键。要保证CMDB更新，全部依赖自动化工具是不可能的。通常可以采纳三种手段：1、自 动扫描工具；

2、由变更管理触发《配置修改通知单》；3、在变更关闭之前点击“更新CMDB”按钮，将CMDB数据调出并直接由变更审实施人员修改。

#亿舟语录#之115：没有纳入变更控制的CMDB，就好比失去了财务控制的会计核算，这样的财务核算数据你敢相信吗？CMDB需要更新的源头在于变更，因此，无论采用哪种更新机制，CMDB都必须纳入变更控制。

#亿舟语录#之 116：服务级别管理过程应该涵盖以下六个阶段：1、需求识别与确认；2、服务设计与签约；3、服务实施与交付；4、服务响应与支持；5、服务计量与报 告；6、服务评审与改进。仅就响应时间、解决时间等指标进行了约定并不能视为实施了服务级别管理，服务级别管理应是一个服务生命周期的概念。

#亿舟语录#之 117：服务级别管理在落地实施时，难点有四个：1、标的物（即服务内容）的定义和识别（结合服务目录梳理进行）；2、客户的识别（谁能代表服务的甲 方）；3、服务级别的约定（可以用绝对数和相对数相结合、定性和定量相结合的办法）；4、SLA如何分解为OLA和SLA（关键在于建立关联）。

#亿舟语录#之118：实践中，很多组织的SLA对于服务内容和范围的约定相当模糊。从而经常导致实际服务交付范围失控。服务内容和服务范围的约定可以采用描述法和列举法（包括正向列举和反向列举）相结合的方法。同时，需要针对服务范围的变更建立变更管理机制。

#亿舟语录#之119：IT服务财务管理体系由以下五大体系构成：1、IT财务预算管理体系；2、IT服务成本核算体系；3、IT服务计费体系；4、IT服务财务报表体系；5、基于平衡计分卡的IT服务绩效评价体系。

#亿舟语录#之120：IT服务预算制定的基本原则：1、以量定额；2、子项汇总；3、全面细化；4、口径一致。

#亿舟语录#之121：IT服务预算科目体系设计应遵循的基本原则：1、从管理需求出发；2、

2、颗粒度适中；3、成本效益原则；4、与IT成本核算相匹配。

#亿舟语录#之122：IT服务预算制定的基本步骤：1、确定IT预算的范围；2、设计IT服务预算科目体系及预算模板；3、估算工作量或资源用量及单价；4、计算单项预算金额；5、汇总IT服务预算；6、与相关部门就IT预算进行谈判；7、IT服务预算调整；8、IT服务预算的审批；9、IT服务预算的发布。

#亿舟语录#之123：建立内部IT服务计费体系必须具备三个条件：1、高层领导高度重视并亲自推动；2、服务计费项目及计费标准已和客户达成一致；3、具备相应的技术手段统计服务的实际用量。