ITSM的建设依赖基础信息库和服务目录，附落地案例分享

Posted 2022-05-06 嘉为科技

 原文出自：嘉为蓝鲸服务号

相信很多企业的管理层都面临过这样的问题：80后70后相对比较好管理，而90后00后出生于较为生活富裕的互联网时代，个性比较突出，应该如何管理才能提高组织的效率呢？

土钦老师谈到，自己曾听过一个麦当劳高管的答案：用企业价值同化其思维，用流程同化其行为。举个例子，新兵蛋子进入部队的第一天就能感受到进入部队的（流程）第一步就是“服从”，下一个人看到整齐划一的队伍就知道如何站。又比如说华为的价值观是“以奋斗者为本，以客户为中心”，当新员工入职时就会对其进行培训，并将企业价值观具体到流程上，让员工在日常工作中深刻理解和体会。

一、关于流程的说明

流程至少有4个核心用途：团队协作、人才复制、经验沉淀、服务效率评估。

• 团队协作：规范的流程让同部门内协作井然有序，跨部门协作减少协作阻力
• 人才复制：新人入职，只要按照流程执行就可以快速上手，不需要担心个别员工离职对团队工作有较大影响
• 经验沉淀：经过长时间迭代的流程，实际上积累了前人的经验，是企业内高效的执行方案，同时还能避免重复踩坑
• 服务效率评估：有了流程积累的数据和分析，才能评估团队的工作效率和企业服务的提供效率

不过也要澄清一些关于流程的潜在理解误区。首先流程不等于工具，而是一个过程，是做事情的顺序，而过程需要依赖流程工具（邮件、OA、ITSM）。其次，关于流程和工具的建设顺序，应先梳理现有的流程、画好流程图，确认需求之后才开始挑选和建设流程工具，再将流程图落实到流程工具中。最后，本次主要介绍的是流程工具，并非介绍如何设计流程。

1.建设流程依赖的基础信息库

流程其实并没有那么容易建好，有一定的依赖性。把流程依赖的基础信息库建设好，才能让流程更高效。如下图的表单，员工在申请电脑时的表单申请环节，电脑品牌型号和电脑来源这两个字段是通过下拉选择的，并不需要手动输入，这样做可以避免不同人的用词习惯。

上述只是举个较为简单的例子，在实际工作中，运维流程依赖的基础信息库一般是企业建设的CMDB（配置管理数据库）。在CMDB里建设好主机模型，该模型中包含很多字段：IP、云主机、云厂商等等，也就是Excel表格的表头。当我们建设好模型之后，也就规范了实例的资源应该包含哪些字段，数据需要手工录入或导入。

​​​​

2.建设流程依赖的服务目录

流程除了依赖基础信息库以外，还依赖服务目录。通过建设服务目录，让流程发挥串联作用。想要理解服务目录，首先要理解什么是服务：服务是企业里帮助其他部门或本部门要做的事情。比如下图服务目录里，机房提供的服务是当有人进入机房时需要先报备，只有报备之后才准许进入，同时包括了一些响应时间和交付时间。由此得知，服务目录是服务的集合，提供描述和SLA等信息。

二、运维流程建设案例分享

1. 客户痛点

这部分内容来自真实的客户案例，该企业在运维流程上有着不少痛点：

• 现有工具体验差：现有流程工具使用体验差，操作复杂、界面难看、功能缺陷多、无法进行统计分析。
• 多个系统间切换：事件管理、问题管理、变更管理流程在三个独立的流程系统上，用户需要在不同系统间切换。
• 工作效率靠关系：员工都在找自己最熟悉的人进行服务，IT资源无法有效和高效分配。
• IT服务效率低：IT服务效率低，质量不高，用户满意度很低。

为了解决上述痛点，项目立项后就开始建设和运维流程相关的内容，从需求确认到ITSM、CMDB、统一告警中心上线，大概用了4个月（见下图）。同时，我们为客户赋能，在基于PaaS平台的两周开发培训完成后，几乎1个月左右就有客户自研的一个SaaS应用上线。

2.项目建设成果

CMDB数据准确性提高：CMDB数据准确性从95%提高到98.5%，为运维场景提供准确的数据支撑。

流程设计简单快捷：运维流程从设计到上线只需要数天。流程设计不再强依赖开发人员，即可按需灵活自定义设计及编排运维流程。

工单处理效率高和移动端便捷性高：2年累计工单量 129046 单，日活量峰值 732 单，服务台累计处理工单达 7763 余次，审批效率提高 50%，整体关单率从 85.3% 提高到 97.54%。坐车、走路等无法使用电脑的场景，都可以使用手机查看工单和接受告警通知。

告警和流程工具打通：统一告警中心和运维流程管理天然相同，平均每月告警事件自动转成工单量为 600+单。

自研SaaS应用沉淀：在长达半年中，围绕运维流程的服务需求，平均1个月左右打造出1个SaaS应用。

合适的工具能够在投入使用后，让企业在未来几年逐步回本。项目带来的其他价值还包括：运维操作失误率降低、事件处理时效性更高，满足监管的要求、让传统运维团队更容易转型成运维开发团队，从手工运维直接进入自动化运维阶段、流程建设敏捷地提供业务支撑等，详见下图。

​​​​

三、案例成功经验总结

虽然每个企业所面临的情况不尽相同，但是仍然有一些共通的痛点和解决办法。本次项目的成功因素有很多，有三点格外值得一提：

• 甲方关键角色（领导、管理层）：比较相同时间维度的两个项目，一个成功一个失败，领导起到关键作用。
• 乙方产品成熟度：比较不同时间维度，一个成功一个失败，产品成熟度起到关键作用。
• 正确的实施顺序：只有当甲乙双方目标一致，基于一个较成熟的产品和正确的实施顺序，才能成功。

1.甲方关键角色决定了项目的成败

服务目录的建设涉及企业内几十、几百个服务的流程建设，需要领导重视和统一建设团队的目标，领导对自动化运维的认识影响项目走向。除此之外，运维流程建设需要有专门的建设团队，同样需要领导协助建立团队。服务建设完成后需要大力推广，若推广遇到阻力也需要领导协助。由此可见，本次项目的成功，甲方关键角色在其中的作用不言而喻。

2.乙方产品成熟度决定了需求的被满足程度

如果一个产品不够成熟，客户的需求得不到满足，也难让项目圆满完成。，产品成熟度高，这对于项目的顺利推进也起着至关重要的作用。

① 高性能高负载：满足企业数十万用户的使用需求，为“工单处理效率高”的建设成果提供了基础的性能支撑。

② 支持移动端：有PC端和移动端界面，提供了移动办公的可能性，为“移动端便捷性高”的建设成果提供基础功能。

③ 灵活的流程引擎：流程引擎支持通过托拉拽来快速将设计好的流程图，转化为运维流程管理工具中的流程，达到“流程设计简单快捷”的建设成果。只有灵活的流程引擎，才能满足当前的需要，并匹配未来的发展需求。

④ 良好的API设计：提供API设计，能够和相关的其他SaaS产品打通和联动，为“告警和流程工具打通”的成果扫清障碍。

当然，PaaS平台不仅仅应该只有流程引擎，如果能有自动化引擎和门户引擎，效果会更好。

① 流程引擎：能够提供流程场景的可视化编排，内置人工、审批、会签、自动化节点，支持流程节点的表单自定义设计，支持流程的并行、串行、分支设计。

② 门户引擎：能够提供自定义拖拽门户编排，内置丰富的组件库、数据源，通过权限控制实现个性化、多租户门户。

③ 自动化引擎：提供跨系统的调度编排，支持平台内置模块 + 外部系统的API接入能力，实现自动化作业编排和任务模块，服务于敏捷交付。

下图是我们的ITSM产品架构图分享，可供参考。基于成熟PaaS平台开发的优势，就是在开发的过程中，能够省去了部分代码的编写，缩短开发时间。

3.正确的实施顺序

首先不能一上来就建设ITSM工具，因为工具很依赖企业的流程。因此，最好先把现有的运维流程梳理并画成流程图。与此同时，还要梳理运维场景的需求，因为运维场景需求决定了CMDB里要放的模型和字段。等流程和运维场景需求都梳理完毕后，方可建设CMDB。上述全都处理完毕后，再开始建设ITSM流程工具，因为流程工具的部分功能是为了保证CMDB数据准确性的。此时如果有需要，可以再去建设告警中心或者自研SaaS，如果不知道如何自研SaaS，可以要求乙方通过培训给企业赋能SaaS开发。

四、不满足于运维流程建设

1.研发运维一体化

成熟的PaaS平台不仅能实现运维流程的自动化，还能够将运维流程和研发流程对接，实现研发运维一体化。更具体来说，就是将自动化运维场景和DevOps对接，实现从需求到开发再到应用上线、下线全生命周期管理。

2.企业服务流程（ESM）

同样，我们还能够将运维流程推广到企业服务流程（ESM）。企业服务管理是将企业各个部门定义为服务单元，员工作为服务单元的消费方，而企业服务管理平台则是一个桥梁，将服务提供方和消费方进行连接。消费方既可以是企业内部的员工，也可以是企业外部的客户、合作伙伴、供应商等。这样在企业中形成了一个大的共享服务中心，让服务消费方可以轻松获取组织提供的服务支持。借助ITSM管理方法、技术和工具，赋能非IT部门的服务运营，通过ESM理念建立企业级的数字化共享服务中心（企业服务台）。

对于此，我们同样也有客户做到了。某银行通过ITSM支撑内部智能运营服务，让服务线上化、规范化，极大地提升了企业效率。

• 用户反响热烈：服务企业员工30W+，系统日活达1W+，月活5W+，在企业内部发挥了巨大价值。
• 数字化水平提升：10000+服务线上化，服务全流程可视，服务自助化、自动化、数字化水平大幅提升。
• 服务规范化、效率提升：服务统一管理，纳管了各支撑部门共8000+服务项，包括：人力资源部、计划财务部、风险管理部、运营管理部、法律合规部等等。

作者：嘉为蓝鲸服务号

未经授权，禁止转载。