Compare commits
2 Commits
9997283e87
...
a758256fa6
Author | SHA1 | Date | |
---|---|---|---|
a758256fa6 | |||
508c61e323 |
171
1-流程梳理/8-G3ERP集团查询模块解读/8-G3ERP集团查询_总模块解读-v1.0.md
Normal file
171
1-流程梳理/8-G3ERP集团查询模块解读/8-G3ERP集团查询_总模块解读-v1.0.md
Normal file
@ -0,0 +1,171 @@
|
||||
# G3ERP集团查询模块解读
|
||||
|
||||
## 一、集团查询模块概述
|
||||
|
||||
G3ERP的集团查询模块是专为连锁企业总部设计的中央数据决策中心。它超越了单一门店的视角,将分散在各个分支机构的业务数据进行集中整合、深度挖掘与多维分析,旨在为集团层面的战略规划、运营监控、风险预警和绩效评估提供全面、及时、准确的数据支持。
|
||||
|
||||
该模块的核心价值在于“全局洞察”。它将复杂的日常业务(如配送、销售、库存)转化为一系列直观、易懂的分析报表和经营指标,使管理者能够穿透数据迷雾,快速掌握整个连锁体系的运营状况。从宏观的销售趋势、库存健康度,到微观的单品贡献、价格波动,集团查询模块为企业实现数据驱动的精细化管理提供了强大的引擎。
|
||||
|
||||
## 二、集团查询模块组成部分
|
||||
|
||||
集团查询模块通过对海量业务数据的重组与分析,构建了五大核心分析领域,这些领域环环相扣,共同构成了集团总部的决策支持体系。
|
||||
|
||||
### 1. 配送协同分析
|
||||
|
||||
此板块聚焦于总部与门店之间的物流与信息流闭环管理,确保配送效率与准确性。它涵盖从门店订货、总部配送处理、双方对账、逆向退货到最终财务结算的全过程监控。
|
||||
|
||||
> **对应报表组:** `门店订货业务`、`配送处理业务`、`配送门店对账`、`配送退货业务`、`配送财务业务`
|
||||
|
||||
### 2. 全域进销存分析
|
||||
|
||||
此板块提供集团层面的全局商品流通视图。它整合了所有门店的入库、销售、库存三大核心数据流,并包含了专门面向财务的进销存平衡核对,是集团掌握整体商品动态和财务状况的基础。
|
||||
|
||||
> **对应报表组:** `门店入库`、`门店销售`、`门店库存`、`财务进销存表`、`加盟店销售表`、`加盟店库存`
|
||||
|
||||
### 3. 价格策略监控
|
||||
|
||||
此板块旨在确保集团价格政策的统一执行与市场适应性。它不仅监控内部价格体系,还追踪价格变动流程,并关注外部竞争环境。
|
||||
|
||||
> **对应报表组:** `现行价格体系`、`价格变动业务`、`同行价格情况`
|
||||
|
||||
### 4. 专项运营分析
|
||||
|
||||
此板块针对特定的运营管理活动进行穿透式分析,帮助管理者评估专项工作的效果,并进行绩效考核。
|
||||
|
||||
> **对应报表组:** `损益业务`、`提成绩效`、`店间调拨`、`指标任务`
|
||||
|
||||
### 5. 品类与商品贡献度分析
|
||||
|
||||
这是最高阶的经营分析模块,旨在通过深度数据挖掘优化商品结构和盈利能力。它从供应商、单品、SKU、新品、毛利、主推品、关联销售、客流、价格带等多个维度,对商品经营进行全方位、立体化的剖析。
|
||||
|
||||
> **对应报表组:** `供应商贡献分析`、`商品贡献分析`、`连锁SKU分析`、`新品追踪分析`、`毛利比较分析`、`主推布局分析`、`关联销售分析`、`客单品单分析`、`价格带分析`、`月度汇总分析`、`必备商品分析`
|
||||
|
||||
## 三、集团查询模块关联关系
|
||||
|
||||
集团查询模块的五大分析领域并非孤立存在,而是建立在底层业务数据之上,并通过层层递进的分析逻辑,最终服务于集团的战略决策。
|
||||
|
||||
### 1. 模块关系图
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph "数据源 (Source)"
|
||||
direction LR
|
||||
A["供应链数据"]
|
||||
B["门店运营数据"]
|
||||
C["财务数据"]
|
||||
end
|
||||
|
||||
subgraph "分析层 (Analysis Engine)"
|
||||
direction TB
|
||||
D["配送协同分析"]
|
||||
E["全域进销存分析"]
|
||||
F["价格策略监控"]
|
||||
G["专项运营分析"]
|
||||
H["<b>品类与商品<br>贡献度分析</b>"]
|
||||
end
|
||||
|
||||
subgraph "决策层 (Decision Making)"
|
||||
direction LR
|
||||
I["战略规划"]
|
||||
J["运营监控"]
|
||||
K["绩效考核"]
|
||||
end
|
||||
|
||||
A --> D
|
||||
A --> E
|
||||
B --> D
|
||||
B --> E
|
||||
B --> F
|
||||
B --> G
|
||||
B --> H
|
||||
C --> E
|
||||
C --> G
|
||||
|
||||
D --> J
|
||||
E --> I
|
||||
E --> J
|
||||
F --> I
|
||||
F --> J
|
||||
G --> J
|
||||
G --> K
|
||||
H --> I
|
||||
H --> K
|
||||
```
|
||||
|
||||
- **数据基础**:所有分析都源于供应链、门店运营和财务系统产生的最原始的业务数据。
|
||||
- **分析层次**:
|
||||
- **配送协同** 和 **全域进销存** 是基础分析,它们将原始数据整理为可读的业务报告。
|
||||
- **价格监控** 和 **专项运营** 是专题分析,针对特定管理目标进行深入探查。
|
||||
- **品类与商品贡献度** 是战略分析,通过复杂的模型和算法提供最高层次的经营洞察。
|
||||
- **决策支持**:所有分析结果最终都指向决策。例如,`进销存分析`为**战略规划**中的库存策略提供依据;`专项运营分析`的结果直接用于**绩效考核**;而所有分析报表共同构成了总部的**运营监控**仪表盘。
|
||||
|
||||
## 四、核心业务流程分析
|
||||
|
||||
集团查询模块本身不产生业务,而是对业务流程的结果进行分析。其核心是“数据切片”与“多维透视”。
|
||||
|
||||
### 1. 典型分析流程:从宏观到微观
|
||||
|
||||
管理者通常遵循一个从宏观发现问题到微观定位原因的分析路径:
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["<b>1. 宏观监控</b><br>(月度汇总分析)"] --> B{"发现销售额未达标"};
|
||||
B --> C["<b>2. 维度下钻</b><br>(销售汇总分析)"];
|
||||
C --> D{"定位到'华南大区'业绩下滑"};
|
||||
D --> E["<b>3. 门店对比</b><br>(连锁销售汇总-按门店)"];
|
||||
E --> F{"发现'深圳旗舰店'问题最严重"};
|
||||
F --> G["<b>4. 品类探查</b><br>(连锁销售汇总-按分类)"];
|
||||
G --> H{"发现'高端护肤品'分类销售锐减"};
|
||||
H --> I["<b>5. 单品追溯</b><br>(连锁销售汇总-按商品)"];
|
||||
I --> J["<b>6. 根因分析</b><br>结合[价格监控]、[库存分析]等<br>判断是缺货、价格失当或竞品冲击"];
|
||||
```
|
||||
|
||||
## 五、集团查询模块思维导图
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((集团查询模块))
|
||||
配送协同分析
|
||||
门店订货业务
|
||||
配送处理业务
|
||||
配送门店对账
|
||||
配送退货业务
|
||||
配送财务业务
|
||||
全域进销存分析
|
||||
门店入库
|
||||
门店销售
|
||||
门店库存
|
||||
财务进销存表
|
||||
价格策略监控
|
||||
现行价格体系
|
||||
价格变动业务
|
||||
同行价格情况
|
||||
专项运营分析
|
||||
损益业务
|
||||
提成绩效
|
||||
店间调拨
|
||||
指标任务
|
||||
品类与商品贡献度分析
|
||||
供应商贡献分析
|
||||
商品贡献分析
|
||||
连锁SKU分析
|
||||
新品追踪分析
|
||||
毛利比较分析
|
||||
主推布局分析
|
||||
关联销售分析
|
||||
客单品单分析
|
||||
价格带分析
|
||||
月度汇总分析
|
||||
必备商品分析
|
||||
```
|
||||
|
||||
## 六、总结
|
||||
|
||||
G3ERP集团查询模块是连锁企业实现数字化、精细化管理的“大脑”和“仪表盘”。它通过对全集团业务数据的集中化、多维度、深层次分析,为企业提供了前所未有的全局洞察力。
|
||||
|
||||
该模块的强大之处不仅在于其报表种类的丰富,更在于其内在的分析逻辑:
|
||||
- **从流程到协同**:将孤立的配送、入库、退货流程,整合为端到端的`配送协同分析`。
|
||||
- **从个体到全局**:将单个门店的进销存,提升为覆盖所有机构的`全域进销存分析`。
|
||||
- **从运营到战略**:提供了从基础的运营报表到高级的`品类与商品贡献度分析`的完整路径,支撑从日常监控到长期战略规划的各层次决策需求。
|
||||
|
||||
综上所述,有效利用集团查询模块,能够帮助连锁企业总部及时发现经营风险、精准定位管理问题、科学评估绩效、深度优化商品结构,最终在激烈的市场竞争中建立起基于数据的核心竞争力。
|
BIN
1-流程梳理/实际补货流程⭕️/media/图片1.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/图片1.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 226 KiB |
BIN
1-流程梳理/实际补货流程⭕️/media/图片2.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/图片2.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 226 KiB |
BIN
1-流程梳理/实际补货流程⭕️/media/图片3.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/图片3.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 267 KiB |
BIN
1-流程梳理/实际补货流程⭕️/media/流程图1.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/流程图1.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 245 KiB |
BIN
1-流程梳理/实际补货流程⭕️/media/流程图2.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/流程图2.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 218 KiB |
BIN
1-流程梳理/实际补货流程⭕️/media/流程图3.png
Normal file
BIN
1-流程梳理/实际补货流程⭕️/media/流程图3.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 202 KiB |
BIN
1-流程梳理/实际补货流程⭕️/补货实际流程(图文).docx
Normal file
BIN
1-流程梳理/实际补货流程⭕️/补货实际流程(图文).docx
Normal file
Binary file not shown.
186
1-流程梳理/实际补货流程⭕️/补货实际流程.md
Normal file
186
1-流程梳理/实际补货流程⭕️/补货实际流程.md
Normal file
@ -0,0 +1,186 @@
|
||||
## 实际补货流程 - 3种
|
||||
|
||||
【背景说明】【业务流转过程中涉及的3个不同的ERP】
|
||||
|
||||
ERP:整合企业核心业务流程的管理信息系统。
|
||||
|
||||
  
|
||||
|
||||
【目前总体情况】没有缺货登记,以销定采。
|
||||
|
||||
采购补货**前置**条件:**集团的ERP1** 已经对商品,客户,供应商的基础资料录入,审核,符合GSP的才能出现在采购可选的商品里。
|
||||
|
||||
#### 【一】 采集公司补货
|
||||
|
||||
**第一步,商品部**根据历史销售数据算出补货量 - 实际库存 - 在途数量 = 计划数量。
|
||||
|
||||
**说明1:** 计划数量目前只考虑销售量,有一个**“可销月”**的概念,根据药店小、中、大不同,按1.2倍,1.5倍、1.8倍来给出计划数量,最终显示给店长的计划数量就是倍数之后的结果。
|
||||
|
||||
**说明2:** 商品部如果需要调整计算公式参数,向**IT部**提出需求,由IT部改,改动周期大约是半年至一年。
|
||||
|
||||
<br>
|
||||
|
||||
**第二步,** 影响最直接,店长可自己调整计划数量,店长调整的数量根据自己的经验来判断,可以调整的数量在商品部设置好的库存上下限范围内。一般店长调整的数量,采购和审查都不会过多干预,只是会有所属的ERP3的连锁公司来进行每日的库压监督。考虑的是对店长的后续的绩效考核。
|
||||
|
||||
<br>
|
||||
|
||||
**第三步,** 各门店的计划数量,由**ERP3的13家连锁公司**来总计 → ERP2的博大来采集。
|
||||
|
||||
**说明:**一般门店无采购权,需要由公司来采购,而且在GSP流程上,需要有审核流程,连锁公司日常也负责对门店的“库压”之类的进行监管,绩效考核。
|
||||
|
||||
<br>
|
||||
|
||||
**第四步,博大ERP2**,属于一树集团,不同的法人主体,是一树的**采集公司**。博大来实际处理补货,但是每日只处理规定的工作计划的店铺。此处有**两种**情况:
|
||||
|
||||
**1.满足** 查库存 → 满足需求 → 占库存 → 传到仓库管理系统WMS仓库进行处理(汇总波次计划:多家门店需要的同一产品汇总计划) → 拣货 → 复核 → 集货 → 装货 → WMS回传给博大ERP2 → 回传连锁ERP3 → 通知门店待收货 → 门店确定/门店退货。
|
||||
|
||||
**说明1:收货按实物收货,不走ERP系统。**
|
||||
|
||||
<br>
|
||||
|
||||
**2.不满足** 查库存 → 库存不满足需求 → 缺货计划 → 采购员。
|
||||
|
||||
**说明1:** 缺货了推送给采购员是一个数据的汇总传输,实际不影响真实的补货,缺货了本次流程也结束了,不会另外补货;下一次的计划数量也不受上一次的缺货数量的影响。
|
||||
|
||||
<br>
|
||||
|
||||
**说明2:商品部、运营部和仓库**3个部门会共同规划,为不同的店铺规定好提货补货时间,店铺提交的计划数量,只能在规定时间提货,博大也只按规定的时间处理店铺的补货。若店铺忘记提交申请也只延后到下一次。按不同的店铺大小,需求,有一周1次,一周2-3次补货的。
|
||||
|
||||
<br>
|
||||
|
||||
**说明3:** 采购部根据采购计划报表的库存销售的数据来生采购 → 仓库备货也有一个**“可销月”**的概念,一般为1.8倍/2.0倍。【**注:** 采购部的采购计划没有归因分析,没有建议,只是比较单纯的考虑存销的数据,所以这是接下来想要去用AI预测优化的方向。】
|
||||
|
||||
<br>
|
||||
|
||||
#### 采集公司补货流程图
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "商品部"
|
||||
A["1\. 根据历史销售数据计算计划数量<br>(历史销售 — 库存 — 在途 = 计划数量)"]
|
||||
end
|
||||
|
||||
subgraph "门店"
|
||||
B["2\. 店长根据经验调整计划数量<br>(在库存上下限范围内)"]
|
||||
end
|
||||
|
||||
subgraph "连锁公司 (ERP3)"
|
||||
C["3\. 汇总各自区域内各门店的计划数量"]
|
||||
end
|
||||
|
||||
subgraph "采集公司 (博大 ERP2)"
|
||||
D["4\. 接收并处理连锁公司的汇总计划"]
|
||||
E{"5\. 检查自身库存是否满足需求"}
|
||||
F["缺货计划<br>(推送给采购员,本次流程结束)"]
|
||||
end
|
||||
|
||||
subgraph "仓库 (WMS)"
|
||||
G["6\. WMS处理汇总波次计划<br>(拣货 -> 复核 -> 集货 -> 装货)"]
|
||||
end
|
||||
|
||||
subgraph "收货与反馈"
|
||||
H["7\. WMS回传博大ERP2,2再回传连锁ERP3"]
|
||||
I["8\.博大ERP2再回传连锁ERP3"]
|
||||
J["9\. 通知门店待收货"]
|
||||
K["10\. 门店按实物确认收货/退货,不经过ERP"]
|
||||
end
|
||||
|
||||
A --> B
|
||||
B --> C
|
||||
C --> D
|
||||
D --> E
|
||||
E -- "库存不足" --> F
|
||||
E -- "库存满足" --> G
|
||||
G --> H
|
||||
H --> I
|
||||
I --> J
|
||||
J --> K
|
||||
```
|
||||
|
||||
<br>
|
||||
|
||||
#### 【二】 店店调拨
|
||||
|
||||
**原则:就近原则**
|
||||
|
||||
由缺货店铺查库,判断,申请,拿货。
|
||||
|
||||
**假设:**A门店缺货,A门店查库存,发现B门店和C门店有货,自己按就近原则判断,如B门店更近,向B门店提出调货申请,B门店有货就要无条件配合,A门店自己取货或者快递取货。
|
||||
|
||||
A门店取货入库,同时B门店出库,实时完成成本划;A拿货1,则A收货1,B门店退货1。
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
#### 店店调拨流程图
|
||||
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "缺货门店 (A)"
|
||||
A1["1\. 发现缺货"]
|
||||
A2["2\. 查询附近门店(B, C)库存"]
|
||||
A3["3\. 按就近原则向B门店申请调货"]
|
||||
A4["4\. A店自行取货或快递取货"]
|
||||
A5["5\. A门店扫码入库,完成收货"]
|
||||
end
|
||||
|
||||
subgraph "有货门店 (B)"
|
||||
B1["无条件配合"]
|
||||
B2["B门店扫码出库"]
|
||||
end
|
||||
|
||||
subgraph "系统 (ERP)"
|
||||
S1["实时完成成本划拨"]
|
||||
end
|
||||
|
||||
A1 --> A2
|
||||
A2 --> A3
|
||||
A3 --> B1
|
||||
B1 --> A4
|
||||
A4 --> A5
|
||||
A5 --> S1
|
||||
A4 --> B2
|
||||
B2 --> S1
|
||||
```
|
||||
|
||||
<br>
|
||||
|
||||
#### 【三】 供应商直调
|
||||
|
||||
供应商直调,直调商品只能是**非药品类**的商品。
|
||||
|
||||
商家售卖的非药品商品也需要在ERP系统的资质管理中确认有资质卖某种商品,由采购部在系统中录入,质量部审核。
|
||||
|
||||
直调某商品也是由店长申请,如果没有仓存,则不配送。
|
||||
|
||||
<br>
|
||||
|
||||
#### 供应商直调程图
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "前提条件 (ERP系统)"
|
||||
P1["1\. 供应商和非药品商品资质<br>由采购部录入、质量部审核"]
|
||||
end
|
||||
|
||||
subgraph "门店"
|
||||
S1["2\. 店长申请直调商品"]
|
||||
end
|
||||
|
||||
subgraph "系统/供应商"
|
||||
C1{"3\. 检查是否有库存可配送"}
|
||||
D1["供应商无货不配送<br>(流程结束)"]
|
||||
D2["供应商满足需求直接发货"]
|
||||
end
|
||||
|
||||
subgraph "收货"
|
||||
R1["4\. 门店收货"]
|
||||
end
|
||||
|
||||
P1 --> S1
|
||||
S1 --> C1
|
||||
C1 -- "否" --> D1
|
||||
C1 -- "是" --> D2
|
||||
D2 --> R1
|
||||
```
|
@ -1 +1 @@
|
||||
[Task Manager UI](http://localhost:50106)
|
||||
[Task Manager UI](http://localhost:57831)
|
Loading…
x
Reference in New Issue
Block a user