• 沒有找到結果。

營建業供應鏈資訊系統訊息中心規劃與建構(II)

N/A
N/A
Protected

Academic year: 2021

Share "營建業供應鏈資訊系統訊息中心規劃與建構(II)"

Copied!
10
0
0

加載中.... (立即查看全文)

全文

(1)

行政院國家科學委員會專題研究計畫 成果報告

營建業供應鏈資訊系統訊息中心規劃與建構(II)

計畫類別: 個別型計畫 計畫編號: NSC93-2211-E-009-040- 執行期間: 93 年 08 月 01 日至 94 年 07 月 31 日 執行單位: 國立交通大學土木工程學系(所) 計畫主持人: 林昌佑 報告類型: 精簡報告 處理方式: 本計畫可公開查詢

中 華 民 國 94 年 12 月 8 日

(2)

行政院國家科學委員會專題研究計畫成果報告

營建業供應鏈資訊系統訊息中心規劃與建構

計畫編號:NSC 93-2211-E-009-040

執行期限:93 年 8 月 1 日至 94 年 7 月 31 日

主持人:林昌佑 國立交通大學土木工程學系

一、中文摘要 近年來由於電腦及網路科技漸趨 成熟,網際網路成為取得資訊之重要途 徑。透過網際網路傳遞資訊為電子化之 基本工作。進一步,企業大幅運用網際 網路交換訊息並創新顧客及伙伴間的 服務、交易與合作模式,進而促使目前 電子商務的蓬勃發展。目前一般建構企 業間資訊交換系統以網頁方式進行,使 用者透過瀏覽器設定各項交易程序,功 能較為侷限,針對各項資訊技術可能因 平台或版權問題,而無法有效結合在一 起。為有效建構整合式企業間資訊交換 形態,並結合公司內部電子化系統,本 研究針對營建業經營環境,建構以訊息 為主體之電子化企業間資訊交換環 境。將利用 java 語言,同時利用 XML 特殊的資料結構,營造出適合資料交流 的環境,進行營建業上下游介面的安 排,整合資訊互通的目標。 關鍵詞: 供應鏈、電子化、電子商務 Abstract

When entering WTO, it is necessary for construction firms to pursuit better productivity in order to compete with international company. In the computer era, more information within companies are transform via the

industry due to different culture and operation standard, it is difficult to achieve that. A better communication environment between collaborate partners (supply chain) can lead to more effective productivity. This can be achieved by introducing standardized electronic environment. In this research, a message agent is establish to work as a middleware to transform information within supply chain. Java language is utilized, and XML schema is also applied to standardize some necessary information using the message agent.

Keywords: supply chain, e-business,

electronic-automation, message agent 二、緣由與目的 近幾年來,科技日新月異,電腦的 技術突飛猛進,在這個資訊發達的時 代,資料的處理、資訊的傳播等等,都 需要依靠電腦,加上網際網路的普遍及 盛行,資訊的傳遞已經可以達到無遠弗 屆了。自從加入 WTO,政府積極推企業 電子化,以應付將面臨的國際競爭壓 力,身處這時代的各企業領導人,無不 提升自身的電腦能力,希望利用科技產 生的新技術,應用於工作上,以電子

(3)

在營建工程中,也不能置身事外, 在政府積極推動企業 e 化的同時,內政 部也頒布了「營建業電子化白皮書」, 顯示推動營建電子化的決心。營建工程 的資訊內容繁雜,各個專業項目分工介 面繁多且複雜,一件工程案件可能包涵 許多不同性質的包商及廠商,所以資訊 的交換及溝通,就顯得格外的重要,如 果各單位各行其事,將可能造成資料的 重複建置、資料格式不一,資訊傳遞不 方便,以致資源及成本浪費、降低效 率,造成工程品質的大打折扣,諸多的 缺點,將使工程的進行更加艱難,無法 從工程中獲得經濟利益。 在這前提之下,就需要運用現有的 資料處理技術,有效透過電子化和標準 化,來整合相關的工程資訊,使得不同 的公司廠商間,也能有專有的資料格式 及便利的傳送方式,達到資訊的充分流 通,進而在取得資訊後,可以把相關需 要的資訊作處理,轉換或重複再利用。 如此一來,將有助於營建業降低企業經 營成本,進而提生競爭力,獲得經濟利 益,提高企業的獲利。 因 為 網 路 的 盛 行 和 電 子 商 務 (E-Commerce)蓬勃發展,各個產業無不 跟進其熱潮,無疑成為現今最紅的經濟 模式。早期企業與企業間資訊的互通, 從信件的傳遞,發展到傳真,進而演變 到電子資料交換(EDI,Electronic Data Interchange),一般現今較廣泛的資料 傳遞方式,即是利用瀏覽器當作資料傳 遞的介面。 本文將在現有的程式語言與資料 格式裡,選擇出最佳的組合,建構一套 訊息傳遞系統,其功能可以傳遞營建產 業裡招投標相關資訊,使得採購機關與 供應商之間能藉由此系統來達成訊息 傳遞、資料交換與共享。 Java 程式語言有開放性且跨平台 的能力,而 XML 資料格式具有開放性、 可標準化,以及可延伸性和可擴充性, 再 藉 由 Java 提 供 的 訊 息 服 務 功 能 (JMS,Java Message Service),建構 出一套跨平台的「訊息傳遞系統」,傳 送的訊息主要以營建招投標過程裡的 各項相關的資訊或資料,而傳送的資料 格式則採用 XML 形式。 在營建招投標過程裡,從招標、領 標、投標到決標,各項過程中都需要傳 送相關的訊息,如招標公告、領標通知 單、採購單、報價單以及決標通知單等 等。 本文最重要的目的就是利用訊息 傳遞的方式,來達成採購機關與各供應 商之間的資訊交流,而資料傳遞的格式 則採用 XML 形式,以期藉由 XML 的優 點,在日後能促使資料流通便利、格式 標準統一化,相同的資訊可以重複再使 用,如此可以降低資訊傳遞所需要的相 關軟硬體成本、提升效率、減少企業營 運成本、增加競爭力、提升工程品質、 獲得最佳的經濟效益等等。在資訊共享 與交換更加快速便利後,能提升營建業 電子商務的效率,進而達成土木營建業 的電子化。 三、研究方法

(4)

訊息傳遞機制之探討 訊息傳遞指使用訊息收送系統在 網路上交換訊息,電子郵件是目前最廣 為使用的訊息收送系統,透過電子郵件 的傳遞,人與人之間的溝通更為便利。 各企業間常常需要做資料的轉移以及 交換,這樣的工作,也可視為是一種訊 息的傳遞,而傳遞的訊息即為欲交流的 資訊或資料。所以了解訊息傳遞的機制 與傳送的方式,實在刻不容緩。 訊息傳遞的架構可分為兩種 [5]: 1.分散式架構: 如同點對點的傳遞,點與點之間都 存在一條專屬的道路專供聯繫。這種系 統在節點較少時也許能發揮不錯的效 果,但是若節點較多時勢必產生負荷過 於沉重的狀況。節點為了傳遞訊息所要 具備的能力,也將必須隨著網絡的複雜 而增加,畢竟每一次的運作都必須在節 點端進行,因此必須考量系統中成員的 組成是否適當。 2.中央集權式架構: 所有的節點都透過一個核心媒介 的運作,並且將屬於各節點的相關資 訊,在系統中作雙向傳輸,達到資訊交 流的目的。此核心媒介的存在,就如同 一個代理人的角色。一個專司訊息控制 的代理人,可以接受來自四面八方的訊 息,並且將訊息無誤傳送到指定的目的 地。因此就算是節點再多,也能夠一目 了然系統其中的運作。同時,節點端的 軟弱並不會影響到整體系統的表現,畢 竟真正處理訊息傳遞的工作是落在媒 介身上,圖一與圖二即為分散式架構與 中央集權式架構示意圖。 由訊息傳遞的架構來看,可以了解 到效率的差別,分散式架構的效率勢必 較低,因為事必躬親。若是網絡上的各 個成員效能落差很大,必定將拖累所有 成員,所以必須對成員在軟體或硬體規 格上要求,而必須付出升級的成本代 價。如果採用中央集權架構的方式,則 只要針對媒介的部分加強效能,對於訊 息 傳 遞 的 效 率 並 不 會 因 為 成 員 的 差 異,而互相影響到整體系統的營運。 比較過優缺點後,本文將採用 中央集權式的架構,進行程式的開發。 而中央集權式架構中,扮演媒介的角色 稱 為 訊 息 導 向 中 介 軟 體 (MOM , Message-Oriented Middleware),或稱 為企業訊息系統。在企業訊息系統中, 訊息的用途在於用來通知另外一個系 統發生了特定的事件。 訊息導向中介軟體(MOM)是指可讓 兩個或以上的程式,透過訊息來交換資 訊,或稱訊息伺服器。當使用 MOM 的時 候,MOM 會確定訊息能夠適當的傳送。 此外,MOM 通常會有容錯、負載平衡、 規模可變,以及交易的支援,如此一 來,企業才可能依賴其訊息交換的機 制。 MOM 傳送的重要概念為「將訊息從 某系統用非同步化的方式,透過網路傳 送到另一個系統」,所謂的非同步化訊 息傳送,意味著傳送端把訊息丟出去 後,就可以回來繼續做其他的事情,不 需等待訊息被接受或處理完畢。

(5)

MOM 必須具備以下幾個特點[6]: 1.訊息系統是一種 Middleware,相 較於傳統的 Client-Server 的架構, Middleware 用來隔離用戶和伺服器,可 讓用戶端程式不必擔心通訊和資料傳 送等事宜,它會負責效率和可靠性,如 此可以減少用戶端程式的複雜度。 2.相異系統之間的整合,意謂不同 平台、程式語言、通訊協定可以整合在 一起,MOM 可提供簡單且具彈性的解決 方案。 3.資訊交換往往需要保證訊息能 無誤傳送與接收,即使系統失敗,也必 須保證資料能被重新傳遞。 4.當訊息傳送到 MOM 後即可不理, 自動商業處理的程序可以減少直接和 使用者的互動,這可避免因等待彼此的 回應而影響效率,使 MOM 能處理更多的 用戶需求。 5.保證系統的可靠性,當一個系統 失敗時,可將訊息自動導向到另一個系 統而繼續訊息的傳遞。 而本研究採用 SonicMQ 作為 MOM。 SonicMQ 是最早開發 MOM 的廠商之一, 它具備的功能完整,並且主要支援可傳 遞 XML 格式的訊息,故選擇 SonicMQ 做 為本研究的訊息伺服器。 訊息服務(JMS) 雖然 MOM 在商業系統的整合有 其實用性,但系統間並沒有一個通用的 程式介面,來自不同公司的訊息系統會 有不同的介面,所產生的訊息程式只能 在某個廠商的系統上執行,這造成往後 轉移的問題。於是 Sun 公司和主要 MOM 廠商於 1998 年提出 JMS 的標準,又稱 Java 訊 息 服 務 (JMS , Java Message Service)。 JMS 本身不是一套訊息系統,而是 一組抽象的介面與類別,用來提供 Java 程 式 發 展 者 開 發 通 用 的 訊 息 傳 遞 程 式,可和 MOM 連接以傳送或接收訊息, 並減少程式發展者需要了解不同 MOM 特 性所花費的時間,且增加程式的可攜 性。圖八所示,意指具有訊息傳遞功能 的 Java 應用程式就是經由 Java 訊息服 務介面(JMS API)和各 MOM 廠商產生連 結來執行訊息的傳送與接收。 四、程果與範例解說 圖三所示為所建立系統架構,首先 採購機關必須先架設網站,主要用於讓 有合作或有興趣參與投標的供應商利 用瀏覽器連上網站註冊並登錄廠商相 關資料,可讓採購機關知道有哪些供應 商在使用本系統,供應商登錄完畢後便 可下載本研究開發的訊息傳遞程式來 使用。 舉一實際範例來實作,並解說其傳 遞訊息的過程。以「交通大學寶山路新 南大門建設工程」為例,採購機關為「國 立交通大學」,向供應廠商進行案件的 招標投標的工作,最後選出得標廠商, 假設供應廠商為 A 營造廠和 B 建設公 司,此實例將以採購機關端和供應廠商 端個別說明之。 採購機關和各供應廠商可遵循營 建招投標的流程,來進行招投標的工

(6)

作,如圖四即為各招標流程裡的工作示 意圖,分為採購機關端和供應廠商端。 以本文所舉案例來說,採購機關端 為「國立交通大學」,供應廠商為 A 營 造廠和 B 建設公司,採購機關端可照順 序利用訊息傳遞程式發送招標公告、採 購單與決標通知單給供應廠商,並接收 來自各供應商的領標通知單、報價單。 而供應廠商端的工作正好和採購機關 端相對應,主要是接收來自採購機關的 招標公告、採購單與決標通知單,並發 送領標通知單、報價單給採購機關。 公告流程 ●採購機關端:國立交通大學。 採購機關編輯招標公告,並存入資 料庫,如圖五所示。使用傳送招標公告 功能,傳送 XML 訊息給相關的供應廠 商,在此使用群體傳送功能,選擇廠商 的類別為「建築工程」,並傳送招標公 告 ●供應廠商端:A 營造廠、B 建設 公司。 2.使用接收招標公告功能,接收來 自採購機關的招標公告,完成招標公告 流程,如圖六所示。招標公告存成 XML 檔,可如圖七所示。 領標流程 供應廠商對有興趣參與投標 的案件,向採購機關傳送領標通知單, 並且取得採購單。 ●供應廠商端:A 營造廠、B 建設 公司。 1.使用傳送領標通知單的功能,選 擇有興趣的案件發送領標通知,如圖八 所示。 ●採購機關端:國立交通大學。 1.使用接收領標通知單功能,接收 來自各廠商的領標通知單,如圖九所 示。 2.使用編輯採購單的功能,將欲採 購的工程材料存入資料庫建檔,如圖十 所示。 3.再利用傳送採購單的功能,將採 購 單 傳 給 有 提 出 領 標 通 知 單 的 供 應 商,並等候報價,即完成領標的流程, 如圖十一所示。 投標流程 投標即為供應廠商在接收到採購 單後,編輯報價單並傳送給採購機關, 等後決標通知。 ●供應廠商端:A 營造廠、B 建設 公司。 1.使用接收採購單功能來接收採 購單之 XML 訊息,如圖十二所示。 2.接收完採購單後,即利用編輯報 價單的功能,輸入單價和總價,並存入 資料庫,如圖十三所示。 3.編輯完畢後,再使用傳送報價單 的功能,將報價單傳送給採購機關,即 完成投標的流程,如圖十四所示。 決標流程 採購機關在接收完各供應商 的報價單後,經過比價的過程,再決定 由哪家供應商得標,傳送決標通知單給 得標廠商,即完成決標的流程了。 使用接收報價單的功能,接收各供 應商的報價單,並存檔以便進行比價, 如圖十五所示。決定由哪家供應商得標

(7)

後,再使用編輯決標通知單的功能,編 輯欲傳送的決標通知單。利用傳送決標 通知單功能,傳送 XML 訊息給得標廠商。 五、結論 隨著網際網路的發展,資訊的交流 已經無隔界、無距離了,交易的時間也 變得非常迅速。在這個前提之下,營建 業招標投標的過程也不該只限於舊有 的交易機制,本研究致力於將科技與網 路的強大功用,應用於營建業招投標流 程裡,加速招投標各項資料的傳遞,達 到無紙化的境界,充分展現營建電子化 的成果。 考慮到各供應廠商電腦設備的不 盡相同,或是電腦平台的限制,於是使 用了現今最強大的跨平台工具,即 Java 與 XML 的結合,由 Java 開發出來的程 式,不但可跨平台,更適合用來開發網 路專用的程式;而 XML 資料格式相容性 高,不限平台又可延伸擴充,是目前業 界最重視的資料交換格式。所以本研究 開發的程式,相當適用於應付各個不同 種類的供應廠商,不必擔心程式不易流 通的困難,更能加速電子化的腳步。選 用的 JBuilder 開發工具,利用其特有 的功能,更方便日後程式的修改與加 強,在美化程式方面,也提供非常有利 的開發環境。 最後利用一實際範例來實作,驗證 本研究的可行性,在廣泛的 Windows 平 台上得到良好的效果,以 Java 跨平台 的功力,其他平台如:Linux、麥金塔、 Solaris 等等也會有同樣優良的成效, 期望本研究能開啟營建業招投標交易 機制的新里程。 五、參考文獻 [1] Sun,「Java Technology」, http://java.sun.com/。 [2] World Wide Web Consortium,

「XML」,http://www.w3.org/。 [3] 周政宏,「Java 與 XML 整合應用」, 文魁資訊,2003。 [4] 明寰資訊,「XML 學習手冊」,碁 峯資訊,2002。 [5] 周政宏,「Java 訊息傳遞」,文魁 資訊,2002。

[6] Richard Monson-Haefel & David A.Chappell,「Java Message Service」,O'Reilly,2001。 [7] Borland 台灣分公司,「Borland JBuilder X 實用技術手冊」,碁 峯資訊,2004。 [8] 超維度工作室,「JBuilder 程式設 計大全」,學貫行銷,2003。 [9] Sonic Software,「SonicMQ」, http://www.sonicsoftware.com/ index.ssp/。 圖一 分散式架構 甲地 戊地 丁地 乙地 丙地

(8)

圖二 中央集權式架構 圖三 營建招投標訊息傳遞系統 圖四 營建招投標流程之工作示意圖 圖五 採購機關端編輯招標公告 前置作業: 決標流程: 領標流程: 投標流程: 1.安裝 Access 資料 庫驅動程式。 2.安裝 Java 執行環 (JDK 或 JRE)。 公告流程: 1.連結採購機關網 站,登錄廠商資料 並下載訊息傳遞程 式。 2.安裝 Access 資料 庫驅動程式和 Java 執行環境 (JDK 或 JRE)。 1.連結資料庫和訊息 伺服器。 2.編輯招標公告。 1.連結資料庫和訊息 伺服器。 2.接收到領標通知單 後,編輯採購單。 1.接收到招標公告 後,編輯領標通知 單。 2.接收到採購單後, 進行比價以決定由 哪一家供應商得 標。 1.接收到採購單後, 編輯報價單。 3.傳送招標公告。 2.接收招標公告。 2.傳送領標通知單。 1.接收領標通知單。 3.傳送採購單。 3.接收採購單。 2.傳送報價單。 1.接收報價單。 1.比價並決定得標廠 商後,編輯決標通 知單。 2.傳送決標通知單。 2.收到決標通知單的 廠商,即為得標廠 商。 1.接收決標通知單。 採購機關 之網站 Access 資料庫 採購機關端之 訊息傳遞程式 供應廠商端之 訊息傳遞程式 MOM 伺服器 (SonicMQ) XML XML 下載 訊息傳遞程式 註冊 Access 資料庫 採購機關架設之訊 息伺服器。 供應廠商端: 採購機關端:

(9)

圖六 供應廠商端接收招標公告

圖七 招標公告之 XML 檔

圖八 供應廠商端傳送領標通知單

圖九 採購機關端接收領標通知單

(10)

圖十二 供應廠商端接收採購單

圖十三 供應廠商端傳送報價單

圖十四 採購機關端接收報價單

參考文獻

相關文件

(A)因為用 Terminal Services 可以不用安裝 ERP 的程式在 Client 端上可以減少 MIS 維護系 統的時間(B)沒有防毒軟體 (C)建置防火牆的系統 (D) APP-Server 與 DB

最後特別提出說明,本研究用戶端作業系統為 Win 2000 Professional,伺服 器端作業系統為 Windows 2000 Server 並啟動 Active Directory

真實案例 4 阿維奧爾公司 善用 真實案例 4:阿維奧爾公司:善用 資訊科技,從失敗中再創生機. ¾你覺得為什麼阿維奧爾在導入 ERP

圖4 1 整合資訊系統風險 圖4.1 整合資訊系統風險..

例如 : http ( 網頁伺服器所用的協定 ) 定義了 client 如何向 server request 網頁及 server 如何 將網頁及其中的各種內容回傳給 client 。. 提供服務給 application layer

密碼系統中,通常將想要保護的密碼訊息稱為 plain text。而將經過加密後產生的加密訊息稱為 cipher text。在這 中間的過程,會用到可以對外供應的 Public Key 以及私人保

資訊和通訊科技 物料和結構 營運和製造 策略和管理 系統和控制

由於資料探勘 Apriori 演算法具有探勘資訊關聯性之特性,因此文具申請資 訊分析系統將所有文具申請之歷史資訊載入系統,利用