题主是一问带两问，先说具体的系统对接：

1、梳理业务流程，从三个维度看看公司是怎么运转的：

信息流：指订单、合同等相关信息是从哪里开始，到哪里结束，中间经过哪些角色~

物流：指原材料、产成品等经营物资，从哪里来，在哪里加工、打包、质检，最后到哪里去~

资金流：指企业的钱从哪里来（销售货款、融资等），用到哪里去（采购、营销、薪酬等）~

把这三个维度都梳理清楚了，业务模式大概就清楚了

2、定位目前的系统在上述业务流中的位置

既然要打通，就要知道哪些是可以通的，哪些是打通存在天然业务阻碍的，找准每个系统在业务中的位置。简化而言，就是看一个系统的输入、输出是什么，把输入输出与业务流对应上；

3、确定要打通的系统及信息

4、梳理数据对象、字段关系，做关系映射

再说说B端产品架构能力的培养： 

姑且认为题主所说的“产品架构”是指产品业务架构，不包含产品技术架构

B 端产品和企业的业务模式息息相关，因此第一步就是了解企业的业务模式。

如果是一个大而全的B端产品，那么：企业内部的组织架构、外部的合作生态，可能都需要考虑到。

就企业内部而言，需了解到每个组织都包含哪些角色，每个角色的日常工作是哪些，哪些是标准化的，哪些是非标准的。对于标准化的工作，就能固化为系统流程；对于非标的，可能需要提效的工具；

了解清楚每个角色的职责后，就是 抽象

每个组织，每个角色都会有一些相似的特征，也有不同的特征，把相似的特征抽象出来，做成系统的公共服务，比如合同管理，销售人员有合同，人资部门也有合同，从产品层面，就可以放到一起，通过合同类型、角色权限做区隔就可以。类似的……

所以我认为B端产品业务架构能力的培养，就可以拆分为：对企业经营逻辑理解的能力、以及抽象能力的训练。然后分别再拆分……

题主这个问题提的很不错，问出了很多产品同学的阶段性困惑。

因为从问题题干和背景描述看，题主其实面临的是一个复杂问题的拆解考验，而这时候对于瓶颈的解释被归因到了产品架构能力不足上。这是我们很多人都能遇到的情况，当面对问题一筹莫展的时候，希望能够求解于一种更高的认知水平。我们想不到这个认知水平是什么样一种状态，就被命名为“产品架构”的能力。

事实上，产品架构能力的提升是果，而我们要提升的是在架构搭建之前的能力，视野深度。

1、先明确问题

题主的背景中有个核心“希望各系统做打通”，所以其实应该回去问自己和领导一个问题：为什么希望打通？打通要解决哪些问题？不打通的话，这些问题是怎么解决的？·······

2、哪些问题“生死攸关”

3、解决这个/那个问题，需要的理想解决方案是什么？

4、解决方案下各子方案模块与现有系统的模糊匹配、匹配度如何

5、方案子模块的再聚合/解耦，就像一个组织，面临新的业务挑战需要组织协作解决。这时候你首先要明确业务目标，再屁股决定脑袋做大致分工，然后再目标倒逼能力成长，要求分工下的各人有一定能力提升

6、方案整编/流程再造/管理制度······你可以想到很多词，但基本概念一致，就是基于上述的聚合解耦，确定系统间的界面和信息流关系

7、统一界面，这一步不是必须算锦上添花，把你整合的系统整体性对外输出，比如门户、工作台等等，看具体有无需求而定。

做到这里题主的问题基本就可以解决了，而其实上述每一步都是产品同学每天都在经历的步骤。只是问题袭来，命题过大或者过于紧急，会让我们乱了方寸。

所以，遇到问题先别怂！拆拆拆！弹弹弹~找到本质很关键。

最后说下对产品架构能力的理解吧，这玩意有形的理解是画抽象的产品架构框图、房子图之类的，但是个人理解个重要的是意识层面的架构能力。这个属于道的层面，真正好的架构不止是你规划功能的能力，更在于宏观业务视野与微观产品手感的不断成熟和碰撞。

1、把模块的【能力】列举出来

包含现有的，未来规划的

2、把各个模块的【边界】给划分好

什么模块应该有什么能力，什么能力应该放在什么模块。划分模块边界的方式有很多。举例子：通过模块的使用角色，定义其功能，例如我们把所有的财务单据的操作都放在财务中心，因为其使用角色是财务。

3、确定每个模块需要对外提供的【服务】，并将服务进行通用化

例如：商品中心，需要对订单中心、仓库中心等同步商品属性数据

4、画一下【业务流】和【数据流】

多考虑一下逆向和异常

5、做完以上步骤，就会有一个基本架构的草稿图，然后剩下的就是个人经验部分了，依据业务现状、业务可能调整方向、开发成本、开发难度、考虑通用性、扩展性、考虑商业化、SaaS化……等等，对架构图进行一个合理调整

6、如果还不满意，可以参考一下竞品，看看竞品公司的规划是怎么做的，人无我有，人有我优，咨询公司也可以咨询一下解决方案

• B端产品其实也分很多种，我个人的区分标准是：一种是纯依照业务规则设计的产品，一种是包含管理体系规则的产品
• 纯依照业务规则设计的产品，例如财务总账系统，基本上就是完全按照国家财务规范设计，无论是哪个企业开发的都基本一致。这种产品甚至可以不需要产品经理，因为业务规范已经很明确了
• 包含管理体系规则的产品，例如CRM系统、供应链系统、甚至HR系统等等，这种系统对产品经理的要求简单说是熟悉业务，其实更多的是考验产品经理自己的管理能力。我在KD时，这类产品的产品经理只是负责需求收集整理，因为他们没有足够的管理能力；而收集的对象是企业的相关业务专家顾问，他们大多是有十多年相关岗位工作实战经验的决策层人物转行。做B端产品的企业有很多，仅仅一个ERP系统，OA系统、HR系统，CRM系统，每种系统仅仅国内都能数出几十家开发企业，而他们产品水平差异的根本原因，就是在于这里
• 所以题主的第一个问题：B端产品经理如何提高自己的产品架构能力 —— 答案就是让自己成为有管理实战经验的业务专家，注意，是有管理实战经验的，管理的层级越高越好。至于什么梳理业务流程等等，这些都是基本能力，你梳理的再清楚、没有实战经验，就没太大用
• 至于题主的第二个问题：如何将企业内各个业务系统打通 —— 我见过、以及自己实施过有多种方案，总体上的原则是要具体产品具体分析 —— 因为每种系统的情况不一样，例如有没有提供公开的数据字典、有没有提供公开的数据接口、甚至有没有公开或可购买源代码等等。假如你的某个主系统既不提供公开的数据字典（也就是你连表结构、字段数据含义都搞不清）、也不提供公开的数据接口、更不要说源码了，这种系统你基本上是无法将其数据打通的 —— 如果你碰上更恶心的、将大量业务逻辑写在存储过程中的，你最佳的选择就是更换一套系统 —— 做这种项目，产品经理必须有开发经验，而且是资深开发经验，否则产品经理就靠边站吧。另外，我在咨询公司时，这种项目的收费是最贵的：4000-6000元/人天（2009年时的价格），你可以问问你老板，有没有足够的预算准备再说

如果把产品架构理解为通过xxx功能完成了xxx流程，那么产品架构落地横向就是功能结构，纵向就是流程。

再具体点就是功能结构图和业务流程图。

顺序是盘点需求，确定需求的解决流程，然后从流程中抽象出功能，在把功能聚合和重新组织。

产品架构不就妥了么。

突然想起来，补充一下

推荐一本 B  端产品经理的案头书：

《系统架构：复杂系统的产品设计与开发》

https://book.douban.com/subject/26938710/

虽然还只看了两章，醍醐灌顶，久久不能忘怀！

英文好的，建议看原版

说实话，最近接手了几个项目，逐渐发现自己产品架构能力不足，现在也在思考如果提升，如何提升其余大佬都说得很实在，学习到很多，我分享个人感悟的点：

1、抽象一步是理想和现实之间一座坚实的桥梁
2、领先一步是先进，领先三步时先烈
3、系统底层都是数据库，如何把数据库连起来，最近了解到有个产品很有意思，airtable

• 1、了解现有系统形成背景：先知晓业务全貌，信息流、资金流的流转过程，数据引入与数据输出；
• 2、明了各干系人的操作项：串业务、串流程、串功能、增删改差错、数据显传；
• 3、知晓当前系统现象问题：再看业务方反馈的需求，与历史优化的版本过程；
• 4、得出产品蓝图：参考下业内成熟产品+公司业务规划面临的调整、挑战、风险；
• 5、形成产品节奏图：当前系统现状VS未来规划VS各业务方需求优先级排期，拆版本，理节奏；

就问问你自己什么时候可以变成业务专家，业务吃透，架构就有了