之前有提到过我在后面的公司参与了ERP系统的搭建和前台工具的实现。上一篇跟大家分享了前台销售工具（BD助手）的立项-结项的过程。从这篇开始，我会将之前负责的生鲜供应链ERP系统以我自己的理解逐步拆解出来，供大家参考。可能会有很多理解不足或者遗漏掉的地方，请大家多多斧正。
供应链ERP系统很庞大，涉及到的板块也比较多，我会拆分几篇跟大家逐步分享下，初步计划是以基础数据-采购与供应商管理-订单与配送-库存管理-财务与结算-数据分析与决策支撑的几个模块跟大家分享。
生鲜行业本身是一个具体的业务方向，也有自己的一些特殊性，系统设计也会兼容这部分特殊性，所以从事不同业务方向的同学有疑惑或者有指正的地方可以在评论区留言，大家一起探讨下。
感兴趣的可以关注一下我，跟我一起从零到整拆解供应链生鲜ERP。
老规矩，先讲一下项目的背景。
最开始做这套生鲜ERP的主营业务方向是面向于批发客户（主要是大B，政企单位）的食堂采购需求，旨在通过线上ERP系统管理采销配过程中的各个环节，做到资金流/订单流/物流三大流程的线上化，提升人效且规范化管理。
后期也借助这套生鲜ERP快速支持了新业务的拓展，也就是当前在做的面向小B的在线批发配送业务，可以说整体的架构设计还是比较合理的，后续也支撑了集团多业态业务的开展。
拆解供应链免不了要从基础数据开始，基础数据作为数字化供应链的基石，对整个生鲜供应链的运作都起到关键作用。
每个系统都有自己的基础数据，支撑系统的正常运行，同时也因为业务方向的不同，基础数据的种类也不同。
本篇分享的生鲜供应链ERP中主要包含的基础数据种类有组织、商品、供应商、客户、仓库、物流等。
基础数据中有些是涉及到全局使用的，比如商品编码，必须全局统一，避免因商品编码定义不同导致的系统单据流转差异；有些数据又是局部使用的，比如商品销售名称，在不同业务或不同区域中允许存在不同定义，以适配不同的业务场景。
基础数据的管理主要涉及到数据的增删改查以及审核和下发，要确保数据管理的高效性、安全性和准确性，需要做到：
基础数据一定要在设计整套系统架构时考虑清楚，如果系统已经实施了大半或者已经上线后，才发现基础数据的设计不足以支撑现有业务，那改起来是非常痛苦的，等于楼盘都交付了要去改地基。
我们现有业务在商品主数据方面就出了类似的问题，调整过程很漫长且难以落地。
我们公司的商品主数据是在SAP中进行维护的，商品准入是在OA申请商品主数据创建流程，补充商品的基础信息，流程审批通过后创建成功，再依次下发到各业务系统中，作废同理。
根据使用场景和管理维度的不同，可以将商品用SPU/SKU/SN来代指。
一般来说一个SPU可能对应多个SKU，一个SKU可能对应多个SN码，即
举个例子，大家可能更好理解一些：
上文中有提到基础数据也分为全局使用和局部使用，可以拿商品基础数据来拆解一下。
1）如果业务系统仅服务于一个业务体，不存在其他业务或不考虑复用性，那商品基础数据可以全量维护在一个表单，商品准入后即创建成功。
这样创建和维护比较简单但局限性很大，基本只适合在后台使用，前台无法共用。如果有一些通用属性相同，销售属性不同的，需要重新再维护一遍，工作量也比较大，且统计也比较难以聚合起来，统一分析。这种比较适合品类比较单一，不需要做聚合的企业。
2）如果考虑多业务体复用性，则可以根据商品属性区分：
这样在商品准入时维护商品基础属性即可，销售属性在实际引用时维护，这样可以做到系统在服务不同业务体的时候，同一商品仅需要建码一次，在引用时通过维护不同销售属性加以区分可以灵活适配不同业务情况，同时也避免数据混乱或数据统计不完全，比较适合平台型企业或品类较为复杂，涉及到的数据维度也比较复杂的企业。
商品类目是商品的一个重要组成部分，在内/外部系统中使用频率都比较高。一般来说，商品类目有一级类目，二级类目，三级类目等。三级类目基本可以满足多数系统的使用需求，但不排除有些业务有更精细化的要求，会分到四级类目，比如汽车零部件行业等。
1）商品类目可以拆分为后台主分类和前端销售分类。
商品主分类是所有商品的标准分类，通常是两级到三级树形结构，涉及到很多外部系统的逻辑，一般不会轻易变更。
主分类上还可以承载商品的基础属性，在维护商品时，选择主分类后，可以将分类下的属性带出，节省维护商品数据的时间。
同时，后台主分类也多用于商品数据分析的场景，辅助判断商品的流通性、销售趋势、价格趋势、库存趋势等关联性。
2）前端销售分类主要是用来促进销售，有时具备一些营销或节日属性（比如今日促销、产地蔬菜），且多是平铺，方便客户浏览查看。
前端销售分类有时还会承载一种业务类型的规则聚集，以我们做的生鲜供应链为例，在发起售后时，不同品类（猪肉，蔬菜，杂百等）之间的售后审批流程，售后规则均不相同；这种不同类别的配置就是依靠前端销售分类来区分的。
后台主分类和前端销售分类的对应可能是一对一，一对多，多对多的，主要还是看实际的业务场景配置。
再跟大家分享下几种编码的使用场景：
同商品主数据，都是在SAP中建档，流程通过后创建成功，作废同理，流程的搭建更多是匹配公司业务规则，可根据实际情况配置。
1）客户基本信息，可直接获取：
2）客户消费信息，由平台消费记录获得：
3）客户用户画像，通过数据分析得出：
如果系统同时支撑多个业务主体，那么在建档时可能会区分出几种客户类型，用以方便最后结算：
档口客户：一个结算客户下可能存在多个档口客户，在最终结算时均结算在一个结算客户下。举个例子：客户中有学校客户，学校有多个食堂，每个食堂都有单独的菜单，分开采购。这时候就可以建立一个学校主体作为结算客户，多个食堂作为档口客户，档口客户之间可以分开下单，数据不互通，最后统一结算在学校这个结算客户下。
供应商指能够为组织提供工程、物资和服务的个人或企业。在决定其为供应商之前，通常会经过审查，符合审查条件的可以进入供应商准入流程，还会根据公司定义的供应商评级，为供应商赋予不同的合作层级。
图1.供应商准入流程
图2.供应商拉黑流程
1）供应商基本信息，供应商的名称、地址、联系方式，企业法人，经营范围，营业三证附件，统一社会信用代码，营业期限等基础信息
2）供应商财务信息，企业名称、开户行、开户城市、开户名、银行账号、税号等。包括与供应商之间的财务交易，如账期、付款方式等。确保与供应商的财务往来得以准确记录和核对。
3）供应商合同，记录和管理与供应商签订的采购合同。包括合同的起始日期、终止日期、合同金额、付款条款等内容。
1）供应商资质审核，确认供应商的合法身份，评估供应商的财务状况和经营能力。
2）供应商绩效考核，通过内部绩效考核规则和实际业务满足率进行综合评估，淘汰掉不达标的供应商。
3）供应商风险评估，分析供应商所处行业和地区的风险，比如在疫情期间，封禁区域的的生鲜产品运送不过来，需要提前考虑备选供应商。
4）供应商合规性评估，监控供应商的表现，一旦发现供应商存在交货延误、产品质量问题、违约行为或存在采购和供应商存在非法交易等，及时拉黑供应商，避免造成公司财产损失。
仓库数据主要是应用在供应链和仓储管理中记录和存储的与仓库运营相关的各种信息。
组织数据中包含公司、业务线数据。
公司信息主要用于挂账，做财务账目往来。
公司基本信息，包含公司编码、公司名称、国家/地区、公司地址、企业法人、联系人、联系方式、公司银行账号信息、税号、营业三证附件、统一社会信用代码、启用状态、税务信息等。
业务线数据主要用于供应链系统中用于划分业务范围、管理业务流程的关键信息，同一公司下不同业务主体可以用业务线加以区分，灵活运用可以使系统同时兼容多种业务情况。
业务线数据，包含业务线编码、业务线名称、业务线分类、业务类型、所属公司、启用状态等。
如果物流是公司自建的，那需要维护的物流信息会比较齐全，包含车辆信息，司机信息，运输路线，运输模式等。
但物流配送行业本身要求专业性高、成本投入大且短期难以看到成果等，通常很多企业是通过三方物流配送公司完成履约，我们公司也是如此。
基于每家配送公司的履约效率，服务范围和履约费用的不同，企业通常会选择多个物流配送公司同时完成服务，那我们需要维护的就是物流公司常规属性数据。
物流公司数据，包含物流公司名称、注册信息、法人、联系人、联系方式、配送方案、启用状态等。
基础数据的管理是数字化供应链系统的支柱，直接影响到企业的运营效率和决策水平。我们在做系统设计的时候，应该优先考虑基础数据的建设：商品主数据，客户主数据，供应商数据，仓库数据，组织数据等，只有把基础数据这个地基打好，系统才能在其之上稳步前行。
基础数据的管理要确保数据的高效性、安全性和准确性，做到：①数据定义清晰，标准 ②数据准入流程规范 ③数据准确，质量高 ④数据安全，权限分离 ⑤数据定期备份。
总的来说，只有通过对商品、客户、供应商、仓库、组织和物流等多维度基础数据的深入理解和科学管理，企业才能在激烈的市场竞争中立于不败之地。
后面几章，我们将深入探讨采购与供应商、订单与配送、财务与结算、库存管理、数据分析与决策支持等关键模块，共同构建完整的数字化供应链体系。
本文由 @安妮的日常生活 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。