從0設計開發乙個進銷存系統的實踐經驗總結

2021-09-13 03:44:01 字數 2397 閱讀 2286

最近在開發一家外貿公司的進銷存系統,小微企業,年銷售額在百萬左右,這是我第一次開發進銷存系統,沒有相關經驗的我覺得這套系統並不會那麼複雜,但實際上它的複雜性被大大低估了。

恰恰就是這種外貿的小微企業,小訂單會特別多,每天幾乎都有數十單,乙個訂單裡面可能會有幾十個型號,總金額從幾十到上萬的都有,銷售商品包括幾十種大類,500多種型號,客戶更多達500+,可想而知之前用excel管理起來有多困難,說實在點,原來可能就沒辦法管理或沒管理,所以迫切地希望能有一套系統來把各個資源要素整合起來進行統一的規範化管理。

這家企業的負責人告訴我,他們用過好幾家現成的系統,都難以達到他們理想的效果,歸根結底還是與他們業務不夠契合。

為什麼會這樣?大部分軟體公司的銷售一般做法都是拿自家產品去套客戶需求,套住乙個是乙個,這種做法往往就沒辦法滿足個性化的業務需要
大**中醫博大精深,借用其綱領,就是「望聞問切」,在系統開發上也一樣適用。

「望」:親自看,看看企業到底什麼規模,人員有多少,組織架構是什麼,有沒有已經使用的系統或工具?看看他們每天都在幹什麼。當然,前提是你有這個機會去到企業。

「聞」:多傾聽,傾聽企業負責人的想法,傾聽管理人員和員工等各個層面的需求,傾聽不是一味地接納,乙個有經驗的開發者是能甄別出哪些是真需求,哪些是偽需求的,如果你沒有相關經驗,那麼在後續要進行調整。

「問」:善溝通,首先要確認企業的代表也就是對接人,這一點非常的重要!所有的問題都與對接人溝通,此人一定要對該企業的核心業務非常了解,而且系統的建設全權由此人負責,結合望、切、聞綜合分析,與對接人進行系統開發方面的溝通。

「切」:多實踐,好的產品在於不斷的打磨,任何系統絕不可能一步到位,往往功能在設計與實際使用中的差別會很大,對於像我這樣第一次開發這種系統沒少進行重構,如果功能沒有達到企業要求,或者不夠完善,果斷進行重構,不然程式的**只會變得越來越臃腫,改動的代價越來越高。

這四種方法沒有絕對的先後順序,在專案的實施過程中不斷的穿插進行。

現在系統基本已經開發完成投入實際生產了,這裡就以我目前碰到的實際問題來說一下進銷存系統複雜在**。

首先說明一下這裡的複雜不同於面向大眾消費端的應用,由於使用者數量侷限在企業內部,所以我這裡暫時還沒有碰到效能問題。

這種系統的複雜度分為兩大方面:業務和資料

要設計乙個業務契合度高的系統就要把該企業的業務了解的盡可能的全面和透徹,小微企業的業務流程一般都比較雜亂和靈活,首先要做的就是要把流程固化下來,起初並沒有直接與該企業**具體的功能實現,而是把他們所有的業務流程按照系統功能劃分成了六大模組做成了excel**,然後與對接人溝通,看看這六大模組是否能涵蓋所有的業務流程。

確定了模組後,進一步確認模組下的具體功能,詳細了解該功能應滿足什麼樣的業務場景,業務流程是如何運轉的等。

這裡通過訂單管理來簡單的說明一下,基本的訂單管理都有新建、修改、刪除的功能,訂單中會涉及到商品、數量、與金額,比如新建的訂單商品要不要出庫,是新建訂單時直接出庫還是需要主管審核後再出庫?訂單什麼情況下可以修改,如果修改了該訂單中已經出庫的商品,是否需要作廢該訂單中這個商品,如果作廢還要恢復作廢商品的庫存等等。
類似這樣的業務需求會有很多,在確認功能時最好能窮盡每乙個需求項。

上面提到的這種業務需求在實際開發中不可避免,後期也會不斷的冒出來,當合理的需求出現時,就要有一套行之有效的方法來盡可能快速和便捷地響應企業需求。

說一下另外一點比較複雜,也是比較頭疼的地方,資料。

進銷存系統開發的一大特點就是圍繞資料的準確性展開。之前開發過很多其它各種各樣的業務系統,但都沒有比進銷存對資料的準確要求的那麼嚴格,進銷存系統由於其對資料的特殊敏感性,原則上是不讓業務員修改資料的,而且也不易修改,因為資料與資料之間的關聯性太強,改了一處,與此關聯的各處都需要進行修正,但往往乙個人並不具備所有的修改許可權,所以就需要確保各處資料的一致與準確性。

在對進銷存的操作流程進行分解後,一般都會有以下幾個步驟:

錄入商品a(a=0)

採購商品a(a+10?)

入庫商品a(a=10)

銷售商品a(a-10?)

出庫商品a(a=0)

盤點商品a(a=?)

舉了乙個簡單的例子,也由此可見商品是進銷存系統很重要的一塊內容,其中要做的就是對商品的數量進行運算。

這裡面的數學模型並不複雜,但是當有幾百個商品,數量翻幾十倍時,再加上外貿要換算匯率,手續費等,無論是商品數量還是金額,計算的過程就會比較複雜,會發現腦子完全不夠用,尤其是出錯的時候,找半天才找到出錯的環節,算到最後往往都是邏輯出錯,而不是數學模型的錯誤。

所以我的經驗是,當面對乙個繁雜的業務時,往往要經過冗長的系統流程,在處理時,盡量的能把它的處理過程拆分成多個function,讓每一部分的function確保它只幹一件事,只要把這件事做的準確就可以了。

用「望聞問切」的方式充分了解需求,通過切合自身實際的方法快速響應,以精益求精的態度不斷改善系統,確保資料的一致性和準確性。

一次進銷存軟體架構的實踐(二) 業務外觀層設計

一次進銷存軟體架構的實踐 一 概述 根據經驗可以發現乙個介面總是一塊一塊的,每一塊裡都是一些基本控制項 按鈕 文字框或者日期控制項等 或者是乙個網格控制項和樹形控制項等,如果每塊稱為區域,裡面的成為項,這樣我們可以把介面抽象出兩個基類 區域和項,從區域派生出的其他區域分別用來建立編輯區域 網格區域和...

從0到1,開發乙個動畫庫 2

傳送門 從0到1,開發乙個動畫庫 1 上一節講到了最基礎的內容,為動畫構建 幀 值 對應的函式關係,完成 由幀到值 的計算過程。這一節將在上節 的基礎上談談如何給乙個完整的動畫新增各類事件。在新增各類事件之前,我們先對 loop迴圈函式進行一些改進 loop else if this.state s...

如何從0開始了解乙個儲存引擎

根據本人淺薄的經驗,了解乙個資料引擎可能涉及以下問題 目錄 1.概念 2.架構 3.部署 4.元資料 5.寫資料鏈路 6.查詢鏈路 階段總結 一些經常被關心的功能和特點 7.舊資料清理 8.資料的hash 9.離線檔案匯入匯出 10.故障恢復時間 11.對比其他db 先粗略看看是否適合自己的需求,從...