aPaaS如何在不同组织结构运营组织结构中应用

最近几年低代码/无代码在业内很是热闹,因此很多这方面的平台也是层出不穷,现在基本统称为aPaaS;结合公司过往承接过的一些业务,再结合各大aPaaS平台的设计,对于如何基于aPaaS构建企业内部和企业运营系统做了一些思考,如下

需求描述

从过往的业务中提取了两类比较有代表性的业务进行探讨,一类是企业内部的管理系统(此次以一个设备生产企业为例);另一类是一个重型设备租赁企业的运营系统;

企业内部的管理系统

这里以一个设备生产型企业为例,企业以生产某类定制型电子产品为主,希望构建一套系统解决内部从销售接单,到销售转生产,生产备料、生产、测试、打包、运输、开票、最后客户确认收货、关单;一整个围绕销售订单的业务闭环;其中企业现在已经存在ERP系统,主要为解决企业内财务、成本、产品BOM等信息;也就以为这构建这套系统主要为企业内部使用的,并且可能需要与既有的ERP系统做对接,也需要与外部的物流系统和开票系统做对接等,当然也不排除希望能基于某个工具自定义其他的业务流程和数据的管理与共享。这里不做过细的赘述。

image.png
目标系统
image.png

企业对外的运营系统

此处以一个生产重型设备的并主要以租赁模式进行整个商业模型运营的企业;他们希望通过将自己生产的设备,分时段租给对应的客户,并按量/按时收费。他们希望通过构建一套系统,一方面与自己的WMS系统做对接,同步到库存数据,同时也需要对租赁出去的设备做位置跟踪,运行状态监控(这里通过物联网技术,可以当做是有另一套物理网系统);销售渠道商有自营、通过子公司销售、通过自己的代理公司销售、以及为终端客户提供可以查看设备运行状态和租赁使用用量(时间/用量),以及租赁合约等信息;在销售网络上代理公司和子公司需要就租赁的设备做利润分成(不同级别的企业可能分成比例不一样);

image.png
如上图所示,作为集团企业与内外部的关系,集团公司下设有分公司,分公司可以直接开展业务;当然集团公司下面也可以直接招代理,代理公司直接发展客户,或者集团公司直接发展客户;这个过程中集团企业可以控制与自己合作的所有企业信息;如果是构建一套系统,绝对控制权在集团公司手上;每个企业可以维护自己的用户和部门以及自己的客户信息等内容。

传统构建思路

企业内管理系统构建思路

这种系统的构建按传统的方式构建比较简答,如果公司有一些技术的沉淀和积累,直接聚焦于业务进行业务流程的串接开发即可;当然过程中可以采用一些比较灵活的流程和表单设计工具辅助快速开发。因为是一个企业,所以一般数据都是共享或是放到同一个数据库中的,基本上不存在太多数据共享和多系统和多模块联动的问题。说白了,直接干就得了。

企业外部运营系统构建思路

对于这个运营系统的构建,需要考虑两个因数,1首发企业是否对整个系统有绝对的操控权;另一个就是数据共享(数据权限的问题);
如果是直接定制化开发,我们可以通过采用公用应用和公用数据库的方式,数据库共享即在对应的业务表里面需要区分不同合作企业的业务下,加上对应租户字段(类似SaaS结构的逻辑隔离);应用系统中需要根据对应企业的标识判断调用对应的业务逻辑和操作对应的Table数据。

基于aPaaS构建的思考

基于aPaaS来构建上面两种场景的业务系统,分析如下:
如果构建企业内部的,重点是依托于APaaS的自定义页面和自定义流程,以及业务逻辑控制;实在实现不了的可能就得通过低代码的方式来实现。
而第二种业务(看上去是夸多个企业)的业务组织模式,这种在aPaaS中实现起来就具备一定的复杂度了;同时也咨询了好多主流的aPaaS服务商,他们对于这种情况的业务比较难以支持。不过我通过从系统构建角度做了思考,主要还是分为两种思路:

  • 一种是与定制开发业务一样,租户信息逻辑隔离,业务流程和页面通过分角色来配置和实现,子公司、外部企业和客户等通过部门的方式进行管理,而不是多租户的形式(如果是多租户需要考虑租户与租户间数据交互问题,特别是涉及到多个企业的业务流程审批问题);
    image.png
    图例:定制开发一个大平台通过建立角色分权限实现不同租户的权限管控,统一数据存储
    这种模式比较常见于我们定制开发业务,或是一些集团性客户业务开发,所有业务在一个大系统内部,通过授权的方式分配权限,同一个大平台内部只涉及到业务流转方面的数据交互,不涉及到系统集成
    这种模式构建应用具备一下特征:
  1. 整个平台就是一个大系统,在平台内部按模块进行划分,不涉及到系统与系统之间的集成
  2. 租户与租户建的数据隔离可通过逻辑隔离方式处理,通过编码或框架区分租户达到数据隔离效果
  3. 系统没有多应用的概念,只有模块的概念,通过大角色的方式进行应用包装和菜单组合
  4. 面向不同用户是通过大角色的方式进行描述,程序内部逻辑需要通过编码来实现
  5. 通过逻辑隔离租户数据的情况下,编码实现难度大,逻辑处理相对复杂
  6. 整个系统开发都在一个大系统内部,内部的模块划分或微服务划分容易职责不清,容易形成大泥球项目
  7. 系统集成相对较少,更多是系统内的各个模块之间的业务和数据交互,不存在跨系统调用一说
  • 另一种是以独立租户数据隔离,多租户应用共享,分不同类型租户构建相同的应用系统然后给与租户授权使用;如下示意图:
    image.png
    图例: 租户独立数据库,多租户应用共享
    这种结构的特征在于:
  1. 所有应用的构建都在运营平台进行管理
  2. 运营平台对每个租户有绝对的控制权
  3. 各个租户更多是使用已经定义好的软件,无需考虑软件维护问题
  4. 租户失去自定义权限(也可以将低代码能力形成应用,授权给各个租户,这样会更复杂)
  5. 每个租户业务数据按租户严格隔离

统一构建应用,然后通过授权的方式将应用授权给对应的租户进行使用;当然在运营平台可以对任意租户的应用权限进行调整,从而达到统一控制的目的;

  • 真正意义的多租户SaaS系统+aPaaS:其实就是在真个SaaS平台中,为每个租户开通了aPaaS能力(无代码/低代码),每个租户在平台上基于这些工具去构建自己的应用;这里有以下一些特点:
  1. 使用该平台的用户需要具备一定的计算机基础和软件构建思维
  2. 每个租户数据完全隔离
  3. 每个租户的应用构建可以高度个性化
  4. 整个平台是以工具方式进行运营,而非业务系统

image.png

以上内容如果你有不同的观点,欢迎留言探讨

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一起学开源

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值