首先我理解的B端产品架构不是指产品的信息架构，是业务流+数据流（核心数据的定义、流转、状态变化）。例如TMS的核心数据架构是订单、作业单、运单。每一种单据类型都有各自的定义和状态，以及状态的流转。
在进行系统设计的时候，要从最完美和最理想的状态下去设计，先刨除掉现有条件的限制，放空掉基于目前自己的业务水平理解和公司的实际业务场景，考虑到以后可能产生的业务场景。将这种状态下设计出来的业务流程作为最终愿景，然后再去规划愿景中的一期二期三期，慢慢把愿景中的逻辑和流程实现。当然，一期肯定是基于现有的业务进行设计，也不要弃本逐末。
步骤如下：
1、调研：项目价值，业务场景，ROI，竞品（抄袭灵魂，而不是骨肉）
2、设计：先出框架和大体流程，业务流程先梳理清楚，再梳理系统流程。
3、规划：出版本计划，规划MVP一期，对于B端的MVP，是先把业务跑通，保证一个业务的合理性，再去优化其逻辑、结构，也就是再做二期三期。
4、设计：出PRD、产品细节、逻辑、数据口径、原型界面
例如：
重构一种单据
一期要先设计好：业务流对应的单据流状态，单据的实际应用场景和价值，单据的状态定义，单据状态的流转、触发和终结逻辑。一期的事情就是这些，把单据的框架搭好。一期是为了保证整个业务模式没有问题，把主要的功能点先上了，能跑通就好。
二期将新框架和原有的业务进行融合，并且修复之前旧框架和业务交融的点，剔除掉旧框架会有一些藕断丝连的功能或者数据，需要去解耦和旧框架的联系，再去耦合新框架的联系。其次还有之前的补丁逻辑和补丁代码，内在的替换了，脱落的补丁需要重新缝上。
三期是处理消费数据，消费原先体系的取数逻辑全部需要更改。其次是发挥新框架的价值，设计新的架构必定是存在新的价值，能实现之前架构无法实现的效果。
总结：一期地桩打牢，二期拆东补西，三期添砖加瓦，四期锦上添花
再例如：
设计一个订单的预处理，对可能产生异常的订单在进入仓库作业前进行排除或拦截。产生异常的可能原因有ABC三个，其中A占了80%，那么MVP的做法就是先做A的排除，先上线一期，实际也是这样的。但是最合理的设计是考虑ABC并将三种业务场景设计进流程和逻辑中，然后再拆解，一期实现A，二期实现B，三期实现C。如果在一期的设计中流程没有兼容到二期的B和C，就会出现到二期和三期还需要修改流程的情况。
