前言:
归纳总结是个好习惯,我们都值得拥有.
每一个业务的开发需求,都是一次归纳的契机.
根据业务特定的需求分析,是否可以概括出一个通用需求?
特定业务需求是否完全包含在这个通用需求中呢?
是否可以根据这个通用需求概括出一个通用处理模型?
该模型是否可以解决这一类的业务需求?
怎么用特定的语言(ABAP)开发这个模型?
怎么给业务最大的自由度去使用这个配置使用这个模型?
如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)
如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)
或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.
尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.
正文
列表-SAP零售版本的一个功能.
站在业务角度,它是一个商品分配到门店的过程,
站在技术角度,它是商品扩展视图的一种方式.(理论上,也可以关闭系统的列表功能,使用其它方式去扩展商品的视图)
使用过SAP 零售版本的可能都在上线过程碰到过这个问题:标准列表程序执行的实在是太慢了. 如果企业有1万个门店, 1百万个商品. 需要耗时多久?根据一组企业列表的真实数据预估. 大概需要15天-170天之间. 这个预估模型过于简单.假设按照最快的速度计算,需要15天,考虑纠错,差不多需要20天左右.
货号(款)商品数(变式商品)门店数列表执行时间(秒)单位货号门店耗时(秒)预计耗时(天)10,146101,46021231,6920.014733941170.531713,566135,6602138,1380.00281634832.5966211,583115,83021436,1540.014585507168.813713,680136,80021544,2400.01504148174.09129,21792,1702162,6490.00133057315.40015
(备注:上图列表执行过程已经考虑了多进程并发执行,并且应用了绝大部分的NOTE中提供的优化方案)
那么怎么能改进列表的速度呢?
SAP提供了一系列的NOTES.用于改进列表速度.但是效果都不太明显.究其原因:SAP是一个严谨的系统,所以在商品主档中存在很多的检查,验证逻辑. 这些逻辑是无法优化掉的, 所以列表性能始终无法有效改进.(升级HANA数据库对列表的改进也不明显).
从业务角度,商品数无法减少, 减少门店数就是一个有效的方法. 把区域公司定义成门店, 门店定义为区域公司的库位. 这样做,大量减少了门店数. 间接解决了列表的问题. 但随之而来的是业务问题:移动平均价是按地点计算的. 这个方案导致区域中所有门店的成本完全一致. 并且与标准retail解决方案相悖,需要开发一系列的增强解决各种相关问题.
还有一个思路就是改写列表逻辑,分析标准列表的结果.根据列表的结果涉及的表及写入的内容,自定义程序直接写表.
方案3看起来有点疯狂, 但是存在一定的合理性和可行性. 使用结果导向过程,再通过业务测试验证结果. 实际应用中, 也确实解决了列表的性能问题. 并且通过了盲测: 一组数据使用标准列表, 一组数据使用方案3列表. 在实际业务执行过程, 系统对两组数据表现为无差异.
SAP提供的标准列表功能很多,核心方式都是一样的.
门店分组(参考门店,门店分类)
商品分组(商品类目,模块中分配商品)
关联门店分组和商品分组
根据关联最终构造商品和门店的关系.
自定义列表功能中也使用了一组配置表,去关联商品+地点.用于辅助业务构造把商品分配到地点的规则.
SAP开发框架系列是我对开篇前言中问题的解答,这个系列提供的是一种思维方式,有些涉及到的代码/工具,会在后续文章中陆续发布.
