商業系統論文精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的商業系統論文主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：商業系統論文范文

一、周期法該方法是由結構化系統分析和設計組成的一種管理信息系統開發方法，圖1結構化生命周期法的開發過程亦稱結構化生命周期法。其基本思想是將系統的生命周期劃分為系統調查、系統分析、系統設計、系統實施與轉換、系統維護與評價等階段。應用系統工程的方法，按照規定的步驟和任務要求，使用一定的圖表工具，完成規定的文檔，在結構化和模塊化的基礎上進行管理信息系統的開發工作。結構化生命周期法的開發過程一般是先把系統功能視為一個大的模塊，再根據系統分析設計的要求對其進行進一步的模塊分解或組合。基本做法如圖1所示。結構化生命周期法主要特點是：

⑴開發目標清晰化。結構化生命周期法的系統開發以"用戶第一"為目標，開發中要保持與用戶的溝通，取得與用戶的共識，這使管理信息系統的開發建立在可靠的基礎之上。

⑵工作階段程式化。結構化生命周期法每個階段的工作內容明確，這便于開發過程的控制。每一階段工作完成后，要根據階段工作目標和要求進行審查，這使階段工作有條不紊，也避免為以后的工作留下隱患。

⑶工作文件規范化。結構化生命周期法每一階段工作完成后，要按照要求完成相應的文檔報告與圖表，以保證各個工作階段的銜接與系統維護工作的便利。

⑷設計方法結構化。結構化生命周期法采用自上而下的結構化、模塊化分析與設計方法，使系統間各個子系統間相對獨立，便于系統的分析、設計、實現與維護。結構化生命周期法被廣泛地應用于銀行管理信息系統的開發中。該方法適合于銀行業務工作比較成熟、定型的系統，如作為銀行管理信息系統信息采集的自助銀行、企業銀行、電話銀行、銷售點服務系統、多媒體查詢系統等為客戶提供金融服務、信息咨詢的系統。在管理系統開發方式上，銀行根據系統的復雜程度以及自己的人力、資金等狀況，可在獨立開發、合作開發、委托開發、購買現成軟件這四種模式中選擇其一。二、原型法該方法是一種根據用戶需求，利用系統快速開發工具，建立一個系統模型，在此基礎上與用戶交流，最終實現用戶需求的快速管理信息系統開發方法。原型法開發過程包括系統需求分析、系統初步設計、系統調試和系統轉換、系統檢測與評價等階段。用戶僅需在系統分析與系統初步設計階段完成對應用系統的描述，開發者在獲取一組基本需求定義后，利用開發工具生成應用系統，快速建立一個目標應用系統的最初版本，并把它提交給用戶試用、評價、根據用戶提出的修改補充，再進行新版本的開發，反復這個過程，不斷地細化和擴充，直到生成一個用戶滿意的應用系統。原型法的開發過程如圖2所示。目前,我國市場上的管理信息系統快速開發工具有：POWERBUILDER、VISUALBASIC、VISUALFOXPRO、DELPHI等。利用這些面向對象的開發工具，可使開發者的精力和時間集中于分析應用問題及抽取反應應用系統實質的事物邏輯上，而不再拘泥于應付處理繁瑣的開發實現細節，節省了大量的編程工作，并且使系統界面美觀，功能較強。原型法具有開發周期短、見效快、與業務人員交流方便的優點，被廣泛地應用于銀行的財務報表系統、信貸管理系統、工資人事管理系統、固定資產管理系統等的開發中。三、綜合法綜合法是將周期法和原型法兩者結合使用，采用結構化生命周期法的設計思想，在系統分析與系統初步設計上采用原型法作出原始模型，與用戶反復交流達成共識后，繼續按結構化生命周期法進行系統詳細設計及系統實施與轉換、系統維護與評價階段的工作。綜合法的優點是它兼顧了周期法開發過程控制性強的特點以及原型法開發周期短、見效快的特點。商業銀行在管理信息系統開發中，可針對不同的實際情況，合理采用綜合法，使開發過程更具靈活性，往往會取得更好的開發效果。四、實例今年上半年筆者采用原型法，開發了交通銀行南通分行計劃信息管理系統，下面就以該系統為例具體介紹一下原型法的主要開發過程。（1）系統需求分析、系統初步設計。通過與計劃處交流，明確了本系統的設計目標，即通過對財會處人民幣和國外部折美元會計月報表、資產負債表、損益表及計劃處信貸收支表數據進行收集、存儲、檢索、傳輸、加工、分析，為計劃處及其它管理部門的科學決策服務。并根據確定的設計目標初步完成系統基本數據流圖、主要功能模塊圖、網絡結構圖的設計。

（2）系統模型的確定。為實現不同部門間信息資源的共享，本系統的基本模式設計為典型的Client/Server體系結構，在分行計劃處設立數據庫服務器，作為數據處理中心，計劃處及其它管理部門的客戶機，通過局域網與服務器相連，進行操作。Server端采用Sybase數據庫作為數據庫系統，Client端采用PowerBuilder6.5作為開發工具，網絡協議采用TCP/IP的通訊協議。

（3）系統模型的實現。使用面向對象的PowerBuilder6.5設計界面快速且美觀，因此本系統的Client端設計重點不是在界面設計上，而是在提高系統的通用性上。由于計劃處報表統計條件改變頻繁，這給生成報表數據帶來一定的難度。本系統設計上采用?quot;參數表驅動法"，使數據與程序相分離，即基于通用報表結構的報表程序，極大地減輕了報表的編程工作量。Server端設計主要是建立帳務類、字典類、控制類系統數據庫表。

（4）用戶審核。將本系統的最初版本提交給計劃處使用，筆者根據計劃處在使用過程中提出的修改意見，不斷完善系統，如此重復，直至計劃處滿意為止。

（5）系統維護與評價。本系統提交給計劃處正式投入使用，為維護方便，筆者建立系統開發檔案，至此，本系統的開發過程基本結束。電子商務網站訪問量的統計南通航運職業技術學院王建華內容提要：作者就電子商務網站建設中的一個實際問題--網站訪問量統計，介紹了電子商務網站訪問量統計信息和方法。關鍵詞：點擊數；頁讀數；訪問人數；訪問量我們的主頁的頁讀數是多少？有多少人在訪問我們的網站？這往往是電子商務網站迫切需要知道的實際問題。遺憾的是，大多數電子商務網站建立初期，往往只考慮網站的內容和版面，并沒有想到某一天會要跟蹤網站的訪問量。當廣告客戶詢問網站的訪問量，想知道有多少人訪問網站，瀏覽網頁時，為跟蹤訪問量忙得疲憊不堪的工作人員往往拿不出令人信服的統計資料。本文就此問題，談談電子商務網站訪問量的統計信息和方法，目的在于拋磚引玉。

一、點擊數和頁讀數Web服務器能記錄它得到的每次請求的信息。對我們有用的請求的信息包括：點擊的日期和時間、主機名、請求、被授權的訪問者的登錄名、Web服務器的反應碼、涉及者、訪問者的useragent、訪問者的IP地址、訪問者的主機名（如果其IP地址可以被翻譯出來）、傳輸的字節數、被訪問的文件的路徑、訪問者發送的Cookies、Web服務器發送的Cookies。上述能收集到的訪問量數據不多，而且得到的信息也不可靠。可用的信息不準確，但不是完全不可用。雖然數據不精確，但仍然可以知道有多少人在用我們的網站。正如我們知道的，用計數器可以很容易地知道有多少點擊數，但對于更精確的分析，我們將不得不存儲得到的點擊數。一個簡單的辦法是把信息存儲在Web服務器的log文件中，然后定期地加載數據庫的table或直接把信息寫到數據庫的table中。點擊是我們的服務器收到的任何文件請求，包括圖像、聲音文件和任何出現在頁面上的東西。如果直接加載數據到數據庫中，我們需要一個已經實現這種功能的Web服務器（如Microsoft腎IS），或需要源代碼。也可以用第三方的API，如Apache的DBILogger。實現了這樣的功能，就可以收集失敗點擊的次數（只需計算狀態碼為4xx的點擊的數量）。頁讀數更準確些，因為它把一頁當作一個整體，而不是它的各個部分。計算點擊數不如計算頁讀數得到的信息量大，而且點擊數計算的結果與其它網站很難進行比較。頁讀數就不同了：按時間塊的頁讀數，可以查看每5分鐘的頁讀數變化；按訪問者的域名分類的頁讀數，可以確定他們是在工作時，工作前還是工作后訪問我們的網站；按登錄用戶的頁讀數和非登錄用戶分類的頁讀數，可以確定允許用戶登錄是否值得；按信息來源分類的頁讀數，可以確定訪問者進入頁面是通過一個連接還是一個旗幟廣告？他們從哪里來？這些信息可以幫我們了解訪問者的興趣，可以確定往哪兒投資，與哪些人合作；按訪問者的硬件平臺、操作系統、瀏覽器及其平臺統計的頁讀數，可以確定Mac用戶和PC用戶的比例各為多少？Netscape和IE的用戶各為多少；按訪問者主機統計的頁讀數，可以確定訪問者中有多少人用AOL？有多少人用Earthling?總之，頁讀數的統計，也就電子商務網站訪問量的統計鼻子二、頁讀數的統計為了計算頁讀數，需要制定一些把頁讀數從點擊數中區分出來的方法。下面是電子商務網站經常考慮到的一些因素：文件名、文件類型（HTML、GIF、WAV等）、Web服務器的反應碼、訪問者的主機。一旦確定了哪些點擊是頁讀數，哪些不是，就可以計算網站的頁讀數了。我們按照文件的路徑確定頁讀數算在哪個具體部分，如:/web/99/13/index0a.html算做Web的頁讀數；而/sys/99/12/index3a.html則算做Sys的頁讀數。如果這種標準在網站的各個層次上實行，可以得到網站的詳細統計。我們有時希望把一個頁讀數算在某一部分，在其它部分算在另一部分。電子商務網站頁讀數的統計方法通常有如下幾種。

1．遠程數據跟蹤頁讀數增長的速度是多少？年底的時候我們期望的頁讀數是多少？網站的哪部分頁讀數增長得最快？哪部分最慢？各種瀏覽器的比例隨著時間變化的趨勢是怎樣的？人們過多久訪問我們的網站一次？從其它網站的旗幟廣告第一次進入我的網站的人，他們隨后讀了多少頁？一旦我們看到可用的各種類型的信息，我們就會得到需要長距離回答的各種問題。如果我們對回答這些問題感興趣，那么多天的跟蹤就會有用。進行遠程數據跟蹤，可以考慮使用數據庫。我們可以編寫程序從點擊數日志中提取想要的信息。如果數據庫設計得合理，查詢信息的時間比用程序從日志文件中提取信息快好多倍。數據量越大，這種差別越明顯。如果只存儲感興趣的點擊，可以節省大量的數據空間。也可用SQL從數據庫中提取數據。SQL是一種小型的、簡練的只需學很少的命令和語法的語言。而且，其命令結構簡單明晰，好的程序員建立一個SQL查詢比編程做同樣的事快得多。而且其結果錯誤更少，更容易理解。如果不想用SQL，可以用一種數據庫訪問工具如MSAccess或Excel。這些工具都很好用，而且是圖形界面。

2．計算訪問時間電子商務網站的市場部和廣告部都喜歡統計訪問時間，即某人在離開我們的站點前停留了多長時間。但是，用HTTP是不可能確定這個數值的。假設一個客戶在正午時訪問Hot的一個頁，然后該客戶在12:28p.m.訪問Hot的另一頁，那么該客戶對Hot的訪問時間是多長呢？該客戶可能在這28分鐘內一直盯著第一個Hot頁，但是該客戶也可能在這28分鐘內新開了一個窗口，瀏覽另一個網站。但是，我們的用戶確實需要這種信息，那么該怎么告訴他們呢？我們可以去InternetAdvertisingBureau，它定義了一個訪問為"沒有連續30分鐘的不活動的訪問者的一系列頁面請求"。當有人問起我們的網站的訪問時間時，我們也可以在IAB的定義的基礎上告訴他們。

3．計算訪問來源如果訪問者點擊某個連接或某個旗幟廣告到達我們的網站，他的瀏覽器會隨著這個請求發送他剛離開的站點的URL，這個URL稱為"referer"。Netscape和IE對訪問的來源的處理方式不同。如果我們點擊原始頁到一個有frame的頁，Netscape將把原始頁作為對包含frame的頁和每個frame中的頁的來源；IE把原始頁作為包含frame的頁的來源，這個包含frame的頁反過來把它本身作為各個frame頁的來源。進一步，我們可能還會得到每頁的頁讀數的數據。如果把網站分成頻道或部分，則可能得到每部分的數據。需要注意的是，上述方法計算出的頁讀數不是我們的網站的實際頁讀數。這是因為我們統計的是在Web服務器的訪問日志中計算訪問記錄，而很多請求從不在訪問日志中留下痕跡。因為沒有十全十美的方案，所以使用哪種統計方法取決于網站的實際情況。

三、計算訪問人數計算訪問人數比計算頁讀數難得多，而且沒有絕對可靠的計算訪問者人數的方法。基本上有三種信息可以用來跟蹤訪問者：IP地址、成員名（如果網站使用成員注冊）和cookie。最簡單的辦法是計算log文件中的唯一IP地址的數量。但是，最容易的辦法通常不是最好的辦法。這種方法是可用的最不準確的辦法。大多數人在每次連接時得到不同的IP地址。這是因為很多ISP為用戶賦予動態的IP地址，例如，當一個AOL用戶上網時，AOL給他一個IP地址，當他斷開連接時，AOL把這個地址賦給另一個用戶。這樣，當我們進行統計時，我們不知道這是兩個用戶。如果要求用戶使用成員身份登錄，統計將很容易和準確。但很多人不喜歡需要登錄的網站，這就使得跟蹤成員名的統計沒有實際意義。最后，可以使用cookies。為每個訪問者定義一個包含唯一值的cookie，我們把它稱為機器ID。如果某人訪問我們的網站時沒有提供機器ID（可能她是第一次訪問，或者她的瀏覽器不接受cookies），把她當作新用戶，并為她訪問的頁發送一個cookie。使用這種方法要注意的是1．很多人關掉了cookies的功能；

2．可以用瀏覽器刪除舊的cookies；

3．cookie存儲在訪問者的機器上（訪問者可能用不只一臺機器訪問我們的網站）；

第2篇：商業系統論文范文

關鍵詞：決策支持系統商流計劃問題處理系統模型庫組件技術

決策支持系統（DSS）是一個日趨被人矚目的計算機應用領域。目前DSS的研究正向群體決策支持系統(GDSS)，智能決策支持系統(IDSS)方向發展。公認的DSS系統結構為四庫一體，即模型庫、算法庫、知識庫和數據庫。在這一結構中模型及其管理是基礎，也是系統成敗的關鍵。本文介紹一個基于知識的四庫一體的商流計劃決策支持系統SLDSS的設計思想與實現方法。

系統設計思想和系統結構

商流計劃是大型商業企業對本企業商品購進、銷售、調配和存儲各環節中各種經指標制定的目標規劃，時間跨度一般為一年。商流計劃應明確指出下一年度中各個季度，各個月份商品進、銷、調、存中各個經營指標。商流計劃的范圍和內容不同的企業可能有不同的要求，但一般應包括進、銷、調、存貨物的數量和金額，毛利和利潤額，各種費用額等。商流計劃決策是典型的半結構決策問題，既需要對影響商流計劃的諸因素進行定性分析又要對各因素的影響程度進行定量計算。為此，商流計劃決策支持系統的主要目標是：如何對影響商流計劃的各因素進行定性分析和定量計算，盡可能的幫助決策者把握市場變化的幅度，從而預測未來一年的銷售總水平；根據預測結果對商品的購進、調配和存儲以及企業各種經營指標提出多種商流計劃的可行方案。

從實際使用的角度出發，系統應盡可能地準確模擬決策過程，所建立的模型也應盡可能是實際決策過程的描述，以期對決策者的支持更有效。另外，系統的設計應向DSS生成器的方向發展，應充分體現基于知識的特征。為此，系統的設計思想為：系統能獲取、存儲商業領域的經營決策經驗（知識），并能準確地應用這些經驗；系統使用方便，適應性強，便于修改、擴充；系統能幫助用戶建立、集成、修改、查詢以及正確使用各種模型；提供“友好”的用戶界面；采用較先進的三層Client/Server系統結構，把組件技術引入到系統設計和實現中來。

為此，SLDSS的系統結構見圖1：

在該系統結構中用戶（客戶端）發送請求，通過問題處理系統（中間層）對問題進行分解后，選擇相應的決策模型（服務器端）對問題進行求解并返回結果，當然用戶也可以直接訪問各子系統。在這一結構中問題處理系統是關鍵，它協調各部件的運行。下面分別介紹系統結構中各部件的功能。

問題處理系統PPS

PPS是用戶與系統的接口，它起著銜接用戶與系統環境的橋梁作用，系統通過PPS對決策問題進行分類并確定問題求解的策略。為此，PPS是反映系統功能的主要部件之一，也是整個系統的窗口。

PPS根據商流計劃的一般要求把商品分成了12大類。SLDSS中的PPS根據商品的種類不同分別為用戶提出制定商流計劃指標決策的解決方案。SLDSS中PPS結構如圖2：

識別器的任務是對用戶提出的問題進行識別和判斷，并引導其進入相應的處理入口。

推理機是PPS的關鍵部件，它根據模式知識，通過協調器調用系統環境來對用戶提出的問題加以處理。其中模式知識是對具體決策模式的抽象化、規則化。模型知識的加工過程也是SLDSS的系統分析過程。協調器根據推理機的“智能”分析，完成系統調用，實現具體問題的構模任務。

系統狀態參數是對決策過程的跟蹤，從決策過程的非連續性出發，對系統的這種跟蹤是必要的。

基于四庫的系統環境

模型庫管理子系統

模型及其管理是DSS的重要工作，本課題把組件技術引入到DSS模型的設計與實現中來，把DSS基模型定義為一個結構級組件，把DSS復合模型定義為由基模型經復合運算復合而成。定義如下：

定義1：我們把稱為一個DSS模型模式。這里的S表示模型的屬性集合，它包括模型的標示ID、模型的類型Type，以及反映模型功能和行為的變量；P可以包括對上述信息的操作和該模型向外界所提供的服務，P對S封閉；E表示模型所產生各類消息的事件集合；I為模型的多重接口，多重接口為模型的連接和了解一個模型的功能提供了一個窗口；O為模型中操作次序，它是反映模型中操作或子模型標示的一個構造數據類型，對基模型一般為空，對復合模型它反映了求解問題的步驟。

定義2：對任何DSS模型M(D（D為論域），DSS模型M為DSS模型模式的一個實例，DSS模型記為：M＝；M＝<{},{},{},{},{}>稱為空模型，記為Mφ。

這里定義的DSS模型是一種結構級的組件。根據上述定義，我們可以定義模型的連接運算。

定義3：設M和N為兩個DSS模型，如果修改模型M將影響模型N的運行或功能，則稱模型N依賴模型M，記作：MN。如果模型N不依賴模型M，則記作：MN。如果模型N依賴模型M，而模型M又依賴模型N，則稱模型M與模型N相互依賴，記為MN。

定理1：設A、B、C為三個DSS模型，如果AB，BC，則有AC。

定義4：設M1、M2、...、Mn和N為DSS模型，如果有M1N、M2N、...、MnN，則稱N為由M1、M2、...、Mn組成的DSS復合模型。

DSS的基模型和復合模型是相對的，一個復合模型在構造更復雜的DSS決策過程模型時，又成為基模型。所以，在不造成混亂的情況下，可對兩個概念不加區分。根據上述定義，我們可以使用組件開發工具實現DSS基模型，對DSS復合模型的設計與實現本課題采用下面策略。

構成DSS復合模型中所用的基模型M1、M2、...、Mn之間的關系有兩種情形。其一是它們由純粹基模型構造，并且它們之間不存在著依賴關系，即不存在基模型Mi、Mj使MiMj；其二是由基模型之間存在依賴關系，即存在基模型Mi、Mj使MiMj成立。對第一種情形我們可以通過組件容器把基模型組合成復合模型或通過編寫程序的方法把基模型復合成復合模型，這里不再討論。下面著重討論第二種情形。兩個基模型存在依賴關系意味著兩個模型之間有消息的傳遞和方法的調用。我們可以采用在兩個模型之間建立連接器的方法解決消息的傳遞和方法的調用，連接器與基模型的關系如圖3。

這種DSS模型的調用關系與組件對象模型的調用關系有所不同。在組件對象模型的調用中，模型Mi通常作為事件源，Mj做為事件的接受者，并在接到事件后執行相應的操作。而在DSS復合模型中Mj做為事件源，Mi作為事件的接受者，Mi在接到事件后執行相應的操作或模型Mj回調Mi中的方法。

SLDSS的模型庫管理子系統提供的功能包括自動建立模型、模型維護和模型的運算。

知識庫管理子系統

SLDSS的知識庫中存放了兩類知識，事實類和規則類。對事實類的知識，如“今年銀行利率增加”，表示為“ZJ（利率）”；再如，對于批處理的模型知識表示為GOTO（START，DLMXL）；GOTO（DLMXL，JGSC），對規則型的知識以下列形式存放于規則庫中，RULE（規則號，[條件1，條件2,條件N]，結論）。例如，“如果工農業生產情況正常且銀行利率不便且物價變化幅度不大，則用一元回歸分析銷售量，可表示為：RULE（22，[ZJ（“工農業”），BB（“利率”），BB（“物價”）]，ZX（“一元回歸”））。

SLDSS中的知識庫由若干子庫構成，不同的知識按其類別存放在不同的子庫中，這樣有利于知識的管理，同時也大大的提高了推理機的搜索速度。知識的推理采用正向推理和反向推理兩種推理策略，對于專業領域知識的推理都采用正向推理，對系統知識的推理采用了反向推理策略，既方便又迅速。而對專業領域知識采用正向推理策略與實際情況較接近。

算法庫、數據庫的組織與管理

算法庫的組織及管理SLDSS中算法庫存放了一些與模型有關的算法，算法是模型的實現。這些算法以它們的計算機程序和有關算法使用的“智能”信息存放在算法庫中，通過算法字典統一管理，算法庫字典的結構為：

算法庫字典是算法管理的主要依據，算法庫的維護也就是其字典的維護，另外，算法庫字典又是使用算法的事實性知識，系統推理機通過算法庫字典的讀取來完成算法的選擇工作，算法庫管理提供的功能有：算法建立；算法查詢；算法修改；算法刪除。

數據庫的組織與管理SLDSS的數據有兩種類型。其一是企業內部運行數據，這類數據可以采用關系模型加以描述并存儲，這里不做討論。其二是模型描述數據，這類數據描述了模型的屬性、調用的條件、返回結果的要求和模型的功能（操作），它實際上是組件的接口。SLDSS中的模型采用三級結構表示法，這種表示法與人工智能中知識的框架——槽值表示法相對應。如線性規劃模型，它的三級表示如下：

第3篇：商業系統論文范文

關鍵詞:工程總承包;商業生態系統;建筑業

0引言

實行工程項目總承包已經成為世界建筑業的一種必然趨勢,世界上著名的225家大型公司中,大都具有總承包的能力。經過20多年發展,我國也形成了中國建筑工程總公司等有實力的工程總承包企業,但是,在我國工程項目總承包企業的發展中還存在許多的問題職稱論文。

1工程總承包概述

工程總承包是指從事工程總承包的企業受業主的委托,按照合同的約定對工程項目的勘察、設計、采購、施工、試運行(竣工驗收)等實行全過程或若干階段的承包。工程總承包企業按照合同約定對工程項目的質量、工期、造價等向業主負責,可依法將所承包的工程項目中的部分工程發包給具有相應資質的分包企業,分包企業按合同約定的內容向總承包企業負責。工程總承包的具體形式、工作內容和責任由業主與工程總承包企業在合同中約定[1]。

2我國建筑企業工程總承包方面的發展現狀及問題

2.1設計單位改革緩慢且不徹底1999年國務院批轉了建設部等部委聯合制定的《關于工程勘察設計單位體制改革的若干意見》([1999]101號),指出“設計單位要參照國際通行的工程公司、咨詢公司、設計事務所、巖土工程公司等模式進行改造”。可見政府是引導設計單位發展以設計為主體的項目總承包管理模式。但是很多設計單位并沒有真正按國際型工程公司模式進行改革,其服務功能和組織體系還沒達到要求,只是設立了二級機構工程總承包部,并沒有真正的項目控制部、采購部、施工管理部、試運行部等部門。而且很多設計單位的人才結構和技術管理體系還比較單一,還是以設計為主。

2.2總承包企業國內市場疲軟且低效雖然我國正在推行城市化建設和基礎建設,工程項目很多,但是,由于國內工程總承包企業還不是很成熟,與之配套的相關軟硬件條件也不成熟,很多業主并沒有采用總承包形式進行招標。據統計2000年我國總承包分額僅占1%,這與發達國家的30%相比差距很大[2]。由于國內市場的缺乏,使得我國的總承包企業失去了發展壯大的基礎,發展緩慢。此外,我國總承包企業效率比較低。2002年全球225家最大承包商統計中,我國企業有43家,占總數的19%。總承包額71.3億美元,占225家承包商營業總額的6.10%,平均承包額為1.66億美元[3]。

2.3缺乏國際競爭力我國具有國際競爭力的總承包企業很少,目前只有化工、石化等行業有少數國際型工程公司。而且我國企業業務范圍比較狹窄,以勞務承包為主,國際承包市場的占有分額比較小。

2.4施工總承包占主導地位在我國,工程總承和項目管理企業起步的比較晚,各種法律、規范、控制手段和運作機制等還不成熟。再加上我國勘察、設計、施工企業分別屬于不同的部門,有各自的利益主體,要通過改造和重組建立工程項目總承包企業還有許多問題要解決,所以施工總承包是目前國內普遍實施的工程項目承發包模式。

3構建建筑業的商業生態系統

整個地球可以是一個生態系統,一個湖泊也可以是生態系統,如同自然生態系統一樣,我國的整個國民經濟是一個商業生態系統,建筑業也是一個商業生態系統。系統不在乎大小,只要它具有商業生態系統的特征,遵循商業生態系統的規律,那么它就是商業生態系統。建筑產品不同與一般的商品,具有資金投入大,耗費資源多,建設周期長,風險大等特點,它涉及50多個工業部門。所以建筑業的商業生態系統物種豐富,關系復雜,主要由三個部分組成(如圖1)。內涵最小,但最重要的是核心系統,主要由設計、勘察、咨詢、施工、業主等企業組成。這些企業是建筑產品生產的直接參與者。其次是支撐系統,主要由分包企業、供應商、政府審批部門、金融機構等組成,這些企業和組織是建筑活動順利進行必不可少的保障。再次是系統,主要由供應商的供應商、教育培訓機構、行業協會標準組織、各種材料的研發機構等組成,這些企業和組織雖然離建筑產品的生產活動比較遠,但是卻與外部環境的聯系最密切,能不斷給系統內部帶來新的活力。

4商業生態系統對發展工程總承包的意義

4.1改善業主關系,發展國內市場建立商業生態系統后,各個參與方都是以顧客利益為基礎,以整體利益為目標,實行利益共享。這一點對于工程總承包模式在我國的發展很重要。我國總承包市場分額低的一個很重要原因是業主不能分享總承包模式帶來的利益,更多地選擇傳統模式,采用直接分包的形式來分享專業化施工的好處。在商業生態系統中,業主可以通過利益共享切實分享總承包模式帶來的成本的節約,獲得利益。只有這樣,業主才會愿意采用工程總承包模式招標,才能發展工程總承包企業的國內市場,才能借助國內市場的給養使我國的工程總承包企業快速發展,增強競爭力,更多的爭取國際市場分額。

4.2依托生態系統,組建總承包企業施工總承包企業在我國已經有了相當的發展,一些大型企業已經具備了領導商業生態系統的條件和能力。商業生態系統是基礎,共同進化、利益共享的特點保證了生態系統具有穩定性,有能力支持組建的工程總承包企業。建筑業的核心系統具備了勘察、設計、采購、施工、試運行等全部的功能單位,有條件組建工程總承包企業。商業生態系統組建的工程總承包企業是系統整體利益的代表,本身不是利益主體,它的存在與發展都植根于商業生態系統之上,是產生于穩定的協作。它的任務就是承接業主工程總承包的委托,并作為項目平臺協調各企業順利完成項目。其組織形式如圖1。

4.3提高效率,增強國際競爭力商業生態系統是建立在分工協作基礎上的。通過分工提高各類建筑企業的專業化水平,做到大而專,小而精,提高企業效率;通過協作發揮企業間的協同效應,節約成本,提高企業效率。效率是企業參與國際競爭的基礎。同時,企業要充分利用商業生態系統的資源,不斷提升企業員工的文化層次,把企業從人力資源優勢轉化為人才資源優勢,從勞動密集型企業轉變為知識密集型企業,全面提高我國總承包企業的國際競爭力。

5結論

工程總承包模式是國際建筑市場的一種趨勢,是我國建筑業實行“走出去”戰略,參與國際競爭,爭取市場分額的必要條件。通過分析我們看到在我國要快速實現工程總承包模式并不容易,只有通過不斷創新尋找新的途徑。通過商業生態系統來發展工程總承包模式可以充分利用商業生態系統的特點,能充分結合我國建筑業目前的發展現狀。通過商業生態系統來發展工程總承包模式能解決我國目前在發展過程中的問題。借助商業生態系統,組建新型的總承包企業,是在我國總承包模式的新途徑。

參考文獻:

[1]建市[2003]30號.建設部關于培育發展工程總承包和工程項目管理企業的指導意見.總第109期:3～4.