从零搭建企业级系统必备技能：业务建模

点击 ↑  蓝字 关注此公众号，从此就是我的人（每周双更哦）~

回复“  3  ”获取《 产品日常必备资料包》

第 47 篇原创好文，共2300字|阅读用时5分钟

“2020年终于要翻篇了，临近新年（农历新年）提前祝大家新年快乐！ ”

不知道大家在日常工作中有没有遇到过这样一个问题？

在我们因为换工作或者新接手公司内部其他业务线的工作，从而一下进入到一个全新的业务领域。

此时自己会产生一种面对业务的手足无措感，感觉这个业务好像是一个陌生的庞然大物，完全不知道从何去理解业务，更别提为这套业务设计一套系统去进行日常业务运营的管理了。

事实上这个问题广泛存在在需要面对多业态的信息化服务商中，比如SaaS服务商，举个例子来说收银管理，面对不同业态的零售行业，例如经典的零售业分类：便利店、商超、大卖场、超市。

虽然说大家都是在进行零售业务的开展，但是由于店铺规模以及货物管理规模的不相同，就会导致业务流程有翻天覆地的差异。

这里说的还是同一行业内的不同业态，而如果我们研发的SaaS是服务百业（零售、餐饮、美妆、洗护）的管理系统，对这个项目的负责人来说每一个行业的业务都是一门新的学问。

所以面对任意一业务们要如何进行快速拆解，从而熟悉当前领域内的业务运作模式，这对于从事业务的团队负责人来说，尤其是于多个不同业务态的B端产品人来说更是一项必须要掌握的核心技能。

当然这项核心技能也有一个官方的名称——业务建模。

1

什么是业务建模？

我们都知道软件系统的本质就是一个信息流管理产物，也就是只能管理信息的输入输出，软件系统本身无法产生任何实物的变化，比如你想要用代码编写出一个能造苹果的软件（注意这里说的只是软件，不借助外部设备），这是不可能的。

因此软件产品的宏观定义就可以被描述出来了：

从上图中我们可以看到，一件事物从落地到软件开发实现的过程可以分为三步：

（1）选择现实世界事件，例如买手机；

（2）分析完成这个事件需要传递的信息流程是怎么样的，例如卖家给予：手机描述信息，价格信息等；买家给予：购物需求信息，确认信息等；

（3）对于这些信息流拆分出不同要素，例如有两个角色在交换信息（角色信息），信息类型可以分为输入/输出两类信息。

如果把上述三步用软件开发的行话来说，整个软件实现过程就是这三步：

我们先立项要做什么软件，再进行需求分析搞清楚本软件要管理信息流范围，最后通过业务建模完成要开发的内容的详细分析。

有了这个背景知识做铺垫后，业务建模定义就可以很容易地给出了：

在日常的软件设计开发中，为了解决如何将需要管理的事件信息点进行无遗漏的定位，此时需要找到所有事物的信息流，并拆解出管理要素的这个过程就是业务建模。

2

如何进行业务建模？

在上面我们已经完成了业务建模定义的认知，接下来就要去学习如何进行业务建模。

这里我们先给出一个通用的业务建模公式：

业务建模：（0）信息流定义；（1）信息输入；（2）信息输出；（3）信息处理公式；（4）信息参与角色；

这里（1）（2）（4）项，其实也就是大家在日常工作中说的场景。

举个简单的例子来看，如果我们要处理在途库存在商城商品的库存怎么展示的场景，本质上也就是上述三项：

业务模型项

拆解内容

信息输入

在途库存数

信息输出

商城库存数

信息参与角色

采购 / 运营

下面我们来看一个进销存业务系统采购侧的建模示例：

所谓进销存系统就是指供应链中以管理账务管理作为目标的系统，也就是管理除了仓库作业外的信息。

（0）信息流分析：

一级信息流

拆解内容

账务流

供应链流转的账本

二级信息流

拆解内容

库存数信息

整个仓库的库存变化，详细记录每一笔库存数变化及原因

资金数信息

记录库存商品花费的资金变化

（1）信息流拆分：

二级信息流

类型

角色

拆解内容

库存数信息

信息输入

运营

（1）客需订单数（如可乐240瓶）

（2）箱规（1箱=12瓶）

信息处理

公式

系统

订单数/箱规=采购数

240/12=20箱

信息输出

采购

建议采购数量（20箱）

信息输入

采购

实际采购数量（30箱）

（可乐畅销，所以多买点以备不时之需）

资金数信息

信息输入

采购

实际采购数量（30箱）

采购单价（1箱50元）

信息处理

公式

系统

实际采购数量*采购单价=采购价

30*50=1500元

信息输出

财务

应付账款（1500元）

仓库新增货值（1500元）

成本均价（50元/箱）

可以看到通过这样的业务建模，我们就清楚的将一个采购流程表述出来了，而且没有遗漏，表中的信息输入项就是我们的页面的输入内容，信息处理公式就是我们的计算逻辑，而输出项就是用户的需求。

有了这张表后，对于后面的原型绘制与程序编写都是及其方便的，可以一目了然的看到完整的业务全貌。

当然进销存流程不会只有采购这一环节，完整的流程如下：

我们可以根据上述的这个建模方法进行逐项拆解，就可以得到完整的进销存业务模型。

3

最后

实际上无论是SaaS，还是中台等这些企业级产品，本质上对产品负责人的能力需求都是在业务建模这一范畴上，也就是如何理解业务，并将业务运作系统化。

如果大家希望掌握更多建模内容，建议大家去看看UML建模理论，这里为大家准备了一份139页的UML建模学习资料，在《三爷茶馆》公众号回复“UML”，可免费获取该UML学习资料。

------------------- END -------------------