案例四專家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），預期什麼時候可以解決問題等等資料都要詳細記載，藉此，系統的品質才可以有良好的控管。

案例四專家2：Leong Chen-Sung

「你可以透過讓用戶了解系統的用途，來使負面影響最小化，並逐漸扭轉局面。當教授們看到系統被廣泛應用，人們就會逐漸對系統產生信任。觀念的改變能透過自上而下的方式取得，而不是自下而上的方式。」

為了應用新的資訊系統，我們首先必須識別利益團體。一旦識別了利益團體，系統的目標和約束條件就應該被傳達給利益團體。利益團體應該參與系統最初的可行性研究與涉入後期實施階段所有的發展過程。

在「雅典娜」案例中，從計畫到實施開始，不滿和沉默的用戶都被拋棄，系統的推動和約束條件也沒有被傳達給這些人。在商業環境中， ERP 專案通常涉及到組織的所有部門。為了成功應用ERP ，所有部門都應該參與可行性研究、測試和開發。在「雅典娜」案例中，技術開發者在傳達約束條件和期望方面的工作做得不好。根據我作為技術開發者的經驗，有時我們沒有做詳細的討論來了解用戶對系統的期望。如果從一開始就沒做這項工作，執行者和用戶會對系統有不同的期望，最終系統不能滿足任何一方的期望。

在「雅典娜」案例中，用戶的期望沒有被滿足。執行者（政策制定者和系統工程師）對專案有很高的期望。他們期望「雅典娜」能夠被教授和學生用作研究和教育軟體的平臺。但是他們的期望與系統的其他用戶（不滿方和沉默方）的期望不一致。多數教授沒有看到這套系統的必要性。「雅典娜」更是對他們研究工作造成干擾。在INSEAD ，很多教授對於應用技術也有類似的顧慮。一些教員對使用技術不感興趣。雖然也可以使用PowerPoint 幻燈片和繪圖模型系統，使用黑板、粉筆和OHT（投影片）仍然很普遍。

在商業環境中，把專案的期望傳達給高層管理者是資訊長的責任。系統實施的方式，很大程度上是由商業環境決定的。在學術機構情況會有所不同。例如，在INSEAD ，管理者對於科技系統的應用權力有限，教授比管理者權力更大。教授對於什麼專案可以實施、什麼專案不可以實施有很大的發言權。

技術侷限是「雅典娜」失敗的另一個因素。技術不相容影響了平臺的穩定性。最初的技術困難給人感覺是系統不能滿足需求。但這可能給人留下了「雅典娜」不好的印象：這個平臺不穩定。這樣，使用者從一開始就對系統產生了一個負面的印象。

任何試圖挽救「雅典娜」的顧問公司都會陷入困境。在過去七年中，用戶認為平臺不可靠的印象早已形成。工程方面可以迅速改變，但觀念只能逐漸改變。學生必須認為「雅典娜」是一個有用的工具，而不只是用來發電子郵件和玩遊戲。

要解決「雅典娜」的問題，需要採取一個自上而下的方法。這案例中有三個資深教授在推動該專案。他們應該把系統的目標和期望告訴所有人，讓用戶了解系統的用途，以使負面影響最小化，並逐漸扭轉局面。當教授們看到系統被廣泛應用，人們就會逐漸對系統產生信任。觀念的改變能透過自上而下的方式取得，而不是自下而上的方式。在INSEAD ，我們沒有任何資訊系統和「雅典娜」類似。最接近的是KMP（Knowledge Management Portal ，知識管理入口網站），我們用它來整合線上研究和教學資料。如果教授有任何需要，我們就會派專人來協助他們使用系統。目前應用很廣泛，但也有教授不願使用。我記得一件事。在KMP 上有一個案例建構工具，但一位教授堅持只用他自己的工具。在這種情形下，你很難改變教授對新科技的態度。你不能強迫教授改變他的習慣。

INSEAD 是很企業化的組織。但做為教育機構，我們也面臨限制條件。對任何一個項目，確定了利益團體後，我們都會與他們溝通，根據優先順序解決他們關心的事。我們目前正在引進一個標準化平臺，這個技術平臺能滿足學生錄取、行政管理、財務控制和教學協調等需求。我們組織培訓課程，讓用戶了解系統的主要特徵和侷限。在首次展示之後，我們從關鍵用戶那裡得到回饋，根據回饋調整並測試系統。系統在最後展示前，會經過兩到三次修改。這樣，用戶不會感覺他們的回饋被忽視了。在「雅典娜」一案中可以應用同樣的觀念，使更多的用戶參與系統改良。

為了評估系統的成功，我們使用統計資料。系統用戶數和業務量能告訴我們系統導入是成功還是失敗。在商業中，資訊系統的效果是由它對基層的影響來衡量的。

案例四專家1：蘇守謙博士

「專案負責人並沒有把他們的『餓』轉化成其他教授與學生們的『餓』，再加上學校文化一向自由，在不會『餓』的情況下，任何人想要硬塞東西給其他任何人，都是很困難的。」

不痛不餓，專案難成。在協助企業導入資訊專案的過程當中，我們經常會跟專案負責人分享一些觀念，其中，「痛」和「餓」的觀念是我們最常探討的。「痛」是指在現行作業當中，存在著一些事情，每天大家都用同樣的方法在做，做得很痛苦，急欲找到更有效的方法，儘速去之而後快的那種感覺。而「餓」則是指一種強烈的渴望，希望事情會因為這樣而變得更好，即使現行作業並沒有什麼問題，也希望儘快找尋突破性的做法。就我們過去的經驗，一個專案如果沒有「痛」也沒有「餓」， 通常很難成功。

「雅典娜」這個專案，從頭到尾看不到「痛」，或是更精確的說，專案負責人並沒有試著要去找出使用者真正的「痛」。究竟教授們在日常教學當中，有哪些滯礙難行的地方？學生們在日常學習過程當中，有哪些不便之處；而這當中，又有多少是可以利用資訊科技來改善的。有些問題可能跟管理制度有關，有些可能跟教授的異質性有關，不見得每種問題都可以靠資訊科技來解決。這些問題如果曾經仔細討論過，就不致於會有技術平臺都已建置好，卻獨缺教學軟體的情況發生。

換個角度來看，這個專案倒是看得出明顯的「餓」。幾位工程背景的資深教授和實驗室負責人，極力促成下一代的資訊運作平臺，深信因此可以提升老師教學品質，增進學生科技能力。如此強烈的使命感和企圖心，再加上院長和資訊大廠的多方支持，斷無失敗的道理。只可惜這些專案負責人，並沒有把他們的「餓」轉化成為其他教授與學生們的「餓」。再加上學校文化一向自由，在不會「餓」的情況下，任何人想要硬塞東西給其他任何人，都是很困難的。

無賞無罰，誰會關心。既然缺乏自發性的「痛」和「餓」，接下來可以思考的恐怕就只有「賞」和「罰」了。在大學，教授最關心的，莫過於得到認可，進而升等或得到長久的聘任。使用「雅典娜」專案所建立的技術平臺，來開發教學軟體、提升教學成效，這件事情如果跟老師的績效、升等、聘期無關，相信要爭取到老師們的關注是很困難的。叡揚資訊曾經有機會參與一企業建立SFA（Sales Force Automation ，業務自動化專案），在系統建置完成之後，業務人員不想用，認為是浪費時間，讓專案負責人相當苦惱。最後還是靠總經理強制要求所有業務檢討會議，均需以SFA 系統內的及時資料為準，凡是未列入系統管制的銷售案，均不能列入業績，同時業務人員也得不到相對的業績獎金。類似像這樣的做法，對於改善業務人員事不關己、我行我素的習性，倒是頗有成效。

管理上常說：「沒有績效衡量，就沒有管理成效。」（No Measurement, No Management）如果學校對教授的所有績效衡量指標，都跟使用「雅典娜」的資訊平臺無關，那教授們自然也就不會關心這個專案的成敗。至於學校應該擬定什麼樣的賞罰政策才會有效，相信不需要大家操心，學校自有辦法，反倒是專案團隊是否有把這件事情放在心上，恐怕
才是關鍵。

科技領導，忽視管理。在協助企業資訊化的經驗當中，我們發覺資訊科技專案和資訊系統專案，兩者在專案管理以及專案成員的組合上，都有很大的不同。一個科技的專案，譬如說，是要擴充網路頻寬，或是建置網路安全機制等，由資訊部門來主導通常沒有問題。但是，如果是一個管理資訊系統，譬如說ERP（Enterprise Resource Planning ，企業資源規畫）或CRM（Customer Relationship Management ，客戶關係管理）系統，若只交由資訊部門來主導，則風險很高。叡揚資訊曾經協助一家電信公司成功地建置一套業績分析系統，主導者便是業務部門的副總經理，責成一位非常了解業務流程的經理來規劃，整合各項業務需求，提
出完整的需求規格。相對而言，資訊部門則是從資訊科技的角度，如資訊架構、安全機制、權限控管等方面來從旁協助。另外一個流通業的資料庫行銷系統案例中，專案負責人也是行銷部門的主管，而非資訊部門的主管。整體來講，就我長期的觀察，如果是屬於MIS（Management Information Systems）或EIS（Enterprise Information Systems）的應用，專案負責人可能是以使用者的上線主管（line manager）來擔任比較恰當。

「雅典娜」專案如果當初定位是在建立一套分散式網路「資訊平臺」，那交由這些工程技術導向的教授群執行，可能問題也不大，就像企業中的資訊部門所扮演的角色一樣。但是如果這個專案的目標是希望老師們都很願意使用電腦在教學中，同學們也都很願意用電腦來學習，那它就變成是一個「資訊應用」的專案，那麼導入者就應該要多考慮上述的各項管理問題了。專案成員最好也要有使用者代表來共同策劃和執行，才能避免反彈，確保專案成功。使用者參與（user involvement）一向是專案成功的重要因素之一，讓使用者參與除了可以對他們的需求充分掌握之外，更重要的是，參與本身就是凝聚共識的最佳過程。一個專案需要考慮的地方太多，可以說，幾乎沒有一個專案是完美的。使用者事前沒有充分參與，事成之後接手使用，就容易站在檢驗的角度來看結果，多少會比較挑剔。若是自己充分參與其中，即使規劃並非完美，執行仍有疏失，也較能體諒、容忍，共同促成。

成功示範，起死回生。檢視了以上種種問題，「雅典娜」專案進行至此，如果還能彌補或挽救，我認為可以嘗試「縮小範圍，建立成功案例」。任何新科技的推出，總是會有一群先期採納者（early adopter）願意率先使用，當務之急就是要在各科系中找出這一群先驅，並給予他們充足的資源和訓練，讓他們願意支持這個專案。接著再挑選合適的教學應用，包括課程內容和進行方式的訂定等等，協助他們發展對應的教學軟體，並配合適當的獎勵措施，鼓勵他們率先應用這資訊平臺在教學上。

過去有許多企業在推行線上學習計畫時，也常因為同仁對資訊技術的生疏和恐懼，或因為課程內容製作不易、無法及時更新等問題，而讓線上學習的計畫推廣困難重重。後來大家有經驗了，便從比較不會改變的課程內容，如公司簡介、CEO 的理念等課程開始，同時挑選資訊素養較高，資訊應用能力較強的部門開始實施，成效才逐漸彰顯。「雅典娜」專案雖比線上學習專案複雜許多，但是在選擇從「先期採納者」和「適當教學軟體」兩者結合之處開始推廣的觀念上，卻是相通的。一個老師成功，就是代表一個科系成功；一種教學應用成功，就有機會擴展到其他的教學應用。成功案例的推廣，對新興資訊應用的採納，個人認為尤
其有用。