四.服务台管理
事件管理与服务台管理是不同的概念，前者是一种流程，后者是一种职能，许多人没有搞清楚这两者的关系。事实上事件管理的许多操作是由服务台人员完成的，服务台本身并不存在流程(注意这是站在ITIL流程的层面)，服务台管理本身也是一个独立的学问。
这要根据每个组织的特点去考虑，在我们的情况中，有几名独立的热线人员作为服务窗口。对这些人员的话务管理是通过语音系统管理的，而这个语音系统与我们的ITSM系统是有接口的，真正的事件操作事实还是在事件管理中完成。
五.事件管理
事件管理是创建、处理事件的模块，一个事件的生命周期全部会在此模块内。在设计时，需要考虑以下的信息：
①事件的类型：事件管理在我们规划中，是一个非常重要的窗口模块。事件类型我们分为了有故障、请求、咨询、新需求、投诉，基本上面向客户的事务都会在此发起，这种类型也是为了日后的统计分析。
②事件的分类：由于项目众多，考虑到横向统计的需要，我们要定义一个公用的事件分类，以便运维管理分析。我们分了硬件、软件、网络、数据库、接口、业务这几个大类，日后可能会进一步细化分类，以便做更深入的分析，但这个难度很大，需要时间的积累。
③事件的等级：最开始我们希望引入优先级(严重度与紧急度)，但发现这样定义非常困难，对指导工程师处理意义不大，还可能会误导信息，所以最后把事件硬切为5个等级。公司给出最粗的定义标准，然后由每个项目具体定义解释。这样每个工程师在作业时，就可以定义事件的等级。默认情况下，等级越高的事件，表示越严重，也表示要优先处理。虽然会相对粗放一些，但简单适用，而且我们的SLA是与此相关的。
④事件的状态：事件状态是为了表达事件单当前的处理状况，我们分了创建、分派中、处理中、等待中、解决、关闭。这样可以形成看板与统计。
⑤事件与CMDB的关联：CMDB的用处，在事件的应用就相当关键。事件发生时，要做一个关键动作，就是组件定位。需要搞清楚这个事件是发生在什么项目(CI)的什么地方(CI)，需要事件创建者做出定位;然后派单时，根据你的CI定位，带出相关的责任工程师，与事件与CI的关联，给你的运维分析带来丰富的信息。你CMDB所有的信息与事件的信息可以交叉统计分析，比如上面说的事件的分类有硬件，那我想知道桌面项目一年中，硬盘发生了多少故障?希捷品牌的硬盘发生了多少故障?客户对哪一款软件的咨询次数最多?这些信息依靠事件中的组件定位，可以轻而易举告诉你。
⑥事件与其它流程的接口：事件与变更、问题、知识库是存在接口的，事件处理过程中可以直接发起变更申请，也可以发起问题申请与知识库申请。需要说明的是事件与变更的接口，我们的事件是否关闭没有硬性判断与之关联的变更是否终结，而是从事件单方面流出信息，并没有把变更的处理情况与事件单关联，让这个流程分线程去作业处理。主要是担心做得太死，可能导致事件单关闭受阻。
⑦事件的时长与工作量：在任何一个事件的处理时，对于时间有二个概念，一是事件的时长，即一个事件的处理周期(从8：00创建到12：00解决，4小时);一是事件花费的资源量，即工作量(4小时的时长中，工程师可能投入了2小时来处理)。时长是为了SLA的计算，后者是为了运维资源的分析。
⑧统计分析：事件报表的统计分析非常丰富，可以从CMDB的角度出发，去统计每一个项目、每一个设备的事件情况;还可以从客户的角度出发，统计某个客户组织或某个客户的事件情况;还可以从运维组织的角度出发，统计我们的一个服务团队或一个服务人员的事件情况;可以从事件本身的信息出发，根据事件的类型、分类、等级、状态、来源(电话、邮件、WEB)去统计，还可以统计SLA方面的数据。
六.问题管理
问题管理处理逻辑其实是类似事件的，它的许多信息是继承事件，比如等级与类型等。在规划问题管理时，要想清楚问题的分类等级等信息跟事件是什么关系，问题管理的大概作业界面有哪一些，在系统流程上有哪几个步骤，如何留下问题的处理时长与工作量等等。
七.变更管理
在ITIL中，变更与发布是两个独立的流程，我们把这个流程合并为一个。发布的控制在程序中可以实现的控制点是很少的，而且它与变更是如此紧密。在我理解中，变更的实施就是发布流程，即发布可以理解为是变更的一个子流程。发布不仅仅是针对软件的，硬件一样也会有发布的概念，比如将一台新设备布署到生产环境中。