不管IT部门的大小，问题都是类似的，只不过以不同的规模存在罢了。从理论上讲，IT基础设施库（ITIL）模型是使IT做出正确选择的向导。今年夏天，我受到启发，采纳了一些IT服务管理的原则信条，并在我自己的Westminster学院进行尝试。我努力使我的员工适应围绕基于成本的心态而不是基于技术的思想方法，作为调整我们自己运营提升内部效率并最终给业务提供更好价值的一种方式。我们并不是要绝对相信ITIL模型，但它是一种不同的思考方式。

　　与许多IT部门一样，我们Westminster学院有许多问题——资源太少，几乎不能完成所有任务；对于组织的IT处理能力来说，任务太多了。每个人都有重要的需求亟待IT部门解决。我们被许多低效的、过时的、手工的内部流程所拖累，这些都影响了整个服务的交付。因为我们花了太多的时间重新发明轮子，我们几乎没法关注业务了。请看下面这些例子：

• 当一个IT组织非常有机地增长时，我们常常关注在机构优先事项费用上的“眼前的危机”。例如，一名IT工作人员会放下手头一切工作响应来自用户的最新请求，而不是继续关注自己原来优先的任务。结果是以整个组织的满意度为代价获得了直接的用户满意度。
• 有时，我们从用户那里接到“命令”，但实际上用户请求的工作没什么意义。例如，用户不喜欢在我们的ERP系统中输入一百条新纪录，因此该用户请求IT部门写一个一次性脚本导入这些数据，该脚本编写时间可能要比发起请求的用户手工输入这些记录所用时间更长。
• 我们的IT部门没有质疑不明确的或者不清晰的投资回报率项目需求，只是对其直接采取行动。同样，用户非常高兴，但是从组织整体来看很糟糕。
• 尽管我们已经取得了重大进展，但许多内部IT流程仍然停留在半自动状态，而且我们仍在不断地重复发明轮子。此外，由于这么多的流程仍然存在部分手工作业，所以有许多出错和低效率的情况发生。

　　ITIL的不同思维模式

　　我们需要改变方法，调整思维定势从一种非常小的组织增长技术部门的角度转变为关注未锁定商业价值和改善整个校园流程。因此，我们做了大量变更，而且还在一直做下去。
下面是一些已经采用的或者为了实现目标即将采用的ITIL风格：

• 减少请求流程。我们现在审查任务请求，以确保合适的人员在做相关工作。如果请求的是可重复应用的东西，并且最终是有一定的投资回报率的，那我们可能就会完成它。然而，我们不再为单个请求创建流程，相反，我们在初始请求阶段花很多额外的时间，使得解决方案具备一定的永久性，这样我们就不用在以后再处理类似问题。如果求的是独特的需求，最好有请求的发起者自己处理，我们会拒绝它。
• 限制项目请求。当新需求出现时，他们必须纳入明确的投资回报率。最近，我收到一个项目需求，其中不包含投资回报率数字和相关调查。我发现这个需求的投资回报率只能达到每个月几分钟，而我们需要花一周多的时间来完成它。在确保请求部门的副总裁理解这种不平衡之后，在其他VP支持该项目的情况下，我拒绝了这个项目请求。所有的IT项目都被执行团队至少每月审查一次，这样可以确保事情如何完成是透明的。
• 开始自上至下的审查和我们自己的IT流程的自动化。最近我们已经建立了一项跨职能部门的身份识别管理专案组，由IT部门领导、所有校园工作参与者都在IT项目管理中参与意见。下面是我们处理一个问题的例子：尽管我们的学生账号创建流程能自动实现是一件好事，但教职员工账户必须手工创建。这就导致在账号处理时的不一致性和不确定性，当我们没有事先通知人事变动和调整时，直接用户就会受到影响。为了解决这种低效率的问题，我们绘制了整个账号的生命周期，包括每个可能受影响的系统，然后实施了微软公司的Forefront身份管理软件来解决这个问题。通过自动化，我们实现了两个目标：我们最终减少了花在管理流程上的时间，而且我们使用了更好的变更管理技术，该技术被认为是IT服务管理系统中的一个最佳实践。
• 转变为“关注成本”的心态。我的员工已经受到了挑战，他们要考虑日常活动的软成本。例如，每天组织花多少成本来管理账目？在我们开始一个新项目之前，考虑是由内部员工完成工作更有意义，还是应该外包呢？我们并不只是把它默认加到内部项目列表中。
• 修改职位描述和评估指标。今年夏天，我重写了所有IT成员职位描述。自它们上次被正式审查以来已经有一段时间了，我将添加更多关注业务的评估指标。我需要确保激励人们关注整个学院而不是个体的需求。虽然我不想失去一次个人接触的机会，希望确保我们满足用户需求，但是我们必须确保我们真正关注那些整体业务目标，这些目标很容易被抛到脑后。

　　通过遵从ITIL模型，我们为组织提升价值的努力一直在进行。一些工作已经产生了效益，而另一些还尚未实施，但是他们都努力实现摆在我们面前的最重要的业务目标。