骏域网站建设专家,开网页cpu使用率高,晋江网站建设报价,郑州网站设计收费源宝导读#xff1a;ERP这类复杂系统中#xff0c;业务模型是系统功能的核心抽象#xff0c;但业务模型对于不同的客户会有差异#xff0c;也会随着业务发展而变化。虽然可以对业务组件进行复用#xff0c;但客户定制的成本依然较高#xff0c;本文将讨论如何利用模板化应… 源宝导读ERP这类复杂系统中业务模型是系统功能的核心抽象但业务模型对于不同的客户会有差异也会随着业务发展而变化。虽然可以对业务组件进行复用但客户定制的成本依然较高本文将讨论如何利用模板化应对业务模型的差异与变化。一、背景来自用户的反馈A区域顾问“客户的合同变更业务只有申报和指令两个阶段并没有确认阶段能否不用二开配置下就能用”。B区域顾问“客户的合同变更有自己的操作习惯产品标准体验不符合他们习惯能否单独提供一个符合我们区域的交互模板”。C区域顾问“客户有三类合同变更但产品只有两类合同变更能否不用二开快速复制一套变更业务简单调整下配置就能交付”。D区域顾问“客户在合同变更业务上有多类应用标准产品的变更业务太固化能否提供一个途径让我们自己根据客户需求打包个性化的变更业务解决方案并分享给其它顾问或区域实现快速交付”。二、如何应对多变业务 低成本、快交付是软件产品交付领域一直非常看重的目标其直接影响了产品最终利润率。那么对于前面场景所展现的业务多变性我们如何破局 系统模型往往是业务模型的落地表现在一个相对固定的业务场景下功能是稳定的需求是可预测的那么对于系统设计来说难度是相对较低的在这个相对稳定的模型下局部的调整与功能扩展点能够很明确的提取出来。这也是ERP、SAAS系统设计和进化的基础。一旦业务模型变得多变而缺乏预测性那么对于系统来说其设计的难度将成倍增长如为应对单据与流程的多样化单据模型配置将变得非常复杂。而对于明源云来说同样将此类问题交由建模平台进行。 近年来“低代码”已经是一个非常高频的词汇其核心是在探索用少量代码甚至无代码方式构建符合客户预期的业务系统包括明源云在内推出了基于各种形式的低代码平台。为了适配业务的多样性“低代码平台”更多的是基于通用开发能力设计而成如Paas底座、对象与关系管理、积木组件、流程编排等再加上基于自身优势业务领域的经验沉淀的可配置组件极大降低了系统开发难度让非科班出生的从业者也能较为轻松的构建出个性化的业务系统。 那么“低代码平台”是一劳永逸的完美方案么虽然“低代码平台”提供了一系列低成本构建和扩展业务系统的手段。但是一个业务模型往往是一个业务闭环涉及多页面、多逻辑、多对象之间的联动共同形成一个完整业务。比如合同变更业务存在非常多的关联校验、业务及数据联动、成本算法计算业务阶段也是多变的。从零开始搭建或者仅仅复用部分业务组件客户的定制成本依然比较高。如何将如合同变更之类多变业务模板化将是我们本次探讨的主要内容。三、多变业务模板化首先我们根据开篇用户的反馈从多变性业务中可以发现一些特点同一业务虽然多变但仍然具有共同的外部关系如合同变更有共同前置对象“合同”共同的影响“合同金额变更”。模型的变化实际上是业务阶段的拆解和合并如合同变更有些客户会拆分为申报、指令、确认三个阶段有些客户会把申报和确认合并有些客户会把确认拆解为事项确认和费用确认。在核心模型之外会有追加诉求如无效成本、税目信息、附件等。交互体验会有差异。基于以上特点我们可以分别将其进行实例映射业务外部关系》事件与接口。业务阶段》页面、表、关系、逻辑。追加的诉求》业务组件、接口。交互体验的差异》可替换的UI。 那么如何将这些实物按照客户需求进行组合呢首选方式是配置配置实现有两种方案第一种是通过全局配置参数进行控制比如利用参数开启阶段、启用组件等但是这种方案难度系数巨大首先是通过参数控制全量的对象只能通过显隐方式实现处理好这些元素间的关系、数据代价较大其次如果要复制一套业务比如新增一个变更或合同则全局配置参数是无法满足的。第二种是通过将配置、对象一起打包为模板通过配置动态创建对象这个过程我们称之为模板生成实例。每个实例有一套配置副本统一进行管理而因为该模板具有极强的业务属性我们称之为业务模板。 业务模板我其实更倾向于称之为“业务解决方案包”因为在前期推演时向同事介绍业务模板概念但是同事往往会将之与页面模板、脚本模板等概念相混淆甚至认为业务模板就是页面模板。其实他们之间差异很大。页面模板是将相似的页面中差异的部分用占位符替代然后根据实际数据动态生成最终的页面并没有太多业务属性。而业务模板则是对整个业务闭环进行抽象这个环是一个业务链比如变更申报单填写、审批再到指令单处理最后到确认单审批最终完成合同金额的调整。环上的点就是每个阶段所涉及的具体单据业务也就是页面。在这个环内有表数据对象、辅助功能页外部有关联影响点和接口。这个业务闭环有多大、有哪些节点、最终会生成哪些数据对象则依赖一套配置进行编排这个配置就是某种意义上的占位符只是其占位的不是数据本身而是数据关系。页面模板只是整个业务方案中具体的某个功能页面仅仅负责用户交互。 搞清楚了业务模板的定位在后续的实践中我们和建模平台的同事一起通过实践确定了业务模板所包含的基本元素数据模板定义数据对象及数据结构最终会生成物理数据表。数据关系模板定义数据对象之间的数据关系。页面模板定义用户交互UI最终会生成物理页面。业务参数模板控制涉及数据的业务个性开关最终会生成供客户调整业务的业务参数。模板配置控制1-3模板的生成规则最终形成的业务各个阶段。四、业务模板的应用 在我们前面的场景中我们利用业务模板能做些什么呢对于A顾问来说我们可以通过模板配置只生成申报和指令两个阶段所需的页面、数据表并在数据交互时识别配置跳过缺失阶段。对于B区域顾问我们仅需编写一套适合当地的页面模板替换掉业务模板中的页面模板创建符合当地习惯的变更单。对于C区域顾问则只需使用模板实例化一套新的变更单实例即可所有的页面、数据表、关系、配套接口等一整套对象都可生成在此基础上做一些微调即可。而对于D客户我们未来可以将打包业务模板的权限逐步向顾问开放通过对标准业务模板的调整最终形成区域自己的业务模板以快速交付区域内其它相似需求的客户。 前面对业务模板的理解更多基于合同变更的例子那么是否同样适用于合同业务中呢 对于合同业务不同业务形态的合同是不同的但梳理下来会有以下共同特点合同对象基本属性。特征属性。关联对象。合同分类合同模板。配套服务工作流。电子签章。离线编制。编码规则。对外服务公共接口。事件驱动。 对于上面这些来说似乎用页面模板就能解决有些客户的合同就是采用页面模板配置的方式实现了数十种合同。但是有些问题待考虑基于客户自身明确的需求而标准产品无法预测客户会在某些合同上附加何种功能而这些功能和数据应该是与其它合同隔离的。所有的合同共用一张物理表是否合理。 我们如果基于业务模板我们来看如何设计这套合同系统。合同属性是由页面来承载的基本属性是所有合同所共有的因此作为固定元素显隐控制即可。特征属性是每种合同特有的可以抽离为特征业务组件选择性使用。关联对象比如税目信息是从信息同样可以抽离为业务组件选择性使用。据此首先将合同分类作为配置项放入业务模板然后定义一个合同表模板包含基础属性字段而特征字段则根据配置的合同分类设置动态特征属性字段而关联对象则为每个对象定一个从表模板。再然后我们定义一个合同页面模板包含所有基本属性并根据配置的合同分类设置动态嵌入特征属性组件以及关联对象组件。最后将配套服务所需的开关作为业务模板的业务参数。那么客户需要某种合同的时候在业务模板中选择合同类型然后实例化出具体的合同此时合同所需的一切页面、表都创建完成逻辑也根据实例自动接入。后续仅需要通过建模做一些微调即可发布。 当然这里我们只做探讨并非表述采用业务模板是实现合同业务最合理的方式一切都需要进行技术选型和论证后才能决定。五、业务模板的挑战 在业务模板技术的艰难演进过程中也不断收到过很多质疑。 从业务方面来说有同学质疑业务模板生成实例只是上线客户一次性的动作如果使用过程中客户做了模型调整那么业务模板就起不了什么作用了对于这个问题从业务模板定位上来说是解决客户业务模型初始化的问题但是这个初始化并不是只在上线时使用如果使用过程中客户做了模型调整那么依然可以使用业务模板初始化功能进行重新初始化当然这里面涉及到了数据升级及客户前期个性扩展如果保留的问题。我们并不认为这是业务模板本身问题而是我们要从数据迁移、建模元数据自升级两方面来降低客户重新初始化的代价这个是任何升级都无法避免的问题不仅仅是业务模板的特例。 从技术方面来说有同学质疑业务模板太重以前每个业务每个页面都是具体的开发简单而业务模板却只是模板开发、调试并不方便增加了产品开发成本。这个是相对的一方面新技术的演进本身就是有一定难度的有种说法是把技术难度前置了研发难度有一定提升但是交付难度降低了基于边缘效应总体成本是快速下降的这也是技术投入的初衷技术投入从来都不是降低研发端的难度而是降低总体的成本。比如单体应用是简单的但弹性扩展难度大而微服务的架构是复杂的高难度的难维护的但却极大提升了弹性扩展能力表现出来的结果就是面对业务数据的快速上升但却能低成本快速的扩展应用总体成本是降低的。另一方面业务模板在开发端还并不成熟体验还待改善这个带来了错觉觉得业务模板太复杂难以驾驭。其实把问题打开来看更多的是可以通过工具化、优化交互、调整流程就能解决的如果解决了这些是否还有模型本身的问题呢这个也需要进一步审视也期待能够更多的反馈。 总的来说多变业务模型如何能够实现快速交付是一个长期的课题业务模板也许不是一个最完美的方案但是也是值得去进一步发掘的方向。------ END ------作者简介胡同学 架构师目前负责ERP成本应用系统的架构设计与开发工作。也许您还想看成本计算引擎动态规则解析技术详解ERP开放平台定制化远程高效协作秘笈建模平台标准组件可维护性改进实践一个全栈式的应用集成平台打破“信息孤岛”
