Home

/

一文带你快速了解低代码技术在ITSM中的应用

Post date:2024-06-12 15:16:56

分享到

还记得早期的Dreamweaver吗?为了提高网页的开发效率,Dreamweaver提供了可视化拖拽的能力来生成网页代码。可见,低代码、无代码的探索和发展其实很早就开始了。

近年来,“低代码”这个关键词突然又热了起来,相关创业公司如春笋般涌现。突然爆火的背后其实仍然是企业数字化转型的驱动,在海量软件开发需求下,现有软件生产力已经难以应对,低代码技术则是一种破局之道。

01. 关于低代码

1)什么是低代码?

通过和专业的代码开发做对比,低代码、零代码本质是提供了一种更抽象的“开发语言”。通过图1能看到,低代码、零代码是建立在一种“建模语言”之上的,相对汇编、高级开发语言,建模语言的抽象程度更高,所以对开发者的门槛更低,只要熟悉图形的含义,就可以通过可视化的方式拖拽出符合业务逻辑的程序。BPMN是一种比较成熟的流程建模语言,专门用于业务流程领域的业务场景构建。这也是为什么很多低代码产品能够在“偏流程管理型”的应用场景中获得成功的原因,除了市场有需求之外,技术层面有成熟的理论支撑也很重要。

还有一种做法是基于大量基础场景组件的积累,然后通过搭积木的方式来实现场景构建的低代码平台,笔者认为这种方式成功的概率很低。组件再丰富也难以应对千变万化的业务场景,只有具备用“语言”来描述场景的能力,才能真正做到以不变应万变。所以,以当前建模语言的成熟度来看,流程管理域的业务场景才更适合发挥低代码技术的应用价值。


2)为什么要低代码?

企业完成核心业务流程的数字化之后,下一步可能会聚焦到内部运营效率的提升,内部运营管理的效率同样是组织的一种核心竞争力。而内部运营支撑系统又不及业务系统那么重要,不可能为此花费过多的软件开发投入,也无法简单引入一套功能丰富的系统(如:ERP、OA)就可以解决问题,很多边缘的、零碎的个性化管理场景是难以覆盖,导致开发需求急剧上升,IT部门如果仍然以传统的开发方式,不管是自研还是引入外部开发团队,其生产力都远远无法满足这些频繁变化的、零散个性化的需求。因此低代码的价值就凸显出来了,其很重要的一点是实现全民开发,即人人都是开发者。如果能真正运营起来,其软件的生产力可以是指数级上升的。


3)流程建模语言

既然低代码的核心是建模语言,那么,我们以最常见的流程建模来看看什么是建模语言。此外,ITSM承载的是运维、运营的流程管理体系,其核心也是流程类的业务场景居多。因此,我们可以聚焦到流程领域再深入看看,进一步理解低代码的底层逻辑,也便于后续理解低代码在ITSM中的应用。

在流程管理领域中使用最广泛的建模语言莫过于OMG发布的BPMN/DMN/CMMN等标准,各种主流的开源流程引擎、规则引擎,如:Activiti、JBPM等,都是基于这些标准进行设计的。

当然,这些引擎也不是百分百实现了前面三个标准,和其发展的重心和年限有关。


① BPMN

在管理机制的设计中,有一个很重要的点就是“工作流”的设计。通常来说,管理流程越成熟,工作流越固化,即某个工作不再需要太多的创造性了,只要按固定的工作流一步一步去完成,就能得到好的工作结果。BPMN的标准就非常适合此类情况,即用于描述可预定义的、固定顺序的工作流。

固化工作流

BPMN语言中关键要素包括活动、网关和事件,通过这些对象符号来描述一个标准的工作流程。(如对更详细图形符号感兴趣,可查阅官方资料,这里不做更详细地展开。)


② CMMN

工作的流程完全固化是一种比较理想的情况,实际管理过程中,成熟度都是从混乱发展到可定义级别的,在还没找到适合组织的最佳工作实践的情况下,更多还是靠人的主观能动性来解决问题。例如:当某个运维事件的发生,通常依赖于成熟的工程师临时做出判断,并拆解出几个关键任务来进行处理,分别由谁来执行,顺序是如何的。这种不确定的、无法预定义的工作过程就难以用BPMN来建模描述了,而CMMN的标准则更加适合此类场景。

CMMN场景案例


③ DMN

管理过程中还有一个很重要的活动就是决策,不同的决策结果会影响后续的工作流程。例如:某个变更是否要执行,就需要人为判断变更的风险程度来决定后续的处理策略。针对此类决策的活动场景,最佳实践则是通过DMN标准来进行描述。通过下图对比可以直观看出在决策场景中用与不用DMN的区别。


④ 最佳实践

如前面章节所述,在流程建模过程中,不同的标准适用于不同的场景。那具体到一个完整流程的设计,应该如何判断选择怎样的标准组合呢?同样行业中也提供了最佳实践的参考原则:

最佳实践
  • 业务流程中使用了一系列的网关,这个时候可以考虑使用DMN决策引擎代替。
  • 业务流程中使用了大量的事件,则可以优先考虑使用CMMN。
  • 业务流程中有一系列的加签、自由流程,则优先考虑使用CMMN。
  • CMMN中如果案例内的元素都是有严格的执行顺序,则优先考虑使用BPMN标准。


02. 低代码引擎设计

1)引擎模块体系

要通过低代码完整地实现一个管理类应用的闭环构建,通常需要五大引擎能力进行配合。


2)引擎功能设计

如下是各引擎模块的定位、功能设计参考。


03. 低代码在ITSM中的应用

1)运维工单构建

最能反映运维管理的业务逻辑的是运维工单的设计,细节到一个事件优先级的定义、问题类别的定义等,都能对运维工作产生影响,甚至影响到是否满足监管合规。因此,即使过了建设期,在运营期间也可能对已定义好的表单进行细微调整,此时ITSM表单的灵活性就非常重要。基于表单引擎可以对运维工单进行可视化建模,包括表单字段的定义、表单字段数据来源的定义、表单字段之间交互规则的定义、表单字段之间数据联动规则的定义等,以应对表单频繁变化的场景。常见的应用场景如下:

  • 承载事件/问题/变更等流程表单的自定义;
  • 承载场景化流程表单的自定义,如:资源申请、权限申请等。


2)运维工作流构建

运维工作流反映的是运维工作的协同过程。在运维管理中,不仅仅是人与人的协同,还可能人与系统、系统与系统间的协同。基于工作流引擎可以对运维工作进行端到端协同层面建模,包括工作流中活动的定义、分支的定义、审批的定义、事件的定义等。在ITSM中的应用场景如下:

  • 审批场景:多级审批、多人审批、加签审批等;
  • 协作场景:事件处理的一线、二线之间的升级流转、工单转派、任务分配等;
  • 集成场景:工作流与自动化作业流的端到端打通。


3)运维管理策略构建

在实际的运维工作中,还存在大量的管理策略规则,比如:事件处理的分派策略、优先级矩阵、风险评估、审批策略等。这些看似简单的逻辑,对效率和成本影响可不容忽视,因为通常属于一种高频的活动,例如:服务台人员一天可能需要执行上百次分派的动作。基于规则引擎,通过决策表、决策树等方式,可以灵活地将规则进行固化,代替人工操作。


4)运维度量报表构建

度量是运维管理持续改进的前提,一是度量指标的设计,二是获取准确的度量数据。同样,度量报表并不是一成不变的设计,而是随着管理的成熟度变化而变化,不同阶段、不同管理者的要求也会带来新的变化。例如:流程运行的初期,我们更关注的是流程有没有推广起来,因此更聚焦工单数量相关的度量指标。随着流程逐步运行成熟,我们开始关注工作的成效,如关单率、平均处理时效等。管理要求进一步提升之后,还可能需要度量SLA的达成情况。基于轻量的报表引擎,可以灵活动态响应此类度量要求,通过数据接入、度量维度定义、度量指标定义、仪表盘编排等能力快速沟通运维度量报表。


5)运维工作台构建

ITSM面向的用户广泛,不仅有运维工程师,还有终端普通用户、运维领导等。不同角色关注的重心不一样,为了提供更好的体验,面向用户的视图可能是千人千面的,基于视图引擎,可以定义不同的视图内容、视图排版、视图样式等,以满足交互和视觉层面的个性化诉求。


04. 总结

低代码本质上还是一种“开发语言”,而不是组件的堆砌和拼装。流程管理领域的低代码技术相对成熟,有完善的建模语言作为支撑。因此,低代码技术可以在ITSM领域较好的发挥其价值,以应对流程数量的激增、管理要求的频繁变化等,更好地助力IT服务管理的数字化建设。

免费申请演示

联系我们

服务热线:

020-38847288

QQ咨询:

3593213400

在线沟通:

立即咨询
查看更多联系方式

申请演示

请登录后在查看!