本页目录

B端方法论在哪些场景下会失效

适用区间：流程已经稳定的企业管理场景

杨堃的四层方法——业务建模、数据建模、权限建模、交互设计——有一个隐含前提：业务流程是相对稳定和可描述的。

这个前提在传统企业管理系统中几乎总是成立。采购审批、仓储管理、财务结算、人事考勤——这些业务跑了很多年，流程虽然复杂但有章可循。方法论的价值恰恰在于把这些已有流程系统化。

适用信号：客户能画出自己的业务流程图（哪怕是手画的白板图），能说清"我们现在是这么干的"。有这个条件，四层架构就有用武之地。

创业公司做一个新品类的B端产品时，业务流程还在快速变化。今天的审批规则下个月可能推翻，核心数据实体两周后可能重新定义。

这种情况下，花两周画完善的业务流程图和数据模型，不是严谨，是浪费——因为画完就过期了。更合理的做法是先用最小可行产品验证业务逻辑是否成立，等流程基本稳定后再按四层方法做系统化设计。

识别信号：如果业务方自己都没法一致地描述"我们的标准流程是什么"，说明业务还没定型，不适合直接进入完整的B端产品设计流程。

四层架构需要投入——业务走查、流程图绘制、数据建模、权限矩阵、交互设计，每一层都需要时间和专业能力。

三五个人的小团队做一个内部工具，如果严格按照四层架构走完全流程，可能光是建模就花了一个月。对于一个使用场景明确、用户量有限、生命周期可能只有半年的内部工具，这种投入不划算。

判断标准：如果产品的预期用户不超过50人、业务场景不超过3个主流程、预期生命周期不超过一年——可以简化方法，先做核心流程，权限做两级就够。

方法论假设组织行为是可以被流程图描述的。但有些组织的实际运作方式和书面流程差距很大——审批名义上走三级，实际上老板一个电话就定了；数据权限规定了部门隔离，但核心信息通过微信群在各部门间自由流动。

遇到这种组织，产品做得越严谨，上线后的使用率反而越低。因为系统强制执行的规则和组织的真实运作方式打架，用户会绕过系统完成工作。

识别信号：业务走查时发现"实际操作"和"制度规定"经常不一致，而且管理层对这种不一致持默认态度。这种情况下，系统设计需要先理解"潜规则"，而不是只映射"明规则"。

几个值得警惕的信号：

业务方反复说"你先做着，我们的流程也在调"——说明业务还没稳定到可以系统化的程度。

需求评审时发现权限规则怎么定都有人不满意——可能不是权限模型的问题，是组织架构本身在调整。

上线后用户大量使用"备注"字段而不是预设字段——说明数据模型没有捕捉到实际业务的关键信息维度。

出现这些信号时，不要试图用更精细的方法论去硬磨。退一步，重新评估业务成熟度和组织配合度，可能需要回到业务调研阶段，或者调整产品的定位和边界。