在此希望总结或强调一下ITSM的三个固有基本特性，以及其相应的核心流程及释意：
共性——ITSM是一种基于ITIL标准的信息化建设的国际管理规范。ITIL体系提供了“通用的语言”，为从事ITSM的相关人员提供了共同的模式、方法和同样的术语，使用户和服务提供者通过有共性的工具深入讨论用户的需求，很容易达成共识。
中立——ITSM为IT管理提供了实施框架，这样可以让用户不会受制于任何单独的服务提供商。ITSM不针对任何特殊的平台或技术，也不会因下一代操作系统的发布而改变。
实用——ITSM是一种以流程为导向、以客户为中心的方法，它在兼顾理论和学术的同时，非常注重实用和灵活。
并且ITSM的核心流程包括：
服务级别管理：它的目标是通过定义、协商、订约、检测和评审提供给客户的IT服务，实现特定的、一致的、可测量的服务水平，为客户节省成本，提高生产率。
可用性管理：通过分析用户和业务方的可用性需求，优化和设计IT基础架构的可用性，从而确保以合理的成本满足不断增长的可用性需求。
能力管理：指在成本和业务需求的双重约束下，通过配置合理的服务能力，使组织的IT资源发挥最大的效能。
服务连续性管理：在尽量少中断客户业务情况下提供IT服务，并在IT系统出现问题时以可控的方式恢复。
财务管理：确定IT服务的预算，监督预算执行情况，根据服务收取费用。
事件管理：在出现事件时尽可能快地恢复服务的正常运作。避免它造成业务中断，以确保最佳的服务可用性级别。
问题管理：旨在找到问题的源头，积极地预防问题的再次发生。
变更管理：它确保使用标准方法和规程有效且迅速处理所有变动，旨在提高组织的日常运作水平。
配置管理：识别、控制、维护和检验现有的包括基础设施和服务在内的IT资产。
发布管理：目的是为了保证发布的成功，主要应用于大型的或关键硬件、主要软件及打包或批处理一组变更。
服务台：服务台不是服务过程，而是一个服务职能，目的是为用户和IT服务组织的提供一个统一联系点。
正是通过这十个核心流程和一个服务职能，实现了IT服务管理的规范化、流程化。
现今随着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或IT服务一直以来，有一个不好的倾向，神秘化有些象一个黑匣子，这里面带来许多不好的现象，客户不清楚IT服务商要这么多钱到底在搞些什么，IT服务管理者不清楚底下的员工具体在忙些什么，也不清楚为什么一个服务吞没了这么多人力，下属主管还在不断喊人力紧张，不同的职能人员也不清楚为什么上一下环节或下一个环节为什么这么慢，而横向的，一个故障解决到底是做了一些什么动作也是不清不楚的。
这些现象造成的恶果是成本居高不下、人员提升难以进行、人员更替培养困难、组织的知识难以有效成长、管理决策依赖是少得可怜的信息。同时这其中会造成一种绑架效应，IT服务商绑架了客户，员工绑架了管理者或公司。
在我的理念中，ITSM软件首先是一个平台，它应该象一面镜子，可以照射出所有服务环节，暴露出所有的灰色地带与问题。每一个服务人员每天在做些什么，每个故障与作业处理到底是些什么动作，花费多少时间，全部需要透明化，一名基层管理者不应该把信息封闭在局部，我们应该可以取到任何一名服务人员或主管的作业信息，我们也应该清楚每个故障的详细解决方法与动作步骤。
当我们真正构建部署好这个平台，并开始有效运行后，我们会发现许多的我们以前不知道的信息，甚至是谎言。我们也会发生其实IT服务其实并不复杂，我们的工程师的资源并没有充分的利用起来。效率与成本此时才真正摊开在我们面前，我们也会发生以前我们对主管们的工作评价原来是不公正的，当我们真正把成本、质量、效率、利润这几者的真实数据分析时，才知道我们之前的认知与管理假设的基础是荒唐的。
ITSM软件的选择
对于大多数的IT服务商而言，国外的ITSM软件还是太贵了，难以承受。而国内的ITSM软件真正成熟的也是相当少，也暂时没有机会对国内每一款软件做测试评估，只能通过接触过一些来推断目前的现状，国内的ITSM软件最大的缺失是，软件本身的设计者并不具备扎实的ITSM知识与管理理念。我个人一直的认知是，一款管理软件的规划者或设计师如果对管理本身没有一定的认知，再精深的专业知识亦是无用，这仅不是ITSM软件一个通病也是中国管理软件的一个通病，缺乏管理思想。
而国内真正对ITSM有深入认识的人目前并不多，同时对ITSM与软件设计二者都有一定基础的人才更是少之又少，但Servicehot有这样的开发团队，对管理、ITSM、软件设计三者同时有一定专长的，这三者还只是一个必要条件，不是充分条件，因为还要有扎实的开发实力与实施经验，这五者组成在一起才有可能使一个ITSM软件项目成功。国内的ITSM软件，一般是两条路，要么模仿起家，要么是依靠自身的业务经验跌跌撞撞成长，以这么短短的几年时间，做出来效果比较好的也还是只有Servicehot 旗下的ITSM系统。
其实ITSM软件的获取是两条路，要么自己开发，要么买一款。这两条路，无论是选择哪一条路，建议还是从长计议。比较实际的是花点钱请一个专业人员或公司帮助做选型评估或软件规划，这样可以少走不少弯路。规模大些的公司选择百万级别的软件同样要慎重，因为这些不是光花钱买一个好软件就够了，还需要有很好的实施顾问才行，主要原因要么是实施顾问没有真正深入实际业务做出很好的咨询意见，要么是实施顾问能力所限，再加上客户本身的执行力不足，导致了和中国企业现在上ERP类似的情况。
选择一款ITSM软件，就等于选择了未来许多年的作业平台，整个IT服务管理就依附于它了，要从许多方面去思考与评估，往往这些国内的IT服务商是没有专业能力来做的，就如让一个没有上过ERP的企业去选择一款ERP一样，最终变成谁的演讲公关能力强就谁中标了，最核心的对软件本身的深入评估分析反而是没有做的，所以对意欲购买ITSM软件的公司而言，多测试评估分析或者请外部专业人员来协助是保险之举。
