零售系统架构图-风君雪科技博客

对零售系统分析了下,然后设计了个架构图,基本有了这个架构图,剩下就是对具体页面功能逻辑进行设计而已。

一、在设计这个架构图的过程,有一些想法

1、业务是基于网上一个文章“新零售-从业务到产品”有兴趣可以看看,文章上面也有一套架构图。不过看了文章及架构,是基于自身业务逻辑来设计,而不是基于通用saas设计,所以抽离了下。

2、基于saas设计的一些考虑点:

    A、要考虑客户可能没有WMS、TMS、ERP等系统情况,说白了,就是要考虑完全没有外部系统的情况下,单靠这套系统就能撑起来所有业务。一开始是没有增加“采购”、“仓库”、“物流”这些模块,但是考虑到这种情景下,的确需要添加这些模块,但是只需要最核心的功能即可

    B、多账号中心:saas系统是多租户,每个租户的权限、数据都是独立。所以设计这套系统的时候,需要增加一个“多账号中心”,目的是独立授权。

    C、模块之间都得提供行业标准接口,不过这种就是后端技术的了,在功能架构里面,其实比较难体现。主要是考虑这个系统肯定会存在只要某几个功能模块,其他功能服务,通过第三方系统满足的情况,这种情况下要做的只是提供行业标准的接口,然后让他们对接就好了。

3、模块大小划分问题:这个~~自身经验问题,所以模块划分也许存在不合理情况。不过对于saas系统来说,当系统复杂度去到一定程度,才需要拆分代码。在此之前有个大概范围划分就好。原因是很难完全一下子将业务梳理清楚,其次业务不停在发生变化,新业务不断产生,也许大模块下再拆分子模块,这种是很正常的。(试想下,一个CRM也可以做到非常非常复杂,非常非常精细,但是对于零售系统来说,起码现在这些模块设计可以满足80%的需求。)

二、产品路线图

    其实如果是软件外包公司,可以根据这些自研一套saas系统,然后再推广销售。以前做外包的时候已经研究过,saas是一条出路,根据某个比较成熟的项目,然后将项目的需求产品化。在这个自主研发的过程里面,最重要是销售能力(外包的销售方式跟saas的方式不一样),其次是产品经理的能力(能否真正产品化)。

    然后从0到1再到N的去建设这个产品,产品路线规划方面就需要有一定顺序,不然将这套系统弄出来,基本钱烧光,公司就准备倒闭了。基本划分成三个阶段,实际的路线或者规划,可以根据不同资源情况,不同能力情况再细分,这里只是凭空设计下而已。

    阶段一:能实现基本交易、业务流程

    所需重点功能点:pos机、商品、订单、支付、店铺、账号-权限等基础功能

    阶段二:塑造销售亮点,支撑销售团队

    所需重点功能点:小程序、店铺助手、会员、CMS、营销

    阶段三:完善业务体系

    所需中重点功能点:采购管理、仓库管理、物流管理、客服、财务

    阶段四:拓展业务范围

    所需中重点功能点:配送助手、线下配送、核销设备、仪表盘

    备注:这种划分,只是业务层面的划分,还有底层接口、数据处理、权限细分这些,则根据阶段里面开发资源、公司情况来去自由加入。因为saas系统很偏重底层的这些性能方面的要求,但是因为是从0到1到N的过程,如果全部资源都放在底层功能、架构设计上的话,就像前面说的,做出一个非常非常牛逼,世界顶尖的架构,但是对于销售没有一点好处。卖不出去的产品,不是产品。而我们是产品经理,站的立场需要考虑整体情况。

因为没在这个行业从事过,分析是基于空想及一些文章,所以肯定存在不合理或者有场景不满足。但是saas系统本身就是不断成长,不断发展的系统,今天你看到的是这样,明天可能就会增加更多的服务。