随着ITSM理念在全世界的普及，应运而生的一个独立的软件市场也在形成，即ITSM软件工具提供。下面是笔者所知的国内外一些公司的ITSM软件（估计仍有不少漏项）

这些软件的性价比不同，适用的对象亦有所区别，从数万到数百万不等，目前ITSM软件市场规模尚且有限，同时带着初生的气息，即混乱而充满生机，相信在未来的几年，ITSM的成熟与应用规模的壮大，ITSM软件市场也会成长。为什么会这样呢，难道引入ITSM方法就必须得有一款相应的ITSM软件才行吗？这其中道理是什么呢？

以下将从几个方面来探讨在ITSM过程中，软件支持的不可或缺：

一、ITSM的数据记录

以ITIL理论为主导的服务管理过程中，每个流程都有大量的数据产生，尤其是配置管理中的配置信息，事件管理中的事件信息，还有诸如问题信息、变更信息、能力信息、服务级别信息等，这大量的记录彼此还存在关联，以纸质记录不现实，电子表格无法有集成关联，搜索查询同样是大问题，仅仅一个CMDB都快成为一个独立的软件产品了，还有大量的基础数据，比如客户信息与支持团队的信息，这些都是组织与人的数据，还有大量的分类基础数据。所以在服务过程中产生的大量数据，这些数据首先要解决记录的问题，然后是查询的问题，最后是分析统计的问题。

二、ITSM的逻辑运算

在具体的服务过程中，为了保障服务级别的执行，需要在许多数据之间做关联与计算，比如当一个应用系统发生故障时，服务台需要将此故障记录下来并调度工程师解决，这时就产生一个问题，这个故障需要派给哪一个工程师解决（服务体制、忙闲状态），工程师需要多久完成故障排除？这里就需要有一个约束，为了保障服务级别得到真正的执行，需要设置这个故障的解决要求时间，同时还要考虑到服务时间的问题，即我们承诺客户的服务是5*8，还是7*24，甚至5*8中，这8小时，分别几点至几点，才是服务时间。只有这些数据参与逻辑运算，才能得到故障（事件）的处理时长，才能将时长与要求时间进行比较，以计算出按时解决率。仅仅一个事件，就需要日历数据、服务级别数据，与单据的创建时间与工程师的完成时间记录，进行综合运算，甚至在故障过程中，还需要考虑到分派的问题（从一个工程师转给另一个工程师处理），还需要考虑到等待时间，最后还要考虑事件的责任归属，这些都是保障服务的基本要求。

关联性的问题同样是需要做比较复杂的运算，比如这个事件与哪一个配置项有关系，这个事件导致了哪一些变更，或者导致哪一个问题的产生。做得比较好的ITSM软件，还会考虑事件升级，即在一个事件处理时，如果达过某一个限定条件（事件长时间没有人响应，事件超过要求解决时间仍没有得到解决，发生一个严重事件），系统会发出邮件与短信通知处理者与相关的领导。这还仅仅是从单一事件本身出来，就有非常复杂的逻辑关系。

三、ITSM的流程执行

无数的管理者最头痛的一件事就是制度或流程的执行问题，我们很多时候，花费很大的精力与资源去设计出一套制度流程，但真正实施时，在日后漫长的作业过程中，要么是制度流程被丢在一边，要么执行得变了样。这里面一方面的教育与素质的问题，还有就是我们没有找到一种有力的方法来监管制度流程的执行，为流程的执行去花费巨大的监督成本，这并不是绝大多数公司可以承受的。事实上管理软件问世，很大程度可以较好的帮助解决这一问题，ITSM作为管理软件的一种，同样有此功效。而且由于ITIL的流程界定相对比较清楚，因此带来的流程执行帮助会更大。

以变更流程为例，变更管理的核心在于评估授权，即评估一个变更能不能做，该如何做，在什么时间点做，做完后如何验证，同时导致的关联信息需要管理。当变更流程利用软件管理起来后，可以事先定义好，哪一些人有权力可以提出变更请求，哪一些有权力进行变更的审批，哪一些人有资格执行变更的实施，哪一些负责变更结果的确认检查，定义好这些角色后，结合服务体制的设置，这样当一个具体的变更发生时，各个控制点都是无法逾越的，同时大家的作业时点可以控制，同时变更导致的配置项变化，可以在变更过程中进行关联，这样避免变更与配置的流程分裂。

四、ITSM的分析决策

在具体的服务过程中，我们经常需要去许多管理改善，有一些管理改善是显而易见的，比如发生一个重大故障发生完成紧急处理后，我们一般都会进一步深入分析故障的原因，并针对性的做一些预防措施，以避免再次发生，或发生后的危害如何降低。但有一些管理改善，我们缺乏方向感，这一点做为IT服务商这种感受尤其强烈，我们总是觉得我们的管理迫切需要提升，我们总是觉得我们还存在许多问题，所以我们不断的在做管理改善，但最终总体的效果并不好，甚至方向是错的，一是许多管理改善，真正深入后会发现并非是一个点造成，而是许多原因交织在一起，是成体系性的，二是ITSM众多的流程全部是可以PDCA的，我们改善的流程可能反而不是我们的最短板，三是我们的改善缺乏一个方向与指标，具体改善什么流程，改善流程的哪一个点（绩效），改善达到的水平。

对于管理而言，分析与决策占有很大权重，当管理者的辖区范围较小、洞悉力强，他凭个人日常感受到与接受的信息就可以很好分析并做出正确的决策，这种类型的管理者仍然占绝多大数，基层的管理者更多是这一种类型。但一旦管理范围扩大，组织架构较具纵深时，这时管理者会无法采集到大量的具体作业过程的信息，同时再也无法以个人的“感觉”来做分析决策了。好象在现实的管理活动中，有一个普适的规律，我们可以看一家公司在大时间跨度做规划与计划，就能最直接看出这家公司的管理成熟度与科学性，凡是那种做年度规划或下一个年度的管理计划时，以拍脑袋进行制定的，多数是不会基于历史的数据分析，这样的计划即便做出来，执行的可能性是极低的，所以每到年底时，回顾对比年初的规划是差距甚远的，这里面就是缺乏一个有效的PDCA机制，如果我们下一个年度的重心是放在提高事件按时解决率或客户满意度提高10个百分比，那么我们非常需要按这一指标设定在日常的管理活动中，或者周期性的进行汇报与分析，并进行改善。

上述的作业过程中，必不可少的就是数据的支持，你作业过程中的表单设计决定了你的数据素材有哪一些，你的报表设计决定了你的分析结果。当有一个作业平台去贯彻与指示你的管理指标时，会很有效的让整个组织形成一种共识，大家的注意力也会集中一起。这样我们管理工作才会每年一个脚印，具有很强的持续性与科学性，而不是东来一下西来一下，好象每个层面的问题都在做，但豪无理性与战术可言。

五、ITSM的作业协作

在服务过程中，由于服务的不同，或对象的不同，亦或专业的不同，会形成多个服务团队与多种职能组，比台常见的IT服务商中，会有服务台、IDC、软件应用、终端类这种职能单位，但具体一个服务时，许多时候会在使用这几个职能单位的资源，即一个流程会贯穿整个组织内部，这时就形成一个悖论，如果我们服务要更有效率，我们应该打破职能，将资源更紧密的组织在一起，如果我们的质量、管理要更有序，我们需要按专业技能划分团队管理，以保证专业性，一个管理再优秀的公司，几个部门在协作做一些具体的事务时，一定会发生纠纷、沟通问题、职能不清的问题，那假设一个场影，如果一个客户的系统出现了一个BUG，需要服务商解决时，首先客户需用电话到服务台，然后服务台需要收集信息，然后告诉软件应用人员，这时软件应用人员需要做程序修正，然后提交测试部门测试，没有问题后，要向IDC人员提出发布申请，最后发布后还需要同客户解释原因与验证解决是否成功，这是一个很典型的故障类型，事实上为了讲解的方便还简化了许多环节与人员，这时我们可以看到，这其中的信息需要充分让每个参与处理者与审批者清楚，依靠邮件与电话是多么不现实，这些人员是不同的部门，有什么方式可以更有效的约束他的作业配合与时间呢，这时一个统一的作业平台是可以很好的发挥作用的。这样就相对的解决了那个悖论，我们不在现实组织架构中打乱专业职能管理，但我们在平台中实现虚拟组织，按最利于客户与效率的方式组建技能组。

六、ITSM的作业透明

IT或IT服务一直以来，有一个不好的倾向，神秘化有些象一个黑匣子，这里面带来许多不好的现象，客户不清楚IT服务商要这么多钱到底在搞些什么，IT服务管理者不清楚底下的员工具体在忙些什么，也不清楚为什么一个服务吞没了这么多人力，下属主管还在不断喊人力紧张，不同的职能人员也不清楚为什么上一下环节或下一个环节为什么这么慢，而横向的，一个故障解决到底是做了一些什么动作也是不清不楚的。这些现象造成的恶果是成本居高不下、人员提升难以进行、人员更替培养困难、组织的知识难以有效成长、管理决策依赖是少得可怜的信息。同时这其中会造成一种绑架效应，IT服务商绑架了客户，员工绑架了管理者或公司。

在我的理念中，ITSM软件首先是一个平台，它应该象一面镜子，可以照射出所有服务环节，暴露出所有的灰色地带与问题。每一个服务人员每天在做些什么，每个故障与作业处理到底是些什么动作，花费多少时间，全部需要透明化，一名基层管理者不应该把信息封闭在局部，我们应该可以取到任何一名服务人员或主管的作业信息，我们也应该清楚每个故障的详细解决方法与动作步骤。当我们真正构建部署好这个平台，并开始有效运行后，我们会发现许多的我们以前不知道的信息，甚至是谎言。我们也会发生其实IT服务其实并不复杂，我们的工程师的资源并没有充分的利用起来。效率与成本此时才真正摊开在我们面前，我们也会发生以前我们对主管们的工作评价原来是不公正的，当我们真正把成本、质量、效率、利润这几者的真实数据分析时，才知道我们之前的认知与管理假设的基础是荒唐的。

七、ITSM软件的选择

对于大多数的IT服务商而言，国外的ITSM软件还是太贵了，难以承受。而国内的ITSM软件真正成熟的也是相当少，我没有机会对国内每一款软件做测试评估，只能通过接触过一些来推断目前的现状，国内的ITSM软件最大的缺失是，软件本身的设计者并不具备扎实的ITSM知识与管理理念，我个人一直的认知是，一款管理软件的规划者或设计师如果对管理本身没有一定的认知，再精深的专业知识亦是无用，这不是ITSM软件一个通病也是中国管理软件的一个通病，缺乏管理思想。而国内真正对ITSM有深入认识的人目前并不多，同时对ITSM与软件设计二者都有一定基础的人才更是少之又少，这里我们可以想象，国内有几家公司有这样的开发团队，对管理、ITSM、软件设计三者同时有一定专长的，这三者还只是一个必要条件，不是充分条件，因为还要有扎实的开发实力与实施经验，这五者组成在一起才有可能使一个ITSM软件项目成功。国内的ITSM软件，一般是两条路，要么模仿起家，要么是依靠自身的业务经验跌跌撞撞成长，以这么短短的几年时间，离真正的成熟还有很长的路要长，除非有大量的客户可以来试验，这样可以飞速的积累知识经验，来做产品的升级换代。

ITSM软件的获取是两条路，要么自己开发，要么买一款。这两条路，无论是选择哪一条路，建议还是从长计议。比较实际的是花点钱请一个专业人员或公司帮助做选型评估或软件规划，这样可以少走不少弯路。规模大些的公司选择国外知名的ITSM软件同样要慎重，因为这些不是光花钱买一个好软件就够了，还需要有很好的实施顾问才行，从我看到的几家购买了国外知名ITSM软件的公司的情况来说，效果实在一般，可以用失败形容，主要原因要么是实施顾问没有真正深入实际业务做出很好的咨询意见，要么是实施顾问能力所限，再加上客户本身的执行力不足，导致了和中国企业现在上厦门OA类似的情况。

选择一款ITSM软件，就等于选择了未来许多年的作业平台，整个IT服务管理就依附于它了，要从许多方面去思考与评估，往往这些国内的IT服务商是没有专业能力来做的，就如让一个没有上过厦门OA的企业去选择一款厦门OA一样，最终变成谁的演讲公关能力强就谁中标了，最核心的对软件本身的深入评估分析反而是没有做的，所以对意欲购买ITSM软件的公司而言，多测试评估分析或者请外部专业人员来协助是保险之举。