电商O2O后台产品漫谈——后台产品的需求对接和产品设计

互联网技术产品行业，可以大致地分成前台接待产品和后台管理产品。前台接待产品就是C端的产品，后台管理产品可以大致地归纳为各种各样智能管理系统。

大家常说的C端产品使用价值就在于满足客户需求、提高客户体验，后面产品彻底不一样，第一要义是对业务的大力支持和提高，根据业务实际操作和统计数据的网上化，来规范化业务管理方法流程、提高业务运行高效率，及其挖掘数据信息的使用价值，从而在各阶段危害到公司的成本费用和收益。这针对主营业务业务为电子商务、O2O等其他方式买卖的公司而言至关重要。四五年前，当互联网技术还处在网上产品为主导的环节，业界要说有很多企业不重视后台管理。但目前互联网技术各领域各种线下推广服务项目早就五花八门，都9012年了，假如也有觉得后台管理产品的使用价值低于产品的企业，可以破产倒闭了。

我自己在小公司干了一段时间的企业内部结构终端软件，汇总出了一部分有关后台管理产品的自身工作经验。文中可分为六个一部分，按后台管理产品设计过程的次序，分别是后台管理产品有什么作用、有什么后台管理产品、业务需求如何连接、产品自身怎么设计、怎样发布和怎样跟进应用状况。这也是第二篇，上篇写了些较为虚的产品总体目标和功效，这篇从实际工作职责考虑，写业务需求连接和产品设计方案这两层面的感受和体会心得。

后台管理产品服务项目于业务，在产品需求调查的环节，后台管理产品主管要做的事儿和做C端产品当然有差别。C端端产品通常是根据各类方式去触碰客户、发掘消费者的需求，面对B端顾客的产品也类似，仅仅调查目标变成了B端客户。而面对企业内部的后面支撑点产品，需求调查的具体形式是与所说的“业务方”开展业务需求的连接。这一业务方，指的也是企业别的单位的人，例如做物流管理系统，就需要找供应链管理单位的采购、统计员连接需求，例如做CRM系统软件，销售市场单位便是业务方。这一节关键写需求连接层面的问题，实际的需求调查和剖析也不扩展了。

在我刚做后台管理产品的情况下，我一直有一个困惑。大家的需求才是很明确的那几个人，大家的产品只需面对她们服务项目，那大家做的岂不便是明确的需求，只需她们说哪些，大家干什么就可以了？在各种各样需求连接的情况下，业务方通常会直接说你给我一个什么什么作用，大家按她说的做，不就早已达到需求了？

之后我慢慢发觉，业务方指出来的实际需求不一定是有效的。虽然大家做的系统软件是给他用的，但产品需求的立足点大量是立在企业业务的视角，考虑到对系统业务的使用价值，流程是不是有效，这种是要由大家产品去整体规划的，而不只是作用用着如何。也有，业务方并不一定掌握产品能为他们产生哪些，她们明确提出要什么作用，并不一定能处理她们真实的需求目地。

这一产品主管自身的工作能力有关系，在初级环节，由于自身能力有限，会逗留在接受需求并实行的环节，但水准提升后，便会了解怎样做更有效，慢慢去整体规划全部产品。因而，除开一些小细节的小作用非常简单，立即做就可以了，一旦牵涉到全部业务控制模块的需求，一定是由产品主管核心，掌握到业务自身，随后给业务方规范化的流程，告知她们如何使用，并不一定要依照她们说的做，要不然做出的很可能不容易是有效的计划方案，业务其术只能觉得产品主管仅仅个重装系统的。

但是我就见到有一些大神说，面对企业里面的产品主管发展趋势的空间比较有限，终究客户太少，明确的需求多，在工程项目中业务方的必要性更高一些，的确无法像做C端或是服务平台的产品主管那般能主宰者一个新项目。这样的事情多多少少存有，这个问题只有说仁者见仁，智者见智吧。

业务连接不比发掘C端客户的需求非常容易是多少，这一环节中一样会发生多种多样的问题。尤其是当我们的业务方并不是做网络的，那麼在需求连接的过程中的确有一定摩擦阻力。我还在目前这个企业，业务聚瑞就会有很多人是以传统产业回来，习惯性用excel工作中、系统对并没有任何定义的人。在我与业务方连接需求的全过程，发生过下列那些状况：

第一，业务方不一定了解后台管理产品的价值是什么，能给业务自身产生哪些提高，她们很有可能只了解业务数据信息和实际操作要在操作系统上开展，比手工制作更便捷一些；

第二，有的人习惯在传统产业用excel工作中，系统对的掌握会逗留在纪录和查找的功效。她们提的需求，通常会提一个主要的作用，你如果不谈就不容易说实际的目地。例如真正目地是要做一项数据分析，但提过来的需求仅仅某一网页页面加个导出来作用，或是某一目录加个哪些字段名之类的；

第三，业务方通常会走到自身实际操作的视角提需求，不一定会关心产品宏观经济层次的使用价值、业务流程的规范化、规范化管理的问题等。尤其是立即电脑操作系统的人，她们提的较多的便是实际的作用，怎样便捷她们实际操作，会发生有一些作用不可以按她们说的做，但她们不理解；

第四，业务方不一定有迭代思维，认为产品发布和传统式公司的交货一样，一次性做完产生终版随后给他用。产品从0到1的历程大家会整体规划MVP，先发布基本要素并不断梯度下降法，但她们看过要说这一怎么没有我想的什么什么作用，一定要等大家把她们要的都做完了再逐渐应用；

第五，有时一个事儿习惯会不易更改，倘若大家出自于管理方法上的目标必须梯度下降法一些实际操作，更改的她们平常线下推广的使用习惯性，她们也许会抵触，反倒说我已经有方法解决这种问题了，不理解大家为什么也要去改这种作用。

自然，这种状况不肯定，仅仅有可能会碰到在其中的一部分问题。在经历了诸多个业务连接以后，对于业务连接此项需求搜集方法，我汇总出了几个方面可以当做参照的方法：

第一，选准业务方的人。别小瞧这一点，有感受了就了解请人很重要的。例如一个单位里，下边的人更掌握业务，但通常只是立在自身实际操作的视角考量问题。单位管理者能决策事儿，也通常了解系统软件要干什么，但对业务流程的关键点不一定熟，也不一定有时间与你对需求。再例如，同一个单位的业务方，有的人对各种互联网技术产品较为掌握，最少会对你说他以前使用过的系统软件是怎样的，另一些人便会更传统产业一点，或许前一个人半小时就能对清晰的需求，后一个人得和他讲俩钟头。我迄今记得我触碰的一个系统软件从0的发展情况下，跟第一个业务责任人一个月开4次会，到最终另一方仍在担心为什么不买一个系统软件，下面换业务责任人以后，开2次会议后新项目立即成功运行；

第二，听他们说，但不必对着做。这一点和大家看待客户需求的心态一样，从她们说的得加XX作用的身后，掌握到她们需求的实质，随后想一种更快的方法达到这些人的需求，而且可以立即告知业务方大家计划方案，及其那样做的益处，坚信她们并不会回绝；

第三，多进行到具体的业务中去，了解业务方日常的工作中，怎样开展工作，系统软件上关心的点，最好是立即协助业务方做一天的体系实际操作，乃至可以加入到她们的业务总体目标、大会、KPI这种行业中去。这一点也和大家看待客户需求一样，但比了解客户需求要难的多，由于一般C端的客户需求门坎低，而业务但是真真切切的专业技能，有专业门坎的。例如做为物流管理系统的产品主管，要深层次仓储物流的业务，就需要掌握统计员工作人员管理仓库的主要发展目标，什么叫存货周转率，库存成本费的测算标准，安全性库存有什么作用、怎么计算，需求预测分析有什么作用、怎么计算等物流信息管理方面的专业技能。如果不深层次业务，即使去帮业务方电脑操作系统，也只有看见一些互动方面的小问题。

最终一点，和业务方终究是真人版零距离沟通交流，因此只需加强沟通，告知她们大家产品的使用价值，大家每一个计划方案为什么要那么做，每片业务大家会如何去梯度下降法，许多问题当然会得到解决。

总算到了产品主管充分发挥的主阵地，产品设计方案阶段。在我们确立了产品总体目标，进行业务需求的连接后，下面就逐渐开展产品计划方案的设计方案。有别于C端产品，后面产品设计方案的核心取决于业务逻辑性和流程，次之是实际操作高效率感受，前面页面几乎是最主次的一部分。我最初做后台管理的情况下，认为和C端一样只必须画原形，附加一点流程图就可以了，随后发觉原形压根找不到方向。之后，我汇总出了十个流程，做为自己做后面产品设计的方法。这种流程是以较为完善的方向设计方案一个业务控制模块，一般的一小个网页页面或流程，可以省去正中间两步。

在这里以我触碰过的一个电子商务/O2O行业的物流管理系统为例子，叙述一下从0到1设计方案体系的采购控制模块必须怎样开展。

1）明确业务名词的定义；

这也是第一步，先要了解大家将要做的是一个什么，及其此项业务中会涉及什么业务专有名词，她们在具体业务中代表什么意思，与在系统软件中怎样界定。假如系统软件沒有，那必须从0逐渐界定。例如在物流管理系统中，只是是和库存有关的词就会有可以用库存、在途库存、冻洁库存、优品、欠佳品、废料、仓库、作业区、储位这些，假如一开始不理解清晰，后边便会一脸懵逼。

2）明确此项业务中参加的工作人员人物角色；

根据和业务方的连接，明确有什么不一样的人物参加到了此项业务中，每一个人物角色做什么事情，并确定不一样人物角色中间管理权限的界限，防止出现岗位职责错乱。这一阶段看起来简易，但必须在连接业务需求的过程中就考虑到清晰。除此之外，有一些人物角色的加入很有可能会涉及别的产品线，这样的事情下要在其他软件中同歩此项业务。

在这儿引进UML图，实际界定自主百度搜索。UML图我所知晓的许多企业也不规定画这一，但可以做为产品主管在后台管理产品设计过程中的协助。在这里一步可以产出率UML中的用例图。

举例说明，在物流管理系统的采购业务中，会涉及的人物角色如下所示：采购工作人员，承担采购提交订单，跟进经销商，记账清算；库存统计员，承担测算库存需求预测分析并递交采购申请办理；经销商，承担接纳采购单开展安排发货；统计员工作人员，承担取货进库；质量检测工作人员，承担对采购的产品产品质量检验；财会人员，承担依据信用卡账单汇款。这在其中，因为会计的参加，必须将采购清算信息内容同歩至财务管理系统。

3）整理全部业务的关键流程；

核心流程是一整块业务中那好多个关键的阶段，明确了人物后，可以将关键业务阶段依照正方向流程画出去。这儿的流程图无需尤其细，只画关键步骤，即关键事宜的迈向，并标出事宜的人物角色。实际的分辨、转变、出现异常等后边再讲。

下面的图为采购业务的关键流程图：

4）依据关键流程整理关键数据信息的流动性标准；

这一步是关键。在电子商务、O2O等买卖型的企业中，订单信息、库存、成本费、收益这种便是关键数据信息。实际上流程自身不会太难整理，关键业务数据信息才算是系统软件数据信息恰当的确保。这一步必须梳理全部流程中什么数据信息会发生转变，各自在哪个阶段产生，怎样加如何减，实际数据多少钱，测算标准又是啥，以后的阶段又运转到哪里。

例如物流管理系统，关键取决于库存流和现金流，因此每一个流程都必须确立这两个数据信息，库存的进库、出入库、冻洁、在途都是啥标准，在哪儿一步产生；每一次进库出入库时库存的额度多少钱，收益和开支又如何计算。在采购控制模块中，最先是库存，通常是将最后一步进库做为库存提升的阶段。也有一种计划方案是取货阶段库存提升且冻洁，进库时将冻洁库存转换为可以用库存，质量检测不过关退换货的则冻洁库存降低。随后是资产，采购流程牵涉到二点，一是进库的库存计算成本标准，普遍的是将现阶段采购价做为库存成本费，除此之外也有加权平均法等方法，这儿也不进行了。二是采购清算额度的开支，相当于每批号进库库存总数的采购价钱总金额。

以上阶段的信息明确后，可以进行找业务方开展第一轮审查，核查基本上的业务流程和标准。进行确定后，下面的事情便是逐渐优化。

5）细化流程，整理每一个流程连接点的具体步骤和流程连接点间的迈向；

这一步是把流程优化，将前边整理的关键流程依据具体业务状况拓展，明确每一个流程有什么实际操作，每一个使用的前提条件和后置摄像头标准是啥，流程中间是怎样运转的，及其各种各样异常现象和处理方法。这一流程可以产出率详细的流程图。

采购业务的流程关键点也不写了，进行的流程图如下所示：

6）明确全部流程中有哪些实体线种类，和每一个实体线种类包括的字段名；

实体线种类可以解释为业务上的一个订单、批号，或是数据信息上必须开展增删实际操作的一条纪录。优化流程后早已确认了各个阶段要实际操作哪些，下面梳理全部流程控制模块中有什么实体线种类，及其每一个实体线种类里有实际什么关键字段名。

这一步和下一步要明确的关联性，自身的功效是以后面产品研发的方向去设计方案数据信息的根本构造，这二步可以产出率UML图中的类图。虽然类图不一定要画，但是做为后台管理产品主管，明确实体线种类的含义就在于根据掌握后台管理构造和关联来整理业务逻辑性，梳理全部业务的后面构造，并做为以后实际网页页面构造和实际操作设计的基本。

返回采购系统软件的实例中，在采购流程中可以整理出这好多个实体线种类和关键字段名：

采购审批单（库房、采购授权量），采购单（库房，经销商，采购量），采购收货单（库房，经销商，安排发货批号，采购取货量），采购出入库单（库房，经销商，安排发货批号，采购进库量），采购发货单（库房，经销商，安排发货批号，采购退换货量）

7）明确各实体线种类中间的的关联性，和她们中间详细信息总数的关联；

有实体线种类以后，下面依据具体业务状况，明确每个实体线种类中间的关联性，一对一或是一对多，强关系或是弱关系。总数的关系比较好了解，在采购的实例中，根据一个采购申请单可以根据不同供应商创建多个采购单，那就是一对多；一个采购单可以多次发货，采购单和发货单也是一对多；一个采购收货单只能一次全部入库或退货，那就是一对一。注意不要有多对多就行了。

强弱的关联可以理解为某个实体是否一定要通过关联它的实体创建。比如采购单可以从采购申请单中创建，也可以单独创建，那就是弱关联；采购收货单一定要有采购单才能创建，采购入库单一定是收货单收货后才能入库，这两个不能凭空创建，所以是强关联。

详情数量指的是流程中核心数据的明细，比如供应链的各种入库出库数量、订单的各种金额等。事实上这些个数量即是实体中的一个字段，每个流程节点中的操作会随之产生数据，原则上后续的流程不能覆盖前面的数据，需要新建一个数据字段来记录，于是会有一大堆数据字段，他们之间存在具体的计算方式、关联规则，会直接关系到数据的准确性，需要按照实际业务情况确定。

采购流程中的数据字段前面已经写了，它们之间的关系，首先采购申请数量和实际采购数量，因为存在供应商无法满足和有不良品会退货的情况，采购量通常会大于采购申请量，这两者之间没有明确的关系；接下来是采购收货数量，由于供应商发货的不确定性，收货量和采购量也没直接关系；再是质检后的入库量和退货量，显然他们和收货数量就有严格的关系限制了，入库量+退货量=收货量。

这两步整理出来的类图如下（不过格式不标准，可以将就看下）：

8）设定页面架构；

明确实体关系之后，页面层级结构自然就出来了。通常来说后台页面的层级结构遵循两个原则，不同的实体类型需要划分为不同页面，以及不同角色需要划分到不同的页面。同一个角色和同一个实体，在一个页面中操作即可。此外，如果有需要把多条记录中的某类数据详情放一起列出来，然后大批量操作的功能，也需要独立到一个页面中实现，比如说如果需要多个采购单的库存一起入库，那就需要加一个库存列表页面，展示所有待入库的详细库存（当然实际业务上通常不需要）。后台产品的页面架构设计满足逻辑和操作即可，不会像C端产品那么精细。

9）确定每个页面的列表数据有哪几种状态；

页面设计的重点是不同列表各自的状态和操作。状态的作用是为了告诉用户当前的动态描述和需要进行的事项。状态的设置有三个参考因素，一个是流程中当前所处的环节需要做什么或者已经做了什么，我们常见的待XX，已XX就是根据基本流程梳理出来的；

二是操作的数量，存在有些环节无法直接通过流程判断状态，需要将操作的数量和总数量进行对比，得出状态。有些业务中会有先操作一部分数量的情况，比如采购收货时，可能只收了一部分，用户又需要了解到收货数量的情况，因此状态可以设计为部分收货、全部收货这两种。有些情况下完结也需要通过数量进行判定，主要是各类申请的满足情况，比如采购申请单，会关联多个采购单，采购申请数量和采购数量、收货数量之间由于不确定性，没有强关联关系，因此采购申请单的完结，只能用实际入库数量和采购申请数量做对比，数量都满足了状态再更新为完结。

三是和其他列表状态的同步更新。一个复杂的流程会涉及到多个实体的列表，每个列表都有各自的状态，某个列表状态变化后，需要根据用户实际情况，考虑其他列表是否要同步这个变化。比如采购流程中，收货、质检、入库都是基于采购收货单的操作，由仓库、质检进行，那么因为采购需要实时跟进这些信息，所以在被关联的采购单中就需要同步这些操作，显示全部收货、已质检、已入库这些状态。再比如采购申请单和采购单，由于采购申请单的角色是库存计划员，不需要跟进采购的情况，所以主流程只需要显示待采购、采购中、已完结这3个状态，不需要同步采购单的其他状态。

10）确定各状态下有哪些操作，如何进行；

操作是根据状态实时变动的，每个状态有它对应能做的操作。根据前面梳理的详细流程中每个操作节点，和用户在这个步骤中需要查看的信息，整理成操作和详情内容。具体操作包含通用的操作比如创建、编辑、删除、启用禁用、取消、回退；流程中的操作，比如发货、收货、入库、质检、退货、完结、审核通过不通过，将这些操作放到对应的状态中即可。

具体功能设计的时候，要考虑用户的操作效率，同一个操作可以针对多个场景设置不同的方式。比如一些大数据量的操作，除了正常的逐条操作，还可以增加批量操作、导入导出的功能；一些复杂的操作，可以设置为多个步骤；还有当需要填写很多表单信息的时候，可以帮用户默认填写。

最后三个步骤的结果考虑清楚后，原型自然就出来了。画完原型，产品设计阶段就大功告成了。

当然以上10个步骤看起来有点复杂，我见过很多人习惯于画完流程图后直接画原型，不需要详细考虑中间那么些个步骤。我自己有时候也会这样，因为一边画原型可以帮自己梳理思路，而且简洁明了。只是一旦遇到流程复杂的业务，如果中间的步骤不考虑清楚，那么原型改来改去会非常耗时间，所以还是一步步来比较好。

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