电商O2O后台产品漫谈——后台产品的需求对接和产品设计
互联网产品领域一般可分为前台产品和后台产品。前台产品是C后台产品可以概括为各种管理系统。
我们常说的C终端产品的价值在于满足用户的需求，提高用户体验，后端产品完全不同，第一个本质是支持和改进业务，通过业务运营和数据在线，标准化业务管理流程，提高业务运营效率，探索数据的价值，然后影响公司的成本和收入。这是电子商务的主要业务，O2O任何形式的交易公司都尤为重要。四五年前，当互联网仍处于在线产品阶段时，业内人士会说，许多公司不关注背景。但现在互联网行业的各种线下服务已经源源不断地涌现出来，已经是9012年了。如果有公司认为背景产品的价值低于产品，它就可以关闭。
我在一家小公司做了一段时间的内部支持系统，总结了一些关于背景产品的个人经验。本文分为六个部分。根据背景产品设计过程的顺序，分别是背景产品的用途、背景产品的用途、业务需求的对接、产品本身的设计、如何在线以及如何跟进使用。这是第二篇文章。最后一篇文章写了一些虚拟的产品目标和功能。本文从具体工作内容出发，撰写了业务需求对接和产品设计的经验和经验。
后台产品服务于业务。在产品需求研究阶段，后台产品经理应该做什么C端产品自然不同。C端产品通常通过各种方式接触和挖掘用户的需求，面向B端客户的产品也差不多，但研究对象变成了B终端用户。对于企业内部的后端支持产品，需求研究的主要方式是将业务需求与所谓的业务方联系起来。业务方是指公司其他部门的人员，如供应链系统，需要找到供应链部门的采购和仓库管理对接需求，如CRM系统，市场部门是业务方。本节主要写需求对接问题，具体需求研究分析不扩大。
当我第一次制作背景产品时，我一直有一个疑问。我们的需求方是非常确定的人。只要我们的产品为他们服务，我们所做的不是既定的需求，只要他们说什么，我们就能做什么？当各种需求对接时，业务方通常会直接说你给了我什么功能。我们按照他说的去做，这不会满足需求吗？
后来，我逐渐发现，业务提出的具体需求并不一定是合理的。虽然我们的系统是为他们使用的，但产品需求的起点更多的是从公司业务的角度考虑系统对业务的价值和流程是否合理。这些需要由我们的产品计划，而不仅仅是如何使用功能。此外，业务方可能不知道产品能给他们带来什么，他们想要什么功能，并不一定能解决他们真正的需求目的。
产品经理自身的能力是相关的。在早期阶段，由于他的能力有限，他将停留在接收和执行需求的阶段，但在水平提高后，他将知道如何做得更合理，并逐步规划整个产品。因此，除了一些小功能的细节非常简单，直接做，一旦涉及到整个业务模块的需求，必须由产品经理领导，了解业务本身，然后给业务方标准化流程，告诉他们如何使用，不一定要做，否则可能不是一个可行的计划，业务方只会认为产品经理只是一个系统。
不过我也看到有些牛人说，面向公司内部的产品经理发展空间有限，毕竟用户太少，既定的需求多，在项目中业务方的重要性更高，确实没法像做C终端或平台的产品经理可以支配一个项目。这种情况或多或少存在，这个问题只能说是不同的。
业务对接不如挖掘C终端用户的需求是多么容易，在这个过程中也会出现各种各样的问题。特别是当你的业务方不做互联网时，在需求对接中确实会有一定的阻力。我现在在这家公司，有很多人来自传统行业，习惯于使用它excel对系统没有概念的人工作。在我与业务方对接需求的过程中，出现了以下情况:
首先，业务方可能不知道背景产品的价值是什么，可以给业务本身带来什么改进。他们可能只知道业务数据和操作应该在系统上进行，这比手工操作更方便；
第二，有些人习惯于在传统行业用excel在工作中，对系统的理解将停留在记录和查询中。他们提到的需求通常会提到一个特定的功能。如果你不问，你就不会说具体的目的。例如，真正的目的是做一个数据统计，但提到的需求只是在页面上添加一个导出功能，或在列表中添加一个字段；
第三，业务方通常从自己的操作角度提出需求，不一定关注产品的宏观价值、业务流程的标准化、管理规范等。特别是对于直接操作系统的人来说，他们提到的最多的是具体的功能。如何方便他们操作，会有一些功能不能按照他们说的去做，但他们不理解；
第四，业务方不一定有迭代思维，认为产品的推出就像传统企业的交付一样，一次性完成最终版本，然后供他们使用。我们将计划产品从0到1的过程MVP，首先推出基本功能并继续迭代，但他们会说为什么没有我想要的功能，必须等到我们完成他们想要的一切才能开始使用；
第五，有时候习惯一件事不容易改变。如果我们需要为了管理目的迭代一些操作，改变他们平时的线下操作习惯，他们可能会抗拒。相反，我有办法处理这些问题，我不明白为什么要改变这些功能。
当然，这些情况并不是绝对的，只是可能会遇到一些问题。经过这么多的业务对接，我总结了一些方法可以作为参考：
首先，找到合适的面的人。不要低估这一点。如果你有经验，你就知道找人很重要。例如，在一个部门，下面的人对业务了解更多，但他们通常只从自己的操作角度考虑问题。部门经理可以决定事情，通常知道系统应该做什么，但他们可能不熟悉业务流程的细节，也可能没有时间与您合作。另一个例子是，在同一部门的业务方面，有些人对各种互联网产品了解更多，至少会告诉你他以前使用过什么样的系统，其他人会更传统的行业。也许前一个人可以在半小时内了解清楚的需求，后一个人必须告诉他两个小时。我还记得我联系的一个系统从0开始，每月与第一个业务负责人召开四次会议。最后，另一方仍在努力为什么不购买一个系统。接下来，在更换业务负责人后，项目将在两次会议后直接顺利启动；
第二，听他们说，但不要这样做。这和我们对用户需求的态度是一样的，从他们所说的增加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后台产品漫谈——后台产品的目标和作用
