企业官网建设流程全解析

简介：基于VB6.0开发的生产计划排程系统1.1版，面向制造企业计划调度人员及VB程序设计学习者，解决产能分析、生产计划导入与任务控制等核心问题。压缩包共68个文件，约2.37MB，主要包含8个窗体源文件（frm）、8个Excel计划分析表（xls）、2个SQL数据库脚本、VB模块文件（bas）及图标图片素材，其中SQL脚本和数据库文件可用于快速还原系统运行环境。系统通过数据库集成实现计划数据的存储与检索，支持从Excel等外部表格导入订单和排产数据，并结合产能数据合理分配资源。已有534人下载学习，适合作为VB6.0数据库应用开发、生产排程业务逻辑分析的实战案例。借助完整源码、设计文档及Excel产能分析模板，可深入理解计划导入、产能评估、进度监控等模块的实现细节，掌握窗体界面与数据库联动的开发方法，便于二次扩展应用。

1. 生产计划排程1.1：一个压缩包背后的产能难题

拿到“生产计划排程1.1”这个标题，老车间计划员和IT运维的第一反应大概率不一样：前者关心的是“这个版本的排程逻辑能不能处理插单和瓶颈机台”，后者关心的是“这包里是源码、工具还是文档，能不能直接跑起来”。我拆过不少这类以版本号命名的排程资源包，1.1这个版本号说明作者至少迭代过一次，修复了初版的一些明显问题——通常这类工具的第一版会死在“算出结果但没法执行”上，1.1往往会补上产能约束和交期校验。这篇文章要解决的是三件事：这个方向值不值得投入、最小可行方案怎么落地、以及真正上线时会踩到哪些软钉子。适合正在做车间数字化改造计划、被Excel排产逼疯的工艺或计划工程师，也适合要评估外部排程工具的IT人员。

生产计划排程，说白了就是在“订单交期、机台产能、物料齐套、工序先后”四个变量互相打架的时候，给出一个能执行的任务时间表。难的不是算，是约束太多后算不动，或者算得快但结果没法用。1.1版本通常解决了“能跑”到“能看”这一步，但距离“能落地”还有一段路——这一版常见的定位是有限产能排程的雏形，即承认机台不是无限产能，按真实负荷去排。这决定了后面所有章节的方向：先立住产能模型，再谈数据、代码和坑。

2. 排程引擎的底层逻辑：先看懂产能模型再谈版本号

2.1 有限产能与无限产能：1.1版本默认站在哪一边

生产计划排程工具首先要回答的问题不是“排得快不快”，而是“排出来能不能干”。无限产能排程的逻辑很简单：订单来一个排一个，不考虑机台是不是已经被占满，只考虑工艺顺序和物料齐套。这种模式在订单少、机台多的车间里够用，但一旦机台利用率超过70%，无限产能排出来的计划就是废纸——因为实际执行时，前一个订单延误会像多米诺骨牌一样压垮后面所有订单。

版本号到1.1的工具，一般已经完成从无限产能到有限产能的跨越。有限产能的核心是“机台在任意时间段内只有一份产能”，排程时必须先把已占用的产能扣掉，再找空闲窗口。这里有个容易被新手忽略的概念叫“负荷率”，即在某个时间窗口内，某台机台被订单占用的时间百分比。排程引擎的每一步都要更新这个负荷率，否则第二次排产时会重复占用同一段时间。

我一般会先确认这个1.1版本的排程粒度——按工序排还是按订单排。按订单排是比较初级的做法，把整个订单的工艺时间当作一个整体块放到机台上，不考虑工序间的转移时间；按工序排则把一个订单拆成多道工序，每道工序单独找机台和时间窗口，这才是能用于实际生产的排程。1.1这个阶段大概率已经支持按工序排，因为做初版的人很快会发现按订单排出来的计划在生产线上根本走不通，而“工序级排程”是迈向可用性的第一道坎。

2.2 顺排与倒排：交期压力决定排程方向

排程的第二个分水岭是“从哪头开始排”。顺排是从当前时间点开始，尽早安排所有订单，好处是总能给出最近的可承诺交期，坏处是如果不刻意处理紧急订单，后插进来的急单会被排到很后面。倒排是从交期截止日往回推，先卡死最晚开始时间，再把工序往前压，好处是能直观看到哪些订单即使现在开工也已经来不及了——这类订单要么插队，要么跟销售谈交期。

实际落地的1.1版本我不会只给它一种模式，而是在参数表里加一个开关：用整数或者布尔值控制方向，同时允许“先顺排后局部倒排”的混合逻辑。比如常规订单顺排，交期小于某个阈值的订单切成倒排并标记为“插单”。这里会引入一个叫“松弛时间”的概念，即理论剩余时间减去剩余工序的最短加工时间。松弛时间为负的订单就是欠交期的订单，计划员最关心的正是这一列。

从纯工具研发角度看，顺排和倒排的代码差异集中在“时间游标”的移动方向上。顺排时游标每次取机台当前最后一道工序的结束时间作为起点；倒排时游标取交期减去当前工序的加工时间作为结束点，工序之间的间隔要倒着累加。这个逻辑不复杂，但很多人第一次写会忘记处理“倒排后开始时间为负”的情况——这说明该订单按当前约束已经无法按期完成，正确的做法是把它标记出来而不是强行从0点开始排。

2.3 约束优先级：交期、工时、批量、订单优先级的排序

排程引擎在一台机台上同时面对多个待排订单时，必须有一个确定的规则决定谁先被排进去。常见做法是定义一个四层优先级判定序列：第一层是订单的“截止时间”，越早越靠前；第二层是“订单优先级”，用于人工指定重点客户或高利润订单；第三层是“工序流转时间”，即当前工序加工时间越短的越靠前，这是为了减少机台换型时间；第四层是“订单进入系统的时间”，先到先得。

这套规则的顺序直接决定了计划的性格。如果把“订单优先级”放第一层，计划会很灵活但交期会乱；如果把“截止时间”放第一层，交期可控但重要客户的插单会被拖延。我习惯的做法是提供一个优先级权重配置表，让计划员在“交期偏差容忍天数”“优先级偏差容忍差值”两个参数之间做权衡，而不是在代码里写死。

数据上需要额外说明的是“批量拆分”对排程的影响。很多车间一张工单数量很大，但机台单次加工容量有限，所以排程时要考虑“分批“；而分批判断的维度包括机台容量上限、每批的准备时间和经济批量。1.1版本如果没做这个功能，会在多品种小批量的场景下翻车——因为每个批次都要消耗一次准备时间，排程结果和实际产能会有明显出入。

3. 把生产数据变成排程输入：基础配置表的字段设计与口径统一

3.1 物料表、工艺路线表、资源表的字段口径：少了哪个字段都会出玄学结果

排程工具上线前最消耗人力的环节不是功能调试，而是数据清洗。我见过一个中型机加工厂导入排程后结果离谱，最后排查发现是工艺路线表中缺少“工序准备时间”，默认值全为0，而实际每道工序换刀和对刀要花45分钟——排出来的产能比实际多出20%。这是非常经典的坑。

我把最小可用的数据模型拆成三张表。物料表注意字段包括：物料编码、默认提前期、库容单位、是否外协件。工艺路线表是排程的核心，必填字段更多：物料编码、工序号、工序名称、加工工时（单件）、准备工时（每批）、工装/模具编号、可选机台组；如果同一道工序可以在多台不同效率的机台上加工，还要加“机台效率系数”和“是否瓶颈工序”标识。资源表的核心字段包括：机台编码、所属车间、日历编号、日产能时长、允许加班时长、维护开始/结束时间。

有一个细节特别容易出错：工艺路线表里的“加工工时”是单件工时还是批量工时。有的企业在ERP里维护的是单件工时，排程引擎计算占用时间时必须乘以数量，再除以“一次合格率”；有的企业维护的是批量工时，直接加准备工时即可。这个口径不统一，导入后计划总时长偏差15%是常态，而且很难被一眼发现。

建议在导入工具里加一道“数据体检”逻辑：对上万条工艺路线记录逐条检查工时字段有没有超过该工序历史平均值的3倍或低于1/3的异常值，标黄提醒计划员确认，而不是直接采用。还有一个高频前处理动作是“压缩版本”，即同一物料存在多个版本的工艺路线时，必须先按生效日期过滤到唯一版本，再进入排程。

3.2 工作日历与班次：排程半天就乱了的元凶

工作日历是实现“计划可执行”的隐性前提，也是最容易在排程结果里产生“黑匣子”般奇怪误差的地方。默认把一周七天全部当作可用产能，排出来的计划会占用周六周日的时段，但车间实际不上班，计划员要手动把周日的时间挪到下周——如果排程引擎支持“班次时段”定义，这个问题在源头就能消掉。

我建议在资源表之外单独维护“日历表”，结构上分成两级：工厂日历（全局休息日、法定节假日、停电检修日）和机台日历（每台机台对应的班次模式，比如三班倒、两班倒、白班单班）。排程引擎计算机台可用时间窗口时，先按工厂日历过滤掉全院停工日，再按机台日历过滤掉非工作时段。这个“两级日历模型”是所有商用APS的标配，1.1版本如果没接日历概念，直接按自然日连续工时排，那它只适合实验室环境，不适合车间。

关于班次还有一个参数容易被忽略：跨天班次。很多工厂的晚班是从22:00到次日6:00，这在日历表里会跨自然日边界。老道的排程实现会把班次拆成若干“时段段”，永不允许一个工序的占用时间段跨越两个不同班次的分界，除非你在参数里明确允许“连续加工跨班次”。否则排程结果里会出现工序起始日期为8月1日23:30、结束时间为8月2日1:30，看起来OK，但一旦换班的交接时间没有从可用工时里扣掉，实际执行一定会延误，这个误差会累计并被车间当成“排程工具不靠谱”的论据。

4. 用最小代码跑通一个排程：从约束建模到甘特图输出

4.1 排程算法的骨架：用Python写一个有限产能排程的最小循环

排程引擎的算法选择取决于规模和交付周期。如果工序数量在几千条以内，优先级驱动的“滚动贪婪算法”就够了，没必要上一上来就搞遗传算法或约束规划，后者是锦上添花，不是雪中送炭。下面给出一个按“最早交期优先+选最早可用机台”策略的最小实现骨架，代码可以直接跑，后续接数据表和参数配置。

import pandas as pd from dataclasses import dataclass, field from typing import List, Optional @dataclass class Operation: order_id: str op_id: str machine_grp: str # 可选机台组，如 "CNC_A|CNC_B" proc_time: float # 单件加工工时 batch_size: int # 批量数量 setup_time: float = 0.0 # 准备工时 due_date: float = 1e9 # 该工序所属订单交期，用于排序 priority: int = 1 # 订单优先级，数字小优先 machine: Optional[str] = None # 排程后回填：选中的机台 start: float = 0.0 end: float = 0.0 @dataclass class Machine: name: str calendar: List[tuple] = field(default_factory=list) # 可用时段 [(start,end),...] loads: List[tuple] = field(default_factory=list) # 已占用时段同上 def first_available_window(self, need_duration: float, from_time: float) -> Optional[tuple]: # 返回 (start, end)，在日历中找最早能塞下 need_duration 的空窗 for cal_start, cal_end in self.calendar: if cal_end - from_time < need_duration: continue # 检查与已有负荷的重叠，见下方说明 candidate_start = max(from_time, cal_start) ok = True for load_start, load_end in self.loads: if not (candidate_start + need_duration <= load_start or candidate_start >= load_end): ok = False candidate_start = max(candidate_start, load_end) if candidate_start + need_duration > cal_end: ok = False break if ok: return (candidate_start, candidate_start + need_duration) return None def schedule(ops: List[Operation], machines: dict): ops_sorted = sorted(ops, key=lambda o: (o.due_date, o.priority, o.op_id)) for op in ops_sorted: best_machine = None best_start = float('inf') for m_name in op.machine_grp.split('|'): m = machines[m_name] win = m.first_available_window(op.proc_time * op.batch_size + op.setup_time, from_time=0) if win and win[0] < best_start: best_start = win[0] best_machine = (m, win) if best_machine: m, (start, end) = best_machine m.loads.append((start, end)) op.machine, op.start, op.end = m.name, start, end else: op.machine = None # 排不进去，标记，等待人工处理

这段代码的逻辑顺序比较直观：先把所有工序按“交期→优先级→工序号”排序，然后逐个工序遍历它可选的机台组，在每台机台上找最早的空闲窗口，选最早的那个机台占用。first_available_window里有个关键循环——如果候选位置和已有负荷冲突，就把候选起点挪到被占用时段的结束点继续尝试，这个“滑窗”处理是有限产能排程里最基本的技巧，也是代码里最容易写错的地方。

这里有几个需要说明的参数：proc_time在排程前必须乘上批量数量，得到单批次总加工时长；setup_time是切换产品时的一次性工时，建议放在机台占用时间之外单独校验——如果机台上一个订单和下一个订单使用同一工装，准备时间可以省掉，但这需要更复杂的上下文判断，初版可以先不处理。due_date是整个订单的交期，同一订单的多道工序会共享同一个交期，这样排出来的工序才可能整体向前赶或向后延。

以上就是方案的最小骨架。这个版本速度上是完全够用的——几千条工序、几十台机台，计算时间通常在秒级。要注意的是，真实场景中还得处理“订单内工序先后顺序”的约束，否则会出现后道工序先排、前道工序后排的尴尬结果。处理方法是在日期推进时，每道工序的可排最早时间取上一道工序的结束时间。

4.2 从排程结果到甘特图：数据格式与可视化套路

排程算法跑完之后，输出的是一张“工序时间表”：工序ID、订单号、机台名、开工时间、结束时间、数量和状态。直接把这张表丢给车间没用，计划员要的是“一眼看到每条产线被谁占着、哪里有空档”的甘特图。我一般用可视化工具直接把排程结果里每个工序渲染成彩色条块，机台名作为纵轴，时间作为横轴，每个工序按“状态”字段着色，比如绿色正常、黄色预警、红色逾期。

在实现甘特图之前，需要先从结果中聚合出几个关键指标，排程工具才算真正可用：机台利用率（总占用时长除以日历可用总时长）、订单准时交付率预测（排程完工时间在交期之内的订单占比）、瓶颈机台识别（利用率最高的前3台）。这三个指标如果排程结果没法直接算出来，那即便甘特图画得再好看，计划员也用不上。

还有一个非常实用的输出是“设备负荷对比柱状图”：把每台机台的可用时间、已排负荷、剩余负荷分三列显示，一眼扫过去就知道哪台机台快满了、哪台还有大量空间可以接急单。这个输出对“接不接新订单”的决策帮助最大，也是销售和计划开生产协调会时最常用的一张图。

5. 排程上线的避坑清单：计划排程包里最典型的翻车现场

5.1 工艺路线张冠李戴：排程结果在电脑里“完美”，在车间里完全走不通

现象：导入主数据后，排程引擎给出了一份看起来工期合理、资源均衡的计划，但车间工艺员一看就知道不对——某道工序指定的机台组里根本没有能加工该零件精度等级的机型。原因排查后发现：工艺路线表里有多个版本的工序定义，旧版本指定的是旧机台，新版本还没在系统里维护完整，数据筛选时没有按生效日期过滤。

解决方案：在排程数据导入环节增加“工艺路线版本过滤”的强制步骤，即每条物料编码只能保留生效日期最大的那一个版本；对旧版本数据不是简单删除，而是移入历史表存档。另外在工艺路线表里加一个“最后审核人”“最后审核时间”字段，凡是超过180天没审核的工艺路线，在数据体检报告里直接标红，不得参与排程。

5.2 工时口径混用：单件工时当成批次工时用，产能凭空放大

现象：有家做精密钣金的工厂第一次跑排程，系统算出来所有订单都能提前三天完成，车间主任不信，因为凭经验这些订单肯定要加班才能赶上交期。排查后发现工艺员在维护工艺路线时，有一部分填的是单件加工工时，另一部分填的是“每100件打包工时”，而排程导入脚本没有区分这两个字段的口径，直接统一当“工序总占用时间”使用。

解决方案：工时字段的命名不要用含义模糊的“加工工时”，明确分成“单件工时”“准备工时”“每批数量”三个字段。单件工时乘以数量加准备工时才是该工序的机台占用时间。导入后加一道校验：取历史订单的实际完工工时，与按工艺路线计算出来的预估工时做偏差对比，偏差超过30%的工艺路线列清单让工艺员逐条确认。说白了，排程工具的准确性上限由数据质量决定，算法再好也救不了烂数据。

5.3 忽略准备时间的换型惩罚：小批量多品种场景直接“假均衡”

现象：某工厂的产品种类多、每张订单数量小，排程结果看起来每台机台负荷很均衡，但实际执行时发现机台整天在换模具和调整参数，真正加工的时间不足一半。原因在于排程引擎把准备时间设成了固定值，没有考虑“相邻两个订单如果使用同一规格模具，准备时间可以大幅缩短”的依赖关系。

解决方案：对同机台上相邻工序做切换矩阵，即从A产品换到B产品的准备工时不一定等于从B换到A的准备工时，这在很多行业有“最优顺序”的讲究。初版可以先用一个简化版：统计每种产品组合的切换时间均值，填入切换矩阵表，排程引擎回填机台时检查正在犹豫的候选位置和上一道工序的产品组合，准备工时按切换矩阵取值而不是固定值。后来我在相关工业软件的资料里看到，工业界普遍把这个问题归为“换型时间依赖”，处理得好不好直接影响排程结果的可用度。

5.4 零头时间重复占用：批次报工、返工、质检时间没进模型

现象：计划排得刚好卡在每个班次的8小时整，但实际每天都会延后半小时收班。查到最后是每个批次完工后都有终检环节，每批抽检要15到30分钟，这个时间既没有算进工序占用时间，也没有算进机台负荷。

解决方案：把检验时间作为一道独立工序“质检”放在加工工序之后，机台资源改成“质检台”。如果质检员公用，要建立质检人员的人力资源日历，而不是默认无限产能。返工处理同理：在排程引擎里给每个订单预留约3%到5%的返工缓冲时间，切到“面向关键订单”的排程模式时，预留可以放宽到8%，用时间换可靠性。

5.5 插单与重排机制缺失：计划只要一改，全线工时全部重排

现象：排程上线后第一次遇到紧急插单，计划员在系统里手工改了某个机台的占用时段，结果保存时整个机台组的其他订单被自动重排，原本已发给班组的计划全乱了，车间现场直接拒绝接收新计划。

解决方案：在排程引擎的机制设计上，不提供“全局一键重排”的傻瓜按钮，而是提供“冻结时间窗”设置——设置未来12小时内的排程结果不可被重排算法变动，只能手工调整。并且重排策略要考虑“牵动最小”原则：默认只对该机台当天剩余时段和后续受影响订单做局部重排，其他机台不参与。这个局部重排的算法不用太复杂，先冻结已完工或已开工的工序，对受影响工序重跑一遍原来的优先级序列即可。

6. 从“排得出来”到“排得能执行”：两道验证与两个进阶习惯

排程工具上线后有没有价值，取决于能不能通过“复盘验证”这关。我会在试运行的前两周每天做同一件事：把排程计划导出，第二天早上对比车间实际报工完成情况，统计“计划开始时间与实际开始时间偏差超过30分钟的工序占比”。这个比例如果高于15%，说明排程约束里漏了重要因子（多半是准备时间或换型依赖），不要急着调算法，先回去查数据；如果低于5%，就可以进入正式并行阶段。

第二道验证是“交期承诺准确率”：排程引擎预估的完工日期与订单实际发货日期的偏差分布，在±1天内的订单占比是核心指标，达到80%以上才适合把排程结果作为给客户的承诺交期。如果一直达不到，我会建议缩小排程范围，先只排瓶颈工序段，而非全流程。

进阶方向上多做一件事最有价值：记录“已开工订单的实际工时”，回写工艺路线表，用于校准后续排程的工时估算。这个动作看起来不起眼，但它是排程结果从“贴近理论”走向“贴合现场”最重要的一步——因为所有排程算法都建立在工时的准确性之上，而现场的实际工时是不断变化的。另外一个习惯是每周导出一次“机台利用率与瓶颈漂移分析”，长期积累下来，你会清楚地看到产能瓶颈是否随着产品结构变化在移动，这比任何昂贵的商业算法都更接近排程的本质。

我自己刚接触排程时犯过的最大错误是沉迷于调优化算法，却忽视了基础数据的清洗和积累。后来想通了：排程工具对大部分制造企业而言，首先是一套“能看见全局的数据透镜”，其次才是“自动算计划的引擎”。先用最小的模型把计划看得清楚，比一上来就推智能优化更容易让计划员接受。希望这篇从产能模型到避坑清单的梳理，能帮你在“生产计划排程1.1”这个方向上少走几趟弯路。

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