在IT服务管理过程中，服务与被服务的双方都有着道不尽的“伤痛”与“困惑”。

    随着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软件的公司来说，效果实在一般，甚至可以用失败形容，主要原因要么是实施顾问没有真正深入实际业务，做出正确的咨询意见，要么是实施顾问能力所限，再加上客户本身的执行力不足，导致了和企业现在上ERP类似的情况。

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

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。