㈠ 電子商務系統4個發展階段的特點是什麼
電子商務發展的四個階段
電子商務發展的歷史雖然不長，但已經經歷了四個階段：
第一個階段是電子數據交換（EDI）。電子商務實際上在網路出現以前就已存在。1994年之前，企業層面的電子商務是通過EDI進行的。EDI指的是商業交易信息（如發票和訂單）以一種業界認可的標准方式在計算機與計算機間的傳輸。對於某些交易來說，在減少交易錯誤和和縮短處理時間方面，EDI發揮了重大作用，但這是以巨大的的成本為代價的。
首先，EDI通常經過專有增值網路進行，這需要花費一大筆投資；
其次，EDI離不開分布式軟體，這種軟體既昂貴又復雜，給參與者增添了很大的負擔；
再次，EDI是批量傳輸的，影響了實時生產、采購和定價。
由於這些原因，EDI從未真正普及過，在中國尤其如此。
第二個階段我稱之為基礎電子商務階段。在這一階段，買家和賣家開始嘗試在沒有中介的情況下開展交易。成功的先行者把它們的網站當作主要的銷售渠道（思科和戴爾），它們通常是技術公司，面向懂技術的顧客，沒有或只有很少的渠道沖突。
對其他大多數公司而言，它們仍然只把網站當作展示產品目錄和市場推廣材料的地方。時至今天，只有15％的網站能夠接受訂單，6％的網站能夠告知訂單處理現狀。
第三個階段是商務社區。在此階段，第三方目的網站（third-party Web destination）開始把交易雙方帶到共同的社區之中。商務社區創造了市場透明度，一旦買主和賣主開始定期在社區中會面，各種各樣的可能性就會出現。這一階段還擁有很大的發展空間。
第四個階段則是一種嶄新的開始，它就是協同式商務階段。商業合作夥伴間的幾乎每一個業務流程都可以藉助網路加以改善或重組。與B2C商務相比，B2B商務涉及的關系要復雜得多。用建築上的事情作比，B2C商務像是等待一所房子完工之後買下它，而 B2B商務則更像從事一個龐大的建築項目，需要在專業工作者之間協調多項流程。我們把這樣的工作稱為「協同」，它面臨的障礙很多，但也蘊藏著重大的機會。
第四階段的任務是在第三階段的基礎上提供對各種商務流程的支持，創造一個虛擬的商業鏈。協同式商務意味著企業員工、合作夥伴和顧客的一種動態合作。他們通過互動交流，在虛擬社區中找到節約成本、創造價值和解決業務問題的方法。協同式商務是需求鏈與供應鏈之間復雜的工作流的一種更為完整的反映。
電子商務的四個階段
靈活性
成本
第一階段 EDI的批量傳輸
低；格式固定
高；專用網路
第二階段 基礎電子商務
高；開放標准
低；Internet優勢
第三階段 商務社區
高；開放標准
低；Internet優勢
第四階段 協同式商務
高；開放標准
低；Internet優勢
支持的商業流程
商家互動 市場透明度
批量訂單
低；供應固化
目錄訂單
低；無中心市場
目錄＋拍賣/競價/詢價
高；跨地域界限
多樣化的訂單
高；跨地域界限
新經濟的兩大核心能力：結盟和專業化
大部分產業都會走向協同商務模式。那些總是生產足夠庫存的縱向一體化公司正在轉型，變成擁有多個專業化夥伴的聯合體，為當前需求提供產品和服務。供求鏈演變成技術驅動的、具備高度靈活性的結盟關系，可以為顧客定製產品。
因此，傳統生產商應該轉向一種依靠多個合作者的以項目和流動性為基礎的製造方式，許多業務都可以被外包出去。那些特別專業的功能，如果對核心業務不具備戰略意義，可以轉移給電子市場。
電子市場將為買主和賣主提供前所未有的市場透明度。目光遠大的公司利用這樣的市場協調供求鏈，由此獲得極大的競爭優勢。例如，它們可以
*通過在供求鏈中緊密聯合所有合作夥伴而創造一個一體化的商業鏈，提高流程透明度，在合適的時間把合適的產品送達合適的地方；
*利用網上市場作為合作平台或「電子中樞」，在其上發布生產計劃和需求信息，以便貿易夥伴能夠作出實時調整，從而極大地降低庫存；
*了解自身的購買行為，使采購政策更具一致性；
*將戰略合作夥伴關系予以自動化，減少公司間交流的成本；
*利用互聯網創造高度嚙合的供應鏈，與合作夥伴的行動保持一致，縮短訂單周期。
上述結果可以導致虛擬公司的誕生――所謂虛擬公司，可以視作一個經由網路中樞緊密維系的公司聯合體。這樣的聯合體可以實現規模經濟。
結盟是新經濟中的一種核心能力。由於有了網路，建立和管理同盟關系的成本大幅度下降，而公司間流程的效率和對這種流程的認識則有顯著的提高。
專業化則是另外一種核心能力。一個多世紀前，英國經濟學家亞當·斯密和大衛·李嘉圖就認識到了比較優勢的原則：在一個完全競爭的市場中，國家、產業和公司將被迫集中精力於它們擁有比較優勢的領域，以此獲得更高的效率和生產力。由於網路造就了一種新型的虛擬商業鏈，那些專業化公司可以在鞏固自己在鏈條中的環節作用的同時，充分利用結盟關系與更大的競爭對手爭奪市場。公司創造價值的過程發生了改變：它們可以把電子商務基礎設施當作空中管制中心，用它來管理商業鏈中的不同專業化成員。
電子中樞
如果實時信息能夠在交易夥伴之間直接流通，效率會達到最高。然而，夥伴間點對點的連接並不具有實用性。它過於復雜和昂貴，也難以擴大規模。好的設計應該是，建立集成性的電子中樞，讓所有的連接都通向這一中樞。
電子中樞在此指的是那些從事大量協同工作的交易市場，它包容了交易夥伴全部的業務流程和互動。
電子中樞提供協同式服務，而一般的交易只會簡單地分配訂單。協同意味著增值，也意味著為B2B站點增加「粘性」。
電子中樞的協同工作包括哪些呢？擇其要者如下：
●產品采購――對供應商進行認證，獲得應有的供貨，獲取相應的折扣。
●訂單處理――完成、記錄並追蹤交易。
●物流管理――同物流部門實行實時對接，達到物流的最優化。
●購買檔案――保存歷史性的購買數據，以方便多次訂貨。
●對外貿易――報關、核查、物流配送、卸岸成本分析及出口批文辦理。
●市場營銷和廣告管理。
●合同管理――制訂條款、續簽、多方協議及合同實施的監督檢查。
●產品生命周期的協同――聯合設計、零部件變化的事先通知、通報產品的有效期限和產品的過渡期限。
●計劃――高層的供應鏈設計和倉儲定位。
●日程安排――在多個合作者之間協調和優化生產日程。
●預測――測算需求、生產和市場反應。
●資產管理――追蹤、修理維護、折舊和處理。
●目錄/內容管理――多廠商目錄優化、庫存測算和調劑、零部件的補充替換和建議。
●電子帳單的出示和支付。
●社區功能――新聞、工作機會。
●第三方保證、風險管理。
●應收帳款管理。
●績效管理――最佳和最壞的發貨記錄、質量、貿易夥伴的再分配。
●逆向物流――退貨和部分退款、特殊商品處理和客戶支持、對退換貨的批准。
●款項調節。
●在線銷售――產品配置；對每一訂單的合理配置進行有效核實；保證多廠商的產品供給；產品的比較分析。
●應用託管。
●復雜定價――討價還價、大宗折扣、多層定價、期價及生效期、多種價格單、報價管理和現狀記錄。
●數字證書管理。
●清算服務。
●付款――付款體系的整合安排；信用核查和記錄。
●內容過濾。
●市場情報。
●客戶的個人化服務和細分化的市場描述。
●渠道管理服務。
●與其他交易市場的連接。
●與後端系統的整合――支持同主要的ERP系統的數據交換；支持本土化的應用程序介面。
●教育和培訓――有關復雜流程的多媒體培訓、產品配置的示範錄像。
●代理經營服務。
●特別的營造市場手段――拍賣、逆向拍賣、集團購買、特色促銷、合同購買。
●買賣雙方的身份認定。
●夥伴計劃。
這些工作給予交易市場以更多上下游的關聯、更強的社區特質，以及更大的價值。交易市場由此獲得了一種與現存商業鏈無縫結合的機會，可以使客戶享受兩方面的好處：一個一體化的供求鏈整合了所有相關的工作流，與此同時，市場的透明度大大提高。
為了保障自身的生存，交易市場必須大規模開展協同工作。簡單的買/賣交易可能會像今天的e-mail一樣，變成幾乎免費的。那些能夠建立「平台」以深化同客戶聯系的B2B商務公司將會成為最後的贏家。它們就是電子中樞。
㈡ 構建電子商務系統常用的技術有哪些各有什麼特點
構建電子商務系統常用的方式一般有兩種，一種是在淘寶、阿里巴巴等網站申版請使用，這權種方式優點是簡單易用，搭建快速，缺點是自定義功能不強，無法實現一些定製功能，並且通常必須使用該網站提供的二級域名；還有一種是選擇合適的電子商務管理程序，自己搭建平台，這種方法的優點是使用自己的域名，可定製性強，缺點是操作較為復雜，需要一定的網站管理基礎，目前常用的中文開源電子商務管理系統主要如下：
Zen Cart：完全免費開源的網上商店系統，易於安裝，支持多語言、多貨幣，具有完善的網店系統流程，可以幫助用戶建立風格不同的電子商務系統；
osCommerce：是一套由自由軟體開發社團開發並維護的在線商店的解決方案，免費開源，並可以應用到任何的商業環境中，可以在短時間內生成一個電子商務網站；
ShopEx：國內最早的網店軟體提供商之一，功能全面，收購了ECShop，目前是國內使用人數最多的免費獨立B2C網店管理軟體；
ECShop：完全開源的網店程序，在插件和二次開發這方面有一定的優勢等。
㈢ 電子商務系統規劃主要內容
電子商務系統的規劃是指：以完成企業核心業務轉向電子商務為目標，給定未來企業的電子回商務戰略，設計支答持未來這種轉變的電子商務系統的體系結構，說明系統各個組成部分的結構及其組成，選擇構造這一系統的技術方案，給出系統建設的實施步驟及時間安排，說明系統建設的人員組織，評估系統建設的開銷和收益。
㈣ 電子商務案例分析的基本情況、模式分析、各主體受益分析、發展前景與改進方法（急急急！）
基於商務社區模式的行業性B2B電子商務平台
摘要： 通過對一個行業性B2B電子商務交易平台主要功能進行分析和設計，闡述了在構建中國企業
自己的B2B電子商務平台時應注意的若干要點和思想．
關鍵詞： 電子商務：B2B；X~vIL；供應鏈；Call Cent~；客戶關系管理
中圖分類號：TP393 4 文獻標識碼：A 文章編號；1001-3695(2001)06-0096-03
Design Point about B2B E—business Trade Platform
Based on Com merce Comm unity
)rlE Shan． CHEN Jia-~ n
{Institute ofNawo~ ＆Database．College ofl~t'ormation Seieaee＆Tedmology,Dc~glmaL'nlve,tsity,Shanghai 200051，a- )
Abstract： The article had a discussion on so]lt~points buiIdin~B2B bu3i gg solutio．ofCIEaese Enterprises through analyzing
and d igning prDfessio~ [B2B E·bminessplatform
Ke)rword~： E-bw．sineas；B2B；XML；Supp]yChain；CallCentex；,CustomerRctatle~hip-Management(CRM)
1 引言
企業級電子商務一般被簡稱為B2B的電子商務過
程，它是一個將買方、賣方以及服務於他們的中間商
(如金融機構)之間的信息交換和交易行為集成到一起
的電子運作方式。通過在網上開展B2B電子商務，可
以使企業直接在網上進行貿易洽談、合同簽約、交易
交割和資金結算， 從而虯最大限度減少流通環節， 降
低流通成本，讓上網企業在交易過程中獲得最佳效益
2 行業B2B系統的設計思想
設計中的「行業性B2B電子商務平台」面對的是
行業的最終用戶和業內供應商和采購商，提供一個企
業間進行在線采購、營銷、招標等活動的電子交易平
台，其主要交易方式為批量商品交易 參與實體分為
交易平台服務商和(企業)客戶。其中前者提供了該電
子商務系統運營和維護所需要的硬體設備以及平台軟
件， 同時保證客戶網上認證和支付的安全性；而後者
既包括了企業間電子商務交易中的上游生產廠商、供
應商(賣方)， 也包括了下游經銷商、采購商(買方)。
事實上， 由於企業問交易的復雜性，往往一個企業會
兼有買賣雙重身份，但具體到一敬交易行為來說，該
企業～ 般只具有單個身份
3 行業性B2B電子商務平台的總體設計
31 設計原理
收稿日期；2000．10．03
設計原則有以下幾點：(1)先進性。整個系統的設
計無論從硬體伺服器上，還是軟體平台、開發工具方
面均採用目前最先進和最流行的方案 以確保應用系
統的先進性和開放性 f2)安全性 採用防火牆和用戶
認證(cA懶術，在企業內部Latrmmt網和B2B電子商務
交易平台以及Internet~行隔離和驗證。(3)可靠性和容
錯性。B2B電子商務應用系統的穩定性是最重要的因
素之一 因此設計方案將採用先進的伺服器硬體產
品、高可靠性的多機備份方案。(4)可擴展性 整個平
台系統開靛上採用模塊化、可移植的資料庫和應用體
系結構，保證整個應用平台能夠隨著入駐企業和業務
量的增加而進行性能和規模上的相應擴展。(5)標准性
和開放性 整個既可滿足當前可實現的應用要求，又
能適應今後系統擴展的需要 (6)高性能。採用高性能
的資料庫和web伺服器， 系統性能卓越 同時， 由於
能動態地分配系統資源，提高了系統軟硬體的利用
率 門灃富和易於使用的在線服務。為入駐及登錄商
家選擇豐富和實用的電子商務服務，使得商家在網上
信息發布，交易等商務活動的進行更方便和更具吸引
力 f8)易於維護。圖形用戶界面的遠程維護工具使得
企業日常數據信息的維護工作簡單易行
3 2 系統總體結構
圖1為行業性B2B電子商務交易平台系統結構示
意圈。交易平台通i塒行業產品信息和會員企業的交
易數據集成，在平台內部建立技術先進， 同時適用於
國內外電子貿易的B2B電子商務應用系統。並對^駐的會員企業不論是買方還是賣方，不論是國內企業
還是國外企業一都統一提供完整的、符合國際電子商
務交易規范的應用服務。形成一個 入駐企業為主要
服務對象的電子商務交易社區。而對非入駐企業則對
其提供產品信息瀏覽，查詢等服務
圖l 交易平芻系統結構示意田
系統基本上採用基於Lnternet／[ntranet的Browse!
Server的結構：使用DHIML和XIvIL技術實現動態的
目錄，企業用戶通~．q／ntemct就可方便地網站交易。如
圖1所示．可以將整個電子商務交易平台劃分為以下
兩個主要的子系統：
(1)交易平台管理子系統主要功能有：入駐會員管
理，並支持企業的客戶關系管理系統：公基商務信息
管理 數據分析管理： 系統運營維護管理：用戶認證
服務：在線安全支付服務。
(2)h駐企業子系統的主要功能有：與各自企業內
部系統的交易數據交換：在線發布信息服務，包括產
品、供求、尋求合作等功能；參照產品目錄， 為供應
商實現 購物籃 功能： 競價交易服務：業務分析功
能：管理和處理定單，應用商務邏輯規則， 與供應商
完成交易(企業與其供應商之間的業務關系均是按照
雙方的約定進行的，簡稱為邏輯規則，如定單信息需
要審核、需要一定的保證金等)。在線的供應鏈連接
管理：在線招／t％標和管理 在線合同管理：其它信息
發布和管理
4 該82B電子商務平台系統的設計要點
B2B電子商務系統的設計和實現無論在功能上還
是在內部採用技術上都與B2C，C2C電子商務系統有
較大的不同。B2B電子商務由於在前端要為眾多商家
服務，而其後端還要和多個企業內部系統相連， 進行
信息收集和交互工作。因此，B2B電子商務系統在平
台本身和各企業內部系統(如ERP，MIS)的信息交換和
資源共享方面有其獨特的設計和實現方案。下面就從
動態目錄發布，供應鏈管理， 客戶服務系統的實現這
三個方面分別闡述它們的技術實現要點。
4．1 基於XML的動態目錄管理和發布
B2B交易平台系統通過使用XML技術及相應開發
工具，開發出完整的為企業客戶服務的動態目錄管理
和發布解決方案， 以滿足買方和賣方的需要。對於供
應商而言，能夠提供經濟有效而且方便的處理方法，
以使其能方便快捷地定製和發布目錄信息內容。並能
讓供應商單獨對其發布的產品目錄進行增、刪、查詢
等管理， 同時又能匯總多個供應商的產品名錄成為網
站統一的產品目錄讓所有買家都能夠訪問。因此，對
於買方而言，這個解決方案可以快速地使其找到需要
的買方產品目錄，簡化了篩選和購買一項新產品和服
務的處理流程。目錄發布支持兩種方式：批量裝載(適
用於大容量數據裝載)、在線發布(適用於小批量數據
裝載和更新)。在線發布就是傳統的基於BrowscdScrver
的遠程登錄在線錄入數據，因此下面就批量裝載這種
較新的產品目錄撒據發布方案進行簡要分析和設計。
·准備目錄內容： 在裝載一個目錄內容到網站上
之前，供應商可以核對目錄內容是否符台要求的目錄
制定標准， 以保證所有目錄滿足標准。這些標準是網
站在線發布，企業用戶可以方便的獲取。
· 批量裝載目錄內容： 網站接收的目錄格式為
XIvIL格式數據文件 為了創建一個XIvIL文件，供應
商首先從系統下載一個XML資源包， 這個資源包包
括：文件類型定義、一個XML范倒文件和指導信息。
一旦收集好目錄項的信息，就可以使用文本編輯器或
XIvIL生成程序離線創建xML文件。
· 向網站提交數據：一旦以任何一種格式建立目
錄 供應商就可登錄到網站的在線發布目錄入口，並
提交這個文件。當該任務完成時，系統產生一個通知
發給供應商。這個通知內容包括：成功裝載的目錄行
信息和被系統拒絕的產品目錄信息(如果有的話)。
·載入資料庫：網站在伺服器端接收到企業客戶
提交的目錄數據文件後，再經過XML文件格式校驗合
格後，啟動XML-資料庫數據轉換工具， 將該XML格
式的目錄文件自動轉換為資料庫中的數據進行存放。
·發布成統一產品目錄： 網站在線同時將後台數
據庫中更新過的企業產品目錄數據，重新發布為到統
一目錄中。這時，該網站的所以用戶都可以瀏覽該目
錄信息 而提交的供應商用戶也可以在線修改自己發
布的目錄數據。
(企業佣戶產品目錄批量裝載的流程簡圖如圖2。
圖2 產品目錄批量裝載流程圖
4 2 供應鏈集成管理系統設計
在行業性的B2B交易平台中，供應鏈系統是其中
一個重要的子系統，通過該供應鏈管理系統，實現了
製造商與分銷商，零售商之間端到端的供應鏈管理， 縮
短了供銷鏈，幫助製造商和分銷商提高了周轉效率，更低的營運成本超越競爭對手， 確保領先優勢
對於行業性的B2B電子商務交易平台， 供應鏈的
集成需要連接製造商、生產商、分銷商、零售商，處於
交易平台中的企業之間需要多方面的數據交換和處
理，而通過行業的一套XML標准通信，可以無需了解
交易對方的內部資料庫結構 在供應鏈中，需要交換
的數據都可以XML形式統一交換
在圖3中， 電子商務平台系統中的B2B集成服務
器處在供應商和分銷商，零售商的數據交換的中間位
置 通過位於B2B集成伺服器、供應商和零售商的分
布式系統，賣方(供應商)和賣方(分銷商，零售商)兩個
系統之間的通信部是完全自動進行的
一
圉3 供應鏈管理系統結構圖
買方如果要訪問B2B電子商務平台連接的供應商
ERP系統以獲得零件的存貨水平， 可 用XML消息的
形式向B2B集成伺服器發出請求， 並通過HTTP協議
的標準的POSTh-法將請求發送出去 B2B集成伺服器
將這些請求弼譯成對口 系統的調用，然後再把來自
供應商ERP系統的應答信息翻譯成XML應答信息，並
發送給查詢信息的分銷商，零售商。
處於交易平台另一端的賣方(供應商)內部系統也
可訪問分銷商，零售商的數據。為了將對供應商的影響
減至最低．B2B使用了標準的URI和CGI查詢方式來請
求數據，並在應答消息中使用HTML~XML來統一不
同系統的交換數據 接收到買方傳來的應答消息後，
B2B集成伺服器就可把傳輸來的HTMLSNXML轉換成
適合賣方系統處理的數據表示，然後再把已轉換的數
據傳遞該系統，從而完成一個請求膻答的工作循環。
該供應鏈集成管理系統將^駐交易平台的供應商
和分銷商緊密地集成起來 在該系統中，任一企業用
戶系統都能和與之有商務往來的企業系統進行采購計
劃通信，且不要求該系統對網際網路、XML或其它企業
用戶系統的介面有任何了解
4．3 基於CTI的客戶服務系統方案
在企業與企業的交易行為中， 無論是從交易前的
產品和貿易夥伴的瀏覽、查詢， 到交易行為的發生，
以及交易後的支付和配送，網站和客戶之間， 以及買
方客戶和賣方客戶之間都會發生大量的、方便的、快
捷的信息交換， 因此僅通過WWW,~NE．fnail等信息交
換是不夠的。而基於CTI的客戶服務系統恰恰彌補了
這方面的不足。CTI(Computer Telephone Integration)
是「計算機．電話集成 的縮寫，它將傳統的、基於
電話的Call Center技術與當今基於Web的電子商務應
用相集成， 在交易平台和用戶之間建立了~,Web方式
以外的信息交換方式，如電話，Fax等， 為企業用戶
提供主動式的、一對一的行銷，太大加強了交易平台
與^駐企業客戶之間的關系。該系統工作流程如圖4。
囝4 c11工作流程囝
該系統在將客戶的瀏覽網頁記錄提供給服務專員
的同時，還可以在客戶上網的時間內不斷搜集客戶資
料並了解跟蹤客戶的商務行為，並且和企業內原有客
戶記錄整合， 當某一新產品推出時，就自}立即找到適
當的潛在客戶，發動網路行銷 該客戶服務系統方案
能把整個交易平台中所有的市場和客戶的信息進行統
一管理、共享，井能進行有效分析，從而為企業用戶
的銷售、營銷、客戶服務等提供全面的支持。
5 結束語
本文所闡述的行業性B2B電子商務構建方案，在
盡可能利用B2B電子商務的長處的同時，也充分考慮
到中國企業和中國網路環境的具體特點 使得該方案
有較好的性價比和伸縮性 可以為那些建設網上垂直
交易市場的中國企業提供全面的技術解決方案和外包
服務，幫助這些傳統企業建設自己的網上交易系統。
每一個企業部可以迅速地建立自己的網上市場，把任
何一個垂直行業中的購買者和供應商連接在一起，創
造新的盈利機會。通過該B2B電子商務平台解決方
案，那些在各個行業內部具備行業背景優勢、產品技
術優勢和信息資源優勢的行業領導性企業可以更快地
建立自己的網上行業交易市場，為企業掃清電子商務
的技術障礙，盡最大程度減少基礎投資和時間開銷，
更快、更好地開展行業電子商務。
㈤ 電子商務系統有哪些重要的性能指標
人盡其才、物盡其用」。企業購買伺服器當然是為滿足特定需要。針對不同需求，我們要關注的性能指標也不同。舉例來說，對於資料庫伺服器，聯機事物處理能力是最需著力考察的指標。TPC-C是「事務處理性能委員會」(TPC)負責制訂的基準測試指標，考察聯機事務處理每分鍾吞吐量。而TPC-C測試結果又包括兩個指標，一個是流量指標tpmC，這個值越大越好;另一個是性價比指標Price/tpmC，指的是測試系統價格與流量指標的比值，這個值則越小越好。以IBM公司的x366為例子，根據TPC官方網站，TPC-C在線交易基準測試中，x366的流量指標達到了141504tpmC，是4路至強晶元伺服器的世界紀錄。 再比如說，購買Web伺服器時，最重要的性能指標就應該是SPEC web99。SPEC web99為Web用戶提供了用於評測系統用作Web伺服器能力的最客觀、最具代表性的基準; 而如果是選購應用伺服器，關注SPEC jbb200和SAP SD這兩個指標就能知道大概其了，因為SPEC jbb200是專門用來評估伺服器系統運行Java應用程序能力的基準測試，而SAP SD 的測試結果為客戶提供了基本的規模建議。 對於大多數人來說，基準測試指標是一個全新的知識空間 – 許多人在購買伺服器時習慣於考慮CPU和內存，以為選定了這些，伺服器的性能就差不多了。其實，不同的系統設計技術會對伺服器的性能產生巨大影響，用諸多量化指標來衡量比較是十分必要和重要的。 用戶都希望系統能24×7×365不停機、無故障地運行，這其實是要求伺服器的可用性。而可用性和可管理性是息息相關的。伺服器的故障處理技術越成熟，為用戶提供的可用性就越高，而這個故障處理技術必須要有良好的管理手段和界面來及時表現:一方面可以通過出現故障時自動執行系統或部件切換以避免或減少意外停機，另一方面要讓管理員及時察覺及幫助診斷，才能從根本上解決問題。目前這方面做得較好的是IBMx3架構伺服器。它帶有一種叫「彈出式光通路診斷面板」的技術，只要輕輕，光通路診斷面板就會以從伺服器前端彈出，指示器可以幫助管理員快速地定位和替換故障組件，減少伺服器的宕機時間。 以基準測試指標為基準，以理性考量為准繩，二者並行互航，您選擇的伺服器肯定錯不了! 附表:部分伺服器性能指標 應用 基準測試 簡述 測試中主要考察的部件 聯機事物處理 TPC-C TPC-C是一種考察聯機事務處理（OLTP）每分鍾吞吐量的基準測試。TPC-C模擬的是完整的計算環境，大量用戶針對資料庫（如SQL、Server Oracle,DB2）執行並發事務操作。許多IT專業人員將TPC-C視為衡量「真實」OLTP系統性能的有效參考基準。 全面考察微處理器，內存子系統，磁碟子系統合一些網路組件 電子商務 SPECweb99 SPECweb99用於評測Web伺服器能夠支持的最大同時連接數的客戶端/伺服器基準測試。基準負載是由運行HTTP Server的伺服器聯網的客戶端設備上的客戶端軟體來實現的。為Web用戶提供用於評測系統用作Web伺服器能力的最客觀、最具代表性的基準。 系統的微處理器、內存體系結構和編譯器 SPECjbb200 SPECjbb200（Java業務基準）是SPEC第一個用於評估伺服器端Java的性能的基準，為Java用戶提供用於評測伺服器系統運行Java應用程序能力的最客觀、最具代表性的基準
㈥ 假定你是一名項目負責人，現在要求承接一個電子商務系統的研製工作，請思考:
別人已經問過一個相同的問題，我把我的答案貼過來！
假設你是一個項目負責人，現要求承接一個電子商務系統的研製工作：
1、在進行系統設計時，是否已經選定了開發語言？如果是，開發語言本身具有的局限會不會導致系統設計時進行折衷？這些折衷能否控制在用戶接受的范圍內？如果不是，你是怎樣做的？為什麼？
答：一般情況下在進行系統設計時，都已經確定了開發語言，因為在設計時，要考慮開發語言的具體情況和要求，在實際工作中一般的設計不可能完全脫離開發語言的要求的，在系統概要設計時，可以不考慮將來的具體開發語言，即可以進行一些純粹的抽象式設計，但是在進行詳細設計時，就要考慮將來具體的實現問題了。每種開發語言肯定有自己的局限性，但是我們肯定不能因為它具有局限性，實現某個功能很困難或者成本太高，就犧牲軟體的質量，或者在設計時，就不符合需求的要求了，而且即使你選擇了某種開發語言，但是也沒有規定你不能使用其他語言開發系統功能呀？現在的系統架構一般都是能夠組裝的，很大一部分都是別人開發好的，你來使用的，比如常用的「按鈕」，其本身就是別人開發好後，進行了封裝，然後你拿來使用的。開發程序不要在一棵樹上弔死。
在進行設計時，處於各種原因，例如成本問題、時間問題，市場、用戶要求等因素，肯定會出現一些變更，這些變更可能就包含你所謂的「折中」，這是很正常的，但是這些變更肯定要用戶能夠接受，而且在進行變更之前一定要徵得他們的同意，因為項目干係人或者說用戶的滿意度，在某種程度上說決定了你項目的成功與否。需要說明一點的是，用戶的需求也是在不斷變化的，在項目結束時的需求，可能與項目開始之初，可能大相徑庭。總之，要多和項目干係人溝通，徵得他們的理解和支持。
2、開發的效率和時間怎麼進行控制？
項目應該有專門的進度管理，即在項目之初要制定比較詳細和使用的項目進度計劃，一般的步驟是1）活動定義：根據項目范圍說明書等要求，對WBS（工作分解結構）的基礎上進行進一步分解，得到最底層的交付物、確定到底要做哪些事情，最終輸出是什麼；
2）活動排序：確定各個活動之間的依賴關系，形成項目網路結構圖，知道影響項目的關鍵路徑；
3）活動資源估算：確定這些活動正確執行都需要哪些資源（人、財、物等），什麼時候需要；
4）制定進度計劃：更具全面所做的工作，制定具體的項目進度計劃，也就是確定每項工作的實際開始時間和結束時間，其依據除了上面的工作成果外，還要綜合考慮項目的合同（也就是硬性規定的結束時間），公司的資源使用情況（什麼時候能夠得到什麼資源），以及可能的風險記錄。甘特圖是一個比較不錯的選擇；
5）進度控制：制定完計劃不是就萬事大吉了，還要對計劃的執行情況進行監督和控制，例如要不斷地進行檢查，要查看實際進度是否和原定的計劃有偏差了，如果發現有偏差，要對偏差進行分析，找到偏差的原因，然後提出改進建議，並根據實際情況對計劃做出調整。
進度控制的步驟一般而言包括：
1）分析進度，找出哪些地方需要採取糾正措施；
2）確定應採取那種糾正措施；
3）修改計劃，將糾正措施列入計劃；
4）重新計算進度，估計計劃採取的糾正措施的效果；
當項目進度滯後於計劃時，可以採取以下一些措施縮短活動的工期：
1）投入更多的資源加速活動進程
2）指派經驗更豐富的人去完成或幫助完成項目工作；
3）減小活動范圍或降低活動要求（最好和用戶溝通好）；
4）通過改進方法或技術提高生產率；
實際工作中就是縮小項目范圍或降低要求，趕工、快速跟進；
3、選擇開發語言時，主要依據是什麼？
答：選擇開發語言時，除了項目本身的特點外，可能還要考慮公司的資源情況，例如是否有現成的東西可以使用（原來是否開發過類似的系統），公司現有的技術人員都擅長於哪些語言（特別是主要技術人員），即開發成本和效率問題也是要納入你的考慮因素的。否則你的開發成本和開發效率是很大的問題，很有可能會導致項目失敗。
4、如果已經有類似的系統在市場上出現，你進行設計規劃時，怎麼考慮上述因素（說明：每種語言（工具）都有自己的優點缺點，而不同系統的要求一般不同，在設計時以自己的項目組熟悉的語言為基礎進行設計開發，還是考慮系統要求，規劃出框架後，再選擇合適工具，是一名組織者要考慮的問題，時間、效率、完成情況等很多問題總是困擾著設計者）
答：市場上有類似的產品出現，你看定要考慮的。要根據實際情況，找到其優點，分析後確定可以吸納到自己系統中的東西，當然前提是項目干係人或者說用戶要認可，不要自己主觀的進行判斷，要多和用戶溝通。和用戶或者需求人員共同確定市場上同類產品的優缺點，從而對自己系統有借鑒作用。
針對你括弧中的問題，我個人項目的最終目的是達到項目的目標要求，從而最終要讓企業盈利，花最少的錢，做最好的事情，總歸是沒有問題的。其他東西都是實現目標的工具和手段，只要能夠達成目標，採用什麼手段或技術都不應該放到第一位。
5、實施國家電子商務戰略的措施有哪些？
請查看《中國電子商務發展戰略綱要》，關於大政方針的事情，這里就不做評論了；
6、應如何解決電子商務發展的幾個重大問題？
不知道你指得是那幾大問題，每個專家，都是仁者見仁，智者見智。問題太大了，呵呵
7、假設你是某個IT行業的總裁，你將如何制定你公司未來五年的電子商務戰略？制定原則是什麼？
答：你這個問題和你所處的行業有關，針對的行業不同，可能其具體規劃具有天差地別的區別。不過制定的原則，肯定是如果你有比較雄厚的資本支持，則可以先不掙錢，進行較為長遠的鋪墊和規劃，例如顯出一個產品，以低價或者免費的方式供別人使用，在某一領域佔領足夠大的市場份額，達到一定程度後，在逐漸加入收費的項目，逐步實現盈利，例如微軟的IE的使用就是這種方式。如果你的公司比較弱小，那麼首先要解決的就是生存問題，怎麼能夠存活下來，是要要考慮的首要問題，都不能生存，其他的就別談了，可以先做一些定製項目，能夠拿到現錢，養活你的技術人員和後勤保障人員，並在實際項目中，逐步總結自己的特點，等具有一定的富裕精力和資本後，在根據自己積累的東西形成自己的產品，逐步地發展壯大。
8、假設你是一位企業的決策者，你要對你公司進行改造來適應電子商務，面對如此多的技術，你如何抉擇？從技術上考慮，你怎麼做自己的電子商務。
答：如果我是企業的決策者，都先第一步我要成立一個班子，其中包括業務專家和技術專家，必要時可以聘請外部人員，對我公司的現狀進行評估，給出我一套完整的解決方案，這套方案要有足夠的高度，而且還有考慮我公司現有的資產（老系統）的使用，並且其成本要在我的可接受范圍內。其實採用何種技術，正如前面我所說的，只是一種具體實現的手段和方式，作為老闆的你（用老闆的高度思考，而不是技術人員的思維），並不是你要考慮的，你要考慮的是怎麼花最好的錢，辦最多的事情，而且過去的投資最好不要浪費，要能夠充分的利用。
呵呵，從你問的問題，可以想見你是一名技術人員，或者是一名技術出身的設計者，考慮問題的角度，還是以技術為重。我認為作為一名項目管理者或者公司的老闆，技術並不是最重要的，技術先進性與否，都沒有太大的關系，適合自己的才是最好的（花最少的錢，辦最好的事）。
㈦ 作為系統工程，電子商務系統建設主要包括哪些內容
包括商務、技術、支付、物流等許多角色與要素的系統工程。在開專始建設電子商務系統之前，屬必須充分研究涉及電子商務系統的所有因素，全面分析、統籌規劃，形成盡可能完善的電子商務系統設計方案，在此基礎上有條不紊地進行電子商務系統建設。
對於大型企業電子商務系統，尤其要重視強調系統規劃設計。如果不重視電子商務系統的統籌規劃，或者不按照事先的統籌規劃進行電子商務系統建設，建成後的電子商務系統很可能出現協同困難，難以實現系統的預期功能，難以實現系統建設的目標，從長遠看還會造成資源浪費，使得將來必須為之付出更大的系統改進與整合成本。
㈧ 電子商務系統對企業的發展有什麼樣的促進作用
隨著不斷加快的經濟全球化進程以及信息技術的快速發展,貨幣金融體系電子化的實現將是一個必然趨勢。在不久的將來,在電子商務不斷發展的帶動下,電子貨幣也將會在社會經濟生活中得到更加全面的發展。如果企業在發展的過程中忽視了電子商務的重要性的話，將會給企業本身帶來難以彌補的損失。
匯亞電子商務系統整合了多款軟體後台，讓企業的管理一站式解決。
1. 網上門店：多級產品展示，搜索，購買，推薦，排行，社區，客戶賬戶，促銷廣告。
2. 客戶關系管理系統：客戶信息管理、訂單管理、自動簡訊和郵件營銷平台、商機管理。
3. 進銷存：供應商管理、采購管理、進貨管理、庫存管理、庫存預警、出貨管理。
匯亞的產品價值：
１．跨越了以往的時間和空間障礙，讓客戶可以隨時，隨地訂購企業的產品。
２．集中化的管理企業的銷售渠道，統一的資料庫，讓以前多門店管理難的局面徹底消失。
３．大幅度降低成本，讓企業的交易成本，和產品庫存成本降到最低，企業不需要為每個門店准備庫存，完全可以按照拉動式，讓物流中心直接配送到全世界的每一個角落。
４．有效的把握客戶，通過系統的記錄和分析顧客的行為等一系列數據，制定有效的營銷和自動銷售策略，讓企業的回頭客大大增加．因為網路是一個可以聚集顧客的途徑。
５．大幅度縮短企業的品牌的宣傳和客戶聚集的時間。
㈨ 電子商務系統建設過程
這問題很大。
內容涉及到正本書籍。
建議：網路搜索該書，進行了解。
㈩ 電子商務系統設計
電子商務系統是互聯網時代計算機系統的主流應用，是集成了數據管理、事務處理、業務流程重組、系統安全管理等技術的復雜系統。很多企業管理者和信息系統技術負責人在被電子商務系統的廣闊前景所吸引的同時，亦為不知如何開展電子商務系統的建設而煩惱。系統集成商參與項目開發的困難更多：用戶需求不準確、經常變化，開發人員與業務人員溝通困難、誤差極大。最後上網工程變成了網頁設計大賽，花費了大量人力物力建造的網站並沒有為企業帶來預期中的收益，反而變成了一個擺設，甚至因為要不斷投入維護費用而成了企業的負擔。 本文著重討論電子商務系統工程中系統需求分析和系統概要設計的基本方法，向項目經理和技術負責人介紹如何組織電子商務項目的開展。事實上電子商務系統一方面是一個相當復雜的工程，需要科學的系統規劃和項目管理，另一方面電子商務系統也只不過是一種應用計算機的系統工程，雖然涉及的技術內容和業務因素較多，但只要遵循合理的系統工程實施方法進行，仍然可以順利地完成電子商務系統的建設。 電子商務技術可能目前世界上最令人眼花暸亂的技術領域，新名詞、新技術、新術語每天都在出現，如何建設電子商務系統，似乎有無數種可能，令人無所適從，不知如何作出正確的決策。技術本身並不能為企業帶來效益，只有合理應用技術建造的系統才能幫助企業解決業務運作中的問題，幫助企業發展業務，所以設計電子商務系統時必須堅持一個原則：企業的需求是目的，任何技術都只是實現需求的手段，建設電子商務系統不是為了應用某項新技術，而是為了解決企業的實際問題。只有堅持這個原則才能避免常見的失誤：採用了很多不成熟或者復雜的技術，工程費用超標，項目進度無法保證，應用效果未如理想等等。電子商務系統的目標可以用以下幾個問題來總結。 應用環境：系統將為哪些用戶服務？他們使用什麼平台，如何訪問企業的電子商務系統？ 系統功能：系統為用戶提供了什麼服務？哪些是已經有的，哪些要修改，哪些要重新開發？ 數據資源：為了實現這些服務功能，系統將使用哪些數據？數據量多大，如何存儲？ 安全管理：系統的安全性如何保證？系統管理如何實施？其中系統功能是范圍最廣泛的問題，從最早的信息發布到現在很流行的B2C，B2B，ASP等都是系統功能的一種，按實現這些功能的技術核心可以分為三類： 1 信息共享與數據交換
數據存儲與數據通訊技術是實現這類功能的核心技術，這類系統幫助用戶通過電子郵件、搜索引擎、數據發布技術等高效地獲得信息，提高數據交換的速度與信息共享的效率。 信息共享型的電子商務系統可以降低企業內部由於信息溝通不靈而帶來的損耗，減少日常工作的文書往來，提高工作效率，更有效地管理企業內的信息使用情況。 2 電子商務交易
以電子化的方式實現商務交易過程中的每一個步驟，能適應業務的快速發展而變化是實現這類系統的關鍵，電子商務交易系統是目前最具挑戰性的領域，技術核心是應用系統開發能力與事務處理技術，其中也包括與金融系統介面進行網上支持的SET及相關技術，目前的B2C，B2B即屬於這一類系統。 電子商務交易系統是現代企業在互聯網時代擴展新市場的重要手段，設計良好的交易系統能使企業一天24小時不停地運轉，為客戶提供優良的服務。如果能將企業核心業務系統與互聯網系統有機地集成起來，就能大大地擴展企業的運作范圍，降低經營成本和銷售成本。 3 互聯網伺服器上的應用服務
擴展互聯網伺服器的服務能力，定製滿足客戶需求的應用服務，其內容可能包含了所有電子商務系統的功能，JAVA技術與事務處理技術是這類系統的技術核心。這類系統通常指企業級的門戶網站或ASP，由於其極高的處理負載，還需要提供額外的集群技術、性能管理等復雜的技術支持。 這類系統或者是把原有的企業核心業務系統與互聯網伺服器集成起來，或者是在互聯網伺服器上開發功能完善的應用服務系統。訪問這類互聯網伺服器的客戶能得到自動更新的最新數據，獲得定製化的自助服務。訪問這類系統的客戶數極多，因此要求具有較好的可擴展能力，性能不會受客戶連接數變化的影響，一直保持良好的狀態，所以要採用連接管理技術、事務管理與資源協調等復雜的技術。 本文分三大部分，分別介紹系統需求分析與系統設計的組織方法，以及開展功能檢驗與性能測試的過程，著重介紹基本原則，並不泛及特定相關技術的細節。至於系統實施階段所採用的技術與方法，由於電子商務系統的復雜性、新技術層出不窮，實在不是用一篇文章甚至一兩本書所能涵蓋的。 系統需求分析 系統需求分析是為了系統開發人員准確地理解業務部門的目標，制定合適的實施方案，系統需求對系統實施的重要性不但應該反復強調，還應該避免收集系統需求過程中常見的幾個誤區： 1 系統需求分析不是一次性的工作，而是一個反復遞進的過程，隨著電子商務應用系統的推廣，業務部門會提出新的需求，或者改變原來的業務需求。這是允許的，而且是正常的，技術部門不能拒絕業務部門提出的新需求，而應積極配合，對原有的實施方案作相應的改變。
2 系統需求的根源是業務部門運作的需求，而不是技術部門為了實現某種先進技術而提出的需求。系統方案不能因為出現了某項新技術而作改變，畢竟，使用新技術只是手段，支持企業的商業運作才是最終目的。
3 系統需求不僅限於業務需求，還包括了客觀條件的各種限制，如項目進度的要求、與已有系統兼容的要求（如企業的所有核心數據都已經存儲在Sybase資料庫中、或者企業的舊系統留下幾千台終端必須加以利用）或其他政策法規的限制（如商業系統中使用的密碼系統必須經過政府有關部門的認證）。制定應用系統的實施方案時應把這些因素考慮在內。
收集系統需求的主要途徑是系統分析人員與最終用戶通過交談發掘搣真正攠的系統需求，獲得用戶的認同，在業務部門的幫助下准確地認識業務環境（這一點是大多數技術人員最缺乏的），收集足夠完整的信息，完成一系列文檔作為確認本階段工作的檢查標記，並作為進行下一步工作的基礎。
哪么什麼才是搣真正攠准確的系統需求，當一個客戶向系統分析人員提出要求：搣我們要建立一個網上商城，讓我們公司的客戶可以在網上直接下訂單攠，這是一個絕對真實的要求，但並不一定是一個准確的系統需求，或者說這並不一定是最適合該企業實際需求的目標。因為客戶在提出要求時，一般已經對電子商務有了一些先入為主的認識，認為電子商務就是這樣的，或者只能是這樣的，又或者同行和競爭者已經這樣做了，所以我們也要這樣做。實際上他們所真正需要的，可能比這個要求多，可能比這個要求少，甚至完全是另一個系統。這時系統分析人員就要耐心地發掘客戶的實際需求，通常是提出這樣的問題：
您希望這套電子商務應用建立起來後，能為您的企業達到以下這些目標中的哪些呢？哪些目標是您最希望達到的，您認為您的企業目前在這些方面存在什麼主要問題，您希望電子商務系統能在多大程度上解決這些問題呢？
增加客戶數量 降低企業運營成本或提高營業額
提升公司的總體形象
加快產品推向市場的速度
使企業比同行更具競爭力
縮短新產品的開發周期
改善庫存管理和采購流程管理的效率
改善企業與代理商之間的合作關系
提高客戶滿意度和客戶服務的質量
提高本企業員工的合作溝通效率
幫助企業拓展新的市場這樣的談話最好是在系統分析人員和企業的業務負責人之間進行，而不和企業的電腦部門技術負責人，只有這樣才能發掘出系統真正的需求。系統分析人員通常會從企業負責人那裡得到一些與電子商務技術完全無關的情況，例如搣客戶抱怨我們的交貨期不準時攠、搣我們的企業太大了，各部門間的合作溝通很成問題，總是左手不知道右手在做什麼攠等。這樣的交談能幫助系統分析人員准確地為電子商務系統定位，規定其功能邊界。
企業的負責人通常會更多地著眼於總體的業務規劃，負責需求分析的系統分析人員和項目經理應利用這個機會，向企業管理人員詳細地解釋幾類電子商務系統的功能和應用，啟發他們更深入地發掘企業的需求，以實踐經驗和成功案例向他們說明企業電子商務系統的預期目標，幫助他們樹立正確的期望值。多數企業都是第一次實施電子商務系統，且由於媒體的大肆宣揚等外界因素的影響,可能對系統的預期效果產生不切實際的期望，系統分析人員在需求分析階段就要准確地掌握和調整客戶的心理期望。客戶的期望值也是系統需求的一個重要因素，直接影響系統完成後的實施效果。
客戶的態度和技術水平是影響系統設計者作出方案的重要因素，也是系統需求的一部分，系統需求分析階段要和客戶一起作出充分的交流和評估。客戶的態度指企業決策者對新技術的接受程度以及願意承受風險的程度，電子商務領域的新技術層出不窮，成熟技術的功能比不上新技術，但風險卻較低，企業決策者在這方面的態度影響系統設計者設計方案時的技術選擇，如果企業決策者選擇較先進的新技術，系統分析人員有責任提醒他採用新技術可能面臨的風險：失敗的可能性較高，項目進度和開發成本可能超出預期。切勿投客戶所好，隱瞞新技術背後的不利因素。企業決策者在選擇系統集成商時也應小心，集成商的技術水平不是由掌握新技術的程度所決定，而是由他們運用技術解決實際問題的水平所反映。
中國的大多數大型企業都有專門的計算機部門，電子商務系統建成後維護管理甚至二次開發的工作都將由他們負責，方案設計時也應把客戶方技術人員的知識基礎和專業訓練程度考慮在內。系統需求分析階段最好對客戶方技術人員作一次全面的評估，考察他們對與電子商務系統相關的技術領域的掌握程度，評估的內容有：互聯網伺服器，對象技術，JAVA，應用開發工具，資料庫技術，事務處理技術，安全技術以及對工業標準的認識程度。
系統分析人員要把這些分散的需求匯總成系統的目標，製成初步系統概要需求書，准確而完整地描述企業的總體需求，再次強調系統的預期目標，並獲得企業負責人的認同，再在此基礎上作系統的初步設計。
系統需求分析的工作並未就此結束，反而才剛剛開始。項目經理應作一些准備工作，召集第一次項目會議，會議的參加者包括客戶方的業務和技術負責人，以及項目建造方的項目經理，會議的主要目的是進一步確認和細化系統概要需求書中列出的需求，確定系統建造的方向。這些會議應原則上達成下列這些目標： 1.詳細討論當前環境的情況和系統需求。2.檢討目前正在使用的應用系統，明確列出需要解決的問題。3.在適當的時候交換各自對電子商務系統所持的思路與觀點，創造較易達成共識的認知基礎。4.確定系統的主要目標，當系統需求的范圍比較廣泛，系統目標也可分為短期目標和遠期目標。5.列出為保證系統順利而要解決的主要問題，劃出最突出、最緊迫的問題，爭取客戶方的合作，在系統開始實施前即加以解決。6.向客戶解釋實施系統過程中使用的核心技術和方案的總體思路。7.基於會上達成的共識，制定各人的行動計劃表。這樣的一個會議不可能在一兩個小時內完成，可能需要幾天的時間，甚至在不同的場合下以不同的形式組織，如方案展示會、討論會、現場參觀等。在條件許可的情況下，組織項目會議成員參觀一些類似的電子商務系統，作為背景參考資料，引導項目會議成員參考成功的電子商務系統的實施經驗，對會議的成功有很大幫助。IBM在全世界各地幫助實施電子商務系統的經驗表明，這樣的項目會議對項目的成功有極其重要的意義。項目會議上技術人員與業務人員面對面地交流，節省了大量時間，技術人員能更好地理解業務人員的需求，作出切合實際的方案設計，業務人員也能更好地了解技術手段的限制，雙方的溝通還可以促進企業的業務流程向更合理、更適合計算機管理的方向改進。
實際運作中，參與項目會議的管理人員的時間相當寶貴，把所有人集中起來的機會不多，項目會議的召集人不能簡單地約定一個時間就召開會議，應該在召開會議前作認真的准備。准備工作主要有以下這些：1.確定客戶方的與會者名單，和每個與會者單獨交談，說明會議的目的，聽取他們的意見收集更細致的需求。客戶方與會者人數以四至六人為宜，太多了溝通效率就會下降。2.確定開發方的與會者名單，開發方的與會者人數以四人左右為宜，主要是項目負責人、系統設計員、開發經理和技術負責人，確定會議上討論的題目，為每個題目指定責任人向客戶說明。雙方與會總人數不宜超過十二人。3.准備需求分析文檔作為討論的基礎，這些文檔主要的內容是：
目標系統概述：目標系統的主要功能描述和運作方式。
* 系統結構：當前系統的邏輯及物理結構，正在運行的軟體及其配置圖。
* 資料庫結構：描述企業核心數據的結構，確定哪些數據將開放到互聯網伺服器上，互聯網用戶訪問數據的方式與范圍。
* 網路環境：當前系統的網路拓撲結構圖，目標系統的網路結構圖，以及網路上採用的工業標准如通訊協議、命名規則等。
* 安全性要求： 企業系統當前使用的安全管理方式，以及為適應電子商務系統的運行應作出哪些安全管理方面的改進。
* 性能要求：系統性能受很多因素的影響，性能要求分析把事務流程分解，針對每一環節討論性能要求，充分討論制約性能的不利因素，以及保證性能要求的技術手段。
系統組織結構圖：企業的人事組織結構和業務流程圖，列出為了保證電子商務系統順利運行而配置的組織結構，及每個崗位的技術素質要求。4.會議召開前公布會議的主題，以及與會者名單，附上每個人的背景材料如職位、在項目中的角色等。總之，會議前訂立明確的主題和充分的准備（包括文檔准備和會前的單獨溝通）是會議成功的基礎，作為會議召集人，要在會上以自已的技術基礎與行業知識作出方向性的指導，控制時間，及時制止會上一些不能在短期內得出結論的討論。會議的重點應放在分析系統的現狀與需求，避免過早地引入特定的技術手段，以免提前給方案的設計設下局限。系統現狀的分析除了總結與回顧在第一階段所作的系統需求的結果，還可以具體地對現有環境作技術性的分析。
系統環境的技術性分析主要有以下內容：
* 網路環境的分析：網路拓撲結構分析，當前系統的網路結構，網路上的伺服器配置等。網路流量需求分析，分析當前網路帶寬是否能滿足新系統的要求。網路系統的安全體系及安全管理策略，電子商務系統是比傳統的企業網更開放的系統，安全性要求更嚴格。
* 應用環境的分析：當前系統的軟體配置及版本，應用程序的運行模式（運行平台、是否需要實時訪問和聯機事務處理等）。資料庫結構，應用系統的核心數據模式。用戶熟悉的應用開發方式和熟練掌握的開發工具，用戶的經驗可能是寶貴的資源，能加快系統開發的進度和保證系統使用的效果，因為無需重新培訓而節省成本、降低風險；也可能是採用新技術的重大阻礙，由於習慣性心理而抗拒新的開發工具和應用運行方式，即使投入大量資源重新培訓，仍然要冒很大風險，系統維護人員可能由於不熟練而發生人為失誤，造成運行故障。這種情況在中國企業中尤其普遍，系統設計人員要以非常謹慎的態度來對待。
* 客戶運行環境的分析：電子商務系統的客戶是互聯網上使用瀏覽器或其他設備的客戶，不同於傳統的企業內部網中所有客戶運行環境都是預定定製的固定環境，系統需求列出電子商務系統支持的客戶環境要求，如瀏覽器類型，是否要支持JAVA，是否支持上網手機等。
* 其他特殊需求，如客戶的系統一定要採用Linux平台，或者有特殊的多國語言字元支持問題等。
經過詳細的分析後，項目會議最可能的結果就是聽到一大堆意見和要求。一個可控制進度與預算的項目不可能達成不受控制地產生的要求，分出輕重緩急才能簡單直接地解決問題。項目負責人先取得與會者的認同，目標太多不能在一個項目內完成，請大家先選出要在當前項目內完成的目標，然後評估這些目標的重要性。如果意見不能統一，被列為很重要的目標仍然很多，就要重新篩選這些目標。對於最後列出的目標，再次徵求大家的意見，確認這些目標已經包含了目標系統的基本功能，沒有重大的錯誤和遺漏。系統設計者對被列為很重要的目標和要求應特別重視，它們是影響系統方案的主要因素。第一次項目會議的成果是詳細而明確的系統需求，系統設計人員根據系統需求和目標進行詳細的方案設計。