B端产品经理：复杂数字化项目如何设计产品架构

数字化转型背景下，越来越多的企业开启数字化转型，B端产品会接触到越来越多的从0-1搭建数字化系统的项目，这样的项目需要从0-1搭建产品架构，还需要设计模块流程，并且严重依赖业务流程和客户支持资源。

复杂数字化系统对产品架构和模块化间的逻辑处理方法要求非常高；如果模块间关系处理不清晰，到产品的后续应用环境会出现阻塞的情况，返工成本会很高。如果产品架构设计不合理，那可能会直接导致功能无法顺利实现。

那我们在做这样项目时需要注意哪些事项？有哪些参考准则呢？

一、项目初始：产品架构框架设计：三要素+三条流+精力分配值

1. 业务三元素：整体组织架构，关键角色及关键权限范围，以及关键业务要素

注意这里三元素不是指我们在系统里实现的功能，而是在客户现有的业务流程里的内容。

我们需要通过全局视角俯瞰整个项目结构时必须了解的部分；组织架构的分布情况了解清楚才可以设计权限角色架构，关键角色权限及范围帮助我们了解角色权限的颗粒度，关键业务要素让我们了解人与业务的交互关系；这些信息能让我们搭建起产品架构的第一层结构。

2. 三条流：业务流 数据流 操作流

业务流是基于数字化系统覆盖范围内的所有业务的流转流程，这个大家应该很清楚，但是在实际调研和设计的过程中特别需要注意，我们设计的系统不是将业务流程原原本本的还原出来，而是通过梳理业务流程，发现隐藏的产品架构； 产品经理要通过数字化的设计能力设计完整的产品架构。

举个例子，我们在给不同的客户设计订货业务系统时，其钱款的实际业务流程是类似的：经销商充值打款、财务审核确认、业务下单订货。

我们在设计架构时，是不是将这个业务流程直接设计出来就OK呢？明显不是，产品经理应该能捕捉到，这里有『账户体系』的结构隐藏在业务之后。

所以在设计产品架构时，我们不但要看到业务的明线，还需要捕捉到产品结构的『暗线』，保证方案的完整性。

另外还需要注意，业务流程梳理完成后转化成设计方案时，一定要结合全链条流程进行设计，否则很容易设计错误。

再拿账户体系的设计方案举个例子：业务流程相同，那是不是所有的这样的业务流程都是设计相同的账户体系内？完全不是。

我们为不同的客户设计过不同的架构体系，虽然业务流程都是一样的，但是账户体系的结构完全不同，原因就是因为后续的结算业务流程不同；所以我们做的A客户的账户体系是归属在经销商逻辑内，B客户的账户体系是归属在经销商订单内。

通过上述的流程梳理，产品的第二层架构可以细化；我们结合数据流转逻辑和关键角色的操作流程，就可以继续细化架构；

3. 关于『精力分配值』

项目调研是每个项目都要经历的一个步骤，调研的手段和方法有很多，我们会花费很多时间和精力在调研的过程中，但是我们更需要关注的是调研的目的。

我们需要通过高层访谈，业务访谈和用户访谈，获取项目关键目标， 了解关键角色以及其主要权限，获取现有的企业资源支持项目；以方便我们确认系统设计的『精力分配值』。

这里需要注意，项目的设计，并不是将客户提出的需求事无巨细的设计出来，客户需求的描述是基于他对业务的认知表达的，最后落地如何设计，是需要产品架构师进行设计的，设计的合理可以为客户有效节省成本,也就是需要提前预估好系统设计的“精力分配值”。

什么是“精力分配值”？

举个例子，我们为一个药械企业做财务数字化系统，他们做数字系统的核心诉求是3年后IPO时，系统需提供所有业务数据，且需要符合审计合规性，保证证据链的完整性。

我们通过访谈获取到核心目标，了解关键角色和关键业务，在后续设计时，就明确了哪些模块是必须要详细设计的，哪些模块可以做简化设计；这样在做项目方案时，我们结合客户的预算和目标，就可以游刃有余的提供设计方案。

二、架构细化阶段：望远镜和显微镜

经过了前期的调研，对项目的业务流程已经有了大概的了解，那我们需要对产品设计方案进行细化及逻辑合理性审查。

这个过程中，我们需要不断的从整体到局部的视角切换 审核方案的合理性。

真正到设计过程中，很多模块间的关联性非常强，如果仅关注单独模块的逻辑，则很容易造成功能不完整；所以我们需要有『望远镜』思维，不断的梳理各个模块之间的关联关系，确保任何联系的那条『线』不会缺失，保证功能完整性。

在建立模块和模块的链接后，我们需要调回到『显微镜』状态，详细梳理模块内各个业务关键点如何设计，如何和不同模块间打造通道，保证系统的完整和合理。

之前我们在设计一个客户的订货业务系统时，就使用了这种方法。

因为下单是整个系统的核心模块，中间关联着渠道价格体系，产品授权，账号，库存，审核权限，串货限制，以及信用体系和任务返利体系，在这个模块设计时，我们通过单个模块的业务流+多个模块的限制并行处理，反复的梳理模块和模块之间的逻辑，最终能够将系统完美交付。

三、模块细节设计

前期的架构设计合理，后续的模块的细化任务就简单很多，这个时候注意，方案的设计会较依赖客户的实际业务需求，所以前期的业务调研一定要做到位，如果业务逻辑梳理以及沟通有歧义，会造成方案设计方向的偏差。

还需要注意：有些设计方案设计出来后，可能会更改业务流程因为之前的业务流程，比如因为之前系统间有数据孤岛，新系统因为模块的链接和数据的打通，可能很多业务流程是可以省略的；在遇到这种情况时，大胆设计，小心验证。

尝试突破业务的限制，最大化利用数字化的优势提供价值，才是我们最终的目的。

作者：边亚南。华秉科技SaaS产品负责人，原搜狗&百度产品设计师，公众号：边亚南

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！