一、缘起
我第一、第二份工作都是在运营商，一共做了18年，自然对运营商的产品概念更加熟悉，而互联网产品汹涌而来，虽然也有学习，但因为没有实践，只是一知半解。去年做的项目中，涉及到了在线教育的产品规划和设计，虽然由于自身原因没有真正投入开发实现，但回顾时发现，自己对于基于SKU的电商类产品概念知之甚少，才有了这篇文章，即对通信行业和电商行业中的产品相关知识进行对比阅读，从而增强这方面的认知。
二、传统通信行业类产品
1、概念说明
简单梳理就会发现，其实通信行业提供的产品绝大多数是服务类产品，即各类通信服务，按照国家的分类目录，第一级就是电信服务、互联网信息服务、电视信号传输服务（IPTV）、卫星传输服务，而从电信服务进行细分，是固定通信服务、移动通信服务、增值电信服务和其他电信服务。
从通信运营商的发展来看，也是如此，设备类销售会有，如最初的电话机，到小灵通，到手机，但从来不是运营商的主营业务，而且大部分都会跟服务类产品进行*绑捆**，如存话费送话机、送手机等，然后就是把这些业务剥离出去，成立独立的公司。
因此，通信行业类的典型产品就是服务类产品，而要研究这类产品，最有效的方式就是去研究支撑产品和业务的BOSS系统。
BOSS是业务操作支撑系统Business Operation Support System的简称，其实它分为OSS和BSS，OSS是运营支持系统，以后台支撑、业务能力的实施为主，BSS是业务支持系统，以面向最终用户的业务受理、客户服务、计费账户为主。
在国内运营商领域，业内公认中国移动在BOSS规划和建设最为出色，而在全球来说，增强型电信运营图（Enhanced Telecom Operations Map，eTOM）则是通信运营商在BOSS规划和建设的主导方*论法**体系，下图为eTOM的业务流程模型（摘自百度百科）。
拿项目管理领域对比，个人感觉，eTOM对于运营商业务支撑人员来说，就好像PMBOK对于项目经理的关系一样。
2、产品相关模型
用户和产品是BOSS系统中的两个核心模型。
而提到用户，就不能不说BOSS中的核心模型之一——三户模型，即“客户-用户-账户”模型。其中客户就是我们日常所说的最终用户，即你我等具体的人，而用户是指客户订购了BOSS中的某种产品/业务后对应的业务身份，如电话用户、宽带用户，它们最终都是对应到具体的客户实体上。而账户是客户与运营商账务关系的体现，客户通过账户缴纳业务费用。
下面是一个三户模型的示意图：
而产品模型是BOSS的另一个核心模型，尤其在互联网业务不断涌现之后，BOSS的产品模型受到了极大挑战，当然三户模型也面临类似的问题，但产品模型的影响更大。
产品最开始的定义是服务+资费，而但随着运营商开展IPTV等内容业务后，现有产品模型适用性较差，所以在服务之下引入内容实体，结合服务所需的资源实体关联关系，所以最后形成的一种产品模型如下图所示：
针对提供内容类产品的SaaS平台，参考传统通信行业理念的产品模型参考设计如下。
简单描述为：产品=服务+资费+内容，产品通过关联不同的营销策略实现各类营销活动，如优惠、打折等，这里省略了用户及账户的关联设计。
三、电商类产品
1、概念说明
说到电商类产品，最耳熟能详的肯定是SKU了，但从实际从业人员来说，其实SPU才是跟产品关联更加密切的。
SPU（Standard Product Unit），标准化产品单元，即大众概念意义上的产品，举例如iphone14，通俗点讲，属性值、特性相同的商品就可以称为一个SPU，跟销售商家无关，与颜色、包装等都无关。
整理到这里，稍微吐槽一下所谓互联网专家的常规做法，即特别喜欢对已有的概念微调之后，换一个更加高大上的名字，让人不明觉厉，但真正了解后才发现是“新瓶装旧酒”。
而SKU（Stock Keeping Unit），库存量单位，最早在服装和鞋类使用最普遍，如纺织品中一个SKU通常表示：规格、颜色、款式等。SKU是物理上不可分割的最小存货单元，对应到iphone14，那么16GB、黑色的iphone14就是一个SKU。
2、产品相关模型
所以从概念来说，SPU其实就是产品，或者说是商品，当然，如果我们把SPU狭义化，只用来描述被销售物品的特性，那么可以把产品/商品看做是SPU+促销信息+物流信息，每个电商平台都需要建立自己的术语体系，不管是叫item、product还是其他。
如果借用淘宝的概念，淘宝中的item可不是产品的概念，我理解可以用“单品”来表示，即在一定场景下交易的最小单元，在多数情况下更多的跟SKU概念基本一致。
以流行的电商平台为例，产品模型中除了SPU、SKU、Item之外，还会有门店、商家等实体，我看到描述这些实体之间关系相对清晰的是下图中的模型：
可以看出在这张图上，是将SPU、SKU、Item三者完全独立，或者说是三层的关系，即在SPU和SKU之间增加了Item，就是两级抽象，SKU是最细粒度，直接可以对应到库存，SPU是最粗粒度，对应到通用产品，两者是1：N的关系，为了防止N太大，那么在其中增加一个抽象层，最终就变成1：M：N，这样可以减少关系映射的数量级，而如何取这个M，应该会跟具体的产品类别有关系了。
以目前理解水平，感觉几大厂商在这个三层的逻辑定义上并没有完全一致，或者说不同行业、不同品类也会有不同，当然，可能他们自己在设计时是有规则的，只不过在外人眼里看不见而已。但不管如何，至少没有行业所统一认可和采用的规则是肯定的，否则就会像eTOM那样，但凡通信行业做BOSS的人到达一定境界后是不可能不去了解的：）
四、初步分析
本来想要做一个深入分析，结果在学习了解中发现，一个是缺少一些行业规范（主要是电商类产品），另一个是这部分内容比自己想象的难度要大不少，自己水平有限，所以只能做一个很粗浅的分析，留待后续认知提升后再进行补充分析了。
从eTOM相关的模型来说，是强调规范性、一致性的，即希望用这个模型涵盖一切，对于运营商运营传统业务来说并没有问题，因为基础的通信类业务种类少、变化也不多，而且所有用户、业务都是区域化服务，即各省自治，在之前的电话业务上甚至做到了市、县自治。在这种强本地化业务运营的模式下，eTOM模型以及背后的运营商服务模式可以提供很好的规划、规范、服务化的支撑，这种模式有一个底层逻辑，即运营商传统类业务的ARPU值足够高、体量也足够大，业务跟基础网络的绑定关系也足够深，所以运营商按省份建设、业务发展和服务的模式才能成立，并且运转良好。
但随着基础网络建设快速发展，带宽飞速增加、3G/4G/5G网络的普及，新业务很快打破了区域限制，通信行业原来分区域业务发展和运营的模式已经无法适应这些业务发展的要求，对应的，BOSS系统的业务模型也无从涵盖这些新业务所要求的产品、营销等特点。通信运营商一般都通过独立建设增值业务专用的BSS来实现新业务的支撑。
所以，完全使用eTOM的产品模型去支撑电商或者其他互联网新业务，并不是一个很好地选择，现在想想，庆幸因为自身原因没将这个模型生搬硬套到去年的这个项目上，否则，即使因为初期市场发展不快，产品模型可能支撑2~3年的业务，但真正业务开始铺开后，模型重构估计是逃不了的，那时可就更难受了。
当然，不是说要用电商产品模型去重构eTOM，把运营商的基础业务产品都重新做一遍，因为如上面的分析，eTOM的模型对于目前运营商的基础产品来说还是比较合适的，而且它的三户模型，我认为也是在电商业务中参考借鉴的，不过，账户模型可能需要根据当前灵活的支付模式（微信、支付宝、银联、支付牌照商等）进行调整，这也是最近在学习支付平台架构中看到的内容。
最后只能说，业务、技术、模型、框架都没有所谓能“一招鲜吃遍天”的“银弹”，都需要根据现在的业务、技术发展情况不断学习不断完善，在实践中更是要根据项目情况进行必要的调整。