on
多平台订单履约：记一次迭代的经历
这篇文章是根据发版后晚上开车回家路上自己的录音整理而来，比较散乱，随便看看得了。
最近一个月在做tiktok shop和shein平台的拉单-订单转换，这篇文章对公司同事的总结和自己的实践做一个总结思考，最后是对于这份工作的反思。
我负责的是美国的订单-发货相关业务（业务量在公司3个大区中业务量占80%左右，是公司的核心业务区）的产品工作，另外组内有3位同事一起工作。我们主要的工作是对外承接电商平台的订单，对内与其他业务系统传递信息。
大致的业务流程可以看这张图：
在订单转换中心，需要对不同平台订单转换为内部统一的数据格式，以便内部系统之间传递，特别是订单在分仓分物流，波次下发、拣货的数据格式统一。
不同平台订单传输协议差异比较大，最常见的是API，还有一些是EDI、SFTP，甚至还有直接是表格文件（这一块可以看看CommerceHub）。
除了传输协议导致的对接方式差异外，最大的问题是订单数据字段差异极大，字段后面代表的业务意义也不一样。需要按照平台做大量的字段映射工作，确保字段在业务上的统一。
像我们内部对接的平台有好几十个，增加一个平台就可能需要对订单表进行加字段，导致订单表字段多、杂乱，新同事理解成本高，上手易出错。为了控制这种无序状态，我们在拉单服务中先将数据存到销售平台订单临时表中，完成订单数据映射和同步后再进入我们后端业务的订单主表。
订单状态映射：确保平台的订单状态与内部订单状态在业务层面的统一，能让内部系统明确哪些状态下能够发货回传运单信息，哪些订单状态无需开始订单转化等业务操作的节点状态。
商品信息映射：不同平台商品的SPU、SKU信息与内部采购、发货等环节一致。
物流服务映射：不同平台支持的物流服务商和物流服务存在较大的差别，内部也不是支持所有的物流服务商的。物流服务映射是确保运单信息回传时不会出现无法识别的前提，也是告知内部系统指定发货物流范围。
收件地址映射：有些平台是提供全部的地址信息，有些平台会有区域代码，这里都是需要进过转换映射为内部统一的收件地址信息格式的。
用户信息：一般情况下是不需要存储平台测的用户信息的，能够通过UID识别即可。
税费：主要用来记账和对账。
在产品设计层面，在考虑了系统扩展性、对未来业务的快速响应上，这些均做成业务配置。对我来说，这次的产品改造的经历难在：
- 部门风格是少做少错的类型，每个需求都必须拉群。我这个需求做下来拉了十来个沟通群，
- 先明确责任再谈解决问题的价值观让我有点hold不住：这是一条部门公开的工作方针，我适应不了的价值观，我的第一反应还是优先处理问题；
- 先明确责任再谈解决问题：这是一条内部公开的工作方针，我在这一条上到现在都没适应。第一反应还是先处理好问题；
- 审批流程太长，推进流程花费大量精力：我第一次见几十个人的审批流，甚至还有一审，二审，三审。
按照我老板的说法：这次是我刚来这边一个月多进行的一次产品改造，因为业务体量大，协调部门多，历经了大概十几次的方案修改和评审过程才达成了一致，敢于去动手解决是最难的地方。工作起来可以说是如履薄冰一般的，要非常谨慎。
总结一下：在一个来月的拉扯后，总算是上线了。花费了80%以上的精力来协调拉扯，对于一个产品经理的心力和热情的消耗挺大的。