为什么说OA和低代码平台都不能代替专业ITSM（二）

接着上一篇《为什么说OA和低代码平台都不能代替专业ITSM（一）》的话题：能否用现成的OA来做；能否利用低代码平台来构建ITSM，来替代已经商业化的ITSM产品。

一、首先，我们看看什么是低代码平台:

“低代码（LowCode）/无代码(NoCode)”是技术界近几年的热门词汇之一，随着企业数字化发展的深入，越来越多的场景化需求要求企业具备更加灵活敏捷的应用开发能力，传统应用开发模式周期长、技术人员能力要求高，无法满足快速变化的市场需求，由此，提供便捷应用开发能力、降低开发门槛的低代码无代码技术应运而生

广义上的低代码平台包括低代码平台和无代码平台，两者的主要区别在于对代码的依赖程度：

低代码平台

通过自动代码生成和可视化编程，只需要少量代码，即可快速搭建各种应用。这种除了页面配置，还需要一些简单的函数、脚本开发能力以达到实现复杂的判断、控制流程和展现结果等目的。对于配置人员要求是有一定的编程基础，或者愿意学习，但是不需要学习新的编程语言。

无代码平台

零开发经验的业务人员通过页面拖拽等方式，无需编写代码，即可快速搭建各种应用。

另外，还一种专业代码的开发，也可以归为低代码开发，两者的不同点是专业代码开发有专业的集成开发环境。早期的BMCRemedyAR平台（早期ITSM国际的NO.1是BMCRemedy，其强大之处就是有AR平台）就可以归为此类，因为有较多的专业代码开发，无论是表单，还是ActiveLink、Filter等等，它早期也有IDE客户端。

早在低代码的概念完善之前，Salesforce公司就在1999年提出了“软件终结”的口号，并面向开发者研发了force.com应用开发平台，允许开发者基于此快速开发CRM软件系统，从而开启了低代码应用开发的航程。另外，ServiceNow是众所周知的IT服务管理(ITSM)SaaS提供商，它的SaaS就建立在称为“Now Platform”的低代码平台上。

后面我们不再区分，统一叫“低代码平台”或者叫“低代码PaaS平台”。低代码平台较原生开发模式，能显著提升开发效率，尤其适合业务变化快、预算有限、开发时间紧迫的企业应用场景；相较于只能解决行业通用问题的SaaS订阅模式，低代码PaaS平台的适用范围更广，可以满足个性化需求，有较强的灵活性。

 如上图所示， 业界的“低代码PaaS平台”主要是有三层目的：

厂商内部：

基于低代码平台构建产品，加上新产品上市的速度，同时可以满足不同行业客户的个性化需求；

客户:

客户可以基于低代码平台定制开发。这点让笔者想到有一个客户抱怨曾经用过的ITSM，每扩展一个流程，修改一个流程都需要客户立项和收费，扩展能力和个性化定制能力比较差，需要依赖于编码实现，所以客户来咨询紫羚云的ITSM，希望可以将其替换掉。

ISV:

低代码及其PaaS作为一个独立的产品或者服务，可以帮助集成开发商开发新产品或者应用于新的场景。

二、其次，我们再来看看低代码平台和ITSM定位和价值上的差异。

低代码是一个技术平台，理论上可以在其平台上实现既定场景的业务或通用的流程。它解决的是业务流程或通用流程的易于实现的问题，而ITSM本是基于ITIL服务管理全球最佳实践的IT管理的业务闭环体系，核心强调的是IT的业务架构以及业务架构在不同行业、规模大小、业务复杂性、组织架构、管理成熟度等场景下基于全球最佳实践的适宜性和有效性的能力；而aPaaS等低代码平台在支撑ITSM业务时只是让ITSM在功能性方面更加易于调整，低代码与 ITSM完全是两类不同维度和不同侧重的平台，根本不具备直接的可比性。具体如下：

•  低代码是一个技术平台，ITSM是一个管理平台；

•  低代码侧重强调通过简单的非开发人员的配置替代传统软件代码开发人员的复杂工作，而 ITSM强调管理本身，低代码仅是实现ITSM基本功能的一个底层支撑，而ITSM强调的是对IT业务的管理；

• 低代码强调技术平台的易用性，可配置性，低门槛，易于搭建一个相对简易的系统，这包括构建系统的表单、流程、报表、数据库等的功能性的能力，而通用低代码平台其中不包括任何特定ITSM专业场景或业务逻辑，而构建一个软件系统是有5大架构视图设计的，这是任何一个合格大型软件平台架构师都懂的基本认知，而业务架构是五大架构视图之一。而 ITSM的核心是基于ITIL&ISO20000以及大量一线ITIL咨询经验与客户碰撞出来的IT管理业务架构，这不是简单地拷贝ITIL流程样例设计的“僵尸”ITSM。

•  通用低代码是可以实现简单业务或管理场景，ITSM本身就是专业且复杂的IT管理和IT业务场景；

•   低代码只是实现ITSM简单“功能”的一个手段，难于胜任中大型企业对专业ITSM复杂场景下动态闭环管理的要求；

•  通用低代码实现的ITSM只能称之为工单管理系统，作用是记录工单和留痕作用的“工单记录器”，使用过程中往往只能增加用户和工程师的工作量；而专业ITSM是以传递CIO管理价值和业务价值的以ITIL为核心的在平衡风险与效率、成本与服务质量、主动与被动、稳态与敏态的服务管理体系。

综上所述，低代码与ITSM没有直接的可比性。这就如同3D打印是一个未来替代部分简单但精度要求较高的传统制造业的工作，但是3D打印替代不了整个制造业，也不能直接把3D打印这个技术与建一个50层大楼或制造一个7纳米的芯片直接进行比较，这完全是两个不同层面的事物。

三、我们再看通用低代码平台是否可以完全实现ITSM？

前面没有否认，通过通用的“低代码平台”可以实现简单的表单和流程的配置，例如工单管理这个层级，的确是比较快捷。但这也有明显的局限性，因为对所有特定的业务应用，都有不同的业务组件和复杂的业务逻辑，不见得满足构建ITSM这样复杂系统。例如ITSM有服务目录、服务级别、组和CTI、地点、值班表等等，对于复杂客户的ITSM需求难以满足。

当然了，专业厂商为了构建自己的ITSM产品，自己量身打造的低代码平台，由于已经充分考虑到了ITSM的行业属性，其目的也是可以灵活适配不同行业客户的个性化需求，应对需求的变化，避免代码级定制开发，对ITSM业务也有足够深入的理解，也历经大量客户的真实需求的锤炼的低代码平台另当别论了。

紫羚云的ITSM就是基于这样的低代码aPaaS平台来构建的，这也是紫羚云ITSM除了培训、咨询和软件三位一体的核心优势之外的又一强大和独特之处：

·内置了几大引擎：表单引擎、流程引擎、算法引擎、接口引擎、数据可视化引擎。

· 流程活动的实时监听：流程SLA的监听、实时数据的分析等

·大量的开箱即用的流程模板和基础组件

· 接口引擎

· 内置大量丰富的接口300余个

· ……

· 数百个适配各种复杂场景的开关等等

从功能层面来说，这里大部分都不是通用低代码平台可以满足的，因为这里有比较强的IT管理工具的业务属性，这也是从大量不同行业客户的真实需求提炼出来的。笔者也看过几家在业界非常领先的CRM专业厂商的低代码PaaS平台，发现也是一样有大量适合营销管理的业务组件。

从业务理解来说，ITSM是基于ITIL全球最佳实践，是将ITSM的先进理念进行固化和落地实施的工具，而不是一个技术平台。这也是ITSM平台和其它低代码平台在最本质的区别，这也是前面说的低代码平台和ITSM两个不同维度和层级的事物的原因。ITSM的设计依赖于厂商丰富的行业经验，基于对ITIL/ITSM深刻的理解和沉淀基础上的。上面分析的功能上的差距，其实也是对业务理解、业务架构属性不同的必然结果。

这就是紫羚云ITSM为什么可以在大量的金融客户（银行、保险、证券等）之外，有制造、互联网、物流等行业也有大量客户，基于紫羚云沃野aPaaS平台的千人千面的满足不同行业的客户需求且能快速上线的原因。

紫羚云希望它的aPaaS平台除了帮助自己灵活定义产品之外，满足ITSM产品开发和SaaS业务，以及帮助客户自己做个性化配置和开发，希望未来能帮助合作伙伴定义行业新的解决方案，建立生态更好的服务不同的行业客户。紫羚云自身已经基于低代码平台开发了多个新产品，包括管理自身业务的智慧运营大脑平台。

四、最后，我们做个总结，为“OA和低代码平台都不能代替专业ITSM”这个话题做个收尾。

无论是OA，还是低代码aPaaS平台都不能替代专业的ITSM产品，不仅仅是功能层面，更重要的是，ITSM产品是基于ITIL全球最佳实践，基于数字化时代对IT服务管理等深刻的业务理解基础上的。用OA或者低代码aPaaS平台，实现几个服务请求流程，做个记录型的工单系统还可以，但是整体来看，和ITSM完全不是一个层面和维度的事物，也远远达不到应有的ITSM的价值和效果。

更为重要的是：实施IT服务管理，不等于实施ITSM工具，工具的选择、产品的选择很重要（后面会有专门的一期来讨论怎么做ITSM工具的选型），但不是全部，而只是四分之一的事情。后文再专门探讨。