[p=30,2,left]学习资料：
[p=30,2,center]
ISO20000体系实施难点
不知道我的理解能力差，还是花钱请的顾问差，还是ISO的标准差，把一个标准搞得这么晦涩难懂，实施起来左右不是，下面我把现在的一些困惑做一些说明，这些是我们在体系设计时也是没有太整明白的，希望有同感或建议的同行们发表一下意见。
一、能力管理
以前在写一篇ITIL的局限性的短文时，我某种程度上曲解了能力管理的概念，能力管理的目标，标准的定义是：确保服务供应商一直保持有效的能力去满足当前和未来的客户业务需求。现实世界，没有任何人与组织的需求是被无限的满足了的，你认为你的软件系统真正的满足了客户的需求吗？事实上你很多时候在压制客户的业务需求。需求的满足往往是被动的结果，而不是主动的结果。能力管理我个人觉得落到实处的动作有限，这些动作就是没有实施能力管理流程，现实也已在作业的。
1)第一个问题：能力是什么？
能力管理的第一个要点：能力计划，你就会发现这个东西难以制作了，先说一下什么是能力，能力指你的服务器的处理能力，能力指你的网络负载，能力指你的工程师人数，能力指你的软件速度，能力指你的硬盘空间，能力指你的打印速度，你可以穷尽吗？可以，但很难，所以第一个问题就出来了，你如何定义你的能力，当你连能力是什么没有搞清楚前，你没有办法去谈什么阀值定义，你连要监视什么都不知道，更谈不上去提升。许多时候能力缩窄为CPU、内存、硬盘、带宽这种根本不用去谈什么能力管理都知道的技术参数，那实施能力管理与不实施能力管理有什么区别呢，除得搞复杂了，增加了管理成本外，带来什么好处了？
2)第二个问题：业务需求如何被洞悉
业务需求也是一个被说得烂了的词，某一个用户希望你的报表增加一个栏位，或者希望你的系统速度提升哪怕一秒钟，这算不算业务需求？算。客户的某个部门要新进一个人员，需要部署一台机器，需要你对这名人员做某个管理软件的培训，这算不算业务需求？也算，你的客户明年的生产需要扩大50%，算不算业务需求？算，举这些例子是想说明，业务需求你很难主动去识别的，更多是被动的接受到讯息，然后进行响应，它更多不是主动意识的结果。
3)第三个问题：业务需求与能力的关系
即便你可以随意入侵客户的组织内部，可以主动收集大量的信息，比如上面的几个例子，你都非常清楚了，那么你打算做什么？你可以把每一个业务需求换算成你能力指标吗？你知道增加一台计算，或提升一点系统速度，或者客户的业务量增加一些，会你的CPU、内存、硬盘、带宽、工程师带多少量化的要求吗？除非你可以有一个完美的计算机模型，不然这些业务需求你得到了讯息，你无法做任何事情，当客户的业务需求有质的变化时，比如明年客户的业务量要扩大一倍，这种需求一定是他提前会告之你做准备的，如果只是一些小的业务需求，你的服务是绝可以消化的，因为这些是在你签合同时就定义了，如果是一个比较大的新需求，客户另外需要付费，这也是一个其它的过程，而不是能力管理的范围。
4)第四个问题：实施能力管理流程，我们到底要做什么
标准会告诉你，你要制作你有能力计划，里面要描述当前与未来对于IT基础设施的能力需求，你要去模拟，去预测你的基础设施的运行情况，你还要做应用选型、监控、分析、调整、实施。这些作业都没有一个基于一个坚实的业务基础，最后更多会流于形式，更重要的没有搞这些时，真正能做的工作事实我们已在做了。而且IITL中对于能力管理好象一直着眼于基础架构，IT服务商真正的能力，最大的能力却不是基础架构，而是人，对服务资源的能力管理却好象是ISO20000或ITIL一直没有明确的。我相信购进一台新设备跟新培养一个服务人员相比，后者更复杂更需要被控制。
二、可用性管理
可用性管理的目的是为保障IT服务商提从符合可用性级别的IT服务，在我们公司就是保证Q指标，我关心的问题仍是，实施这一个流程我们要干嘛，好象没有什么活动是可以真正落到实处的，而且以可用性的监控与评价而言，没有一个管理软件去撑，你是极难通过人工去采集计算的，象MTTR（meantimetorepair）平均修复时间，MTBF（meantimebetweenfailures）平均无故障时间，MTBSI（meantimebetweensystemincidents）平均系事件间隔时间，还有象总体正常运作时间与宕机时间，这些指标都是与某些事件捆绑的，还需要考虑你的服务时间承诺，难以想象通过手工记录去进行计算。
标准还要告诉你要做可用性计划，注意这个计划不是可用性管理的实施计划，至于是什么，内容有哪一些，请自已猜去吧。可用性管理用朴素的思想去理解的话，就是你承诺了客户可用性的指标，是利用这一个流程去控制如何保障指标的达成，但是怎么做，做什么，没有与现实业务脱节严重，无法真正对体系建设起到实质性的指导方法，这其中有大量的数据采集与计划，没有软件的支持基本上是不现实的。
三、持续性管理
我的理解是：可用性管理是为了控制、保障你的服务是不中断的，持续性管理是为了控制、保障你的服务真的发生中断时，你如何最快的恢复你的服务。在我们公司以前对应此的做法就是各个紧急预案，但是站在体系的角度，持续性管理是如何在体系占有一角，它与事件管理的区别与联系，持续性管理要做的风险评估与控制到底与信息安全管理是怎样的关系，这些都没有地方说清楚。这样每一个流程的边界都没有切分清楚
在ITIL的方法论中，要求IT服务商要做持续性需求分析与战略规划，然后去实施，这里忽略了一个事件，绝大多数应用ITIL或ISO20000的组织是商业组织，不是英国的政府部门，钱是稀缺品，对于持续性与可用性更多是基于资源投入，比如备用机、备件的准备充分，这些都是需要钱的，作为IT服务商，并不对基础架构拥有所有权，这也意味着你客户掏钱来搞这些，这现实吗？如果你做了完美的可用性与持续性的分析，然后做了最好的战略规划，客户根本不对此打算作投入，意义何在，最后持续性管理的实施，是实施什么呢。
四、信息安全管理
信息安全管理这个名字，我一直以为是搞错了，从英文上看，是安全管理，但从内容上看，又好象是信息安全管理，请注意喔，安全管理与信息安全管理，这其实是两个完全不同的概念，这也意味具体的作业是很不相同的，涉及到的范围也不一样，安全管理是基于组件本身的运行而言，信息安全管理是基于组件提供的服务而言，这在评估时，要素完全是不一样的，比如一台电脑，请对它做安全评估，你得出来的内容，与你对它做信息安全评估的内容是是不一样的。内容不一样又决定了后续采取的措施是不一样的。
信息安全管理的范围有哪一些？顾问指导我们用资产盘点的方式去驱动，但是组件并不都是资产的，从安全的角度而言，任何一个组件都有可能隐藏安全的风险，这种盘点的方式非常耗费人力的，同时还要对每一个盘点出来的对象做风险评估，去定值，然后还要采取相应的防范措施，从最保守的角度而言，你只有1000个设备，每一个设备存在的风险不会少5个，一共就是5000个，你需要针对这5000去制订控制措施（就算我非常高杆，一个措施就搞定一个风险），你如何落实5000个措施呢？这些措施与你其它流程又是什么关系呢？你可以想象其中的复杂了。
我们在做这一块时，把软件也纳入其中了，比如应用软件的项目，你不能说只有主机有风险，而数据与程序没有安全风险了，后者反而是我们容易忽略的。这一块我不知道是方法论差，还是顾问差，这一个过程太不严谨了，许多点经不起推敲。如果你用严格意义的执行这一流程，可以说单单这一流程的工作量不亚于你的其它的流程加在一起的工作量。可笑的是，你按严密逻辑做下来，最后发现基本是无法有效落实。
五、服务级别管理（对IT服务商的好处）
服务级别管理与前面的能力、可用、持续这几个流程不一样，前面几个我认为是标准或方法论没有定义清楚造成不知如何具体操作，服务级别管理定义应该说是清楚的，这里要说的是落实与可操作度
OLA是内部的协议，我们公司的情况是，比如一个应用系统项目，主机部份属于一个专业部门管理，网络属于一个专业部门，桌面属于一个专业部门，程序的开发是一个专业部门，而应用系统的维护是由一线的团队负责（非服务台），那是不是负责这个应用系统项目的一线团队需要跟其它的所有部门签订OLA呢，我们这样项目有50个以上，你能想象如何作业么。
UC是指外部供应商，外部供应商有两种情况，一部是客户购买IBM的主机时，IBM就间接的成了我们的外部供应商，还有一种是我们硬件的采购或服务商，比如打印机。这些大大小小的外部供应商怕也有好几十家吧，每家去谈判签订UC难度也是比较大的，先暂切不说跟客户订SLA的艰难，假设SLA真正分解后，对UC肯定是会有一个基线要求的，如果供应商无法接受怎么办？我们去掏钱付费吗，还是返回头找客户降低SLA，可以想象这个过程的复杂度，尤其是项目数量多时。
在当前客户还没有成熟起来时，是以人力购买的方式付费结算时，当一个IT服务商去实施ISO20000时，要强迫客户去拿起SLA这条鞭子抽我们么？我们花钱去让客户找罪我们受，这违背商业精神，我一直说，如果客户是一个头脑非常聪明的完全理性人，光是SLA的签订过程就是一个非常痛苦的过程，就不谈OLA与UC了，服务体系从来不是服务商单方面可以决定的，而ISO20000的体系标准其实是在暗示一个逻辑，就是你的客户是完全成熟理性的，现实中这条件往往不成立。
六、体系的融合问题
在体系设计过程中，一直觉得整个体系无法非常紧密的有机集成，尤其是服务规划实施，还有服务交付的几个流程（信息安全、能力、可用性、持续性），以我当前这一刻，我无法判断到底标准、方法论的问题还是顾问能力造成的问题，再或者是我的理解能力问题。在我的认知中，要让每个流程互动集成起来，一定是需要信息串插起来的，这种信息不是标准或方法论中的一句话，而是一个具体的表单或文件，每个流程的输入信息与输出信息就应该体现这些，不然说起来这是个体系，到时其实仍然是一个个孤立的流程，彼此没有协作。这一点是我比较担心的。
以个人浅薄的意见，除非有迫切的商业标贴压力，否则不建议IT服务商上马ISO20000这种带有强制性要求的体系标准，做一个ISO20000项目，一般也就是一年内要完成（公司不太可能给两年以上的时间搞一个标准认证），可以想象以ISO20000体系覆盖的广度与深度，在一年内要如何真正见到成效，13个流程，就算你一个月吃进去一个流程，也需要一年了，就不谈其它的项目作业时间（准备、培训、设计、试运行），可以想象这个过程的难度与挑战，国内IT服务商我虽然接触不多，但是我相信在运维服务管理的成熟度超过我们公司的并不多，即便超过也不会有质的差别，所以估计情况与我们类似，我的建议是如果是从切实想改善你的运维服务现状，还是引入ITIL，跟咨询公司合作一起做实，不要去奔认证，这样公司内部有时间慢慢来做，顾问也会更深入你的业务中，而且许多时间考虑点就不会首先从标准要求出来了，而是从业务实际出发，这些感受也是我们项目进展了这么长时间才有的切实感受。如果一定要搞ISO20000，就象我们公司这种情况，我的建议是领导一定要有战略考虑，定义重点流程，这些流程是需要在项目过程落实清楚的，其它的流程我们先把框架搭好，把法律条文先订下来，等项目结束后再落实，做ISO20000这个项目，认证时间有要求，但并不是说认证后我们的体系工作不做了，我们可以逻辑的把它看成两个项目阶段，前者是跟顾问一起做，后面的是我们自已进行，这些需要一开始形成共识，不然在项目过程会引发许多怀疑与担心。ISO20000的标准我认为制订得并不好，制订得也太具野心了，我说不出不好在哪儿，只是模糊的觉得它的体系与结构性真的不强，依靠几个简单的框架并没有把各个流程结成真正的体系。
虽然现在ITIL的传播越发快了，在我读过的ITIL的书籍中，许多说法过于含糊，而没有人对此做出说明解释，往往大家在看完一个流程后心里没有底，却越发认为这其中内有乾坤，搞得越发神秘，我倒觉得这是失败，理论的失败，以及理论普及的失败，一个管理方法不应该如此含糊不清，当一个正常智力对业务也有一定熟悉度的人去学习与认真培训后，还是存在这么多盲点，这正常吗，我总相信合理的东西一般都是富于结构而清晰的，容易让人明白。我有一段时间试图把ITIL的一些流程全部组装在一起，用一张图把所有流程的内部情况与接口情况表达清楚，但我发现光是服务支持这一块是非常难了，更不要谈把服务提供这一部份揉捻在一起，这个图我认为非常重要，可以解决许多问题，尤其是在解释IITIL与普及ITIL方面，是真的没有办法画出来吗？还是本身就不存在这样一个有机体系呢？鄙视一下那些写ITIL书籍的专家们，还有管理咨询公司那些不知所谓的顾问们，我认为这是他们需要思考、或者要做的功课，估计专家顾问们都非常忙，忙着在全中国点燃火种，写书、IT运维管理社区、讲座、售前，中国更需要ITIL的传教士而不是教父。苦了我们这些ITIL应用的先行者，NND，做ISO20000项目，或者写这类文章时，有一种做先烈的感觉，怕怕。。。。。。。。
|
micro_clark
发表于 2011-12-27 22:44:12
转播
分享
淘帖
()
