你提出一个ITIL项目可能是因为大家都看到冗余现象即将出现，而ITIL好像是个不错的解决方案。一个出色的ITIL业务方案，其关键之处往往都是一些非常基本的东西。
对于从哪些ITIL中的流程开始、采用什么顺序、甚至到底是否要这么做或者如何决策等问题，已有很多讨论。如果流程再造的推动因素是业务方案（Business Case）的话，那么相应的选择就是对的，ITIL将会带来回报。
不幸的是，在IT方面，决策的动因往往不是具体业务。某个管理者认为（或被说服）某个想法不错，就会在回报不明的项目上浪费投资。很久以来，我们的很多IT决策都是为了让某个东西“更好”（更快、更灵活、空间更大或更酷），而没有考虑最基本的问题：我要投资回报。
如果回报低于投入，那就不能做。如果你是企业员工，你就得按企业规律办事，也就是说，要有业务方案。
业务方案是一个逻辑清晰、条例清楚的文件，并附带各种材料和证明，用来说明项目在财务方面和战略方面的可行性。它应当考虑到企业的整体战略和规划，并经高级管理层审查、批准。
商业社会中，业务方案必需证明其财务方面的合理性。没有钱就没有项目。可令人吃惊的是，很多论证都忽视了这一简单原则。
展现投资回报
业务方案的长处在于展示投资回报，包括真实的回报和想象中的回报。业务方案的战略是如何与组织目标协调一致。有实力、有策略，再加上一点运气，你就会成功。我们要说服的不是执行管理层，至少最初不是。我们要说服自己。理论上，IT不应该尝试任何无法带来投资回报的东西（尽管实践中建设和维护基本架构时很难证明这一点）。我们经常看到运营经理或CIO主观地决定采用ITIL，然后进行大量的、凭空想象出来的所谓业务方案来验证他们的决定。很多IT部门已经学会了像业务部门一样谈论问题，但是还没学会怎样去做。
因此，先来做一个业务方案，练习一下吧。它有帮助作用吗？如果没有，你为什么要把它引进来呢？它符合企业整体的根本利益吗？如果你认为它是对的，那就找出为什么的答案，并将它们写入业务方案之中。
当然，你提出一个ITIL项目可能是因为大家都看到冗余现象即将出现，而ITIL好像是个不错的解决方案。一个出色的ITIL业务方案，其关键之处往往都是一些非常基本的东西。
目标要易于实现。如果无法实现短期收益，就不能吸引底层参与者和高级管理者的注意。
收益必须实际。如果不能节省成本，你就不得不依赖于支持你的高级管理者的“决定”（即信心激增）。这个人一旦离职，对你的支持也将随之而去。缺乏明显的投资回报，面对继任者，你只能从头再来。
ITIL咨询公司Pink Elephant的某位员工说：“你在CMM3（成熟度模型）中设定流程改进的成熟度目标，分析事故数据，计算出CMM3级流程实施后事故率下降的比例。这样就可以计算出投资回报了。”好在IT运营逐渐趋于采用强大的工具，为业务方案提供支持；并应用重复性流程，以提高效率。不过，钱总是不够的，所以业务方案中要写明风险、法规遵从和战略优势等造成的“差额”。
风险。如果管理层根本不关注风险，那么这个问题就很简单。我们曾提到过如果因为审慎或近期曾出现事故而对风险特别关注，或者正好是控制预算的人面临着风险，那么降低风险就是非常紧迫的问题。
法规遵从。向审计师、风险管理经理或首席安全主管进行咨询，看他们担心的是什么。然后利用这些问题刺激决策者，至少让他感觉到威胁。如果是一家银行，就采用Basel II。安全是最明显的关注风险的领域，但不要忽略其他ITIL领域。降低储运损耗或平均修复时间，不仅可以减少成本，而且能够降低风险。
一旦对企业提出要求，法规遵从问题就很简单了。SOX法案、ISO9000和即将出台的ISO/IEC 20000，都要求在客户合同中写入流程或质量服务水平协议（SLA）。此外还有一些企业内部要求。其中讨论最多的就是“透明性”或“业务一致性”。如果这是业务对IT的真实要求，就予以采用。如果只有简单的要求，没有论证，那就不是真正的需求。