两个方面的工作要做，一方面是清晰目标并梳理流程，同时利用技术手段提高效率。另一方面是为了持久的提供价值，而建设的潜力和能力机制。

IT工作的目标，我总结应当有三个：一是准时交付有质量的软件项目，二是保障IT系统的稳定运行，三是及时响应服务请求。

运维与保障

针对IT系统的保障不是出了事以后救火的思路，而是如何让事情根本就不出现。因为定位故障，解除故障是技术问题，而实话实说，在今天这样一个品牌繁多，种类广泛的IT系统世界里。那一款独立的工具，都只是从一个层面或维度去判断故障，也就是使用任何一款系统去监测IT系统的运行状态，都会出现死角和盲区。

对于IT系统的观测，我认为既应当有集中监测的统一视角，也应当有单个领域的显微镜视角。当然这些是技术手段，不是今天的主题。今天的主题是我们应当向医学界学习，如何能够保障健康，而不是急救。也就是针对IT的隐患预防，而不是基于监测的救火处理。

海恩法则指出： 每一起严重事故的背后，必然有29次轻微事态和300起未遂先兆以及1000起事故隐患。

那么，如果我们能够识别这些隐患，发现这些先兆，处理这些事态，我们是否可以避免这些故障。这就需要我们有隐患和预案的积累，并且有对隐患的监测和记录，以及对隐患处理的持续跟进的闭环管理。然而我们今天的许多工作是不足的，我们缺少应有的隐患库，大多数预案是针对极端情况的，是针对已经发生了故障的，而不是针对日常隐患的。我们也少有隐患的处理记录，甚至隐患是否都被解决也无法跟进和管理。

这需要IT部门做到，事前：系统化的描述IT系统的逻辑，识别系统薄弱环节，进行隐患与预案的管理。事中：能够监测到，并自动化记录隐患的发生，形成事态单，并进行自动化派发，持续跟进事态的处理。事后：对隐患发生的频率、规律、趋势进行统计。

服务响应

服务目录里面是一些围绕核心应用而展开的典型服务事件清单。那么服务目录的作用可以说是用来界定服务范围的，而这个范围的界定绝对不是为了推卸服务义务，而是为IT部门对这些典型服务事件的性质进行观察和分析的一个基础。也就是这些服务行为的性质是什么，该如何服务。

我们建设一个系统的目的，不是要达到人告诉系统，我干了什么，然后量化工作这么简单。而是应该做到让系统告诉人，你应该干什么，应该怎么干。通过系统化的系统，来实现的也不止是流程和规范。我们的理想不是简单的实现流程（为了流程而流程，为量化而量化），如果流程和量化是我们的目标，那就完蛋了，因为它无法带给团队一种应有的状态。我们的理想是，按步骤阶段化的实现以下状态：

[if !supportLists]·     [endif]首先、通过集中服务台和规范化的流程，减少多对多的混乱情况，并实现系统告诉人应该怎么干；

[if !supportLists]·     [endif]然后、通过规范化服务流程，把低价值的服务外包（或交给新员工），把精力转移到核心服务上。

[if !supportLists]·     [endif]再然后、通过流程化，逐步实现调度中心旁路，真正做到资源调度的定位。

[if !supportLists]·     [endif]再然后、通过把服务目录与知识结合，逐步让业务用户实现简单问题的自助。

[if !supportLists]·     [endif]最后一个目标是通过服务数据，找出需要改进的环节，以达到持续改进的状态。

[if !supportLists]·      [endif] 

除此以外还需要量化业务客户的满意度，让业务部门对当前提供的服务及服务质量，从印象转变为理性。当一个业务用户提交服务请求时，他应当能够看到，这个服务将在何时为您解决，这样一个预期的结果。同时这个预期结果应当成为这个服务单处理人的预期目标，并开始计算剩余时间。用户在服务完毕以后，应当按每一个服务单填写满意度。

Ahoova介绍：

珠海国津软件凭藉多年的行业经验知识积累、自2009年开始自主研发基于ITIL V3和ISO20000国际标准推出的IT服务管理系统（ITSM），产品国际化程度高，面向全球市场；包括基于ITIL框架的各类相关功能模块：门户管理、请求（事件）管理、问题管理、变更管理、发布管理、配置项（固定资产）管理、知识库管理、服务级别管理、云端SaaS应用、手机端应用等等，功能齐全。整套系统以JAVA开发，B/S结构，历经多年的市场锤炼，产品精细化程度高，可维护性、可扩展性、安全性、跨平台能力、客户自定义能力等等都得到了广大客户的认可，并且可以集成其它的第三方主流企业级应用系统、呼叫中心等等。目前该产品广泛应用于海内外的金融、物流、高等院校、政府机构、制造业及IT外包商等领域，并且在不断地依据客户需求、市场要求快速迭代更新。

官网链接：www.fuwuguanli.net