如何避免資訊系統開發專案失敗

文 – 楊振源

資訊系統開發專案是一件苦差事，尤其是從無到有的資訊系統開發過程，往往付出過多的心力，平白走了很多的冤枉路，成果卻極其有限，阿達嘗試整理分享一些狀況，以分享避免重蹈覆轍。

● 受訪代表完整性
專案開發過程當中，通常會成立專案小組，指派專案成員接受訪談。常遇到的狀況之一是重要工作無代表人參與訪談，以致欠缺一大塊的需求表達。再則Key User突然請假，或接到臨時任務不克出席會議，究其發生原因，因為這個訪談會議的位階太低，或不被視為最重要的工作，以至於任何人突然或臨時的事情都比這個基礎工程的會議還要優先，這些現象會影響專案訪談進度以及訪談完整性。

● 需求表達完整性
許多公司的ISO文件是為應付審查用的，與實務嚴重脫節，毫無參考價值，假如有完整的SOP文件則可以縮短訪談時間，強化訪談的完整度。沒有SOP文件就只能靠主談者的誘導，談出現行的作業流程，加上適度的合理化、制度化、系統化，也就是直接從隨意的人工作業，直接跳入電腦系統管制。這是一件很危險的事，沒有經過實務驗證的過度理想化需求、邏輯規則不完整的防呆或內控管制點，這些都影響到規劃的品質。沒有SOP文件，往往未能一次完整描述需求，一個作業常常談了數十次了還在變，這些現象還是影響到訪談進度以及訪談完整性。

● 決策代表人
訪談會議會有各部門或作業的Key User參與，通常他們也都是平行單位，當意見相左對立的時候，就需要有仲裁者，仲裁者需要具備足夠的專業、經歷、輩分、與職位權力…等。高階長官通常以業務繁忙為由不參加這個會議，其實這些長官是因為聽到電腦就害怕，我們寄希望於PC世代的主管出頭，這問題就不存在了。主管不參加也OK，但是決策委員會必須動起來，我們可以利用精簡的時間描述問題點請長官裁決。資訊系統也不是把現有的人工作業直接電腦化，這樣只是把原本不對、零散、沒有管制稽核的散亂作業電腦化，讓弊端透過資訊系統快速漫延，產生更多的弊端與垃圾。議而未決、無人仲裁，這些現象還是影響到訪談進度以及訪談完整性。

● 衍生擴散需求
資訊系統有其模塊組織性，User望雲霓若渴，常會許願，希望這個希望那個，希望是有代價的，任務也是有階段性的，無止盡的擴散需求導致時程延誤、費用增加。客廠糾紛不利於專案進行，雙方PM或決策高層必須有高度智慧與技巧，去異求同，逐步強化完成共識部分，隨著逐步完成的事項再來看差異部分，或許會更明確或更有助於釐清差異。

● 不合理的合約條款
目前資訊系統的開發技術能力已經不是問題，問題通常出在適合的作業程序、適當的管制點設計、需求描述的完整性，這一些事並非乙方提供的，但往往合約卻將這些責任加諸乙方，例如延遲條款、罰則…等等，責任不合理或不對等的合約，一開始已經注定失敗一半，失敗的專案對甲方沒有任何好處，這是我之所以堅持的原因。

錯誤的規劃方向，不能達到公司期望透過資訊系統興利除弊的目的，砍掉重練的規劃徒增工作同仁的挫折，彼此消耗更多的成本與時程，如何一次到位是我們追求的目標。