考拉POP生态建设之路：如何做“开放”
从考拉POP的缘起到运作逻辑，今天，笔者介绍了考拉POP平台的核心原则。围绕这个原则，团队进行了不少尝试，也留下了一些遗憾。
前面两篇分别介绍，以及，POP的核心是开放和平台化，本篇以“开放”为契机谈谈考拉生态建设的一些收获。
需要说明的是，这里仅是个人实践的点滴，里面的内容与阿里开放生态、“商业+开放平台+云计算商业平台”的高度不可同日而语。
在“开放、连接、赋能……”这些与平台生态建设相关的概念里，“开放”是生态建设首要考虑的问题。
我参与过的B端产品设计里，有关“开放”的产品设计是里最具挑战性的产品域之一。
如果说C端很多域的产品设计需要“艺术”sense，那么开放这个B端域的产品设计需要的是“哲学”修养。它的哲学性体现在“目标与手段、过程与结果、矛盾与统一”等诸多关系的理解和处理。
让我们从灵魂三问开始，聊聊“开放是什么？如何开放？为什么开放？”。
开放既是目的也是手段，平台通过向合作伙伴开放平台的服务和能力，可以让合作伙伴更好完善平台开放的开放能力。当平台采用开放的态度时，在一定程度上就实现了开放。
开放既是过程也是结果。真正的开放是一个不断深化，持续完善的过程。
以上有关“开放是什么”的解释里，也包含了“如何开放、为什么开放”的思路。如何开放的首要条件之一是保持开放的态度，构建平台生态是为什么要开放的核心奥义。
在介绍具体的产品体系之前，花篇幅来解释“开放”的种种关系，一方面是因为这些关系本来就是产品体系的基石，另一方面是因为这些关系影响着我们团队产品设计原则的形成。
“开放”之于POP，就像“克制”之于微信，属于我们产品的核心设计原则。
以下从产品角度介绍我们团队对开放策略的思考。
一、开放产品体系
行业里有些团队“认为开放平台就等于开放”，从产品的角度看，这种说法稍有欠妥，这会让开放平台的产品边界有些模糊。
我们团队定义的开放产品体系，包含一套开放能力（Open API），一个开放平台和一系列SAAS产品。
Open API是开放平台能力的基础，开放平台是SAAS的平台基石。这个产品框架与阿里开放生态、“商业+开放平台+云计算商业平台”的范围不可同日而语。
1. 开放能力（Open API）
POP的API体系经历了两个版本，实现了一些基础能力的开放，包含商品、交易、订单、会员、商家、物流等100+接口（详见：接口中心），比较友好地支持了商家“商品管理”、“订单履约”、“物流发物”、“财务结算”等四个大的业务场景，高频核心业务场景的覆盖度在75%左右。
POP业务完整的业务场景以及API覆盖的核心场景见下图。
一个完整的API体系是一张庞大的网络，要完善这个网络，负责API定义的人既要吃透产品业务场景，又要了解技术实现细节，需要产品和技术的双重能力。而且API的提供方散落在各个业务域，有效推动各业务域来完善丰富API，需要极高的协调能力，哪怕有战略优先级支持。
POP的API体系设计之初没有产品经理负责，全赖技术支持来负责API设计，后面逐渐将各业务域的API定义交给对应的产品经理来负责。
这个产品过程走得比较漫长和艰辛，其结果是API的完善度一直不太理想，其中也不乏一定API的定义本身不太合理的原因，甚至出现个别API返回、报错内容可读性差的情况。
回顾这个过程，有以下几点经验：
- API的定义尽量用行业统一的标准，包括接口名称、接口字段、常用的接口动词都等；
- API的字段提供要尽力最大化满足合作伙伴不同业务需场景需求，实现业务闭环；
- API接口设计保持单一性，维护合适的粒度，并保证好的扩展性；
- API定义要保持稳定性，力争不要变化；
- API的可读性要好，最好提供示例；
- 建立一套各方认可的API完善机制；
- 做好打持久战的准备。
开放平台算是软件行业最古老的产物之一，属于标准得不能再标准的产品。
这个产品设计的难搞的地方正好也在于它的“标准化”，我们团队产品经理一半对它“发怵”，另一半对它“嫌弃”。产品经理“发怵”的核心原因是因为这是一个偏技术的“产品”，而“嫌弃”是因为做它没有太多“成长性”。
产品经理对开放平台不感冒，技术人员却对它趋之若鹜。
技术同学做开放平台的直接原因有两个：一是因为开放平台实现的技术挑战性较高；二是大量的合作伙伴对接联调以及API的管理，需要无休止的投入时间，他们亟待开放平台赋能（从这点看，技术比产品经理有远见得多，难怪很多公司要消灭产品经理）。
其实，开放平台还有另一层更重要价值：开放平台是生态赋能的基石，基于开放平台开发者可以为商家开发出更多有价值的工具和服务，赋能平台。
POP开放平台是由技术同学自发构建的业务型开放平台，经历过两次大的版本迭代，实现了基础的API网关、开发者中心、授权中心、控制后台等模块，下面附上开放平台系统架构图与核心关系图便于大家理解。
POP开放平台系统架构：
POP开放平台系统关系：
基于这套OPEN API和开放平台能力，我们在一年时间内完成了95%主流电商ERP系统对接（包括网店管家、E店宝等，详见开放平台ERP名单），支撑了80%以上的POP商品发布和订单处理。ERP服务商的整体对接周期平均从45天缩短至三周以内，服务商对接满意度获得了极大提升（综合满意度从65%提升至90%），对应的开发联调时间也减少了70%以上。
POP开放平台仅仅是支持了POP商家这个角色的生意模型，自营供应商、物流服务商、仓储服务商、清关服务商等、分销商等角色的业务场景分别散落在不同的开放平台里，多个平台没有有效整合，这也是我们团队最大的缺憾之一。
总体上看，POP开放平台支撑业务范围非常有限，成长的空间很大，这里放一张比较古老的淘宝开放的业务结构图做个对照。
团队做开放平台的点滴收获如下：
- 对于POP来说，开放平台越早做越好，而且要做持续的投入；
- 公司对外的开放平台最好是做一个统一平台，避免内外部的资源浪费；
- 开放平台是一个技术、商业、体验三重挑战的产品，值得产品经理投入。
SAAS是软件行业的一种典型的盈利模式，国外电商行业shopify是亚马逊的劲敌，国内的有赞、微店等公司更是以SAAS为收入支柱，淘系SAAS的营收早超过100亿规模。
我们团队的SAAS尝试是从平台赋能角度来切入的，没有做商业化的实践，陆续上线的几个服务也是以免费的形式来向商家提供，个别服务甚至是倒贴钱。
有赞业务结构图，资料来自有赞2019财报：
有赞收入结构图，资料来自有赞2019财报：
之所以把SAAS放在开放产品体系里，是因为SAAS是POP这个业务皇冠上的明珠。我们团队虽然没有太多产品实践，但仍然对这个模式做了许多讨论。
下面对我们提供的几个SAAS服务的构想做个简单介绍。
SAAS服务之一：电子发票服务
电子发票服务，是了为解决商家开票时效慢的痛点而提供的一站式解决方案。
平台引入电子发票服务商，基于商家授权，平台向发票服务商开放相关开票的数据，服务商完成电子发票开票并回传开票信息。
在服务提供前，POP商家的发票客诉和工单长期居高不下；服务上线后，约有90%的电子发票是通过这个服务来完成，相关客诉下降了60%以上。
该服务的业务逻辑图见下：
SAAS服务之二：商品一键搬家
商品一键搬家，是为了解决商家跨平台商品发布难的痛点而上线的服务。
平台引入ISV，ISV提供跨平台抓取商品的能力，商家开通服务后，可以授权ISV抓取指定平台店铺下的商品，并通过类目映射的方式发布到POP的商品库。
这个服务的难点有两个：一是保证商品素材抓取的稳定性，二是确保类目映射的准确性。
商品一键搬家服务在非标类目商家的使用比非常高，在很大程度上缓解了商家商品发布的压力。
有关服务市场的一些不成型的思路：
服务市场是我们团队长期思考的一条产品线，团队的产品参考淘宝服务市场完成MRD和产品框架设计。但受限于业务规模的制约，因此这个产品项目一直未能开始。
POP服务市场产品框架：
项目虽然未能开始，但仍有几条收获可以分享：
- 业务量是服务市场的根基，淘宝服务市场的成型就来源于“流量”业务规模化的带动；
- 活跃商数达到2000+，能支撑ISV 10W/月的收入体量时，可以考虑服务市场；
- 服务市场可以从内到外冷启动，先由平台提供一些核心服务再引入ISV提供其它服务；
- 可以裹挟TOP商家一起来跟ISV谈判，TOP商家往往是ISV在其它平台的重点客户；
- 商品管理、订单管理、店铺装修、促销管理、优惠券管理相关的应用是SAAS的重中之重。
SAAS是一个很成熟的行业，各大佬有许多高屋建瓴的探讨，有兴趣的同学可以进一步查找。
“开放”是POP平台的灵魂之石，团队倾全力投入也不为过，这个道理我还是明白得太晚了。
二、开放与不开放
开放与不开放是一对矛盾统一体，对“不开放”的定义越清楚，越有益于更好“开放”。
平台不开放的红线之一是：隐私信息，包含用户隐私、商户隐私等。
要在保护用户隐私的同时又满足合作伙伴需求，个人的建议是：
- 对信息获取严格的权限控制；
- 对能获取用户隐私数据以及行为做好溯源跟踪；
- 对隐私数据获取和使用，做好平台层面定义甚至是法律层面的规范 。
为数据建起一道防护墙，是平台的责任，也是合作伙伴的责任，需要大家一起自律和完善。
其它一些开放与不开放的策略讨论还有：
- 品类选择性开放，尤其POP以非标为主；
- 品牌选择性开放，仅选择契合平台调性的品牌；
- 用户触达的渠道选择性开放，以不打扰用户为原则；
- 商家经营信息选择性开放，同行数据指数化处理；
- 流量策略性开放，维持良性生态。
为解决数据安全、稳定性的问题，阿里采用的是“聚石塔”——电商云工作台的方案，比较完美解决了开放与不开放的问题。
最后放一张阿里聚石塔产品架构图来镇楼，向这个行业的引领者们致敬！
注：资料来自《尽在双11，阿里巴巴技术演进与超越》，电子工业出版社，2017年第1版。
本文由 @赢乾 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议