本文主要拆解SHEIN产品，SHEIN在跨境领域中进展如火如荼，是排名前几的独角兽公司，是我国出海企业的一个标杆，本文就以SHEIN核心产品进行浅析，不妥之处，不吝斧正。
SHEIN在跨境电商领域属于头部玩家，有一套完整的产业链以及运营方法论，在现有基础上更进一步，除了卖货，或许辐射自身产业链和运营方法是一个不错的选择，这样相当于扩大自己的影响力，把盘子做大，却不是一味的做大，而是基于自身优势相关的领域做大，从而可以反哺自身主要业务。
一个业务走通完整流程，做到精熟之后，可以将其自身的经验、能力、资源辐射给其他做相似业务的客户，一方面报团取暖、二来让客户少走弯路，三者把自身优势最大化、开创第二增长曲线，稳固护城河，这也是搭建开放平台的初衷。
开放平台既是一个产品也是一本用户手册和帮助文档，是接口化的SaaS；这就像是一个集装箱，可以集成，可以封装。这里传递的是数据，哪怕是功能，也是用数据体现的，因此开放平台就是一个数据交易/交换平台，能力输出，也涉及到数据安全的问题（这是根基）。
开放平台有四种类型：自研自用、自研他用、他研自用，他研他用。不管是那种类型，都需要考虑成本和效益，以及是否有必要。
1）自研自用
在公司内部，如果存在多个系统，有业务关联的话，会有接口之间的对接，哪怕没有业务关联，至少员工信息是需要通用接口来数据互相传递的，而内部的接口对接我们通常不称为开放平台，或者加个前缀叫内部开放平台。
在中小公司往往不存在这样的平台，要么是在一个swagger上集成某个系统的所有接口，要么就是零散的接口文档，根据需要定制给内部其他系统，这时候就会出现哪些系统用了什么接口都不清楚，可能同一个或类似需求，做了好几个接口，没有规范，只求方便。
2）他研自用
有些时候，如果发现外部市场有自己想要功能的开放接口（不包含纯定制化的场景，如果纯定制化，那就是和外包的区别了），这个时候我们需要考量下是自己去研发一套还是自研一套新的，这里面考量的是自研的成本（包含时间、人力），这个时间一方面是指研发时间，另一方面是指该功能使用时间，这就需要与外采的费用进行对比（使用时间内的全部费用+对接的时间人力），还有考虑产生效益（如果自研时间是红利期，那么就先选择采购），进入市场的时间（市场瞬息万变，差一点就会错过，后续要花更大的代价才能争取原来的市场份额），综合考虑下来选择最优解。
3）自研他用
这也是绝大多数开放平台的一种形式，将自身能力向外辐射，这种他用的比上述自用的要求会更高，成本也更高，当然产生效益也更高。
4）他研他用
这种类型一般基于两种情况，一种是纯做二道贩子，自己包装后去售卖；第二种是结合自己现有产品打包售卖，可以作为一个增值功能，可能是一条业务流程线上的某一节。
以上几种大多不是单独存在的，而是结合存在，在于开放平台的搭建与否和本身的投入有关，也与取得的效益有关。
搭建者为降本增效，使用者为降本，为什么使用者不为增效呢？如果真的增效，自研定制化岂不是更贴切自身企业业务，讲到底还是为了节省产品研发维护费用。
SHEIN走稳跨境赛道后，有很大的可能性，这种可能性不仅仅来源于跨境电商一条路，但这是主路，至少目前是。其他的路也是基于这条主路衍生的，包含了线上和线下两种形式出现，也可以分成硬能力和软能力两种类型，以下都是个人觉得可能成为增长点的机会。
这里分为三块内容：软件、软件实施培训、代运营。
1）软件
软件部分又分为开放平台和SaaS，一个提供的是软件功能接口服务，一个提供的是软件功能操作服务。
SaaS更适合完整的一套跨境电商业务，相当于复试一个SHEIN基础版给到客户使用，有点类似有赞微盟。
接口开放平台则更丰富，它可以不需要一个完整的流程，只需要一个完整的功能，是基于跨境电商流程中某些节点的功能，例如：报关、支付、BI、CallCenter、供应链。。。
2）软件实施培训
与软件部分相结合，用户在购买了SaaS产品或者对接了相关开放功能，需要实施人员对接支持，以及操作过程中的培训支持。
甚至可以做成技术咨询，给客户培训软件系统架构。
3）代运营
把自身电商运营的成功经验复制给客户，包含网站的运营、商品的运营、客户的运营等。
这就和实体相关了，可以从产品和服务设施说起。
1）产品
SHEIN有自营产品，有自己的供应链和加工厂商，那么也可以额外给到其他商场做代加工业务，这样下来，如果是自己找的供应商，量大更优惠；反之自己的加工厂，则可以消化更多的业务，这里面包含成品、包装和原材料。
还可以咨询工艺品加工。
2）服务设施
跨境业态下比较难的、资产重的除了上述的产品外（现在好多支持一件代发），还包括了仓库、物流（也可以外包掉）、报关（这块前面有涉及），订单（这块需要代运营来解决）
仓库主要是海外仓，现在关税和物流成本很好，如果海外有仓库会极大减少成本，因此海外仓库租赁也是一个增长点，集中仓和散仓一个更稳定一个更灵活，目前来看主要是集中仓，散仓的概念是临时通过租房想出来的，可以分布在全国各地，更有可能培养房东成为快递小哥，既熟悉附近又有一份钱挣，这只是一个大胆设想。
除了以上的，就是现有SHEIN最稳的产品和服务，自营和加盟入驻平台，平台上售卖的产品也分为零售（B2C）和批发（B2B）。
常言平台就感觉平台上什么都有，什么都放，这不是专业的平台，只是一个杂货店，哪怕百货商场也有界限的划分，我们做软件的也需要有这个概念，我们每一步的处理都要经过深思熟虑。
这有点像很多SaaS厂商，什么功能可以集成进来，什么功能会破坏原有的结构，需要很谨慎的分析需求，打磨需求，找到标准化，只有标准化才能普世，如果都是定制化，那就纯纯外包得了。
简单的功能堆砌和调用是任何软件的断头路。
适合自己生态的产品放置其中才能不断强化自身的平台，就像开发一个鱼塘，是能把什么鱼都放进去，也不是看市面上什么挣钱就放什么进去，这个鱼塘的原本适合什么鱼类，这要因地制宜，然后再在这基础上选择适合一起生存的鱼类、草类等植物放置其中，让原本的土著更适宜生存，也可以周边养些鸡鸭鹅，他们的排泄物是很好的肥料，有助于鱼塘边的植物生长，植物可以给鱼吃，形成一个生态自循环。
因此，在做开放平台的时候，是需要深刻熟悉业务场景，并按照业务场景进行闭环处理，把相关联的接口功能放置在一起，不止于来回查找。
至于调用，需要加强数据、权限等安全管控机制，这是最基本的为平台和客户负责，再能力所及之处，可以优化对接的内容，让对方对接起来更舒服，这是需要同频，比如一些名词的解释，让不是开发的人能看懂。
开放平台上只有接口开放吗？有没有纯功能的接入？就像直接移植一个H5页面，也许也是开放平台的一种形式。
对开放要有敬畏和热爱。
因为热爱才能更好的开放，因为敬畏不会过度开放。
如果设计好一个开放平台，需要一定的气质，不仅仅是技术上的能力，还包含了对业务的了解，对行业的了解，对趋势的了解，从浅入深阐述以下几点：
开放平台是一件严肃的事情，是一个规则的浓缩，因此不需要特立新奇，需要的是按照规准格式进行布局，这样对接的人可以轻车熟路按照规则进行对接。
上述调用过程也提到了，这不是说文字水平有多高，但要平易近人，让人可以读懂，保持同频是做事效率最高的形态。
对于不清楚的业务，是不知道哪些可以进行封装开放的，也不会知道如何开放出去更好用，因为这里面包含的是流程场景，流程性、相关性的接口搭配在一起，才是完整的业务，这对于对接的人员也方便。
熟悉业务是整条产业链，从原材料开始到最终销售到客户手上，全盘去考虑业务形态，让埋藏在深层的机会浮现出来。
也就是上述生态开放中的健康开放，需要我们评估功能的增减，这要考虑的不仅仅是市场，还有自身架构，后续的延展性，这一步不仅仅是技术方面的问题，有时候也是管理层面的问题，有时候不要比要更重要。
好大喜功也是一个弊端。
这是对未来的感知，基于业务市场趋势的熟悉，才可能培养敏锐的感知力，提前布局，占住先机。
感知力的培养需要深入市场，深入市场是为了获取更多纬度的信息，从信息数据中分析出一个轮廓，平时也需要多思考，多关联性思考，有时候也需要跳出本行业去看，可以借鉴别的产业链，所有跳出借鉴都是反哺自身业务。
其他一些基本的职业素养就不罗列了。
这其实和上面标准化类似，只是在执行过程中的一些注意事项，都是基于安全性角度出发的。
在功能上线需要充分测试（功能、性能、兼容），需要评估影响范围，做到算无遗策，如果有隐患，需要提前做好预防和准备解决方案。
在升级维护方面，需要提前告知，有些可能需要做好培训工作，发布后也需要客服待命。
在所有对接的数据中要关注使用量，异常行为，如恶意灌输。从数据中也可以分析出客户的使用情况，这对后续合作有帮助。
开放平台方面写得差不多了，接下来粗略勾勒了SHEIN产品结构图，如下所示：
以上是结构核心内容，也正是基于以上的核心功能出发，才有开放平台的定位，从下到上进行阐述。
这是底层，也是根基，重要程度不言而喻。
数据有人和行为结果，主数据就是讲的平台的忠实用户（也叫流量），如果平台上有多个系统，需要保证客户唯一性，这边客户分为C端消费者和B端客户（商家、供应商、其他厂商）
客户有了行为后会产生行为数据，部分行为数据会产生结果（离开、签约、下单、支付，最终是交易成功），这些数据都在数据仓库中，当然是标记上来源。
通过这些数据，可以按照各系统自己的需求形成系统数据（数据集市），互不影响。
再往上是通过数据做成可视化的dashboard，各个维度的数据通过联系统计分析后得出一个个结论和预测，展示给相关人员看。
往上一层是底层技术架构中的一些基础功能组件，按照SHEIN业务来看，我罗列了6项基本的组件。
应该还有其他的一些组建，暂未罗列，只是把个人认为比较重要的列出来了。
往上是业务系统，也是一些成熟的业务类系统，这边也罗列了SHEIN相关业务需要用到的一些系统。
业务往上是职能层了，这主要做内部管理的工作，包含各角色的系统。
这边指的是针对前台系统做支持的后台系统，这边只罗列了两个业务模块：电商和供应链
1）电商
这是主业务，包含了B2C和B2B业务，也有自营和加盟两种形式。
这里包含了商家管理（商家入驻管理）、产品管理（商家上传商品）、订单管理（交易）、营销管理（各种营销活动发布）、会员管理（消费者管理、等级等）、税务（报关）、支付（支付配置）、CMS、账单。。。
2）供应链
这是基于自身产业链头部材料获取及后期代加工为主导的系统。
这里包含了供应商管理、产品管理（电商也有产品，这边产品与电商的一般不太一样，因此独立做了一个）、订单管理（材料、产品订单）、计划预测（根据市场反馈设定采购和出品）、生产管理（产品的进程）、质量管控、采购管理（可以借用OMS）、运输/配送（可以用TMS和快递）
以上仅仅罗列了完整系统中的小部分功能，真正完整的系统很复杂，但再复杂的系统也有规则，只要摸清规则就不难了，最多就是定制化。
前台就是直面用户的端口了，根据SHEIN的业务，分为C端消费者和B端商家。
C端消费者可以使用电商官网和APP进行购物，B端商家可以使用商家客户端进行店铺维护
行文至此基本结束了，但这也只是一个开始，如何设计、如何运营还需要看市场的需求和反馈，但麻雀虽小，五脏俱全，一些基本的功能提前布局好，是对未来扩展一个帮助。
所有的功能复杂程度是成本和效益的一个博弈。
本文由 @诗忆录 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。