如果你正在搭建一个 Sana Commerce 店铺，并问出“谁来建它？”，诚实的回答是这个问题有两个答案，而大多数 Sana 项目只为其中一个配备了人手。Sana 的合作伙伴生态围绕 ERP 实施伙伴构建：那些早已驻扎在你的 Business Central、S/4HANA、NAV 或 F&O 实例内部的公司。让 Sana 与 ERP 对接，自然非他们莫属，因为这正是他们每天在做的工作。但“让 Sana 与 ERP 对接”和“打造一个能转化的店面”并不是同一件事，而后者很少会随前者一起到来。
我们以一家网站设计与开发代理机构的身份承接 Sana 工作。我们不是 ERP VAR，也不会假装是。这个区别正是本文的全部要点，因为理解它，才能让你避开 Sana 项目最常见的悄然失望：一套精准的集成，被硬接在一个没人设计过的店面上。
这道缺口为何存在（这是结构性的，而非懒惰）
Sana 通过合作伙伴渠道销售，而这一渠道由 ERP 伙伴主导，是有充分理由的。Sana 的核心承诺是 ERP 集成式商务：实时定价、库存与客户逻辑，直接从 ERP 端供给。要销售并兑现这一承诺，需要能与 ERP 一端流畅对话的伙伴。于是 Sana 的激励机制、认证体系与联合销售动作，全都围绕 ERP 实施者展开。这是稳健的生意。它同时也是这道缺口的源头。
因为 ERP 实施公司有一个关键之处：他们的重心是正确性，而非转化率。他们极其擅长把价格做对、把税做对、把信用冻结逻辑做对、把收货规则做对。这些都不容妥协，而且确实很难。但前端工艺（字体排版、响应式布局、无障碍、页面速度预算、商品陈列、结算流程摩擦的优化）是另一门学科，对应着另一批人才。要求一家 ERP 伙伴同时成为顶尖前端工作室，就像要求你的结构工程师同时担任室内设计师。有些公司两者兼备。大多数则不然，这并不丢人。
Sana 项目上的两项工作
把这两项工作明明白白地命名很有帮助，因为一旦你把它们视为彼此独立，人员配置的决策便会自然而然有了答案。
第一项工作是集成。把网页用户映射到 ERP 客户记录，验证定价、ATP 与信用逻辑针对每一个客户分层都返回正确结果，处理那总会浮现的客户主数据乱局，在 Sana 自有框架内构建插件，使其在每季度升级后依然存活。这是 ERP 伙伴的领域。如果你试图用一家从未碰过你 ERP 的纯网页公司来做，你会切身感受到代价。
第二项工作是店面。信息架构、视觉设计、前端构建、符合 WCAG 的无障碍、Core Web Vitals、商品陈列、转化路径、内容。这是代理机构的领域。如果你试图用一家纯 ERP 公司来做，你会得到一个正确却令人过目即忘的店铺。正确很重要。令人过目即忘则会让你每上线一天就损失一份营收。
谁负责什么：清晰的分工
进展顺利的项目，都是在第一天就把这两项工作之间的界线明确划出的项目。下面是我们实行的分工，也是即便在我们并未参与的项目上我们也会推荐的分工。
ERP 伙伴负责
- ERP 连接器与集成健康度。实时定价、库存、ATP、信用冻结、付款条件、客户专属目录。数据必须正确，这是他们的职责所在。
- 客户主数据关系。网页用户到 ERP 客户的映射、收货方与付款方、重复数据清理，以及那些没人列入范围、却人人都会撞上的数据质量工作。
- ERP 端业务逻辑，以及触及 ERP 数据的插件。构建在 Sana 的插件框架之上，使其在升级后依然存活。
- ERP 环境、测试数据，以及对定价按分层正确返回的验证。
网页代理机构负责
- 信息架构与 UX。导航、搜索、分面浏览、已认证买家的体验，以及从落地到再次下单的路径。
- 视觉设计与前端构建。Sana 主题、响应式布局、设计系统，以及在 Sana 模板体系内的品牌表达。
- 无障碍与性能。WCAG 合规、键盘与屏幕阅读器路径、Core Web Vitals，以及那份被 ERP 供给的店面变得更难而非更易达成的页面速度预算。
- 转化与商品陈列。商品详情布局、结算摩擦的削减、申购与再次下单流程、内容，以及那些能拨动数字的东西。
- 前端插件与展示逻辑。构建在 Sana 框架之上，但关注的是店铺如何呈现与运作，而非 ERP 怎么说。
共担，且值得设一个固定例会
- ERP 数据与展示之间的接缝。信用冻结如何呈现、缺货行在结算时如何表现、客户专属目录如何驱动导航。这一块没有哪一方能独自负责，而它正是无人盯防时项目最容易崩裂的地方。
- 升级路径。双方都会编写插件。双方都必须让插件保持升级安全。一份季度升级测试计划，而不是两份。
当一家公司试图两者通吃时的失败模式
我们被请去救火、最常见的那种 Sana 失望，是一体化的 ERP 伙伴式构建：集成完美无瑕，店面却看起来像一个 2014 年的后台面板。价格精准到分。买家找不到产品，移动端布局破碎，结算多出三个本可避免的步骤，无障碍审计在第一次自动扫描时就不通过。这些都不是对 ERP 伙伴的指责。它是要求一门学科去交付两门学科的可预见结果。
反向的失败也存在，而且更糟。一家毫无 ERP 通晓能力的纯网页代理机构接下整个项目，把 Sana 当成 Shopify，在插件框架之外手写集成，交付出来的东西会在下一次 Sana 升级时崩坏，而且从来就没有为那些处于合同条款下的客户返回过正确价格。没有 ERP 伙伴负责集成，这类项目我们不接，你也不该这样把项目交出去。
可供引用的版本：ERP VAR 把价格做对；网页代理机构让店铺好卖。一个 Sana 项目两者都需要，而大多数只为其中一个配了人手。
具体该如何配置人手
如果由你来主导采购，最清爽的结构是两份合同配一道明确的接缝。你的 ERP 伙伴（往往就是你现有的实施方）负责集成范围。你的网页代理机构负责店面范围。在双方动工之前，你以书面形式把接缝（上面那份共担清单）定义清楚，并把两边的负责人放进同一个每周站会。就这么简单。两家公司带来的开销真实存在，但很小，而它远比一家全能型公司在它并不擅长的那一半上交付不力时所需的返工要便宜得多。
如果你更想要“一个可以追责的对象”，也行，但要让总承包方是那个其短板你最承受得起的一方。如果你的 ERP 错综复杂而品牌简单，就让 ERP 伙伴做总包并分包设计。如果你的 ERP 是干净的 Business Central，而品牌与转化目标雄心勃勃，就让代理机构做总包并分包连接器。只是别因为发票上只印着一个标识，就假装那薄弱的一半并不存在。
Sana 对代理机构友好之处究竟在哪里帮上了忙
值得肯定的是，Sana 这个平台并不与代理机构的角色相抵触。主题化与插件模型给了前端团队真正的施展空间，无需触碰 ERP 逻辑，这正是这种分工所需要的关注点分离。一家自律的代理机构可以独揽整个展示层，而绝不在 ERP 之前再立起第二个事实来源。这就是架构按其本意运转：ERP 始终是权威数据源，代理机构掌管体验，二者在一道有记录的接缝处交汇。
这对买家意味着什么
如果你只记住一件事：当一家 Sana 伙伴说他们会“把整件事都包下来”时，问清楚他们真正擅长的是哪一半。ERP 集成与店面是两门手艺。这个平台是假定两者都会到场而建造的。合作伙伴渠道则是假定第一者会到场而建立的。有意识地留意那道缺口，为两者都配好人手，你才能得到 Sana 真正承诺的东西：一个由 ERP 供给、既精准又让人愿意从中购买的店铺。
我们是一家通过 Sana 认证的网站设计与开发代理机构，而店面这一半正是我们所做的工作。如果你已经备好了 ERP 伙伴，需要他们覆盖不到的那一半（或者你不确定该如何划分），开启一次对话。你也可以进一步了解我们作为 Sana Commerce 代理机构的工作方式、我们更广泛的 Sana Commerce 能力，或者如果你仍在选择平台，看看 Sana 与 BigCommerce 的对比。