前言

本书关键在于06章，10章。分别为具体方案设计、需求池管理。

该书的作者杨堃，是一个典型的企业管理-系统架构级的B端产品经理。 因而该书逻辑严谨，层次分明，其关注的重点，也非常符合B端产品的重点，以下详细说明。

类似于B端产品经理的工作职责、常见B端产品业务模式介绍，都属于B端产品常识，不累述。

该书的重点分别为：

• B端业务调研
• B端产品的整体方案设计
• B端产品的需求与迭代管理
• 企业级应用架构

一、B端业务调研

1. 业务调研目标，分析框架

两个常见的重要目的：

• 梳理业务现状
• 总结业务问题

分析框架

• 战略层
  • 战略定位
    • 明确该项业务在公司的战略定位
  • 战略目标
    • 明确公司的战略目标，与该项业务在公司内希望达成的战略目标
• 战术层
  • 经营策略
    • 理解公司的经营策略，确保对产品的定位、形态做出准确的判断
  • 管控模式
    • 理解公司对部门、总公司对分公司等的运营管理策略。不同的管控模式需要对应不用的配套管理系统与管理事项
• 执行层
  • 管理层
    • 组织架构
    • 人力资源
  • 运营层
    • 流程管理
    • 绩效管理
    • 合规风控

2. 业务调研方法

• 深度访谈
  • 准备访谈大纲
  • 从高级别人员开始
  • 提前研究访谈对象
  • 和访谈对象保持联系
• 轮岗实习
• 调研问卷
  • 激励用户完成填写
  • 控制好开放式和封闭式问题
  • 避免诱导性问题
  • 谨防“幸存者偏差”
• 数据分析
• 行业研究
  • 研究针对业务相关领域的经典管理案例
  • 研究针对业务相关领域的经典管理案例

二、B端产品的整体方案设计

B端产品的方案设计, 分为两章,分别为整体方案设计, 方案细节设计. 其中前者共五个小节，如下，比较泛泛而谈。 后者针对方案设计的重点进行了阐述。 B端产品设计的重点，就是：

• 架构设计
• 业务数据建模
• 角色与业务流程

理清楚了这三点，就不会有什么问题了。类似界面设计、报表设计、权限设计，都是相对没那么重要、且后期容易更改的。

1. 核心业务流程

核心业务流程图：

2. 产品定位

产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持。

经过以上分析，我们进一步将分销系统拆分为三个独立系统，每个系统的定位不同：

• 分销商城前台（移动端，通过H5实现）：为分销客户提供下单功能。
• 客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。
• 运营管理后台（PC端）：为分销业务部门提供客户及商品定价管理的业务支持功能。

3. 应用架构设计

所谓应用架构，是指公司所有产品和系统的整体结构和布局，我们在“进阶篇”会详细讲述。任何公司的应用架构都不是随意设计的，有复杂的设计思想蕴含在其中。 在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。

4. 功能模块设计

5. 演进蓝图设计

三、B端产品的需求与迭代管理

好像也没讲什么..都是一些比较寻常的。

 

四、企业级应用架构

该书用了整整三章的内容，详细讲解了企业级应用架构设计。 这里是本书的重点。因为企业级架构设计，非常的重要且复杂。涉及到很多个互相作用的子系统 ，且是企业管理的基石。

1. 典型的企业级应用架构图

企业信息化建设已经发展了几十年，仔细思考你会发现，传统企业和成熟互联网企业的应用架构并没有本质的区别，无论是传统企业，还是互联网公司，发展到一定阶段后，都需要一整套体系化的应用架构来支撑其运转。 良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险；而混乱的、不合理的应用架构则会限制企业的快速发展，成为企业发展与变革的瓶颈。

2. 学习企业级应用架构

a. 理解企业如何运作

b. 理解支撑企业运作的成熟产品方案

c. 理解多个产品如何写作

d. 理解应用架构是随业务发展而改变的

 

3. 案例: 传统销售企业的应用架构演变

小型企业（门店~大型超市）

• 小型门店使用EXCEL管理数据。
• 中型超市使用ERP系统管理订单、进销存、财务等业务。
• 大型超市上线完整的CRM系统，使用公众号、微信群等方式进行营销

中型企业（连锁超市）

• 组织结构大规模调整
  • 成立法务部、人事部、财务部等，对业务部门进行支持。
  • 成立零售业务部，管理各个下属门店
  • 成立采购部、仓储部等业务部门， 处理公司业务。
• 使用成熟的ERP、CRM系统，企业系统革新 - 企业管理系统，跟随业务发展而进行变革（例如对N家门店进行管理） - 打通数据链路，实现数据在不同系统模块、不同部门间的传递与互通 - 完善数据存储与报表设计，上线成熟的BI分析模块 - 使用更加成熟的OA系统，做好知识库等内部管理建设，避免企业因规模扩大而信息不畅，出现管理问题

集团企业（包含在线商城、跨市连锁超市、仓储运输公司的销售集团）

• 集团业务逐渐复杂化，业务繁多且部门团队多
• 集团数据复杂，数据量大且同一套数据被多个部门共同使用，出现数据孤岛、数据维护困难等数据问题
• 早期的应用架构不合理，也不再适合新的业务模式，需要对应用架构、数据建模进行重构
• 集团企业内有多套系统，且账户、数据均未打通。部门、业务团队间的业务交互存在障碍。集团迫切需要提升中台化能力，尤其是数据中台、业务中台。

4. 通用的企业级应用架构

通过对企业级应用架构进行分层，可以更好地体现其特点和逻辑结构，我们来看一下各层的含义。

● 第一层是对外系统。 所有供企业外部客户使用的系统都在这一层，包括官网、普通用户或客户使用的C端系统。 如果是类似美团、天猫这种平台性质的企业，对外系统还会包括给商家使用的商家端。 这一层的系统处在与客户接触的最前线，是公司实现商业模式的桥头堡。

● 第二层是与C端系统对应的管理后台。 常见的管理后台都包含订单、会员、商品等模块。 每个C端业务形态都会对应一个管理后台，有些管理后台的模块可能会被抽象为公共服务，下沉到第五层，例如消息中心、订单、商品、营销等模块。

● 第三层是业务单元支持系统。 绝大多数业务的开展都不可能只靠线上的运作来实现，而要包含电话销售、客服、地推、仓配等一系列业务单元共同协作。 业务单元的运作需要强大的系统支撑。

● 第四层是职能单元支持系统。 企业发展到一定规模后，必然会有完善的职能单元作为后勤部门，来支持业务单元的运转和企业的正常运作，例如法务、财务、人力部门，每个部门工作的开展都需要相应系统的支持。

● 第五层是基础服务支持系统。 信息化建设达到一定程度后，企业有必要将通用功能服务化、平台化，以提升服务效率，保证应用架构的合理性。 这类系统主要给其他应用系统提供基础服务能力支持。目前非常火热的中台理念，实际上就是类似的思想。

● 第六层是数据底层和应用，和第五层类似，这一层主要聚焦于数据层面的统一和封装，对各个下游系统提供数据服务。大数据平台也可以和数据仓库（Data Warehouse）并列，同属于这一层。

企业级应用架构的设计建议

业务定位和边界要清晰

一套应用系统是为了解决某一类业务问题而存在的，对应某一个业务模块。 如果业务部门本身权责定义混乱，必然会导致对应的应用系统定位混乱，进而导致后续的维护、升级、管理困难。 因此，在设计业务系统之前的业务调研（详见第4章）非常重要，如果发现不合理的地方，需要和业务方一起确认、梳理清楚，再开始设计。

系统要实现松耦合、高内聚

业务的需求是在不断变化的，这要求应用系统是灵活、可扩展的。 一个扩展性强的应用系统，对外界来说，应该是简单、易理解的，与外部系统的接口应该简明、可拆解； 在系统内部，各个模块应该是高度聚合的，模块之间要实现松耦合，什么意思呢？ 可以借助汽车来理解：系统的各个模块就像汽车的轮子、发动机等组件，应该功能明确、独立、灵活（高内聚），而且各个组件通过轻松组合（松耦合）就能得到一辆完整的汽车（相当于完整的系统）。

不要让易变的新业务影响现有业务的稳定性

新业务发生变化的可能性大，失败的可能性也大，因此可以考虑新建独立的微小型应用系统来支持新业务，以避免改造成熟核心系统，影响其稳定性和健壮性。

系统之间要实现数据的单向流转

系统之间应尽量保证数据单向流转，确保数据流可回溯，这样才能保证数据的一致性和可追溯性。 混乱的数据流转会造成应用架构管理和企业经营管理的灾难。

综合考虑架构的合理性和业务发展的需要

应用架构设计的首要目标是支持业务发展。 在企业创业初期和成长时期，业务还在试错，活下去是关键，系统建设要全力支持业务，而不要过于追求架构的完美，这一点我们已经强调多次。 如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，业务已经取消或失败。 优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务需求之间做出权衡。 一方面要保证整体应用的大框架是合理的，因为如果大框架有偏差，修正的代价会非常高； 另一方面，在必要时要允许局部偏差的存在，局部偏差的修正成本是比较低的。对于某条产品线的负责人和产品经理来说，也要在架构的合理性和整体的业务需求之间做出权衡。

深入思考新系统与旧系统的关系

前面讲M集团分销平台和架构演进的时候，我们看到系统中的某些模块复用了之前的系统模块，有的则是新建的。 在实际中，新旧系统的关系是架构师或条线负责人经常需要思考的：是做一套新系统还是修改旧系统？ 新系统如何定位？ 旧系统如何调整定位？ 数据如何流转？ 系统之间如何关联？ 底层数据如何打通？ 是否要复用其他系统模块？ 是否要将某些模块抽象化、服务化、平台化？ 产品经理则要在自己负责的版块思考类似的问题，识别潜在的系统架构风险，必要时升级汇报问题，避免做出错误决策。

结后语：

本书较为关注B端企业级架构设计。有详细的B端企业级应用架构的案例。作者看上去有着优秀的企业架构设计经验。推荐对企业级应用架构感兴趣的人详细阅读。

与之相对应的，B端产品基础理论涉及的内容，讲得并不是十分详细。在此方面，推荐另一本书《B端产品必修课2.0》。

企业级应用架构，一向都十分复杂，而且至关重要。它和大型企业的管理问题直接相关。

大企业很容易产生大企业病，造成一系列类似：人浮于事、管理层级众多、信息传递受阻、很多人员远离市场，获取不了来自市场的反馈，等问题。

_同时，大型企业会产生大量的业务数据。这些数据被频繁使用。如何更有效地支持业务部门，如何形成数据积累，进行数据分析，也是很重要的问题。
_

_近年来，国内大型企业频繁讲的中台化，就是这些问题的直观体现。系统和业务，多、繁、乱，顶层应用和底层数据的频繁交互，都促使了中台化的推进。
_

这些问题都和企业级应用架构有关。大型企业的企业管理，是一个十分关键且重要的问题。

然而，企业级应用架构并无法直观地解决企业的管理问题。“知行合一”，企业级应用架构是一种很有力的支持，但本质上，企业需要做好自身的管理。而企业级应用架构就是对企业自身的管理的有效帮助。