产品经理的终极目标，就是去架构公司的业务，解决从市场机会到商业变现的过程，这需要很好的商业意识、业务洞察、战略规划和架构能力来相互配合。
一、什么是业务架构
关于业务架构，简单的说就是，“企业希望从这个产品身上得到什么”，以及“用户想从产品身上得到什么”。
我们还必须弄清楚那些用户，能够通过什么渠道达成他们的目标，甚至还可能会有其他的目标。
音乐平台的业务架构模型：
O2O 服务业务架构：
二 、什么是产品架构
“产品架构”解决的是如下两个问题：
1. 产品方向
按照产品架构图的结构和路径，产品的RoadMap也就可以被清晰的拆解出来，同时它还能指导技术架构的选型，比如：业务的容量，扩展性等等，为未来的产品发展指明了方向。
产品架构设计了各个功能模块的业务范围，针对每个功能的内外关系有清晰完整的定义。当一个产品的架构被确定后，也就确定了产品的迭代周内的范围，并且能够帮助上下游清晰的理解产品的结构、功能和复杂度。
2. 产品边界
不做什么，很多时候更为重要，明确一个产品的基本边界，可以让这个产品少走很多弯路，降低很多的风险和不必要的成本。这对于创业团队来说，有些时候非常关键。
三、什么是信息架构
信息架构，它决定这个界面需要呈现什么内容，以及呈现的方式，明确的表达这个界面所需要解决的问题，也就是业务痛点。
首先要对用户的行进路线做一个规划，让用户在任何一个页面都找到他想要的信息，能够通过最合适的路径去到下一个想去的页面。思考的重点是在功能架构被确定的情况下，如果摆放按钮，设置跳转连接，才能高效的满足用户的使用需求。
四、架构图的分类
(1) 基于技术&功能的产品架构图
列出产品已经拥有或初期产品规划阶段，应该拥有的功能进行抽象归类，描述出模块结构和关联关系。
(2)基于产品，技术和功能的服务架构图
下图是阿里云互联网金融解决方案服务架构图，基于现有产品以及产品所承载的功能，提供的服务构成了整套的解决方案架构。对基本的功能和产品进行抽象归类，划分模块。模型框架选用底层，中层，表层来表达。
(3)基于功能，技术，产品与服务的系生态&商业模式架构图
五、架构图的画法
抽象是指从具体事物抽出、概括出它们共同的方面、本质属性与关系等，而将个别的、非本质的方面、属性与关系舍弃，这种思维过程，称为抽象思维。
基于客户业务，设计产品架构，主要有四个步骤，如下所示:
第一步，业务架构分析
第二步，系统结构设计
一、业务架构分析
在业务架构分析前，B端产品经理首先要保证自己对所在行业有深刻的认知。 对行业有深刻的认知主要表现在以下几点:
全面的行业知识
对行业的痛点和特点有所理解
了解行业的商业模式
能获取行业意见领袖的意见
业务架构分析的作用是梳理出支撑客户的业务需要哪些系统。业务架构分析主要包含业务分析、需求分析、跨角色业务流程、系统梳理。
1. 业务分析
分析业务，主要是对业务进行一个整体性分析。
主要分析出:客户的业务投入什么?产出了什么?参与的角色有那些?客户对于业务的商业诉求是什么?客户的核心业务是什么?最后使用流程图来描绘核心业务。
2. 需求分析
需求分析主要是分析客户提出的特定需求，对业务影响，比如新增业务、修改业务流程等。
这里的需求分析，不同于产品功能设计时的需求分析。
做产品架构时，需求分析更加偏向于分析客户需求和业务间的关系，进而调整我们的业务分析结论。
以医院为例:客户提出需要，对他的客户资料进行数字化管理。针对该需求，分析可以得出需要新增CRM相关的业务。
在B端系统设计时，有很多通用的范式需求。比如:登录系统、企业架构、权限管理、数据权 限、报表统计等。
这些可能是业务上不会直观体现，客户可能也不会明确提出，但是对于B端产品又是非常必要 的。这些范式需求，在我们梳理业务架构时，也是要进行需求分析的。
3. 跨角色业务流程
在完成业务分析后，我们得出了业务的参与角色和业务流程。这时候，就需要明确角色和业务的关系了。
描述角色和业务的关系，可以使用序列图来分析。
4. 系统梳理
完成以上分析后，我们可开始梳理在该产品中会存在哪些子系统。
分析时，需要结合业务流程、需求分析和角色参与关系，划分各业务系统。以及子系统有哪些角色参与，体现的哪块子业务。
划分子系统的原则是优先把同一角色参与，流程中相近，业务相关联的整合到相同的系统。
2、系统结构设计
最容易实现的产品层级结构就是三层，即用户层、功能层和数据层，这种层级关系即
可完整的实现前、后台关系的业务系统：
1、统一的用户感知层
解决的是用户触达的问题，考虑在何种场景下通过何种方式触达用户，最表层的业务体验，也
就是我们常说的“用户体验”，包括界面，布局，配色等直观可见的每一个产品页面。
2、解耦的业务功能层
“业务功能”的解耦，本质是解决产品的核心功能设计问题，包括如何高效的完成业务功能，如何与用户层进行交互，如何与外部系统进行数据通信等一系列复杂的业务场景；
例子：
用户故事：“坐席接到用户王五反馈的问题，安排李四上门服务解决用户的冰箱故障”。
在这个描述中实际包括的关键信息有：记录问题，安排资源，工程师接受任务，上门服务。所以这个过程经过抽象处理后就变成如下形式：
受理：坐席把用户反馈的问题记录在案，并形成一个单据
调度：坐席根据用户信息，安排恰当的工程师
接单：工程师接受坐席安排的任务
履约：工程师上门处理用户反馈的问题
1、集中的数据处理
这一层处理的问题就是，产品的数据从哪里，沉淀到哪里去。实际上，稍微深入一点的问题就是数据如何高效的存储，如何快速的被调用。
例子：
用户故事：
“张三新买的冰箱出现了故障，他找到当时的回执单申报了一次售后服务，要求在周六上午处理完冰箱的故障”。
（1）用户信息
要有一个方便的界面协助用户申报服务，怎么能让用户在申报服务的时候把资料问题录入正确，有没有办法在用户打开这个界面就直接解决问题，有没有一个FAQ供用户查阅。
（2）业务信息
后台要处理用户的服务请求（申报的售后服务），要安排一个擅长处理这个故障的工程师上门服务（业务技能要匹配，不能派一个不懂冰箱的工程师处理这个问题），时间是周六（资源要调配，距离太远不合适，时间冲突不合适等）。
（3）数据信息
上次的订单是怎么找到的，这个用户是不是在服务期内，是不是要额外收费，费用是多少。这次处理完的订单怎么和上次的订单相关联等等。
六、产品架构需要的能力
1、需要有一定的技术理解能力，帮助自己理解清楚信息在不同的系统之间是怎样交换、
存储、耦合和解耦的。
2、要有基本的商业逻辑思维，比如节省成本、提高营收、提升效率等。
3、业务的整合需要对所在行业及业务本身有深刻的理解，同时对公司整体的运行逻辑也要有一定的认识，如销售、市场、财务、运营、产品、技术等。
4、需要有更强的抽象能力。不仅是把一个工作流程抽象成一个功能，而是要把一个业务抽象成一个系统，并且知道这个系统在产品中所处的位置;不是理清任务与任务之间的关系，而是要清楚业务与业务之间的关系，这样的关系最后是如何交织和演化在一起，共同促进产品繁荣的。
网友评论