案例四專家3：Lucas Chuang

「『雅典娜』系統經常不穩定，使廣大的使用者對系統缺乏信心，在一開始信心度不足的情況之下，之後的開發及建置過程中，導入者便很難去重建使用者的信心。所以一項科技導入並不是敗在系統不好，而是敗在使用者心理層面的排斥。」

專案時間不宜太長。麻省理工學院這個案子，前後長達八年，以民間企業的角度來看，時間太長了。一個專案如果超過三年，通常就註定要失敗。以航空業為例子，外在環境的變化很大，例如2003 年，原本預期會是景氣很好的一年，可是怎麼知道會發生SARS 。再舉一個例子，長榮航空開航以來貨運的每公斤單價最高和最低都發生在九一一那年。

我的意思是專案時間這麼長，環境會變化，科技也會變化，特別是在麻省理工學院的例子中，採用最新的科技，在這麼長的專案執行時間內，一定會有很大的變化。另外，一個長達八年的案子，有多少人員會變動，重要的核心人物一走掉就麻煩了。新的人員承接不上，系統必須重新設計（rework），有時候rework 可能造成整個技術基礎建設（infrastructure）的改變。新的成員也可能會帶來新的想法，尤其是新的主管，他可能有新的理想，而導致系統成為不斷變動的目標（moving target）。

舉一個例子，我們有一個航空貨運的資訊系統，最初是由我們及另外三家航空公司——英國的British Airways 、澳洲的Qantas 及韓國的韓亞航（Asiana Airlines）共同合作開發。但是四家航空公司由於文化背景及經營模式不同，要達到共識很困難，因此許多程式都得處理很久。澳洲的Qantas 航空因為一些商業上的考慮，首先退出系統開發的合作關係。接著1997 年亞洲發生金融風暴，韓國的航空公司也因為缺乏資金而退出。British Airways 則因為要在Heathrow 機場蓋一個很大的倉儲中心，所以決定全力放在該案子上，因此也接著退出合作，四家航空公司最後只剩我們一家。這也是為什麼我會說專案的時間不能太長，時間太長，變數就太多。一個專案一開始必須要有弘遠的願景（vision think big），然後由小處著手（start small），最後是要能迅速執行（scale-up fast）。

有效管理專案中不同的重要關係人（stakeholders）。一個專案中存在著許多重要關係人。有些人對專案的進行可能是正面，有些可能是負面，你必須去管理它，但也不要過於鄉愿，因為你不可能去滿足每一個人的需求。因此要明確定義誰才是真正使用系統的人，這些人就是這個專案的顧客，他們才是系統真正的擁有者。在麻省理工學院的個案中，教授及學生就是顧客，系統人員要追求的便是顧客的最佳利益。

但是一個專案中，使用系統的人可能很廣，來自不同單位，例如教授及學生分別來自不同的學院，不同的學院間可能存在不同的理念，教授之間也可能有不同的需求及對系統不同的期望，一個標準的系統是否就能同時滿足不同的需求？因此，系統的規劃是不能以one-size-fits-all 的構想草率行之，在專案執行前要先做企業探索（business discovery），當使用者的組成很廣泛時，要能顧及不同使用者的心理層面，因此在麻省理工學院的個案中，導入者要能讓不同學院的聲音被採納。在我們公司，一定是使用者的參與及涉入程度都很高的專案才會成功。

對使用者的管理有幾個策略。首先，是當使用者有不同意見時，要對相關人員進行遊說。有時候透過非正式的管道進行溝通，反而能讓使用者接受或改變想法。再者是必須有足夠的教育訓練，因為縱使有良好的系統，缺乏充分的教育訓練，使用者便不知道要如何去使用，因此也不會了解系統有哪些有用的功能，系統的接受度便很低，最後導致使用者對系統人員的不信任。我們資訊部門經常透過巡迴演講的方式，到各個單位去介紹系統相關功能或新的科技知識，就好像是下鄉義診，同時也聽取使用者的意見。我在我的部門內也對每個營運單位設置單一聯絡窗口（single contact window），由課長級（manager）以上的人員擔任，把使用者當顧客，就像是在經營資訊科技公司，使用者及資訊人員之間形成夥伴關係，溝通便可以更通暢。

技術變革管理（configuration management）。以長榮的文化，在任何專案決定以前，可能有不同的意見在討論，但案子一旦決定要執行，全部成員都要完全的支持。私人企業比較不會有像麻省理工學院的情形發生，就像前面提到的四家航空公司合作的例子，長榮航空能堅持到最後，是因為我們有很強的推動力量（driving force）以及背後高層堅定的支持。例如前面四家航空公司共同開發貨運系統的例子，在這案子決定前，其實也有高階經理持不同意見。但貨運的收入占全公司獲利的一半，我們了解到這個系統對公司營運的重要性，專案的進行因此獲得總裁直接的承諾。

當一個資訊系統同時牽涉到多個營運單位時，為了讓營運單位的使用者接受系統，我們公司內設有一個協調支援單位，做為協調資訊部門跟營運單位之間的溝通橋樑。當系統有變更或修改時，資訊部門必須先對這個支援單位負責，然後支援單位的人會協調後端的經營單位。因為這個單位隸屬於企業規劃部（corporate planning），地位比較崇高，它的
建議大家比較不會去質疑（challenge）。

關於這一點，或許可以用我們公司內稱為功能權威（functional authority）的名詞來說明。負責功能權威的人控管所有系統功能，他對系統的所有功能都相當了解，當使用者對系統有升級或修改的要求時，他會判斷是否有其他的方法可以達到相同結果而不必改變系統。如果他認為要修改系統，他要有足夠知識做business impact analysis（企業衝擊分析），分析系統的變更可能會對企業帶來何種影響，接著判斷系統需要有什麼功能，然後協同資訊人員，從科技的角度做系統的衝擊分析（systemimpact analysis）。另一種做法叫議題管理（issue management）指的則是企業相關的分析，包括系統對企業其他專案排程或資源的影響，這部分的分析可能會牽涉到政治層面的風險評估。

系統的管理。在專案一剛開始規劃時， 要設立一個接受水準（acceptance criteria ），也就是你的系統要達到何種服務水準（service level）。像麻省理工學院的個案中，「雅典娜」系統經常不穩定，使廣大的使用者對系統缺乏信心，在一開始信心度不足的情況之下，之後的開發及建置過程中，導入者便很難去重建使用者的信心。所以一項科技導入並不是敗在系統不好，而是敗在使用者心理層面的排斥。另外，在我們公司內會有所謂的OR（Observation Report ，觀察報告），指的是在系統檢閱（review）後，對系統做確認（validate）的工作，確認後才能進行下一階段的工作，每次一項系統測試失敗就要完成一份OR ，包括OR的負責人（owner），預期什麼時候可以解決問題等等資料都要詳細記載，藉此，系統的品質才可以有良好的控管。