怎么有效地实施ITSM流程
ManageEngine总结了以下最佳实践“干货”，这些内容可以帮您简化ITSM流程的实施，并更加有效地对其进行利用：
1、审核ITSM运行情况并找出“缺口”
在实施ITSM流程之前，首先应明确组织的早期目标，然后逐步进行。在实施IT服务管理工作流时，没有对任何问题通吃的解决办法。因此，细心确定ITSM流程在IT区域的哪个位置非常重要，以及让合适的人参与进来，部署相关技术，选择正确的工作流程，分析潜在的风险，为任何情况下的突发状况准备好恢复、后备策略。
2、建设ITSM流程时，时刻与相关者保持互动、沟通与培训
根据麦肯锡的报告，70％的变更项目失败，是由于管理层不能或不愿意帮助员工执行变更。为防止这种情况，您的组织需要树立一种积极接受改变的文化。为做到这一点，需要：确保所有利益相关者都能够认识到所制定的战略，以及实施ITSM流程所带来的好处，并通过会议与与所有相关人员进行沟通，而不仅仅是核心实施团队，以确保所有涉及的人员都能够达成统一的共识。
3、找到关键因子，密切关注KPI和指标的变化
随着ITSM实施的推进，您的团队需要使用一些指标和KPI来定期监控IT服务台的性能，为服务交付的持续改进提供基础保证。利用ITSM工具内置的报告功能，您可以生成具有深度和细粒度数据的各种报告，帮助进行性能分析和决策。虽然定期分析KPI是有必要的，但真正的诀窍是采用正确且合适的的服务台指标和KPI，这将帮您避免在一些无关紧要的指标上浪费时间。这些关键指标有：
营业时间损失（Lost business hours）
因IT服务不可用而导致业务中断的小时数。
变更成功率（Change success rate）
在给定时间范围内，成功更改数量与执行的更改总数之比。
基础设施稳定性（Infrastructure stability）
高度稳定的基础结构具有最高的可用性、极少的中断和较低的服务中断。
工单数量趋势（Ticket volume trends）
在指定时间内，IT服务台处理的工单总数及其趋势。
首次呼叫解决率（First call resolution rate）
在第一级支持下（用户首次致电或与IT服务台联系），解决的事件百分比。
SLA合规率（SLA compliance rate）
在商定的SLA时间内解决的事件百分比。
每工单费用（Cost per ticket）
IT支持每月总运营支出除以月工单数量。
软件资产利用率（Software asset utilization rate）
企业实际使用的软件产品与许可的百分比。
事件响应时间（Incident response time）
响应事件所花费的时间。
事件解决时间（Incident resolution time）
解决事件所需的时间。
重新打开率（Reopen rate）
解决后被重新打开的工单数量。
问题解决时间（Problem resolution time）
从发现问题到解决问题所花费的时间。
4、使用工具，自动化流程
IT服务台管理解决方案通过提供开箱即用的最佳实践流程和工作流，简化了ITSM流程的实施。大多数帮助台软件都支持自动化、实时分析、自定义ITSM流程等等功能，再辅以正确的流程，IT团队的工作重点将可以从被动救火式转移到以战略业务目标和增长为驱动力的模式上来。
选择适合自身IT需求的IT服务台工具也很重要，对于企业或组织机构，不应该盲目的投资于高端工具或寻求具有广泛支持能力的工具，通常情况下，一次ITSM的实施过程涉及不到所有工具或实践的所有功能或流程。投资这样的ITSM工具是最明智的：可以满足您当前大部分的IT需求，具有有可定制和灵活性，良好的实用性、对用户友好、能够与其它IT工具集成，并具有在将来能够平滑扩展的能力。
5、建立一套有效的反馈机制
高效的ITSM策略不会随着实施完成而停止，而是随着时间的推移不断的演变。对于组织而言，利用其ITSM流程来实现定义的业务目标非常重要。因此有必要建立一套有效的反馈机制，这些反馈可以是来自最终用户，也可以是其他利益相关者的。您的IT团队需要尽可能多的收集这样的反馈，确定用户痛点，可视化他们的期望状态，进而制定进一步改进的蓝图。通常，反馈信息主要在于技术支持、功能要求，以及一些用户界面功能的改进等领域。同样重要的是要注意，用户反馈有时可能不会为团队带来那么大的帮助。为了获得良好的、建设性的反馈，调查问题应精心设计且具有具体指向。以下是最终用户反馈的示例：
不好的反馈：“您的IT技术人员很棒。”
好的反馈：“您的IT技术人员处理请求的方式很棒。我的销售代表小王完全知道我想找什么内容，并帮我找到了可以节省大量时间和精力的外接程序。我也可以提些建议：如果外接程序可以在Office365中使用，那就太好了。总之，我绝对会把您的帮助台工具推荐给其他人。”
虽然第一个例子是积极的，但它太简单，并没有提供什么实质性、建设性的内容。而在第二个反馈中，不仅仅对产品团队服务提供了认可，同时对于产品功能也提出了改进性的建议，而这是正式我们寻求用户反馈的意义所在。