不知道大家在日常工作中有没有遇到过这样一个问题？
在我们因为换工作或者新接手公司内部其他业务线的工作，从而一下进入到一个全新的业务领域。
此时自己会产生一种面对业务的手足无措感，感觉这个业务好像是一个陌生的庞然大物，完全不知道从何去理解业务，更别提为这套业务设计一套系统去进行日常业务运营的管理了。
事实上这个问题广泛存在在需要面对多业态的信息化服务商中，比如SaaS服务商，举个例子来说收银管理，面对不同业态的零售行业，例如经典的零售业分类：便利店、商超、大卖场、超市。
虽然说大家都是在进行零售业务的开展，但是由于店铺规模以及货物管理规模的不相同，就会导致业务流程有翻天覆地的差异。
这里说的还是同一行业内的不同业态，而如果我们研发的SaaS是服务百业（零售、餐饮、美妆、洗护）的管理系统，对这个项目的负责人来说每一个行业的业务都是一门新的学问。
所以面对任意一业务们要如何进行快速拆解，从而熟悉当前领域内的业务运作模式，这对于从事业务的团队负责人来说，尤其是于多个不同业务态的B端产品人来说更是一项必须要掌握的核心技能。
当然这项核心技能也有一个官方的名称——业务建模。
一、什么是业务建模？
我们都知道软件系统的本质就是一个信息流管理产物，也就是只能管理信息的输入输出，软件系统本身无法产生任何实物的变化，比如你想要用代码编写出一个能造苹果的软件（注意这里说的只是软件，不借助外部设备），这是不可能的。
因此软件产品的宏观定义就可以被描述出来了：
从上图中我们可以看到，一件事物从落地到软件开发实现的过程可以分为三步：
- 选择现实世界事件，例如买手机；
- 分析完成这个事件需要传递的信息流程是怎么样的，例如卖家给予：手机描述信息，价格信息等；买家给予：购物需求信息，确认信息等；
- 对于这些信息流拆分出不同要素，例如有两个角色在交换信息（角色信息），信息类型可以分为输入/输出两类信息。
如果把上述三步用软件开发的行话来说，整个软件实现过程就是这三步：
我们先立项要做什么软件，再进行需求分析搞清楚本软件要管理信息流范围，最后通过业务建模完成要开发的内容的详细分析。
有了这个背景知识做铺垫后，业务建模定义就可以很容易地给出了：
在日常的软件设计开发中，为了解决如何将需要管理的事件信息点进行无遗漏的定位，此时需要找到所有事物的信息流，并拆解出管理要素的这个过程就是业务建模。
二、如何进行业务建模？
在上面我们已经完成了业务建模定义的认知，接下来就要去学习如何进行业务建模。
这里我们先给出一个通用的业务建模公式：
业务建模：（0）信息流定义；（1）信息输入；（2）信息输出；（3）信息处理公式；（4）信息参与角色；
这里（1）（2）（4）项，其实也就是大家在日常工作中说的场景。
举个简单的例子来看，如果我们要处理在途库存在商城商品的库存怎么展示的场景，本质上也就是上述三项：
下面我们来看一个进销存业务系统采购侧的建模示例：
所谓进销存系统就是指供应链中以管理账务管理作为目标的系统，也就是管理除了仓库作业外的信息。
（0）信息流分析：
（1）信息流拆分：
可以看到通过这样的业务建模，我们就清楚的将一个采购流程表述出来了，而且没有遗漏，表中的信息输入项就是我们的页面的输入内容，信息处理公式就是我们的计算逻辑，而输出项就是用户的需求。
有了这张表后，对于后面的原型绘制与程序编写都是及其方便的，可以一目了然的看到完整的业务全貌。
当然进销存流程不会只有采购这一环节，完整的流程如下：
我们可以根据上述的这个建模方法进行逐项拆解，就可以得到完整的进销存业务模型。
三、业务建模的后续
实际上无论是SaaS，还是中台等这些企业级产品，本质上对产品负责人的能力需求都是在业务建模这一范畴上，也就是如何理解业务，并将业务运作系统化。
当然完成业务的建模只是将业务以信息流的方式表述出来，下一步需要做的工作就是需要由一个框架将业务模型中的信息流装进去，这里用于承载各信息流的系统框架在我的书《中台产品经理宝典》中，我将其称之为：应用架构。
而在应用架构中我们需要拆分为两步进行设计：
- 数据架构：各信息流的字段是什么，数据结构是什么？
- 技术架构：选取什么技术实现，并如何承载多大体量的业务量？
所以我们也明白了一个产品的设计通用的过程其实分为两步：
- 业务模型定义：找出流转信息与处理公式；
- 应用架构设计：承载业务模型的实现架构；
