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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 关于『精力分配值』

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

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

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

什么是“精力分配值”?

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

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

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

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

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

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

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

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

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

三、模块细节设计

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

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

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


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

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部