企业官网建设流程全解析

简介：面向新能源行业供应链管理者与咨询顾问的埃森哲专题报告PPT，系统梳理数字化供应链规划及集成计划的现状评估与能力提升路径。资源为单个pptx文件，共95页，约4.26MB，当前已有66人学习。内容涵盖总体架构、业务架构、应用架构现状分析，并基于五场执行委员会领导层访谈、十四场业务领导层访谈及五十场业务代表访谈，形成覆盖计划、采购、制造、交付及IT领域的关键发现。报告同时结合光伏行业季节性、地域性与规模性特征，提出以专业化生产、精细化管理整合供应链资源，并探讨通过规模化扩产与差异化订单策略适应市场波动。读者可借此快速获取头部咨询机构的新能源供应链诊断思路、行业趋势判断与集成计划改进方向，适合用于企业规划参考或行业研究。

1. 新能源行业的“集成计划”为什么难做

很多做供应链的老兵都有一个感觉：新能源比传统汽车、快消品制造难的多。原因是供应链管理系统用ERP拆完料、跑完MRP还不够，需求波动大、产能爬坡快、物料替代频繁、周期又非常长，计划与计划之间经常打架。95页PPT里的埃森哲新能源供应链规划及集成计划方案，本质是在回答一件事：当需求、供应、库存、产能、物流都被业务单元各管一摊时，用什么模型把整个链条拉通用。

本文不评价咨询公司那份交付物本身，而是站在IT和计划系统建设者的角度，把这套“新能源行业供应链规划及集成计划”的方法论拆成可落地的数据模型、计划引擎边界、参数设计和实施路径。适合正在做供应链中台、APS、S&OP或制造执行系统集成的架构师、数据分析师和计划经理。无论你拿到的是一份95页的蓝图还是5页的会议纪要，最后都要回到一个问题上：谁会用什么系统、在什么频率下、读什么数据、产出什么计划指令。

2. 域模型与计划层级：先把“计划什么”定义明白

2.1 新能源供应链的域模型：从硅料到电芯再到整机

新能源行业的供应链可以抽象成四个域：原材料域、零部件域、产品域、能源资产域。在原材料的粒度上，光伏涉及硅料、银浆、玻璃；电池涉及锂、钴、镍、正负极材料；风电涉及稀土和特种钢材。零部件域则是电池模组、逆变器、叶片、齿轮箱。产品域是电池包、光伏组件、风机、充电桩。能源资产域则是电站、储能柜和配网侧的设备，这部分是新能源区别于汽车供应链的一个显着特点。

每个域名下都有独立的计划对象。原材料域的计划对象是采购订单和到货批次，零部件域是物料需求计划和在制品，产品域是主生产计划，而能源资产域的计划对象直接就是项目交付时间和并网时间。IT系统做集成计划时，第一个任务不是建模型，而是把这些域名下的计划对象统一成一套自然键，否则每个系统都在建自己的物料编码和日期维度，计划就永远对不齐。

我在实际项目里常用的做法是定义六维主键：工厂、物料、库存批次、需求订单、时间桶、计划版本。这六个字段构成集成计划数据平台的主键，所有计划域都围绕它们展开。有了这层抽象，S&OP、主计划、物料需求计划、产能计划才有共享的坐标，而不是各算各的再靠人工对账。

2.2 计划层级：战略、战术、执行三层怎么联动

集成计划按时间尺度分三层。战略层按季度和年度做产能规划与投资决策，总供应能力是多少、要不要扩建工厂、要不要锁长单，决策周期是月或季度。战术层按周和月做S&OP与主生产计划，覆盖需求预测、库存策略、粗产能校验，决策周期是周。执行层按天和小时做排产、物料下达和齐套检查，决策周期是天甚至分钟。

三层必须有承接关系，否则就会失真。战略层说产能够，战术层主计划按满产产，执行层发现某个工序的模具不够，整个计划就要返工。传统做法是让PSI报表手工传递，线下的Excel比系统里的数快一步。集成计划的意义在于把三层串成闭环：战略层输出供应约束，战术层按约束生成主计划，主计划放行给执行层排产，执行层实际执行结果再回写战术层做偏差分析。

还要注意计划滚动窗口的设计。新能源行业的采购提前期很长，硅料长单可能锁到三年，电芯级原材料大概三个月，而销售需求只能看到一个月。三层计划的滚动周期不同，如果统一做月度全量重排，短周期的需求波动就会频繁冲击长期产能规划。所以说集成计划不是把三层数据放到一张表里，而是建立一套“长期不变、中期可调、短期刚性”的跨层约束框架。

3. 集成计划的数据底座：主数据、需求与库存快照设计

3.1 主数据字段设计：贯穿ERP、MES、WMS的计划属性

集成计划系统不是从零造一套主数据，而是复用并补充现有主数据。物料主数据里必须带上计划属性：默认提前期、安全库存策略、批量规则、最小/最大库存、供应商提前期、质检周期。工厂主数据要带上产能属性：产线上下限、换型时间、班次日历、设备综合效率。BOM主数据要区分规划BOM和制造BOM。规划BOM用于长期物料需求预测，制造BOM用于MRP运算，混用会导致计划量偏大或偏小。

还有一类容易漏的数据是约束主数据。比如某个电池模组工厂，仓储区域只能放三天的电芯库存，货位选择还要避开危险品分区。IS此类的仓库约束、物流约束、质检约束，都要建模成计划参数。在一个S&OP月份滚动模型里，这部分约束直接决定计划可行性。

主数据质量怎么检验？我用一个简单方法：对每个物料算一遍“计划相关字段完整度”。完整度低于80%的物料判定为不可计划，从S&OP中排除。不需要复杂的数据治理平台，一张SQL校验清单就能做到：

SELECT md.material_code, SUM(CASE WHEN md.lead_time_days IS NOT NULL THEN 1 ELSE 0 END) AS has_lead_time, SUM(CASE WHEN md.safety_stock_qty IS NOT NULL THEN 1 ELSE 0 END) AS has_safety_stock, COUNT(*) AS total_plans FROM plan_master_data md GROUP BY md.material_code HAVING has_lead_time < total_plans OR has_safety_stock < total_plans;

这段SQL的目的不是查出所有缺失字段，而是快速列出哪些物料会在MRP运算中产生异常。运行后得到的结果是主数据治理的原始任务清单，后续按物料分组逐一维护。主数据维护权要落在计划部门而非IT部门，IT只负责提供校验视图和变更流程。

3.2 计划快照：如何用SQL汇总多系统库存与需求

集成计划系统需要一份可重复计算的计划快照，它由需求侧、供应侧、库存侧三个映射表构成。实际落地时数据来自不同的系统，SAP取库存和采购订单，MES取在制品数量，WMS取实物库存，CRM取销售预测。将这些数据汇聚到计划数据平台的快照表中，每批提取时间要打上版本戳。

CREATE TABLE plan_snapshot AS SELECT t.bucket_date, t.site_code, t.material_code, SUM(t.demand_qty) AS demand_qty, SUM(t.supply_qty) AS supply_qty, SUM(t.stock_qty) AS stock_qty FROM ( SELECT '2025-06-01' AS bucket_date, site_code, material_code, demand_qty, 0 AS supply_qty, 0 AS stock_qty FROM sales_forecast UNION ALL SELECT '2025-06-01', site_code, material_code, 0, open_po_qty, 0 FROM purchase_order UNION ALL SELECT '2025-06-01', site_code, material_code, 0, 0, current_stock_qty FROM inventory_position ) t GROUP BY t.bucket_date, t.site_code, t.material_code;

这段SQL把三张业务表按统一日期桶合并成计划快照。第一次跑和第二次跑结果一样，因为都是同一时点的数据。真正要设计的是快照版本号，以便在回测时回溯“当时的计划输入是什么”。计划版本建议用年月日小时加批次号，例如“202506011800_01”，这样后续做计划偏差分析时能准确定位是哪一版计划出了问题。

快照生成时间也很关键。白天业务系统在动态变化，库存数据一直在动，我一般习惯在凌晨零点半跑批，取SAP的日结库存和MES的季度盘点快照。如果要支持白天的插单模拟，就需要把快照表做成增量刷新而不是全量重算，这会对数据平台产生额外的实时性要求。

4. 计划引擎的最小复现：用Python实现一个带产能约束的物料需求计划

4.1 用Python表达计划运算逻辑

集成计划的核心引擎一般叫APS或高级计划系统，商业软件里常见的是Blue Yonder、SAP IBP、OMP。但不管多贵的系统，内核都是几个最简单的算法规格：净需求计算、按时段分桶、产能校验、安全库存调整。下面这段代码展示最小可运行的MRP核心逻辑，定位在“战术层主计划”的粒度，适合团队理解计划引擎再去做选型或自研。

import pandas as pd # 需求侧：销售预测加安全库存 demand = pd.DataFrame({ 'week': ['W1', 'W2', 'W3', 'W4'], 'gross_demand': [1200, 1500, 1300, 1600], 'safety_stock': [300, 300, 300, 300], 'onhand_begin': [800, 0, 0, 0], 'schedule_receipt': [600, 0, 500, 0], }) # 产能约束：每周可产出上限 capacity = {'W1': 1400, 'W2': 1400, 'W3': 1400, 'W4': 1400} # 批量规则：最小批量 1000，批量倍数 500 lot_min, lot_multiple = 1000, 500 for i, row in demand.iterrows(): week = row['week'] projected_available = row['onhand_begin'] + row['schedule_receipt'] \ - row['gross_demand'] - row['safety_stock'] net_need = max(0, -projected_available) # 基本批量取整 planned_order = max(lot_min, net_need) if planned_order % lot_multiple != 0: planned_order = ((planned_order // lot_multiple) + 1) * lot_multiple # 产能约束：超出则剪裁并把超出部分推到下一周 planned_order_actual = min(planned_order, capacity[week]) shortfall = planned_order - planned_order_actual # 把下周的期初库存指回来 if i + 1 < len(demand): deficit_impact = row['onhand_begin'] + row['schedule_receipt'] \ - row['gross_demand'] - planned_order_actual demand.at[i + 1, 'onhand_begin'] = max(0, deficit_impact) if shortfall > 0: demand.at[i + 1, 'schedule_receipt'] += shortfall \ if i + 1 < len(demand) else 0 print(f"{week}: 净需求={net_need}, 计划订单={planned_order}, " f"实际投产={planned_order_actual}, 缺口推延={shortfall}")

这段代码解决的问题是按周期把净需求和产能限制同步展开。注意projected_available计算必须用安全库存，否则MRP系统永远在做“清零式”补货。批量模数lot_multiple=500对应产线换型的最小经济批量，这个参数要由生产部门给出，不能拍脑袋写死。产线产能的约束采用钳制规则，产能不足部分推到下一周，实际项目中还要考虑加班费率与延期交付惩罚成本，才会决定是否推延。

4.2 计划算法选型：MRP、APS、仿真优化各用在哪个层级

行业里的工具选型大致遵循以下匹配关系。ERP自带的MRP适合执行层做物料需求展开，假设是无限产能，运算速度快但是缺乏产能视角。APS适合战术层的S&OP与排程，把产能范围、批量、优先级都作为约束，用线性规划或启发式算法求出可行解。仿真优化适合战略层和瓶颈工序分析，用离散事件仿真模拟不同需求场景对整体交付的影响，运算要跑几分钟到几小时。

选型时要先问自己问题核心是“会不会缺料”还是“什么时候能交付”。缺料问题MRP就能回答，不用买APS；交付问题必须走排程优化，MRP算不出来。很多项目先花了三个月实施APS，发现主数据质量撑不起来，又退回ERP MRP加Excel，这是最经典的走弯路路径。我建议规划时把项目拆成两层：先做快照和报表体系让需求、库存、供应可见，再上计划优化算法。没有可见度之前的算法参数都是黑盒。

还有一个容易忽略的点是环境版本。新能源行业有碳酸锂价格波动、硅料价格周期、政策补贴节奏等多重变量，APS的确定性算法会在输入变化时產生完全不同的方案。所以计划引擎的输出必须支持“多方案对比”，而不是只给一版结果。这里的多方案可以用仿真方法——对需求做高、中、低三个场景，各跑一遍计算，人工再决策。

5. 落地路径：从PPT蓝图到ERP、APS、MES的接口设计与实施节奏

5.1 系统集成全景：四个系统之间的数据流向

一套供应链集成计划落地在信息系统层面，核心是打通四个角色。ERP管采购订单和库存，是计划执行的结果回写处。APS或计划系统负责跑战术层的S&OP与主计划，属于决策中枢。MES提供产线实际投产与完工数据，是执行反馈源头。WMS提供真实库存水位和库位状态，是库存保障的事实基础。

数据流向是这样设计的。第一步，ERP的历史库存、采购在途、销售订单进入计划快照层。第二步，计划系统结合MES的工序能力生成主计划和补货建议。第三步，补货建议回传ERP创建采购申请和生产订单。第四步，MES按生产订单派工，产出实际完工数量，WMS更新库位库存。第五步，计划系统对比原计划与实际结果，生成偏差报表并触发下一轮滚动计划。

接口协议方面，如果ERP是SAP ECC或S4，建议用RFC或IDoc接口作为数据载体，计划系统通过接口表读写；如果ERP是Oracle，则用EBS的开放式接口表或REST API。计划系统与MES的接口通常走REST或消息队列，比如Kafka或RabbitMQ。集成计划实施中最大的坑是实时性定位不清晰：不是所有数据都要实时同步，采购在途和库存每天同步一次就够，MES完工数据却需要按小时同步，否则排程结果执行反馈过慢。

从表里可以看到，频率设计要跟着业务节奏走，不是越实时越好。采购订单日批就能覆盖，实时接口反而增加成本和故障点。MES的完工数据如果延迟超过一小时，当天排产可能错过调整窗口，所以频率最高。每个接口都要设计失败重试和断点续跑机制，新能源工厂一般存在高温粉尘环境，网络稳定性不作保障，接口断连是非常常见的事。

5.2 实施节奏与主数据治理的先后顺序

落地节奏推荐分三阶段。第一阶段建设控制塔和计划快照，重点是把需求、供应、库存数据拉到同一个平台上，用报表回答“现状是什么”。第二阶段上线S&OP主计划，重点是用计划引擎替代Excel的PSI表，让计算逻辑可复现。第三阶段才做排程和优化，将产能细排和设备级计划交给算法。

每个阶段都要设置退出条件。第一阶段的退出条件是计划快照表能连续跑30天不出错，且业务方承认报表数据口径对自己有用。第二阶段的退出条件是主计划结果比历史Excel方案偏差低于指定百分比，并完成两个滚动周期的验证。第三阶段才算完整集成计划系统的投入使用。

主数据治理的投入占比通常被低估。我见过太多项目在APS引擎上花三个版本，但组织层面的物料清洗、BOM规范、计划参数维护没人负责，最后系统跑出来的计划没人敢用。建议成立一个计划数据管家角色，按月维护安全库存、提前期和批量规则，任何参数修改都留审计日志。没有数据管家的计划系统再先进也会慢慢失去可信度。

6. 用历史数据回测安全库存：一个可量化的进阶验证技巧

计划系统上线前要做一次回测，拿过去六个月的真实需求、库存、到货数据跑历史计划，与实际结果对比，验证计划参数是否合理。安全库存是验证中最容易量化的变量，因为它直接决定缺货成本与资金占用。传统设置法按经验给一个固定天数，比如15天，但新能源行业需求波动剧烈，固定天数会导致旺季缺货、淡季爆仓。回测的思路是改变安全库存系数，观察缺货率与平均库存的关系。

import numpy as np import pandas as pd # 模拟历史周度需求 np.random.seed(42) weeks = 26 demand = pd.Series(np.random.normal(loc=1000, scale=200, size=weeks)) for safety_factor in [0.1, 0.3, 0.5, 0.8, 1.0]: # 用需求量分布的标准差乘系数作为安全库存 safety_stock = demand.std() * safety_factor stockout_count = 0 inventory_list = [] current_inv = 1500 for d in demand: current_inv -= d if current_inv < 0: stockout_count += 1 current_inv = max(0, current_inv) # 补充到目标库存水平 current_inv += max(0, safety_stock - current_inv) inventory_list.append(current_inv) avg_inventory = np.mean(inventory_list) print(f"安全库存系数 {safety_factor}: 缺货周数={stockout_count}, " f"平均库存={avg_inventory:.0f}")

这段模拟把安全库存当作标准差的倍数，跑26周历史需求，对比不同系数下的缺货周数和平均库存。运行结果能看到明显权衡：系数越大缺货越少，但库存资金占用越高。具体取什么值取决于缺货成本与库存成本的财务折算，不是技术问题，但IT要能输出这组权衡曲线给业务决策。回测的更深一层意义是检验计划参数是否有解释力，如果安全库存系数调到二倍标准差仍然频繁缺货，就要检查需求预测模型和提前期参数，而不是继续调系数。

最后提醒一个常见误区：把历史平均需求直接回放给计划模型验证。因为历史需求本身就是受当时库存影响的结果，存在反馈偏差，严格做法是用预测值作为输入，回放当时的计划逻辑才公平。IT团队如果能把这个偏差圈出来，给出的回测结论才站得住脚。这也是实际项目中识别计划系统可信度最有效的一项体检。

本文还有配套的精品资源，点击获取