[摘要]在开发超市信息管理系统过程中，系统规划是第一步，也是重要的一步，根据一个超市信息系统规划开发的过程中出现的问题及针对问题提出了对应的解决方法。并且同时介绍主要超市信息系统的功能模块及组成。

广州某超市公司，在广州，上海，香港等各大城市，拥有200个以上面积超过400平方米的超市，有的面积甚至达到上千平方米，集团的超市信息管理系统，一直在运行中不断开发，修改，维护当中。本文从核心的开发、维护的角度来剖析其管理系统的结构、流程，分析问题，提出对策。

一、超市信息系统结构整个系统由三部分组成：分别是门店子系统、中心子系统、库房子系统

1.门店子系统：是提供给各超市使用的，主要的功能是管理超市中的前台POS机，并且负责对销售数据的初步整理、汇总，以及销售数据的上传、商品资料的下载等。门店子系统分为：门店后台管理系统和门店前台POS系统门店后台管理系统按功能、流程分为：(1)系统设置部分,包括了门店的人员设置、权限的设置、人员密码的修改、报表文件的管理;(2)基础数据部分,包括了商品目录、直送门店商品目录、供货商、供货商协议书、商品折让折扣、商品搭配促销、支付券信息;(3)POS管理部分,包括了POS机登记、POS使用人员权限、转换成POS数据、总销售浏览、细销售浏览、POS交接情况;(4)总仓部分,包括了门店坏货退坏品仓、总仓送货、要货管理，自动要货提示;(5)门店部分,包括了直送货上架、直送货退货、门店调场、商品报损、架存管理、商品架位信息、公文、盘点管理;(6)报表部分,包括了打印门店销售分析报表;(7)网络传输部分,包括了网络传输商品目录、网络传输要货单、网络传输销售数据。门店前台POS系统按功能、流程分为：(1)系统准备部分,包括了商品数据的更新、系统的登录清机;(2)销售部分,包括了存备用金、销售、退货、付款;(3)销售结束部分,包括了取款、取购物券、打印销售日报、数据上报;(4)其他功能,包括了交接、打印全部交接单、查询销售流水、查询单价、购物券信息。

2.中心子系统：是提供给总部的采购人员、财务人员及管理人员使用。主要的功能是销售数据的整理、归档。采购下单，促销制定，财务报表及数据分析，以及获取库房及门店方面的数据。中心子系统是整个系统的核心部分。中心子系统按功能、流程分为：(1)基本操作,登陆、选择功能、条件运用;(2)主档维护,供应商基本信息、供应商协议书、商品目录、商品其他分类、商品其他分类、商品等级、商品大类、商品小类、商品品类、商品销售单位、商品产地、配货保质期截止提前天数、配货上下限、容错商品、同一商品、价格码分类、配送扣率、门店销售级别管理、安全存量天数管理、供应商类别、开户银行、门店编号管理、门店类别、总仓类别、总仓编号管理;(3)价格管理,商品折让折扣管理、搭配促销管理、正常调价;(4)采购订货,订货单输入、订货单查询、采购推广;(5)仓库物流信息查询,中心库房库存、门店送货单、门店退仓单验收、总仓退货、入库验收查询、转仓单管理、坏品仓退货、退换到货、门店退仓商品管理;(6)架存及变价管理,门店架存（分门店）、门店架存汇总、各类变价查询（报表）;(7)销售数据查询,商品日销售、POS日销售、分门店商品销售统计、全部门店商品销售统计、销售数据分析管理、各类销售报表;(8)财务单据管理,财务进货付款管理、库房盘点管理、门店直送上架单、门店直送退货单、门店调场单、门店商品报损管理;(9)盘点管理,库房盘点查询、门店盘点单;(10)会员及公文管理,公文管理、会员卡基本信息管理。

3．库房子系统：是提供给库房人员使用的。主要的功能是货物的入仓出仓，堆叠摆放设计，以及架存的管理。库房管理系统按功能、流程分为：(1)系统设置部分,包括了修改密码、人员对应库房权限、设置人员使用权限、报表文件管理、报表（查询）权限管理;(2)中心目录查询;(3)到货入库验收;(4)商品配送门店部分，包括了门店要货单、门店配货单、门店送货单;(5)库房管理部分,包括了库房库存查询、仓位管理、商品转仓、库存备份管理、库房盘点、库房盘点原因、公文管理;(6)库房退调部分,包括了门店退仓、门店退仓验收、总仓退货、坏品仓退货、退换到货。调用报表，POS前台系统由C语言开发;门店后台系统由Delphi+InterBase开发结构;中心及库房子系统则是Delphi＋MSSQLSERVER的开发结构。

二、系统流程中出现的问题

在整个流程中在进货与销售环节出现问题，造成了架存不准。（问题主要是集中在中心系统）首要的是每个门店的架存不准，严重影响了订货的准确性，出现问题的原因：一是新货或某些商品过不了机（即POS系统辨认不出货品名称及单价）就允许售货员以一个特殊的商品号再加手动输入价格销售。二是进货渠道太多（由库房进货，或门店要供应商直接进货等）。三是系统还有些不完善。解决的方法最直接的就是盘点，但费时费力。建议每个门店独立核算，使用加盟店的策略。让各门店独立建立一个进销存的流程，独立核算，但所有的门店还是由总仓库、供货商进货或者是从其他门店调货。而中心，总部只提取汇总数据，这样各门店的架存各不影响。而根本的解决方法是在保证硬件连通，即POS机与后台系统保证连通的基础上可以实现即时更新商品目录，保证在超市销售的所有商品都可以在商品目录上找到资料。

三、在整个系统开发过程中存在的问题及解决的建议

1.开发期过长，到该超市破产停业时该程序还处于末期开发阶段。造成开发期过长的根本原因是：增加原设计以外的功能，特别是某些功能匆忙临时加上去，其危害有：

（1）造成程序代码重复。

（2）有时甚至会触发两段代码对同一数据同时进行操作，在发现数据错误时很难找出问题进行解决，经常要大量的代码阅读才能发现错误，效率低下。（3）造成时间的浪费，由于新增的功能在设计之外，要进行相关的验证，看是否对整个系统的结构性造成影响，耽误了整个开发进度，维护时也非常困难。（4）后期的开发已经是掉进“出现错误→查找原因→修改→又出现错误”的怪圈。

2.客户的需求是非常模糊的，他们无一例外要求一个功能齐全的系统。实现的主要功能他们会告诉你，但细致的环节他们就没有建议。但到系统差不多完成，或完成70％～80％，看到一个成形的系统的时候，他们的需求就非常清晰了，按要求改动基本结构的话，整个系统可谓“伤筋动骨”了。所以一个系统如果做到了80%的时候才真正明确这个系统是什么样子的话，笔者认为是设计者的失败。所以在设计阶段不但应该做好传统做法的各种文档和论证，而且，应该做一些具体的设计工作。比如，系统的整体运行设计及系统各功能模块的具体设计，而且这些设计应当都有详细的设计说明书。

3.需求与环境的变化。由于在项目开发前客户没有实质性的需求，加上软件开发人员不熟悉客户的业务，就导致在开发过程中需求的不断变化，严重时将导致分析与设计作废。现在的开发工具已经很对象化了，而我们开发的程序却很过程化。也就是说你虽然努力地模块化、层次化，可只要运行环境有所变化，你还要不断地修改再修改。比如，系统的整体运行设计及系统各功能模块的具体设计。而且这些设计应当都有详细的设计说明书。当这些说明书完成后，应当能做到：随便找个程序员他都能只通过看某功能模块的设计说明书就能够开始代码的开发，而不用再重新思考该怎样去做了，程序员在这里就真的只是一个设计者的实现工具。当然，也像某些人说的那样，现在的系统都越来越繁杂、越来越庞大、越来越向集成性质靠拢，似乎是没有多少人能掌握具体用什么方法做得更好，但关键就在这里。但目前的显示情况是，设计人员的水平偏低，有些公司的设计人员根本就没有多少开发经验，他又怎能了解太多的系统呢。

系统设计在目前看来似乎是个拿钱多干活少的工作，这是不正常的现象。培养一个程序员根本不用花多大的力气，一个人只要给他一个机会，相信就能掌握某门技术或方法。但要掌握若干种方法，就不是能够通过速成解决的了。目前似乎所有的系统设计人员都能够设计所有的东西。其实不然。很多人都有知识的局限性，这就决定他只能对某些方向的东西作出决策和设计。客户固然不知道他要做什么，但我们应该知道。如果在前期能够多接触用户、多深入实际，把设计人员当成客户工作中的一员，他就能够真正了解到客户的需求，当然也就能够为他作出合适的设计。至于说到各种系统之间的好坏对比，笔者认为任何东西都没有绝对，有的只是某些方面的权衡。比如性能或空间的权衡、价格和性能的权衡和功能侧重上的权衡等。计算机里的东西没有哪一样的存在不是包含了这种权衡在内的。虽然从商务上似乎总想说服用户什么东西好，什么东西不好，其实从技术上讲无所谓好和不好，有的只是区别及该区别所针对的问题而已。这就像有人总在争论Linux和Window到底谁好一样。或许从”技术”上讲，Linux比Window好，但这其实并不公正，因为漂亮的GUI界面和友好的人际交互同样应该是”技术”中应该考虑到的一部分。把所有的东西结合起来一看就知道没有绝对的好。所以，不见得非要在用户决定之前由系统设计的人员事先来为各种方案做个排队，只需要了解用户的需求，然后从大方向上决定一个方向再做具体设计就可以了。超级秘书网

首先，认同两个说法：

第一，项目(或说工程)有三个主要方面：功能，时间，成本。

第二，系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。

分析一下问题出在哪里：

（1)有人说系统分析员不真正了解客户的需求，可这不可能(项目时间的限制)也不现实(不可能让分析员到每个岗位都去操作一下)。

（2)有人说系统分析员的知识和经验不足，可现实却是，分析员认为应该的而客户觉得没必要，而客户觉得必须的，分析员又不可理解。

（3)有人说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方向上，掌握全部细节可能吗？这就是一个长期困扰的问题：细节(而不是方向)往往成为成功与失败的关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现与分析清楚的。

如何在这种不完整的需求上构造完整的系统呢？或是根本不可能呢？笔者认为这个过程中最不好的地方就是：把东西做死了，没有切实地为用户着想。很多的系统设计，可能考虑最多的就是实现上的快捷、方便，而不是系统的扩展及更新。要知道，用户的需求是在不断变化的，如果总是在设计前就“善意”地替用户假设，是难以预料后事的结局的。所以笔者认为，在设计阶段就因该把可能出现的问题都摆到桌面上讨论，包括其特点、效果和后果，而不是自以为是地、好心地替用户”假设”。

因此，对于此问题，笔者认为，客户要求功能的增加时，宁愿分配一个或多个开发人员，另外开发单独的小程序，就算由于功能的前后衔接而要求某些功能是重复开发，也要把该程序独立出来，制定相关的触发机制来独立于整个系统之外运行，避免以上的情况出现。然后在整个系统开发的后期把这些小程序合并成一个程序，验证以后一次把合并后的程序融合在整个信息系统之内。其实很多国外的成功的信息系统开发都不会由于客户不断提出的新要求而随便修改，添加系统功能。

参考文献:

[1（]日）北原写作论文贞辅《现代管理系统论》中国人民大学出版社北京1998年版

[2]王众托《:计算机在经营管理中应用——新的系统集成》大连理工大学出版社大连1997年版

[3]张海藩《:软件工程导论（》第三版）清华大学出版社2000年版

[4]薛华成《:管理信息系统（》第二版）清华大学出版社2001年版

[5]陈景艳《:管理信息系统》中国铁道出版社1998年版