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

知识的领域是无限的,我们的学习也是无限期的。这篇文章主要讲述ITSM的建设依赖基础信息库和服务目录,附落地案例分享相关的知识,希望能为你提供帮助。

  原文出自:嘉为蓝鲸服务号
相信很多企业的管理层都面临过这样的问题: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.项目建设成果【ITSM的建设依赖基础信息库和服务目录,附落地案例分享】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+服务项,包括:人力资源部、计划财务部、风险管理部、运营管理部、法律合规部等等。
作者:嘉为蓝鲸服务号
未经授权,禁止转载。

    推荐阅读