接口还没开始做，“产品”先有了三个意思

项目一开始，看起来只是把几个系统连起来

客户要把 SAP 里的产品数据送进 Akeneo，再分发给其他系统。项目清单看上去很技术：整理字段、开发接口、迁移数据、测试同步。

接口还没开始做，真正的问题先冒了出来。市场说的“产品”、数据团队说的“产品”和 SAP 里的“产品”并不是一回事。大家平时用同一个词，直到需要让系统交换数据，才发现这个词下面放着几套不同的东西。

如果不先把这件事说清楚，接口当然也能开发。系统会非常稳定地把一边的误解传到另一边。

这篇案例会反复出现四个缩写和产品名，先把它们放回具体工作里。

SAP 是客户原来使用的企业管理系统。这里可以把它理解成现有产品和物料数据的重要来源：很多历史数据、编码和业务规则已经在里面运行了多年。

PIM 是 Product Information Management，也就是产品信息管理。它不负责库存结算或财务交易，主要负责把产品名称、描述、属性、分类等信息集中管理，再提供给网站、目录和其他渠道。

Akeneo 是一套 PIM 产品。这个项目选择 Akeneo 来承接未来的产品信息管理，所以团队不仅要“把数据搬进去”，还要决定搬进去以后，产品应该怎样被组织、补充和维护。

SKU 是 Stock Keeping Unit，中文常说“库存保有单位”或“最小库存单位”。一件商品因为颜色、尺寸或包装不同，可能对应多个 SKU。但“一个 SKU 是否等于一个产品”，并没有放之四海而皆准的答案，它取决于业务怎样销售、管理和描述产品。

问题就在这里：SAP、Akeneo 和业务团队都能使用“产品”“变体”“SKU”这些词，却不一定指向同一层东西。

SAP 里已经积累了不少历史例外。有些编码代表现在仍然有效的业务差异，有些只是旧系统当年不得不这样存，还有一些已经没人敢肯定为什么存在。

如果把它们原样复制到 Akeneo，迁移会很顺利。旧问题也会顺利获得一个新地址。

所以项目最先要决定的不是哪个字段连哪个字段，而是几个更基础的问题：什么算一个产品，什么只是同一产品的不同 SKU，哪些变体需要被单独管理，哪些历史差异到了新系统里已经没有继续保留的必要。

这些问题不属于某一个系统。市场关心客户怎样看到产品，产品团队关心目录怎样组织，数据团队知道历史编码从哪里来，IT 则需要确认最后的定义能不能被系统实现。任何一方单独回答，都只能得到一部分。

工作坊里出现了很多真实摩擦：属性没人相信，产品信息要反复手工更新，创建流程很别扭，某些步骤大家已经绕着走了很多年。

这些抱怨都是真的，但不一定都应该进入未来系统。有些是业务必须解决的问题，有些只是当前工具造成的限制，还有一些是局部不便，不值得为了它重做整套产品结构。

每轮工作坊以后，我们会先整理自己的理解，再在下一轮交还给参与者确认。不是问“这个需求写得对不对”，而是问：“我们理解的麻烦，是不是你每天遇到的那个麻烦？”

这一步很重要。否则 PIM 很容易变成一套更现代的旧流程：页面更新了，字段换了位置，大家仍然用同样的方法绕过去。

进入配置以前，团队先把数据模型和关键工作坊设计好，让市场、产品、数据和信息技术团队在同一个模型里核对各自的要求，也把容易被忽略的边界情况提前带进讨论。

产品、SKU 和变体的定义逐渐清楚以后，业务分析师根据已经确认的数据模型，在 Akeneo 开发环境里完成配置。未来真正使用系统的人再亲自创建产品、修改属性，并按照新的流程完成工作。

演示时看起来顺畅的流程，轮到使用者自己操作，往往会突然长出细节。有些测试证明定义能工作，有些则暴露出工作坊里没有出现的情况。业务分析师调整配置，再测一次。这时候接口开发还没开始，调整数据模型只需要改定义和配置，不必返工已经写好的接口。

这个项目怎么做决定

进入接口和字段映射阶段时，团队至少已经知道每个字段在业务上代表什么。产品、市场、数据和信息技术团队不需要一边开发接口，一边继续争论一个 SKU 到底是不是一个产品。

集成没有因此变得简单。SAP 的历史数据仍然复杂，下游系统也有自己的限制。但技术问题终于只是技术问题，不必顺便替整个组织决定“产品”是什么。

这个项目里，最有价值的工作发生在系统真正连接以前。我们先把日常抱怨还原成问题，再让对的人决定产品、SKU 和变体各自意味着什么，最后用真实操作检验这些定义。

系统当然需要接口才能交换数据。但在那之前，人得先同意自己究竟在交换什么。