简介：这份《钢铁企业产销一体化整体解决方案》PDF文档，面向钢铁行业信息化从业者、ERP与MES实施顾问及企业生产管理人员，聚焦产销衔接不畅、计划脱节、质量管理不完善等典型痛点，提供可落地的整体解决思路。资源包共1个PDF文件，大小约771KB，内容以文字方案为主，便于快速查阅与打印研读。文档以邯钢产销一体化咨询项目为背景，系统梳理了ERP环境下钢铁企业一般产销模式的工作流程，剖析了销售、生产、质量、发运等环节的衔接缺陷，并给出涵盖ERP R3系统、高级计划系统、MES制造执行与作业排程模块、PCS过程控制系统的产销一体化整体架构，同时探讨了计划与调度体系、质量管理体系等实施要点。目前已有83人学习下载，适合需要理解钢铁行业产销协同架构、ERP与MES集成方案及有限能力计划、ATP/CTP等关键技术的读者参考借鉴。
1. 钢铁企业产销一体化整体解决方案：从「以销定产」到「算得准、排得下、交得出」
很多钢铁企业的产销协同，表面看是销售和生产两个部门在吵架，根子上是「合同—订单—炉次—轧批—准发」这条链路的数据断了。销售签了 3000 吨冷轧卷，交期 25 天，生产说原料板坯不够、轧机排不下；等生产勉强排下去，销售又发现客户要的牌号跟实际产出对不上。所谓钢铁企业产销一体化整体解决方案，核心不是上一套 ERP 就完事，而是把销售订单、质量设计、生产计划、合同匹配、库存准发这几件事用同一套物料编码和同一套规则串起来，让「接单时算得准、排产时排得下、交付时交得出」。这套方案适合年产能 100 万吨以上的长流程或短流程钢厂的信息化负责人、生产计划员和销售运营岗，也适合正在做 MES 与 ERP 集成、想把产销协同从 Excel 搬到系统里的团队。下面按我实际落地过的路径，把选型、建模、排产、匹配和踩坑讲清楚。
2. 产销一体化的数据底座：物料编码、质量设计与合同结构
2.1 为什么物料编码不统一，后面全是白干
钢铁行业的物料编码比离散制造复杂得多。同一块板坯，在炼钢叫「炉次号」，在热轧叫「轧批号」，到冷轧又变成「卷号」，销售那边还有「合同号」「订单行号」。如果这几套编码各管各的，产销一体化就是空中楼阁。我一般会先做一件事：定义一条贯穿全流程的「主物料线索」，通常用「材料号 + 工序状态」来表达。材料号在质量设计阶段就生成，后续所有工序都挂在这个号上，炉次、轧批、卷号只是它的属性维度，不是独立实体。
常见做法是建三张主表：物料主数据表、质量设计表、合同行表。物料主数据管牌号、规格、标准；质量设计管「这个牌号走哪条工艺路线、每道工序要控什么参数」；合同行管客户要什么、交期什么时候、允不允许替代。这三张表的主键必须能互相引用，否则后面合同匹配时你会发现自己在对着一堆字符串做模糊匹配，那才是真正的血泪经验。
2.2 质量设计表怎么建：从牌号到工艺路线
质量设计是产销一体化的「翻译层」，把销售语言翻译成生产语言。销售说「我要 DC01 冷轧卷，厚度 0.8mm，宽度 1250mm」，质量设计要输出：走哪条产线、炼钢要什么成分、热轧要什么终轧温度、冷轧要什么压下率。下面是一个简化的质量设计表结构和插入示例。
-- 质量设计主表：一个牌号+规格区间对应一条工艺路线 CREATE TABLE qd_route ( route_id VARCHAR(32) PRIMARY KEY, -- 工艺路线ID grade VARCHAR(20) NOT NULL, -- 牌号，如 DC01 thickness_min DECIMAL(6,3), -- 厚度下限 mm thickness_max DECIMAL(6,3), -- 厚度上限 mm width_min INT, -- 宽度下限 mm width_max INT, -- 宽度上限 mm steelmaking_code VARCHAR(20), -- 炼钢工艺代码 hot_roll_code VARCHAR(20), -- 热轧工艺代码 cold_roll_code VARCHAR(20), -- 冷轧工艺代码 priority INT DEFAULT 100 -- 匹配优先级，越小越优先 ); -- 插入一条 DC01 冷轧卷的工艺路线 INSERT INTO qd_route VALUES ('RT_DC01_08_1250', 'DC01', 0.600, 1.000, 1200, 1300, 'SM_LD_01', 'HR_FT_880', 'CR_01', 10);这段 SQL 的逻辑是：当销售订单进来时，系统用牌号、厚度、宽度三个条件去qd_route里匹配，命中优先级最高的那条路线，就得到了炼钢、热轧、冷轧的工艺代码。参数说明上，thickness_min/max和width_min/max是闭区间，实际匹配时要注意边界值归哪一边，我一般规定「下限含、上限不含」，避免同一规格命中两条路线。priority是后悔药，当规格区间有重叠时，靠它决定用哪条。
提示：质量设计表不要一次建全，先覆盖占产量 80% 的牌号和规格，剩下的用「默认路线 + 人工确认」兜底，否则前期数据准备能把项目拖死。
2.3 合同行表：把销售承诺变成可计算的对象
合同行表的关键字段不是客户名，而是「可承诺量」和「替代规则」。可承诺量 = 当前库存 + 在制量 + 未来可排产量 - 已承诺量。替代规则管的是：客户要 1250mm，我只有 1200mm，能不能替代？替代要满足什么条件？这些规则不写进系统，销售就会一直打电话问生产，产销一体化就退化成电话一体化。
CREATE TABLE contract_line ( line_id VARCHAR(32) PRIMARY KEY, contract_no VARCHAR(32) NOT NULL, grade VARCHAR(20), thickness DECIMAL(6,3), width INT, qty DECIMAL(12,3), -- 订单量 吨 delivery_date DATE, -- 交期 allow_substitute TINYINT DEFAULT 0, -- 是否允许替代 sub_rule_id VARCHAR(32), -- 替代规则ID status VARCHAR(16) DEFAULT 'NEW' -- NEW/PLANNED/PRODUCING/DELIVERED );allow_substitute和sub_rule_id是产销协同的润滑剂。没有这两个字段，计划员只能按合同死排，稍微有点库存余量也用不上。status字段是后续排产和准发的状态机基础，状态流转必须由系统控制，不能让人随便改。
3. 用 APS 排产引擎把合同变成炉次和轧批
3.1 排产不是排序，是带约束的搜索
钢铁排产和离散制造最大的区别是「炉次」约束。一炉钢通常 200 到 300 吨，同一炉次里不同合同要能一起炼，成分要兼容，否则要么改判要么回炉。热轧那边还有轧辊周期、换辊次数、宽度跳跃限制。所以排产引擎不能只做交期排序，得做带约束的搜索。常见做法是用「合同分组 → 炉次归并 → 轧批排序 → 产线分配」四步走，每一步都有明确的约束条件。
我一般会先用一个分组算法把可同炉的合同聚在一起，判断依据是牌号相近、成分区间重叠、交期接近。分组之后，每组合同的总量去凑炉容，凑不满的用库存板坯补，凑超了的拆到下一炉。这一步的输出是「炉次计划」，每个炉次有明确的合同行列表和计划重量。
3.2 炉次归并的代码实现与参数
下面是一个简化的炉次归并逻辑，用 Python 写，核心是贪心加约束检查。实际项目里会用更复杂的启发式或求解器，但思路一致。
# 炉次归并：把合同行按可同炉规则聚成炉次 def group_heats(contract_lines, heat_capacity=250.0, tolerance=0.15): """ contract_lines: 合同行列表，每行含 grade, thickness, width, qty, delivery_date heat_capacity: 炉容 吨 tolerance: 允许超装比例，0.15 表示最多超 15% """ # 按交期和牌号排序，交期紧的优先 lines = sorted(contract_lines, key=lambda x: (x['delivery_date'], x['grade'])) heats = [] current = {'lines': [], 'total_qty': 0.0, 'grades': set()} for line in lines: # 约束1：牌号不能差太远，这里简化为同牌号或已存在牌号 if current['grades'] and line['grade'] not in current['grades']: # 尝试开新炉 if current['total_qty'] >= heat_capacity * (1 - tolerance): heats.append(current) current = {'lines': [], 'total_qty': 0.0, 'grades': set()} else: # 当前炉没凑够，但牌号不兼容，只能强行开新炉 heats.append(current) current = {'lines': [], 'total_qty': 0.0, 'grades': set()} current['lines'].append(line) current['total_qty'] += line['qty'] current['grades'].add(line['grade']) # 约束2：超过炉容上限就封炉 if current['total_qty'] >= heat_capacity * (1 + tolerance): heats.append(current) current = {'lines': [], 'total_qty': 0.0, 'grades': set()} if current['lines']: heats.append(current) return heats这段代码的逻辑说明：先按交期和牌号排序，保证紧急合同先排；然后逐行往当前炉次里加，加之前检查牌号兼容性和炉容上限。heat_capacity是炉容，tolerance是允许超装比例，这两个参数直接决定炉次数量和余材量。实际项目中，tolerance一般设 0.1 到 0.2，设太小会频繁开新炉，设太大炼钢厂会有意见。牌号兼容性这里简化成「同牌号」，真实场景要用成分区间重叠判断，比如碳含量差不超过 0.02%。
注意：炉次归并的结果一定要回写到合同行的
status和heat_id字段，否则后续轧批排产和准发环节找不到源头，又得靠人工对账。
3.3 轧批排序：宽度跳跃和轧辊周期的坑
热轧排产最容易被忽略的是宽度跳跃限制。轧机从宽料换到窄料容易，从窄料换到宽料容易出问题，所以排序时要尽量「宽到窄」。另外轧辊有轧制公里数上限，排到一定量必须换辊，换辊时间要算进交期。我一般会在轧批排序里加两个约束：宽度跳跃不超过 200mm，单轧程公里数不超过轧辊上限的 90%。这两个参数不设，排出来的计划看着漂亮，到现场就被操作工打回来。
# 轧批排序：宽度递减 + 轧辊公里数约束 def sequence_slabs(heats, width_jump_limit=200, roll_km_limit=80.0): """ heats: 炉次列表，每个炉次含 lines，每行有 width, qty 返回排序后的轧批列表 """ # 把炉次展开成板坯，按宽度降序 slabs = [] for h in heats: for line in h['lines']: slabs.append({ 'heat_id': h.get('heat_id'), 'width': line['width'], 'qty': line['qty'], 'grade': line['grade'] }) slabs.sort(key=lambda x: -x['width']) sequenced = [] current_km = 0.0 for slab in slabs: # 模拟轧制公里数，这里用 qty 粗略折算 km = slab['qty'] / 10.0 if current_km + km > roll_km_limit: # 触发换辊，实际项目里要插入换辊时间 current_km = 0.0 sequenced.append(slab) current_km += km return sequencedwidth_jump_limit控制宽度跳跃，roll_km_limit控制单轧程公里数。代码里用qty / 10.0粗略折算公里数，真实场景要用「卷重 / 单位长度重量」精确计算。换辊时间要作为独立事件插入排程，不能忽略，否则交期计算会偏乐观。
4. 合同匹配与准发：把产出对回订单
4.1 匹配规则：不是有货就能发
产出卷下线后，要匹配回合同行才能准发。匹配不是简单的「有货就发」，要满足牌号、规格、重量、交期四个条件。常见做法是建一张匹配规则表，定义「允差范围」和「优先级」。比如客户要 1250mm，实际产出 1245mm，允差 ±10mm 内可以匹配；重量上，合同 30 吨，实际产出 28 吨，允差 -5% 内可以准发，超出部分要么补产要么改判。
-- 合同匹配规则表 CREATE TABLE match_rule ( rule_id VARCHAR(32) PRIMARY KEY, grade VARCHAR(20), width_tol_min INT, -- 宽度允差下限 mm width_tol_max INT, -- 宽度允差上限 mm weight_tol_pct DECIMAL(5,2), -- 重量允差百分比 priority INT ); -- 插入一条规则：DC01，宽度允差 -10 到 +10，重量允差 -5% INSERT INTO match_rule VALUES ('MR_DC01_01', 'DC01', -10, 10, -5.00, 10);匹配时用产出卷的牌号、宽度、重量去match_rule里找规则，命中后判断是否在允差内。priority用于多条规则命中时选哪条。这个表看起来简单，但实际项目里经常被忽略，导致准发环节要么卡死要么乱发。
4.2 准发流程：从产出到发货的状态机
准发流程要定义清楚状态流转：产出下线 → 质量判定 → 匹配合同 → 生成准发单 → 发货 → 合同关闭。每个状态都要有系统校验，不能跳步。我见过最离谱的翻车是：产出卷还没做质量判定，就被匹配到合同并发货了，客户收到后发现性能不合格，整批退货。所以状态机里「质量判定合格」必须是「匹配合同」的前置条件。
# 准发状态机校验 def can_match(coil, contract_line): """ coil: 产出卷，含 grade, width, weight, qc_status contract_line: 合同行 返回 (bool, reason) """ if coil['qc_status'] != 'PASS': return False, '质量未判定合格' if coil['grade'] != contract_line['grade']: return False, '牌号不符' # 查匹配规则 rule = get_match_rule(contract_line['grade']) if not rule: return False, '无匹配规则' width_diff = coil['width'] - contract_line['width'] if width_diff < rule['width_tol_min'] or width_diff > rule['width_tol_max']: return False, '宽度超允差' weight_diff_pct = (coil['weight'] - contract_line['qty']) / contract_line['qty'] * 100 if weight_diff_pct < rule['weight_tol_pct']: return False, '重量低于允差下限' return True, 'OK'这段代码把匹配条件显式化，每个失败原因都能追溯。qc_status必须是PASS，这是硬约束。宽度和重量的允差判断用规则表驱动，不同牌号可以配不同允差。实际项目中，get_match_rule要加缓存，否则每次匹配都查库，产出高峰期数据库扛不住。
5. 产销一体化落地避坑：五条血泪经验
5.1 坑一：物料编码没统一就上系统
现象：系统上线后，销售看到的库存和生产看到的库存对不上，同一批货两个部门报出两个数字。原因：销售用「合同号」管库存，生产用「材料号」管库存，两套编码没有映射关系。解决：上线前先做编码映射表，把历史数据里的合同号、炉次号、卷号全部映射到统一材料号，映射不上的挂「待确认」状态，人工清理完再上线。这一步至少留两周，别信「上线后再补」的鬼话。
5.2 坑二：质量设计表覆盖不全，排产时频繁人工干预
现象：排产引擎跑出来的计划，计划员要手工改 30% 以上，改完还不如 Excel 排得快。原因：质量设计表只覆盖了主力牌号，新牌号或小批量牌号匹配不到工艺路线，引擎直接报错或走默认路线，结果不可用。解决：先统计近半年产量，按牌号+规格区间排序，覆盖前 80% 的产量；剩余 20% 用「默认路线 + 人工确认」流程兜底，并在系统里记录人工确认的原因，后续逐步补全。
5.3 坑三：炉次归并只看重量不看成分
现象：炉次计划排出来，炼钢厂说「这炉钢成分差太多，炼不了」。原因：归并算法只按牌号和重量分组，没检查成分区间。解决：在归并前加一步成分兼容性检查，用碳、硅、锰等关键元素的区间重叠判断，重叠度低于阈值的不能同炉。阈值一般设 70% 到 80%，具体看钢种。
5.4 坑四：准发匹配没有质量前置校验
现象：客户收到货后投诉性能不合格，追溯发现是未判定合格的卷被匹配发货了。原因：准发流程里「质量判定」和「合同匹配」是并行分支，没有强制先后顺序。解决：把质量判定设为合同匹配的前置状态，系统层面校验qc_status，不合格或未判定的卷不允许进入匹配环节。这个校验要写在代码里，不能只靠流程制度。
5.5 坑五：排产结果不回写，计划和生产两张皮
现象：排产引擎每天跑出计划，但生产现场按自己的节奏干，计划形同虚设。原因：排产结果没有回写到 MES 或生产工单，现场看不到最新计划。解决：排产引擎的输出必须通过接口回写到 MES，生成生产工单，工单状态变更再回传产销系统，形成闭环。接口可以先用文件交换，稳定后再换消息队列，别一上来就追求实时，先把闭环跑通。
6. 进阶技巧：用「可承诺量」做接单前的实时模拟
产销一体化做到后面，最有价值的不是排产多快，而是销售在接单时就能知道「这个单能不能接、什么时候交」。这需要把可承诺量（ATP）算准，并且支持实时模拟。我一般会做一个轻量的 ATP 服务，输入是牌号、规格、数量、期望交期，输出是「可承诺」「需调整交期」「不可承诺」三种结果，并给出建议交期。
实现上，ATP = 当前可用库存 + 在制量 + 未来可排产量 - 已承诺量。当前可用库存从库存系统取，在制量从 MES 取，未来可排产量用排产引擎的粗能力模型估算。关键是「已承诺量」要实时更新，每签一个合同就扣减，否则 ATP 会虚高。下面是一个简化的 ATP 计算示例。
# 可承诺量计算 def calc_atp(grade, width, qty, delivery_date): """ 返回 (atp_qty, suggested_date) """ # 1. 可用库存 stock = query_stock(grade, width) # 2. 在制量 wip = query_wip(grade, width) # 3. 未来可排产量：用粗能力模型，按周估算 capacity = query_capacity(grade, width, delivery_date) # 4. 已承诺量 committed = query_committed(grade, width, delivery_date) atp = stock + wip + capacity - committed if atp >= qty: return atp, delivery_date else: # 建议交期：往后顺延，直到 ATP 满足 suggested = find_next_available(grade, width, qty, delivery_date) return atp, suggestedquery_stock、query_wip、query_capacity、query_committed四个函数分别对接库存、MES、排产引擎和合同系统。find_next_available是顺延逻辑，按周粒度往后找，找到第一个 ATP 满足的周就返回。这个服务不用追求秒级，分钟级更新就够用，但数据准确性要求高，任何一个环节的数据延迟都会导致 ATP 失真。
提示：ATP 服务上线后，先让销售用一个月，但不要直接对接客户，等数据准确率稳定在 95% 以上再开放给客户自助查询。
我自己的习惯是，每做一个产销一体化项目，先花两周把物料编码和质量设计表理清楚，再动排产引擎。排产引擎可以换，编码和规则换起来伤筋动骨。另外，别指望一次上线就全自动，先做「系统排产 + 人工确认」，跑顺了再逐步减少人工干预。这套方案值不值得做，取决于你的合同复杂度——如果每月合同行超过 5000 条，手工排产已经明显吃力，那就值得投入；如果只有几百条，先把 Excel 模板优化好可能更划算。希望帮到你。
本文还有配套的精品资源，点击获取
