新闻详情

新闻详情

首页 / 资讯中心 / 详情

ERP能力计划实战:RCCP与CRP如何避免排产翻车

发布时间:2026/9/29 7:19:56来源:尧图网络
ERP能力计划实战:RCCP与CRP如何避免排产翻车
1. 排产计划为什么总在车间翻车能力计划的定位很多做过生产计划的朋友都有过这种体验物料需求计划MRP跑出来漂漂亮亮采购单、生产订单全都按时下达结果到了车间要么机床前排长队要么某台关键设备闲得发慌。订单交期一拖再拖销售天天催车间天天喊缺人缺设备计划员夹在中间两头受气。问题的根子往往不在物料而在能力——你有没有在计划阶段就把设备和工时的账算清楚。在ERP体系里处理能力够不够这件事靠两个工具粗能力计划RCCPRough Cut Capacity Planning和能力需求计划CRPCapacity Requirements Planning。这两个东西名字很像很多人学了第六章之后还是分不清谁先谁后、谁粗谁细。我用一句话概括RCCP是给主生产计划MPS做体检只看关键资源快速判断这个计划靠不靠谱CRP是给MRP做精算把所有工作中心、每道工序的工时都摊开算看具体哪天哪台设备会堵。这套东西适合谁看如果你是制造业的计划员、生产调度、ERP实施顾问或者正在学ERP原理的学生这一章的内容会直接影响你排计划的准确率。我见过太多企业上了ERP却从来不用能力计划模块MRP跑完直接下达结果计划永远停留在纸上车间执行全靠老师傅拍脑袋。这不是软件的问题是方法论断了一截。能力计划的核心逻辑其实很朴素把你的生产任务换算成对设备和人力的需求再和实际能提供的产能去比。比出来的结果无非三种负荷大于能力干不完、负荷等于能力刚好、负荷小于能力吃不饱。计划员的工作就是让这个对比尽量均衡并且对偏差提前做出反应。RCCP和CRP的区别只在于算的精度和覆盖范围不同本质是同一件事在不同阶段的两种做法。下面我会先拆RCCP的三种算法和关键资源的识别方法再讲CRP怎么把工时算到工序级然后讲两者的数据衔接、负荷平衡手段最后把我这些年踩过的坑和土办法一并倒出来。2. 粗能力计划只算瓶颈资源的快速验证法2.1 为什么RCCP只盯关键工作中心粗能力计划挂在MPS下面作用是验证主生产计划是否可行。MPS的颗粒度是成品或关键部件按周或按天排列它不会细化到每道工序。如果这时候就去做全工序的产能核算工作量巨大且毫无必要——因为计划本身还可能调整。RCCP的设计哲学是只抓瓶颈。这里的关键工作中心不是随便指定的通常满足几个条件之一设备昂贵且数量少比如大型冲压机、热处理炉、操作人员技能稀缺比如高级焊工、经常成为生产瓶颈的工序、或者一旦停机整条线都得停的环节。我一般建议企业先看历史数据把过去半年里负荷率长期超过85%的工作中心列出来这些就是重点监控对象。数量控制在全部工作中心的10%到20%比较合理多了RCCP就失去快速的意义少了又抓不住真正的堵点。识别关键工作中心这件事很多企业偷懒直接让ERP系统按是否瓶颈的勾选框一刀切。我见过一家做精密件的工厂把二十多个工作中心全勾成关键资源结果RCCP跑出来和CRP一样慢完全没起到快速验证的作用。正确的做法是每个季度复盘一次随着订单结构变化瓶颈是会转移的。2.2 资源清单法的计算逻辑拆解RCCP最常用的方法是资源清单法也叫能力清单法核心思路是给每个产品定义它对各关键工作中心的单位资源需求再乘上MPS的计划量。举个具体例子。某产品AMPS计划第1周生产100台第2周生产150台。它经过两个关键工作中心WC01加工和WC02装配。经过工艺分析单位产品在WC01需要0.5标准小时在WC02需要0.3标准小时。那么周次MPS计划量WC01负荷小时WC02负荷小时第1周1005030第2周1507545再往下就是和能力对比。假设WC01有3台设备每天1班8小时每周5天那么额定能力是3×8×5120小时/周。但实际可用能力要打折扣考虑设备效率比如90%和利用率比如85%实际能力是120×0.9×0.8591.8小时/周。这样第1周负荷率是50/91.8≈54%第2周是75/91.8≈82%都还能扛住但第2周已经开始紧张。提示效率和利用率这两个系数千万别人云亦云地填。效率反映的是做一件活实际比标准工时多花多少利用率反映的是设备真正在干活的时间占比。两个都取0.9是理想值大部分离散制造企业利用率能到0.75就算不错了。2.3 分时段资源清单与负荷图的实际差别资源清单法是静态的它假设一个产品的所有关键资源需求都发生在同一个时段。但现实是产品在WC01加工完可能过两周才进WC02装配这两笔负荷不应该落在同一周。分时段资源清单法就是解决这个问题的它根据提前期把资源需求偏置Offset到相应的周次。继续上面的例子假设产品A在WC01的加工要比交货提前3周在WC02的装配提前1周。如果MPS第3周要交100台那么WC01的负荷应该落在第2周3-31按周序推算WC02的负荷落在第2周。这种偏置逻辑算起来麻烦但对负荷分布的真实性提升很大尤其是提前期长的产品。再进一步就是资源负荷图把各周的负荷画成柱状能力画成一条横线超出的部分一眼就能看出来。这个图在跟车间沟通时特别好用比一堆数字直观得多。我在实际项目里经常拿这张图去和生产经理对齐哪里要加班、哪里要外协看图说话扯皮少很多。RCCP的局限也要说清楚它用的是标准工时和粗略的提前期不考虑工序间的排队等待、批量转移、设备实际排产顺序。所以RCCP的结论只能定性——这个MPS大致可行或某几周肯定过不去不能拿来当精确排产依据。3. 能力需求计划把工时算到每台设备每一天3.1 CRP的输入数据链条RCCP过了之后MPS往下展开成MRPMRP生成自制件的生产订单CRP就是对这些生产订单做详细的产能核算。CRP的输入数据比RCCP复杂得多缺任何一环都算不准已下达和未下达的生产订单包括订单数量、开始日期、完工日期工艺路线每道工序对应的工作中心、准备时间、单件加工时间工作中心数据设备数量、班次、效率、利用率车间日历工作日、节假日、设备检修计划提前期数据排队时间、准备时间、加工时间、等待时间、传送时间我见过最常出问题的是工艺路线不准。很多企业上ERP时工艺路线是几年前手工整理的工时定额早就过时设备也换过但数据没更新。CRP跑出来的负荷和车间实际感受差一大截计划员慢慢就不信这个模块了。这个坑我在第5节还会细说。3.2 从MRP到工序负荷的推算过程CRP的计算是自下而上的。一个生产订单要经过多道工序每道工序在一个工作中心上完成。单道工序的负荷工时计算是工序负荷 准备时间 单件加工时间 × 订单数量注意准备时间和数量无关一次生产只发生一次。这就是为什么小批量多品种的生产模式对产能消耗特别大——准备时间摊不掉。假设某工序准备时间2小时单件加工0.1小时做100件负荷是21012小时做10件负荷是213小时。单件负荷从0.12小时涨到0.3小时翻了一倍多。这个账在排产时一定要算。然后是时间维度。每道工序要根据提前期倒排到具体日期。这里有个容易搞混的地方**倒排Backward Scheduling**从交货期往前推得到最晚开工时间**顺排Forward Scheduling**从最早可开工时间往后推得到最早完工时间。CRP一般用倒排来确定工序负荷的时间分布但如果订单已经延误或者产能不足就会显示为负荷集中在近期形成负荷峰值。把所有生产订单的工序负荷按工作中心和日期汇总就得到了工作中心的负荷分布。再和工作中心在该日期的可用能力对比得到负荷率。负荷率超过100%的时段就是冲突点需要调整。工作中心日期可用能力小时负荷小时负荷率WC013月10日1620125%WC013月11日161275%WC023月10日16850%WC023月11日1622138%这张表一出来问题就清楚了WC01在10号堵WC02在11号堵而它们各自另一天都有余量。如果工序之间有先后关系可以通过调整排产顺序把负荷平一平如果没有就只能靠加班、外协或者调整订单交期。3.3 能力与负荷的平衡手段CRP算出来的冲突处理手段就那么几种但选择顺序有讲究。我通常建议按这个优先级来调整排产顺序把非关键订单往后挪填到负荷低的时段。这是成本最低的手段但受交期约束。加班短期有效但长期加班会带来质量下降和人员流失别当常规手段用。外协适合本厂产能瓶颈但外部有富余的情况要考虑质量一致性和交期可控性。增加班次或临时工只在需求持续增长时用临时加人上手慢短期反而可能拖累效率。调整工艺或替代设备技术上可行的话把工序分流到能力富余的设备上。修改主计划或拒绝订单这是最后手段但有时候是最诚实的选择。这几种手段的顺序不是拍脑袋定的逻辑是先动计划再动资源最后动需求。因为动计划和资源的成本低、可逆动需求影响客户关系不可逆。4. RCCP与CRP的接力关系与数据口径4.1 两个计划的触发时机与数据依赖很多人搞不清RCCP和CRP的先后顺序和数据关系。正确的流程是MPS → RCCP → MRP → CRP。RCCP在MPS确认前跑确认MPS可行后再展开MRPMRP跑完再跑CRP。RCCP是MRP的前置校验CRP是MRP的后置校验。为什么不能跳过RCCP直接做CRP因为CRP要等MRP跑完才能算而MRP的计算量很大跑一次可能要几个小时。如果MPS本身就严重超出产能跑完MRP再被CRP打回来这几个小时就白费了。RCCP只需要几分钟就能筛掉明显不可行的MPS这是它的效率价值。反过来说RCCP过了不代表CRP一定过。RCCP只看关键工作中心非关键工作中心可能藏着瓶颈RCCP用的是标准工时CRP要考虑准备时间和实际批量RCCP的时间颗粒度粗CRP可以看到某一天某个班次的冲突。两者是互补的不能互相替代。4.2 常见的数据断层与口径不一致RCCP和CRP在数据口径上最容易脱节的地方有这么几个第一是标准工时的版本。RCCP用的可能是产品级的汇总工时CRP用的是工序级的工时。如果这两套数据来源不同算出来的总负荷可能对不上。我建议企业统一用工艺路线的数据来汇总产品级工时保证两个计划同源。第二是工作中心的编码。RCCP里叫关键资源CRP里叫工作中心如果ERP系统里这两个是两套编码映射关系没维护好数据就对不齐。有的系统干脆用同一个工作中心主文件只是打个关键标记这样最省事。第三是时间偏置的处理。RCCP用提前期偏置CRP用工序的开始完工日期如果提前期数据和工艺路线的工序间隔不一致负荷分布就会错位。第四是能力计算的口径。RCCP可能按周算能力CRP按天算如果周能力和日能力的汇总有出入对比就没有意义。这个问题的根源往往是车间日历没维护好比如某周有调休按天算和按周算就出现差异。注意每次上线新版本或者调整工艺路线后一定要用同一批订单同时跑一遍RCCP和CRP对比负荷结果的偏差。偏差超过15%就要查数据源别等到车间执行时才暴露。5. 能力负荷平衡中反复踩的坑和土办法5.1 工作中心划分过粗或过细工作中心怎么划分直接决定CRP算出来的结果有没有用。划得太粗比如把一台加工中心和一台铣床合成一个工作中心两者的能力混在一起算实际调度时根本没法按这个结果排。划得太细一个工作中心就一台设备数量一多CRP的数据维护量爆炸计划员根本忙不过来。我的经验是能互换使用的设备合为一个工作中心不能互换的分开。比如三台同型号的数控车床可以算一个工作中心一台普通车床和一台数控车床即使做同样的活也要分开因为效率和工艺能力不一样。另外瓶颈设备必须单独建工作中心这样RCCP才能精确监控。还有一个隐蔽的坑工作中心的产能单位。有的企业用台时有的用工时有的用标准小时。如果MRP的工时是标准小时工作中心能力是台时两者不能直接相减。这个单位统一的问题必须在系统配置阶段解决上线后再改历史数据全得重算。5.2 定额工时不准导致计划失真工艺路线的工时定额不准是CRP翻车的头号原因。工时定额的来源通常是工艺部门按经验或IE测量定的但实际生产中新员工操作比标准工时慢30%到50%材料硬度波动导致加工时间变化设备老化后效率下降刀具磨损后需要额外换刀时间这些因素让标准工时和实际工时之间有一个常态化的偏差。如果CRP用标准工时算负荷而车间按实际工时干活计划永远是乐观的。结果就是计划显示能干完实际天天加班。处理办法有两个。一是定期修正工时定额至少每年审一次重点产品每季度审一次。二是引入效率系数根据历史实际工时和标准工时的比值给每个工作中心设一个动态效率系数。ISO9000或者精益生产搞得好的企业一般有实际工时的统计用这些数据反推修正系数。我服务过的一家注塑厂他们的做法很土但有效每个月把车间的实际生产日报拿出来按工作中心算实际吨位小时和标准吨位小时的比值滚动更新效率系数。用了半年后CRP的负荷预测和实际加班时长的相关系数从0.4提到了0.85计划员终于敢信这个模块了。5.3 车间日历和班次维护的隐藏问题车间日历看着是小事但直接影响可用能力的计算。常见问题包括法定节假日没有及时更新、设备检修计划没有录入、临时停线没有维护、淡旺季班次调整没有同步。任何一个漏掉算出来的能力和实际就差一截。尤其是设备检修很多企业的检修计划是设备部门单独管的没进ERP。结果CRP按设备全周期算能力实际那几天设备在检修产能是零。这种偏差在连续生产型企业里特别致命因为设备停机往往是计划外的CRP很难动态反映。我的建议是把设备可用性的变化尽可能纳入系统做不到实时的至少做到按周更新。哪怕用一个简单的电子表格每周一早上把本周的设备可用性发给计划员也比完全不管强。系统层面能集成设备管理模块最好不能集成就靠流程补。6. 把能力计划用起来而不是算出来我见过很多企业的ERP里RCCP和CRP模块是开启的但几乎没人看结果。原因不是模块不好用而是算出来的负荷和车间的实际感受对不上久而久之就不信了。这不是技术问题是数据治理和流程习惯的问题。要让能力计划真正发挥作用我自己的经验是先从痛点小的场景切入。别一上来就全厂所有工作中心都上CRP先选两三个瓶颈工作中心把RCCP跑准用它去支持MPS的评审。MPS评审会上拿着RCCP的负荷图说话比空口说产能不够有说服力得多。等大家尝到甜头再逐步扩大范围。另一个关键是让车间参与数据维护。工时定额、工作中心效率、设备可用性这些数据车间最清楚。如果全靠工艺部门或IT部门维护数据永远滞后。可以设计一些简单的反馈机制比如每周班组会上确认本周的设备可用性和实际工时偏差计划员据此更新系统。这个流程听着麻烦但比起计划失准带来的加班和交期延误成本低得多。还有一个我个人很推荐的做法把CRP的负荷结果和实际产出做定期对比。每周末把每个工作中心的计划负荷和实际完成工时拉出来对照偏差大的查原因。是工时定额不准、订单没按时开工、还是设备故障连续跟踪三个月你会发现哪些工作中心的数据需要修正哪些环节的流程有问题。这个复盘习惯一旦养成能力计划的准确性会持续改善。最后说个现实的话能力计划不是万能的它解决的是计划层面看得清的问题执行层面的波动、插单、设备突发故障任何系统都无法完全预测。但有一个相对准确的能力视图至少能让计划员在做决策时有依据而不是全靠经验和直觉。从凭感觉到凭数据这一步跨过去生产计划的管理水平就上了一个台阶。这套方法我在不同行业的工厂里反复验证过RCCP和CRP不是摆设前提是你愿意在数据上花功夫愿意让计划和生产用同一套语言对话。工具是死的把它用活的是人。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

.NET 5.0 WinForms免注册调用大漠插件:SxS并行程序集实战 2026/9/29 9:18:22

.NET 5.0 WinForms免注册调用大漠插件:SxS并行程序集实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
DeepSeek-R1技术拆解:从API调用到本地部署的完整实践指南 2026/9/29 9:18:22

DeepSeek-R1技术拆解:从API调用到本地部署的完整实践指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
AI编程代理skills实战:从SKILL.md到Claude Code与Codex的安装管理 2026/9/29 9:18:22

AI编程代理skills实战:从SKILL.md到Claude Code与Codex的安装管理

说实话,我第一次认真研究 AI 编程代理里的skills,是因为一个特别没面子的场景:Claude Code 在同一个项目里连续三次把同样的 ESLint 配置改错,我气得差点把终端砸了。后来朋友甩了一个词过来:你没给它写 skill 吧&…

阅读更多 →
bup restore 完全指南:从备份集中精确提取文件与目录 2026/9/29 9:17:55

bup restore 完全指南:从备份集中精确提取文件与目录

灾备CLI存储 【免费下载链接】bup Very efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mail…

阅读更多 →
Apache Beam 测试基础设施:使用 Kustomize 在 Kubernetes 上安装 Strimzi Kafka Operator 2026/9/29 9:17:54

Apache Beam 测试基础设施:使用 Kustomize 在 Kubernetes 上安装 Strimzi Kafka Operator

【免费下载链接】beam Apache Beam is a unified programming model for Batch and Streaming data processing. 项目地址: https://gitcode.com/gh_mirrors/beam18/beam 点击查看 免费下载 导读 本文围绕 Apache Beam 仓库中 .test-infra/kafka/strimzi 目录下的…

阅读更多 →
Claude Code 配置管理模板:从零搭建高效开发环境 2026/9/29 9:17:40

Claude Code 配置管理模板:从零搭建高效开发环境

1. 为什么需要一套配置管理方案第一次接触 Claude Code 的人,大概率会经历这样一个过程:兴冲冲装好 CLI,敲了几个命令,发现确实能读代码、能改文件、能跑终端,然后开始琢磨怎么把它用得顺手一点。结果一搜资料&#xf…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉