本文以企业内部的后端支持系统为主要研究对象，分为六个部分，按后台产品设计过程的顺序，分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。
前台产品即是C端的产品，后台产品可以笼统地概括为各种管理系统；BAT等大公司还会把后台产品细分为两个部分：一个是纯后端部分，指的是业务流程、逻辑规则、数据结构部分，不涉及到界面；一个是中台部分，即提供内容展示、功能操作的可视化系统界面。
我们一般所说的后台产品，根据面向用户群体的不同还可以分为两类，一类是针对大企业内部，作为内部各个业务线的支持系统，常见的比如电商行业的商品管理系统、订单系统、供应链系统等，我把它概括为后端支持系统。
通常以交易或者实体业务为核心的互联网公司，比如电商、O2O、金融等方向，都会自己开发完整的后台系统用于支持业务；还有一类就是我们常说的To B 的saas系统，面向各行业的企业用户，通过某种商务合作，提供B端或者小B端产品给他们使用，比如现在各种行业中给线下机构、门店提供的管理系统，为大企业内部提供的ERP、OA系统，以及专门为特定企业定制化开发的系统，均属于此类。
本文以企业内部的后端支持系统为主。
我们常说的用户端产品价值在于满足用户需求、提升用户体验，后端产品完全不同，第一要义是对业务的支持和提升，通过业务操作和数据的线上化，来标准化业务管理流程、提升业务运转效率，以及发掘数据的价值，进而在各环节影响到公司的成本和收入。这对于主营业务为电商、O2O等任何形式交易的公司来说尤为重要。
四五年前，当互联网还处于线上产品为主的阶段，业内会说有很多公司不注重后台。但现在互联网各行业各类线下服务早已层出不穷，都8012年了，如果还有认为后台产品的价值小于前端产品的公司，可以倒闭了。
我本人在小公司做了一段时间的公司内部支持系统，总结出了一部分关于后台产品的个人经验。本文分为六个部分，按后台产品设计过程的顺序，分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。
本文并没有什么深度，适合小公司的产品经理或者没接触过后台的产品经理看看，也欢迎大公司的产品经理来批评指正。
1. 用户需求的悖论
从我做产品开始一直到现在，我都能在各个不同地方听到这句话：产品经理的核心价值在于满足用户需求。我们接手一款产品后，首先发现目标用户，然后通过种种手段挖掘用户的需求，通过功能界面等方式实现，满足用户需求。
刚做后台产品的时候，我也照着这句话，把我从后台产品的“用户”处收集到的需求一一实现；一段时间后我产生了疑问。
后台产品和用户端一样也有目标用户，而且用户是固定的，对于企业内部的后台系统来说，用户就是公司内部某个部门的人。他们的需求比广义上用户的需求明确的多，通常他们的需求就是公司实际业务上的事情。
但这意味着他们说什么，我们做什么吗？如果是这样，那产品经理在挖掘需求这方面的价值，不就很少了吗？
这里就遇到用户需求的悖论了；后台产品的目标到底是不是满足用户需求？
经过一段时间的产品经历下来，对这个问题，我自己做出了两点解释：
首先，所谓的“用户”不同。用户端产品是服务于C端个人用户的，满足用户需求是永恒的真理；而后台产品通常是面向B端，服务于公司的，因此后台产品第一要满足的是“公司”这个用户的需求，也就是业务需求，而不是狭义上使用产品的那些人的需求。
换句话说：公司层面的需求大于用户自身的需求。其中，面向B端企业的产品，服务对象是所处行业中的各个客户，企业内部的后台产品，服务对象就是自己公司。
举个最简单的例子：钉钉的“钉”功能，站在用户立场上被频繁骚扰很不爽，但站在企业客户的角度看，“钉”这个功能能提升企业员工间沟通的效率，有助于公司的管理，所以它解决了公司的需求，很多公司会为这个功能买单。
我做供应链系统的时候，经常遇到这样的问题，有些功能对公司的管理有作用，但对使用人来说，反而会加重他们的使用成本，让他们很不爽。但显然这样的功能不得不做，因为这些功能会为公司带来更大的价值。
比如我们要做的一物一码溯源体系，站在公司的角度能规范化管理和数据追踪，站在直接使用者的角度，大大加大了他们的人力和工作量，但结论是这肯定得做。
这就是我针对用户需求悖论的第二点解释：后台产品的价值和用户端产品不完全相同，“满足用户需求”只是其中一个目标，后台产品还有更大的作用。
我做后台产品的时候，一开始我只是接收一些具体要做的事情，比如我们要补全某某业务流程，比如要上线某某模块，然后开始做，中途不断和业务方撕逼后，做出来上线。
后来我想，做这些功能流程的目的是什么，尤其是有些东西业务方并不喜欢，我们为什么还要这么做。之后在产品过程中加了一个步骤，做每个需求之前，都必须和大家明确，这个事情的目标和价值在哪里。一段时间后我发现，这么些需求的目标和价值。
基本可以归纳为以下3个大方向：
1. 提升业务运转的效率，进而节省时间和成本
一般说起来做一个后台产品，就是将一项发生在线下的业务，搬到线上完成的这么一个事情。
对比线下手工导数据、微信钉钉私下沟通的麻烦，一项业务通过系统，在各个角色之间快速流转，通过各环节的进度和数据的实时同步，提升沟通和操作的效率，同时通过生成、导出各类表单、统计表等功能，减少业务方手工的工作量，进而对整个业务本身的效率提升。这一点是作为中台部分的核心价值，以效率为导向，在满足“用户需求”这个方向上的作用。
2. 通过标准流程，实现公司管理方式的标准化，并保证业务数据的准确性
将一项业务从线下搬到线上的基础是流程本身的标准化。将标准化的业务流程和规则在线上实现后，能让所有人都按照这一套统一的规则去做业务，实现平台化管理，避免各种“人治”的人工管理。
在此过程中，保证流程涵盖所有的业务，能支持意外情况的处理，并且做到流程中所有的业务数据准确，包括财务数据、订单数据、库存数据等。
这一点以平台化管理为导向，体现在后端流程方面。一般规模较大的互联网公司都会实现平台化管理，后台系统的流程会作为管理的基础。但要做到涵盖所有业务、业务数据百分百准确，并不是一项简单的事情，只要业务流程没有完全闭环，留下了人工操作的入口，就可能造成数据的不准确。
发掘数据的价值，反过来对做到业务的驱动和提升
在做到基础流程的支持和效率的提升之后，后台产品真正能为业务带来实质性提升的地方，在于数据的挖掘和分析。这里的数据分析不是简单的数据统计展示，而是在决策环节，结合各项业务数据进行智能计算、自动化调配，提升业务决策的准确度并加快时效，最终对业务本身带来提升。在决策性的环节，算法的准确度一定是比人脑要高的。
这一点是以数据为导向，需要各环节的业务数据作为基础。数据算法有一定高度后就属于策略领域，会有专门的产品经理做策略算法。不过普通的后台产品，在很多环节中同样少不了数据的挖掘和分析，而且这一点的价值能够直接通过业务的发展数据来体现。
以我接触过的电商供应链系统的采购模块为例，看下这三大价值具体体现在哪些地方。我刚接手采购模块的时候，我们的系统只有一个采购入库单的页面和入库操作，只能实现人工把库存数据入准确这一个事情。开始做这块之后，我根据以上思路开始思考上线系统后对业务有哪些实质上的提升。
首先，通过将整个采购流程在线上实现，可以节省采购人员、仓管、供应商、质检等多个角色之间的进度同步和效率提升，比如说供应商发货后仓库能及时收到发货信息的同步，再比如采购能在仓库清点完货后第一时间看到收货的情况，然后找供应商要剩余未发的货等等。这样比之前只能通过线下沟通到最后才录一个入库单要效率高得多。
然后，在实现了采购主流程、采购价格管理规则、质检流程后，可以保证每个货品的采购成本数据和库存数据准确，不再像之前一样只靠人工输入数字，一旦输错了会直接影响到计算订单成本的财务数据，和一系列出入库的库存数据。
当系统运转起来，到第二个阶段，我们可以通过积累的各项过程数据对供应商进行评估，比如在制定采购计划的操作中，根据采购数据计算出供应商良品率、供应商发货满足率，根据订单数据计算库存预计消耗量，智能计算出推荐的采购数量和供应商的选择方案，最终提升采购的满足率和时效性。
每个不同领域的后台产品的核心和方向都不一样，但总体而言，除了我们常说的用户需求，后台产品的价值都可以从这三个方向引申出去。
对于电商、O2O等交易型的互联网公司来说，后台系统是支撑业务运营的核心产品。
以我所在的一家自营模式的O2O公司为例：
我们的业务模式，是用户下单后，系统指派给上门服务人员，相应的人员领取仓库的商品，上门到用户家里完成服务，在各个城市有门店作为上门服务人员的调度中心和库存的中转站。
我们的产品后台体系，需要提供整个订单流转的流程支持、库存进销存业务、人员的指派调度上门、以及线上线下运营推广规则的支持。
1. 订单系统
汇总各种类型、来自不同平台的用户订单，处理订单从下单到完结正向流程，以及售后退款的逆向流程。订单系统是整个对用户服务体系最基本的支持；
订单系统属于后端的业务逻辑，作为中台、客服工单、上门服务人员的终端等其他产品做订单各类操作的底层支持。
比如我所在公司，一个订单的基本流程为用户下单、系统指派、客服联系用户、上门人员接单并上门服务、用户付款完结订单，在这个流程中，多个角色在各个环节中的各项基本操作和延伸服务，都需要通过订单的逻辑进行。
2. 供应链系统
所有商品进销存的业务，处理一个库存从采购入库、仓库间调拨、物流配送，直到用户手上的整个生命周期，以及仓库的周转、盘点、售后等各项库存管理服务；供应链系统以库存和资金的流转为中心，是公司成本管控的核心。我
在现在的公司做过供应链系统，供应链直接涉及到公司的重资产，因此库存和财务数据的准确性通常会作为系统的第一目标，而非用户需求。而且供应链涉及到采购、仓管、质检、物流等多个环节，业务流程比较复杂，梳理清楚并不容易。
3. 商品系统
作为平台商品结构的体系，用户下单时选类目、选SKU、选规格尺寸，就是来自于商品系统的支持。商品系统本身的东西不多，不过也是底层逻辑的一部分。
4. 运营系统
用于平台日常线上的运营，包含折扣、促销、线上活动、拼团、分销等各类优惠的支持，和针对C端用户的会员管理体系；
每个互联网公司都有产品运营，运营承担着互联网公司直接获取用户和订单的作用，是直接背KPI的，所以运营系统的好坏直接影响平台用户量、订单量和交易额。
5. 线下网点的中台系统
很多O2O、新零售领域、或者自建物流的电商公司，都会在线下设置几个网点，作为作为一片区域内人员和物流调度中心。这个概念不一定看得懂，如果我说门店就比较好理解了。
我所在的公司有自己的上门服务团队，由每个线下网点独立管理自己区域内的订单、上门服务人员和库存，因此我们做了一个中台系统，用于上门人员的指派调度和工作统计，订单的各类操作、用户到店订单、售后等业务的处理，库存配送的中枢。
这个系统属于操作层面的，核心在于两点，提高订单的完成效率和服务质量，以及实现对人员和业务的标准化管理机制。
6. 客服工单系统
作为客服处理客户咨询、投诉、售后、回访等业务的系统支持。客服工单和中台都是属于系统的操作层面，以订单系统为基础，针对客服的各项日常业务，通过工单流转规则提升客服的工作效率，继而提升面向用户服务的效率。
7. 统计系统
提供所有业务数据的统一计算口径和出口，包括订单数据、库存数据、成本收入数据、页面转化数据等。
具体每个系统的业务流程和功能模块就不在这里赘述了。
可以看到，以上后台产品对公司业务的作用，不仅作为基本的数据业务支持，还对实际的业务效率有着不少的提升。
当然，以上的这些只是电商或者O2O行业中比较常见的后台产品，还有些其他常见的后台产品，比如面向B端客户服务的CRM系统，面向财务人员的财务系统，供应链的一部分、电商行业配送方向的物流系统等。具体的后台产品定位和架构，在不同行业、不同公司也会不一样。
