ITIL是一种IT服务的思想，一种IT管理的流程，或者具体化为一套程序系统；建立这样一套规范的服务流程，无论从改善IT服务水平，IT风险防范还是IT服务的量化，都是有很大的帮助的，但是在具体的实施中，是否应该掌握一个平衡度的问题，能否在成本与效益间找到一个平衡点？举个简单的例子：
   业务部门要求修改一个SAP R3的报表，变更的内容是修改一下报表的标题，对于这样一个需求，按照公司IT服务管理系统的流程：业务部门的相关人员在系统中提交需求申请——〉需求转到service desk，分配给相关的IT人员——〉IT人员接受申请——〉报表修改完成，申请程序TP——〉TP完成IT人员在IT服务系统上结束申请，上报审批——〉系统通知业务人员；
    对于这样一个简单的需求，中间却需要经过这么多繁琐的过程，时间延迟有时会比较厉害，往往会遭到来自业务部门和IT人员的双重抗议，ITIL是否存在让简单的问题复杂化和资源浪费？

还有这样一个问题：
       对于像硬件，网络或者服务器这样主要基于IT技术的IT服务，往往在业务部门提出相关需求后，IT人员在不需要与用户更多的互动交流的基础上就可以解决问题；
       但是对于像ERP这样与业务息息相关的软件服务，则往往需要IT和业务人员的大量交流和磋商，以准确理解用户的需求，而仅依靠业务人员提供的业务需求文档往往是不够的；
      针对第二种情况，在采用ITIL系统进行管理时，是从原始的需求就通过ITIL系统来进行交互还是在需求确定的情况下再提交到系统？如果是前一方法，这样的交流方式估计双方都不会满意，不如电话+需求文档的方式；如果是后一种方式，则系统沦为了文档管理系统；怎样处理才能发挥ITIL系统的最佳功效？

ITIL只是一个方法论，，呵呵，，至于将简单问题复杂化，不是ITIL的错，
而是国内很多公司弊病，复杂的审批流程，才是罪魁。

QUOTE:

---

最初由 kevinlieu 发布
ITIL只是一个方法论，，呵呵，，至于将简单问题复杂化，不是ITIL的错，
而是国内很多公司弊病，复杂的审批流程，才是罪魁。

---

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

这个变更请求流程确实太长了,通常只有Major Change需要这么长的路径。
如果你们公司的所有人都觉得这个过程太长了，说明制订流程的人有问题。ITIL告诉你标准变更和小变更的批准路径很短的。其实真正实施后变更经理很忙才是个问题。

你的用户部门不了解IT技术，他们只关心他们能感知的服务。所以，IT部门内部的技术问题是ITIL中OLA关心的问题；而SLA则是IT部门和用户部门之间的问题，其中的定义也往往不是IT的技术词汇。

其实这些问题在很多跨国企业中可以得到相关的实际案例。

还有个问题是审批往往不能立即执行，manager不可能整天坐在那里等着审批阿，有时候会拖上半天，业务部门又使劲儿催。。。

这种显然不会增加多少成本的事情，先执行，完成了做一份记录，定期交给经理不就成了，何必这样负责的枝枝叶叶呢。

这个明显是没有做好服务的分级。
对于一些关键的业务，如SALE部门要更改某种产品的属性，这个对于生产或者日来销售影响很大的，这当然要经过这么多的步骤去做了。这个流程还能给在这个流程中做决策的领导一个思考的时间。
但是如果是一些很简单的业务，级别可以调成低一个档次的，就是直接到Service Desk--->IT人员---->通知SALE就可以了。

QUOTE:

---

最初由 sdsdsd 发布
还有个问题是审批往往不能立即执行，manager不可能整天坐在那里等着审批阿，有时候会拖上半天，业务部门又使劲儿催。。。

---

用多种快捷的通知方式，比如短信、邮件等等，同时设置超时提醒，另外建立相应的考核制度，这样就能在一定程度上推动流程的流转。