ITIL服务目录最佳实践
组织机构不应将服务目录本身视为最终的目的，而应将其视为高效交付服务和实现更广泛业务目标的一种手段。ManageEngine卓豪总结了一些行业最佳实践，帮助您将ITIL服务目录转变为向最终用户、服务台团队和整个业务交付价值的工具。
1. 从最常用的服务开始
关于如何定义服务交付是最重要的步骤之一，在描绘您所提供的产品服务时，从最常见的服务开始，此外，在服务目录中涵盖机构中其它类型的常见服务，有助于在终端用户之间推广您的服务目录。
2. 培训用户以促进早期的应用推广
当服务目录首次推出时，终端用户可能需要一些时间来适应它的操作。为了简化这个过渡的过程，IT部门和管理层应该举办用户培训研讨会，让终端用户了解服务目录的优点以及如何使用它。这些培训计划有助于在早期尽可能的使服务目录在终端用户层面得到应用。
3. 定期与利益相关者互动
涉及服务或利益相关者的咨询不仅仅是在您服务目录设计时使用的。它是一种持续的实践，必须定期执行，以衡量终端用户的满意度和服务目录对您的业务的价值。
与服务或利益相关者互动的一些例子：
用户服务调查：
在每个服务请求完成后发送调查，以确定您是否交付了令用户满意的服务体验。利用这些调查结果，描绘出您的IT部门的用户服务体验轮廓。
每周或每月数据汇总：
召开涉及IT团队成员、管理人员和不同的终端用户组的会议，讨论服务目录的性能，接收改进建议。
4. 为所有服务产品创建完善的SLA
SLA是服务交付的基石，除了执行服务目标之外，SLA还为用户设置了预期标准。
为特定的服务创建SLA是非常重要的，它定义了服务的目标标准，并在违反时提供升级机制。建议创建一个主动升级过程以防止SLA违规，提高最终用户满意度。
5. 自动化日常工作，使服务台更有效率
及时满足服务请求是每个服务台的重要目标，利用自动化的方法来处理日常工作或重复性的任务，是减少与请求相关的周转时间改善用户体验的重要方法，如自动执行工单分类、指派支持代表和审批通知的处理等。
自动向终端用户发送更新信息可以进一步优化服务的实现过程，终端用户不必不断的联系服务台，或创建重复请求以期获得其请求的处理进度。
6. 将关联性服务合并到一个产品中
根据常见的需求合并服务可以简化服务目录。一个典型的例子：员工入职，员工的入职会涉及多部门/团队之间的协作，如提供办公设备、设置IT服务的访问权限、分配计算机等等，诸如这些内容可合并到单个服务中，对于申请服务的终端用户来讲，消除了繁琐的服务提交工作，也利于其选择正确的服务。
7. 提供用户友好的界面
通过直观、易于访问的界面，使终端用户能够轻松地提交请求。例如，如果终端用户必须为简单的需求填写繁冗的表单，他们会感到沮丧。
充当服务目录门户的自助式门户需支持终端用户通过不同平台（如移动应用程序或网页）访问。列出最常用的服务，以减少终端用户搜索这些服务的时间。
仔细考虑服务目录的用户体验将有助于服务台提供更好的用户体验，从而增加服务目录的使用率。
8. 制定良好的度量标准，并根据它们采取行动
当您的服务目录开始运作后，服务台将生成大量的数据。服务台经理常常会希望通过大量指标分析这些数据，但是其中许多指标对可操作性并没有实质性的帮助。这里有一个简单的经验法则来判断度量是否有用：
S -明确的，M -可衡量，A -可操作，R -可重复，T -及时
关注那些符合上述标准的可度量数据，根据分析结果采取必要的行动。。
服务目录是随着业务和客户的需求变化而不断发展的。为确保您的服务标准保持不变，您需要以这些度量作为您的指南并进行及时改进。
常见的ITIL服务目录误区
ITIL服务目录是一个非常好的工具，可以无缝地组织和交付服务，同时将组织的服务与业务目标保持一致。但是，组织机构往往因各种原因，服务目录计划未能达到预期的ROI。
远离“IT术语”
组织最常犯的错误是用技术术语而不是业务术语定义他们的服务目录。在定义服务属性时避免使用技术术语，可以让终端用户更容易浏览和请求服务。
避免过于细致的分类
在对IT部门提供的所有服务进行分类时，要注意避免非常细粒度的分类，因为这可能会导致终端用户难以搜索和请求所需服务。
目录层次结构应该简洁，避免提交服务时过深的类别层次结构。
创建请求后不要停止与请求者的沟通
请求者希望能够看到请求的实现过程。许多组织机构不让请求者知道他们的工单的状态，导致重复的电话或电子邮件，甚至重复的工单。组织机构需要确保IT服务台在与最终用户交付服务的整个生命周期中都与他们保持沟通。
不要假设终端用户的需求
没有按照最终用户的期望和业务目标组织目录是许多服务目录计划失败的原因之一，IT部门不应过分遵循基于自己的假设，由内到外的来定义服务，他们需要了解如何充分使用IT资源，以业务结果为导向来制定服务。
点击“阅读原文”，了解并预约基于ITIL的帮助台演示。
