业务需求是什么？
业务需求宽泛的说很容易用一句话来概述：我需要一个什么样的工具，来满足我要做什么的诉求？
所以本质上，业务需求就是：因为业务方不满足现状，希望达到的一个状态。
带着这个核心，我们可以进行如下的分析：
1. 要掌握业务的发展方向需要了解什么？
在着手设计一套系统的时候，第一步需要先了解：业务的发展方向需要什么？
可能业务在不同的阶段会有着不同的发展策略，但是大的方向是不会变的，尤其是对内的业务流程系统。
可能原本就有一套这样的流程，我们需要做的就是将其线上化，产品化。这种情况其实要比C端的场景好入手的多，尤其是针对一些比较有针对性的平台系统。例如：各种内部的业务系统，其终态目标会更明确一些。
具体给出以下几点参考：
找谁去谈：
尽量找一些业务方向的决策者，整个业务的leader。
谈些什么：
① 聊业务：从宏观的角度来谈，我们做的产品是服务于什么样的业务，什么样商业场景？
同是ERP，餐饮行业的ERP和电商行业的ERP差别肯定会很大。我们在聊终态的第一步，首先得先搞清楚目前需要服务的业务是什么，避免一些南辕北辙的事情发生。深入的同时了解商业背景，业务背景在设计产品的时候也是很
有好处的，有助于把控业务需求边界，同时也容易产生业务同理心，在设计的时候根据不同的站位去定义产品。
②定基调：预计什么时间，给谁提供一种什么样一套工具或服务，满足谁和谁的什么诉求。
比如，我们之前做的一套品控质检系统，当时所定的方向就是：预计在三个月内，给质检专员提供一套可以从商户送货，到出仓检验的全业务流程系统，满足质检专员快速质检和异常情况处理的诉求，满足质检主管查看管理当天情况的诉求。
2. 产品需要根据业务发展制定什么样的阶段性目标？
在有了大的发展方向后，我们需要把其拆解成不同阶段的目标，每一个阶段要达到什么样的阶段性成果，进行再次明确。
而与传统意义上的C端产品相比，后台产品是没有MVP的概念的，因为我们无法通过某一个痛点或者爆点去满足用户的诉求，后台产品在第一个阶段不求做到大而全。但是，也需要将核心的功能逻辑做到完善。
我认为这点需要定义一个后台产品MVP。
之所以称之为后台产品MVP，因为在精益创业中的MVP定义为：满足客户的核心价值诉求，通过市场验证去不断的完善产品，调整方向。而从后台产品来讲，当某个业务场景已经明确被提出需要被产品化的时候，核心诉求可能不会一个，而是根据上面所提到的发展方向定义出来的一个完整业务流程。
所以，其产品功能结构和迭代的节奏会大有不同。我们需要做的是满足核心业务流程，并且在此基础之上不断的降本增效、优化流程、合并支出、减少重复建设。
后台产品MVP应该为：满足某一业务场景的核心业务流程的基本闭环，并在后续不断优化流程，完善支线流程，数据功能。
所以可从如下几个方向如考虑：
第一阶段：定义核心业务主线功能，拆解核心业务流程，确定需要产品化的流程。
第二阶段：根据主线功能进行拆分，满足主线功能的支撑流程线上化；满足核心业务逻辑的所有线上化流程操作。
第三阶段：定义主线功能多场景覆盖。满足业务不同情况下的业务闭环流程，同时确定产品化需求。
第四阶段：定义产品支线流程。分阶段满足各个支线流程的需要产品化的需求。
第五阶段：统计数据需求，为决策者做辅助。
上面五个阶段是产品可以支持到的业务场景阶段目标，在完成了上述功能后，可进阶到第六个阶段：产品能力提升，支持多维度多角度的丰富能力，比如对外的open api/系统稳定性优化。
举个例子：在明确了生鲜品控质检系统的业务发展方向后，不同阶段的目标具体如下：
第一阶段：
核心业务流程是商户将货品送至仓库后品控专员先进行商品核验后对货品抽检，确保货品在送到客户手中的货品数量无误且质量合格。
需要产品化的流程是：不同商户下的每个sku所送到仓库的数量无需手动记录，可实时推送至品控系统。品控系统直接进行货品的数量及质量的检测，并且可线上记录检测结果，同时给予商户反馈。有检测不合格的情况可推送至客服系统。
第二阶段：
主线功能可分为：
- 商户送货的数量校验
- 每个商户不同sku的抽检结果记录
- 反馈商户结果的记录及处理措施
- 反馈客户的记录及处理措施
第三阶段：针对第二阶段所列出的拆分功能，确定不同场景下的不同的业务流程。
比如：数量校验时对于标品及非标品的校验方式不同的流程记录。不同品类的sku合格/不合格的标准流程记录，不同结果对商户及客服的后续不同流程的记录。将每种情况都一一进行列举，并且满足每一种情况的主线功能业务流程的闭环。
第四阶段：定义产品的支线流程。
- 缺货后根据客户等级确定每个下单客户的缺货数量，并且可通知客户进行后续操作处理。
- 商户送货后送货确认单的打印及签收流程。
- 校验无误后入库操作与WMS的联动处理机制。每个支线业务流程可展示进行详细的闭环讨论。
第五阶段：确定业务数据指标——商户缺货率、商户货品合格率、货品入库率等。
以上是一套生鲜品控系统在不同阶段所要达到的一个目标，每个目标都可作为一个阶段性的产品需求展示进行设计。然而，业务需求有时候并不是以这样的方式告诉你，甚至有时候需求的提出者都不知道自己想要什么。
所以，我们要按照这个思路去引导业务方。同时，需要以一种同理心，自己也是业务的决策者，使用者的心态去和业务方一起去共创。
业务流程梳理
在有了业务需求之后，我们需要再深一个层次的去了解整个业务流程是怎样运作和流转的。
分析业务流程的时候，可以通过流程管理六要素进行分析：输入、输出、活动、关系、客户、价值。
- 输入：从业务角度来说指的是业务流程输入跑起来所必须的资源。也是流程启动的触发原因。
- 输出：指的是流程完毕后所得到的产物，整个业务流程流转到最后的产出。
- 活动：指的是业务流程流转的过程中各个环节，如何有机的调动整个业务流程运作起来的核心关键点。
- 关系：指的是各个环节即上述的活动直接的联系，以及相互承载使整个业务流程可以串起来的节点。
- 客户：指的是流程服务的对象。
- 价值：指的是这一套业务流程跑完后，得到了什么，有什么意义，同时这也是为什么要有这么一套流程的意义所在。
整体总结起来，业务流程就是：为一组存在相互“关系”的“活动”将“输入”转化成为对“客户”有“价值”的“输出”的工作。
在了解了以上知识后，在我们将业务需求所拆分成阶段性的目标进行不同业务流程的梳理。比如品控系统的第一个阶段：商户将货品送至仓库后品控专员先进行商品核验后对货品抽检，确保货品在送到客户手中的货品数量无误且质量合格。
输入物为商户要入仓的货品；输出物是最终品控流程的结果，数量是否一致，货品是否合格。以及最终所记录的结果。
活动有：
- 商户送货至仓库。
- 品控进行货品的数量核对。
- 品控对货品质量进行抽检。
- 记录抽检结果并进行反馈。
关系指的是：将1234流程接起来的动作，比如收货、核对数量后进行。
客户指的是：品控专员、商户、客服。
价值为：通过品控质检流程可对入库货品进行数量及质量的双重检验，减少出仓时的误差及降低不良率，提高客户满意度。
综合起来为：品控流程第一阶段目标的业务流程为商户送货至仓库后，品控专员接收商户货品后对商户货品进行数量核对。核对完成后对商户进行质量抽检，抽检动作完成后将结果进行记录，客服可根据结果进行对应的操作。以此来完成品控入库校验流程，客服登记异常结果的目的。减少出仓时的误差及降低不良率，提高客户的满意度。
梳理出业务流程后，我们再将其中的每一个细节进行细化。细化的过程就是一个不断抛问题并且找到结果的过程。这个结果可以是业务方提供的流程细节，也可以是我们和业务方达成的一个共识。
比如：品控进行货品的数量核对时，是如何进行核对的，根据公式进行测算的还是数出来的？都需要核对什么样的信息，是否只有SKU和数量？哪些是关键信息，哪些是非关键信息？核对完成后需要记录什么？记录的结果记录在哪里？都记录什么内容？有没有什么标准。
在将每一个流程细节整理清楚后，我们就会得到一个当前业务流程的大致概括。
业务流程优化
在了解了业务流程之后，需要将业务流程进行优化，也是在进行流程产品化升级的第一步。
可从以下几个方面去考虑：
- 简化高频操作：操作频率越高的操作，越值得进行流程的优化。比如某个系统的操作频率为一次闭环任务占用总工时的1%，每次闭环任务会有30次操作，则当流程效率优化10%时，一次闭环任务效率就是整体提高3%。
- 合并流程比较紧密的操作：如果两个流程衔接的特别紧密。
- 抽象繁琐的流程，尽量系统化：如果为人工操作起来比较复杂繁琐的流程，可将其抽象成系统化流程，即减少内部交互，提高操作效率。
- 整理工作流：流程中涉及到工作流的内容进行梳理（工作流介绍可看之前的文章）。
- 异常流程梳理：主线流程梳理后，对主线流程中可能产生的异常流程进行输出。关键节点按照流程六要素进行流程梳理。
在完成了上述的大部分工作后，我们会发现业务需求已经有一个大概清晰的范围及内容。接下来，就是按照业务需求进行产品功能的设计。
专栏作家
执迷，微信公众号：执迷有悟，人人都是产品经理专栏作家，一个后台产品经理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 unsplash，基于 CC0 协议
