項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。
項目管理手記(四) DRP項目中軟件系統架構的比較
軟件系統架構，這是一個非常技術性的詞，一般來說，服裝企業的業務部門是不太理會這個東西的，畢竟他們關注的是業務實現，操作方便性等；就算是一些企業的IT人員，對於軟件系統架構到底能夠在IT項目中起到什麼樣的作用，可能也不太清楚。我還記得有一位企業的IT主管說過：“軟件系統架構是個什麼樣的東西，對於我們公司來說，軟件好用即可，我管它是用VB寫的，還是用10層架構碼出來的。”
這位IT主管的話對嗎？可能從企業的角度來說，信息系統的管用就行，其它的因素可能不用擔心太多，至於軟件系統架構，這是演示的時候無法看出門道的東西，但如果從架構設計的目標：可靠性、安全性、可升級性、可擴展性、可定製性、可維護性再加上良好的客戶使用體驗這幾點要求來說，如果在進行IT項目的大規模部署時，忽略了軟件系統架構，如果出現問題將有可能是致命的。畢竟隱藏的越深的問題爆發出來的後果越是嚴重。今天挑這個話題來說，也是因爲身邊有朋友曾經做過的一個DRP（Distribution Resource Planning，配送資源計劃）項目，這個項目中的一些經驗與教訓，值得我們借鑑。
分銷系統的系統架構要求
從軟件系統架構的種類上來說，一般分爲以下幾種：
1、單機程序：這個應該是簡單的一種軟件系統架構了，不在本文討論之列。
2、C/S架構：C/S又稱Client/Server或客戶/服務器架構。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
C/S架構的優點是：
ü 交互性強。在C/S中，客戶端有一套完整的應用程序，在出錯提示、在線幫助等方面都有強大的功能，並且可以在子程序間自由切換。B/S雖然由JavaScript、VBScript提供了一定的交互能力，但與C/S的一整套客戶應用相比還是太有限了。
ü 提供了更安全的存取模式。由於C/S是配對的點對點的結構模式，採用適用於局域網、安全性比較好的網絡協議(例如：NT的NetBEUI協議)，安全性可以得到較好的保證。而B/S採用點對多點、多點對多點這種開放的結構模式，並採用TCP/IP這一類運用於Internet的開放性協議，其安全性只能靠數據庫服務器上管理密碼的數據庫來保證。
ü 降低網絡通信量。B/S採用了邏輯上的三層結構，而在物理上的網絡結構仍然是原來的以太網或環形網。這樣，第一層與第二層結構之間的通信、第二層與第三層結構之間的通信都需佔用同一條網絡線路。而C/S只有兩層結構，網絡通信量只包括Client與Server之間的通信量。所以，C/S處理大量信息的能力是B/S所無法比擬的。
ü 速度相對較快。由於C/S在邏輯結構上比B/S少一層，對於相同的任務，C/S完成的速度總比B/S快。使得C/S更利於處理大量數據。
C/S架構缺點主要有以下幾個：
ü 只適用於局域網。
ü 這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分佈式的數據。
ü 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。
ü 系統軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
ü 對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Unix等。
3、B/S架構：B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器（Browser），如Netscape Navigator或Internet Explorer，服務器安裝Oracle、Sybase、Informix或 SQL Server等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
B/S最大的優點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網的電腦就能使用，客戶端零維護。系統的擴展非常容易。
B/S架構的缺點就是所有C/S的優點，在前文已論述，不再重複。
4、三(N)層架構：N層架構的四層是指Presentation Tier（表示層，就是直接呈現在用戶面前的界面）、Web Server Tier（Web服務器層）、 Application Server Tier（應用服務器層）和 Data Tier（數據層）。
N層架構的核心是提供可規模化特性，一方面是從服務負載上可規模化，能同時爲極大規模的用戶同時提供服務；另一方面是服務功能上的可規模化，可形成極大規模的軟件羣系統，各分系統可以共享信息、服務，形成企業級的信息高速公路。
N層可以分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此,系統規模越大這種形態的優點就越顯著。
5、遠程終端技術：該種方式是根據C/S架構系統無法滿足遠程訪問需求而存在的。遠程終端技術提供了通過作爲終端仿真器工作的“瘦客戶機”軟件遠程訪問服務器桌面的能力。終端服務只把該程序的用戶界面傳給客戶機。客戶機然後返回鍵盤和鼠標單擊動作，以便由服務器處理。每個用戶都只能登錄並看到它們自己的會話，這些會話由服務器操作系統透明地進行管理，而且與任何其他客戶機會話無關。
這種軟件技術架構在小規模應用上尚可，但如果部署到大規模應用時，網絡帶寬、服務器響應能力、磁盤讀取能力都會受到極大挑戰。
從服裝企業的行業特性上來說，包括鞋業、皮具、禮品等企業，在這裏一般特指品牌連鎖運營企業，企業的產品基於直營、分公司、加盟、專櫃、批發等連鎖經營方式，通過各級代理商、專賣店或者銷售專櫃實現最終銷售，DRP系統就是要對企業的供應鏈進行全程管理，包括內部供應鏈和外部供應鏈的管理，涵蓋了從生產廠家，物流配送，各級代理商分銷，到專賣店零售的每一個環節，DRP系統要以供應鏈爲核心實現各項業務功能。DRP系統必須通過物流、商流、信息流、資金流對供應鏈進行管理和監控，實現供需匹配、動態適應、快速反應，從而降低庫存、共享資源、降低成本、規避風險，爲企業創造價值。服裝企業的上下游供應鏈關係可以用如下圖表示：
在初步瞭解了軟件系統架構及服裝企業的供應鏈模式之後，我們且先來看一下G公司在長達5年間的三次DRP項目經歷，從這三次項目經歷來看一下軟件架構之痛。
G公司三次選型的軟件系統架構之痛
這個故事說的是G服裝企業的選型經歷，該公司2001年起一直處於高速增長狀態，在2001年時，全國的專賣店約有800家左右，但到2007年，該公司已經是行業內的知名品牌，全國的專賣店達到3000家，而該公司的IT經理，暫且稱他爲Z吧，他們公司在2002年、2004年進行了兩次DRP項目的選型，而直到今天，他們的選型故事還在繼續，爲什麼在五年之內就對DRP項目進行三次選型呢？在一次聚會的時候，和Z聊起了這個話題，也就從中聽到了一個圍繞着DRP項目軟件系統架構的故事。
第一次DRP軟件選型：G公司在2002年的時候，由於當時公司規模還算比較小，組織結構也不完善，當時還沒有獨立的IT部門，只有一個網絡管理員掛在財務部的名下，而此時Z還沒有進入該公司，網管員只負責公司PC維護的工作，對IT系統並沒有發言權。而當時G公司考慮到業務規模的不斷擴大，業務部門都迫切需要有一套業務管理系統。此時G公司用的是國內某知名財務軟件公司U公司的財務系統，而且由於沒有獨立的IT部門負責對這些軟件系統選型負責，G公司財務經理就向業務部門推薦了U公司的分銷軟件系統，而當年U公司並沒有針對服裝行業的DRP系統，但出於向服裝行業進軍的目的，同時也是爲了通過該項目完善自己的產品線， G公司的項目還是被U公司承接下來了。
U公司承接該項目之後，對G公司的分銷業務進行了全面分析，然後在U公司原有財務系統的基礎上，對軟件系統進行了大量的二次開發工作，在項目開發人員基本滿足了G公司的業務需求之後，就將該項目推行上線，而在上線之後才發現了還有一個需要解決的問題：由於U公司原有的軟件都是基於C/S(Client/Server，客戶/服務器)架構，而在G公司進行實際部署時，需要將該系統部署到全國各地的分公司、辦事處、代理商直到專賣店，而在當時U公司提出了使用遠程終端技術+VPN網絡的方案來解決這個問題。再當時，G公司對技術架構上也沒太多辨別能力，而且在G公司對該方案進行效果測試時，感覺都還不錯，應該能滿足業務的需求，也就同意了該方案。也就是這個方案的出臺，爲下一次的項目失敗埋下了禍根。
當U公司對項目實施完公司總部各個部門，只在幾個分公司進行實施之後，就發現該項目舉步維艱了，由於U公司的軟件系統是基於財務的DRP系統，一切以財務爲核心，而不是以業務流程爲核心，使得G公司在應用過程中業務流程無法順利地流轉。再加上了大規模的定製開發，已經脫離了U公司原有的產品線，因此，G公司若有新的業務需求時，也將無力投入大量的人力進行開發，使的G公司的這個系統處在沒有更新，沒有升級的狀態。基於這種情況，G公司決定與U公司停止項目合作，進行新的DRP項目選型工作。
第二次DRP軟件選型，G公司接受了上次的教訓，也不敢請看似強大，但對行業不夠了解的軟件公司來做該項目了。G公司這次選擇了一家服裝行業的軟件公司B公司來完成G公司的DRP項目大業，B公司在行業內有幾個較大的客戶案例，雖然這次項目有一定的競爭，但由於B公司的軟件產品在報表呈現上顯的比較豐富，得到了業務部門的好評，因此也從幾個供應商中脫穎而出。而B公司原有的客戶案例，所有實施的規模沒有超過200個併發用戶，而且他們的軟件系統與U公司相同的一點是採用C/S架構，這就使得B公司也必須使用遠程終端技術+VPN網絡來實現遠程訪問。在G公司爲了該系統能夠正常運行，且不論投入大量金錢購買了大量的遠程終端服務器供客戶端接入，同時在總部還備有電信、網通的
G公司發現兩次DRP項目沒有資深IT專家介入的情況下，如果貿然對DRP系統進行選型是一定會犯錯誤的。此時G公司引進的IT專家Z。而Z對B公司的系統目前也是束手無策，因此向公司建議，第三次開始DRP項目的選型，同時做ERP級的項目，而不只只是停留在產品的層面上，而是根據公司的發展規模做平臺級的ERP應用，這對Z應該又是一個新的考驗。但G公司在DRP項目上的兩次失敗，不能不承認，信息系統是爲了滿足業務需求而存在的，但它的本質還是需要由IT技術來支撐的。
如何選擇一個好的系統架構
企業的供應鏈複雜程度是DRP系統選型中一個非常重要的因素，因爲企業供應鏈的複雜程度越高，對DRP系統的性能要求就越高，相較之下系統構架要求就越高。
但服裝企業因爲其分銷網絡的不斷擴張，不同的軟件系統架構在企業的不同階段是具有適應性的，根據G公司的應用效果，基本上我們可以進行如下判斷：
1、單機程序：適合單個的服裝店，或者是幾家服裝店只進行進銷存管理的企業。
2、C/S架構：該方案只適合在局域網內使用，而DRP項目一定是要進行跨地區應用的，因此不適合作爲DRP項目的主要架構，但可以應用在DRP項目POS或者收銀部分的脫機應用程序中，與ACCESS本地數據庫配合使用。當然，如果C/S架構的系統配合遠程終端技術+VPN技術，則可在不高於100個併發用戶的情況下進行應用。
3、B/S架構：由於DRP項目的複雜性，而B/S架構因爲其前端應用展現能力有限，因此不適合作爲DRP項目的主要架構。但如果企業的應用需求不復雜的情況下，如在報表查詢、客戶資料查詢等方面可以應用。
4、三(N)層架構：一個具有良好擴展性，能夠進行大規模部署的DRP系統應該是基於三(N)層架構下的，否則的話，就算軟件系統的功能再強大，也只是“水中月”、“鏡中花”，中看不中用。
5、遠程終端技術：由於一些歷史原因，在C/S架構的舊系統，通過遠程終端技術+VPN網絡的方法，可以延長原有系統的使用壽命；但如果是新的DRP系統建設中，由於遠程終端需要耗費大量的服務器處理能力、網絡帶寬及I/O，因此不建議使用該技術。特別是在併發用戶數在200左右的時候，遠程終端技術需要用三(N)層架構一倍的服務器、帶寬才能將應用跑起來，而此時除非用小型機，如果只是用PC服務器的話，估計是沒有將DRP系統進行更大規模的部署了。