欢迎光临
我们一直在努力

来,给你聊下后台

11511548332659 .pic hd 来,给你聊下后台

 

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

 

前台产品即是C端的产品,后台产品可以笼统地概括为各种管理系统;BAT等大公司还会把后台产品细分为两个部分:

 

  • 纯后端部分,指的是业务流程、逻辑规则、数据结构部分,不涉及到界面;
  • 中台部分,即提供内容展示、功能操作的可视化系统界面。

 

我们一般所说的后台产品,根据面向用户群体的不同还可以分为两类:

 

一类是针对大企业内部,作为内部各个业务线的支持系统。常见的比如电商行业的商品管理系统、订单系统、供应链系统等,我把它概括为后端支持系统。

 

通常以交易或者实体业务为核心的互联网公司,比如电商、O2O、金融等方向,都会自己开发完整的后台系统用于支持业务。

 

还有一类就是我们常说的To B 的saas系统。面向各行业的企业用户,通过某种商务合作,提供B端或者小B端产品给他们使用。

比如现在各种行业中给线下机构、门店提供的管理系统,为大企业内部提供的ERP、OA系统,以及专门为特定企业定制化开发的系统,均属于此类。

 

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

 

我们常说的用户端产品价值在于满足用户需求、提升用户体验,后端产品完全不同。

 

第一要义是对业务的支持和提升——通过业务操作和数据的线上化,来标准化业务管理流程、提升业务运转效率,以及发掘数据的价值,进而在各环节影响到公司的成本和收入。

 

这对于主营业务为电商、O2O等任何形式交易的公司来说尤为重要。

 

四五年前,当互联网还处于线上产品为主的阶段,业内会说有很多公司不注重后台。

 

但现在互联网各行业各类线下服务早已层出不穷——都9102年了,如果还有认为后台产品的价值小于前端产品的公司,可以倒闭了。

 

我本人在小公司做了一段时间的公司内部支持系统,总结出了一部分关于后台产品的个人经验。

 

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

 

一、后台产品的作用

 

1. 用户需求的悖论

 

从我做产品开始一直到现在,我都能在各个不同地方听到这句话:产品经理的核心价值在于满足用户需求。

 

我们接手一款产品后,首先发现目标用户,然后通过种种手段挖掘用户的需求,通过功能界面等方式实现,满足用户需求。

 

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

 

一段时间后,我产生了疑问:

 

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

 

但这意味着:他们说什么,我们做什么吗?

 

如果是这样,那产品经理在挖掘需求这方面的价值,不就很少了吗?

 

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

 

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

 

首先,所谓的“用户”不同。

 

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

 

换句话说:公司层面的需求大于用户自身的需求。

 

其中,面向B端企业的产品,服务对象是所处行业中的各个客户,企业内部的后台产品,服务对象就是自己公司。

 

举个最简单的例子:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

一段时间后我发现:这么些需求的目标和价值,基本可以归纳为以下3个大方向:

 

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

 

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

 

对比线下手工导数据、微信钉钉私下沟通的麻烦,一项业务通过系统,在各个角色之间快速流转,通过各环节的进度和数据的实时同步,提升沟通和操作的效率,同时通过生成、导出各类表单、统计表等功能,减少业务方手工的工作量,进而对整个业务本身的效率提升。

 

这一点是作为中台部分的核心价值,以效率为导向,在满足“用户需求”这个方向上的作用。

 

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

 

将一项业务从线下搬到线上的基础是流程本身的标准化

 

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

 

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

 

这一点以平台化管理为导向,体现在后端流程方面。一般规模较大的互联网公司都会实现平台化管理,后台系统的流程会作为管理的基础。

 

但要做到涵盖所有业务、业务数据百分百准确,并不是一项简单的事情——只要业务流程没有完全闭环,留下了人工操作的入口,就可能造成数据的不准确。

 

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

 

在做到基础流程的支持和效率的提升之后,后台产品真正能为业务带来实质性提升的地方,在于数据的挖掘和分析。

 

这里的数据分析不是简单的数据统计展示,而是在决策环节,结合各项业务数据进行智能计算、自动化调配,提升业务决策的准确度并加快时效,最终对业务本身带来提升。

 

在决策性的环节,算法的准确度一定是比人脑要高的。

 

这一点是以数据为导向,需要各环节的业务数据作为基础。数据算法有一定高度后就属于策略领域,会有专门的产品经理做策略算法。

 

不过普通的后台产品,在很多环节中同样少不了数据的挖掘和分析,而且这一点的价值能够直接通过业务的发展数据来体现。

 

以我接触过的电商供应链系统的采购模块为例,看下这三大价值具体体现在哪些地方:

 

我刚接手采购模块的时候,我们的系统只有一个采购入库单的页面和入库操作,只能实现人工把库存数据入准确这一个事情。

 

开始做这块之后,我根据以上思路开始思考上线系统后对业务有哪些实质上的提升。

 

首先,通过将整个采购流程在线上实现,可以节省采购人员、仓管、供应商、质检等多个角色之间的进度同步和效率提升。

 

比如说供应商发货后仓库能及时收到发货信息的同步,再比如采购能在仓库清点完货后第一时间看到收货的情况,然后找供应商要剩余未发的货等等。

 

——这样比之前只能通过线下沟通到最后才录一个入库单要效率高得多。

 

然后,在实现了采购主流程、采购价格管理规则、质检流程后,可以保证每个货品的采购成本数据和库存数据准确。

 

不再像之前一样只靠人工输入数字,一旦输错了会直接影响到计算订单成本的财务数据,和一系列出入库的库存数据。

 

当系统运转起来,到第二个阶段,我们可以通过积累的各项过程数据对供应商进行评估。

 

比如在制定采购计划的操作中,根据采购数据计算出供应商良品率、供应商发货满足率,根据订单数据计算库存预计消耗量,智能计算出推荐的采购数量和供应商的选择方案,最终提升采购的满足率和时效性。

 

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

 

二、不同公司会有哪些后台产品

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

 

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

 

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

 

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

 

后台产品架构大致如下:

11501548332484 .pic hd 来,给你聊下后台

 

 

1. 订单系统

 

汇总各种类型、来自不同平台的用户订单,处理订单从下单到完结正向流程,以及售后退款的逆向流程。

 

订单系统是整个对用户服务体系最基本的支持.

 

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

 

比如我所在公司,一个订单的基本流程为:

 

用户下单

系统指派

客服联系用户

上门人员接单并上门服务

用户付款完结订单

 

在这个流程中,多个角色在各个环节中的各项基本操作和延伸服务,都需要通过订单的逻辑进行。

 

2. 供应链系统

 

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

 

我在现在的公司做过供应链系统,供应链直接涉及到公司的重资产,因此库存和财务数据的准确性通常会作为系统的第一目标,而非用户需求。

 

而且供应链涉及到采购、仓管、质检、物流等多个环节,业务流程比较复杂,梳理清楚并不容易。

 

3. 商品系统

 

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

 

4. 运营系统

 

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

 

5. 线下网点的中台系统

 

很多O2O/新零售领域或者自建物流的电商公司,都会在线下设置几个网点,作为作为一片区域内人员和物流调度中心。

 

——这个概念不一定看得懂,如果我说门店就比较好理解了。

 

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

 

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

 

6. 客服工单系统

 

作为客服处理客户咨询、投诉、售后、回访等业务的系统支持。

 

客服工单和中台都是属于系统的操作层面,以订单系统为基础,针对客服的各项日常业务,通过工单流转规则提升客服的工作效率,继而提升面向用户服务的效率。

 

7. 统计系统

 

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

 

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

 

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

 

当然,以上的这些只是电商或者O2O行业中比较常见的后台产品,还有些其他常见的后台产品。

 

比如面向B端客户服务的CRM系统,面向财务人员的财务系统,供应链的一部分、电商行业配送方向的物流系统等。

 

具体的后台产品定位和架构,在不同行业、不同公司也会不一样。

 

原创: 潘帕斯雄鹰

 

赞(0)
未经允许不得转载:电商之家 » 来,给你聊下后台

登录

找回密码

注册