1. 供应商考核这件事为什么值得用 WorkBuddy 重做一遍做过供应商管理的人都有一个共同感受考核数据不难收集难的是把数据变成能推动供应商改进的东西。我手上这份供应商考核数据来自季度评审覆盖 47 家供应商字段包括来料批次合格率、准时交付率、质量异常响应时长、配合度评分、价格竞争力评分、年度采购额等。原始数据躺在表格里看起来挺整齐但真要拿去做评审会材料问题就来了——谁该评 A、谁该评 C不能靠感觉评审报告要写清楚每家的问题和依据整改跟踪表要能落到责任人、时间节点和验证方式。这三件事如果全靠手工一个下午就没了还容易出错。WorkBuddy 在这类场景里的价值不是替你“做管理决策”而是把重复性的数据整理、分级计算、文档生成和跟踪表搭建这几步串起来。你可以把它理解成一个能读写文件、能执行脚本、能按模板产出文档的工作台。我这次的做法是把供应商考核数据交给 WorkBuddy让它完成 ABC 分级计算、生成评审报告初稿、再输出一张可维护的整改跟踪表。整个过程我实际跑了一遍下面把思路、参数、踩坑点全部摊开讲。这篇文章适合三类人看一是做供应链、采购、质量管理的从业者手头有考核数据但缺自动化手段二是刚接触 WorkBuddy、想知道它在真实业务里怎么落地的人三是需要定期出评审报告和整改跟踪表的团队负责人。哪怕你之前只用过 WorkBuddy 的基础功能跟着走一遍也能复现。2. 整体设计思路数据、分级、报告、跟踪四步走2.1 为什么选 ABC 分级而不是简单排序供应商分级最常用的就是 ABC 法。它的核心逻辑是按重要性把供应商分成三档A 类是核心供应商重点维护B 类是合格供应商正常管理C 类是观察或淘汰对象重点整改。很多人做分级时直接按综合得分从高到低排然后前 20% 是 A、中间 60% 是 B、后 20% 是 C。这个做法简单但有个隐患——它强制每档都有供应商哪怕所有供应商表现都很好也一定有人被划进 C。我这次采用的是“绝对阈值 排名校验”的混合方式。先给每个维度设定合格线和优秀线算出综合得分后按阈值初分再用排名做一次校验避免出现“整体优秀却硬切出 C”的尴尬。具体阈值后面会给。选这个方式的原因是供应商分级的结果会直接影响采购策略和整改资源分配不能为了分级而分级。2.2 WorkBuddy 在流程里承担什么角色整个流程我拆成四步数据清洗、分级计算、评审报告生成、整改跟踪表输出。WorkBuddy 主要承担后三步的自动化数据清洗这一步我保留了人工确认环节。原因很简单供应商名称可能有别名、采购额单位可能不统一、缺失值需要业务判断这些交给脚本容易出错先人工过一遍更稳。WorkBuddy 的工作台支持文件读写和脚本执行我把考核数据存成 CSV写了一个分级脚本再准备了一个报告模板和一个跟踪表模板。运行时它读取数据、执行计算、把结果填进模板最后输出两个文件一份评审报告、一份整改跟踪表。这个链路跑通之后下个季度只要替换数据文件几分钟就能出结果。2.3 方案选型背后的取舍有人会问为什么不用现成的 BI 工具做分级和看板我的考虑是BI 擅长展示不擅长生成带叙述的评审报告和可编辑的跟踪表。评审报告需要文字描述比如“该供应商本季度来料合格率下降 3.2 个百分点主要问题集中在某类物料”这种话 BI 不会替你写。跟踪表需要按问题逐条列出整改措施和验证方式也不是看板能直接给的。WorkBuddy 的优势在于它能同时处理数据和文档把“算”和“写”连起来。另一个取舍是模板的灵活度。我没有把报告模板写死成固定段落而是留了占位符比如{{供应商名称}}、{{综合得分}}、{{主要问题}}这样脚本填进去之后人工还能再润色。完全自动生成的报告读起来会有点生硬留一点人工调整空间实际用起来更舒服。3. 核心细节解析分级参数、报告结构和跟踪表字段3.1 ABC 分级的阈值怎么定分级不能拍脑袋我把六个维度先做了归一化处理再按权重算综合得分。权重是根据采购品类特点定的来料合格率 25%、准时交付率 25%、质量异常响应 20%、配合度 15%、价格竞争力 10%、采购额规模 5%。采购额权重给得低是因为它反映的是体量不是表现体量大的供应商不一定表现好但可以在同等表现下优先维护。综合得分算出来是 0 到 100 分。阈值我定的是A 类 ≥ 85 分B 类 70 到 85 分C 类 70 分。同时加了一条校验规则如果某供应商综合得分 ≥ 85 但排名在后 30%仍然降为 B如果综合得分 70 但排名在前 10%升为 B 并标注“重点观察”。这条规则是为了防止极端分布下的误判。等级综合得分区间管理策略评审频次A≥ 85 且排名前 70%优先合作可谈战略协议每季度B70–85 或高分但排名靠后正常管理跟踪改进每季度C 70 或低分且排名靠后限期整改必要时淘汰每月3.2 评审报告要写清楚哪几块评审报告不是数据罗列它要回答三个问题整体表现如何、谁好谁差、差在哪里。我设计的报告结构是概述、分级结果、A 类亮点、C 类问题清单、整改建议。概述部分用一段话总结本季度整体合格率和交付率分级结果用表格列出各等级供应商数量和占比A 类亮点挑两三家写具体表现C 类问题清单逐家列出主要失分项整改建议按问题类型给通用措施。这里有个细节C 类问题清单不能只写“合格率低”要写到具体维度。比如“来料批次合格率 88.5%低于合格线 95%主要异常集中在 3 月和 5 月的某类物料”。这种描述才能让供应商知道改什么。WorkBuddy 生成初稿时我会把每个维度的实际值和阈值都填进去人工再补一句原因分析。3.3 整改跟踪表的字段设计跟踪表是这次输出的重点因为它要能持续用。我设计的字段包括供应商名称、等级、问题描述、问题维度、整改措施、责任人、计划完成时间、验证方式、验证结果、状态。其中“问题描述”来自评审报告“整改措施”和“责任人”需要人工填“验证方式”我预设了几种复检报告、现场审核、数据跟踪。“状态”用下拉选项待整改、整改中、已完成、已验证。跟踪表用 CSV 输出方便导入表格软件继续编辑。WorkBuddy 负责把 C 类供应商的问题自动填进去A 类和 B 类如果有单项低于阈值也会生成一条跟踪记录。这样就不会漏掉“总分合格但某项拖后腿”的情况。提示跟踪表的“验证方式”一定要在生成时就填好默认值否则后续人工补填容易漏。我预设的规则是合格率问题用复检报告交付问题用数据跟踪响应问题用现场审核。4. 实操过程从数据文件到两份产出物4.1 数据准备与清洗原始数据是一张 Excel 表我先导出成 CSV字段名统一成英文避免脚本处理中文列名时出编码问题。清洗做了三件事供应商名称去空格、采购额统一成万元、缺失值用“待确认”标记而不是直接删。缺失值这块我踩过坑之前直接删掉导致某家供应商整行消失评审时被问起来很尴尬。现在改成标记脚本遇到“待确认”就跳过该维度计算并在报告里注明。数据文件我命名为supplier_review_q3.csv放在 WorkBuddy 工作台的data目录下。WorkBuddy 的缓存目录如果默认在系统盘建议改到空间大的盘我这次数据量不大没改但如果你要处理多年数据改一下更稳。改缓存目录的方法在设置里找“工作目录”或“缓存路径”选一个剩余空间充足的文件夹即可。4.2 分级脚本的关键逻辑脚本用 Python 写核心是读取 CSV、计算综合得分、应用阈值和校验规则、输出分级结果。下面是我实际用的代码骨架你可以直接参考import csv WEIGHTS { pass_rate: 0.25, on_time_rate: 0.25, response_score: 0.20, cooperation: 0.15, price_score: 0.10, amount_score: 0.05 } def normalize(value, min_v, max_v): if value 待确认: return None return (value - min_v) / (max_v - min_v) * 100 def grade(total, rank_pct): if total 85 and rank_pct 0.70: return A if total 70 and rank_pct 0.10: return C return B rows [] with open(data/supplier_review_q3.csv, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: rows.append(row) for row in rows: scores [] for key, weight in WEIGHTS.items(): val normalize(float(row[key]) if row[key] ! 待确认 else 待确认, 0, 100) if val is not None: scores.append(val * weight) row[total] round(sum(scores) / sum(WEIGHTS[k] for k in WEIGHTS if row[k] ! 待确认), 2) rows.sort(keylambda x: x[total], reverseTrue) for i, row in enumerate(rows): row[rank_pct] (i 1) / len(rows) row[grade] grade(row[total], row[rank_pct])这段代码里归一化用的是 0 到 100 的线性映射因为我的原始数据各维度量纲不同合格率是百分比响应时长是小时不归一化没法加权。权重和阈值都放在开头方便调整。排序后算排名百分比再套分级规则。4.3 报告生成与模板填充报告模板我用的是 Markdown因为 WorkBuddy 读写文本方便后续转 Word 或 PDF 也容易。模板里留了占位符脚本把分级结果和问题清单填进去。填充逻辑是先按等级分组A 类取综合得分最高的三家写亮点C 类全部列出问题维度。每个 C 类供应商的问题描述格式是“维度名称实际值阈值”比如“来料合格率88.5%阈值 95%”。生成后的报告我人工过了一遍主要改两处一是把“主要问题”补上原因比如“3 月某类物料批次异常”二是调整语气自动生成的句子偏机械改成更自然的表达。这一步花不了几分钟但报告质量提升明显。4.4 跟踪表输出与状态初始化跟踪表用 CSV 输出脚本遍历所有供应商凡是等级为 C 或任一维度低于阈值的生成一条记录。字段填充规则问题描述取该供应商最低的维度整改措施留空待填责任人留空计划完成时间默认设为报告生成日期后 30 天验证方式按维度预设状态初始为“待整改”。输出后我打开检查了一遍发现有两家 B 类供应商因为价格竞争力低于 60 分被生成了记录这是符合预期的因为价格竞争力虽然权重低但太低会影响采购成本。如果你不想让 B 类进入跟踪表可以在脚本里加条件只处理 C 类。注意跟踪表的计划完成时间不要设得太短30 天是常见整改周期复杂问题可能需要 60 天。我建议按问题维度区分合格率问题 30 天交付问题 45 天响应问题 15 天。5. 常见问题与排查技巧实录5.1 数据编码和列名问题最常见的问题是 CSV 编码。Windows 下 Excel 导出的 CSV 默认是 GBKPython 读取会报错。解决办法是导出时选 UTF-8或者在脚本里指定encodinggbk。我建议统一用 UTF-8避免后续麻烦。列名如果有中文或空格脚本里用DictReader时容易取不到值最好在导出前改成英文下划线命名。5.2 缺失值导致的计算偏差缺失值处理不好会直接影响分级。我之前的做法是缺失就按 0 分算结果一家供应商因为一个维度没填综合得分被拉低误判为 C。后来改成跳过缺失维度用剩余维度的加权平均并在报告里注明“某维度数据缺失得分仅供参考”。这个改动让分级更合理。5.3 分级结果与业务直觉不符怎么办脚本跑出来的分级如果和你的业务直觉差太多先别急着改阈值检查三件事权重是否合理、归一化范围是否合适、有没有异常值。我遇到过一家供应商合格率很高但交付率极低综合得分中等按规则是 B但业务上它其实该被重点整改。这种情况我在跟踪表里单独加了一条“交付专项整改”不改变等级但加强跟踪。5.4 报告生成后格式错乱Markdown 模板填充时如果供应商名称里有特殊字符比如竖线|会破坏表格结构。解决办法是在填充前做转义把|替换成\|。另外如果问题描述太长表格会很难看建议在脚本里截断到 50 字以内详细内容放到表格下方的列表里。问题现象可能原因排查方法解决方式脚本报编码错误CSV 是 GBK用记事本打开看编码导出时选 UTF-8某供应商得分为 0缺失值被当 0 算检查原始数据跳过缺失维度分级结果异常权重或阈值不合理对比业务直觉调整权重或加校验规则表格错乱特殊字符未转义检查填充内容替换竖线等字符跟踪表漏记录条件只判了 C 类检查脚本条件加上单项低于阈值判断5.5 实操心得留人工确认环节我最大的体会是全自动不等于最好。数据清洗和报告润色这两步人工花几分钟能避免很多尴尬。比如供应商名称别名脚本不认识“某某公司”和“某某有限公司”是同一家人工合并一下就行。报告里的原因分析脚本写不出来人工补一句报告就活了。WorkBuddy 把重复劳动干掉把判断留给人这个分工最舒服。6. 后续扩展让这套流程更省事这套流程跑通之后我做了两个小扩展。一是把分级脚本改成可配置的权重和阈值放在一个单独的配置文件里换品类时不用改代码。二是把跟踪表的状态更新做成半自动每周读一次跟踪表把“已完成”的记录筛出来提醒责任人去验证。这两个扩展都不复杂但让整个流程从“季度用一次”变成“持续在用”。如果你也想试建议先从一家供应商的数据开始跑通链路再上全量。WorkBuddy 的安装和基础操作不难关键是把自己的业务规则想清楚规则清楚了脚本就是水到渠成的事。我踩过的坑基本都在上面了你照着走能省不少时间。