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 并标注“重点观察”。这条规则是为了防止极端分布下的误判。

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", encoding="utf-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(key=lambda x: x["total"], reverse=True) 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 默认是 GBK，Python 读取会报错。解决办法是导出时选 UTF-8，或者在脚本里指定encoding="gbk"。我建议统一用 UTF-8，避免后续麻烦。列名如果有中文或空格，脚本里用DictReader时容易取不到值，最好在导出前改成英文下划线命名。

5.2 缺失值导致的计算偏差

缺失值处理不好会直接影响分级。我之前的做法是缺失就按 0 分算，结果一家供应商因为一个维度没填，综合得分被拉低，误判为 C。后来改成跳过缺失维度，用剩余维度的加权平均，并在报告里注明“某维度数据缺失，得分仅供参考”。这个改动让分级更合理。

5.3 分级结果与业务直觉不符怎么办

脚本跑出来的分级如果和你的业务直觉差太多，先别急着改阈值，检查三件事：权重是否合理、归一化范围是否合适、有没有异常值。我遇到过一家供应商合格率很高但交付率极低，综合得分中等，按规则是 B，但业务上它其实该被重点整改。这种情况我在跟踪表里单独加了一条“交付专项整改”，不改变等级但加强跟踪。

5.4 报告生成后格式错乱

Markdown 模板填充时，如果供应商名称里有特殊字符，比如竖线|，会破坏表格结构。解决办法是在填充前做转义，把|替换成\|。另外，如果问题描述太长，表格会很难看，建议在脚本里截断到 50 字以内，详细内容放到表格下方的列表里。

5.5 实操心得：留人工确认环节

我最大的体会是，全自动不等于最好。数据清洗和报告润色这两步，人工花几分钟，能避免很多尴尬。比如供应商名称别名，脚本不认识“某某公司”和“某某有限公司”是同一家，人工合并一下就行。报告里的原因分析，脚本写不出来，人工补一句，报告就活了。WorkBuddy 把重复劳动干掉，把判断留给人，这个分工最舒服。

6. 后续扩展：让这套流程更省事

这套流程跑通之后，我做了两个小扩展。一是把分级脚本改成可配置的，权重和阈值放在一个单独的配置文件里，换品类时不用改代码。二是把跟踪表的状态更新做成半自动，每周读一次跟踪表，把“已完成”的记录筛出来，提醒责任人去验证。这两个扩展都不复杂，但让整个流程从“季度用一次”变成“持续在用”。

如果你也想试，建议先从一家供应商的数据开始，跑通链路再上全量。WorkBuddy 的安装和基础操作不难，关键是把自己的业务规则想清楚，规则清楚了，脚本就是水到渠成的事。我踩过的坑基本都在上面了，你照着走能省不少时间。