我从ServerFault上的“关于系统pipe理员作业的Joeltesting”中看到，没有人说公司最好使用ITIL，否则他们不会在那里工作。 事实上，没有人提到ITIL。
ITIL是否是一种时尚？ 实践起来太麻烦了吗？ 你必须要有一定的规模才能使ITIL工作良好？
“事件”与“问题”的ITIL定义很有意思，但是在快速的帮助台环境中，组织是否真的发现区分这两者有用呢？
绝对。 ITIL并不是一个必须遵循的十条诫命。
这只是一个基础或框架来运作。
真正的问题在于解释。 如果你把ITIL的规范变得比实施更容易，那么它将永远不会工作。 但是，如果执行得当，IT服务水平提高，系统pipe理员的压力就会降到WAAAAY！
任何以教条式方式实施ITIL的人都是傻瓜（他们告诉我，在“官方”ITIL课程中）。
你可以/应该适应和采纳它的一部分，以满足您的需求。 对于一个IT人员商店来说，尝试和实施ITIL显然是一件非常困难的事情，当时变更pipe理，发布pipe理等各个“领域”之间的大多数对话实际上都是在一个人的大脑内进行的，但是在另一方面，如果你刚刚获得了一笔财富，可以成为微软或惠普或苹果公司的内部服务台经理，或者是遍布全球各地的用户和服务台电话中心，那么你怎么可能在没有ITIL的情况下完成这项工作？类似的指导方针？
在这一点上，我真的应该补充说，我们已经为我们的服务台实施了事件pipe理和问题pipe理，并且非常有帮助。
ITIL不是一个开/关的决定，你逐渐推出与你的环境相关的事情，并处理组织中最大的摩擦/痛苦的领域。
例如：如果您的服务台被请求淹没，有助于开始对它们进行分类，分析来源并决定采取什么行动来缓解这种情况。
这实际上只是一套已经certificate可以在组织中运作的最佳惯例和规则。
我最喜欢ITIL的是，它定义了与其他公司的IT专业人员交stream时使用的通用语言，在欧洲多语言多文化环境中更是如此。 …
问题pipe理，问题pipe理等等的理解和意思是相同的。
除此之外，我同意罗伯特·莫尔（Robert Moir）的看法： 任何以教条式方式实施ITIL的人都是傻子
ITIL是一种工具，不是你的救赎。
根据我的经验，ITIL也是一个框架，它允许支持人员和IT人员坚持反对来自业务的无理要求，实施技术问题的真正解决scheme，而不是“快速修复”和“我们现在需要CUZ这么酷！ “ 需要。
我曾经在一个使用“业务变更”作为借口来摧毁，绕过或覆盖几乎所有试图实施的标准IT（硬件，软件，authentication系统，存储系统等）的组织中工作。 那家公司购买了一家在支持模式中生存和呼吸ITIL的公司。
我向新公司过渡，不仅对IT人员来说生活更美好，而且从长远来看，业务更加快乐，因为他们获得了一个稳定的环境，实际上他们得到了更好的支持，新的技术更快，因为有定义的标准支持哪些饲料定义的技术标准。 当一个标准升级时，我们知道我们的升级path是什么，我们知道它可以应用到我们部署的系统的很大一部分。 这使我们能够更快地沿着这条道路前进。
我们仍然有一个允许业务部门和各种应用程序开发者请求“特殊”设备或服务的方法，但是由于我们要收取费用，所以对于那些请求它的人来说，这是非常“昂贵的”预算。 ITIL框架为您提供了
是的，但是当你的时候，你为什么不仔细看看你的组织程序和支持要求，与经理和用户谈谈，他们期望什么样的支持水平，如果他们之间进行折衷。 然后logging这个和你做工作的过程。 你实际上做的和所有这些ITIL / ISO的东西都是一样的。
了解像ITIL这样的标准使得上面的任务变得更加容易，因为你有一个框架可以提供正确的问题来完全覆盖任务，但是最重要的是关于以下方面的文档：
将文档分解到最低的实体（如单个任务）是非常多的工作，但只要您这样做，您可能会发现现在手动完成的大量任务是不必要的，可以自动化和/或可以委派。
对组织进行深入严密的审视从来不是stream行或容易做到的事情，但是这会使公司更好地了解，并且通过停止不必要的事情和将工作分配到更低的薪酬来帮助您获得更多的利润水平。
真正会让你不受欢迎的是，当你做这种标准化的时候，你经常会无意中描述了许多pipe理层因为他们自己而存在，而将他们切割出来可能会提高沟通和性能。
ITIL的理念很有意义，不幸的是，根据我的经验，这通常是支持/操作人员解决问题的工具，而且会减慢业务变更的速度。