4

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

 2 years ago
source link: https://www.woshipm.com/pd/5524654.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

编辑导语:在数字化转型的大环境下,越来越多的企业都在进行数字化转型。本文作者分享了在进行复杂数字化项目时设计产品架构的具体方法思路,讲述了产品架构过程中的注意点等,一起来学习一下吧,希望对你有帮助。

TTvQG30TVmmDFRu6NLKH.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 关于『精力分配值』

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

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

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

什么是“精力分配值”?

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

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

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

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

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

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

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

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

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

三、模块细节设计

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

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

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

#专栏作家#

边亚南,微信公众号:边亚南,人人都是产品经理专栏作家。华秉科技产品合伙人,IT东方会副秘书长,北京理工研究生,《数字突围》第二作者。专注实体企业数字化升级方案设计和私域流量运营体系搭建,擅长为企业提供全链路数字化升级解决方案,以及私域流量运营方案。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK