电商O2O后台产品漫谈——后台产品的目标和作用

8 评论 11551 浏览 130 收藏 20 分钟

本文以企业内部的后端支持系统为主要研究对象,分为六个部分,按后台产品设计过程的顺序,分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。

互联网产品领域,可以笼统地分为前台产品和后台产品。

前台产品即是C端的产品,后台产品可以笼统地概括为各种管理系统;BAT等大公司还会把后台产品细分为两个部分:一个是纯后端部分,指的是业务流程、逻辑规则、数据结构部分,不涉及到界面;一个是中台部分,即提供内容展示、功能操作的可视化系统界面。

我们一般所说的后台产品,根据面向用户群体的不同还可以分为两类,一类是针对大企业内部,作为内部各个业务线的支持系统,常见的比如电商行业的商品管理系统、订单系统、供应链系统等,我把它概括为后端支持系统。

通常以交易或者实体业务为核心的互联网公司,比如电商、O2O、金融等方向,都会自己开发完整的后台系统用于支持业务;还有一类就是我们常说的To B 的saas系统,面向各行业的企业用户,通过某种商务合作,提供B端或者小B端产品给他们使用,比如现在各种行业中给线下机构、门店提供的管理系统,为大企业内部提供的ERP、OA系统,以及专门为特定企业定制化开发的系统,均属于此类。

本文以企业内部的后端支持系统为主。

我们常说的用户端产品价值在于满足用户需求、提升用户体验,后端产品完全不同,第一要义是对业务的支持和提升,通过业务操作和数据的线上化,来标准化业务管理流程、提升业务运转效率,以及发掘数据的价值,进而在各环节影响到公司的成本和收入。这对于主营业务为电商、O2O等任何形式交易的公司来说尤为重要。

四五年前,当互联网还处于线上产品为主的阶段,业内会说有很多公司不注重后台。但现在互联网各行业各类线下服务早已层出不穷,都8012年了,如果还有认为后台产品的价值小于前端产品的公司,可以倒闭了。

我本人在小公司做了一段时间的公司内部支持系统,总结出了一部分关于后台产品的个人经验。本文分为六个部分,按后台产品设计过程的顺序,分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。

本文并没有什么深度,适合小公司的产品经理或者没接触过后台的产品经理看看,也欢迎大公司的产品经理来批评指正。

一、后台产品的作用到底在哪里

1. 用户需求的悖论

从我做产品开始一直到现在,我都能在各个不同地方听到这句话:产品经理的核心价值在于满足用户需求。我们接手一款产品后,首先发现目标用户,然后通过种种手段挖掘用户的需求,通过功能界面等方式实现,满足用户需求。

刚做后台产品的时候,我也照着这句话,把我从后台产品的“用户”处收集到的需求一一实现;一段时间后我产生了疑问。

后台产品和用户端一样也有目标用户,而且用户是固定的,对于企业内部的后台系统来说,用户就是公司内部某个部门的人。他们的需求比广义上用户的需求明确的多,通常他们的需求就是公司实际业务上的事情。

但这意味着他们说什么,我们做什么吗?如果是这样,那产品经理在挖掘需求这方面的价值,不就很少了吗?

这里就遇到用户需求的悖论了;后台产品的目标到底是不是满足用户需求?

经过一段时间的产品经历下来,对这个问题,我自己做出了两点解释:

首先,所谓的“用户”不同。用户端产品是服务于C端个人用户的,满足用户需求是永恒的真理;而后台产品通常是面向B端,服务于公司的,因此后台产品第一要满足的是“公司”这个用户的需求,也就是业务需求,而不是狭义上使用产品的那些人的需求。

换句话说:公司层面的需求大于用户自身的需求。其中,面向B端企业的产品,服务对象是所处行业中的各个客户,企业内部的后台产品,服务对象就是自己公司。

举个最简单的例子:钉钉的“钉”功能,站在用户立场上被频繁骚扰很不爽,但站在企业客户的角度看,“钉”这个功能能提升企业员工间沟通的效率,有助于公司的管理,所以它解决了公司的需求,很多公司会为这个功能买单。

我做供应链系统的时候,经常遇到这样的问题,有些功能对公司的管理有作用,但对使用人来说,反而会加重他们的使用成本,让他们很不爽。但显然这样的功能不得不做,因为这些功能会为公司带来更大的价值。

比如我们要做的一物一码溯源体系,站在公司的角度能规范化管理和数据追踪,站在直接使用者的角度,大大加大了他们的人力和工作量,但结论是这肯定得做。

这就是我针对用户需求悖论的第二点解释:后台产品的价值和用户端产品不完全相同,“满足用户需求”只是其中一个目标,后台产品还有更大的作用。

2. 后台产品的三大价值体现

我做后台产品的时候,一开始我只是接收一些具体要做的事情,比如我们要补全某某业务流程,比如要上线某某模块,然后开始做,中途不断和业务方撕逼后,做出来上线。

后来我想,做这些功能流程的目的是什么,尤其是有些东西业务方并不喜欢,我们为什么还要这么做。之后在产品过程中加了一个步骤,做每个需求之前,都必须和大家明确,这个事情的目标和价值在哪里。一段时间后我发现,这么些需求的目标和价值。

基本可以归纳为以下3个大方向:

1. 提升业务运转的效率,进而节省时间和成本

一般说起来做一个后台产品,就是将一项发生在线下的业务,搬到线上完成的这么一个事情。

对比线下手工导数据、微信钉钉私下沟通的麻烦,一项业务通过系统,在各个角色之间快速流转,通过各环节的进度和数据的实时同步,提升沟通和操作的效率,同时通过生成、导出各类表单、统计表等功能,减少业务方手工的工作量,进而对整个业务本身的效率提升。这一点是作为中台部分的核心价值,以效率为导向,在满足“用户需求”这个方向上的作用。

2. 通过标准流程,实现公司管理方式的标准化,并保证业务数据的准确性

将一项业务从线下搬到线上的基础是流程本身的标准化。将标准化的业务流程和规则在线上实现后,能让所有人都按照这一套统一的规则去做业务,实现平台化管理,避免各种“人治”的人工管理。

在此过程中,保证流程涵盖所有的业务,能支持意外情况的处理,并且做到流程中所有的业务数据准确,包括财务数据、订单数据、库存数据等。

这一点以平台化管理为导向,体现在后端流程方面。一般规模较大的互联网公司都会实现平台化管理,后台系统的流程会作为管理的基础。但要做到涵盖所有业务、业务数据百分百准确,并不是一项简单的事情,只要业务流程没有完全闭环,留下了人工操作的入口,就可能造成数据的不准确。

发掘数据的价值,反过来对做到业务的驱动和提升

在做到基础流程的支持和效率的提升之后,后台产品真正能为业务带来实质性提升的地方,在于数据的挖掘和分析。这里的数据分析不是简单的数据统计展示,而是在决策环节,结合各项业务数据进行智能计算、自动化调配,提升业务决策的准确度并加快时效,最终对业务本身带来提升。在决策性的环节,算法的准确度一定是比人脑要高的。

这一点是以数据为导向,需要各环节的业务数据作为基础。数据算法有一定高度后就属于策略领域,会有专门的产品经理做策略算法。不过普通的后台产品,在很多环节中同样少不了数据的挖掘和分析,而且这一点的价值能够直接通过业务的发展数据来体现。

以我接触过的电商供应链系统的采购模块为例,看下这三大价值具体体现在哪些地方。我刚接手采购模块的时候,我们的系统只有一个采购入库单的页面和入库操作,只能实现人工把库存数据入准确这一个事情。开始做这块之后,我根据以上思路开始思考上线系统后对业务有哪些实质上的提升。

首先,通过将整个采购流程在线上实现,可以节省采购人员、仓管、供应商、质检等多个角色之间的进度同步和效率提升,比如说供应商发货后仓库能及时收到发货信息的同步,再比如采购能在仓库清点完货后第一时间看到收货的情况,然后找供应商要剩余未发的货等等。这样比之前只能通过线下沟通到最后才录一个入库单要效率高得多。

然后,在实现了采购主流程、采购价格管理规则、质检流程后,可以保证每个货品的采购成本数据和库存数据准确,不再像之前一样只靠人工输入数字,一旦输错了会直接影响到计算订单成本的财务数据,和一系列出入库的库存数据。

当系统运转起来,到第二个阶段,我们可以通过积累的各项过程数据对供应商进行评估,比如在制定采购计划的操作中,根据采购数据计算出供应商良品率、供应商发货满足率,根据订单数据计算库存预计消耗量,智能计算出推荐的采购数量和供应商的选择方案,最终提升采购的满足率和时效性。

每个不同领域的后台产品的核心和方向都不一样,但总体而言,除了我们常说的用户需求,后台产品的价值都可以从这三个方向引申出去。

二、电商、O2O公司会有哪些后台产品

对于电商、O2O等交易型的互联网公司来说,后台系统是支撑业务运营的核心产品。

以我所在的一家自营模式的O2O公司为例:

我们的业务模式,是用户下单后,系统指派给上门服务人员,相应的人员领取仓库的商品,上门到用户家里完成服务,在各个城市有门店作为上门服务人员的调度中心和库存的中转站。

我们的产品后台体系,需要提供整个订单流转的流程支持、库存进销存业务、人员的指派调度上门、以及线上线下运营推广规则的支持。

后台产品架构大致如下:

1. 订单系统

汇总各种类型、来自不同平台的用户订单,处理订单从下单到完结正向流程,以及售后退款的逆向流程。订单系统是整个对用户服务体系最基本的支持;

订单系统属于后端的业务逻辑,作为中台、客服工单、上门服务人员的终端等其他产品做订单各类操作的底层支持。

比如我所在公司,一个订单的基本流程为用户下单、系统指派、客服联系用户、上门人员接单并上门服务、用户付款完结订单,在这个流程中,多个角色在各个环节中的各项基本操作和延伸服务,都需要通过订单的逻辑进行。

2. 供应链系统

所有商品进销存的业务,处理一个库存从采购入库、仓库间调拨、物流配送,直到用户手上的整个生命周期,以及仓库的周转、盘点、售后等各项库存管理服务;供应链系统以库存和资金的流转为中心,是公司成本管控的核心。我

在现在的公司做过供应链系统,供应链直接涉及到公司的重资产,因此库存和财务数据的准确性通常会作为系统的第一目标,而非用户需求。而且供应链涉及到采购、仓管、质检、物流等多个环节,业务流程比较复杂,梳理清楚并不容易。

3. 商品系统

作为平台商品结构的体系,用户下单时选类目、选SKU、选规格尺寸,就是来自于商品系统的支持。商品系统本身的东西不多,不过也是底层逻辑的一部分。

4. 运营系统

用于平台日常线上的运营,包含折扣、促销、线上活动、拼团、分销等各类优惠的支持,和针对C端用户的会员管理体系;
每个互联网公司都有产品运营,运营承担着互联网公司直接获取用户和订单的作用,是直接背KPI的,所以运营系统的好坏直接影响平台用户量、订单量和交易额。

5. 线下网点的中台系统

很多O2O、新零售领域、或者自建物流的电商公司,都会在线下设置几个网点,作为作为一片区域内人员和物流调度中心。这个概念不一定看得懂,如果我说门店就比较好理解了。

我所在的公司有自己的上门服务团队,由每个线下网点独立管理自己区域内的订单、上门服务人员和库存,因此我们做了一个中台系统,用于上门人员的指派调度和工作统计,订单的各类操作、用户到店订单、售后等业务的处理,库存配送的中枢。

这个系统属于操作层面的,核心在于两点,提高订单的完成效率和服务质量,以及实现对人员和业务的标准化管理机制。

6. 客服工单系统

作为客服处理客户咨询、投诉、售后、回访等业务的系统支持。客服工单和中台都是属于系统的操作层面,以订单系统为基础,针对客服的各项日常业务,通过工单流转规则提升客服的工作效率,继而提升面向用户服务的效率。

7. 统计系统

提供所有业务数据的统一计算口径和出口,包括订单数据、库存数据、成本收入数据、页面转化数据等。

具体每个系统的业务流程和功能模块就不在这里赘述了。

可以看到,以上后台产品对公司业务的作用,不仅作为基本的数据业务支持,还对实际的业务效率有着不少的提升。

当然,以上的这些只是电商或者O2O行业中比较常见的后台产品,还有些其他常见的后台产品,比如面向B端客户服务的CRM系统,面向财务人员的财务系统,供应链的一部分、电商行业配送方向的物流系统等。具体的后台产品定位和架构,在不同行业、不同公司也会不一样。

#专栏作家#

潘帕斯雄鹰,人人都是产品经理专栏作家,进击、踩坑中的产品狗一枚,关注互联网,写过小说,看过哲学。简书:潘帕斯雄鹰。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash ,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 对于中台和后台的解释,笔者的说法和BAT的观点貌似是相反的。

    另外,价值观体现中,业务创新(拓展)和质量提升(补坑)也是非常重要的哈~

    来自广东 回复
  2. 作者您好,这篇文章我可以在公众号转发一下吗,觉得您写的非常好~期待回复

    来自北京 回复
  3. 后台产品和用户端一样也有目标用户,而且用户是固定的,对于企业内部的后台系统来说,用户就是公司内部某个部门的人。他们的需求比广义上用户的需求明确的多,通常他们的需求就是公司实际业务上的事情。

    实际上,后台产品的【目标用户】可以看成【客户】和【使用者】
    【客户】是需要后台产品解决问题的人,可以是企业,也可以是个体户,也可以是普通人,他们会为【后台产品】付费,但不一定直接操作,较为关注解决问题的能力,和产出的能力;
    【使用者】是操作后台产品解决问题的人,可以是企业员工,也可以是个体户,也可以是普通人,他们不为【后台产品】付费,却是直接操作者,较为关注使用体验;

    而后台产品需要解决的是这两者的需求,【客户】的需求是最高优先级也最根本的,但是通过支持【使用者】的需求有时候可以更好的解决【客户】的需求;

    当区分出这二者,对于【目标用户】就可以更客观的理解,不用非此即彼了。

    感谢分享,也发表一下愚见;

    来自广东 回复
  4. 建议提升美观度、科技感

    来自浙江 回复
  5. 小公司也会有很健全的后台

    来自上海 回复
  6. 作为同道,觉得不错

    来自广东 回复
  7. 不错,对于B端和C端客户所处的角度不一样

    来自广东 回复
  8. 三大价值体现,表示很认同~

    来自广东 回复