案例四專家2：Leong Chen-Sung

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

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

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

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

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

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

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

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

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

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