5个方法,帮助产品经理做好业务分析

2 评论 15890 浏览 84 收藏 26 分钟

业务需求来源于业务,业务梳理的主要思路是去理清业务中的要素,以及业务方在业务过程中的问题和所关注的核心点、需求。文章分享了5种梳理业务的方法,希望通过此文能够加深你对业务的认识。

在产品经理教学市场中,充斥着大量的课程、书籍,向我们灌输用户需求分析,用户研究等等概念,但少有人提及“业务”,即使提及了,也讲述得非常笼统,在进行“业务分析”关键词的搜索时,甚至很难看到有人对“业务”进行了定义。

相比于国外,B端的业务分析体系已经较为成熟,形成了健壮的知识共同体,有认证机构、配套的教学体系等等。而C端业务,由于面向群体的混沌性、随机性,国内国外都未呈现出系统性的知识体系。

在本文中,笔者尝试通过对“业务”进行定义,并对业务进行建模,得到描述业务的主要维度,并定义“业务需求”是什么。接着我会聊聊为什么重视业务以及业务建模很重要。

最后讲讲关于阐述业务的可视化方式,也就是业务分析完后需要输出的内容是什么。但具体的了解业务的方式由于篇幅有限就暂且不展开了。

一、什么是业务?

我们在研究一样东西的时候,首先需要对这件事情做一个定义。业务这个词对于产品经理来说并不陌生,但让你回答一下“业务”是什么的时候,这个事情似乎又没那么容易。

写这篇文章前,我就因为这个问题卡住了不少时间,司空见惯的东西却是最难以解释的。

后来我从他的英文单词中,明白了它的定义 — Business。

*Business* is the activity of making one’s living or making money by producing or buying and selling products (such as goods and services).业务(商业)是通过生产和买卖产品(如商品和服务)来谋生和赚钱的活动。业务一词最早来源于日本的翻译。

那我们可以明白,业务的本质其实就是商业,那我们在研究业务过程,本质上是在理解商业过程,及这个过程中供需关系与其中信息流、物流、资金流的传递。

从我过去所读过的一些经济学、进化论社科类书籍中,我明白了一个道理,人类的社会的经济发展来自于个体自下而上的信息、物质互换,在这过程中,比较优势凸显出来,个体的分工也越就更加明确。

在这个分布式的信息、物质传递过程中,一个复杂适应系统演化出来(复杂适应系统是我最近比较感兴趣的内容,不知不觉就会扯到它,以后找机会写写),在「理性乐观派」中,将这个系统称之为“集体大脑”,他是个体分工合作的集合。

业务,就是分工合作的小集合。社会中不同的业务共同构成我们的集体大脑。

「理性乐观派」中有一段话:经济进步的一项衡量标准:超过一半的人口脱离了自给自足,去探索以集体大脑为基础的生活所充满的无穷可能性。

啥意思呢?集体大脑是人类分工合作的结果,是社会中所有岗位的集合,我们工作就是参与了集体大脑的构建,从而有了更安全、更干净、更便捷的生存空间。但我们工作之余,也有精神需求,有学习、阅读、追求个性等等需求,他们则是集体大脑为基础的更多可能。

所以,我个人将产品分为两类,一种是为了构造集体大脑的,及业务型的产品,需要研究业务本身,研究促成社会发展的分工合作;另一种是有足够生活基础后,是对美好生活的探索,需要研究个体需求,这类产品俗称C端产品。

二、业务有哪些元素?

业务是分工合作,通俗的说,就是一群人在一起合作,以完成业务,达到各方的期许。通过业务,供需双方各取所需,各方消耗边际成本,获得边际收益,B端产品则是服务于这一过程的信息系统或服务。

那么完整地描述一个业务,需要有哪几个维度?这关乎到每一个产品经理在面对一个或陌生或熟悉的业务时,是否能准确分辨研究对象。

通过用户?场景?需求?似乎这种方式太过于简单粗暴,不太严谨。通过流程图?还是不够全面,业务中涉及到的信息没法很好的体现。

最后我在这本书中找到答案 –「七步掌握业务分析」

10年出版的书,评价仅有五十来人,页数也不算很多,但内容牛批。

这本书中,将业务分为四个部分:人、信息、流程、规则。从一个信息系统的角度来看,也就是外部实体、数据、过程及业务规则

以打车这个分工场景为例:参与的人员有司机和乘客,司机需要的信息是是否有乘客是否需要打车,他在哪里,他要去哪里,乘客需要的信息是哪里有车可以打,哪辆车可以提供服务等等。整个流程便是,乘客发布乘车需求这一信息,司机接受后,前往乘客所在地,获知乘客目的地,提供价格,乘客获取价格,选择坐与不坐,最后到目的地,乘客花费了金钱,满足了迅速到达目的地的需求,司机花费了时间成本、燃油费等,获得了酬劳。这一过程,还需要一定的规则,比如行车价格规则、安全规范等等,假若规则不明确,供需双方就可能无法达成平衡,以至于业务无法开展。

用一张图来表示这其中涉及到的人员和信息及规则,可以是这样:

加上流程描述,那就是这样,在书中,被称为核心需求组件。

第一张图,在书中称之为高阶数据流图,而我更倾向于业务全景图,因为他描述的是一个业务大致全貌,有助于我们在一开始确认研究的范围。

在这四个维度的基础上,我又加上了两个维度:业务目的、业务风险。因为业务的完成总是有所目的的,打车的目的是车主赚到钱,乘客安全快速地到达目的地,是业务参与人“想要”的驱动力。

而一个业务参与人也同样是有“不想要”的驱动力,那就是业务风险,完不成业务可能会发生的后果。比方说,打车这个业务下,乘客的风险轻则有黑车坑钱、司机送错目的地、绕道,经济和时间的损失风险,重则有人身危险的风险。

对于业务目的,则尽可能地减少成本,提升效率;对于业务风险,则需进行监管、管控,避免发生。

举几个例子:

产品开发业务,在这个业务当中有多个角色,简单地来看的话,主要是产品经理和程序员,程序员需要产品需求、BUG、数据需求等等,产品经理需要产品成果、开发,流程上可能会有企业的立项流程、产品开发流程等等。大家都基于公司的规章制度来行事,最终是想通过这个业务,这个分工合作来达到企业、员工、客户各方的利益,完不成业务的风险则是错失客户、市值下跌、员工可能被炒鱿鱼…

PM与RD之间,存在信息不对称、不及时的话,就会耽误开发周期,间接影响业务的完成质量,而这些在排除人员个人问题之外,主要就是由流程不明确、规则不明确、角色分工不明确导致的。

案件发生后,警察要抓贼,也就是情报侦查业务,这个业务中,贼与警察是两个主要角色,贼与警察存在着信息的不对称。贼知道是自己犯的事,而警察不知道,业务的目的就是弥合这种信息的不对称,使贼被抓住,维护被害人的权益,维持社会的稳定。那么啊sir就会通过各种手段来弥合这种信息差,通过监控、人脸识别等方式,而啊sir的信息则需要故意不让贼知道,啊sir需要基于一些规则办事,比方说调用监控的权限规则、依据法律办案。倘若破坏了规则,则可能造成一系列的公关问题,信息泄露问题等等。

三、什么是业务需求?

前文我们定义了业务是什么,也就是理清我们的研究对象,但是至于他们想解决什么问题还没有解决。

业务需求的含义指的是他们在分工合作中遇到了一些问题,所以主导这个业务的、能够从这个业务中获利的人希望能够解决掉他们。或者是这个人看到了业务能够提升的空间,也就是业务机会,希望能够抓住这个机会来实现业务的提升。

业务需求来源于业务,那么就是四要素中出现了某些问题,导致成本损耗、营收达不到目标要求、风险失控。不同的业务需求,决定了我们接下来要解决的用户需求是不同的,

四、为什么要理解业务,定义业务需求?

为什么我认为在做产品之前,应当先理解业务,再考虑方案?可能有些人会说因为没考虑清楚业务,做出来的产品肯定是不符合需求的。但个人认为还有一个更重要的原因,这个原因困惑了我许久时间。

做产品经常会被要求要有框架性思维,我也一直试图再学习练习在面对一个陌生事物,不管是生活中的还是工作上的,都能够带入这套思维去思考,后来发现,不管我怎么做,我最后都还是会回到起点,没有办法在一时间构想整个框架。后来,我发现这个框架太庞大了,从最初的需求到后期的运营,啪一下全构想出来是不可能的,因为工作记忆只能容纳7个数字,人类的大脑特性决定了这件事情是不可能。

但是为什么有些人能够一次性记忆数百个数字,那是因为他将一连串的数字拆分成3-4个数字的组合,并且通过已有知识将这些无逻辑的数字构想成逻辑,组合起来就能记忆上百个数字。比如说记忆100252037989,就可以拆分为1002(是我的出生日期倒过来,Justkidding),5203(我爱你撒),7989,学习更多的数字抽象化方式有助于记忆。

那产品思维的方式也是这样的,需要将多个复杂步骤拆分成几个模块,并且通过已有的知识将这些模块拆解、构成自己的逻辑,就可以有效记忆和理解。同样,学习和练习更多的需求理解方法论,也有助于理解。

那么首先要思考的就是业务的四要素和业务目的、业务风险,通过对业务的了解。

五、业务分析的输出内容

由于篇幅问题,本文就直接讲解业务梳理后输出的内容,也可以说是业务要素的呈现方式。

业务梳理的主要思路是去理清业务中的要素,以及业务方在业务过程中的问题和所关注的核心点、需求。

我们定义了业务是什么,那我们如何梳理业务,让业务信息尽可能全面和清晰呢?

这里介绍几种方法,帮助我们能够梳理清楚并清晰展示业务的过程逻辑。

他们分别是:

  1.  业务范围图
  2. 核心需求需求组件
  3. 业务流程图与用例
  4. 业务规则表:决策表、业务术语表、角色与权限矩阵、业务规则表
  5. 数据模型:实体关系图

这几个方法的层级关系是这样的:业务范围图描述最粗粒度的业务,只描述关键信息与所涉及的人员。而核心需求组件进一步,描述业务的人(外部主体)、信息(数据)、流程、规则,但也是粗粒度的整体描述。再通过流程图、用例图展开描述所涉及到的人与流程之间的关系,业务规则表展开描述规则,数据模型则描述人与信息之间的关系。

1. 业务范围图

在前文中也介绍过,业务范围图描述业务中所涉及的所有角色,以及每个角色在业务过程中所供给和需要的重点信息。业务范围图,有助于在项目初期理清业务范围、业务干系人,和其中比较重要的信息,无需技术背景,也可以让各方干系人理解沟通。

外部的方块表示外部实体,角色、机构、依赖的系统等。箭头表示信息进出的方向,中心的圆圈表示研究的领域,及业务。

2. 核心需求组件

核心需求组件提炼业务的核心要素。依次来描述:

信息(数据):可以指的是一个实体,比如说一个订单,也可以是实体的属性,订单价格。对于数据的分析待会会再提及。这里的只需要将这些数据进行罗列,个人建议罗列实体,属性在实体,理清业务中的信息对象。

外部主体(角色):指的是与业务领域内有交互的人、组织或系统。体现的是业务过程中,哪些角色进行了分工合作,有时候分工对象还有硬件设备或外部软件,它们也是其中的外部主体。

流程:流程是所有产品经理最熟悉的东西了,指的是业务所完成的活动工作。流程就会涉及外部主体与信息的传递。这里只需要概述有哪几个业务流程。比方说项目管理业务,包括立项流程,月总结流程,结项流程。

规则:业务规则是分工合作过程中的条件,是业务演化的结果,它使得业务在一些情况下,能够有决策依据,使业务保持一致,顺利开展。现在很流行的策略型产品经理,我认为本质上就是在写业务规则,即推理规则、计算规则。

3. 业务流程与用例

业务流程是大家熟知的方法,不管是C端B端都会绘制业务流程,后期运营也通常是通过它来找问题。

业务流程图展示的是一个业务分工合作、信息互传的过程,描述的是没有我们的设计方案之前是如何完成业务的,流程通常用动词进行描述,表述角色的任务、动作。关于业务流程图的资料已经较多,就不做展开。

描述角色动作(任务)与信息传递的方式还有用例图。用例图即可以是描述系统功能、产品需求的方式,也是我们做业务分析时,可以使用到的工具。

用例图有四个元素:参与者、用例、边界、箭头(关系)。参与者表示与软件(项目)接口的人、组织、系统;边界在软件需求中指的是系统的操作边界,而对于我们进行业务分析而言,它就意味着业务的边界范围;用例是角色在业务范围内的动作;箭头在复杂的用例图中有多种画法,我们可以尽量保持简洁以便沟通。

  • 参与者 ➡️ 用例:参与者使用用例
  • 用例 ➡️ 参与者 :用例使用完后,信息传递给参与者
  • 用例 ➡️ 用例:父用例包含子用例

用例的使用,可以让我们清晰看到在业务范围内,不同角色有哪些职责、任务,也可以理解为不同角色的用户需求,但用例图隐藏了用例过程中的一些细节,有时候还需要更详尽的用例说明来辅助表达。

除了流程图和用例之外,也可以用用户-场景-需求的方式去梳理用户需求。

4. 业务规则

在「软件需求:第3版」中,业务规则分为这么几类:事实、约束、触发条件、推理规则、计算规则。它们都有相应的需求表述的方式。值得一说的是权限也是业务规则的一种说明。

比如:项目管理业务中,公司规定了PM每个月必须上报项目进度。这是一条业务规则,但后期,设计一款项目管理工具时,它就成为一个需求,每个月未上报,会进行邮件通知或者绩效考核扣分之类的后置条件。

业务规则的类型较多,表达方式也比较多,如权限设计有RBAC模型,策略算法可能用的决策树、决策表等等。本文介绍一种简单、通用的方法来记录这些规则,来自于「软件需求:第3版」,业务规则表。每条业务规则用一句话去描述,

来源:软件需求第三版

5. 数据模型

数据模型处理的是人和信息之间的关系。

我们在业务的过程中,我们经常会虚构出一些词汇,来定义某一类东西,以便于业务各方能够快速沟通,同步信息。就像金钱是我们生活中虚构出来的概念,以便于在市场中,能够进行快捷有效的交易,又比方说“订单”,它的作用在于让购买者和出售者用同一载体沟通购买的结果。又比如说“课程”,它是为了让教师和学生方便沟通的统一介质,他们都是某种人为定义的非物理性质(也可能被制定成某种物理材料)的概念。

数据模型的梳理是为了让我们知道业务过程中,有多少种人为抽象出来的概念,以便于信息的传递和沟通。在业务调研过程中,就需要发现和记录这些虚构出来的概念。那如何记录与分析呢,就需要用到我们的实体关系图。

同样,实体关系图也是来自于信息系统设计,它既是一种设计数据层、设计数据库的方法,也可以是我们分析业务数据对象的方法。

我们用实体关系图来对业务信息进行抽象和分析,将大大方便我们后期对产品的设计。由于本次不讲产品设计,所以就暂且不展开。

实体关系图非常的简洁,包含三个元素:实体、属性、关系。实体指的是我们抽象出来的概念,比如之前说的「课程」,又比如说「学生」,学生其实也是一种概念,他们都描述一类事物。

但是描述一类事物还不够,我们还需要区分这类事物的不同个体。比如说上课这个业务,我知道你是学生没有用,我还得知道你这个学生叫什么,是哪一班的,是男是女才行。

所以每种实体还会有属性,比如说「课程」有上课时间、课程类型等属性;「学生」会有姓名,性别,学号,年级班级等等。如果是在产品设计阶段,这些信息就会被存储在一张「课程」、「学生」数据表当中,大概像下图那样。

一个实体有多个属性之余,还和其他实体之间存在着“关系”,因为它们通常不是独立存在的,是因为业务而产生的。「课程」这种实体会与「教师」这种实体的关系为1:1的授课关系,「课程」和「学生」存在1:N的被授课关系。

通过这几种方法,我们可以清晰地看到业务过程中的所有元素。

总结

在这篇文章中,提出了对于业务的定义,有助于我们认清楚分析对象是什么。同时也提出了关于“为什么产品工作要先进行业务分析”的观点。最后介绍了5种业务呈现方法,帮助我们对业务全貌形成理解。

 

作者:Lobster.;个人公众号:生猛龍蝦

本文由 @ Lobster. 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 文章过长到后面有点乏味了

    来自山西 回复
  2. 页面流转

    回复