軟件工程師供應鏈系統(tǒng)案例

1、.：.；供應鏈系統(tǒng)SCM搭建軟件工程案例分析第一章：案例總體引見 背景 20 世紀 60 年代，企業(yè)開場了管理信息化的運用，從 MRP 到 ERP，逐漸實 現(xiàn)了對采購、庫存、消費、銷售、財務和人力資源等業(yè)務的管理，使內部業(yè)務流 程和處置實現(xiàn)了自動化，為企業(yè)內部縱向一體化管理奠定了根底。在經(jīng)濟全球化 的今天， ERP 在供應鏈的跨企業(yè)橫向一體化管理方面力不從心。 全球 500 強企業(yè) 在經(jīng)過假設干年的 ERP 運用后紛紛引入 SCM供應鏈管理 ，將 ERP 拓展到整個 行業(yè)的一切物流環(huán)節(jié)。 零售企業(yè) ERP 系統(tǒng)的重要性更是在很多年前就被企業(yè)注重，一時間中國零 售企業(yè)都在開場了本人的 ERP 改

2、造工程，隨著 ERP 概念的逐漸冷卻，以及各企 業(yè)間對于信息、科學管理、計算機管理的不斷完善，另一個領先的概念又在各企 業(yè)間被逐漸傳開，這就是供應鏈。 供應鏈管理(SCM)，就是把供應商、消費廠家、分銷商、零售商等處于一條 供應鏈上的一切節(jié)點企業(yè)都聯(lián)絡起來進展優(yōu)化，從而使消費資料以最快的速度， 經(jīng)過消費、分銷環(huán)節(jié)變成增值的產(chǎn)品，最后到達有消費需求的消費者手中。它不 僅可以降低本錢、減少庫存，而且可以使社會資源得到優(yōu)化配置，更重要的是， 經(jīng)過信息網(wǎng)絡、組織網(wǎng)絡實現(xiàn)了消費及銷售的有效銜接和物流、信息流、資金流 的合理流動。圖 1 是供應鏈管理的模型 工程引見 本案例引見的工程是對零售企業(yè) ERP

3、系統(tǒng)的功能延伸供應鏈管理的開 發(fā)、實施過程。ERP 系統(tǒng)作為零售企業(yè)內部管理、運轉的中心架構，使得企業(yè)內 部業(yè)務流程和處置實現(xiàn)了自動化，為企業(yè)內部縱向一體化管理奠定了根底。從一 個企業(yè)的角度看， ERP 系統(tǒng)無疑為企業(yè)提供了先進的管理理念、 整合了企業(yè)內部 的流程、提高企業(yè)運轉效率，但是從一個更大的層面看，使得各企業(yè)彼此之間形 成了信息孤島，使得彼此之間的信息流通還停留在原有的根底上。在網(wǎng)絡技術充 斥的當今社會，信息的快速獲取和共享曾經(jīng)成為各個協(xié)作企業(yè)間共同追求的目 標。這必然使得企業(yè)間的溝通和整體運作越來越遭到雙方的注重，作為零售業(yè)來 說需求與各個供應商堅持良好的協(xié)作關系， 更重要的是希望能

4、實現(xiàn)彼此信息的共 享和反響，使得能根據(jù)不斷變化的銷售市場調整運營戰(zhàn)略，實現(xiàn)最大的利潤。這 就給供應鏈系統(tǒng)提供了前提，也正是出于這種目的，零售企業(yè)迫切希望經(jīng)過供應鏈系統(tǒng)與供應商建立利益共享的戰(zhàn)略同盟。 企業(yè)原有的 ERP 系統(tǒng)很好的整合和規(guī)范了企業(yè)內部的運轉流程，并且經(jīng)過 多年的運營存儲了海量數(shù)據(jù)，并以北京總部為中心，經(jīng)過先進的網(wǎng)絡技術在全國 各地門店中搭建起完備的網(wǎng)絡環(huán)境，這為供應鏈系統(tǒng)的實施提供了良好的根底。 同時公司指點希望經(jīng)過供應鏈系統(tǒng)，吸收現(xiàn)代管理理念，運用先進的科學技術， 在本人與供應商之間建立起信息共享的平臺、整合管理流程、縮減運營本錢，使 雙方都能從中獲得更大的利潤和更高的效率。

5、 工程的整體運轉主要由企業(yè)信息技術部牽頭， 在技術和選型上進展定位和把 關，其他各相關部門，包括：百貨事業(yè)部、零售本部、超市事業(yè)部、財務部全力 配合，并提出相應需求和意見，外請專業(yè)公司開發(fā)程序的方式進展工程開展。 企業(yè)指點提出在 2021 年 6 月前首先實現(xiàn)北京一家門店供應鏈系統(tǒng)試運轉， 之后在 2021 年 10 月前實現(xiàn)北京其他三家門店合計四家門店全部上線供應鏈系統(tǒng) 的總體目的。 根據(jù)與各事業(yè)部的協(xié)商和企業(yè)內部的討論決議初期主要實現(xiàn)供應商 經(jīng)過網(wǎng)絡能在供應鏈系統(tǒng)中隨時查詢本人在門店的銷售和庫存信息，實現(xiàn)訂單、 結算單由傳統(tǒng)的打印紙質單據(jù)傳送的方式向網(wǎng)上結算方式的轉變， 并希望在后期 實現(xiàn)

6、可視化和供應商自動參與的供應鏈方式。 作為我在整個工程中主要擔任技術的保證， 對雙方之間的技術問題進展協(xié)調 處置。由于本次開發(fā)采用的是外包方式進展，從這個角度上講我是作為工程中的 甲方身份，但是由于為了滿足供應鏈系統(tǒng)的一些需求，需求在原有 ERP 系統(tǒng)基 礎上進展一些功能的擴展，所以從這個角度上我又是一種類似乙方的身份，能夠 正是由于這兩方面的不同的角度，使得我在這個工程中有了更多的領會，特別是 結合著在案例分析課程中學到的一些專業(yè)的工程管理理念和閱歷， 更是使得本人 從整個工程中學到了不少的知識，增長了更為豐富的閱歷，下面我開場進展工程 的詳細分析。第二章：案例分析 這個工程或者案例說的是對

7、原有 ERP 系統(tǒng)進展改造實現(xiàn) SCM的功能擴展。 從目前的結果看這個工程曾經(jīng)投入到正式運用之中， 并且對于企業(yè)的流程整合和 效率提高都起到了應有的作用，應該說從這方面講工程是勝利的，但是其間有這 太多的遺憾，而這些遺憾也呵斥了工程不能繼續(xù)前進的阻力，要是從這方面講項 目好似又是失敗的，總的來說勝利中帶著遺憾，下面我就從幾個方面詳細的討論一下這個工程，希望能從中看到勝利的方面也能在今后彌補遺憾的方面。 1、前期可行性討論 工程開場于 2007 年年底，真是的實施是在 2021 年 3 月開場的，這期間的 3 個多月時間主要進展的前期可行性討論， 這個可行性針對的是數(shù)據(jù)對接可行性的 討論。這是由

8、于 ERP 系統(tǒng)作為目前企業(yè)的中心架構是不能夠隨便進展修正的， 并且出于對于數(shù)據(jù)平安性的思索， 不能夠將企業(yè)中心效力器和數(shù)據(jù)庫提供應供應 鏈系統(tǒng)訪問， 故需求將數(shù)據(jù)從中心數(shù)據(jù)庫中取出并導入到供應鏈系統(tǒng)中單獨進展 展現(xiàn)。這必然需求在一個單獨的數(shù)據(jù)抽取過程來實現(xiàn)兩個系統(tǒng)的對接，而這種對 接又是兩個層面，其一是技術角度上數(shù)據(jù)庫中數(shù)據(jù)的抽取和導入，這方面主要是 純技術層面的，在當今各廠商的技術趨于一致化的前提下，這方面根本不會存在 太多問題，只是在數(shù)據(jù)格式轉換、表構造轉換等細節(jié)上進展討論；其二是數(shù)據(jù)展 現(xiàn)結果的對接，這個層面主要是業(yè)務系統(tǒng)的對接，也就是將本來在 ERP 中展現(xiàn) 的結果放到供應鏈中進展展

9、現(xiàn)，這將涉及到雙方的展現(xiàn)方式能否一致、數(shù)據(jù)分析 的角度能否一致、信息存儲的含義能否一致等方面，這將更多的涉及到業(yè)務層面 的細節(jié)。這些問題是涉及到雙方能否進展本質性協(xié)作的關鍵，故在工程正是開場 之前雙方就這幾方面進展了反復的交流和討論。 作為外包公司他們曾經(jīng)有了一套比較成型的供應鏈系統(tǒng)， 此系統(tǒng)運用的 Java 技術進展前端開發(fā)，以 IBM Webshere 為中間件，運用 DB2 數(shù)據(jù)庫進展數(shù)據(jù)存 儲。 作為我們的 ERP 系統(tǒng)運用的是比較傳統(tǒng)的 Sybase 數(shù)據(jù)庫進展后端數(shù)據(jù)存儲， 這樣由 Sybase 到 DB2 數(shù)據(jù)庫的轉換是不可防止的。由于目前兩個數(shù)據(jù)庫均是標 準的關系型數(shù)據(jù)庫，雖然

10、從數(shù)據(jù)庫管理構架、存儲構造上看存在這比較明顯的區(qū) 別，但是數(shù)據(jù)庫內部遵照的規(guī)范是一致的，數(shù)據(jù)在數(shù)據(jù)表中的存儲方式也大致是 一樣，從技術角度的層面可以預見到在這方面不存在太大的問題。雙方最終決議 由 Sybase 數(shù)據(jù)庫中將數(shù)據(jù)保管為文本 TXT 格式的文件，再將 TXT 文件導入到 DB2 數(shù)據(jù)庫中，這樣的操作方式對于兩個數(shù)據(jù)庫均可以比較容易的實現(xiàn)。當時 雙方?jīng)]有進展更為詳細的技術上的討論和實現(xiàn)測試， 在后期的開發(fā)過程中發(fā)現(xiàn)兩 個數(shù)據(jù)庫中的對于日期型數(shù)據(jù)的處置方式存在一些不同，會導致數(shù)據(jù)轉存失敗， 在技術上進展轉換處置后得以處理。雖然這只是一個小小的問題，并且很快的得 以處理，但是也暴顯露前期

11、可行性討論的不嚴謹性。由于數(shù)據(jù)庫層面屬于整個系 統(tǒng)的底層部分，假設在這部分沒有充分的思索的和可行性的驗證，不敢想象后期整體工程全面展開后如出現(xiàn)不可處理的問題時，我們將面對如何的窘境。這就提 醒我們前期技術方面的溝通和討論應該做到細致嚴謹， 并且需求進展相關的實現(xiàn) 測試。 作為零售企業(yè)的 ERP 系統(tǒng)和供應鏈SCM系統(tǒng)來說，它必然要滿足于這 種行業(yè)的規(guī)范和規(guī)范，但是說實話在中國市場上并沒有明確的對于 ERP、SCM 的定義，這就導致了每家企業(yè)都在做本人的 ERP、SCM 系統(tǒng)，有本人的特點和 遵照的規(guī)律，從這方面思索假設需求對 ERP 進展功能擴展和延伸，那么 SCM 所 遵照的規(guī)范和規(guī)范能否與

12、 ERP 系統(tǒng)堅持根本一致也是能工程能否能開展起來的 關鍵，而這方面所思索的將不光是技術方面的要素，更多的將是對零售業(yè)的了解 對系統(tǒng)的了解。為我們做供應鏈的公司之前也是一家以 ERP 系統(tǒng)起家的公司， 并且于我們如今運用的 ERP 系統(tǒng)還頗有淵源，所以在初期覺得上雙方應該不會 存在太大的分歧。當初期雙方派出代表進展討論的時候，我發(fā)現(xiàn)對方的技術人員 也好，代表也罷對于商業(yè)的了解很有限，甚至可以說對于商業(yè)根本不了解，這使 得雙方的交流產(chǎn)生了很大的妨礙。我不敢說經(jīng)過這些年在企業(yè)維護 ERP 系統(tǒng)對 于零售業(yè)有多么的了解，但是零售業(yè)所遵照的規(guī)范和習慣我還是知道一些的，所 以我對對方的業(yè)務只是產(chǎn)生了疑心

13、，同時我也認識到一個問題：作為一個技術人 員來說， 技術程度的高低僅是衡量他才干的獨一規(guī)范嗎？假設他對于本人所做的 行業(yè)沒有了解， 難道能做出好的系統(tǒng)來嗎？當然這些問題在對方改換了技術代表 后得到了很好的處理，我們彼此雙方對于零售業(yè)的了解達成了共識，彼此間的溝 通也變的非常容易，這樣我們開場從業(yè)務的層面進一步討論技術層面的實現(xiàn)問 題。由于受雙方表構造在構建當初的時代和思索角度的不同，許多 SCM 系統(tǒng)需 要的數(shù)據(jù)在我們的系統(tǒng)中需求經(jīng)過處置才干得到， 但是在雙方從業(yè)務層面曾經(jīng)達 成一致的前提下，這些技術層面的事情根本都可以想出處理的方法。在這里讓我 又一次認識到了，技術本身并不奧秘也并沒有價值，

14、只需當運用技術實現(xiàn)了某種 實踐的目的，才使得技術看上去是那么的光彩奪目，這也就是我本人不斷要求自 己的，不光要懂得技術，更要了解技術的運用。在這種前提下，我們雙方開場逐 個表甚至逐個的數(shù)據(jù)進展對照任務，在 ERP、SCM 和 Sybase、DB2 中找到一個 雙方溝通的機制，這部分的任務進展的比較順利，但是由于涉及的內容比較多， 還是花了一些時間的。但是能夠也正是前期的這種方式，注定了這個工程后期的 一些不可更改的弊端，由于雙方在初期太關注細節(jié)方面的對接了，不斷都在討論數(shù)據(jù)的轉換、對照等任務，這樣彼此雙方都忽略了對整個工程的整體思索。能夠 這也從一個側面看到了中國市場上對于軟件方面的不系統(tǒng)化管

15、理也沒有比較明 確的規(guī)范規(guī)范， 能夠也是雙方指點對于究竟需求一個什么樣的供應鏈應該是個怎 樣的供應鏈都沒有明確的規(guī)范， 這樣對于后期功能的擴展和延伸都產(chǎn)生了不可逾 越的妨礙。 經(jīng)過軟件工程案例這門課的學習，教師講解了一些軟件工程的案例，使我在 這個工程之后認識到了對于一個工程來說前期整體的規(guī)劃和思索是多么的重要， 也讓我找到了這個工程在后期不可防止的遇到妨礙的根源所在。 2、程序開發(fā) 經(jīng)過前期的雙方溝通，彼此都明確了本人應該做的事情，并且進展了數(shù)據(jù)抽 取和導入的功能測試，使得一些歷史數(shù)據(jù)按照雙方事先商量好的規(guī)范轉移到 SCM 系統(tǒng)中，這也為下一步的開發(fā)、測試提供了根底，使得雙方開場了下一步 的

16、任務。我方將 ERP 系統(tǒng)中一些展現(xiàn)風格和數(shù)據(jù)規(guī)范告知對方，由對方進展程 序的改造，以符合我們的風格和特點，同時我們的 ERP 系統(tǒng)為了滿足新的業(yè)務 流程的開展需求在原有的根底上進展功能的添加。 在這里我們作為甲方的身份將我們的一些需求告知對方， 由對方進展功能的 實現(xiàn)，由于對方是一家比較專業(yè)的 IT 公司，而且他們其間的內部運轉機制我們 不便深化干涉， 我作為本方技術代表的身份與對方技術代表多次進展數(shù)據(jù)方面的 議論，要求對方在原有程序的根底上進展改造，以滿足我們的風格和規(guī)范。在這 里我更多的是將 ERP 系統(tǒng)中一些表單的展現(xiàn)界面告知對方應如何從數(shù)據(jù)庫中取 得，這是有了之前雙方比較細致的數(shù)據(jù)庫

17、對接任務的根底，使得我們雙方彼此交 流起來比較順暢。由于我并不知道更不了解 SCM 數(shù)據(jù)庫的構造，所以我只是將 ERP 系統(tǒng)中數(shù)據(jù)如何計算的方法告知對方， 由對方的程序員在本人的數(shù)據(jù)庫中進 行相應的計算實現(xiàn)各個界面的展現(xiàn)功能。當時由于手頭還有其他的任務，我并沒 有更多的去關懷對方數(shù)據(jù)庫與我方數(shù)據(jù)庫的對應關系， 當時以為這些應該是由對 方程序員思索的事情，但是當工程走到了后期的時候，特別是我方覺得數(shù)據(jù)的一 致性和準確性存在問題的時候， 前期這方面的忽略成了至于我方進展數(shù)據(jù)稽核也 好數(shù)據(jù)對比也好的致命傷，并且一致影響到如今，使得在問題出現(xiàn)的時候雙方都 比較被動，排錯的過程也比較復雜和難以控制。 前

18、面我說過，在這個工程中我也以一種類似乙方的身份出現(xiàn)，也就是說為了實現(xiàn)供應鏈的一些功能，我對于我們本人原有的 ERP 系統(tǒng)也進展了一些功能擴 展性開發(fā)。我之前并沒有系統(tǒng)學習過計算機變成，對于變成的整體思緒也沒有把 握，好在此次開發(fā)主要是在原有的程序根底上進展開發(fā)，有很多的源代碼可以進 行參考。我當時可以說是采用了一種類似迭代式的開發(fā)方式進展工程展開的，因 為在程序成型之前，業(yè)務上的需求只是一種籠統(tǒng)的概念，并沒有明確性的需求分 析，這對于開發(fā)任務來說是相當困難的，所以我只能是在原有的根底上將一些功 能進展簡單的擴展。當時當我仿照原有程序的源代碼進展開發(fā)的時候，我發(fā)現(xiàn)了 原有代碼比較的冗長，并且其間

19、的移植性比較差，一些關鍵的點也沒有明確的標 注實現(xiàn)的目的，所以也為我的開發(fā)過程產(chǎn)生了比較大的影響，而當時的我也沒有 才干去改動這些曾經(jīng)成型的系統(tǒng)， 所以我只是一味的復制進展一些簡單的修正以 滿足需求。在這種前提下，程序的雛形根本實現(xiàn)了，并暫時有我們部門同時擔任 這個工程的人員進展簡單的功能測試， 在測試過程中對于細節(jié)方面的一些缺乏展 現(xiàn)出來了，需求進展二次的程序完善，但是當我再翻過頭來預備對程序進展完善 的時候， 我發(fā)現(xiàn)由于之前對于程序的開發(fā)沒有很好的遵照軟件開發(fā)高內聚低耦合 的規(guī)范和很好的一個對于軟件整體的思索， 使得一些細小的改動非常的繁瑣和困 難，經(jīng)常是改動了這里忘記了那里，使得修正的過

20、程非常的苦楚，最終我決議重 新審視這個軟件，進展全新的開發(fā)。這可以說是我第一次開發(fā)一個功能比較成型 的軟件，其間讓我認識到了軟件開發(fā)過程中科學性的重要性，在二次重新開發(fā)的 過程中，我盡量遵照軟件開發(fā)的規(guī)范，首先并不是急于編寫代碼，而是整體的考 慮了一下這部分功能實現(xiàn)的方式，并將其間一些反復的功能進展匯總，大致屢清 一個變成思緒后開場進展程序框架的搭建任務， 并對一些需求反復實現(xiàn)的功能進 行整體函數(shù)的編寫，盡量思索函數(shù)的適用性和通用性，之后進展關鍵環(huán)節(jié)的開發(fā) 和代碼編寫，并盡量運用上之前開發(fā)的函數(shù)進展實現(xiàn)，盡量將后期一些環(huán)節(jié)的改 造而影響代碼改造的任務量降到最低。正是經(jīng)過了這種二次的洗禮，我逐漸

21、在時 間中探求到了軟件開發(fā)的規(guī)律，并且構成了一些本人的風格。 如今經(jīng)過這門課程的學習，回過頭來看一看本人的開發(fā)過程，我覺得到了一 個科學有效的軟件開發(fā)管理方法對于整個工程的實施是多么的重要， 假設沒有這 些作為根底， 那么編出的軟件不論從運用性上也好還是從強壯性上也好都是不能 滿足實踐的要求的。 3、功能測試閱歷了程序開發(fā)的過程之后，必然開場了功能的測試任務。在當時我就已 經(jīng)覺得出我們測試任務的薄弱性， 經(jīng)過本門課程我更是認識到了測試的重要性和 我們測試任務的不規(guī)范不科學性，我從中得到的更多的是教訓，但是有的時候教 訓能讓人記住更多的東西，也更能給人以啟示，所以在這里我重點討論的不是我 們的測

22、試方法，而是結合這門課程進展的一些思索和對今后的改良。 對于 SCM 方面的程序我方進展的更多的是黑盒方式的測試，主要由我們部 門包括我在內的兩位同事進展功能測試，對于這方面我們沒有嚴厲的測試規(guī)范， 也沒有運用一些專業(yè)的軟件使得測試任務其實只是淺薄的局限在外表。 由于當時 我手頭還有其他方面的任務甚至當時出差在外， 而我的同事并不懂技術對于零售 業(yè)的了解也不非常充分，所以使得當時的測試只是外表的功能測試，就是將幾個 界面籠統(tǒng)的看了一下，覺得沒有太大的問題就以為沒有問題。同時由于企業(yè)內部 門間關系的問題，也沒有讓相關部門進展測試，所以從這方面開我們的測試任務 幾乎可以說沒有，就更談不上什么科學的

23、方法了，其間也只是對于界面提出了一 些改良的意見，對于數(shù)據(jù)的準確性也沒有進展嚴厲的核對。這使得之后在運用過 程中，用戶提出了很多細節(jié)方面的問題，使得我們疲于進展解釋和調試中，這也 就闡明了我們的測試任務存在多大的弊端。經(jīng)過這么課程的學習，我希望可以將 教師在課堂上將的一些勝利的案例中的測試方法引入到我們之后的任務中去， 因 為只需測試任務做的更加充分才干使得整個工程更加勝利。 開發(fā)方進展的測試任務我們沒有進展更多的參與和干涉， 經(jīng)過和他們技術人 員的交流，他們進展的更多的是數(shù)據(jù)一致性的測試，也就是將 SCM 中的數(shù)據(jù)和 ERP 系統(tǒng)中的數(shù)據(jù)進展逐界面的對照，以保證兩個系統(tǒng)中數(shù)據(jù)的一致性完全一

24、致。正是由于有了這方面的測試任務，使得系統(tǒng)在上線的時候數(shù)據(jù)方面并沒有出 現(xiàn)太多的問題，使得運用人員對于數(shù)據(jù)的準確性沒有提出太多的異議，我真的不 敢想象假設兩方數(shù)據(jù)出現(xiàn)了不一致我們將如何面對雙方的指點和運用者。 測試這部分本來應該是整個工程中一個比較主要的環(huán)節(jié)， 但是我覺得我們在 這個環(huán)節(jié)上的欠缺和缺乏，這個能夠也是我們整個部門的一個弊端，我確實希望 一方面經(jīng)過對于測試流程的系統(tǒng)學習另一方對以一些勝利工程的學習可以改善 我們部門這方面的弱勢。能夠也正是經(jīng)過課程的學習，使我的眼界放開了，使我 找到了方向，當然實際上的東西或者其他人的東西要變本錢人的還需求一個過 程，但是我以為至少我如今認識到了認識

25、到了，這些都必將對于下一步的改良起到積極的作用。 4、工程上線 閱歷了上面各個環(huán)節(jié)，工程一步一步的走到了開場正是上線的環(huán)節(jié)。這個環(huán) 節(jié)可以說是整個工程一個最終失敗與否的關鍵點，雖然它并不能代表整個工程， 但是它確實整個工程的最好的表達點。 由于此次實現(xiàn)的功能比較簡單，只是一些報表的展現(xiàn)功能，也正是在先前對 于數(shù)據(jù)一致性的把握上，使得上線時并沒有產(chǎn)生太多的對于系統(tǒng)的質疑。相仿的 由于之前一些培訓任務的不到位和一些對問題估計的缺乏， 使得上線初期用戶對 于管理方面的質疑聲音比較劇烈。 這也提示了我們軟件工程不光是一個編寫代碼 的過程，其間的運作手段也是非常重要的，甚至可以說這將直接影響給運用者一

26、個怎樣的初印象的問題，所以作為一個工程的實施來說，不光需求科學的編程、 測試方法，更加需求科學的運作方式，這當然也為工程的管理人員提出了更高的 要求，但是這是符合實踐開展趨勢的，也是必可防止要遇到的問題。 之后根本按照指點提出的要求，工程如期的上線，也根本實現(xiàn)了當初想象的 一些功能，為供應商和我們都提供了一定方面的便利和效率的提高。 5、后期展望 初期的功能可以說很好的實現(xiàn)了當初的想象，但是工程并沒有就此停頓，因 為目前實現(xiàn)的只是最簡單一些報表的展現(xiàn)，而與供應商直接的聯(lián)動性并沒有實 現(xiàn)。 就在我們在原有的根底上預備進展下一步開發(fā)的時候， 一個可以說是不可逾 越的問題出現(xiàn)了，由于前期對于整體工程思索的不完善，使得后期一些功能的擴 展變得步履維艱， 對于每一個新的功能都需求進展從抽取數(shù)據(jù)到程序開發(fā)整個過 程的整體改動，并且雙方數(shù)據(jù)的一致性