主题：【原创】我给SCM软件开发商提的需求清单1 -- wqnsihs

以我的工作经验来看，M总的这个系统很庞大，不是短期能搞定的。我也做过一家大型企业的的分析支持，主要接触的是该系统的库存，预测，订货，商店布置，销售模块。该公司的配送中心与商店共有两三千家。上述任何一个子系统都很大，支持团队是百人级别的。开发演化至今都几十年了。

就拿这里最简单的商品编码来说，这就是一件非常繁杂的事情。从我应用的角度来说，系统设计之初就应该考虑长远的需求。我所在的公司所有的商品都需要有编码，商品编码是有专人负责的，该公司是自己一套编码体系，这本身就是一个子系统，他们是分为部，类，子类，型号，项这五级。系统设计之初，只有部，类，项三级，结果后来发现不够使用。因为很多程序是按三级编写的，推倒重来代价就大了，只好用修补的办法，但这样一来数据的结构就不够干净。类似的情况是很多的。另外，编码是不是重复使用？这也是一个问题，因为有些商品，如服装，常常几个月后就不再销售了，今后也不会有同一种产品出售，因此重复使用编码似乎没问题，但后来发现，这对一些应用带来了不便，比如查找销售历史数据就很麻烦（公司经常有法律诉讼，需要历史资料证据等）。

库存管理：这又是一个庞大的系统，我不知M总企业使用什么软硬件，反正我接触的系统相当大，IBM的那套系统，还是感觉不够用，一个大点的数据库表就几百个G，所以只能存储每个周末的瞬时数据，都无法看每天的结束状况。做个大点的分析，仍然需要数小时运算。对大型企业来说，WEB只能作为用户界面，后端的软硬平台要求很高。

公司的库存水平控制是与预测模块（又一大块子系统！公司使用专用软件）紧密相连的，而预测模块需要销售历史作为依据，每周微调。

我感兴趣的是数据仓库与挖掘方面，因为公司数据浩如烟海，各个系统之间联系有的松散，有的紧密，报表常常出现不一致，这又是许多公司的通病，如何在不影响公司业务的情况下，尽量整合各个系统的数据，利用数学与统计的手段，进行各种

分析，从中挖到金子，是很有意思的一个方向。我看就算美国，很多公司这方面还是刚刚起步。河里这方面的大牛们能否交流一下。