来，给你聊下后台

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

一、后台产品的作用

 

1. 用户需求的悖论

 

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

 

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

 

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

 

一段时间后，我产生了疑问：

 

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

 

但这意味着：他们说什么，我们做什么吗？

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

举个最简单的例子：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

后台产品架构大致如下：

 

 

1. 订单系统

 

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

 

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

 

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

 

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

 

用户下单

▼

系统指派

▼

客服联系用户

▼

上门人员接单并上门服务

▼

用户付款完结订单

 

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

 

2. 供应链系统

 

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

 

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

 

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

 

3. 商品系统

 

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

 

4. 运营系统

 

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

 

5. 线下网点的中台系统

 

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

 

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

 

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

 

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

 

6. 客服工单系统

 

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

 

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

 

7. 统计系统

 

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

 

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

 

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

 

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

 

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

 

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

 

原创： 潘帕斯雄鹰