接下来一段时间,打算做一个有关软件产品设计的系列推文。
今天这一篇先从大家最常见的——如何处理功能的分与合说起。
注:为了聚焦,我们这边谈的还是以2B软件为例。
先从一个例子,带大家热热身哈
一个订单功能,有个属性信息叫订货类型(属性值:期货、现货);还有个属性信息叫客户名称(属性值:A公司、B公司…)
这两类最常见的属性信息,我们要分别通过什么功能载体来承载它们?
想好上面的问题后,我们再来个进阶的问题:一个公司有可能是我们的客户,也有可能同时是我们的供应商,我们又要怎么处理这类基础信息?
好,今天的功能分与合设计,就从上面的两个问题说起。相信讲完后,下次你遇到这类问题,就知道怎么处理此类问题的产品设计。
基础数据和主数据的区别?
我们先对这两者进行定义。以下定义参照《华为数据之道》
基础数据:通常是静态的(如国家、币别),一般在业务事件发生之前就预先定义。它的可选值数量有限,可以用作业务或IT的开关和判断条件。
主数据:是参与业务事件的主体或资源,具有高业务价值、跨流程和跨系统重复使用的数据。比如客户、商品、供应商、组织、人员等。
有了统一的认识后,下次你再看到一个信息时,就基本能判断它属于哪一种?
接着我们来说说一般如何处理基础数据、主数据的功能设计?
基础数据,一般是些通用的信息(比如上面说的国家、币别,适用于各行各业),要么是信息化的过程中经过抽象了的配置项(比如订单类型),不论是哪一种,每类基础数据的取值范围都是有限的。
这类信息一般由系统管理员统一负责,它可以看成是系统管理员的一个配置中心,所以可以考虑合并在一个功能和数据表内。
在系统中,通常用数据字典的形式来承载,如下图
主数据因为对应具体的业务数据,数据量是不断递增,且不同主数据的管理者不同,所以不论从数据库的设计考虑,还是系统权限的分配考虑,都应该把不同的主数据分开成独立的功能和数据表。
通常用主数据的形式来承载,如下图
讲完基础数据和主数据的区别,我们应该就知道怎么区分和设计。
主数据的分与合
基础数据和主数据有明确的定义区别,大家只要搞清楚,就能快速做出判断到底属于哪一类?
我们遇到的另一个棘手的问题是像企业、人员等主数据,当它们叠加了业务特性后(比如一家企业可能是我们的客户,可能是我们的供应商,还有可能两者都是),就陷入分与合的两难境地。
在这里还有一个新的问题:以上面的例子来说,一家企业如果有两种身份,那么在后面的财务账款统计上(我们对这家企业既有应收,又有应付),当需要以企业为维度来看时,如果前期没有处理好分与合的关系,这时又带来无法统计的问题。
这里我们说下主数据合并的原则:如果存在汇总统计的需求,建议先建立一个合并的主数据基础信息
那还需要考虑将客户和供应商分开成两个主数据吗?
先上结论:如果客户和供应商有各自的属性信息,且由不同人负责管理,就应该考虑再分成两个主数据。
原因是:当它是客户时,我们除了上面说的主数据基础信息外,还会有销售相关信息(比如采购联系人、进项税率);当它是供应商时,同样除了上面说的主数据基础信息外,还会有采购相关信息(比如销售联系人、销项税率)
而企业的销售和采购部门往往是分开的,他们负责各自客户或供应商的信息维护。
这和我们前面讲的主数据分开原则又对应了:主数据因为各自对应具体的业务属性不同,且不同主数据的管理者不同,所以不论从数据库的设计考虑,还是系统权限的分配考虑,都应该把不同的主数据分开成独立的功能和数据表。
单据功能的分与合
讲完主数据后,我们再来看个更高阶的问题:单据功能又要如何考虑分与合?
以订单这种最常见的单据功能为例
按订单的订货类型可分为期货、现货;按订单的客户类型可分为国内、国外;
按订单的商品/服务类型可分为商品、服务。
这么复杂的情况下,我们如何设计订单这类单据功能?
答案是先找出不同类型的订单的共同属性信息,再找出它们之间的明显差异信息。
所有的订单都有单据编号、日期、客户、付款方式、订单成交金额、商品/服务明细、收货/服务地址、联系人等共同属性信息。我们将这些信息作为共同信息。
再来看这些订单的差异信息:
期货和现货的区别,一般只是商品的销售价不同,差异点在于商品的计价规则不同,这个属于订单上的一个计价功能,不影响数据库设计;
国内和国外订单的区别,这往往就有较大差异,国外订单需要增加记录货代、船公司、海关等信息,这样我们对于国内和国外订单在单据功能的页面呈现就有较大区别,后台数据库设计就需要对国外订单增加不同的子表去记录上面说的信息;
商品和服务类订单的区别,举个比较典型例子:美团。一开始美团提供的是生活服务,现在也做起了电商。我们在美团这个APP上通过不同的入口选购商品/服务。每个入口的订单是分开的。那么如果我们是美团的后台产品经理,我们要怎么样设计我们内部系统的订单功能?
商品和服务的区别主要在于交付过程的区别,商品的交付是即时完成(比如骑手把商品送到),而服务的交付是分阶段完成(比如洗空调,系统先生成核销码,师傅上门清洗后再完成核销,这笔服务订单才算交付完成)。以这个为例,我们就要在订单的交付处理上做不同的设计。
完成上面的分析,我们就能设计出订单的基本信息,也能对不同类型的订单添加其特有信息。
总结
讲到这,我们稍微总结下两个原则
合并原则:
1.凡是有合并统计数据的需求
2.凡是同类用户负责的一类业务活动
分开原则:
1、不同的业务活动
2、不同的用户负责
如果你足够仔细,你会看到我们上面的设计原则都离不开数据库设计的考虑。这对于非IT行业从业者不容易理解,但做产品设计确实需要具备基本的数据库常识。
关于IT行业产品经理这个岗位的讨论,众说纷纭。但如果你要做产品设计这类落地的工作,最后我们还是回到软件的本质:软件程序=数据结构+算法
如果你对产品设计的这篇推文有兴趣,欢迎点赞、转发。
创业项目群,学习操作 18个小项目,添加 微信:923199819 备注:小项目!
如若转载,请注明出处:https://www.zodoho.com/86623.html