市場意見蒐集－廠商的角度

關鍵的事情往往在量化數據出現之前即顯示於現實之中。在本章前三節各項 資料的蒐集分析後，研究仍欲了解本土廠商、代理商及原廠（含分公司）在面對 臺灣圖書館自動化系統市場所觀察或經歷的市場生態，與系統廠商進行半結構式 的深度訪談（見附錄三、系統廠商訪談大綱），以獲取統計數據中缺乏的市場現場 意見，訪談期望了解的兩個主要研究問題的關鍵面向：

(1) 從廠商的角度，其所認知的臺灣圖書館自動化系統市場呈現的特徵。

(2) 從廠商的角度，其看待圖書館系統需求文件（RFP）所隱藏的核心議題。

談起臺灣的圖書館自動化系統市場及圖書館採購系統的慣習，四位受訪者從 其立場析論對市場的經驗及想法，整理分述如下。

一、RFP 文件本身的意義探討

（一） 需求書的面向：庶務性與進階發展型的規格同時存在

受訪者 B 提到 RFP 所羅列的規格大致區分為兩個層面：一為庶務型的規格，

114

亦即圖書館作業的基本面；二為進階的發展型規格，尤以目前發展中的規範或國 際標準、通訊協定、介接介面為主。茲分述如下：

1. 庶務型規格

從基本面來看圖書館提列的庶務型需求是可以理解的，例如編目需進行抄 編，因此有連到全國圖書資訊網的必要性。像這類型的需求為館員日常作業，

由於館員熟悉其工作內容及程序，若失去該類作業功能及流程則會對其工作 產生衝擊，故館員對於此類庶務型的規格描寫得非常細緻且條目多項，系統 公司也易於從館員的業務需求出發，理解館員何以有此需求規格。

2. 進階發展型規格

但當需求落在描述第二種較為進階發展型的規格時，僅一句話帶過，相較於 庶務型規格細緻且繁瑣的規格，此類型的規格就容易產生問題。圖書館將其 系統及業務需求訴諸於文字描述，系統廠商對於圖書館的需求陳述，可從規 格應用情境、目的效益，及圖書館員對其提出需求的自我了解程度等三方面，

舉例說明廠商人員如何看待目前 RFP 進階發展型規格的需求描述。

(1) 缺乏應用情境的需求規格

當規格陳述「系統需支援 MODS」（Metadata Object Description Schema，簡稱 MODS），圖書館於 RFP 中並未表明系統支援 MODS 的企圖心為何，藉由支 援 MODS 規格的系統來進行哪些方面的業務或想要達成何種效益；而系統公 司對此種模糊的需求規格，因有承接案子的欲求，則必須為圖書館的此種規 格創造應用情境（scenario）以呈現 MODS 的價值，這類型規格在圖書館模糊 簡略的需求陳述裡與系統公司創造應用情境的互動模式，卻往往能在標案場 合說服評審委員。然而，這樣似是而非的互動模式是有問題的。

(2) 目的與效益不明確的需求規格

圖書館自動化系統需支援 ISO2709 格式以做異質系統之間的書目資料交換，

115

因此規格支援 ISO2709 可以很明白圖書館的業務取向及其需求目的。但有些 RFP 又會加述「需支援 OMI-PMH、MARCXML」等規範，則難以辨別需求目 的及效益。又例如規格寫「系統需支援 Z39.50」，是需要 ZServer 或 ZClient 也未言明。或許兩者都要，那引出更深入的問題是圖書館需求支援 ZServer 與 ZClient 的系統要做甚麼事情？當圖書館需求規格說「系統需支援 Z39.50」的 時候，卻沒有明確地講支援 Z39.50 的使用情境，便看不出圖書館因應業務而 生的需求。能講述規範與國際標準的名詞定義相對是容易的，但當這些名詞 運用於系統功能時，則必須探究得很細緻、深研系統如何運用、而圖書館運 行該標準的用處與效益，例如所有系統的 Z39.50 都需要遵行書目層次一（bib 1）的規範，定義 title、creator 等欄位的代碼、做為此標準的主列表，ZServer 與 ZClient 彼此之間才得以互通，各異質資料庫送出來的資料才能讓其他系統 辨識 1001、1007 為何，這才是談 Z39.50 這標準時所應掌握的核心，才有可能 接著談應用與效益。

(3) 系統廠商認為圖書館對該需求規格「一知半解」

有些規格在線上公用查詢目錄（Webpac）的部分會提到「需支援 openurl」，

臺灣圖資教育下對於 openurl 的理解是傳送書目資料的語法出去，以與其他資 源做連結。圖書館在提列此類應用某種規範而訂立的規格時，似乎忽略了該 項規範的精神。以 openurl 為例，其真正用意是將書目資料打包成一串標準的 openurl 語法，並將語法傳到其 openurl resolver，透過 resolver 具備的知識庫

（knowledge base）所儲存的各項連結資訊，以呈現連結的資源。因此，即使 系統回覆其有支援 openurl 的語法功能，但若未具備豐富的知識庫，空有支援 語法也無益於圖書館的使用。回歸到 Webpac 這模組功能，其所呈現的資訊是 ILS 的書目資料庫，以 Webpac 支援 openurl 將此應用於館藏書目的情境而言，

是將 ILS 書目資料庫做為 openurl resolver 的知識庫，此時應思考其向外連結

116

的必要性在哪，作為 openurl resolver 知識庫的書目資訊有何意義，當這些都 前後思考確當，才能清楚這項規格存在於系統功能的必要性、以及對圖書館 業務需求的輔助性有多少，也才能明確地決策是否列於 RFP 上。

因此，受訪者 B 認為從整個 ILS 採購案看來，有館員提列的具文規格、有系 統公司提供的解決方案、而在評選過程中也說服了評審，這一路雖是暢通，但極 有可能從源頭就產生錯誤的認知及作法，卻無由亦無從矯正。尤為困難的地方是，

這類型規格連學界也未必熟知其所觸及的許多觀念實際應用情境，於是更難有機 會與公開場合來討論這些現象，受訪者 B 在業界處理這麼多 RFP 的經驗裡，對這 類型的需求所產生的種種現象感受最為深刻。

（二） RFP 的重新設計必要性

目前看到的系統需求書，常見動輒上千條的系統功能描述、要求相當多的項 目，受訪者 A 認為這些條列描述充其量僅能說是作為全案驗收時的系統功能檢驗 清單（checking list），而非在其館務作業層面的功能需求（functional requirement）。

從描述細緻又項目繁多的規格隱含了雙重的訊息：（1）規格描述的過於細緻，除 了是館務的特殊作業需求之外，也有可能是指向某個特定品牌的系統才具備的功 能，圖書館藉此規格排除其他可能進入的系統品牌；（2）在系統需求書的運作過 程裡，館員經常向系統公司提問系統可否執行某種功能以替代館員的作業，可能 引發的接續議題是：「在使用這樣可取代館員作業的系統之後，是不是便毋須存在 館員呢？」受訪者 A 提出如此的疑問。

受訪者 A 認為 RFP 是一種在系統評選結束的當下，即成為一種過時的文件與 規格了，即便該案往後的系統驗收仍須依據 RFP 的文字記載。然而，軟體最大的 特性是持續前進並隨時因應最新的發展應用而作調整，軟體的精髓即在今日與明

117

日的成品會不停地變動，如同三年前的手機跟現在的手機功能差異甚大，當新手 機上市時，舊手機便成為過時的物品，受訪者 A 為軟體尤其如此，「唯有在不停的 變動中，才能產生更多新的火花」。因此從系統評選結果公布，到全案驗收上線的 這一段時間內，軟體功能仍舊持續更新變動，圖書館是否仍需要緊緊抱住原招標 文件的 RFP，而棄用系統公司所提供的最新版功能呢？有鑒於此，受訪者 A 才持

「RFP 是一種在系統評選結束的當下，即成為過時文件與規格」此一主張。

在實務作業的表面上，圖書館應自館業務特性及需求提出了 RFP；但實際上，

多年下來市面上許多圖書館自動化系統採購案的 RFP，所提出的系統需求規格大 同小異，皆具有普遍性。綜合四位受訪者的意見，可從三方面來看：

1. RFP 多半為複本式的複製改寫

四位受訪者都提到目前的 RFP 皆為複本式的複製改寫。大部分的需求書多源 自於民國八十九年版的《各層級圖書館資訊系統軟硬體規範書》，此為因應圖 書館規模大小及行政體系的差異，就《圖書館自動化系統軟硬體共通規範書》

（1997）再加以區分成大、中、小型圖書館需求的系統規格書（賴忠勤，2003）； 或者是甲館複製乙館，丙館又複製甲館的需求書；更常見的情況是圖書館向 各家系統公司邀集其圖書館自動化系統規格書，加以整併成該館初版的系統 需求書之後，再發送給其他系統公司覆答此合併之規格書，以進一步確認該 份規格書的合理性。無論是哪種做法，多年下來的系統採購案需求書，規格 都很類似，包括需求書的文件結構與特徵、著重的需求議題、可操作的庶務 型規格與止於概念層面的發展型規格描述等等。很多庶務型的規格細瑣繁 縟，因基於館員所熟悉的業務操作流程與內容，故要求系統必須具備的這些 功能規格；但後來很多時候的 RFP，其所羅列的規格繁複與細緻，則往往是 為了安心－－鑒於他館規格都有條列、故自館的規格也必須羅列的心態。

118 2. 系統的模組功能多已標準化

受訪者 A 的工作職涯中曾接觸三套 ILS，其回覆圖書館需求書時，無論是哪 一套系統所能達到的功能大致佔整份需求規格的 70％，認為此現象代表的涵 意是：（1）各圖書館開出的系統功能規格相似；（2）圖書館實務作業的模組 功能已經標準化。因此受訪者 A 主張圖書館提出需求時，應可省略羅列動輒 上千條的細緻規格，反而應詳加思考這套新系統所欲達成的目的，並檢視圖 書館各部門的工作內容，於需求書明列 10－15 件、甚至 20 件重要的工作，

例如編目組需例行將書目上傳至全國書目資訊網，那麼為了達到此工作目

例如編目組需例行將書目上傳至全國書目資訊網，那麼為了達到此工作目