伙伴云客服论坛»论坛 S区 S行业资讯 查看内容

0 评论

0 收藏

分享

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

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

需求描绘

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

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

目的系统

aPaaS如何在不同组织构造运营组织构造中应用-2.png


企业对外的运营系统

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

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

传统构建思路

企业内管理系统构建思路

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

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

基于aPaaS构建的考虑

基于aPaaS来构建上面两种场景的业务系统,分析如下:
假设构建企业内部的,重点是依托于APaaS的自定义页面和自定义流程,以及业务逻辑控制;实在实现不了的可能就得通过低代码的方式来实现。
而第二种业务(看上去是夸多个企业)的业务组织形式,这种在aPaaS中实现起来就具备一定的复杂度了;同时也咨询了好多主流的aPaaS效劳商,他们对于这种情况的业务比较难以支持。不过我通过从系统构建角度做了考虑,主要还是分为两种思路:
    一种是与定制开发业务一样,租户信息逻辑隔离,业务流程和页面通过分角色来配置和实现,子公司、外部企业和客户等通过部门的方式停止管理,而不是多租户的形式(假设是多租户需要考虑租户与租户间数据交互问题,特别是涉及到多个企业的业务流程审批问题);

    aPaaS如何在不同组织构造运营组织构造中应用-4.png

    图例:定制开发一个大平台通过建立角色分权限实现不同租户的权限管控,统一数据存储
    这种形式比较常见于我们定制开发业务,或是一些集团性客户业务开发,所有业务在一个大系统内部,通过受权的方式分配权限,同一个大平台内部只涉及到业务流转方面的数据交互,不涉及到系统集成
    这种形式构建应用具备一下特征:
    整个平台就是一个大系统,在平台内部按模块停止划分,不涉及到系统与系统之间的集成租户与租户建的数据隔离可通过逻辑隔离方式处置,通过编码或框架区分租户到达数据隔离效果系统没有多应用的概念,只要模块的概念,通过大角色的方式停止应用包装和菜单组合面向不同用户是通过大角色的方式停止描绘,程序内部逻辑需要通过编码来实现通过逻辑隔离租户数据的情况下,编码实现难度大,逻辑处置相对复杂整个系统开发都在一个大系统内部,内部的模块划分或微效劳划分容易职责不清,容易形成大泥球项目系统集成相对较少,更多是系统内的各个模块之间的业务和数据交互,不存在跨系统调用一说

    另一种是以独立租户数据隔离,多租户应用共享,分不同类型租户构建相同的应用系统然后给与租户受权使用;如下示意图:

    aPaaS如何在不同组织构造运营组织构造中应用-5.png

    图例: 租户独立数据库,多租户应用共享
    这种构造的特征在于:
    所有应用的构建都在运营平台停止管理运营平台对每个租户有绝对的控制权各个租户更多是使用已经定义好的软件,无需考虑软件维护问题租户失去自定义权限(也可以将低代码才干形成应用,受权给各个租户,这样会更复杂)每个租户业务数据按租户严格隔离
统一构建应用,然后通过受权的方式将应用受权给对应的租户停止使用;当然在运营平台可以对任意租户的应用权限停止调整,从而到达统一控制的目的;
    真正意义的多租户SaaS系统+aPaaS:其实就是在真个SaaS平台中,为每个租户开通了aPaaS才干(无代码/低代码),每个租户在平台上基于这些工具去构建自己的应用;这里有以下一些特点:
    使用该平台的用户需要具备一定的计算机根底和软件构建思维每个租户数据完全隔离每个租户的应用构建可以高度个性化整个平台是以工具方式停止运营,而非业务系统

aPaaS如何在不同组织构造运营组织构造中应用-6.png



以上内容假设你有不同的观点,欢送留言讨论

回复

举报 使用道具

全部回复
暂无回帖,快来参与回复吧
本版积分规则 高级模式
B Color Image Link Quote Code Smilies

怪咖小青年
注册会员
主题 15
回复 25
粉丝 0
|网站地图
快速回复 返回顶部 返回列表