学习资料： 艾拓先锋论坛专家讲堂直播 300期视频回放

一般业界认为"ITSM工具不是万能的，但是ITIL没有软件工具是万万不能的“。难道引入ITSM方法就必须得有一款相应的ITSM软件才行吗？以下将从几个方面来探讨在ITSM过程中，软件支持的不可或缺：

1.1 ITSM的数据记录

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

1.2 ITSM的流程执行

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

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

1.3 ITSM的分析决策

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

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

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

1.4 ITSM的作业协作

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

1.5 ITSM的作业透明

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

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

1.6 ITSM的逻辑运算

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

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

学习资料： 艾拓先锋论坛专家讲堂直播 300期视频回放

一般业界认为"ITSM工具不是万能的，但是ITIL没有软件工具是万万不能的“。难道引入ITSM方法就必须得有一款相应的ITSM软件才行吗？以下将从几个方面来探讨在ITSM过程中，软件支持的不可或缺：

1.1 ITSM的数据记录

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

1.2 ITSM的流程执行

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

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

1.3 ITSM的分析决策

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

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

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

1.4 ITSM的作业协作

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

1.5 ITSM的作业透明

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

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

1.6 ITSM的逻辑运算

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

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