之前有提到过我在后面的公司参与了ERP系统的搭建和前台工具的实现。上一篇跟大家分享了前台销售工具（BD助手）的立项-结项的过程。从这篇开始，我会将之前负责的生鲜供应链ERP系统以我自己的理解逐步拆解出来，供大家参考。可能会有很多理解不足或者遗漏掉的地方，请大家多多斧正。

供应链ERP系统很庞大，涉及到的板块也比较多，我会拆分几篇跟大家逐步分享下，初步计划是以基础数据-采购与供应商管理-订单与配送-库存管理-财务与结算-数据分析与决策支撑的几个模块跟大家分享。

生鲜行业本身是一个具体的业务方向，也有自己的一些特殊性，系统设计也会兼容这部分特殊性，所以从事不同业务方向的同学有疑惑或者有指正的地方可以在评论区留言，大家一起探讨下。

感兴趣的可以关注一下我，跟我一起从零到整拆解供应链生鲜ERP。

一、背景

老规矩，先讲一下项目的背景。

最开始做这套生鲜ERP的主营业务方向是面向于批发客户（主要是大B，政企单位）的食堂采购需求，旨在通过线上ERP系统管理采销配过程中的各个环节，做到资金流/订单流/物流三大流程的线上化，提升人效且规范化管理。

后期也借助这套生鲜ERP快速支持了新业务的拓展，也就是当前在做的面向小B的在线批发配送业务，可以说整体的架构设计还是比较合理的，后续也支撑了集团多业态业务的开展。

拆解供应链免不了要从基础数据开始，基础数据作为数字化供应链的基石，对整个生鲜供应链的运作都起到关键作用。

二、基础数据

每个系统都有自己的基础数据，支撑系统的正常运行，同时也因为业务方向的不同，基础数据的种类也不同。

本篇分享的生鲜供应链ERP中主要包含的基础数据种类有组织、商品、供应商、客户、仓库、物流等。

基础数据中有些是涉及到全局使用的，比如商品编码，必须全局统一，避免因商品编码定义不同导致的系统单据流转差异；有些数据又是局部使用的，比如商品销售名称，在不同业务或不同区域中允许存在不同定义，以适配不同的业务场景。

基础数据的管理主要涉及到数据的增删改查以及审核和下发，要确保数据管理的高效性、安全性和准确性，需要做到：

• 数据定义要清晰、明确，不存在歧义，数据类型要标准化。
• 规范数据的准入和更新流程，明确下发字段和下发及时性要求。
• 保障数据的质量，定期校验数据准确性。
• 设计数据安全与权限策略，限制对敏感数据的访问和编辑，追踪数据的变更记录。
• 定期备份数据，以防止数据的损坏或丢失。

基础数据一定要在设计整套系统架构时考虑清楚，如果系统已经实施了大半或者已经上线后，才发现基础数据的设计不足以支撑现有业务，那改起来是非常痛苦的，等于楼盘都交付了要去改地基。

我们现有业务在商品主数据方面就出了类似的问题，调整过程很漫长且难以落地。

三、商品主数据

1. 商品准入/作废

我们公司的商品主数据是在SAP中进行维护的，商品准入是在OA申请商品主数据创建流程，补充商品的基础信息，流程审批通过后创建成功，再依次下发到各业务系统中，作废同理。

2. 商品的SPU/SKU/SN码

根据使用场景和管理维度的不同，可以将商品用SPU/SKU/SN来代指。

1. SPU（Standard Product Unit）： 标准产品单元。SPU是一组具有相似外观、功能和用途的商品的标准标识。通常，同一SPU下的商品在功能和外观上是相同的，只是细节上可能有所不同。
2. SKU（Stock Keeping Unit）： 库存量单位。SKU是对具体库存商品的唯一标识，通常由数字和字母组成。每个SKU都对应着一个特定的商品，它可以是SPU的一个具体实例。SKU通常用于区分不同的商品属性，如颜色、尺寸、包装等。
3. SN码（Serial Number）： 序列号。SN码是商品的唯一序列号，通常由数字、字母或二维码组成。每个商品都有一个唯一的SN码，通过这个码可以追踪商品的生产、流通和销售情况。SN码通常用于保障产品的质量追溯、售后服务以及防伪等方面。

一般来说一个SPU可能对应多个SKU，一个SKU可能对应多个SN码，即

举个例子，大家可能更好理解一些：

• SPU更多的使用场景是在销售和运营层面，同时方便用户的搜索和后台的快速归集及数据统计，制定商品策略等。
• SKU是具体的商品属性的归集，更多应用在价格和供应链层面，包含商品定价，出入库管理，商品备货，库存管理等。
• SN码也是供应链管理的维度，不参与销售行为，更多的是库存精细化管理的标记，一般应用于电子产品、汽车、医药等较多，要精确到某一个具体的实物身上，方便后续追踪。

3. 商品属性

上文中有提到基础数据也分为全局使用和局部使用，可以拿商品基础数据来拆解一下。

1）如果业务系统仅服务于一个业务体，不存在其他业务或不考虑复用性，那商品基础数据可以全量维护在一个表单，商品准入后即创建成功。

这样创建和维护比较简单但局限性很大，基本只适合在后台使用，前台无法共用。如果有一些通用属性相同，销售属性不同的，需要重新再维护一遍，工作量也比较大，且统计也比较难以聚合起来，统一分析。这种比较适合品类比较单一，不需要做聚合的企业。

2）如果考虑多业务体复用性，则可以根据商品属性区分：

• 基础属性（全局统一）：①商品编码 ②商品名称 ③商品主分类 ④基础单位。
• 销售属性（允许不同业务体定义值不同）：①商品销售名称 ②前端销售分类 ③税率 ④商品销售单位 ⑤规格 ⑥标签 ⑦商品图片等。

这样在商品准入时维护商品基础属性即可，销售属性在实际引用时维护，这样可以做到系统在服务不同业务体的时候，同一商品仅需要建码一次，在引用时通过维护不同销售属性加以区分可以灵活适配不同业务情况，同时也避免数据混乱或数据统计不完全，比较适合平台型企业或品类较为复杂，涉及到的数据维度也比较复杂的企业。

4. 商品类目

商品类目是商品的一个重要组成部分，在内/外部系统中使用频率都比较高。一般来说，商品类目有一级类目，二级类目，三级类目等。三级类目基本可以满足多数系统的使用需求，但不排除有些业务有更精细化的要求，会分到四级类目，比如汽车零部件行业等。

1）商品类目可以拆分为后台主分类和前端销售分类。

商品主分类是所有商品的标准分类，通常是两级到三级树形结构，涉及到很多外部系统的逻辑，一般不会轻易变更。

主分类上还可以承载商品的基础属性，在维护商品时，选择主分类后，可以将分类下的属性带出，节省维护商品数据的时间。

同时，后台主分类也多用于商品数据分析的场景，辅助判断商品的流通性、销售趋势、价格趋势、库存趋势等关联性。

2）前端销售分类主要是用来促进销售，有时具备一些营销或节日属性（比如今日促销、产地蔬菜），且多是平铺，方便客户浏览查看。

前端销售分类有时还会承载一种业务类型的规则聚集，以我们做的生鲜供应链为例，在发起售后时，不同品类（猪肉，蔬菜，杂百等）之间的售后审批流程，售后规则均不相同；这种不同类别的配置就是依靠前端销售分类来区分的。

后台主分类和前端销售分类的对应可能是一对一，一对多，多对多的，主要还是看实际的业务场景配置。

5. 编码

再跟大家分享下几种编码的使用场景：

1. 商品编码：一般是指SPU编码，商品准入后自动生成，一般使用在系统内部，用于确定具体商品。
2. SKU编码：维护销售属性后生成，多用于供应链内部流转，一般使用在系统内部，唯一性确定某一个商品。
3. 商品条码：一般称为69码，69码的编码规则包含20位数字，其中前14位是全球唯一的商品编码，由全球唯一编码机构（GS1）颁发；第15到17位是地区码，表示商品在哪些地区销售；第18位是包装级别码，表示商品包装的级别；第19位到20位是校验码，用于检验前面数字的准确性。主要是用于仓库出入库扫描，识别SKU的依据。
4. SN码：商品出厂时印在商品包装盒上的识别码，同一SKU下的每一个实物SN码都不同，一般用在商品价值比较高或需要全程溯源的行业。

四、客户数据

1. 客户主数据维护/作废

同商品主数据，都是在SAP中建档，流程通过后创建成功，作废同理，流程的搭建更多是匹配公司业务规则，可根据实际情况配置。

2. 客户信息

1）客户基本信息，可直接获取：

• 包括客户的名称、公司法定名称、联系人等基本身份信息。
• 联系方式： 客户的电话号码、电子邮件地址、传真等联系方式。
• 地址信息： 客户的办公地址、仓库地址或者其他重要地址信息，特别是在涉及到物流和配送的业务中。
• 记录负责该客户的销售团队成员信息，跟进记录等，以便协调沟通。

2）客户消费信息，由平台消费记录获得：

• 客户购买历史。
• 客户支付记录。
• 客户参与营销记录情况

3）客户用户画像，通过数据分析得出：

• 客户生命周期。
• 客户类型（普通客户/VIP会员/分销商/批发商等）。
• 客户偏好（下单偏好及客户售后偏好等）。
• 客户层级。

3. 客户结算

如果系统同时支撑多个业务主体，那么在建档时可能会区分出几种客户类型，用以方便最后结算：

1. 结算客户：一般性的客户类型，表示与公司有结算关系的客户。这可能包括常规的销售和采购活动。
2. 一次性客户：短期一次性的交易，不需要保留过多的客户信息，通常不做建档，统一放在同一个一次性客户下。

档口客户：一个结算客户下可能存在多个档口客户，在最终结算时均结算在一个结算客户下。举个例子：客户中有学校客户，学校有多个食堂，每个食堂都有单独的菜单，分开采购。这时候就可以建立一个学校主体作为结算客户，多个食堂作为档口客户，档口客户之间可以分开下单，数据不互通，最后统一结算在学校这个结算客户下。

五、供应商数据

供应商指能够为组织提供工程、物资和服务的个人或企业。在决定其为供应商之前，通常会经过审查，符合审查条件的可以进入供应商准入流程，还会根据公司定义的供应商评级，为供应商赋予不同的合作层级。

1. 供应商准入/拉黑

图1.供应商准入流程

图2.供应商拉黑流程

2. 供应商信息

1）供应商基本信息，供应商的名称、地址、联系方式，企业法人，经营范围，营业三证附件，统一社会信用代码，营业期限等基础信息

2）供应商财务信息，企业名称、开户行、开户城市、开户名、银行账号、税号等。包括与供应商之间的财务交易，如账期、付款方式等。确保与供应商的财务往来得以准确记录和核对。

3）供应商合同，记录和管理与供应商签订的采购合同。包括合同的起始日期、终止日期、合同金额、付款条款等内容。

3. 供应商评估

1）供应商资质审核，确认供应商的合法身份，评估供应商的财务状况和经营能力。

2）供应商绩效考核，通过内部绩效考核规则和实际业务满足率进行综合评估，淘汰掉不达标的供应商。

3）供应商风险评估，分析供应商所处行业和地区的风险，比如在疫情期间，封禁区域的的生鲜产品运送不过来，需要提前考虑备选供应商。

4）供应商合规性评估，监控供应商的表现，一旦发现供应商存在交货延误、产品质量问题、违约行为或存在采购和供应商存在非法交易等，及时拉黑供应商，避免造成公司财产损失。

六、仓库数据

仓库数据主要是应用在供应链和仓储管理中记录和存储的与仓库运营相关的各种信息。

• 仓库基本信息，仓库编码、仓库名称、仓库类型、仓库位置、仓库负责人、负责人联系方式、仓库面积、仓库层数、冷库数量、营业时间、启用/停用状态等。
• 货架和设备信息，货架编码、货架类型、货架容量和规格、设备编码、设备信息、设备状态等。
• 员工信息，员工工号、员工姓名、员工联系方式、员工角色、工作权限等。

七、组织数据

组织数据中包含公司、业务线数据。

1. 公司信息

公司信息主要用于挂账，做财务账目往来。

公司基本信息，包含公司编码、公司名称、国家/地区、公司地址、企业法人、联系人、联系方式、公司银行账号信息、税号、营业三证附件、统一社会信用代码、启用状态、税务信息等。

2. 业务线信息

业务线数据主要用于供应链系统中用于划分业务范围、管理业务流程的关键信息，同一公司下不同业务主体可以用业务线加以区分，灵活运用可以使系统同时兼容多种业务情况。

业务线数据，包含业务线编码、业务线名称、业务线分类、业务类型、所属公司、启用状态等。

八、物流数据

如果物流是公司自建的，那需要维护的物流信息会比较齐全，包含车辆信息，司机信息，运输路线，运输模式等。

但物流配送行业本身要求专业性高、成本投入大且短期难以看到成果等，通常很多企业是通过三方物流配送公司完成履约，我们公司也是如此。

基于每家配送公司的履约效率，服务范围和履约费用的不同，企业通常会选择多个物流配送公司同时完成服务，那我们需要维护的就是物流公司常规属性数据。

物流公司数据，包含物流公司名称、注册信息、法人、联系人、联系方式、配送方案、启用状态等。

九、总结一下

基础数据的管理是数字化供应链系统的支柱，直接影响到企业的运营效率和决策水平。我们在做系统设计的时候，应该优先考虑基础数据的建设：商品主数据，客户主数据，供应商数据，仓库数据，组织数据等，只有把基础数据这个地基打好，系统才能在其之上稳步前行。

基础数据的管理要确保数据的高效性、安全性和准确性，做到：①数据定义清晰，标准 ②数据准入流程规范 ③数据准确，质量高 ④数据安全，权限分离 ⑤数据定期备份。

总的来说，只有通过对商品、客户、供应商、仓库、组织和物流等多维度基础数据的深入理解和科学管理，企业才能在激烈的市场竞争中立于不败之地。

后面几章，我们将深入探讨采购与供应商、订单与配送、财务与结算、库存管理、数据分析与决策支持等关键模块，共同构建完整的数字化供应链体系。