案例四：2009.04.09 課堂討論實況

案例四：〈悲傷雅典娜〉心得三

第三組(思茜、佳玉、宛婷、景威 )

在本次的案例裡，我們遇到的是有關教學知識平台導入的問題，和之前的案例有些相像的地方，我們試著不要掉入以往的窠臼，試著用反向思考的方式，想由挖掘真正問題的所在。

本周的心得是即便理解故事的第一層脈絡，脈絡之下仍會有背後的故事。我們目前討論的個案，常常是計畫推行者和方案接受使用者之間的利害衝突。威爾森領導的「雅典娜」推動專案委員會，是以技術為導向，他們相信只要建構出「雅典娜」完整的教學系統，也就是技術面的問題克服了，教授與助教們就會使用這套軟體，甚至會有「百花齊放」的效果。而主要的反對者─教授和助理，則是因為缺少轉化新技術的驅動力和面對升遷等壓力的交互關係，而對系統有所排斥。

有了過往的經驗，每組都試著從使用者的角度來幫助在MIT推展系統。有些小組已開放授權以外部以吸引內部的團結與認同，或是以工學院為「頭」來以論文獎勵的方式導入，大家雖然都很有創意可以似乎都還是會有執行上或是想法上的困難或不足。

我們認為「助教授的職場情境」就是雅典娜沒法在MIT順利推廣的原因。但在進一步思考如何調整「雅典娜」的用途時，雖考慮了不同使用者的需求，我們卻受限於框架：大學課程應該多元、而教授總有自信地獨到見解。

我們都理解助理教授對升等的迫切性，卻走進背後的第二個陷阱，認為升等是需要多方資訊，而忽略了「減低授課時數」這個需求。「思維的框架」讓我們被固有的意識型態限制，也可能是我們對教授或是助理的需求和工作背景比較不熟悉。因此，這周課程告訴我們，除了理解脈絡，也要注意脈絡之後的多重選擇，要理解背後的最重要需求，才能對症下藥。

案例四：〈悲傷雅典娜〉心得二

第四組 葉思妤 吳彥輝 李承陸 徐百威

在這禮拜的科技福爾摩斯課堂中，我們討論的是有關七零年代麻省理工學院(MIT)的工學院希望引進一個名為雅典娜的資訊系統，以求增進整體學院在學術研究以及教學上的聲譽和產出、品質等等的重點項目之表現；這個系統的建置，要求所有學院在一個以C語言為構成基礎的平台上，進行教學軟體的編輯以及學術領域課題的研究，然而各學院在採用雅典娜系統時面臨以下問題：首先，各學院本來就有已經特化過的專用軟體，這些軟體未必是由C語 言構成，但是卻非常福何現在使用並且與業界接軌；第二，重新以軟體語言進行軟體的編輯必須花去很多的時間，而各學院的助理教授們並沒有這麼多的時間進行語 言的編寫，因為他們必須要花時間進行備課，同時面對一個嚴重的眼前壓力－升等的要求；第三，學生們似乎對於在一個內部網路上進行課程和學習興趣缺缺，使用 這個內部網路最大的目的大多是玩遊戲，這樣根本就違背了當初設立這個網絡的本意；第四，這個內部網絡的建立是否真的與學術的增進和教學的增進有關連，似乎 在脈絡的分析或是配適上面並沒有經過一個全盤而切中要點的思考，學術的成績在於論文的被引用數，教學的成績如何衡量？都是尚未確保能被解決的問題。

經過課堂上的討論以後，我們決定根本的捨棄設立這個系統的本意，並且嘗試進行各方利益團體的滿意度的提昇，我們的做法如下：將這個內部網絡分享與其他學術研 究單位，建構更廣域的研究成果分享平台，同時將原本集中在工學院的委員會成員分散下去，讓各學院獲得技術指導，協助他們將課程內容等基本分享內容放上平 台，並不需要特意發展以C語言為構成基礎的

案例四：〈悲傷雅典娜〉心得一

第一組(蔚宗, 維中, 強英, 駿義)

今天討論的個 案是悲傷雅典娜，主要探討的議題是知名大學究竟該如何導入雅典娜系統，好讓各個院所的教授願意使用，並加強其工程方面的領先優勢。本組經過多次的組內廝殺 討論與跟學長姐或是老師討論的結果後，決定回歸最基本面的問題點來討論這次的議題，也就是設法滿足利益團體與院長威爾森的需求。

我們所提出的 做法是針對利益團體與院長的需求，各取所需來提出一套可行的方案，例如從利益團體面來看，教授普遍較可望學術界的地位、名譽或甚至是金錢的追求，因此我們 希望此計畫從各個學院派出一至二位代表邀入計畫內，參與探討、提出需求，藉此各個學院之代表可以於委員會內有充分的地位；另外，計畫代表也可以藉由成功案 例參加產業計畫，擴大於其業界的知名度。相對的，助理教授最大的壓力是升等，也就是以發表論文數量及教學來努力的升等至副教授或終身職教授，因此我們希望 計畫可以提供做研究時所需的軟體，例如建築系教授可能希望有建築3D模擬軟體，以利教學或做研究，減少研發的時間，加快研究速度。學生方面來說，教授應該提供學生最好的學習環境、加強學習效果、提升學生學習時的理解能力與獨立思考，所以學生除了學習知識外，也可利用新軟體的應用（例如建築3D模擬軟體），納入研究並從操縱軟體中，體驗做中學的概念。

依據院長威爾 森的需求，我們希望可以增列人事費用，因為普遍來說，工學院外的其他院系教授對於雅典娜系統應該較不清楚如何使用，所以我們希望編列人事費用來讓教室能聘 請助理來幫忙使用雅典娜系統，減少教授們教學負擔，加快研究速度。另外，可開發各學院所需軟體，依據各學院所需的需求，提供軟體開發、協助與訓練，或是經 由學生來了解如何操作雅典娜系統，協助教授研究上的幫助或是教學上課程的資料建立等等。

經過一番的各組廝殺與辯證，蕙芬學姊整理了所有組的共通點，並點出其他的好方法，例如邀請其他學校一起加入雅典娜系統，建立資料庫, 改變或重組委員會, 了解學術界脈絡等等。接著，蕭老師講解雅典娜系統的未來，雖然還是有使用雅典娜系統，但是工程系委員的委員會席次從70%減少至30%。另外，新的線上OpenCourseWare反 而解決教授們及院長的認知問題，其線上資料庫整合所有全世界的論文發表及其學校之課程資料，這反而創造出一種新的效果，也就是其他學校的教授或這所學校教 授會引用這些課程資料，來減低助理教授備課時間，這反而滿足這所知名學校於學術地位的慾望。最後，蕭老師建議我們當碰到這種科技框架的問題時，要從痛點下 手, 找出切入角度很重要，有時並不是拼命的想解決方法，反而從案件中了解並找出脈絡，從中切入，並有解決之道。

案例四專家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 的理念等課程開始，同時挑選資訊素養較高，資訊應用能力較強的部門開始實施，成效才逐漸彰顯。「雅典娜」專案雖比線上學習專案複雜許多，但是在選擇從「先期採納者」和「適當教學軟體」兩者結合之處開始推廣的觀念上，卻是相通的。一個老師成功，就是代表一個科系成功；一種教學應用成功，就有機會擴展到其他的教學應用。成功案例的推廣，對新興資訊應用的採納，個人認為尤
其有用。

案例四：〈悲傷雅典娜〉案情簡介

「雅典娜」將使學生們進一步了解學術基本原理，使他們超前掌握未來科學家和工程師們將要使用的技術和方法。這項計劃超越了單純的計算，有效地把電腦引進到教育過程中。
——勒門教授（Steven Lerman ，麻省理工學院）

1995 年末，麻省理工學院威爾森（Gerald Wilson）教授感到極大的壓力。因為目前「雅典娜」系統的導入深受技術不穩定性的影響，學校師生普遍感到這項科技將來的收益，遠比不上它所帶來的麻煩。雖然專案小組擔保「雅典娜」是教學上的創新，但學生和教授們都覺得這個系統忽視了教育上的需求。科技導入因此引起劇烈的衝突。

5.2.1 「雅典娜」計畫（Project Athena）之源起（1978 年至1982 年）

「雅典娜」（按：雅典娜為古希臘女神，掌管智慧）是由麻省理工學院的三位教授發起的，分別是威爾森教授（工程學院院長）、摩斯教授（ Joel Moses ， 後來任電腦科學系主任） 和德徒宙教授（ Michael Dertouzos ，後來任電腦實驗室主任）。他們注意到麻省理工學院正在喪失工程方面的領先優勢。他們相信「雅典娜」不僅能讓麻省理工學院重返領先地位，而且能以分散式系統架構吸引銷售商免費贈送電腦（參考圖表5-2）。

「雅典娜」計畫斥資一億美元，耗時八年在麻省理工學院校園內建設一個大型的教學工作站網路8 。它將成為全美最大的教學電腦系統。「雅典娜」能支援一萬名用戶在1300 臺工作站上進行操作，此外還能運行135 臺雷射印表機和80 個檔案伺服器。系統計畫擴展到一萬臺工作站。項目最初的投資者是麻省理工學院、Digital Equipment 公司和IBM 。該系統於1991 年全部移交給麻省理工學院來進行操作和維護。整體而言，技術轉移是很成功的—— X Windows 系統、X Toolkit 和「雅典娜」系統身分認證服務後來都成為產業標準。

「雅典娜」是一套分散式電腦系統——讓麻省理工學院教授能夠透過系統開發科學和工程相關的程式、資料和知識9 。「雅典娜」系統啟動後，預計將在無線通訊工業、證券交易市場和大型服務企業上擁有很高的市場價值。德徒宙教授展望了「雅典娜」的前景：

「麻省理工學院應該在『雅典娜』系統的發展上保持領先地位，並把此技術運用到教育、研究和其他各科學應用。也許對教育來說，電腦最大的作用在於幫助學生進一步理解傳統學習模式。未來電腦在教育領域的發展空間主要是質的改變，而不在於提高效率。」