跳到主要内容

如何弥合 COTS 与定制解决方案之间的差距

如何弥合 COTS 与定制解决方案之间的差距

传统上,当组织需要新的数字解决方案时,他们通常必须在标准的现成软件包或自己构建定制解决方案之间进行选择。

两种选择的优缺点都很明显: 标准套餐 提供所有必要的(或大多数)开箱即用的功能,但对于调整或扩展,则完全依赖于 供应商(通常价格昂贵)。

通过 定制,您可以构建您所需要的内容,并且可以完全灵活地进行调整,但需要拥有(或雇用)所有必要的技术技能和专业知识,并且经常需要重新发明轮子。

最终,它往往变成两个次优选项之间的选择。有多少组织陷入了购买标准包解决方案的陷阱,并最终(通常是在业务用户的压力下)对解决方案的核心进行了定制调整?结果通常是非常昂贵的一次性解决方案,无法再维护或升级到最新版本。

另一方面,有多少组织认为他们可以通过建立自己的 IT 组织并自行构建定制解决方案来防止这种情况发生?通常一开始规模很小且易于管理,但随着时间的推移和解决方案的增长,这会慢慢退化为无法再维护的庞大整体解决方案,IT/维护组织过于庞大,外部承包商费用昂贵,TCO 远远高于最初的预算。通过反复试验,组织明智地选择在其架构愿景中选择使用标准包来实现其支持业务功能(80% 适合用途也可以),并且只使用自己的定制解决方案来实现其差异化的主要业务功能。

使用低代码构建和购买

As 朝着正确方向迈出的第一步是让两个极端更接近,并克服两个选项的缺点,低代码(或者我更喜欢说 模型驱动) 软件已推向市场。许多标准的现成软件包解决方案现在在其平台内或之上提供(或多或少)一种低代码或无代码形式。

凭借“保持核心清洁”的范式,所有非标准功能仍可通过这种方式轻松添加。对于完整的定制解决方案,现在可以采用现代低代码应用程序开发平台,例如 Mendix 几乎所有可以用传统编程语言编程的东西现在都可以用现代的所见即所得工具进行可视化建模。其优势在于,平台已经处理了棘手的技术和 IT 问题,开发人员(或者越来越普遍的业务分析师)可以完全专注于构建和验证所需的功能和可用性。

建立与购买 正变得越来越紧密,从而产生了以标准“核心”模块和低代码定制组件为补充的混合解决方案。

下一步是什么?低代码构建的自适应模板

Is 这就是这次进化的终点吗?显然不是。

尽管低代码使自己开发定制数字解决方案变得更容易、更快(而且最重要的是技术含量更低),但它尚未提供商用现成解决方案的完整现成功能和行业专业知识。这可以是现成的数据模型、业务流程、智能算法、现成的集成或现代客户交互设计模式。为了满足这一点,你会看到以下公司 Mendix 越来越关注预先构建的、可定制的应用程序选项,从特定功能模块的启动模板到其 ISV 合作伙伴销售的完整垂直解决方案。

以 HumbleBee 保险解决方案为例:它已完全采用低代码开发 Mendix 技术由 Mendix 合作伙伴 Valcon。这款端到端的保险自适应解决方案由 Valcon 在过去 2 年中为保险业及其他领域的各种客户开发的多个功能模块和概念组成。HumbleBee 的核心概念之一是 Valcon 开发的动态案例管理 (DCM) 和业务规则管理 (BRM) 功能。

这样就可以针对特定保险产品线设置和定制灵活的报价、承保和索赔流程。与标准工作流功能不同,DCM/BRM 非常适合具有长期运行的事件驱动案例、直通式处理自动化和针对特定产品或客户的异常处理的保险应用程序。DCM/BRM 是现代 BPM 平台的原生功能,但在低代码平台(如 Mendix通过使用 HumbleBee 作为自适应解决方案,组织既可以获得标准现成解决方案的开箱即用功能,又可以获得低代码定制解决方案的灵活性和适应性。实际上,这种适应性在保险行业中始终是必要的,以便将解决方案集成到现有 IT 环境中或与外部服务提供商集成,并定制解决方案以支持组织的特定产品和流程。

自适应解决方案兼具构建和购买的优势。企业无需了解底层技术,即可获得并配置标准的开箱即用功能。另一方面,该解决方案完全可定制和扩展(既可以作为 ISV 供应商的托管解决方案,也可以作为组织本身的快速启动模板)。底层的低代码技术使解决方案的调整和集成变得简单且易于管理。

选择你的语言