半个京东市值的servicenow

第1章 servicenow概况

几年前，在gartner的魔力象限中看到过servicenow这个名字，由于身处金融行业，对saas偏保守的态度，并没有太多关注。今天，servicenow是全球itsm领域领先的独角兽企业，提供saas的解决方案，是全球三大saas公司之一, 作为对itom的发展持续保持关注的从业者，很值得我对servicenow进行一些分析。所以，借着前期与servicenow公司一次交流机会，以下汇集一些非严谨的研究内容。

注：以下对于servicenow的一些研究意见仅为个人判断，不一定正确。

1.1 servicenow整体情况

开篇前，先看看最新的servicenow的市值数据，对他的体量有个直观的感受（300亿美金略高于京东的一半市值）：

servicenow在世界范围内多个地区设立了分支机构，在中国大陆最近的两个分支机构是中国香港和新加坡（同时设立了数据中心），代理商基本上都为中国香港公司,中国大陆的客户主要是跨国外企在中国的分公司。从gartner的分析数据可以看到servicenow产品目前的位置：

servicenow的产品以itsm为核心，产品的功能结合了saas的特点，以简化工作、提高效率、控制风险思路，在设计上结合了日常功能所涉及的人、流程、自动化工具等方面的工作，加上itsm最佳实践，进行了全面的整合，引领客户的IT管理可持续发展。

对于产品功能的本身，有几个突出的优点：

• 使用简单，高效协作办公，可视化效果好；
• 真正以服务化的理念进行流程设计，提供如何更高效的解决问题能力，而不仅仅是传统ITSM中以流程审批为目标的设计；
• 结合CMDB对运维工作的多个场景进行了整合，包括人员、资源、流程、数据统计分析等整合；
• 统一整合到云端，可以利用实时的数据分析提高工具的能力，促进工具用户能力提升，在产品迭代优势明显；
• SAAS化的产品更能看到未来预期收入，这个角度上明显好于私有化的产品，所以他们估值好于传统的big4的itsm产品，利于servicenow的发展；

serviceNow在国外saas领域的itsm属于绝对领先位置，从我的了解看，在国内目前仍属于起步阶段，可能有以下原因：

• 因为SAAS产品，国内能够买得起serviceNow产品的公司，可能还不能接受saas的理念，而且serviceNow有些优势是建立在SAAS的基础之上，比如经验的共享，高可用等。
• Itsm是建立在企业运维流程服务管理的基础上，但由于国内的ITIL的理念普及程度还不够，每个企业在落地上都会有差异，所以国内的企业在选择产品时更希望有客户化需求，且最好提供客户自助式的功能、流程设计功能。在这方面来看，国外的产品在国内的落地能力普遍会弱于国内产品。
• 在国内推广过程中，主要遇到两个问题：

- 响应速度，最近的数据中心在中国香港和新加坡，有对通过互联网访问方式访问速度慢的担忧。

- 数据安全，系统数据需要保存在中国大陆以外的数据中心。

• 目前在国内的客户主要是外资企业，比如上海路虎、麦当劳。有些国内公司又在中国香港代理商手中成了国内的代理。

1.2 servicenow是做什么的

servicenow公司以itsm为基础，并扩展到itom、itpm、信息安全等产品，从我个人理解，itsm以外的产品并非顶级，但强在能提供一整套从运维、运营管理的整体解决方案。为了更好的理解servicenow，可以尝试将他作一个对标：

• 相当于云端的BMC（擅长本地化部署），提供SaaS化ITSM服务。BMC的remedy作为ITSM在国际上领跑者，公司创始人曾是bmcremedy的一个合伙人，servicenow的产品与remedy产品会有些类似，有评论说是90%以上的相似度（网上有报道说两者还曾有专利纠纷，最终以servicenow赔偿的方式解决，不知真假），servicenow只在saas领域发展，有自己的生态圈，二次开发快；
• 相当于服务领域的SAP（著名的ERP软件公司），将企业人财物进销存信息都整合在一起，提供有价值的数据服务；
• 相当于Atlassian（全球排名领先的项目协同公司，走开源社区商业化路线，与软件开发者分享软件销售收入）；

从官网的介绍资料看，大致有以下的能力：

1.3 研究servicenow的意义

关注servicenow的人当中，有些人是因为servicenow市值高，想了解一下一家以itsm为核心的新兴企业服务公司是如何反超传统big4，他是如何形成一个生态，如何保持功能、解决方案的不断有序的扩展；也有些人是因为对saas应用的看多或看空的站队心态去研究，研究saas化带来的优势，它的itsm、itom、itpm是开展；也有些人是从itsm的产品功能设计角度去研究它，看看它与传统itsm有什么区别，企业的itsm应该如何建设才能具备高扩展性。作为甲方使用者，我重点以第三种视角对servicenow的itsm进一些偏功设计角度的调研，主要感受有三点：

• 以人为本，整体的功能整合很自然，细节的交互设计体验好，可配置性很强，很多细节设计上都很贴心；
• 以服务场景为导向，整合数据、资源，构建一个相对完整的IT服务场景，并非以一个it流程审批的角度进行建设；
• 售前的专业素养高，从沟通前的背景调查，沟通交流中的方案提供的细节中都能让我们甲方感受到我们是VIP，他们在为我们特定客户定制解决方案；

本篇的内容主要是从第2点的产品功能设计角度进行扩展，其中第2章主要是看看servicenow如何设计大家关注的几个IT服务，相关的图片使用servicenow测试用户试用截录，第3章则是我对itsm建设的一些零散认识的整理汇总。

第2章 从运维主要的IT服务能力看看servicenow的设计

itil V3中定义了26流程，本章主要从服务目录、事件、问题、变更等7个主要的服务能力进行分析。

2.1 服务目录

“你觉得运维人员的工作范围是哪些？”

“我觉得所有和‘电’有关的事就是运维人员办的事”

很多业务人员对运维团队的认识就是上面所说的和‘电’有关的工作，这尤其体现在一线业务运维人员的常规工作当中，我们除了要处理各种计算机、网络设备、服务器和一些应用的故障外，当用户最到复印机故障、电话通讯故障、传真机故障、饮水机坏了等也向运维求救。我们先不讨论如何为业务人员提供更好的服务，因为做对的事情通常比把事情做好更重要，它需要运维组织依据自身资源配置情况提前定义好服务目录，即“我能提供哪些服务”，有了服务目录能聚集资源将这些服务做得更好，能为企业提供有保障、有承诺的IT服务能力。在实际的itsm服务目录建设过程中，可能会关注以下几点：

1）具备完整且支持快速调整的服务目标

• 具备高效检索服务支持的功能设计
• 具备完整的IT和业务服务列表
• 支持流程的个性化定制
• 支持流程页面的所见即所得的拖拽方式实现
• 提供丰富的服务模板，进一步促进流程的定制

2）可灵活定制的工作台

• 针对不同的用户提供标准的用户工作台模板，供多维度的用户选择
• 提供流程信息的整合组件，减少用户的难度，提供用户可定制的工作台内容
• 促进用户形成自助服务的工作习惯，提高IT服务转型

3）流程自动化、可追溯

• 流程自动化程度高，提供自动通知、提醒、历史及当前流程可追溯
• 整合自动化工具，将工具的审批环节剥离到服务平台，工具主要实现操作层面的控制

针对上面几块内容，servicenow提供了这样一个更接近一个小白消费者的服务目录，相关服务目录和统一的IT服务台做了一些整合，以下摘录几点：

• 构建一个简约的IT服务简搜界面，并提供几个主要服务工具的入口，比如服务台：

• 可以看到主要的服务目录列表，选择需要的服务

• 简约的服务创建与透明的服务处理反馈设计

下面这种透明的服务处理反馈信息的设计特别的棒：

2.2 事件管理

“运维不怕故障，就怕故障处理不及时、不够快，或重复故障。”

当IT系统出现紧急故障时，需要运维第一时候解决问题，恢复系统的正常，所以事件管理的宗旨是最短时候恢复故障，从而将故障的损失降到最低，在此前提下尽可能满足服务的要求。因此，事件管理突出的就是恢复企业的业务，启用备份，容灾系统等手段，第一时间采取各种措施来恢复企业生产，这就要求服务台将紧急故障定义为最高优化级，从而确保工单的快速流转，通过各IT部门密切配合来排除故障。需要考虑事前、事后、事中处理，以事件管理的故障处理为例需要考虑的因素包括事件登记、影响判断分析、问题定位、故障恢复、故障协同、故障经验汇总、事后统计等过程。

将上面的事件管理思路进行归纳：“制定各项保障措施，尽早发现潜在问题，协同高效的完成事件恢复，保证服务质量与可用性水平，并对事件管理进行举一反三的持续优化。”，在itsm中可以为事件管理提供以下能力：

• 视图：基本视图为事件创建（接收、自建）、处理、关闭、分派、问题（或变更、操作维护、参数）等其它审批流程，同时关联监控事件整合工具。
• 事件管理的最终目标是系统的可用性的持续提升，事件管理模块的设计也应该以在事件的事前、事中、事后过程中的场景进行整合，可以考虑整合影响判断、问题定位、故障恢复、故障协同、经验库等工具，实现事件或故障的一体化处理能力。
• 定好事件最小录入要素，不同事件定级，录入要素不同（事件的定级由ECC值班经理牵头界定）
• 事件录入要素需考虑到经验库、事件分析（重复事件、事件类型、处理时效、关联关系等信息、问题流程的关联的获取）
• 提供事件数据的分析报表功能，可自定义查询方法，支持导出功能
• 支持事件人员的分派，结合值班、组织结构等因素，具备全流程的闭环机制；
• 与监控事件丰富联动，减少录入要素，提供事件接口

同样看看servicenow的几个解决思路：

• 整体化的仪表板，以查看事件概况：

• 采用可拖放的协作处理事件，一目了然

• 建立一个针对重大事件处理而设计的应急场景，是一个升级机制：

• 事件创建过程中与相关工具关联，提高事件处理效率，减少重复事件录入，比如与知识库关联：

• 与监控事件数据关联的设计，辅助事件定位，比如性能数据。

2.3 问题管理

“这是重复事件，事件根源解决方案己提交XX处理”

“然后呢？什么时候能解决，现在谁在跟进，有什么困难？”

“……”

问题管理与事件管理的区别在于，事件管理目的在于恢复服务，而问题管理在于找出IT事件的根本原因，制定并跟进解决方案，防止类似故障的再次发生。其流程是创建问题，相关负责人对问题进行评估，然后提交解决方案，并有渠道提供问题解决的跟进。问题管理能够找出故障的根本原因，举一反三，减少重复性问题导致的生产事件或故障。问题管理的生成可以是从事件管理流程引出，也可以根据一些风险、头脑风暴等方式引出，需要在其它流程，包括事件管理流程、服务台等功能中快速生成问题。

在问题管理的整个环节中，最大的挑战是问题的解决，所以在IT服务管理的功能设计上需要关联变更流程、经验库来关联问题解决方案的流程，关联服务台由服务台推动问题流程的跟进与上升协调，关联风险流程来实现问题的升级。

• 视图：问题创建（接收、自建）、处理、关闭、分派、关联解决方案或流程（变更、风险）、关联监控性能与事件数据，其它关联；
• 事件、风险、运行分析等方式转移的问题，问题的分派到流程或开发团队，关联到其它系统，比如变更系统、风险流程、开发需求管理系统等，实现闭环；
• 问题流程最大的难点是后续跟进的有效性，需提供有效的分析统计、提醒、报表、升级等机制；
• 整合知识库、服务台，实现解决方案入库

同样来看看servicenow的问题管理的设计，主要是从问题解决方面的整合，包括监控性能数据、事件数据、知识库的整合辅助问题分析：

• 整体性的问题管理，识别潜在的故障分析

• 提供对性能趋势的分析，也可以考虑关联监控的性能分析

• 知识库的关联，以快速查询己知问题

2.4 变更管理

“大佬都在提倡devops，还需要变更管理吗？”

讲变更管理时，肯定会有人觉得ITIL的变更管理与devops的理念冲突，其实变更管理的目标是更安全、更快的交付，这与devops并没有冲突。更安全是指需要规范变更的方法和步骤，消除或降低变更风险，减少变更对业务运营的影响，保障公司各项业务及服务的顺利进行，这方面的关注点恰是devops比较少提到的内容；更快是结合devops的思路通过自动化手段提高变更管理的成本，比如关联应用变更部署工具提高应用变更部署效率，增加CAB的评审会议工具及流程提高CAB变更评审的落地等等。这里提几个关注点：

• 流程视图：变更发起、评审、审批、发布、监控、闭环评价、关闭、关联变更所涉及的工具，比如评审会议、部署工具、云管平台等；
• 变更合理分类，不同分类录入要素不同（简易变更、一般应用变更、重要应用变更、基础设施变更等），与开发或测试系统对接，减少重复录入；
• 变更与其它流程的关系，问题、操作维护、风险、故障等
• 变更与其它工具的关联,监控、发布系统、开发测试管理工具、邮件、微信、短信通知等
• 变更成功率、自动化覆盖率的分析
• 提供变更接口
• 变更窗口、变更日历、统一发布公告等多层次的可视化管理
• 应用部署、资源平台的等工具的整合

以下是servicenow的变更管理的设计的几个亮点：

• 变更整体情况仪表板

• 变更影响分析图，在变更前中后可以看到变更影响分析

• CAB会议安排，增加对变更的计划管理，风险评估

2.5 服务台

规模化的企业通常有IT运维部门，他的职责是服务于业务部门，保障企业网络的正常运转，在ITIL定义中与业务部门的关键环节是服务台，服务台一般都具有三个特点：作为运维部门和业务部门的单一连接点，跟踪用户提出的IT请求到解决为止；提供支持服务，主要包括记录所有IT请求，设定优先级，合理安排IT部门处理请求日程，同时向用户提供服务关注、反馈记录跟踪等功能；服务台可以显著降低IT管理成本，将企业的IT系统应用及管理流程化、规范化，将大大节省企业的人力、物力等成本。成熟的服务台具备一种低门槛，傻瓜式的服务获取、消费交互能力，响应快，反馈透明等特点，可以有几个关注点：

• 视图：发起（接收、自建）、处理、分派、关闭、满意度汇总,与工具的整合，比如协作聊天工具
• 与服务目录关联，形成一个良好的人机交互，专业的服务台处理能力，与透明的反馈跟进机制
• 分析统计工单处理及时率、满意度，并通过邮件通知用户
• 与流程相结合，比知识管理
• 提供接口，关联事件流程、监控与服务台等工具，为工具提供经验提供；
• 工单升级机制，关联驱动一线、二线机制

servicenow的服务在上面己提到，这里不重复摘录。

2.6 知识管理

“一个团队最终能留下来的是什么？硬件？软件？人？”

知识的积累，管理、技术、业务等多维度的知识积累。

知识的积累比较广，这里提到的知识主要是一些常规零散问题的知识管理。以往，这类零散的知识主要是面向一线运维人员日常工作的经验落地，具体有己记录的故障、应急解决方案、常用的功能性问题的解决方案。如果将知识建立一个面向全公司人员，那么在知识的选择上可以将范围进一步扩大，知识的丰富最好是全员参加，需要鼓励全员去丰富。几个关注点：

• 视图：入库、梳选、查询、历史知识内容管理等；
• 提供接口，关联事件流程、监控与服务台等工具，为工具提供经验提供；
• 提供手工文档上传，作为运维知识、文档管理入口；
• 知识利用率情况的分析统计，提供知识条目的优先级，保证知识含金量
• 知识的评价打分、知识的排名、热点知识的推荐等。

以下是servicenow的知识管理的设计的几个亮点：

• 自助检索知识库

• 知识文档定位

• 知识内容，有热点知识，有知识评分，支持全员丰富知识

• 知识准确率的管理

2.7 报表管理

大部份工作都可以遵循PDCA的持续优化的思路开展，当前很多ITOM的工具建设往往聚焦到了中间的执行环节，对于事后这个环节关注度低，以我的经验看，基于事后统计分析是投入产出比很高的一个环节，尤其是ITSM这类涉及流程、管理机制、组织人员是一个持续优化的过程，一些简单聚类规则便可以快速提升对IT服务运转的全面管控，不仅有更好的体验，还能辅助优化决策。

• 视图：实时查询、复杂模板定制、导出、外部数据整合关联
• 内置报表模板，包括各类流程、服务活动数据，针对不同的角色有不同的报表权限控制；
• 自定义报表，可对请求、问题、变更、资产、变更等生成自定义报表，无需二次开发，所见即所得。
• 可针对角色、时间订阅报表

以下是servicenow的报表管理的设计的几个亮点：

第3章 聊聊ITSM的建设

3.1 建设思路

在ITSM的建设过程中，主要有流程审批与IT服务统一管理两种建设思路，两者大概如下：

• 流程审批的平台：流程审批的平台建设主要的用户是IT人员，主要是集成事件管理、问题管理、变更管理、资产管理、IT项目管理、知识库、值班等单独的流程管理整合在工具上，实现运维工作流程标准化，实现风险控制，在工具体系中承担工具使用的流程控制，这个思路比较适合运维标准化程度不高，需要优先建立规范化、标准化的组织。
• IT服务统一管理平台：IT服务统一管理平台为面向全公司人员提供IT服务，平台通过服务台作为IT服务的统一入口，结合自动化工具的整合实现IT服务的高效反馈，并整合运维规范与流程。它在工具体系中承担工具使用的场景整合，通过场景的整合实现工具的互联互通与工具使用的控制。基于服务管理的理念适合组织的流程标准化、服务台、自动化工具具备一定的程度。

IT服务统一管理平台的思路更具扩展性，支持运维流程及规范的不断优化，以及服务效率与质量的不断提高。在实施过程中，鉴于实施的可行性，可以考虑制定短期内优先建设流程审批的平台，实现运维组织的规范化、标准化，接下来将运维场景与IT服务整合为场景，通过CMDB整合自动化工具，提高服务质量与效率，最终实现IT服务统一管理。

3.2 难点与解决方案

1）难点

行业里的服务平台落地会有一些痛点，比如：

• ITIL运维理念落地困难。服务平台ITIL流程的落地初期，不像监控这些工具能给一线运维解决痛点，容易被认为是束缚运维工作效率的工具，运维人员会有一些抵触。
• 运维流程优化的扩展性不强。ITIL V3在V2基础上重点提出了全流程、流程的职能化转为服务化，但现有的很多服务平台仍主要以单独流程建设，这种方式虽可以实现流程化、标准化的效果，但扩展性不强。比如流程化的故障管理主要是故障的登记，统计分析，但实际上故障管理的目标应该是提高应用可用性。
• 工具整合能力不足。为了实现工具体系中工具操作的合规性、控制风险，需要对于工具的使用前进行流程审批，但由于服务平台不开放审批接口，一方面每个工具要单独开发审批功能；另一方面审批的系统多个来回切换，使用不便。
• 对流程调整响应效率低、性能扩展性不足。服务平台需要根据运维组织自身的特点持续优化，运维组织对服务平台扩展性与用户自主可控很重要，但由于大部份服务平台不支持流程的定制、表单的用户设计等特性，很容易导致对厂商的依赖，运维组织对流程的调整响应效率低。同时，由于原有很多服务平台工具通常每个流程一次性加载太多信息，且不支持横向扩展的能力，性能扩展性不足，当访问量上升时用户体验差。

2）解决思路

针对上节提到的落地难点，在服务平台的设施过程中需要注意几个思路：

• 理念先行

IT服务平台是基于ITIL运维方法论，结合运维组织的管理流程规范，设计一个技术平台，它提供ITIL中的运维服务台、事件管理、问题管理、变更（发布）管理、配置管理、知识管理等标准流程功能，也提供运维组织特有的值班管理、巡检管理、供应商管理、督办事项管理、机房管理、需求管理、项目管理等运维管理扩展功能。服务平台的引入将打破原来依赖口口相传、人员纪律性为基础的工作方式，短期内会给组织内的人员带来困扰，甚至会有排斥行为，为了提高服务平台落地效率，在服务平台的建设过程中需要注重将流程规范的理念推广到运维组织，比如通过培训、沙盘演练、鼓励组织内参与ITIL认证等方式。

• IT服务管理思维转变

实施IT服务管理思维需要从流程标准化、建立统一高效的服务台，同时在场景的建设中回归不断优化运维组织能力的本质作为建设思路。

• 工具体系的整合

IT服务平台在工具体系中一方面要承担流程的落地，另一方面需要具备整合联动监控平台、操作平台、信息安全平台、资源管理平台、运维数据平台的使用控制角色，并整合用户管理系统、邮件短信系统、OA 系统等第三方系统，为IT 运维服务管理提供量化数据。

• 架构的可控性、可扩展性、可维护性

可控性、可扩展性、可维护性是从技术角度进行分析。架构的可控性，主要从易用性、流程及视图可自主编排，实现运维流程调整的快速响应，自主可控；架构的可扩展性是指针对性能问题，架构应支持横向分布式扩展能力；架构的可维护性是，系统架构需要在足够的安全性设计，同时适应多种操作系统等适应能力。

3.3 工具体系中的建设重点

• 流程标准化

IT服务平台的建设过程实际上是运维组织工作流程标准化的过程，运维组织应该充分利用好这个契机，对运维组织的规范、日常操作流程、监管要求结合ITIL的流程与服务理念相结合，形成标准化并落地。另外，如果采用外购服务平台的方式，还可以借鉴同业在流程理念上的经验，完善运维组织自身的流程。

为了让服务管理平台更加高效的整合管理规范、流程，提供更高效的IT服务，平台需符合扩展性强（性能、功能、流程、角色、与其它工具间的接口整合等）、技术可控（提供了灵活的流程和表单设计工具，可配置、可渲染、代码可控）的特性。帮助运维组织根据自身特点定制流程，改变错综无序的IT服务现状，提高IT团队的生产效率，改善终端用户的满意度。

• 服务统一入口

IT服务台作为企业内部IT服务支持的窗口，结合服务目录，统一规范管理并同时处理大量的IT请求，提供包括问题咨询、用户变更请求、服务级别管理、配置管理、可用性管理，避免了因找不到特定技术人员而耽误时间，从而降低运营成本。一方面建立服务台IT服务支持的人员能力、考核、协同机制的优化机制；另一方面通过知识库，以及其它自动化工具提高服务的高效，高质，并提供更透明的反馈机制。

• 场景工具整合

在IT服务平台的场景的建设过程中，需要考虑的不仅仅是流程的标准化管控，还要回归运维的本质，比如故障管理流程场景的建设过程中可以整合故障处理工具的整合，以提高故障处理效率，系统可用性；比如工单管理流程可以结合服务台、经验库等工作的整合，以提高工单处理效率。