ISO20000广破论（3）
学习资料：IT运维管理社区专家讲堂直播300期视频回放ISO20000广破论（3）
体系规划
管理体系（下略为体系）是指一组相关联的流程的综合体，是指管理制度的总和，是指导、规范业务如何运作的方法，一、二、三、四级程序文件是体系的载体，业务是体系的受体，人员、资金、订单、合同、设备是体系的输入，资金与作业记录是体系的输出，体系描述了一个组织如何运作、如何管理，小的说它像是一个机器的操作说明书，大的说它是一个国家的律法，成立ISO20000的主要目的就是设计出一个更效率、科学、合理、标准的体系，并且它符合ISO20000国际标准的所有技术规格要求。
谈到体系规划，首先脑子中要清楚的知道这是针对管理体系的规划设计，它可以是一个很宏大的工程，也可以是渺小的工作，这取决于你对体系规划这一概念的理解与你对目标的设定，如果你真的把这个当成是这个组织一次重生的难得时刻，那么你会珍视这个机会，为这家公司，也为你个人，因为很少有机会让我们去全面而深入的去理解组织的运作，而且给你个人一次利用你的管理理念去体系重构的机会，你会发现许多流程、表单的原来并没有经过深思熟虑，一个组织的运作原来可以不需要一个全能的控制者，哪怕它带有这么多的缺点与病态，组织的存在与扩散特征与生命体有非常的相似，它不需要什么目标，只是运作。你会发现原来一个这么重要的流程，它的产生是带有很大的不合理性，许多管理者做的工作或报表，原来都是经不起推敲的，深入的了解分析，去拷问背后的为什么，你会发现人类的所有的荒唐，就如你没想到运载火箭尺寸居然与马屁股的尺寸有很大关系一样。但是如果你仅仅把这个当成一个任务，也会变得很简单，把现有的流程表单收集收集，缺哪一些流程就找别的公司的文件改一下LOGO，修修补补就发行了，也不会有什么大问题的完成任务，虽然那其实不是体系，那套文件到底在说什么也没有一个人真正清楚，但这是绝大多类似项目的现状，这也是绝大多数公司的现状。在看过许多的公司后，有时真想武断的说，中国没有真正的管理，我们是如此缺乏严谨认真的人，我们是如此充满自认聪明的灵活，我们最强调天下为先，但是我们却最缺乏集体主义，我们叫得最多的是守信用，我们却最没有契约精神，企业中那些最强调管理制度的管理者，往往是最大的制度破坏者，管理制度在他们看来是适用于下属的约束与规范，仿佛他是一个超然的存在者。细细探究这些背后的根源问题，你能看到中国过去几千的王朝的一些根本问题，而到了我敲着电脑键盘打字的现在，根本性的问题依然没有得到解决，大到国家小到公司均是如此。
前面强调的是重视而且严肃对待体系规划，除此之外要有大胆开放性的审视精神，我们对未知的东西总是充满恐惧，当有一个流程被一大群人执行了很久后，现在给你一个机会去修改这个流程，大多数人会像是一个不懂电的人面临一大堆电闸线路一样不敢伸手，因为担心引发大规模骚乱，因为内心缺乏勇气与认知。事实上我们的脚步真的可以迈大一些，我们担心流程调整引发的问题并不如我们想象的严重，大家容易高估人们的自律与智慧，却也容易低估人们的适应调整能力，只要我们想清楚每一个步骤与落实的应变方法，在一个比较短的时间内，你会发现规律开始在形成。在我们审视、调整流程时，一定要清零的进行思考分析，我们容易掉入过去的认知，要当自已是一个看一个新的公司的流程，不断的弄清楚每一个步骤为什么做，为什么这样做，为什么是这个角色做，为什么在这个阶段做，弄清楚作业的逻辑非常重要，在不带倾向性的不断深入，最终我们会找出许多貌似很应该的流程、审批动作、作业动作其实毫无意义，只是人们认为应该如此所以一直如此。
体系设计
体系的范围
要规划一个体系，首先要确定体系的范围，就如做一个信息系统，你要确定它的功能范围一样。体系的范围可以从几个视角进行考虑
地理范围
ISO20000这种认证要确定场地，比如一个公司在多个国家有业务点，或者在一个国家的多个城市有业务点，或者在一个城市的多个地点有业务点，这时ISO20000就需要确定你的认证范围，也就是哪几个地点业务点。地理范围的多少跟体系的设计有比较大的关系，地理范围越大，体系设计越复杂。
业务范围
ISO20000是一个信息技术服务标准，它的重心落在服务上，而不是信息技术上，所以到底你的体系是面向哪几种服务的很重要。这里的说的服务就是服务产品，比如一个公司如果提供桌面终端服务与网络维护服务，到底是哪一种服务来做认证？在体系设计时，我们是覆盖到两种服务还是一种服务，这种基本的问题一定要界定很清楚，业务范围越大，体系设计越复杂
部门范围
体系规划设计时，要考虑日后体系应用于公司内的哪一些部门，是全部的部门还是部份的部门，要根据公司的组织架构进行圈定，部门范围越大，体系设计就越复杂。
客户范围
服务商面临是多个客户，多个合同，在ISO20000认证前要确定到底哪一些客户哪一些合同是认证审查的范围。体系设计时同样如此，要考虑体系覆盖到哪一些合同（项目），客户越多、合同越多，体系设计就越复杂。
体系的范围需要多以上多个角度进行考虑，这些最基本的问题一开始前必须进行清楚的定义回答，因为它会全方位的影响体系设计与整个项目的所有作业、计划、体制等等。体系越统一越好，越少越好，最好一个公司只有一个体系的存在，它适用于所有的地理范围、所有的业务范围、所有的部门范围，所有的客户范围，这样框架上会非常全面与统一。
体系的单元确定了体系的范围后，即体系的外围有多大后，要考虑体系的内部是怎样的组成，即，也就是一个体系由哪一些流程组成，要把体系分解成一个个子单元，体系的核心单元（体系单元）是什么，当体系的框架非常全面时，就会带来一个适用性的问题，因为越通用的东西，越不具备具体约束力，它容易牺牲对象的特性，引发质量问题，比如事件流程，广州市政府的市长的一台笔记本电脑坏了，跟联想的SAP软件出现BUG了，这都是我们的客户，我们要进行事件处理，这是用同一个流程管理吗？客户不同，对象不象、客户的级别也不同，性质也不同，是直接按客户拆分成不同的事件流程？还是同一个事件流程，再在流程下面根据不同点做指引文件？，这时确定每一个体系单元就非常重要，要把握好其中的平衡，通用而不具执行意义，体系本身就失去了意义，一个体系一旦分裂过多的流程，或流程分裂成过多的子流程，最后会导致体系庞杂，失去重心同时无法维护，最终失去了体系本身这一个问题。ISO20000标准帮助我们解决了一部份问题，即它已经对一个服务管理体系做了最粗的解构，第一层的分解基本如下：
(一)业务规划管理：标准3.1、标准4.1
(二)管理评审管理：标准3.1
(三)文件管理：标准3.2
(四)培训管理：标准3.3
(五)绩效管理：标准3.3
(六)服务设计管理：标准4.2、标准5
(七)内部审核管理：标准4.3
(八)服务改进管理：标准4.4
(九)服务级别管理：标准6.1
(十)服务报告管理：标准6.2
(十一)可用性管理：标准6.3
(十二)持续性管理：标准6.3
(十三)财务管理：标准6.4
(十四)能力管理：标准6.5
(十五)信息安全管理：标准6.6
(十六)客户关系管理：标准7.2
(十七)供应商管理：标准7.3
(十八)事件管理：标准8.2
(十九)问题管理：标准8.3
(二十)配置管理：标准9.1
(二十一)
变更管理：标准9.2
(二十二)
发布管理：标准10
注：具体每个子程序的说明见第4章的流程解释。
上面的切割可能是不够的，也可能是需要再进行组合的，要根据组织的情况进行瓦解，如果一个流程会进行再分裂，需要全部进行边界定义，也就是最终我们需要得到所有二级文件有多少，三级文件有多少的一个树状目录，每一份文件的适用范围与基本内容需要进界定说明，做一次严格的评审，这一步非常关键，它相当于一个程序要进行开发，需要定义出它的模块有多少，每一个模块有哪一些功能，这就是最基本的规划设计。
业务的单元
如果我们得到一个体系规划，要继续要问一个问题，执行每一个体系单元的业务单元是什么，也就是最小的执行体系单元的业务单位是什么，这一个回答会全方面的影响流程设计、执行。仅仅说是一个公司，或一个部门很可能是不对的，因为ISO20000是以服务为主线的，服务与公司或部门很可能不是整数的换算关系，而且所有的执行记录、统计分析、绩效计算只到部门层面是不够的，用具体的例子来说明可能容易理解一些，比如能力计划、监视计划、备份计划是以部门为单位吗？财务的预算分解到部门吗？成本分析是针对部门的吗？服务级别协议是针对部门的吗？所有的报告的统计的是针对部门级的吗？所有的内部审查是针对部门的吗？结合ISO20000的标准，我们会发现服务的视角很有可能与行政的视角有着很大的区别，ISO20000的以服务级别协议驱动的，或者说以服务合同驱动的，所有的一切作业与管控均以服务为主线，在现实中我们行政单位的设立多是以职能性划分的，而服务往往是跨职能的，除非一个服务完全可以封装在一个业务部门内部，否则以部门为单元的模式必须会遇到体系的基本逻辑问题，因为大部份的计划、记录、报表、绩效均是要以服务进行集合的，服务管理就意味着我们要以服务的视角进行管理。
每一个服务合同可以视为一个项目，项目才是执行体系单元的业务单元，当我们知道每一个项目的作业情况，理论上我们应该知道每一个业务部门的情况与每一个客户的服务情况，它是一个最小的业务单元，根据这个最小的单位可以计算其它单位的信息，这样既可以从根本上提供端对端的服务，才能让服务效能最大化，才能可能真正做到以客户为中心，才能真正的实现流程化管理，才能实现真正的全生命周期的服务管理。想象一下，当每一个项目的商业合同、执行计划、作业体制、作业记录、服务报告、服务绩效、服务流程、预算与成本核算等等这些都是清楚的，我们的服务管理是怎样的局面？。按这样的思种，我们会形成一个体系的矩阵结构：
所以最后体系的范围到底多大，可以直接体现在项目的多少上，而项目的范围，又包含客户范围的属性、部门范围的、服务产品范围的属性、地理范围的属性。
4)体系的接口
当依照ISO20000标准建立的体系只是一个组织的一部份规程时，就面临一个问题，即体系融合的问题，一个服务产品系列比较全面的IT服务商容易面临以下四种体系并存在情况：
ISO9000
ISO20000
CMMI
ISO27001
可能体系的种类实际情况还会更多，此时整合的复杂度就很大，每个体系事实上有关联，而且存在重叠，比如ISO9000的供应商管理与ISO20000的供应商管理，CMMI的配置、变更管理与ISO2000配置、变更管理，ISO27001与ISO20000的信息安全管理等等，这四种体系每一个彼此都存在关联或重叠关系，每一种体系的根本视角与出发点是有不同的，当多个体系并行在一个组织时是必然引发执行层面的问题的。从理论而言，应该全部融合成一个视角统一而又满足几种不同标准要求的体系，但其中光是理论问题就非常复杂了，这种理论很难想象是一个不以管理标准研究的主业的普通IT服务商能解决的，这一个问题最应该的解决者是ISO这种国际标准化组织，其次应该是那些咨询公司，但是这些组织更多中负责生产不负责整合。
在IT服务商无法独力解决的此问题情况是，建议的方式是把一些关联性较强的流程做融合或接口，比如ISO9000也要求内审与管理评审，ISO20000亦是如此，这样可以考虑直接采用现有的流程，进行标准结合修订即可，还有一些已有的类似培训管理、绩效管理之类的都可以利用现在的进行梳理。CMMI的变更管理与配置管理跟ISO20000的变更、发布、配置这些关系涉及到更具体的操作层面，需要进行专题研究，结合公司的情况，要么接口，要么融合。一般来说不太可能一次性把体系合一的问题解决，所以一开始确定一个策略是需要考虑，这里面还涉及到一个组织里面的权力分配问题，是比较复杂的，所以为了项目的成功，不宜过于把项目面铺开。把当前的公司的管理规程做一个了解与盘点，结合ISO20000的标准要求，让咨询给出一个初步的整合意见，必要的流程在项目要实现整合，当课题比较复杂时，可以考虑在项目体制中设立一个体系接口组，进行专门应对。
组织设计
一个清晰组织架构非常重要，没有一个合理的组织架构，体系在运作过程中，必须会发生扭曲，大多数公司的组织架构往往成因于各种历史原因，它与最高领导者的制衡思想、高管之间的权利分配、管理者个人的能力高低、业务发展有着很大关系，却往往与最需要考虑的体系设计思想的关联度很低，所以国内目前许多公司的管理体系名存实亡，与此有着莫大的缘由，最高领导者会因为器重一个管理者，或一个管理者的能力较强就让他兼任数个部门的领导，管理者又都希望其的管理团队或业务规模越多越大越好，这些组织因个人而不断进行调整的情况很多，这些调整时是很少会考虑到流程的问题，组织与流程的调整是最需要变更管理的地方，现在的情况是组织与流程的调整是权力问题，而不是专业问题，随着长年累月的发展，其结果可想知，一个不合理的组织加上一个不合理的体系，服务效率与服务质量是难有保障。这里讨论的组织分两个层面，一个是行政组织，一个是项目组织。
行政组织
行政组织好比人体的骨骼，它是支撑一个组织最重要的架构，一般来说行政组织多是根据职能进行划分的，职能也意味着专业性，即类似专业的工作者会组成一个团队进管理，象人事、销售、开发、财务等；如果我们分析这种组织的形式历史，也可以做一个基本的推断，当一个组织人数很少时，只是一个建制，大家分工也是同样的，当组织人数增多时，此时由于效率的考虑，开始有明确的分工，随后专业就开始出现，这时组织在面的纬度出现分裂，出现了专业的管理者，如果各种组织对某种专业的需求越来越多，在社会上就形成一个事实专业，教育系统就开始批量生产这种专业人员。所以组织内部设计更多是出于效率的考虑，也是专业的考虑，如果一个行业规模较久较大，它需要的专业人员是在社会上比较容易取材的，这时这个行业的组织对于专业分工设计是不需要考虑太多的，IT业虽有一定的历史与规模了，但IT服务业却需要面对这些基本的设计问题。企业内部的分工设计，最好是与社会的专业做较好的对应，不然需要付出很大培训成本，而且取材困难。
组织设计还需要考虑基本的规模问题，当一个专业团队规模太大时需要分拆，不然难以进行有效控制，这时组织的纵深开始出现，也就是我们说的层级，此时管理者的数目开始增多，组织的控制系统是开始形成了。在分拆一个团队时，需要考虑适度的平衡性，就是说两个相同专业的团队大小严重不一，这里面有一些现实因素，比如地理的问题，当一个组织在多个地点的业务不均衡，而且需要现地服务时，很可能会出现这种情况，另外需要考虑的是组织的层级不宜过多，一个规模不大的组织，设计过深的组织层次，是很容易造成控制系统失灵、人浮于事、权责不清，现在信息技术的发展已经能帮我们可以控制更大的建制规模。当一个专业团队被分成不同的建制各自作业时，会慢慢出现一个问题，大家遵行的专业标准、方法、制度等等开始发生偏差，彼此差异会越来越大，地理的分散会更加剧这一发展趋势，最后会导致一个组织的规模优势的丧失，同样的岗位做事情不一样，做事情的方法不一样，甚至职责也不一样，这时需要有力量做这方面的控制与检查，形成一些专业管理部门。组织设计要达到的效果是，以最少的标准岗位种类来完成最多的业务类型（服务产品），以最少的组织层级控制最多的组织个体，要达到这种效果组织架构必然要清晰。
项目组织
行政组织是对专业的管理，项目组织是对业务的管理，行政为体，项目为用。当各种业务开展时，每一个服务合同均可视为一个项目，这时为了完全每个服务合同，需要利用各种专业资源，此时需要把这些专业资源进行有效组织，从管理而言需要进行建制，此时项目组织就会产生，项目组织同样非常重要，需要建立一个稳固的组织模式，对于IT服务而言，最佳的模式是建立一个项目组织模型，套用到每一个服务项目中，把项目经理、一线、二线、三线等明确，这样由项目经理组织调用这些资源，实现服务视角的作业与管理。
如果没有明确的项目组织，依赖行政组织完成服务的交付会面临一系列的问题，服务很可能是跨专业的，它需要一系列的专业组装才能实现交付，此时没有一个人组织或个人最终承担服务职责，也没有人主动做服务改善，也没有人能统一调配为这个合同服务的所有资源，每个人从自已的专业与效率考虑，不会从客户的角度考虑，慢慢的与客户的隔膜越来越厚，服务质量与效率越来越低，一定要注意行政组织是对内的，项目组织是对外的，在设计时，需用考虑两者的调和，这两个视角会在从根本上影响对管理者的职责与权力定义，也会影响到绩效的设计。
角色设计
按照组织的设计思路，有三种关键的角色：
专业管理者
负责管理一个专业团队的人是专业管理者，它属于行政组织的一部份，他的主要职责是：
负责专业技术标准的开发与制订
负责专业力量、技能的培养
负责专业课题的组织攻关
负责专业效能的改进控制
负责专业技能考评
这里特别要注意的专业管理者对员工的拥有程度，通常的概念中，一个行政领导的所有下属的做什么都对由他说了算，但现在不是这样，真正拥有资源的是服务管理者，一个专业团队是由专业管理者进行培养打磨，一个专业团队好比是一个“服务资源池”，一旦池中的资源被分配到一个项目中去后，交付给服务管理者之后，专业管理者就失去对这部份资源的控制，专业管理者需要保障的是由他制造出来的专业产品是合格的，而且以后是可以不定期进行升级的，他需要保障放出去的专业产品是按既定的程序去完成每一次专业操作，专业管理者只负责一部份专业团队的每一个人的绩效评定权。比较典型的专业团队象系统管理人员、软件开发软件、网络管理人员、服务台热线人员等等。
服务管理者
服务管理者也就是服务项目经理了。他承担项目的最终责任，也掌握项目的权力，他责责项目资源的调配，按照体系去完成业务生产，他会参与许多流程活动，项目体制内的成员的绩效也是由他进行评定，服务管理者无法打破的是体系，包括流程与技术标准，当一个专业管理者交付给他一个专业产品时，比如一个系统管理工程师，服务经理不能去要求一个系统管理工程师去做热线的工作，也不要求一个系统管理工程师去做软件开发的工作，就是说这个岗位的职能不能打破，同时专业管理者可以要求一个系统管理工程师去重装一个服务器的操作系统，但是系统管理工程师是按专业管理者制订的安装方法进行操作，服务经理无法干预具体技能过程，如果在流程中明确规定了，所有服务器的启停需要做变更控制，由服务管理者进行审批才能进行，那么服务管理者就不能授权系统管理工程师日后不需审批就可以进行对服务器进行启停。服务管理者是最大的资源拥有者，同时也是最大的责任承担者。需要有意识的区分出专业管理者与服务管理者，这样让组织内部与客户取得平衡，让生产与管理取得平衡，让专业与效率取得平衡。
体系管理者
体系管理者是一个立法与司法的单位，他负责确定所有作业流程的设计开发，并负责解释与培训推广、流程的执行检查与流程的维护改进，他负责界定每个人的职责范围与权力边界，他不参与具体的业务活动，他通过对流程的控制规范业务运作，并对服务管理者与专业管理者做体系执行绩效评定。
作业岗位
一个公司中会存在多个岗位名称，岗位越多，管理越复杂，各种升迁与薪资设计与岗位要求都更多，岗位要尽可能标准化，与社会上的专业做较好的结合，将岗位种类减到最小的数量，事实上目前许多公司存在大量的社会资源浪费，许多岗位设计如果合理的话，可以很大程度的低端化，即不需要聘请高学历的人员来从事这种岗位，因为这些岗位上只有极少数的情况才需要用到复杂的专业技能，为此拔高岗位的人员素质要求，一是浪费社会资源，二是增加企业成本，最终转移到客户身上，造成服务价格不具备竞争力，员工也因此学无所用，造成过速流动，又引起服务质量问题。如果真正去分析服务过程，我们发现大量服务时间是用在简单的服务响应上了，我们完成可以把复杂的问题后移，建立一个服务梯队，也就是通常说的一、二、三线，能否建立一个技能要求低端化的一线对成本起着决定性的作用，在我的理念中，一线可以不需要精深的技能要求，但是他可以有很大的资源调配权，从内部而言，他们就是客户的代言人。在漫长的服务过程中，许多管理者因为一、二、三线的配合衔接问题，而让一线人员的技能进行培养提升，最终异化了一线的岗位标准，这种做法长远来说，对组织是一种伤害，最终公司需要付出更大的成本支出，同时会扭曲整个作业体制，最后个别强悍的一线会出现绑架公司的情况，这样的人员离职很难有人替代，最终造成的结果可能是整个一线的岗位要求提升，一线的职责进行扩充，挤压后端的资源。要有意识的控制岗位标准，这是一个非常根本的问题，一旦失控，麻烦将是全方位的。
当专业管理者、服务管理者、体系管理者三种角色形成独立的相互制衡的力量时，组织的运行有了最基本的逻辑与源动力，往下就是具体的作业岗位，在后续流程中可以进行一一界定，往上是高层领导者，负责维护这一个生态系统，任何一方力量的过度发展都是不适宜的，在每一次出现矛盾时做出审视与调整，这样会不断形成促进体系发展、专业发展、业务发展的机制，让组织整体越来越健壮。
体系蓝图
体系一定要保持框架的完整性，同时又要具备非常的厚度，它是唯一的合法依据，我反对把管理与生产，技术与流程这样进行二元对立，这是对基本的管理认知误区，体系是一个机器，资源是它的源料，业务是它的结果，在运作过程中你是不能去区分什么是生产什么是管理的，通常人们的认知是事件流程这是流程的，一个操作系统的安装是技术的，在我认为的体系中，如果一个操作系统安装需要规范，那么就需要设计一个规范进行约束，如果操作系统的安装是事件流程的一部份时，那它是技术还是流程呢？当一个流程精细化发展时，它必须进入技术的范畴，你无法再区分管理与技术，这种区分也没有丝毫意义。体系不是高高在上的，不是静态的，如果一个体系长时间的没有变更，要么是非常完美，要么是它没有进入操作层，在最近几年的工作中，我越发感觉到，有一个独立的力量去控制、开发、检查、改进体系的必要性，同时要定期对员工与管理者进行体系培训，不能出现体系之外出现执行标准，或充许局部的组织进行自我标准开发执行，一定要集中进行控制。管理的职能随着业务规模的发展与对质量要求的提高而日益增长，对专业标准建设的要求将更加迫切，从而导致整个组织专业能力的进化，技术与流程无法再进行明确切割，体系成为体现一个组织对管理、技术的最终理解，一切无法转化成组织力量的个人能力是不能常态的发挥作用的，一切无法融入体系的制度与规范起到的短期正面作用远远大于长期带来的负面作用。
流程的控制要集中，但要赋予每一个不同的项目的灵活与进一步的精细要求，所以在体系结构设计要明确这样一个逻辑：所有流程文件必须在所有项目得到豪无例外的遵守与执行，针对每一个项目要设计出项目作业书来进一步约束，以弥补流程文件的不足，项目作业书任何定义与要求不得与流程文件发生冲突。流程文件+项目作业书等于一个项目作业者需要遵守的全部。这样做的原因是为了解决一个先天的矛盾，如果流程非常通用性，它容易适用于所有项目，但是指导约束意义很低，如果流程非常精细，它的指导约束意义很高，但是又无法适用于所有项目，所以我们把统一的要求用一个层次来控制，把更精细、可灵活的部份下沉到项目作业书。更重要的是流程是分散的、岗位是专业化的、组织是行政的，在项目作业书中把这些组装在一起，它指导了我们如何完成这个项目的交付与管理，所有这个项目作业书的计划、文档、记录全部进行集中的管理，这样又以项目为单位形成整个公司的配置管理。
把管理的颗粒度深入到项目这个层次，所有的一切围绕着这个点，才真正的与服务的视角做了契合，实现真正的以客户为中心，粗放式管理将开始精细化，分析、统计、指标核算、绩效设计均紧紧以项目为主进行，将公司的内部管理与客户做了更紧密的联系与捆绑，最终这会形成一种服务文化，扭转那种二、三线人员难以被一线人员调动的情况，提高一线的资源调动力，预算与成本意识下沉到项目管理者，真正掌握每一个项目的成本利润情况，并在作业过程中进行控制，最后会形成对服务合同进一步精细化定义与界定，同时项目管理者会逐渐具备经营意识，开始有正面的力量发掘客户进一步的服务需求，以前知道预算与合同的人不知道具体做了什么，真正知道做了什么的人不知道预算与合同，所以造成合同该做的事情没有做，不该做的事情却做了，由于没有一个服务的全面考虑者，隐性的作业成本被大量忽略，形成一笔糊涂账，真正每一个项目有没有利润，利润是多少是不清楚的，到底每一个项目的成本是多少同样是没有人清楚的，只知道总账目，其中的情况很可能是有的项目暴利，有的项目亏损，这样的运营是存在很大的未知风险的，就好比一天到晚乱吃东西，活着是活着，但不知哪一些是有毒的。暴利是不会长久的，如果IT服务商不提前做好应对准备，一旦哪一天暴利项目的泡沫被剌破，会突然出现经营恶化的情况，这些长远来说对IT服务商与客户都是不利的。项目需要成为一个独立管理单位，一个独立的运营单位，一个独立的核查单位，体系需要进入每一个项目的内部运作过程，这才是最根本的价值所在。
体系要设计出权力的制衡模式，同时要建立权责对等模式。专业发展是值得鼓励的，业务发展是值得鼓励的，流程发展也是值得鼓励的，但如何实现均衡发展，这需要进行制度设计，好的制度不是消灭问题的，而能够让问题浮出水面，并赋予一个机制去处理。专业管理者与服务管理者与流程管理者将实现三权分立，构建组织最重要的三极管理角色，让这三个角色相互博弈，来促进体系的进化。行政组织是骨骼，项目组织是神经，二者缺一不可，它们一起确保组织的坚固与灵活，权力不再以行政级别的高低去定义，让管理者渐渐成为一个后台支持角色，一个前哨的步兵可以调动战斗机，是因为他掌握前线的信息，信息的丰富与否与权力多少形成正比，减少所有作业过程中那些无谓的领导审批，领导是河流的清道夫，让水流更加顺畅，而不是堤坝，去阻档水流，承担更多职责的人要赋予更大的权力，让最专业的人做专业的决定，而不是让权力最大的做专业的决定，每个角色各司其职，知道自已真正该做的事情、怎么去做事情。
从体系框架、体系结构、组织与角色几个角度去实现基本的服务管理思想，去设计构建一个合理的可以进化的服务管理体系，这些基本的约束在体现在每一个流程设计上，最终带来整个组织风气的变革与权力认知。
跟大家交流一个ITIL的概念吧：ITIL落地是ITIL最佳实践在企业信息化运维过程中真正贯彻，让企业信息化运维遵循ITIL的相关理念。IT运维管理社区的专家整合多年的ITIL咨询、ITIL实施的经验，编写了唯一的一套ITIL落地课程，并将其推向IT服务人员的培训，目前已经在北京、上海、广州、深圳组织了多场的ITIL落地培训，取得了良好的效果。 跟大家交流一个ITIL的概念吧：为推动ITIL在国内的发展，降低IT服务人员的培训成本，在保证培训质量的基础上，一些培训机构通过互联网组织了ITIL团购，目前IT运维管理社区组织了ITIL Foundation培训团购（ITIL团购）、ITIL落地培训团购以及ITIL Expert培训团购活动。
页:
[1]