本帖最后由fashionicet于2011-6-2810:01编辑
回复longerwood的帖子
版主强大啊。总结的比我精炼多了。其实，现在在网上看很多人讨论ITIL，基本还是偏理论和理想状态，一个简单的话其实放在企业中就非常复杂，会牵扯出很多的细节出来。比如“组织内部不了解ITIL，难以推广”，大家其实都知道这句话，在售前或咨询顾问培训ITIL在中国的情况，都会说这句话，但是真正把这句话放在企业中去剖析，会发现很多细节问题。
为虾米组织内部不了解ITIL？？
1，利益。利益分为两点，第一当然就是赤裸裸的money分配问题，因为ITIL涉及的不仅仅是IT部门，还涉及业务部门（当然这是较完善的ITIL），即便是小ITIL，即便是初级ITIL只实施在IT部门中，也会牵扯分配问题，因为要上ITIL的企业，IT部门已经非常细分了，有各个小组，每个小组有领导，而且可能有几个副总统一管理。利益自然就会牵扯出政治斗争的问题。第二是指IT工程师或业务部门员工的“利益”，做了ITIL，对我有虾米好处？你这些厂商口口声声说减轻我滴工作？可是我怎么觉得你给我增加了工作？我管那么多系统，你还让我再使用你的虾米ITIL平台？
2，IT战略。这个可能有些人觉得抽象。但是不口否认，这是存在的。要看这个企业对IT部门的定位是怎么样的，对于IT部门的核心价值是什么。到底保障系统正常运行，还是支持业务发展，这是很重要的。每个企业对于IT部门的定位不同，导致对IT部门的投入和上的项目就不同。即便忽悠了一个ITIL项目来做，但是人家IT部门的核心价值是保障系统正常运行就OK了，没必要搞这么高深的装B东西，所以导致之前的那个句话“组织不了解ITIL”。
3，XX。（暂时没想到用啥词来总结第三点）。很多厂商或咨询方在培训的时候总会说这句话，但是又不说透彻到底为啥，是因为他们用这句话来重伤他们的竞争对手，好在客户面前表现他们是专业的，有了他们，客户组织就一定会理解ITIL。这种厂商我亲自就见过几次。
“我最近就在想是否可以参考SOA的理念建立企业组织架构，并让每个部门根据自身的职能和职责做出服务目录，包括服务的输入输出以及过程约束，形成一种基于ESB的企业运行机制，以便于组织内部为组织的业务目标的达成更加有效地协同。这个设想的核心在于组织内部对于面向服务的理解和贯彻，同时在运行中参考ITIL的一些关键活动域，如服务目录、服务台、事件管理等等。”
能做到这个程度，估计就是各自成为SBU，全部独立计费，独立核算。愿景很不错。
不可否认软件厂商存在的目的就在于赚客户的钱，这也是客户很清楚的，如果客户在IT服务管理中确实存在痛处，需要改进，也需要积极地提一些现实的需求，同时通过一些有效地手段去约束软件厂商如何实施好这个项目。完全指望厂商把这件事情做得很完美是不现实的。同时往往很多中国特色的项目，可能出发点就是为满足某些个人的利益，那就另当别论了。
我觉得任何合作或者交易最好是实现双赢。
回复 fashionicet 的帖子
同意你的看法，持续改进很重要，这也是ITIL实施后所忽略的。另外我提到的实施，我认为是需要包括需求分析和规划的，应该严格按照项目管理的方式来做。
有说的不对之处，还请包涵
楼盖得有点歪了，还是想聊几句。
一、ITIL实施本身就是个持续性的过程，不可能一蹴而就。另外就是知识库的建立，必然需要一定的时间进行累计，沉淀出来的东西才是精华。
二、适应性问题，任何单位都有自身的流程，所以不可能全部都与ITIL的理论一致，因此实施中的变通更重要，生搬硬套就是个死，顶多画虎不成反类犬了。
三、ITIL本身就是一种管理的变更，无论是实践，还是历史都证明了，新制度的实施必然会引起老制度的抵触。阵痛是难免的，而硬着陆多半只会使新制度被扼杀在摇篮里。所以，ITIL实施是要从根本上改变管理方法，改变管理制度，改变管理流程。还得是一点一滴的渗透进去。
最后说下买软件的问题。软件商本身一般是不抵触持续作业的，因为持续作业意味着持续的收费。但对用户来说就是持续的支出，而且收效甚微。就像第三点里说的，动作太快，太大用户必定会反弹，但动作太慢，用户又觉得效果小，支出大。这也是为什么ITIL在实施后，要么一锤子买卖闪人不管结果，要么就是用户终止项目，真正做成功的少之又少。况且国人对待工作的态度也确实存在问题。