QUOTE:

---

最初由 sdsdsd 发布


不是基于方法论的
书上好像也是这么强调的哦

---

书上还说，ITIL的精髓就是：流程和最佳实践

QUOTE:

---

最初由 sdsdsd 发布


我们本来没那么多审批的，结果PWC审计完了，这事儿就搞复杂了

---

Audit的确是必要的，他们都是按照标准的流程来看待问题。对他们来说，不敢放过有漏洞的地方。毕竟他们就是靠这个吃饭的。

但是如果制定的流程是能规避audit提出的问题，audit也是会同意的。只是完善audit发现的问题时，各级manager的处理也是不同的，有的就完全复杂化了，这是很普遍的

QUOTE:

---

最初由 itpeople 发布


变更流程中Urgent Change可以很快处理变更。

我想起了一个问题，ITIL的变更流程面向运行环境，如果是开发环境，相应的流程又不一样了。原因是运行环境中变更没有很好的控制的话，很容易引入Incident，造成SLA Break.

---

Urgent Change一般是对应urgent incident的。

我的感觉也是：针对开发流程，ITIL似乎过于复杂了。

任何事情如果要约恕领导就麻烦了。

感觉大家说的都有道理。在实际操作过程中，确实会遇到这样的问题。
这个主要就是把ITIL教条化了。
在ITIL理论的变更流程中，是把变更分为常规变更和非常规变更，把一些经常需要变动的权利下放到一般IT维护人员，这样简化变更的审批流程，提高效率。

ITIL在中国企业的实施，中国客户都是初级的认识，很多企业都还没有体会到ITIL带来的好处。

Regarding such issue, I think it should go through the above process, but I don't think it is downgrade the effeciency. actually it only send request(from sales)==>program setup(IT)==>change management(IT)==>Logged(IT). the process is same as before, right?

目前还在学习itil，希望在这里得到最大的提高。

在企业实际情况中确实会出现楼主所提到的情况和需求，ITIL是企业IT服务的管理方法，针对不同的企业ITIL的实施也是不同的，要根据企业实际状况的需求实施ITIL。用一个很简单的办法就可以解决你举的第一个例子，企业中的变更有软件的也有硬件的，有复杂的也有简单的，那么根据这种特性我们完全可以把变更分类，把简单的变更归属为简单变更，把复杂的变更（必须企业审核批准的）归属于标准变更，那么我们完全可以根据企业内部的需求或变更的性质将变更进行分类，业务部想改系统标题，那就走简单变更好了，提交批准就OK了，就不用走标准变更那么多复杂的流程了。所以说ITIL的实施不一定就是遵循死搬硬套的流程，要根据企业的需求和实际情况量身定做。楼主能走出这个弯就能了解了，呵呵。个人见解，大家讨论。

很同意楼上的观点。
流程是死的，人是活的。ITIL提供的是一个最佳实践，不能保证把它移植到哪个企业都适用。如果这么简单的话，我们又何需在这里进行探讨和交流呢？
记得有位ITIL好友的名言是：ITSM，适境而为