監察院研考室 洪國興主任 資料來源： http://www.ima.org.tw/net014.htm#p38 前言 資訊作業委外服務是政府機構或企業不得不採取的資訊資源取得之重要策略。從整體層面來看，它解決了政府機構或企業對於資訊人力不足的問題，亦有助於資訊服務業的成長，對扶植軟體工業的發展應有其正面的價值與貢獻。然而，就個別的政府機構或企業而言，都有層出不窮的問題，無論是業主或是資訊業者，對於資訊作業委外服務的外包或承包，都有各種的經驗，或多或少的糾紛，有的雙方訴諸司法，有的無法驗收，也無法取得價款，雙方互不退讓，各有堅持，在眾多的委外服務案例中，以軟體開發的糾紛最多，困擾最煩。本文即在探討軟體開發的委外服務中，所發現的種種問題及分紛爭，以及預防或解決這些紛爭的方法或對策，算是對委外服務所產生的病症，開出來的處方，這些處方未必適用於每一個個案，因為每個人的體質不同，相同的處方，藥效自然無法一致，當視各別情況而定，但可舉一反三，亦可作為參考。本文先就辦理招標階段之問題與對策提出探討，希有助於委外服務糾紛或爭議之有效預防。其常見的問題如下： ●押標金與履約保證金多寡的爭議，若太少業主恐怕得不到適當的保障；若太多，又怕增加廠商的負擔，因押標金或履約保證金所增加的財務成本，會反應在投標金額上，仍是由業主負擔。 ●時程的訂定合理與否的爭議，多長才算合理，業主在會計年度即將結束，如未能在結束前發包或驗收，預算得面臨繳回，或首長要到立法院報告預算保留的原因，在此種壓力之下，主辦單位顧不得時程多久才合理，必會訂在會計年度結束之前驗收，因而種下糾紛的原因。 ●合約對於雙方權利義務要訂到何種程度才算明確，怕掛一漏萬，又怕訂得太僵硬，毫無彈性，執行起來會有困難。 ●軟體規格要如何訂定，只開功能規格可以嗎？或程式規格都要具體詳列？太籠統怕廠商不做；而逐一列舉，但又擔心掛一漏萬，或規格稍有錯誤，連修正、調整的機會都沒有，可謂兩難。 以上所發生的問題或爭議，不只是業主兩難，廠商也兩難，如何是好，有一些對策可以因應： 一、以有價證券作為押標金： 押標金係作為廠商投標至簽約期間的保證，而履約保證金係由得標廠商押標金轉換而來，作為合約執行的保證金。兩者對業主而言均甚為重要，若訂得太低，失去保障的意義，訂得太高，則增加廠商的財務負擔，又反應到投標的金額，固太高或太低均有風險，通常是以合約總價的5%至10%間，並避免限定以現金支付，可改以定期存單、公債、票券等之等值有價證券作為押標金，對廠商的財務負擔應可減輕不少。 二、以品質為導向的時程評估原則： 交貨時程應力求合理，除了應按軟體工程的方法評估時程外，尤應考量軟體的品質，在維持適當的品質水準原則下，應有足夠的發展時間。對於大型的系統，其發展時程恐不易估算，可採分階段發包，分階段訂時程，則時程即可估算得較正確且合理，至少可考慮系統分析之前為一個階段，系統分析之後為另一個階段。為避免因受限於會計年度即將結束，而訂出不合理的時程，可在會計年度開始前，即做好所有發包前的準備工作，會計年度一開始，即辦理發包，則時間較為充裕。再者大型系統應按分年編列預算，逐年執行發包，即可減輕會計年度結束在時程上的壓力。 三、委外合約的爭議最多的莫過於合約內容的爭議，如何預防合約爭議的發生，或使爭議減至最低程度，其合約內容研擬，對策如下： 1.適當的合約型態是減少爭議的第一步： 採用總價法，則雙方各自承擔可能的風險，雙方就固定合約價款完成合約所規定的事項，乙方不得要求甲方加價，甲方亦不得要求乙方減價。成本加公費法即雙方共同核計成本，依成本加公費計價，雙方均無太大風險，公平合理，誰都不吃虧。開口合約則係為因應緊急性、臨時性的工作，其計價係以完成工作指派單的工作為計價依據。 2.合約亦應規範合約的執行方式： 究係交付最後產品，亦或雙方約定以成本計價，則雙方對於成本的紀錄、審核、控制應有一完整程序可作為依據。亦可以投入人月數為計價基礎，此為成本加公費法的另一種模式。採開口合約者，工作指派單則係合約執行及計價的重要依據。 3.軟體規格係逐步發展而告確訂定： 軟體發展不同於其他產品，無法具體的以數據或文字對其產品的規格加以充分描述。軟體產品的規格是隨著每一階的進行，使其規格逐漸明確，逐漸清楚，因此，分階段發展，經過甲方分階的確認，並分階將產品交予甲方的方式，恐怕是訂製軟體產品獨有的方式，因此，要將軟體工程的理念及作法訂於合約之中，使雙方運作有具體依據，此部分應是軟體發展合約的重要精神所在。 4.共同管理專案： 合約所能規範的內容畢竟有限，且擬訂合約條款時，尚無法知道得標廠商為何，當決標後，應由雙方就合約精神在其合約期限內完成合約產品的目標之下，雙方共同管理專案，並將此精神納入合約，以作為合約執行之依據。軟體發展合約，甲乙雙方的關係不同於其他採購案中甲乙雙方關係的如此清楚、對立，而有部分是雙方需要合作，那就是共同管理專案。如何共同管理呢？除事先在合約內已約定主要的工作範圍外，對於主要的工作內容要在專案計畫內約定，專案時程要雙方共同研訂，至少甲方要有對時程的審核權，對於重要里程碑雙方要有共識。專案人力的資格條件與人數無法訂於合約，但可約定於專案計畫中加以明訂，使雙方可共同遵守。 5.共同擁有著作權： 著作權之歸屬亦應列入合約，為降低軟體開發成本可考量由雙方共同擁有著作權，並將程式原始碼（source code）保存於律師事務所中，避免一方組織不存在，無法取得程式原始碼，而損害其合約。 6.約定軟體發展標準： 文件發展標準列入合約，原則當今委外服務盛行，可能每一次發包得標的廠商均不同，使用的軟體工具不同，使用的文件製作方式、標準均不同，一段時間下，電腦中心會成為聯合國。再者在文件審查的階段，往往雙方對何種程度才達到標準，難有客觀，致雙方爭議不斷，因此使用何種文件標準，及系統發展標準，可規範由甲方提供，或由乙方提供，甲方有審查及同意與否之權，以避免對方對文件認知不同的糾紛。 7.保固及維護權利與義務之明確化： 保固期間、保固及維護之義務、維護費額度等均應於合約規範中訂定，若未訂明，容易造成低價搶標，高價維護的不合理現象，再者，維護期間的工作範圍亦容易造成糾紛。對於維護費額度於合約規範加以明訂並列招標文件，則可維護廠商的公平競爭。 四、軟體規格的訂定常是爭議的焦點，預防爭議的作法如下： 1.至少要有需求分析才能委外： 能有完整的系統設計或軟體規格（soft spe.），再委外當時是最理想不過，但是多數電腦中心難以做到，因人力不足，才採取委外的策略，何來人力資源做系統設計或軟體規格呢？唯人力再不足，需求分析是絕不可省略的，若連需求分析都沒有即委外，保證是糾紛不斷，爭議不停。 2.功能規格亦可委外： 進一步的除了需求分析外，亦可採用功能規格（Function spec.）發包，當無法完成系統設計，能有功能規格總比沒有好，再者有時迫於時間的限制，先用功能規格也是彈性的作法，若功能規格能訂得明確，仍可有效的避免雙方的糾紛或爭議。 3.輸出表單或畫面是常被採用的規格文件： 4.雙預留彈性空間： 無論用何種方式訂規格，尤其是以具體的軟體規格發包者，應在滿足功能的原則下，讓得標廠商的專案人員有發揮的空間，此一作法對雙方都有正面的意義。對乙方而言可以使用較具有效率的發展方法及工具，並表現其特有的開發能力；對甲方而言，則可不拘泥原有規格，可追求更高品質及使用效率的軟體產品，能運用得好，應是雙贏的策略，千萬不可掉入「規格的迷失」，雙方均無法自拔，最後是兩敗俱傷。 5.政策或法令變更的因應： 在軟體開發的過程中，遇到政策及政府法令的改變，其風險由何人承擔，此亦造成雙方糾紛及爭議的重要因素，通常可以系統設計為分界點，即系統設計確認前，因政策或政府法令改變所涉及的變更，由乙方負責吸收；如在系統設計確認後，則由甲方負擔，以追加方式調整價款，此種作法應係公平、公正的方式，應將此一原則訂於合約中，未雨綢繆。 委外服務的爭議當不止於此，以上僅就發包階段可能的爭議提出一些預防的措施及作法，對於合約執行及軟體使用階段仍有相當的爭議，將另案探討。 資訊作業委外服務的問題層出不窮，曾多次加以探討，之前對於招標階段所面臨的問題，及發生的爭議有若干探討，也提出一些對策，期盼對於委外服務的糾紛與爭議能有效的預防，使爭議消弭於無形。然而委外服務之糾紛與爭議並不限於招標階段而已，當委外服務招標案決標之後，雙方簽訂合約，即開始依約執行，進行專案的規劃與開發，此時仍有不同的爭議可能接踵而來，即是合約執行階段的爭議，諸如： ．規格確認之爭議 ．交付遲延之爭議 ．固定價格之爭議 ．智慧財產權相關爭議 ．交付內容之爭議 ．驗收之爭議 ．變更頻繁之爭議 ．專案管理之爭議 茲就上述爭議發生的原因及可能的對策逐一加以探討： 一、規格確認之爭議 在資訊作業委外服務之中，以軟體外包最常見，而軟體規格又是爭議的焦點，雙方往往對是否「符合軟體規格」產生極大的爭議，之所以如此，係因「軟體規格」難以訂定，無法像硬體規格可以用具體的數據或文字加以充份的描述，而又缺乏具體客觀的衡量標準，用以判定「符合規格」與否，致雙方爭議不休。下列一些作法可供參考： 1.分階段發展，分階段確認 軟體工程的理念即在分階段發展，分階段確認，以期提早發現錯誤。軟體發展另一特性是其規格無法在一開始即可明確的詳列，而是經由每一階段的發展，使規格隨發展之進度而愈來愈明確，換言之，軟體規格係經由發展而確定，而非一開始即加以明確訂定。因此，若能貫澈軟體工程的理念，分階段發展與分階段確認，自然可以消除規格不明確的爭議。 2.約定確認時間，逾期視同確認 確認花費的時間太長，容易造成專案進度落後，當交付遲延發生後，業主欲以逾期罰款處理，廠商則反而以確認時間太長造成交付逾期，向業主要求損害賠償。因此，雙方應於合約約定確認時間，業主得以此要求使用單位如期完成確認，如逾約定之確認時間，則視同確認，使用單位未在期限內提修正意見，即同意廠商所做之各項規劃設計，如此，使用單位為掌握修正的機會，必會認真如期的完成確認，使進度能掌握在可控制之範圍內，而經確認之文件即是明確的規格，規格爭議自然消弭於無形。 3.約定確認後之文件為合約之一部分 軟體發展的特性係經由每一階段的發展，使規格逐步確定，而非於一開始即可完全確定，換言之，每一階段經過確認的文件，即是規格的一部分，當完成所有文件的確認，其軟體規格亦隨之確定。因此，確認文件對雙方應是具有法律上之拘束力，始能維護雙方之權利，故約定確認後之文件為合約之一部分，則對雙方即是具有拘束力，廠商應依確認後之文件發展軟體，而業主則僅能依確認後之文件作為驗收依據，各有所本。 4.約定法令修改時配合修改規格的分界點 在許多的委外服務案例中，經發包之後因政府法令修正，或政策變更，而其變更內容又與軟體功能有極密切的關係，若未按新法令或新政策作修正，其軟體功能顯然是無法滿足使用者的需求，因此修正軟體規格是勢所必然，只是分界點在何處，始為合理適當。若系統已接近驗收階段，法令才修正，此時軟體規格再作重大調整，而由廠商承擔成本及時程增加的責任，顯然是不公平的，因此應訂定一個合理的分界點，通常可約定在細部設計確認前，在此之前廠商應調整規格，之後，廠商可不作調整，或可修訂合約價款與交付時間因應。 5.其他 要預防委外軟體規格是否符合之爭議，最重要的是不可將發包時的簡要規格作為惟一的依據，如同聖經一般不可變動，應秉持軟體工程的分階段發展，分階段確認，經由確認而使規格逐漸確定的精神處理，除此之外資訊人員在此過程中，要扮演中介的角色，作為廠商與使用者間溝通的橋樑，使用單位對確認所提出的意見亦應合理，廠商亦應盡責。在使用需求的規劃過程中，可展示類似的系統供使用者瞭解，可藉此引發使用者對使用需求描述的更精確，減少系統開發者與使用者問題認知的差距，當然雛型法(Prototyping)亦可在系統規劃，系統分析階段採用，對需求界定會有極大的幫助，需求愈明確，發生爭議的可能即可相對的降低，唯無論如何明確都不可能做到百分之百確定，因此，預留適當的修改彈性應是雙方應有的共識，另也要讓系統開發者有發揮的空間等，都是防止雙方為規格是否符合之爭議發生的措施與策略。 二、交付遲延之爭議 委外服務能如期交付的case不多，這是資訊界的通病，一時恐怕難以改變。廠商往往怪罪業主訂定的合約交付時程不合理，而業主則迫於會計年度即將結束，不得不壓縮專案時程，草草驗收，留下無窮的後患。此類的爭議亦不在少數，仍有一些方法可以參考： 1.分階段交付 照軟體工程的理念應分階段開發，分階段確認，則交付亦應分階段交付。其交付內容與時程要訂於合約或專案計畫中，則依約執行，較無爭論。分階段交付對業主而言，有較多的時間可以審查測試，避免於最後全部一次交付時，匆忙中趕工驗收，無法消化。再者若有錯誤亦可提早發現，立即反映修正，最後交付當不致發生重大之錯誤，對品質管制而言，亦有其正面價值。 2.新增功能，應另訂交付期限 在專案發展過程中，往往會增加一些發包時未涵蓋在合約內的功能，此部分除價款應另訂外，其交付時程亦應另行商討訂定，以符公平交易原則，亦是避免影響原有合約內容的交付期限，致發生遲延爭議的作法。 3.明訂變更程序，嚴格變更控制 任何專案發展都會有變更控制(Change control)的問題，要杜絕所有的變更是不可能的，此一想法亦是不切實際的，但是業主內部對於變更應有合理的控制程序，在一個部門內的變更應由授權的主管核定，跨部門的變更則應由跨部門的共同上層主管核定，以明權責，以昭慎重。萬萬不可由最基層的承辦人提出變更需要未經任何主管核定，即予受理，那將導致變更失控(out of control)，對專案發展之控制及專案品質管制傷害頗深。對於重大的變更需求尚應除部門主管核定外，應經由一個專責的審查會，就其對專案的影響、成本、技術、時程等因素作整體考量，嚴密審查，才能確保專案品質及進度。 4.明定交付程序與方法 若程序不清，方法不明，日後雙方必為有交付或無交付，及交付的時點爭議不休，但遲延發生，雙必互相推諉，不願負責，故交付程序與方法可訂於專案計畫，明訂雙方交付或確認文件的窗口、流程及責任，每一步驟的經過，應詳加紀錄，以明責任。 5.明定逾期確認的責任 確認期限是為保障雙方可在約定的期限內完成專案，若未能在期限內完成確認，業主自應負部分責任，然而廠商對確認所提出之意見，未能即時修正，再經由使用單位確認，或同一錯誤經多次提出，廠商未必修正，則廠商自應付遲延責任。 合約執行階段爭議問題頗多，篇幅所限，除以上探討的規格確認與交付遲延兩大爭議之外，固定價格等六項爭議將在以後數期加以探討，就教於讀者。 網路志工聯盟----Visita網站http://www.vista.org.tw ---[ 發問前請先找找舊文章 ]--- 發表人 - axsoft 於 2002/08/23 11:28:59 發表人 - axsoft 於 2002/08/23 11:30:15