业务交付与运营「业务架构和应用架构的区别」
今天给大家普及一下业务交付与运营「业务架构和应用架构的区别」相关知识,最近很多在问业务交付与运营「业务架构和应用架构的区别」,希望能帮助到您。
本文从传统电商产品设计为切入点,对比分析企业服务交付平台的设计逻辑及侧重点,并尝试提出设计方案。
一、
在介绍企业服务电商之前,我们先简单总结下传统电商平台产品的设计逻辑和侧重点。
传统实物电商有标准的会员管理、商品管理、营销管理、订单管理、支付管理、物流配送管理等功能模块,其每个模块经过这么多年的摸索在业内基本已形成系统标准。
会员管理
会员管理体系主要针对个人用户设计,讲究便捷,其目的是能够让买家在平台有一个统一识别的身份认证。能够以该身份建立用户画像,实现进准营销。
通过这种精准的用户画像为客户提供大量的能够产生“逛”的欲望场景,在逛的过程中产生下单的欲望。
商品管理
商品管理主要体现品类的丰富性。在后台其与库存管理结合起来能够实现对商品移动的时间、成本进行管理,也能够为公司财务测算业务成本、利润分析提供基础数据。
在前端通过商品详情页给客户展现大量的介绍商品价格、质量、规格、使用方法的信息,同时聚合服务评价相关的信息,以支撑客户做最后的购买决策,客户能够通过商品管理提供的功能完全的熟悉商品各个方面的情况,商品管理只提供一口价这种单一定价模式。
营销管理
营销管理在整个电商系统中是一个辅助性的系统,为客户提供“省”的购物体验。营销管理系统需要与会员、商品、订单、支付等模块整合使用,通过营销管理能够为客户提供大量的优惠、折扣、以及相关的营销活动,同时能够对各种因素引起的折扣结合商品中的基础价格进行价格计算,并能够对计价规则进行管理。
订单管理(狭义的订单管理)
订单管理是整个电商系统中的核心,是对订单整体生命周期管理的实现,是一个把会员、商品、营销、支付、物流等信息进行集中处理和展现的功能模块。
在传统电商的订单管理中,客户会在一个订单中购买多种商品,如果订单中的商品会有不同的配送方式则会进行拆单处理,订单履约的过程主要是物流信息的跟踪,订单生命周期一般在7天到一个月之间。
支付管理
支付管理主要为个人提供支付功能。主要有银行卡快捷支付、第三方支付、网银支付等通道,一般为一次性付款支付,若需要有分期付款则通过信用卡或者个人消费贷款实现(花呗、白条等)。
二、
介绍完传统电商的系统的实现逻辑和侧重点,我们再回过头对比下企业服务电商的设计逻辑和侧重点。
首先,我们对企业服务进行一个简单的定义:企业服务指的是为企业提供经营所需的人力资源、工商财税、知识产权、设计咨询等相关的服务。
其中有三个关键点:
服务对象为企业,也就意味着是2B;人力资源、工商财税知识产权等都是专业性很强的服务型产品;提供的是服务,不同于实物,没有物流(商品货权转移的过程复杂),取而代之的是服务流程。企业服务电商平台其本质还是在售卖商品,在系统整体的架构层面同样具有会员、商品、营销、订单、支付等功能模块,乍一看似乎二者没有什么太大的区别,但如果从我们所给的企业服务的定义中的关键点我们可以看到其本质上是有巨大的区别的。
首先,由于服务对象为企业,我们在设计会员体系时即需要考虑其客户的需求与传统电商的需求侧重点会有不同。
企业用户的交易决策机制一般为多人决策,一次交易会涉及到企业中各个部门的不同角色,即使是个体经营户也会涉及到2个或2个以上的人员决策。
出于这种需求的考虑,我们在会员管理系统设计之初即需考虑多账户、多角色的相关功能,也需要考虑会员账户与企业主体之间的委托法务关系。
在设计整体的交易流程也不在是以“逛”为核心,即使你能给产品使用者制造出冲动消费的欲望,这欲望在2B的产品中也是很难进行订单转化的。
我们更多的是需要为客户提供专业、高效的体验,取得用户信任,从而影响其集体决策的取向。
由于服务对象为企业,我们对不同规模、不同交易频次的客户需要采用分级分类,个性定价,区别服务的处理,要求我们对商品的定价机制需要结合客户的基础信息、历史成交信息进行动态定价,且能够允许人工介入进行定价。
不同规模的客户对下单、支付的流程会有不同的需求。一般企业客户会对合同、资金凭证、发票有特殊的要求,且国家也出台了相关的规范要求业务、资金、发票中的企业主体需要三流合一,系统在设计之初就需在这种规范和灵活之间取得平衡点,太规范则效率不高、太灵活则不符合国家合规化的要求。
其次,由于是专业性很强的服务,所以一个最直接的问题是新手客户或者未从事本领域工作的客户在售前是很难通过简单的商品介绍,就能理解服务的具体内容和找到交易决策的依据,他们也很难知道在下单之后需要如何配合服务提供者完成服务的交付,一个财务人员是很难理解人力资源和知识产权的,反之亦然。
而每一个大类的服务其售前的方式、售中的交易条件确认以及售后的履约过程都是有天壤之别,代理记账和专利申请、商标注册和商标疑难的交易流程差异巨大。
这种种特殊性要求我们在设计商品管理系统时,就能够考虑到系统能够按不同的类目对交易流程(售前导购、售中咨询、售后履约)进行配置或定制化开发,能够在发布商品时就提供全方位的说明资料,需要对不同的类目定义服务所需资料、交付标准。
最后,说一下交付物为服务的影响,由于交易物为服务,很多服务是没有明确的物权转移标志的,只能通过在售中确认的交付条件进行约束,而这种约束的条件往往需要用正式的文件进行记录并取得双方的正式确认,以备后续服务过程中发生纠纷时双方进行维权使用。
由于交易物为服务,而企业服务一般的交易周期较长,像知识产权、人力资源等服务一般履约周期的跨度在3个月到几年不等,造成公司业务的收入确认很难在一个财务周期完成,在交易发生退款、售后申请时难以按正常的电商流程处理。
在实物交易中,一般一个物品的交付确认外物权转移即可进行收入确认,并与相关的供应商等外部机构进行结算,而为了保证物权转移,基本上所有的电商平台均会设置客户确认收货的流程。
而服务交付时间跨度太大也难以保证服务提供标准的一致性,服务交付过程中前后的连贯性,而由于难以保证一致性和连贯性会造成大量的客户维护投诉。
服务是分阶段交付,且普遍的交易金额较大,造成大量的订单的支付方式会出现分期,且会使用不同的支付方式进行付款,从而造成财务核算的难度加大。
三、
在把关键点拆开进行分析时,已经可以看到企业服务电商平台设计的复杂性,但这还不是全部。
在现在这个企业讲究核心竞争力的时代,很多企业对一个领域的企业服务往往希望服务提供商能够给出系统性的交付产品。
他们希望的是得到的是:知识产权布局及整体解决方案,公司财务、税务整体解决方案等。
而这种跨品类的服务品组合的解决方案对系统的挑战就该更大,对会员体系、商品价格体系、订单管理体系、财务支付体系等要求也更高。
而我们的团队也正在探索其产品系统的解决方案,若有同学对这一块想深入研究可以随时和我交流沟通。
本文由 @keeliu 原创发布于人人都是产品经理 ,未经许可,禁止转载。
题图来自 unsplash,基于 CC0 协议