超市信息管理功能分析論文

前言：本站為你精心整理了超市信息管理功能分析論文范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

[摘要]在開發超市信息管理系統過程中，系統規劃是第一步，也是重要的一步，根據一個超市信息系統規劃開發的過程中出現的問題及針對問題提出了對應的解決方法。并且同時介紹主要超市信息系統的功能模塊及組成。

廣州某超市公司，在廣州，上海，香港等各大城市，擁有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.需求與環境的變化。由于在項目開發前客戶沒有實質性的需求，加上軟件開發人員不熟悉客戶的業務，就導致在開發過程中需求的不斷變化，嚴重時將導致分析與設計作廢?，F在的開發工具已經很對象化了，而我們開發的程序卻很過程化。也就是說你雖然努力地模塊化、層次化，可只要運行環境有所變化，你還要不斷地修改再修改。比如，系統的整體運行設計及系統各功能模塊的具體設計。而且這些設計應當都有詳細的設計說明書。當這些說明書完成后，應當能做到：隨便找個程序員他都能只通過看某功能模塊的設計說明書就能夠開始代碼的開發，而不用再重新思考該怎樣去做了，程序員在這里就真的只是一個設計者的實現工具。當然，也像某些人說的那樣，現在的系統都越來越繁雜、越來越龐大、越來越向集成性質靠攏，似乎是沒有多少人能掌握具體用什么方法做得更好，但關鍵就在這里。但目前的顯示情況是，設計人員的水平偏低，有些公司的設計人員根本就沒有多少開發經驗，他又怎能了解太多的系統呢。

系統設計在目前看來似乎是個拿錢多干活少的工作，這是不正常的現象。培養一個程序員根本不用花多大的力氣，一個人只要給他一個機會，相信就能掌握某門技術或方法。但要掌握若干種方法，就不是能夠通過速成解決的了。目前似乎所有的系統設計人員都能夠設計所有的東西。其實不然。很多人都有知識的局限性，這就決定他只能對某些方向的東西作出決策和設計?？蛻艄倘徊恢浪鍪裁矗覀儜撝?。如果在前期能夠多接觸用戶、多深入實際，把設計人員當成客戶工作中的一員，他就能夠真正了解到客戶的需求，當然也就能夠為他作出合適的設計。至于說到各種系統之間的好壞對比，筆者認為任何東西都沒有絕對，有的只是某些方面的權衡。比如性能或空間的權衡、價格和性能的權衡和功能側重上的權衡等。計算機里的東西沒有哪一樣的存在不是包含了這種權衡在內的。雖然從商務上似乎總想說服用戶什么東西好，什么東西不好，其實從技術上講無所謂好和不好，有的只是區別及該區別所針對的問題而已。這就像有人總在爭論Linux和Window到底誰好一樣?；蛟S從”技術”上講，Linux比Window好，但這其實并不公正，因為漂亮的GUI界面和友好的人際交互同樣應該是”技術”中應該考慮到的一部分。把所有的東西結合起來一看就知道沒有絕對的好。所以，不見得非要在用戶決定之前由系統設計的人員事先來為各種方案做個排隊，只需要了解用戶的需求，然后從大方向上決定一個方向再做具體設計就可以了。超級秘書網

首先，認同兩個說法：

第一，項目(或說工程)有三個主要方面：功能，時間，成本。

第二，系統分析的任務：將用戶的業務邏輯轉化為程序邏輯，計算時間和成本。

分析一下問題出在哪里：

（1)有人說系統分析員不真正了解客戶的需求，可這不可能(項目時間的限制)也不現實(不可能讓分析員到每個崗位都去操作一下)。

（2)有人說系統分析員的知識和經驗不足，可現實卻是，分析員認為應該的而客戶覺得沒必要，而客戶覺得必須的，分析員又不可理解。

（3)有人說系統分析員的水平不夠，可問題絕大部分是出在細節而不是大方向上，掌握全部細節可能嗎？這就是一個長期困擾的問題：細節(而不是方向)往往成為成功與失敗的關鍵(注意，這里的成功是包含了時間和成本的)，而細節是不可能全部發現與分析清楚的。

如何在這種不完整的需求上構造完整的系統呢？或是根本不可能呢？筆者認為這個過程中最不好的地方就是：把東西做死了，沒有切實地為用戶著想。很多的系統設計，可能考慮最多的就是實現上的快捷、方便，而不是系統的擴展及更新。要知道，用戶的需求是在不斷變化的，如果總是在設計前就“善意”地替用戶假設，是難以預料后事的結局的。所以筆者認為，在設計階段就因該把可能出現的問題都擺到桌面上討論，包括其特點、效果和后果，而不是自以為是地、好心地替用戶”假設”。

因此，對于此問題，筆者認為，客戶要求功能的增加時，寧愿分配一個或多個開發人員，另外開發單獨的小程序，就算由于功能的前后銜接而要求某些功能是重復開發，也要把該程序獨立出來，制定相關的觸發機制來獨立于整個系統之外運行，避免以上的情況出現。然后在整個系統開發的后期把這些小程序合并成一個程序，驗證以后一次把合并后的程序融合在整個信息系統之內。其實很多國外的成功的信息系統開發都不會由于客戶不斷提出的新要求而隨便修改，添加系統功能。

參考文獻:

[1（]日）北原寫作論文貞輔《現代管理系統論》中國人民大學出版社北京1998年版

[2]王眾托《:計算機在經營管理中應用——新的系統集成》大連理工大學出版社大連1997年版

[3]張海藩《:軟件工程導論（》第三版）清華大學出版社2000年版

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

[5]陳景艷《:管理信息系統》中國鐵道出版社1998年版