搭建php网站环境,百度指数是怎么计算的,企业手机网站建设咨询,wordpress 主题加速概述
上篇文章我们大致讲了一些商品中心相关的概念#xff0c;例如#xff1a;SPU、SKU、Item等等#xff0c;在这里我们来简单的回顾一下#xff1a;
商品概念的分层与定义#xff1a; SPU#xff08;Standard Product Unit#xff09;#xff1a;代表产品系列或产品…概述
上篇文章我们大致讲了一些商品中心相关的概念例如SPU、SKU、Item等等在这里我们来简单的回顾一下
商品概念的分层与定义 SPUStandard Product Unit代表产品系列或产品组具有相似特征的产品集合。它定义了一类商品的关键属性和绑定属性但不包含销售信息。 CSPUChild Standard Product Unit作为SPU的补充增加了销售属性可以完全确定一款商品。它是SPU加上销售属性如容量、颜色、存储容量等。 ITEM商家发布的产品实例包含SPU信息和商家信息。它是SPU的一个实例可以被搜索到并且受到SPU规范的限制。 SKUStock Keeping Unit库存管理中的最小单元代表具体可销售的商品变体如不同颜色、尺寸的同一产品。SKU由CSPU加上商家、价格和库存信息构成。 类目管理的重要性 类目管理帮助用户快速找到目标商品提高用户体验。 它为运营维护商品信息提供方便为其他功能如品牌关联、仓库管理和数据分析提供基础支撑。 类目管理在电商运营中是基础提升整体运营效率。 前端与后端类目管理的差异 后端类目面向商家和运营人员需要客观、统一的分类标准以便于日常操作和团队协作。后端类目相对固定不轻易变更和删除。 前端类目面向消费者需要通俗易懂的命名减少类目数量和层级以简化购物流程。前端类目灵活多变以适应市场变化和运营策略。 什么是一个好的商品中心
好都是相对的在我们需要知道什么是一个好的商品中心我们需要了解商品中心需要服务的具体业务场景是什么。
我们之前在供应链系统设计-供应链中台系统设计六- 商品中心概念篇中提到了阿里的业务场景如下图所示 阿里有淘宝、天猫、健康业务等这些业务都会有维护商品、发布商品等诉求因此我们需要从业务流程来看对于商品维护和发布的商品流程大致是怎么样的。因为所有系统首先需要满足业务流程的诉求。 从商品的角度来看无论是淘宝、天猫和健康业务还是其他的公司的业务对于供应链业务而言主要就是针对商品进行“进销存”活动因此我们把商品的在业务过程中整个生命周期细化为如下图所示
商品生命周期图极简版 由上图我们其实可以看出所有从SPU/CSPU/SKU/ITEM都是围绕着供应链业务的进销存来开展的。其实在实际的业务中例如SKU对于供应商来说会存在起发量和最小订货倍数对于SKU也会存在生成状态SKU与SKU之间也会存在新老号的关系主子商品等等这里里面有非常多的细节就没有展开了我们主要是先了解商品在整个进销存的过程的大致的生命周期。
因此基于对于商品生命周期的理解商品中心作为中台的一个核心的主数据我们来想想可能会存在的问题
首先如果淘宝、天猫针对统一个商品是两个不同的SKU会怎么样会出现SKU泛滥导致对于同一样SKU因此对于平台来说商品就泛滥了无法识别销售或购买的是那个商品对于后续商品数据统计与分析就无从下手。因此商品中心核心就是构建商品标准防止商品标准泛滥。
其次作为商品中心作为通用中台的一部分需要最大程度的给前台业务提供可复用的能力让前台业务可以快速服务客户的产品创新和精细化运营而不是把时间花在系统通用能力的构建上。
在这里我们再来回顾一下前中后台的定义 前台指离客户最近最理解和洞察客户需求和行为最终实现和提升客户价值的职能。其核心能力是对市场和客户行为深刻洞察服务客户的产品创新和精细化运营主要围绕C端和B端客户建立灵活、创新和快速响应的机制。 中台指为前台业务运营和创新提供专业能力的共享平台职能。其核心能力是专业化、系统化、组件化、开放化主要通过沉淀、迭代和组件化地输出可以服务于前端不同场景的通用能力不断适配前台。 后台指为整个商城提供基础设施建设、服务支持与风险管控的职能。其核心能力是专业化、服务意识与能力。 如果大家对于前中后台不是很熟悉可以参考供应链系统设计-何为“前”“中”“后”台系统的文章里面有详细的描述。 基于以上中台的定位就决定商品中心其实非常大的程度上前台商品信息标准的制定者。
最后对于前后台业务来说从商品生命周期来看供应链的主要是针对商品进行进销存的业务活动一个商品从采购到最后销售会涉及到非常的业务活动和规则这个里面需要协调各个非常多的部门。
如何让商品信息进行更好的协同什么可以采购、什么是可售等如何控制已不销售但是采购部还在不停的进行采购无法解决采销不一致问题呢等等。
这个就会涉及到商品的生命周期管理一个商品从采购到最后的下架都会经历非常多的业务环节进销存的每个业务环节中如何能够基于商品去进行协同一致就非常重要了。
因此我们基于上面讨论的大致思路我们从业务的视角暂且将一个好的商品中心的标准定义为以下三点 1、需要构建商品标准体系防止商品应用数据泛滥 2、商品中心作为中台的一部分应该抽象前台业务的共性需求让中台商品能力复用最大化以此来提高前端业务的效率 3、商品生命周期需要保证围绕供应链进销存协同一致 以上是从业务角度去思考何为一个好的商品中心的三个标准好的标准针对不同的行业、不同的公司、不同的业务场景都是不同的我只是站在当前的业务场景下去进行思考这个大家一定要注意好的标准一定是根据具体的业务场景来确定的。
上面是基于业务诉求其实我们做架构的时候还需要考虑到非业务诉求也就是系统的质量诉求。针对商品中心的需要服务的业务场景和特性质量诉求如下4点 1、数据正确性。商品作为主数据数据的正确性的重要是不言而喻因此需要有纠错的机制和能力 2、海量的商品数据。根据SPU/CSPU/SKU/ITEM的概念商品数据会随着业务的发展会不断的成倍增长 3、高并发读请求。商品数据是典型的读多写少的访问场景需要支撑前台业务高并发的读请求 4、模型和系统稳定性要求高。商品中心作为最底层的主数据服务几乎前台业务所有的应用都会依赖它因此领域模型的稳定性和系统的稳定性就非常重要。如果商品模型经常变化经常性修改势必会影响到前台业务的稳定性。 以上就是针对什么是一个好的商品中心的标准的定义。
商品设计落地
一个好的商品中心标准定义分为了业务诉求和质量诉求两部分我们设计现在就围绕好的标准去进行展开设计。
基于业务诉求的好标准设计
首先我来第一个好的标准。 1、需要构建商品标准体系防止商品应用数据泛滥 数据泛滥问题首先需要从商品标准来进行限制。前文讲过了SPU/CSPU/SKU/ITEM的模型如下图所示 对于SPU/CSPU/SKU的标准都统一收口到一个组织进行维护而不是让业务前台来定义标准。不同的前台业务对于商品的诉求都是不一样的前台业务和后台业务都可以发起SPU/CSPU/SKU但是对于SPU/CSPU/SKU的维护则需要收口到一个商品管理中心的组织。商品管理中心就是来进行商品的管理以及治理避免出现相同商品数据的标准不一出现重复的数据。 我们再来看看第二个标准如下 2、商品中心作为中台的一部分应该抽象前台业务的共性需求让中台商品能力复用最大化以此来提高前端业务的效率 由于我们知道不同的业务对于商品维护、发布都会有不同的诉求这个会随着业务的发展业务流程的差异回来越大。我们在供应链系统设计-中台系统设计系列二- 好中台的标准之复用原则的文章聊到了不同业务可能存在不同的商品新增、发布等业务流程如下图所示 在业务流程层其实对应的都是不同的业务的流程不同的业务差异是非常大的。因此从最小复用的角度来看在这一层是不太可能复用的这一层需要前台业务自己去进行定义。因此中台在业务业务流程的层面其实在业务初期是很难提供流程级别的复用能力。具体可以如下图所示 在这里我和大家再次回顾一下前台开发和中台开发的核心区别 业务前台技术基于中台提供的能力进行能力集成、编排、扩展实现个性化的业务逻辑及展现层 。衡量指标业务支撑的效率、行业解决方案的沉淀 业务中台技术面向业务能力的开发以最小复用原则。衡量指标能力的稳定性和复用性 因此我们需要看每个流程中的节点对于每个流程节点能力是否可以复用。因此我们可以想到如下的设计 我们将类目、属性、SPU/CSPU/SKU/ITEM等增删改查的最小粒度操作定义成为能力。这样不管是哪类业务都是需要复用的都可以复用这样业满足最小复用原则做到复用的最大化。
大家一定的记住在业务发展阶段我个人建议对于中台能力最好是以原子能力沉淀为主就是能力的最小化做到能力职责的最小一个能力只做一件事情例如SKU创建、ITEM创建。对于创建就是单纯创建业务不要包含创建之外的逻辑否则复用能力会非常差。
这个我在之前的中台建设的经验中非常有感触也踩过雷因此也别提出来。
我们再来看看第三个指标 3、商品生命周期需要保证围绕供应链进销存协同一致 如果从供应链进销存的视角来看商品大致可以分为以下四个阶段商品主数据维护、进、存、销四个业务阶段。如下图所示 大家可以想想一下可能会存在的问题 1、采购状态与销售状态不统一禁止销售的商品还在不断的进行采购 2、在采购的时候由于没有维护SKU信息导致无法进行采购 3、销售进行售卖发现商品过期了仓库没有维护商品有效期信息 4、由于主数据没有维护销售渠道一线业务无法新增ITEM导致不能在一线业务进行销售 .... 以上问题可以总结为业务组织协同以及流程问题。我们可以通过对于商品生命周期的定义来进行解决。商品生命周期具体流程其实已经在文章开头的流程图图中已经展示了在这里就不再进行赘述了。
主要是让大家明白商品生命周期的管理对于业务的重要性以及对于商品中心本身的意义。
写在最后话
今天主要和大家讨论了关于一个好的商品中心的标准的是什么因为没有好的标准我们的设计其实是没有目标的。因此这个是一个非常重要的问题。一个好的商品中心标准可以分为业务诉求和质量诉求两个部分具体如下
业务诉求
统一标准制定统一的商品数据标准如SPU、SKU等避免数据重复和不一致确保数据准确性和一致性.流程支持与复用在流程节点层面提供最小粒度的能力复用如类目、属性等的增删改查操作满足不同业务需求实现能力的最大化复用.生命周期管理有效管理商品从采购到销售再到下架的生命周期协调各部门协同工作解决采销不一致等问题确保商品信息在各业务环节的一致性.
质量诉求
性能具备高性能处理能力快速响应大规模商品数据处理和高并发业务请求.可靠性保障数据可靠性和系统稳定性通过数据备份、容灾机制等措施确保系统在异常情况下快速恢复.可扩展性架构设计支持模块化和组件化便于灵活扩展功能和适应业务变化.安全性采取严格的安全措施如数据加密、访问控制等防止数据泄露和非法访问确保系统安全.
我们针对业务诉求部分进行展开讨论并且说明了在具体实施过程中需要注意的设计点。由于商业保密原因在这里不能详细进行说明希望大家可以谅解。
关于质量诉求其实涉及到业务知识不多更多是偏纯技术架构层面的东西我会在下篇文章的中和大家继续探讨。
今天就和大家聊到这样希望能够给大家带来一些收获和启发下篇文章见哟。
