|
|
回复 achotsao 的帖子
关于服务设计这个模块，我们不会陌生，包括V2时期的服务级别管理、可用性管理、能力管理以及可持续性管理，这些流程虽然不陌生，但是除了服务级别管理外全面实施的本来就不多，原因是牵涉面较大，无法协调管理，但平时日常工作中，这些工作一点也没有少做，重要的是没有形成规范流程而已，这也和大部分ITIL工具只擅长工作流，不擅长价值判断有很大关系。值得注意的是，这个部分加了三个流程，一个是服务目录管理、一个是供应商管理，还有一个是安全管理。这都是很有价值，尤其是服务目录管理，我们几年前就开始在很多企业的服务级别管理当中去实施过，最近几年随着服务产品化的推出，我们的工作更多了，互联网行业由于特殊性，在这方面走得比较早，有一些企业在我们带动下，内部也逐步形成了服务目录制定的热潮，我一度把服务目录和知识库、配置管理数据库称为三个最难逾越但最值得逾越的难关。服务目录实施中最重要的是要理解一个浅显的道理，就是能让客户看明白和用明白。除了互联网企业，有些企业开始印刷了一些以服务为导向Catalog，很好，虽然产品体系没有建立，但是感觉对了，还有的企业做了很细致的产品操作说明，这点要注意了，这可以作为产品目录的一部分，但是切忌只有自己能看懂。
供应商管理的落地不多，因为机会不多，很多IT组织的采购工作会由一些采购部门进行，不过他们可能没有意识到，ITIL V3很有可能涉及到的部门并非只是IT部门，这个以后还可以谈。关于安全管理，其实从V1开始一直有，不过一直有些姥姥不疼舅舅不爱，我觉得重点在于这些内容更多是关注在一些政策上，而实际中的安全管理需要落地到技术才有用。很多年前，我们慕名从国外花了一千多人民币，买了本相关的书未来，一百多页，看了半天，大家只得出一个结论：就是IT信息安全管理很重要。然后没了，我们当即无语。其实服务设计这本书是我个人比较喜欢的书，除了一些流程的设计外，很多有用的模型如RACI等等流程外的内容也很有用。我建议有了一定规模的IT组织好好学习这个部分，有些地方可以开始实施起来了。
服务转换部分包含大家熟悉的配置与资产管理、发布与部署管理以及变更管理，同时加了知识管理、评估、验证与测试等一些流程。首先我们说说原来V2有的三个流程，发布与变更我们很多时候是作为一个项目来实施的，配置管理则一般基于建设CMDB作为关键点，均是比较难实施的流程，重点在于它不仅仅只是设计流程那么简单，还需要最大限度考虑组织的组织架构以及组件架构，更难的是遵行与维护，我们几度访谈以往的客户，往往在后期不能加强管理，使得这些流程和模型变成鸡肋，不管是V2还是V3，这都是我们要重点去关注的，我可以讲一个案例，有个企业最初有四个小组，他们的小组长很愿意实施变更管理，因为老是变更有冲突，后来他们直接都担任变更经理，有一位作为主导者来召开CAB，变更经理们负责录单和分配工作，按道理没有问题。但几个月后我们去回访，发现里面单子填写得敷衍了事，服务台也反映仍然有多次变更冲突事件。原因呢？其实这几个组长很苦恼，因为他们工作太忙，填单的事情太复杂。好吧，那么就请个专职的变更经理，但烦事又来了，他们希望这位未来的变更经理，又要懂技术，又要懂流程，又要会沟通，又要能铁面无私，技术还得不比他们差，结果每天做录单的活……这个事情我估计我也不愿意干。其实变更经理真的要是多面手吗？他其实重点在于流程的熟悉与KPI的熟悉，并且能有基本的IT知识，有主持CAB的能力是关键。在我们帮助下，他们逐步改变了招聘政策--案例是次要的，问题是，如果我们不回访，谁会去逐步改进这个流程呢？所以这几个流程实施还是很有挑战的，这和V2还是V3的关系不是太大。不过另外几个流程就是新增的流程，我很难回答大家有没有实施它，因为它本来就是从很多软件开发环境中采纳的最佳实践，这个部分的落实关键点不是流程，而在于开发与运维的关系，现在IT服务管理中非常难的一个事情是，明明IT开发工作是服务交付的重要一环，但偏偏运维经理几乎就无法调用开发人员的资源，并且开发人员长期以来对于什么是故障，什么是问题，什么需要快速处理哪怕只是用应急措施，什么需要根本解决也处于相对茫然。所以对于其它的大部分流程来说，难点其实就是在于组织间的整合，倒并非是流程的采纳。
另外有一点很重要的是，知识系统管理，知识库的建设是业内常讨论的话题，知识系统管理的野心远远大于知识库，它几乎包含了ITIL V3的所有相关数据与信息乃至支持系统，但我们现实中实施更多的还是知识库，知识库的建设是个永恒的话题，我们这次就不多提。
接下来就是原来实施得最多的运营管理，这个部分事件管理，服务台，问题管理可以讲是ITIL里面的老兵，如果你了解过ITIL，你就不可能没有听说过它们，不过这次ITIL V3加了三个流程，一个是服务请求实施，一个是安全访问，一个是事件管理，这个事件管理是event management，先谈谈最后的Event management，这个流程我们尝试在一些企业实施过了，我们可以理解为是故障，问题，变更前的一个哨兵，比如设定一些阈值，超过了某个阈值是记录呢还是自动响应，还是说转往故障管理流程。这个流程实施不难，很多企业自己都有，就是没有规范化，对工具的依赖性很强，我也曾考虑过是否需要专门设定这样的流程。安全访问流程其实也被很多企业在技术上采纳了，只是没有规范起来，而服务请求实施就是把一些服务请求，如标准变更，密码修改，咨询，文档要求等一些非故障类事情单独设流程。有些企业也实施了，比如他们把该类请求转到一个专门的部门，对于这个部门主要是考核客户满意度，不着重考核平均修复时间。其实这几个新添的流程从很大意义上是考虑到了呼叫处理的多样性，在以往我们实施的案例中，都或多或少涉及过。至于如今是否需要新设流程，我觉得要根据实际情况来分析。
最后一个模块是服务改进，和服务战略有类似的地方，里面更多的是方法论，一堆方法论足以让你们看得头晕。但是优化改进是很重要的，这个部分如何实施？我觉得当你打算进行优化的时候，就已经开始实施了，因为你实施中可以根据ITIL提供的一些方法论和模型进行指导即可，中间的细节工作，如考核，考评还是要根据实际情况来。对于服务改进，也是一个非流程的实施单元，而是个思想实施与参考实施的单元。
CIO时代网 ：刘老师不亏是ITIL V3实施的专家，给出这么多的关于实施的真知灼见。假如实施一个系统的话，会考虑实施是否成功，那么就ITIL V3实施的话怎么样才算是成功了？这个有没有一个可以借以判断的标准？
刘颋：首先ISO20000确实是itSMF与国际标准组织来评估IT组织IT服务管理水平的一种方法，不过，大家都知道在中国无论是企业还是个人，都很擅长应对“考试”，所以我们往往存在尽管ISO20000通过了却未必意味着内部管理提升的现实。因而我们一般做项目的时候会根据实际情况来选择对组织的“关键流程”进行细化处理，已达到效果。
至于说什么是ITIL的成功案例，这个问题你会觉得很有趣，因为我知道很多企业都会把他们实施过的案例都称为成功案例，比如有个着名的保险公司，曾经于五年前几乎全面实施ITIL，被誉为成功案例，但在一个月，我和他们的关键人聊起来，他们很痛苦的是，如果企业因为工具等方面的原因，开始全面抵制ITIL，新的领导甚至提出了“赶走ITIL，还我实效”的口号，作为最佳实践的框架，被人称为不实际是很可悲的，但是这个现象也是广泛的。你能说我会承认这是成功案例吗？
重点在于，ITIL的实施不能完全是项目制的，而是长期要进行的，需要定期的优化，定期的改进。所以你要问我心目中什么是ITIL的成功案例？我会说，首先跑起来了，在一定时期内能得到有效反馈，有专人，根据各种指标进行问题分析和优化改进，能逐步为客户、员工及相关利益者所接受，最终产生价值。所以即便在翰纬，成功案例只是一个相对值，如果哪个企业由于主动或被动去放弃优化改进，我们都很难称之为成功案例。
当然在我心目中，我们和阿斯利康、阿里巴巴、浦发银行、佛山电力、上海电信以及各地一些移动公司、地铁公司等大概几十个企业做的项目，个人还是比较满意的，因为我们形成了一种共同创造价值的文化，只要有这种文化，就意味着改进会不断进行，这种持续改进则是我心目中的成功案例。
CIO时代网 ：刚刘老师提到了有很多案例是比较成功的，但是成功判断也是有一定的，ITIL V3实施了，也成功运营了，但是能不够给企业带来预期的绩效呢？运维绩效评估也是我们比较关注的，绩效评估是否也有一些具体的实施方法或者流程？
刘颋：你的意思我明白就是说你说你是一个成功的人士，为了建设与改进一些流程和模型，我们确确实实地采用了许多评估方法。一般的评估方法是采用PPT结构，即Process流程，People人，Technology&Tools工具与技术的方面进行。
对于工具的评估，有很多方法，不过我们一般是把它作为流程评估的一部分来进行。
对于流程的评估我们是比较熟悉的，一般采用的是将一些成熟的模型对应到一些定制化的问题上，而我们访谈的时候，也并非采用机械式的问答，而是采用开放式的问题，利用我们的经验逐步将开放问题映射到既定问题上，然后做周密的差距分析，从科学的方法得出正确的结论。这种方法也是我们大多数咨询项目与研究项目中的方法，我在授课时也偶尔会将一些自己在项目中的实例拿来帮助学员理解知识的实践方法。
|
|
achotsao
发表于 2010-12-15 21:07:06
转播
分享
淘帖
()
