零售系统架构图

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

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

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系统本身就是不断成长，不断发展的系统，今天你看到的是这样，明天可能就会增加更多的服务。