O2O电商全业务产品架构
零、引子
近来被基建混乱的传统企业搞的死去活来的，于是想着把之前的工作经历里做下梳理，以飨团队。
一、架构图
也许是我的幸运，在我的职业生涯里，基本各家雇主都是遵循了系统分层的设计理念，即各系统定位清晰，仅做自己系统应负责的边界内的事情。
例如在基础服务侧，SSO单点登陆服务承载了所有系统的内部鉴权，通过LDAP能力同步内部所有用户的基础信息，在其他所有系统中不独立设计登陆服务统一使用SSO。
这样首先可以更好的对内部账号进行管理，无需各个系统独立的去处理内部账号密码以及登陆的问题；其次可以节约所有其他系统的开发成本；最后在用户使用内部系统的时候也可以免去跨系统使用时的频繁登录的问题。
二、定位详解
出于各系统对业务的贡献与在整体中的定位，将所有系统简要的划分为了5个板块，（注：阿里、头条等超级互联网公司内部的系统更为精细，拆分也更复杂，不在此做赘述与讨论；同时社交型、直播等其他非电商业务模型的产品架构与上图有极大的差异）即
1.基础服务
与业务关系度极低的，服务于近乎所有业务系统的基础数据或服务的系统，如统一单点登陆SSO，客户基础信息服务，地理位置基础服务GIS等，这些基础服务通常意义上行业虽然有诸多成型的解决方案，但由于与企业业务的特殊性相关联很大，且由于数据安全问题，多半无法直接采购；
2.效率工程
与业务基本无关系的，仅作为提升企业内各职能部门效率的，如开发过程管理系统（行业内如TeamBition、Tower等），EHr系统（行业里如Moka，飞书People等），这些效率工程侧的产品在行业里通常有非常完善的解决方案，作为中小型公司在平衡效率与投入后，其实可以考虑直接外采，非核心数据的直接采用SaaS部署，年费甚至可能低至不到10w/年；
从OKR上看，效率工程侧更关心的是内部的非业务人员的作业效率问题，而基础服务侧更关心对于业务的支撑能力效率问题；但对于基础服务和效率工程的界定，因为我并未管理过这两个团队，其间有可能错误的划分，如财务系统是否该从效率工程划分至基础服务甚至独立为财务中台，SSO是否该从基础服务划分至效率工程，这些边界并不是非常严苛的定位的系统，还望观者在实战中贴合业务以及组织的情况斟酌；
3.数据服务
自我卷入互联网这个行业开始，我就一直在思考互联网到底是个什么。如果说互联网是把所有东西都放到系统/云上，能够用代码、程序来辅助/管理业务的流程，那么传统软件时期其实也实现了这样的目的，我更倾向于这样的事情叫做信息化；
进一步，如果说互联网的定义就是流量游戏，通过更贴合用户的场景、更优的用户体验来获取更多的流量，那么各种传统商超、商场等等也天然具备巨大的流量，可流量进入后企业却无法高效的掌控并加以利用；
所以以我的不成熟的视角看，互联网公司之所以是互联网，能够创造出更高的员工均收入价值进而能够给出远超行业天花板的薪酬，有一点至关重要的原因是，互联网公司通过对数据的利用，可以以极低的成本获取巨大利润空间；
对于任何一个公司，一套独立的数据服务，包括数据的存储、加工、分析、使用等，都对整个业务起着至关重要的作用。
4.各体系的中台
互联网大中台的口号从阿里喊响，到头条把这个玩意玩到了极致成就了App工厂的美名，虽然在行业里仍然有美团这样的公司在搞独立BU独立系统闭环（BU独立系统闭环有他的优势），再到现在阿里逐步的去中台化，看上去中台化的思路是一条弯路，但仍不可否认的是，大中台的思路可以极佳的简化节约复杂业务形态下的开发成本；
作为中台服务，在单一业务模型下的价值尚不是极其明显，其更多的是作为上下游系统的基础信息的统一系统管理与数据来源（在部分传统企业中，这一点都尚未达到，而是通过数仓来记录所谓的主数据来实现业务中台的目标），而当业务模型为复杂多形态的场景下，一套高灵活度、高可扩展性的中台服务可以为诸多业务快速提供业务能力以达成效率提升的目标；
以O2O电商业务为例，业务中台、运营中台、供应链中台、增值业务中台，分别为各独立板块的业务承载其业务所需的所有能力支持；
1.业务中台
承载业务的基本能力，对比基础服务而言，业务中台会更贴近业务，会更易受到业务的变动而变化；
如在电商业务中，商品的基础能力与其产生的数据在其他所有业务系统中均会被使用，如商城的展示、订单中的商品的记录、供应链体系中的商品采购、生产、存储、运输等等，均会使用统一的商品数据；
其余包括订单、物料、价格等等在全业务链条中承担着核心流程体系的也划在其中。
2.大运营业务
承载了面向客户侧相关的业务需求，常见的如商城运营、活动营销、销售运营、客服能力、用户服务等侧重于提升用户DAU、复访、留存、NPS等提高用户体验及转化的目标的业务承接的系统。
拆开来看，在互联网高度发达的今日，其中任何一个单一系统在成熟的互联网公司都是一个非常大的独立的团队，其系统复杂度都远超我上图所绘，在此不做展开讲解。
3.大供应链业务
供应链作为交易商务模型中最古老也是最早一批信息化的模块，早就有ERP这种成熟的系统占据了半壁江山，WMS，TMS等等独立模块更是有数不胜数的软件公司提供极其便宜的解决方案。但随着互联网电子商务的体量与业务复杂度越来越高，ERP这种单纯的信息化的解决方案在面对诸如京东211履约promise下的供应链要求，在多仓场景下的智能调拨、最优成本寻源等方面则显得力不从心。
供应链作为企业的成本大头，其整体的业务目标一直都围绕着提效降本，时至今日，供应链的系统建设应该比erp拆分的更碎更垂直更深入，但要比富勒WMS等等独立的解决方案看的更全更整体，才能够在极其复杂的业务场景中获得更好的目标达成。
4.其他增值业务
在电商业务场景中，也会存在一些和主业务并无太大相关性，弃之可惜食之无味的业务，比如广告。
作为流量消耗体，电商无法自发的产生额外富裕的流量，而这违背了广告变现的核心本质：拥有大量的富裕流量。但从另一个视角看，对于电商来讲，依靠复访或外采获得的流量在内部转化时始终会有损耗，流量一旦进入，成本已经消耗，如何在用户一次活跃中将这些流量最大价值的变现是每一个对客运营侧的终极难题，完全无广告一定会造成流量成本的浪费，而广告过多又会影响自身业务的转化效率；广告业务在这样的一个背景下，投入的多与少都是一个需要细致斟酌的问题。
但对于增值业务板块也需要视更细的业务模型而定，如上文提到的广告，同样是电商，如果是京东这样核心供给是自营的，其核心目标是更高效的使货流转起来使其供应链成本降低，那么广告的优先级会相对较低；但对于淘宝而言，其本质上并无过多的供应链成本，更多的是在人-货之间的高效匹配，广告可以更好的匹配人货需求同时填充可能浪费的未转化流量，并收取广告主费用来达成企业营收的提升，这时广告的优先级会相对提高；
同样的道理，POP三方商家，在京东商城的权重会相对较低，但对于整个京东来讲，通过完善渠道（京东商城）与供应链（京东物流）打包作为行业解决方案，则会显得更有价值和意义；但对于淘宝这种完全无自营的业态，POP或者说是商家服务，则是构建起其完备的供应链的最重要的业务。
5.端与Portal
互联网产品经理的兴起，更多的是由于用户体验得到重视而火热起来的。早期市场上一抓一把的app产品经理随着各大厂的产品完善后，逐渐变成了用户产品经理；
用户端可以说是一个企业的门脸，对于外部客户来讲，无论是直接面向消费者的客户端app/小程序，还是面向合作者的商家端、供应商端等等，用户体验、转化效率、运营的钩子等都是其非常核心的工作重点；
有人说用户体验是种玄学，甚至有人说用户体验完全就是老板体验，那么端一侧有一个非常重要的职责就是把所谓的玄学变成哲学，无论是从人机交互原则、设计语言标准一致性等方法论还是从用户行为数据、用户动线、用户访谈、调研问券等数据分析得出的量化结论，端一侧始终是站在用户的视角里，去伪存真的来更科学的守住企业的面子，让企业体体面面的站着把钱挣了的同时获得用户的一致好评。
从Portal的视角谈，对于上述说的从基础服务再到各体系中台，其本质都是在用高度抽象的逻辑在去解决业务问题，并没有考虑到用户体验的事情。事实上，很多B端的产品都是从软件时期走过来的，传统软件如金蝶、用友这些基于C/S架构的用户体验真的是差到爆，但由于其是给内部员工使用，也很少会有人关心内部员工的体验与使用效率。随着互联网的逐渐成熟，内部员工的体验和效率提升开始逐步变得重要。举例如客服工作台，客服的工作性质使得其天然的需要查询客户诉求的全流程数据，如果其工作的过程需要不断的切换各系统从学习成本极高的诸多后台获取信息，那么工作效率的降低带来的不仅是低人效高成本的问题，甚至会有用户体验的损失的问题。一个良好的内部系统Portal或者Dashboard应该用场景化的方式高效的解决员工的需求，并做好信息的甄选，何为重要信息做一级便捷的展示，何为偶发性信息需要隐藏，如何更快捷的找到隐藏的信息，其更像是一个贴着内部员工做的用户产品。
三、部分传统软件的弊病
随着云计算的兴起，从SaaS到PaaS再到IaaS，诸多软件公司也开始喊着我们是PaaS服务的口号来宣传自己的产品很牛X，有幸在传统企业见识到了一些软件商，如某蝶，某客。
宣讲的PPT写的真的是高大上到令人自惭形秽，但真到了部署实施使用之后，这个地方不开放，那个地方要定制，借用另一个RD的话，讲的时候说自己是个PaaS，到实施完发现就是个披着P外壳的SaaS，就装的像个P。
传统软件因为其需要打包售卖的性质问题，底层逻辑是否分层合理、是否边界清晰，在封装成软件之后都显得不那么重要了，反正对客户都是一个黑盒嘛，而且买软件的绝大多数公司都是传统企业，对于系统好不好用，合理不合理完全不care。同样，对于绝大多数小型企业来讲，拿来即用即可，如果自己的业务流程与软件不一样，轻则改变自己的业务流程，中则搞一搞Excel或者其他非技术的手段辅助，再不济找几个IT外包做个二开，总能解决问题。
但对于大型企业来讲，随着业务的发展其需要的业务复杂度是呈指数级上升的，而且从合规、效率组织等诸多方面考虑，变动其业务流程显得非常的不切实际。并且随着业务的变大，在各细分业务模块的需求都随之变多后，并不会选择仅使用某一家ERP或CRM软件解决所有问题，多系统间的衔接的问题开始变得明显。
举个最明显的例子，ERP中会对库存进行管理，因此首先需要对商品进行管理，而CRM中因为要对客做管理，因此同样也需要先对商品做管理。从两个独立的软件来看，商品管理是其软件的核心必备，都具备其软件自身逻辑，这样看是合理的。但是站在企业视角看，对商品的管理要分散到两个独立的软件中去，无论是数据一致性还是管理溯源，均会存在巨大的问题。
从全局视角看软件，如果其占位在核心业务流程中，软件的非定制化所带来的问题只会随着时间的推移愈演愈烈。同时，对于大型传统企业来讲，缺少了咨询公司的业务梳理，单纯的采买软件，无异于饮鸩止渴。
当然，话分两头，像EHR，IM这些离业务极远的效率工具，选用三方软件真的是利企利人。
四、写在最后
我也仅仅是个互联网新兵，机缘巧合在创业公司里做过诸多项目，也经历过各种杂七杂八的系统；和动辄管理过上千人团队，做过全体系系统建设的互联网大佬完全没得比。故本文中可能会存在部分错误，还请读者带着思考阅读，也欢迎各位大佬指正勘误。
鉴于各系统建设绝非仅仅是图中所示的几个方块里写到的那些简单的能力，针对各系统的更为详细的产品架构如未来有机会，再详细写吧。