2024 年下半年，我参加过一个年 GMV 约 4 亿的服饰品牌的数据复盘会。会议开到第 40 分钟，业务负责人说了一句让我记到现在的话：“这套系统上线 8 个月，报表从 6 张加到 47 张，我还是不知道下个月该砍哪些款。”会后我翻了他的看板：访客数、加购率、转化率、动销率、库存周转、毛利额，全都齐了，但没有任何一个页面在回答“哪几个 SKU 应该被淘汰、哪些价格带应该补货”。这不是数据能力问题，是起点问题，他搭系统时，第一步走的是“接数据”，而组合优化真正需要的起点，是先定义“要动的是结构还是效率”。

这篇文章我想把这件事讲清楚：商品分析系统搭建时，组合优化到底该从哪一步开始，为什么多数团队第一步就走偏了，以及不同体量的团队应该怎么选自己的第一刀。

一、先说结论：组合优化的起点，是“你想动结构还是动效率”

我做过 6 个从 0 到 1 的商品分析项目，也接手过 3 个“已经建好但没人用”的烂尾系统。复盘下来，失败的项目几乎都在同一个地方出错：把“数据接入”当成了起点。而成功的项目，第一步都是先回答一个业务问题，这次优化，我到底要动的是商品结构，还是运营效率？

1. 结论一：起点不是数据，是决策问题

“组合优化”这四个字听起来像一个技术命题，实际上它是一个决策命题。你要优化的不是“数据”，而是“接下来三个月哪些商品该留、该加、该砍、该换位置”。数据只是支撑这个决策的原材料。

所以真正的第一步，是明确你这次要做的决策是什么。是砍掉冗余 SKU？是补齐价格带空档？是把资源从低效品类挪到高效品类？还是把新品孵化周期缩短？没有决策目标的系统，最后一定会退化成报表仓库。

我见过最典型的反例，是一个团队花了 5 个月接入 11 个数据源，从 ERP、WMS、CRM 一直到客服工单，做了一个统一数据层。交付那天所有人都很兴奋，结果第二周使用率跌到个位数。原因很简单：没人能回答“我看完这个页面之后，明天要做什么”。

2. 结论二：先分清“组合”的三层含义，再谈数据

市面上大量文章把“组合优化”当成一个整体概念讲，这是最容易误导人的地方。在商品语境里，“组合”至少有三层互相独立的含义：品类组合、价格带组合、生命周期组合。它们的数据口径、分析方法和决策动作完全不同。

如果你没有先分清自己要做的是哪一层，就会出现“什么都想看，什么都看不深”的典型症状。后面第二章我会给出完整的判断矩阵，这里先记住一句话：三层组合的起点各不相同，混在一起做等于都不做。

3. 结论三：第一版系统只解决一个问题

我给所有客户的建议都是同一句：第一版系统只解决一个决策问题，跑通一次完整闭环，再扩。能跑通一次的闭环，价值远大于能看一百个指标的看板。

下面的图对比了三种常见起点的启动成本与结果，你可以先看一眼差异有多大。

二、把“组合”拆开：它至少有三层含义

“组合优化”被讲得最含糊的地方，就是很少有人先定义组合的层级。我在实际项目里会强制把组合拆成三层，每一层单独定义目标、口径和动作，不混着做。三层拆清之后，你会发现“从哪开始”这个问题一下子变得可回答了。

1. 品类组合：决定钱花在哪条线上

品类组合回答的是“我的资源应该分配到哪几个品类”。它的核心指标不是销售额，而是品类毛利贡献与品类资金占用的比值。销售额高但库存占用大的品类，往往是隐形的利润黑洞。

判断品类组合是否健康，我通常只看两个数：该品类的毛利率，以及该品类的库存周转天数。两个数放在同一张散点图上，右上角是高毛利快周转（重点加码），左下角是低毛利慢周转（优先收缩）。

品类组合的优化动作很重，通常伴随采购结构、供应链账期、视觉资源的整体调整，所以它适合作为季度级决策，不适合每周做。

2. 价格带组合：决定客单与转化的平衡点

价格带组合回答的是“我的货架在同一品类里覆盖了哪些价格区间，哪里有空档，哪里过度拥挤”。这一层最容易被忽略，但它的见效速度往往最快。

我服务过一家家居类目客户，他们在 99-129 元区间堆了 40 多个 SKU，而 199-259 元区间只有 3 个。数据一拉出来就发现问题：99-129 区间内部竞争极其激烈，广告费互相挤压，而 199-259 区间的访客转化率是全店最高的 4.8%。后来他们把 6 个低效 SKU 下架，把资源倾斜到 199-259 区间，两个月后整体客单价提升了 17%。

价格带组合的优化动作轻、可逆、见效快，非常适合作为组合优化的第一个切口。

3. 生命周期组合：决定什么时候推、什么时候清

生命周期组合回答的是“我的商品在导入期、成长期、成熟期、衰退期各占多少比例”。健康的结构应该是一个持续流动的梯形，而不是全部堆积在成熟期。

这一层的难点在于分级标准。我的经验是不要用复杂模型，用三个可量化条件就够了：上架天数、近期销量趋势、动销率。三个条件组合出四档，比任何聚类算法都更容易被业务接受。

生命周期组合的优化节奏最快，通常按周复盘，因为清库存和新品孵化的窗口期都很短。

4. 三层组合的判断矩阵

把三层含义摊开之后，选择起点就变成了一道比对题。下面这张表是我在项目中实际使用的判断矩阵，可以直接对照自己的情况。

三、三种最常见的错误开局

我见过太多团队在“从哪开始”上栽跟头，而且错误的方式高度雷同。下面三种开局我都亲历过，有的还是我自己犯的。写出来是为了让你少走几个月的弯路。

1. 从数据源开始：接了 11 个渠道，一个结论都没出

这是最普遍的错误。团队的第一步动作是列数据源清单：ERP、WMS、POS、电商后台、广告平台、客服系统、第三方数据服务……然后开始排期对接。

问题在于，数据源接入是一个没有明确终点的任务。每接一个源，就会冒出口径不一致的问题；每对齐一个口径，又会发现历史数据缺失。数据源的边界是业务问题界定的，不是技术能力界定的。

我做过一个统计：在 6 个从数据接入起步的项目里，平均有 6.2 周时间花在了口径对齐上，而这 6.2 周里业务侧没有产生任何一个决策。这个投入产出比，任何老板看了都会皱眉。

2. 从工具选型开始：选型 3 个月，业务已经换了方向

第二种错误是被工具牵着走。团队花三个月做选型对比，评估 7 家供应商，做 POC、做安全审查、做价格谈判。等工具上线，业务的重点已经从“拉新”转到了“利润”，当初设计的分析主题全部作废。

我的判断很直接：在还没有跑通一次完整决策闭环之前，任何选型都是猜测。你不知道自己需要什么，就无法判断工具好不好。

正确的顺序是反过来的，先用现有工具跑通一次闭环，明确自己缺什么能力，再去选工具。这时你手里有真实的使用场景，选型效率会提高数倍。

3. 从部门分工开始：KPI 不一致，系统越建越像报表仓库

第三种错误最隐蔽。项目启动会上，老板拍板“数据部门负责搭建，业务部门负责使用”。听起来很合理，实际上埋了一个雷：两边 KPI 不一致。

数据部门的考核是“系统稳定性、数据准确性、需求交付及时率”，业务部门的考核是“销售额、毛利率、库存周转”。结果就是数据部门拼命把系统做稳做全，业务部门想要的却是能直接指导明天动作的结论。两个 KPI 之间没有交集，系统就必然变成一个校验合格、但没人使用的报表仓库。

四、三个可选起点，以及它们各自的适用边界

错误开局讲完，接下来是我认为真正可用的三个起点。它们没有绝对优劣，只有适用边界。选错边界，再好的方法也会失效。

1. 起点 A：从利润结构诊断开始

这个起点适合业务已经成熟、SKU 数量稳定、成本数据相对完整的团队。核心动作是把“销售额”拆成“销售额 × 毛利率 − 库存占用成本”，重新算一遍每个品类、每个价格带、每个主力款对利润的真实贡献。

我通常的做法是先跑一张“利润贡献倒序表”，把 SKU 按利润贡献从高到低排序，然后看累计 80% 利润需要多少个 SKU 覆盖。如果答案是 15% 的 SKU 贡献了 80% 的利润，那剩下的 85% 就是优化空间。

适用信号：销售额没降但毛利持续下滑；库存周转天数逐年变长；新品成功率低于 20%。

不适用信号：成本数据不完整，或者库存成本只有总数没有分摊到 SKU。这种情况下做出来的利润诊断会严重失真。

2. 起点 B：从商品分层开始

这个起点适合 SKU 数量多、管理颗粒度粗的团队。核心动作是先建立一套简单可执行的分层规则，把几百上千个 SKU 分成几档，然后对每一档给出明确的处理动作。

我的分层规则通常是四档：主力款（销量稳定、毛利达标）、潜力款（销量上升、毛利达标）、问题款（销量下滑或毛利不达标）、淘汰款（长期不动销）。分档标准必须量化，避免“感觉还可以”这种模糊判断。

适用信号：SKU 超过 300 个，运营对多数商品的印象已经模糊；动销率持续低于 60%。

不适用信号：SKU 不足 100 个。这种情况下分层带来的收益小于分层本身的维护成本。

3. 起点 C：从最小指标闭环开始

这个起点适合完全没有数据基础的团队，或者此前建过系统但失败了的团队。核心动作是选一个最小的决策场景，用最简陋的工具（很多时候就是一张表格）跑通一次“发现问题，做出决策，验证结果”的完整循环。

所谓最小闭环，我的定义是：一个决策对象、一个判断指标、一个验证周期。比如“哪些 SKU 应该被下架”这个决策对象，“过去 60 天动销率为 0”这个判断指标，“4 周后看库存周转是否改善”这个验证周期。

适用信号：团队没有任何分析工具使用习惯；此前项目失败过；预算有限。

不适用信号：团队已有成熟分析能力。这种情况下再跑最小闭环属于浪费时间。

4. 怎么选：三问定位法

如果你不确定自己属于哪一种，问自己三个问题，按顺序回答，答案会自然收敛。

1. 我的成本数据能不能分摊到单品？能，走起点 A；不能，跳到第二问。
2. 我的 SKU 数量是否超过 300 个？是，走起点 B；否，跳到第三问。
3. 我的团队有没有稳定的分析工具使用习惯？有，回到起点 A 补成本数据；没有，走起点 C。

五、系统搭建的启动顺序：四步走

确定起点只是第一步，真正的难点在于顺序。下面这四步是我在多个项目中反复验证过的顺序，每一步都有明确的完成标志。顺序错了，后面每一步的成本都会翻倍。

1. 第一步：定义“优化什么”，而不是“采集什么”

这一步的产出不是数据清单，而是一句话决策描述。格式是：“我们要在【时间范围】内，对【决策对象】做出【决策动作】，判断依据是【一个指标】。”

举个例子：“我们要在 Q3 内，对现有 620 个 SKU 做出下架或保留的决策，判断依据是过去 60 天动销率与毛利率的组合。”

这句话写不出来，说明你还不知道自己要做什么，后面所有工作都会失去焦点。写不出决策句子的项目，不建议启动。

2. 第二步：选一个能被验证的最小指标

注意“能被验证”这四个字。很多团队选的指标无法验证，比如“品牌力”“用户心智”这类无法量化、也无法在短期内观察变化的指标。

最小指标应该同时满足三个条件：可以在现有数据中算出来、可以在 4 周内观察到变化、变化可以与决策动作建立因果关系。

我的经验是，第一版指标不要超过 3 个。超过 3 个，业务就会开始纠结“到底看哪个”，决策速度反而下降。

3. 第三步：用现有数据跑通一次闭环

这一步的关键词是“现有数据”。不要等数据仓库建好，不要等 ETL 调度上线，用导出的表格、用 SQL 直连、用手工透视，怎么快怎么来。

我通常会让团队先手工跑一遍，把整个决策流程写进一份文档，包括：数据从哪里来、怎么算、算出结论后谁做决策、决策后怎么记录结果、多久验证一次。跑通一遍之后，你才知道系统真正需要自动化的是哪一段。

下面是一段最小闭环的口径定义示例，我用 SQL 伪代码表示，重点是让业务和数据对口径达成一致。

-- 最小闭环示例：识别过去 60 天低动销 SKU
-- 决策对象：SKU 级

-- 判断指标：60 天动销率 + 毛利率

-- 验证周期：4 周后回看库存周转天数变化

WITH sku_sales AS (

SELECT

sku_id,

SUM(sales_qty)              AS qty_60d,

SUM(sales_amount)           AS gmv_60d,

SUM(gross_profit) / NULLIF(SUM(sales_amount), 0) AS gross_margin_60d,

DATEDIFF('day', MAX(sale_date), CURRENT_DATE)    AS days_since_last_sale

FROM dwd_order_item

WHERE sale_date >= DATEADD('day', -60, CURRENT_DATE)

AND order_status = 'paid'

GROUP BY sku_id

),

sku_stock AS (

SELECT

sku_id,

SUM(stock_qty)              AS stock_qty_now,

SUM(stock_cost)             AS stock_cost_now

FROM dwd_inventory_snapshot

WHERE snapshot_date = CURRENT_DATE

GROUP BY sku_id

)

SELECT

s.sku_id,

COALESCE(s.qty_60d, 0)                       AS qty_60d,

COALESCE(s.gross_margin_60d, 0)              AS gross_margin_60d,

COALESCE(s.days_since_last_sale, 999)        AS days_since_last_sale,

COALESCE(t.stock_qty_now, 0)                 AS stock_qty_now,

COALESCE(t.stock_cost_now, 0)                AS stock_cost_now,

CASE

WHEN COALESCE(s.qty_60d, 0) = 0

AND COALESCE(t.stock_qty_now, 0) > 0

THEN 'D_淘汰候选'      -- 60 天无销售且有库存

WHEN COALESCE(s.gross_margin_60d, 0) < 0.15

AND COALESCE(t.stock_qty_now, 0) > 30

THEN 'C_问题款'        -- 毛利不达标且库存偏高

WHEN COALESCE(s.days_since_last_sale, 999) <= 14

THEN 'A_主力款'        -- 近期持续动销

ELSE 'B_观察款'

END                                          AS sku_layer

FROM sku_sales s

FULL OUTER JOIN sku_stock t ON s.sku_id = t.sku_id

ORDER BY stock_cost_now DESC;

这段代码的价值不在于它多复杂，而在于它把“分层规则”写成了可复现的逻辑。业务看到分层结果，如果某个 SKU 被分到了淘汰候选但业务认为不该淘汰，双方就可以对着这段逻辑去修改阈值，而不是各说各话。

4. 第四步：再谈工具与自动化

前三步跑完之后，你手里会有一份非常具体的需求文档：哪些数据要每天更新、哪些逻辑要固化成任务、哪些页面是决策时真正会看的。这时候再选工具，你会发现选型时间从三个月压缩到两周。

更重要的是，此时你已经知道哪些环节不需要自动化。我见过太多团队把大量精力花在自动化一些每周只看一次的报表上，而真正需要每天刷新的分层结果却靠手工。

六、一个可观察的样本：数跨境的组合优化落地路径

上面讲的都是方法。方法要落地，需要一个能承载流程的工具环境。我近两年在跨境电商和国内电商项目里，用得比较多的一个样本是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。用它做样本不是因为它是唯一选择，而是它的产品结构比较典型地体现了“从指标到动作”的路径。

1. 为什么拿它当样本

跨境电商的商品分析有个特殊难点：SKU 跨多个平台和站点，同一个商品在不同国家的表现差异巨大，而库存和物流成本又要统一核算。这种场景下，如果还按“先把所有数据接进来再说”的顺序做，项目几乎必败。

数跨境的产品结构里，数据接入、指标定义、多维分析、看板呈现是一条相对连续的链路，而且它的多维分析能力允许业务自己拖拽出组合维度，不需要每次都提需求给数据团队。这一点对我讲的“第三步跑通闭环”很关键，闭环要跑得快，就不能每次都排队等开发。

2. 三次迭代：从“看全”到“看准”到“看动”

我参与过一个跨境家居类目的项目，用数跨境做载体，整个过程大致经历了三次迭代，每次迭代的目标都不一样。

第一次迭代的目标是“看全”。把所有平台的订单、库存、广告数据接入，建立一个统一的商品视图。这一阶段的产出是一张全量 SKU 明细，包含销量、GMV、毛利率、库存、动销天数。这个阶段大概用了 3 周，比从零建数据仓库快很多，因为大部分平台数据有现成的连接方式。

第二次迭代的目标是“看准”。在明细基础上做分层，把 SKU 按动销率和毛利率分成四档。这次迭代的关键动作是反复校准阈值。第一次分层结果出来后，业务发现 30% 的 SKU 被划入淘汰候选，明显偏高，于是把动销率阈值从 60 天放宽到 90 天，比例降到 18%，业务才认这个结果。

第三次迭代的目标是“看动”。给每一层 SKU 绑定具体动作：A 类主力款加广告预算、B 类观察款控制补货、C 类问题款做促销测试、D 类淘汰候选走清仓流程。这一步是整个项目里最容易被忽略的，但也是决定系统有没有价值的一步。没有动作绑定的分层，只是一次性的分析报告，不是系统。

3. 两个值得抄的动作

第一个动作是“分层结果每周固定时间刷新，并在同一时间开 30 分钟的对齐会”。这个动作看起来很小，但它把分析结果嵌进了业务的固定节奏里。没有固定节奏，再好的看板也会慢慢被遗忘。

第二个动作是“每一次决策都留痕”。他们在系统里记录了每条决策的内容、决策人、决策时间和预期效果，4 周后回看实际结果。这个动作让团队在半年内积累了上百条决策记录，后来这些记录成了优化阈值的最好依据，比任何方法论都管用。

我要提醒一点：上面这些数据来自我参与项目的观察和脱敏整理，具体数值会因类目和平台差异而不同，请当成参考区间而不是标准答案。

七、不同情况下的行动建议

方法讲完之后，我更想给的是可以直接执行的建议。不同体量的团队，第一步动作差别很大，下面按三种典型情况分开说。

1. 0 到 1 的团队：先做一张“减法表”

如果你没有任何数据基础，不要先想系统，先做一张减法表。具体做法是：导出过去 90 天的 SKU 销售明细和当前库存明细，用表格工具做一次最粗糙的分层，找出明显该砍的商品。

这张表不需要精确，因为它不是为了做决策，而是为了让团队体验一次“数据驱动决策”的完整过程。选 5 个 SKU，做出下架或保留的决定，记录理由，4 周后回看结果。

关键点在于动作要小、周期要短、结果要回看。一次成功的闭环体验，比十份方法论文档更能推动团队往前走。很多团队失败不是因为能力不够，而是因为第一次尝试周期太长，还没看到结果就失去了耐心。

2. SKU 500 以上的成熟团队：先做分层，再做指标

SKU 数量一大，最大的成本是注意力。这时候最该做的不是加指标，而是减对象，先把 SKU 分成几档，让业务每次只看一档。

我的建议是第一次分层只用两个维度：动销情况和毛利水平。不要一开始就引入季节性、渠道差异、退货率等更多维度，那会让规则复杂到没人愿意用。等第一版分层稳定运行两个月，再考虑加维度。

分层跑通之后，再针对每一档设计专属指标。主力款看增长率和缺货率，问题款看毛利改善幅度，淘汰款看清仓进度。这样每个指标都有明确的决策归属，不会出现“看完不知道干什么”的情况。

3. 已有 BI 但决策没变的团队：先做归因链

这是最尴尬的一种情况：系统有了，数据准了，就是没人用。这时候不要再加功能，先做一件事，把现有看板上的每一个指标，追问三层“所以呢”。

比如看板上显示“动销率 58%”，追问第一层：所以呢？答：说明有 42% 的 SKU 没动销。追问第二层：所以呢？答：这些 SKU 占用了库存资金。追问第三层：所以呢？答：应该在下个月清掉其中毛利最低的一批。

如果追问三层之后得到的还是一句“需要继续观察”，说明这个指标不应该出现在看板上。归因链的终点必须是动作，否则这个指标就是装饰。

八、必须做的取舍：四个绕不开的选择

讲完建议，还要讲取舍。组合优化的每一个选择背后都有代价，不把代价说清楚，执行时一定会翻车。

1. 广度 vs 深度

广度是指覆盖多少品类、多少渠道、多少指标；深度是指对某一个对象的分析细致到什么程度。资源有限时，二者只能选一个。

我的判断是：在第一轮优化中，深度永远优先于广度。原因是组合优化需要靠一次成功的案例来建立内部信任，而一个做得深的品类比五个浅尝辄止的品类更能说明问题。

什么时候该转向广度？当你已经有两个品类跑出了可复制的分析框架，而且这个框架被证明可以迁移到其他品类时，再扩广度才是安全的。

2. 自建 vs 采购

自建的优势是灵活，能完全贴合业务；劣势是周期长、维护成本高、依赖关键人。采购的优势是快、有现成的分析能力；劣势是个性化需求响应慢、数据在别人手里。

我的经验判断是：如果你的核心竞争优势就在数据分析逻辑本身，考虑自建；如果分析逻辑是通用的，采购更划算。对绝大多数电商团队来说，商品分层、价格带分析这类逻辑是通用的，不值得自建。

另外一个容易被忽略的点是维护成本。自建系统的隐性成本主要在人员流动上，核心开发离职后，系统往往迅速失修。如果团队规模不足以支撑专职维护，采购的长期成本通常更低。

3. 实时 vs 离线

很多团队一上来就要求实时。我的看法是：组合优化几乎不需要实时。品类组合按季度调，价格带按月度调，生命周期按周度看，实时刷新带来的边际价值极低，但成本可能高出数倍。

例外的情况是清仓和促销场景。如果一次促销活动只有 6 小时，库存和价格需要动态调整，那实时确实是必要的。所以我的建议是：先做 T+1，把决策循环跑顺，等到有明确的实时场景需求再加。

4. 精细 vs 可执行

这是最本质的一组取舍。精细度越高，模型越准，但业务越难理解和执行；可执行性越强，规则越简单，但可能损失一部分精度。

我曾经用聚类算法做过一次 SKU 分层，分出了 7 个簇，每个簇的特征都很显著，从统计上看非常漂亮。但业务看完之后说：“我记不住这 7 个簇分别是什么。”最后还是改回了四档规则。

在商品分析这个场景里，可执行的粗略规则，价值远高于不可执行的精确模型。因为组合优化的收益来自执行，而不是来自分析本身。

九、三个误判，以及对应的自检问题

最后说说我在项目复盘时最常遇到的三个误判。它们看起来像常识，但真正执行时暴露出来的问题非常具体。

1. 误判一：工具越全越好

工具越全，功能边界越模糊，团队越容易陷入“先搭起来再说”的惯性。我在一个项目里见过同时使用四套分析工具的团队，结果是同一个指标在四个地方有四个不同的值，业务不知道该信哪个。

自检问题：如果明天只能保留一个分析工具，团队会保留哪个？如果答不上来，说明工具已经过量。

2. 误判二：数据越多越准

数据量与分析准确性之间不是线性关系。引入不相关的数据源，反而会稀释重点，增加口径冲突的概率。我见过为了做商品分析接入 chatbot 会话日志的案例，最后这部分数据从未被使用。

自检问题：当前系统里，有多少字段在过去 30 天内被至少查询过三次？如果比例低于 30%，可以考虑清理。

3. 误判三：组合优化是数据部门的事

组合优化的落点在商品、采购、运营，不在数据部门。数据部门能提供分层结果和阈值建议，但最终“这个款要不要留”是业务判断，包含数据无法覆盖的因素，比如供应商关系、品牌定位、季节预判。

自检问题：上一次分层结果出来后，有几条被业务推翻？如果一条都没有，可能意味着业务并没有认真看。

这里的边界感很重要：数据团队负责给出可信的分层和可复算的口径，业务团队负责在数据结论之上叠加商业判断。把决策权留在业务手里，系统才不会变成一份没人认领的报告。

十、结语：从“能回答的问题”开始，而不是从“能采集的数据”开始

回到开头那个问题：“商品分析系统搭建，组合优化从哪里开始？”我的答案是，从你能回答的那个具体决策问题开始，而不是从你能采集到的数据开始。

顺序应该是这样的：先确定这次要动的是结构还是效率，再确定要做的是品类组合、价格带组合还是生命周期组合，然后选一个能被验证的最小指标，用现有数据跑通一次完整闭环，最后才是工具和自动化。

这个顺序看起来慢，实际上是最快的路径。因为它把有限的人力集中在了能产生决策的环节上，而不是消耗在无边界的准备工作中。

如果你现在就想起步，我给你三个可以直接执行的动作。

第一，今天写出一句话决策描述，格式是“我们要在【时间范围】内，对【决策对象】做出【决策动作】，判断依据是【一个指标】”。写不出来就先别启动项目。

第二，本周用导出的表格做一次最粗糙的分层，选 5 个 SKU 做出决定，记录理由，设好 4 周后的回看日期。这次闭环的体验，比任何方案评审都有价值。

第三，把现有看板上的指标逐个追问三层“所以呢”，凡是问不到具体动作的指标，先下线。看板变短的那一刻，团队的注意力才开始变得有效。

组合优化从来不是一个技术难题，它是一个关于顺序的判断题。顺序对了，工具只是加速器；顺序错了，工具只会让错得更快。

免费注册

咨询方案

扫码咨询方案