B端产品100问：一图掌握业务架构图绘制心法
大家好，我是穆宁。
本篇文章是我的专栏《B端产品100问：从0到1看清toB行业底层逻辑》的第四篇更新内容。
专栏详细介绍
本内容适合阅读的人群主要有：
1.对toB产品感兴趣的在校大学生；
2.已经在toB领域工作1-3年的小白；
3.toB领域工作多年的资深产品经理；
4.想要从toC领域转型到toB领域的产品经理；
本内容的基本大纲分为：
1.概念篇——澄清相关toB领域基本概念；
toB产品入门，掌握最基础的toB产品相关概念与理论，建立基础的个人知识库；
2.标准篇——toB产品设计要求及工作标尺；
toB产品中阶，掌握从业务调研、方案设计到解决方案执行过程中的所有工作规范，参考下方图片；
3.系统篇——通过业务实践构建B端系统方法；
toB产品高阶，通过具体实操案例讲解toB产品从概念期、引入期、运营期、成熟期的全部流程与操盘方法，从产品、运营、市场、到销售、售后；内容来源于网络，侵删；
本内容可以带给你的帮助与收获：
1.帮助想要投身B端行业的小白夯实基础，建立认知；
2.帮助“野路子”B端产品从业者建立系统方法论与分析思路；
3.为资深B端产品经理提供一些信息输入，得到启发或查漏补缺；
4.B端产品行业爱好者收藏，学习所用；
本内容的更新频率：
每周更新8-15个问题，预计在10月底完结。
本付费专栏的价格：
79.9元/终身，每周涨价10元（上周价格为69.9元）
请注意，是终身，终身！只要我不发生重大人身事故或疾病，我就会持续更新。
每天大概多少钱已经可以近乎为0了，我只知道只要你加入，就能和我共同成长。
PS：请注意，该专栏价格并非仅能享受toB产品100问连载内容，而是《看本质》专栏的全部内容！截至目前已经更新两期内容：
100问内容完结后，还将策划新的选题内容。
本专栏已经开启“合伙人”计划，通过分享专属的邀请链接或邀请海报有人下单后，可得到40%收益分成。
专栏往期内容见下方链接：
B端产品100问：从0到1看懂toB行业底层逻辑：概念篇（1-8）
B端产品100问：从0到1看懂toB行业底层逻辑：概念篇（9-16）
B端产品100问：从0到1看懂toB行业底层逻辑：UML篇（17-27）
订阅方式
扫描下方二维码即可
===============================
好了，闲话少说，我们正式开启第四期内容：
B端产品100问
**从0到1看懂toB行业底层逻辑——概念/**架构篇（Q28-Q37）
Q28:什么是产品架构？
将业务结构化抽象，并以功能和信息的形式体现。展开说是将具体的业务功能按照一定规则组装成业务模块，将不同业务模块按照一定规则进行划分和归拢，并用图形或者文字把各模块之间的关系表达出来的逻辑模型。
Q29:为什么要设计产品**/业务****架构？**
产品经理角度来看：帮助产品经理梳理清楚每个业务模块/功能间的边界，以及它们之间的关系，明确产品方向，划分产品边界，指导产品路径。
公司角度来看：将无序、散乱的业务抽象成中心化、标准化的有序服务，将系统的共性抽象成通用服务。改善高频需求重复占用资源问题，提升系统功能复用性。改善旧系统耦合性强问题，利用SOA理论及架构，提升系统功能延展性。
Q30:好的产品**/业务****架构有哪些特点？**
清晰的系统目标：能体现公司的业务目标及管理目标。
助力商业模式：能体现公司的业务目标及管理目标。
架构边界清晰：清晰的功能边界，架构分层明确。
组件职责单一：功能经过抽象，做到标准化、互相独立，组件职责单一。
组件弱耦合度：在系统设计时十分忌讳“强依赖”。
组件具备扩展性：架构开发预留开放接口，具备迭代优化的能力。
抽象能力强：能帮助产品适配更多的领域，支持纵向演进及横向业务的覆盖范围。
落地性强：开发难度适中，可验证方案较多，落地能力强。
Q31:产品/业务架构包含哪些要素和内容？
产品架构要素主要包含两个视角，一个视角是业务视角，另一个视角是架构视角。
业务视角主要体现在业务调研过程中，通过访谈获取到核心目标，了解关键角色和关键业务，在后续设计时，就明确了哪些模块是必须要详细设计的，哪些模块可以做简化设计。
架构视角则是在业务调研之后，我们需要在进行实际的产品架构设计之前梳理出我们需要了解产品架构所包含的要素，用于理解与呈现。
业务视角是对实际业务的抽象，架构视角是对业务视角的进一步抽象及可视化。
业务视角：
整体组织架构：全局视角俯瞰整个项目结构时必须了解的部分；
权限角色架构：角色权限及范围帮助我们了解角色权限的颗粒度；
关键业务要素：业务中用户产生业务操作的对象以及交互关系；
业务流：系统覆盖范围内的所有业务的流转流程；
数据流：系统中不同平台交互所产生的数据流转流程；
操作流：某权限用户为实现业务诉求而在系统中某平台产生的操作流程；
架构视角：
模块：不同功能汇聚成模块，模块的划分需要遵循规则，根据角色、场景、交互操作等去进行功能块的聚合。
域：不同模块可以进一步聚合形成域，域是模块根据某个场景聚拢而形成的，域可以支撑某一个场景下的一系列操作，输出一个闭环的能力。
层：是某几个域和模块的组合，层实现了向下整合或向上支撑的统一化的能力。逻辑关系指层、域、模块之间需要有清晰地逻辑关系，如输入输出、边界等等。
Q32:产品/业务架构图的两种类型？
常用的业务架构分层有2种：
上中下结构：资源层—数据层—平台层—业务层—用户层。
左中右结构：上游产业—业务模型—下游产业。
Q33:产品架构图的绘制流程？
一、确定业务方向
1. 定义业务场景
问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充成一个在商业模式和用户体验上能够形成闭环的产品需求。
-
核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？
-
产品目标：如果以一个数字指标衡量我的产品，它应该是什么？
-
3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？
2. 清晰业务流程
这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。
二、业务架构分析
业务分析：
主要分析出：客户的业务投入什么？产出了什么？参与的角色有那些？客户对于业务的商业诉求是什么？客户的核心业务是什么？最后使用流程图来描绘核心业务。
需求分析：
需求分析主要是分析客户提出的特定需求，对业务影响，比如新增业务、修改业务流程等。
这里的需求分析，不同于产品功能设计时的需求分析。
做产品架构时，需求分析更加偏向于分析客户需求和业务间的关系，进而调整我们的业务分析结论。
跨角色业务流程：
在完成业务分析后，我们得出了业务的参与角色和业务流程。这时候，就需要明确角色和业务的关系了。
描述角色和业务的关系，可以使用序列图/泳道图来分析。
系统梳理：
完成以上分析后，我们可开始梳理在该产品中会存在哪些子系统。分析时，需要结合业务流程、需求分析和角色参与关系，划分各业务系统。以及子系统有哪些角色参与，体现的哪块子业务。划分子系统的原则是优先把同一角色参与，流程中相近，业务相关联的整合到相同的系统。
三、业务架构设计
1）基础框架
对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。
将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。
将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
2）分层
分层是一个功能维度上的概念，可以按照服务的对象不同，分为用户层、业务层、数据层。
用户层：将所有面向用户的功能集合在一个层级，需要考虑不同的用户群体所享受的服务存在差异。
业务层：将所有的业务处理规则和逻辑，集成在业务层，业务层对用户层有逻辑支撑，业务层在不同的场景下集成的规则和能力都是不同的，向上输出也不尽相同。
数据层：将所有的数据沉淀，数据处理集成在了数据层，数据层提供基础的跟数据相关的增删改查服务，这些服务供业务层调用，在不同的场景下沉淀不同格式的数据。
3）分域
域一般情况下可以考虑按照业务职能进行划分，也可以根据业务线或业务主体进行划分，最常见的比如滴滴租车域、专车域、顺风车域等，这种划分的本质也是逐步在扩充我们业务边界，也是产品生态的不断扩容。
域也可以按照系统的关系来进行划分的，支撑域、集成域、消费域这类划分方式，这种方式划分域能够把能力聚合在一起向外提供统一服务。而集成域更像是一种解决方案的聚合。
4）分功能
分功能是指在同一个域中，将独立的功能划分出来，该功能可以代表一个业务入口。
简单理解就是将一个模块体系中的功能，比较具有代表性的，客户比较关注的，拎出来。
在画业务架构前，有必要对整个业务体系进行全量的思考，将所有涉及到的应用、功能、系统、能力、平台全部要罗列出来。
然后进行提炼、归纳、分类，按照常用的分类模板，或是自建模板进行大体框架的构思。
5）识别核心业务时标对象及状态流转
在拆解核心场景时，一定会涉及到业务单据，将其记录下来，若单据有跟随时间、事件、动作发生状态转移，则需要绘制出它的状态图。
6）理清业务对象之间的关系
识别出来业务对象后，通过箭头或虚线表达出他们之间的关系，以让开发同学一目了然。
四、画出架构蓝图
使用合适的工具，基于上面的分析进行合理的绘制即可。
Q34:业务架构对企业应该起到什么作用？
业务架构是一个具有通用目的的学科，适用于许多不同场景。它本身并不是一个目标，更像是一种实现交付业务场景的手段，例如：
-
制定和沟通战略业务目标的影响
-
跨业务部门对齐战略和计划
-
实现商业模式目标
-
评估监管和政策变化的影响
-
提高客户和第三方的参与度和体验
-
框定、范围、阐明和重用业务需求
-
确定企业投资的范围
-
定义IT目标架构
-
实现战略业务转型
Q35:针对不同需求如何切换产品架构的思考？
不同类别的需求，对应着不同的架构思考，分别为：
小需求，用产品模块内可配置思考方法；
先站在整个系统架构来看这一个又一个的小需求，把需求归类到属于它的模块，然后尽量的用一个功能模块来满足多个类似的需求。一个Ｂ端资深的产品经理，在面对一个一个小需求时，懂的在整体中来理解部分。
中等需求，用高内聚、低耦合思考方法；
高内聚的意思是指，产品结构中单个模块内各个元素联系紧密，也就是一个模块内的代码只完成一个任务。
低耦合的意思是指，产品结构内不同模块间的联系弱，关系简单，修改一个模块则不会影响另一个模块。
产品通过低耦合、高内聚的思想来设计，会给产品未来带来更好的可扩展性和灵活性，避免了后期产品的难以迭代，需要重构。
大需求，重启产品线思考方法；
公司有了新需求，且这个需求已经远远超过了产品从0到1的架构边界。这个需求是不是真需求？这个需求有没有价值？能不能规模化发展？等等都是一个未知。
这时最好的解决方案就是重新启动一个独立的新产品来解决这个问题，千万不要把新需求聚合在老产品里，让产品越来越不好用，影响了老业务的发展，得不偿失。
Q36:如何提升产品架构图的扩展性？
产品架构想要具备扩展性，就需要考虑将产品的模块按照其在架构中可能涉及到的变化频率分为三个类别：
核心层：作为不可变或低频可变的内容，用于设计产品最核心，最具竞争力的部分。大部分产品架构中数据层都是核心层，核心层提供的能力是最内聚的，是产品的底座。
组合层：是指将一些垂直的场景内聚到域当中，域内的能力是相对集中的，通过跨域的组合搭建不同的商业场景，组合层的能力决定了产品的灵活性。
定制层：定制层主要指差异化的部分，差异化的部分是可以进行定制的，定制出来的功能模块需要组合层的支撑，组合层提供的能力越多，那么定制层的定制能力则越强，扩展性就越好。
具备了这三个部分的能力的产品架构，已经具备相当不错的可扩展的能力了，主要体现在大部分业务的特性化诉求，都是可以通过定制层来满足的，少部分具备一定抽象能力的诉求，可以在组合层中来支持。只有当出现大的技术变革或业务方向发生调整之后，核心层才会发生改变。
Q37:绘制产品架构图的工具有哪些？
processon：
ProcessOn是一个方便易用、免费高效的在线作图工具。之所以会推荐这个工具主要因为：一是因为它是一个在线的工具，具有了跨平台的特性。二是因为其在线存储，文件备份比较方便。三是操作简单，它基本吸取了visio之类常用绘图软件的操作特点。四是因为结合网络社交的特性，不同图表的作者可以轻松地在平台分享各自作品，用户也可以方便地对公开的作品进行搜索，同时还支持多人协作的功能。当然，这个工具还存在或大或小的不稳定因素，如丢失数据，菜单功能卡住，图标相对比较少等。
axure：
Axure RP是一个专业的快速原型设计工具，除了产品经理之外，还有很多领域的从业者使用该软件。Axure RP不仅仅可以设计产品原型，也可以绘制产品线结构图、用例图、逻辑流程图等等，甚至很多产品经理直接使用Axure RP表述产品需求文档。
visio：
微软推出的一款流程图制作工具，也是目前产品经理最常用的一款流程图工具。通过Visio可以方便、快速地把业务流程、系统实现流程画出来。它本身有很多的组件库，可以很方便的完成各类流程图、结构图和网络图的制作。Visio的另一个特色功能在于它有非常丰富的自带模板。
Powerpoint：
Powerpoint是我们日常使用几乎最多的办公工具，其强大的形状库与素材库可以满足产品经理绘制流程图、产品架构图等基础需求，且输出较为方便，学习成本也较低。如果工期紧张需要快速绘制时，PPT其实是个不错的选择，但如果有更专业架构图绘制工具，可能就要对比衡量一下了。
摹客：
摹客是一款专业的原型设计工具，支持对产品架构图的绘制，但并不是主打功能。优点在于可以随时切换查看产品原型与业务流程图，较好的实现产品逻辑的可视化校验。
draw.io：
draw.io 是一款免费的在线图表编辑工具，代码完全开源，可以用来编辑工作流，BPM, org charts, UML, ER 图，网络拓朴图等。不论是在线编辑还是定制化开发，都是一款非常强大的工具，非常推荐。
高清大图我放在了我的小报童专栏小册
【看本质——俯瞰世界世界的100张图解】
如果想要持续关注我的精华内容，欢迎订阅
价格：79.9元/终身
（每周涨价10元，早买早享受）
↓↓↓↓↓↓****
如果觉得文章不错，欢迎点个在看。
我是穆宁，让我做下自我介绍
混过BAT做过PM，创过业，现央企搬砖
虎嗅，36kr，人人产品经理专栏作家
互联网撰稿人 | 音乐人 | 网球手
别被任何人定义，你我都是独一无二
