专业的编程技术博客社区

网站首页 > 博客文章 正文

记录搭建DMS系统(二)(dms/oms)

baijin 2024-09-12 10:59:49 博客文章 7 ℃ 0 评论

继续记录DMS系统的搭建


梳理业务现状并总结业务及系统问题后,开始进行解决问题的整体方案设计,也就是进行系统整体改版规划。


第四步:应用架构确认、功能模块优化及演进蓝图

系统改版主要目的为了解决以下问题:

① 现有主要流程根据实际业务流程进行优化,保证流程更符合实际需求

② 补充目前确实的功能模块

③ 由于要开放经销商自主下单,因此小程序前端整体页面需要重新设计来提升用户体验感


第五步:数据建模、流程角色优化

整体优化方案确认后,需要进行细节方案设计。首先,我们要对业务对象进行建模,主要是针对业务特点,归纳并设计对应的底层数据模型。

由于DMS的主要客户为公司的经销商,因此需要根据现有经销商的销售组织架构,来设计业务数据模型。


考虑到需要开放下单给经销商,同时愿意继续让销售进行代下单的话,代下单流程还是需要保留,因此在核心下单流程中需要增加经销商自主下单和保留销售代下单两套流程。

代下单功能修改为可单独为某个经销商开放或关闭。


第六步:其他细节设计及编写文档

① 页面流转

首先需要重新梳理页面流转,主要是用户完成某项工作需要访问的页面及页面跳转顺序。在做页面流转之前,需要先梳理需要开发的页面,如下图:


当我们将待开发页面梳理完成后,即可做页面的流转示意图,如下图:


② 原型界面设计

页面流转图完成后,开始进入原型设计阶段,绘制线框图原型来表达系统中每个页面的设计需求

③ 权限设计

系统权限主要包含两部分

首先是功能权限:

由于多组织多部门多人员使用本系统,且每个部门权限不一致,因此菜单权限在设计的时候,需要细化到每个页面菜单也页面上的操作元素,以方便设置不同角色对应的细节。如下图:



其次是数据权限:

数据权限一般可通过组织机构树或客户地区控制,当然更重要的是需要根据业务部门实际需求进行设计。

本系统需要根据销售部门的组织架构,按经销商归属销售,销售归属部门进行数据权限管控→通过sap获取销售与经销商的归属关系后,在DMS创建销售部门组织架构,通过组织架构节点关联管理账号进行数据管控。

④ 其他细节设计

状态机图:由于系统中各流程牵涉到的状态比较多,因此可以进行个流程的状态机图设计,以方便描述所有状态之间的流转规则



用例图:主要用来描述某个角色或用户在不同场景下能做什么


数据埋点

由于系统更多的使用者可能是销售团队,因此销售运营要求无需做用户行为分析,本系统不做数据埋点工作。实际产品只要涉及到用户行为分析,都需要进行数据埋点工作

一般前3步主要由研发人员负责,产品经理重点参与第四步

web端埋点工作可以使用GA或百度统计

移动端埋点工具可以使用神策或GrowingIO

⑤ 编写文档

当整体方案及细节方案设计完毕后,需要进行PRD文档编写。个人习惯将文档内容编写至axure文件中,按以上流程进行每一步记录与说明,最终形成PRD文档;可通过发布至云服务,方便团队协作查看。

第七步:需求沟通会(立项会)

当PRD文档编写完毕后,产品经理前期的工作告一段落,接下来需要与团队进行需求分析沟通会,主要沟通整个产品方案及求确认技术方案。不同公司的立项沟通会内容会不同,本次沟通会中确认以下内容:

① 沟通并确认清楚整体规划中各个细节模块

② 确认需求优先级及排期

③ 确认技术方案

④ 确认开发人员的具体工作安排


第八步:实施整体改版计划

需求沟通会结束后,将按沟通会上确认的内容,开发团队进入研发阶段。此时产品经理需要做的主要工作就是跟进开发进度,日常开发中与开发人员保持沟通,随时进行开发过程中疑问或细节的把控,推进整个项目按规划的进度执行。

开发阶段结束后,进入测试阶段,产品经理需要协助测试工程师进行个阶段测试,保证开发内容符合需求,并能按要求进行分阶段发版上线。


后记:

在整个改版过程中,遇到各种各样的问题,不管是因为公司原因还是其他原因,都需要产品经理在过程中不仅仅要解决系统设计问题,还要解决或优化各种流程、沟通上存在的问题。

其实解决问题的重要途经之一是沟通,而沟通需要遵循一些基础原则,比如:理性、对事不对人、同理心、层次分明逻辑严密、正视客观现实、从自我的圈子中跳出来、尽量少用所谓的行话等等。日常工作中提升自己的沟通能力,对于产品经理来说是至关重要的。

啰嗦了一大堆,将DMS系统的打造进行流水账记录,主要是整理下自己的思路,促进自己不断的思考和改进,同时也希望可以达到相互交流的目的,大家共勉~

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表