业务需求的分类
我们上次讨论了从采购系统的职责的“采购订单六要素”如下图所示:
从狭义上来讲,采购本质上主要就是关注“谁来采”、“采什么”、“采多少”、“找谁采”、“如何到”、“多少钱”。上次给大家从业务的角度介绍了六要素以及可能的一些业务场景。这些描述主要是告诉大家采购订单主要在做什么。主要做什么就是告诉大家基本的功能是什么。在这里我想和大家说需要软件需求的集中分类,这个对于我们后面理解系统设计是非常有好处的。
对于业务需求,我们一般可以分为以下四类,如下图所示:
业务系统基本功能驱动:一般都是功能级别,解决业务信息共享以及基本功能的实现,基本上由业务工作流和功能的增删改查组件。主要承载业务流程和数据共享。核心价值是提供了业务流程和功能的基本诉求,提高信息共享和数据存储和使用效率。
系统使用问题驱动:一般都是功能级别,使用问题驱动,靠业务问题 反馈,需求呈现散状、颗粒度小、自下而上,研发处于被动接受,无法规划和预测。核心价值是提供了解决业务使用系统问题的方案,提高业务部分执行效率。
业务模式调整驱动:一般都是独立业务级别,随业务模式变化而进行系统调整,需求呈现随机状态,无法长期规划。使系统适应业务变化,提高执行效率。
业务核心能力驱动:通过对于业务深刻的认知,自上而下进行规划,将业务核心能力转化业务数字化 核心能力,提供订货业务决策,输出核心业务能力,系统参与部分决策,提效业务决策效。
四种不同的需求,其中业务系统基本功能驱、系统使用问题驱动和业务模式调整驱动,一般都是就是我们经常性说的功能性需求,业务基本上显性提出来。而业务核心能力驱动,一般我们叫做质量需求,一般都是隐含需求,业务或者用户不一定能够说出来。质量需求中对于技术来说考虑最多的就是系统性能,例如:TPS和QPS等等,这些都是技术指标,但是还有一种的质量需求,可能很容易被忽略,那就是如何去思考业务上的好,我们系列文章的主题,“如何设计一个好的采购系统”,其中好就是质量的诉求。因此,在这里对应的是我们的业务核心能力驱动。我们把采购系统的好,定义为了:
1、能够根据采购业务诉求和采购策略,做到采购订单的时效、成本和订单满足率的最优。(注意,这里说的是针对采购订单,而不是单个商品明细的最优,需要考虑整体订单的维度)
2、能够自动识别好的供应商,淘汰差的供应商,让供应确定性提高
3、不能出现由于结算错误引起的资损或导致下游系统出现资损,因为与外部有交互,可以识别已知的采购业务风险。
因此,采购订单的时效、成本和订单满足率的最优,提高供应确定性,避免资损就是采购的业务质量指标,这些业务质量指标需求,需要我们在深刻理解业务的基础上,将这些质量需求抽象出来成为系统设计需求,这些质量需求一般业务人员很少或者通常是不会说的,可能这些诉求隐含了在业务的KPI指标中,但是很少业务会在首次以及系统化、结构化、显性化的提出来。
对于信息化与数字化的区别这里我们进行一个简单的区分,如下图说是:
如果对于以上比较感兴趣的同学,可以去看看我的数字化系列文章,那里面有更详细的介绍,以下是相关链接:
企业数字化不装逼系列(二)- 你绝对想不到的为什么要数字化转型
我们为什么把功能需求和质量需求花一定篇幅和大家说下,是因为以下的描述中,我们会区分出那些是功能性的需求和那些是业务质量的需求。功能性需求就是刚性,有和没有的区别。质量的需求相对来说是柔性的,好和不好来区分,是不同的两个维度。
采购系统总体架构
如果从采购系统整体角度来看,采购可以分为以下子系统,如下图所示:
采购系统L0架构图
采购需求中心:业务部门对于采购的需求,S&OP计划、开店闭店计划、缺货记录等需求,这些都可能需要对外进行采购诉求,因此,我们把这些业务的部门的可能的采购诉求,统一抽象为一个对象,这个对象就是“采购需求”,任何业务部门或个人都可以提出采购需求,这样设计的好处就是采购需求是对内统一的采购诉求的收口,对于采购需求可以进行标准化。
采购主数据管理中心:
什么是主数据?
主数据(Master Data)是指在一个组织内部跨多个系统、应用程序和业务过程中共享、使用和维护的关键业务实体的核心数据。这些数据通常包括客户、产品、供应商、员工和其他重要的业务对象的信息。主数据的目的是确保数据在组织内的一致性、准确性和可靠性。
主数据的特点是不依赖于某个具体的业务流程,但却是主要业务流程都需要的。主数据的核心是反映对象的状态属性,它不随某个具体流程而发生改变,而是作为其完整流程的不变要素。
采购主数据主要包含了:
-
供应商相关主数据:包括供应商的基本信息、付款条件、交货条件、采购组织信息等。
-
采购订单相关主数据:记录了物料或物料组和供应商之间的关系数据,包括订单单位、订单价格、供货日历、发货仓库、税码、有效期、起发规则等信息。
-
物料主数据:涉及物料的基本信息,如物料代码、描述、分类、物料清单等。
-
采购寻源数据:涉及供应商的选择和评估过程。
-
合同主数据:涉及与供应商签订的合同条款和条件。
采购计划中心:包含了采购预算、各种业务类型的计划单,例如:囤货计划、S&OP计划、开闭店计划、新品开发计划等,都会涉及到后续采购相关诉求。
采购订单管理中心:采购订单、采购预付单、采购订单审核等功能,主要是围绕采购订单制单、确认、交付的管理。
采购协同中心:与供应商进行业务协同、管理协同、数据协同的平台。业务协同包括:供应商注册、订单管理、发货管理、物料管理等,管理协同主要包括:供应商绩效相关的管理,数据协同主要包括:销售数据、库存数据、商品数据等与供应商的互联互通。
采购结算中心:与供应商相关的结算规则、对账管理、付款管理、发票管理等,这部分由应付系统来进行承担相关的系统职责。
采购能力中心:采购业务能力中心,寻源业务能力、风控业务能力、对账稽核业务能力、供应商绩效评估能力、订单执行效率分析能力、采购需求采集能力等,这个就是之前和大家一起讨论的内容,把这些核心的业务能力抽象为系统能力。
采购系统L1架构图
针对采购系统L1架构图,我们可以更加细节的看到采购系统中各个系统组件的所承担的功能需求和质量需求,其中灰色部门的采购需求中心、主数据管理中心、采购计划中心、采购订单管理、采购协同管理中心以及结算中心都是功能性需求,而采购能力中心,则是对于质量的诉求,也就是核心业务能力的抽象,基于业务核心能力抽象后实现的系统数字化能力。如下图所示
关于模块之间的关系如下图所示:
以上采购系统主要还是偏向于采购订单的制单、审核和交付,这也是系统架构的片面性所在,因为在我们经历过大多数企业咨询中基本上都是围绕着订单展开,也是比较有代表性的。
写在最后的话
本篇是采购系统设计的最后一篇文章,采购系统的设计和需求分析不仅关注于订单的制单、审核和交付,还需要深刻理解业务,将业务核心能力转化为系统设计需求,以实现业务的数字化转型。这涉及到对业务流程的深入分析,以及对业务质量指标的识别和实现,从而提高采购效率和决策质量。希望大家能够在采购系统设计系列文章中有一些小小的收获,我就非常满意了。