案例四專家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 。「雅典娜」系統啟動後，預計將在無線通訊工業、證券交易市場和大型服務企業上擁有很高的市場價值。德徒宙教授展望了「雅典娜」的前景：

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

案例三：2009.04.02 課堂討論實況

案例二：〈學得越多、懂得越少〉心得四

組員：陳景威、劉宛婷、王思茜

本周透過網路學習的議題，體會到對問題「根本」的研究。因為學習本來就能透過很多媒介傳達，一切科技、教育都只是選項之一，最終目的仍然是要達到吸收知識的效果。

當我們只看到眼前的問題，執著在問題的本身去強化，到頭來仍舊無法打敗隱含在問題背後的大魔王，忽略掉維修人員其實在處理問題之特色，例如每次遇到的都是新的問題、遇到才有解決之動力的要素，於是課上得越多學的越少的情況就發生了，印證4個學習模式中的實踐模式才是對於維修人員最好的訓練方式，花這麼多努力在線上學習產品能力或培養講師技巧提升，不如增進各地維修技術人員的溝通途徑來的有效，透過微觀的角度與宏觀的解決模式，讓我們小組學習到不同的一課。

此外，對學期的心理歷程、學習模式等教育理論（也很實務），也讓我們大開眼界。

另一個體會是，我們都該盡力擺脫一個虛妄的目標。

以本周個案為例，我們都認為該「有教無類」，讓每個工程師都學會十八般武藝。因此設計的方案不論從哪個角度著手，都旨在激發工程師的學習動機、降低學習的障礙，好讓他們學得更多、更快、更方便。卻疏忽了這樣的配套措施、講師輔導培訓所打造的環境正是工程師們的沈重負荷。

案例三專家1：周龍鴻

形成分享的習慣

「在一股導入知識管理的熱潮下，企業也漸漸意識到，導入知識管理只是一項暫時性的專案。終究，企業得形成員工日常的分享習慣，才能解決最根本的知識議題。」

這個案例所面臨最根本的問題是，知識管理專案尚未完成便失去執行的焦點。事實上，這家個案公司只作了知識管理專案中的變革管理。儘管個案公司成功地導入「探索者」這套知識分享系統，順利地建立分享的文化，公司也盡全力地改善知識內容，並於每週固定舉辦知識分享會議。在一般人眼中看似非常成功的案例，卻不知背後工程師竟會有如此負面的評價，其實我並不感到十分地意外。以我個人在日月光推動知識管理的實務經驗來看，儘管個案公司這些變革的努力相當成功，也普遍獲得工程師的讚許與認同，但這都僅是知識管理專案中的冰山一角，
嚴格說起來，半導體器材公司的知識管理專案只完成三分之一。

讓我從目前所提供的案例，來檢視知識管理部門對「該如何繼續執行知識管理專案？」的爭議。我認為永梅希望加強組織變革、龍嘯天建議繼續強化系統的功能，以及漢斯希望用虛擬社群的方式，進行工程師內隱知識的分享，這三大方向都對，但都尚不足以解決工程師對知識分
享系統的不滿。真正核心的問題是，要將知識管理的概念融入組織的新管理制度。同時，他們也必須結合工程師每日實際的作業流程，才能解決工程師在實務上所碰觸的棘手問題。

因此，我才會說，這個案例中知識管理工作只完成三分之一。知識管理專案要成功必須包含知識管理模式（Knowledge Management Model）、組織管理模式（Management Model）與企業流程模式（Process Model），知識管理才會完整、才算成功。業界許多公司投入大量的資源進行e 化、導入知識分享系統。但嚴格說起來，這只能算是建立知識管理模式。若這些努力未能結合組織管理模式與企業流程模式，儘管這些專案身著美麗的糖衣，終究得步上失敗一途，此章便是一個出師未捷身先死的實際案例。

以我的經驗為例。當時日月光集團正處在變革中，我便順勢把知識管理的活動融入新的組織管理制度中。趁著原本三家企業（日月光、福雷、日月宏）具有相似功能的部門進行整合之際，於人員磨合期便將知識管理的觀念帶入其中。再來，就是當三家企業於2003 年開始推動「TS16949」系統（一套企業作業流程系統），和新部門成立的契機，將知識管理落實於組織的管理制度之中，讓總體組織體質提升，更重要的是，可以加速知識管理的推動並展現其成效。

以下是我的看法與建議。誠如我之前所言，知識管理必須整合知識管理、組織管理與企業流程等三大模式。在日月光我們關心的是：工程師如何藉助BKM （Best Known Method ，最佳實作方法）活動累積我們的核心能力，即知識管理模式？這些BKM 又如何與TS16949 流程串聯，即流程模式？又該如何將這些BKM 與流程納入平日管理的事務當中，即管理模式？

以下是我對這三大模式的說明與看法：
知識管理模式。這是一般企業導入知識管理所最關注的模式，也是最直接與知識產生關聯的模式。許多企業認為導入知識管理系統就是將隱性知識編碼，建立知識庫，以有效的分享外顯知識。或者，企業可以利用知識社群，建立人際網絡，以分享彼此的內隱知識。因此，組織的變革管理顯得格外重要，這包括塑造分享的文化、資訊科技的運用，以及激勵員工樂意分享他們的核心知識等。事實上，以本案為例，永梅、龍嘯天或漢斯的建議都只是強化知識管理模式而已，並不能真正解決工程師所面臨的實際問題。

組織管理模式。成功的知識管理要結合組織日常管理，這包括了員工績效考核與人才培訓。如此一來，知識管理與組織管理兩個模式才會形成所謂的「水幫魚、魚幫水」的綜效。將個人的升遷與知識管理活動連結起來，員工也才會更積極地奉獻出知識，願意花心思去吸收這些內
隱及外顯的知識。

企業流程模式。最後該公司還需將知識管理與流程管理串起來，才能將知識管理融入工程師的實務作業中，而漸漸成為工程師的日常習慣，達到「讓工程師自然地分享知識，卻不知他們正在分享知識」的境界。一方面，工程師依照企業流程，依規範主動執行知識管理的相關活動；另一方面，工程師也可以在組織管理模式的相互影響下，很自然地分享知識。

完善的知識管理必須整合知識管理、組織管理與企業流程三大模式。在知識管理的熱潮下，企業也需意識到，導入知識管理只是暫時性的。終究，企業得讓員工養成分享的習慣，才是解決最根本的知識議題。

案例三專家2：Cao Lin 博士

了解誰掌握知識

「為了挽救這個失敗的專案，半導器材公司的知識管理隊伍必須在知識探勘和回饋管道兩方面有所改善。他們必須了解用戶的需求——特別是現場工程師。現場工程師應該經常參與進來，為下一代Discover 的需求提出建議。」

半導器材公司的團隊在模仿博克門實驗室的K’Netix 知識管理模式時，犯了一些錯誤。他們不了解「探索者」和K’Netix 的本質是不同的，兩個行業（即化學和半導體）也差別很大。首先，在實施專案前，他們似乎未深入研究知識消費者的需求。根據我的經驗，如果你想導入一個重要的項目，首先你必須高度重視使用者的需求。誰是你的使用者？對專案的要求是什麼？很明顯地，知識管理團隊在這方面做得不好，因此知識分享的內容對現場工程師來說是不切實際、也毫不相關，雖然對設備工程師有一些用處。

第二，評估和選拔委員會的成員，似乎在廣度和深度上，都不了解現場工程師的知識。很可能，他們的評審方式無法選出好品質的知識內容。因此，即使現場工程師想回饋知識，這些知識內涵可能超出了委員會成員的知識範圍，導致提案被拒絕，打擊了現場工程師的信心。

第三，「最佳實務」的內容結構過度學術化，對於解決問題卻沒有意義。我認為現場工程師既不可能有耐心，也沒有具備足夠的技巧來寫這種「最佳實務」。要知道，知識消費者並不一定能勝任知識生產者。半導器材公司應該讓工程師用他們擅長的方式來闡述知識，而不是遵循僵化的、標準的形式。

為了挽救這個失敗的專案，半導器材公司的知識管理部必須了解知識消費者的需求——特別是現場工程師。現場工程師應該經常參與，為下一代「探索者」功能提供反饋意見。如此，系統才能夠更符合他們的需求。其次，知識管理部應該指派一個該領域的專家來領導知識內容的審
查，以避免不必要的審查疏失，從而沖淡了現場工程師的熱情。半導器材公司應該在委員會中選拔一位有資格的專家，從而改善「探索者」中知識內容的品質。另外，他們應該告訴現場工程師知識分享的重要性，以及分享知識後帶給他們自己的好處。他們應向現場工程師展示「探索者」的優越性，以吸引更多的現場工程師來使用系統。如此，半導器材公司也能樹立一些成功案例。

最後，知識管理部應該強化「探索者」的內涵，例如分配一些時間給現場工程師去寫出有價值的知識。公司不能期望現場工程師在業餘時間或下班後來寫文章。如果公司只是等工程師「方便的時候」才去貢獻知識，這是絕對行不通的。

案例三專家3：Chan Yong-Hee

知識分享前先要變革

「宣傳知識分享的重要性，主管必須透過培訓、傳播成功故事、獎勵、尊重知識分享者來實現。同時企業也需要在工作職責中加入『知識分享』這一條。這樣做的目的是使員工之間產生互相競爭的壓力，這也是保證企業文化變革成功的重要因素。」

根據我的經驗，知識管理系統成功的關鍵因素在於人。這包括激勵人們參與、執行變革等。知識管理不是只有伺服器、軟體和資料庫，而是獲取、發布和有效利用知識的過程。雖然一套精密的工具能為知識管理系統提供可靠的支援，但是這些工具不是知識產生的驅動力。資料的精確、完整和安全只是一套好的知識管理系統的重要基礎。

知識管理系統還包括變革管理，領導階層應該是變革的驅動者。領導人必須激勵員工，鼓勵員工分享知識。高層管理人員的示範與承諾能夠促使員工參與。持續的關注、回饋都是保證知識專案成功的關鍵因素。文化轉型是建立知識管理系統的成敗關鍵。這比應用新技術和重組新流程更重要。宣傳知識分享的重要性，主管必須透過培訓、傳播成功故事、獎勵、尊重知識分享者來實現。同時企業也需要在工作職責中加入「知識分享」這一條。這樣做的目的是使員工之間產生互相競爭的壓力，這也是保證企業文化變革成功的重要因素。

一個有效的知識管理系統已經成為企業運作的核心。我們是一個全球性公司，知識儲備和跨地域的知識交流非常重要。我認為一個成功的知識管理系統要能為企業帶來利益，這需要有系統的實施方式和大規模的投資。雖然公司內部有專人來推動系統，也必須有外部的專家提出改善意見。企業還需要有特別的專家團隊分析知識財產權的問題。像我們公司在每個區域都有一個技術專家，負責知識的管理工作。對知識管理專案的支持必須是自上而下的，問題要一部分一部分解決，在每個相關步驟都做記錄，而不是把所有問題都放到最後解決。在把工程師隱形知識轉變成顯形知識的過程中，最大的障礙是他們在工作了很久之後，不願意再花時間去記錄這些工作步驟。這個過程需要簡化，把整個維修過程分成階段性的報告。這項記錄工作最好有專家負責，並在最後提供一份終結報告。這樣知識管理才可以縮短工程師的作業時間，但這樣的記錄方式需要有專人來監督負責。

我發現半導器材公司的另一個問題是資訊共用機制（information sharing mechanism）。要使一個知識管理系統有效運作，應該有一個全球統一的資訊共享政策（information sharing policy）。知識也應該按照產品和服務的領域來合理分類，並提供索引。知識管理系統應該有大量的、有價值的內容，並且容易使用。一旦使用者對系統失望，他們一定不再信任「知識管理」這套觀念。

知識管理系統推廣的另一個困難是——知識內容品質與系統的便利性。我們大多數人會使用Google ，是因為它便於使用，而且檢索的結果相關度高。知識系統同樣需要考慮「知識消費者」，並在資料庫的查詢中加入知識消費者經常查詢的問題。資料庫查詢得到的結果必須是使用者需要的、相關度很高的資訊。

因此，半導器材公司需要針對不同的社群去創造知識分享的氛圍。半導器材公司也可以向員工公告知識系統每月的使用頻率與次數等資料。同時，如果半導器材公司要混合採用線上論壇和知識資料庫，我們也必須牢記，現場工程師所面臨的問題是動態的、多變的。我前面提到過，技術變革不應太快，人們總是需要一段時間來適應新技術。

總之，要想實施知識管理系統，我們必須首先考慮人的因素。要充分激勵員工來分享知識，領導階層必須推動變革，鼓勵員工參與，並給與必要的支持。雖然領導階層的承諾對於知識管理會有幫助，但是員工還是或多或少會拒絕分享知識，因為知識分享會與個人的利益產生矛盾。為了解決這種矛盾，公司需要調整獎勵機制，以鼓勵員工分享知識。這個機制能促進員工使用並適應知識管理系統。我認為，這些是知識管理系統成功的關鍵因素。

案例三專家4：Lee Nyen Kong 博士

將知識分解

「企業應該培育一種透過問問題，幫助他人解決問題來提高自身優勢的氛圍。這樣的氛圍可以由展現實際的效益來建立，例如：點出因避免重蹈覆轍而節省的時間。」

當我們談到知識管理時，首要的問題是：什麼是知識？知識不是資訊。我們每天都從討論、會議等管道獲得資訊。但什麼是知識？知識是可以重複利用的、存在於我們決策和學習過程中。知識就是人，組織的知識是存在公司內那些擁有特殊專才的人，是存在某一個領域展現傑出能力的人，他們對於影響組織文化有重要的作用。我認為，知識管理系統要能落實於實際的目標。知識管理除了要做到不斷蒐集、儲存公司中重要的資訊，還要建立一個環境，使人與人的聯繫更順暢，如此創新才出的來。

認識到這一點後，在一年前中央公積金局開始使用知識管理系統。我們建立了一個論壇，但是我們發現最大的挑戰是：如何激勵人們貢獻他們的知識。組織中的成員通常有惰性，可能是因為沒時間把經驗寫下來，可能是因為回憶起來有困難，也可能是不知道如何適當的編輯
資訊。

這些問題恐怕不能透過增加工作人員來解決。多一個人意味著成本的增加，而且你永遠不能確定，增加一個知識部門就能夠有效地記錄知識。員工在建立資訊系統和識別知識來源也會有困難。根本的解決辦法是，讓員工在實際操作流程中獲取知識。事實上，我們的員工已經在日常工作中，養成了儲存和記錄知識的好習慣。透過這種方法，我們能夠很快地找到學習的要點。

用同樣的邏輯來分析這個案例，我認為他們除了要記錄知識之外，還要找到知識。半導器材公司的員工不知道如何把實際經驗轉化為知識。我認為將工程師修理機器的經驗轉化為論壇上的知識分享文章，應該是一個很流暢的過程。工程師可以把操作過程分成多個小步驟，然後根據這些小步驟來記錄他們的操作過程，分享經驗。這樣記錄的過程應該會簡單很多。知識分享既可以使工程師的經驗價值最大化，也可以使他們獲得應得的報酬和認可。

企業應該培育員工學會提問題，並幫助他人解決問題，來提升競爭優勢。這樣的優勢可以由實際效益來展現，例如：衡量因避免重蹈覆轍而節省的時間等。新加坡中央公積金局最初建立了一個知識論壇（knowledge forum），它提供一個資料庫。透過這個論壇，我們把問題和
查詢結果放在這個資料庫。這些資料是顯性知識，可以被反覆運用。我們要注意，科技不能完全解決知識管理的問題。知識管理最大的困難是去改變人的行為。目前知識分享最大的障礙是文化。相比之下，克服技術限制並不重要。技術是用在克服時間和空間上的障礙，避免這些障礙成為限制性因素。引進知識分享系統，員工要先改變工作方式，善用新科技，才能在團隊中形成更有效的溝通。

案例三：〈如果大家都知道〉案情簡介

半導器材公司是一家跨國公司，總部在美國，專門提供生產設備給半導體生產廠，如英代爾、台積電、中蕊、聯電。陳永梅是半導器材公司在臺灣（新竹科學園區）的人力資源經理。最近，在參加了哈佛商學院高階經理人課程後，她對博克門實驗室（Buckman Lab ，一家美國著名的化工原料公司）的知識管理做法很感興趣r 。回到新竹後，永梅正在考慮怎樣把這種方法運用到公司。她組成了一個七人工作小組，成立「知識管理部」，積極導入一套知識庫。這個系統叫Discover（探索者），是為了幫助設備與現場工程師進行知識分享。

雖然永梅宣布系統的第一階段已經實施成功，也贏得了設備工程師的好評。但是，現場維修工程師並不認同這套系統。

一個工程師語帶諷刺地說：

「『探索者』這套系統完全是在浪費我的時間。你知道嗎，我修理的是最先進的設備，學習新機型的時間還不夠呢，怎麼還有時間記錄過去修理機型的經驗。再說，那些『探索者』系統中的評審，他們知道的東西可能早就過時了，比我知道的知識更落後不止三代呢。這些評審又怎麼可能有辦法來審核我提交的知識呢？」

另一位資深工程師則無奈地說：

「『探索者』系統中的『維修竅門』，頂多也只能說明維修問題的一小部分。通常，我們需要考慮到機臺在整個流程上的問題，不斷地和其他工程師溝通，才有可能找到真正故障原因。這有點像急診室裡的情況，我們就像為機器看病的醫生。當一切工作完成後，雖然我很清楚維修的全部過程，但是要叫我寫出這
個過程是很難的。」

永梅很擔心，因為如果現場工程師一直反對的話，總經理張仲彥將會停掉「探索者」專案，並解散「知識管理部」。龍嘯天是來自安德魯的顧問，他從一開始就參與「探索者」開發，該系統結案時還獲得臺灣經濟部頒獎。受永梅之託，他再次前來診斷這套知識管理系統的採納問題。

永梅對他說：
「我實在是無計可施了，我們絕對不可以失敗。部門能否繼續生存就取決於『探索者』系統能否被接受。我們一定要提出具體的成本效益來說服老總。無論如何，你一定要幫我向公司老總證明這套系統是可行的，否則，公司將不會再投入任何資金，也會解散知識管理部。說實在的，我真的不懂，這套系統可是找了第一流的顧問公司進行開發與導入，而且工程師也都參與設計，為什麼他們會不喜歡？」

案例二：〈學得越多、懂得越少〉心得三

第三組 陳湘瑾 徐伊嫻 沈佳穎 張鈞硯 陳治平 郭軒志

本組認為該案例所要重視的是如何讓維修人員能夠兼顧彈性與效率的學習，因此我們提出關於該案例的五大討論議題：

一、語言阻礙，講師授課效果不好，學員吸收差。
二、基礎建設差異，有些國家的網路建設不足，會影響平台進行。
三、實做必要性，維修工作強調實作，接觸學習效果佳。
四、現有授課方式乏味，學員難認真學習。
五、部門合作，建構完整學習組織。

本組希望藉由新的種子講師培訓團，讓他們能夠充分的以當地語言教授，也在平台界面上修改成為視訊模式，簡化管理，使得其不僅有同步功能，也能夠錄影讓建設較差的地區進行非同步教學。而且我們經由種子講師的實作，提供新產品的同步操作影像檔，減少無法實做帶來的困擾。我們並將維修人員以產品線區分的方式來上課，避免人員負荷太重。除了在現有的界面上改善，我們也考量到組織整體的學習提升，讓維修部主導課程內容，培訓部提供講師技巧，企劃建立學習社群，包括KM、新產品SOP說明等。希望藉由以上幾項方式使得人員願意學習，也能學得有效率！

但就本組的意見中，仍無法順利解決讓其他學員實作的部分，造成學員興趣缺缺。同時因為種子講師培訓往返仍太頻繁(新產品三個月有一次)，成本又會再次增加等問題。這塊可能是我們要再思考的，尤其是案例中的學習是屬於情境式學習模式，維修人員需要認知性技能的情況使得案情更複雜。

如同老師所說的，該案例的重點不是在於如何擁抱科技，而是E-LEARNING要怎樣來配合學習模式來進行?若是我們分析案例時未能洞察其真正的徵結點，再多意見也只是隔靴搔癢。因此我們要學習的除了提供意見之外，還要學會如何問問題來找到問題的徵結所在，這樣才能對症下藥，真正成為專家！

案例二：〈學得越多、懂得越少〉心得二

組員: 古佳玉、徐百威、李承陸、吳彥輝、葉思妤

本周的個案：「學得越多，懂得越少」，是有關於學習平台的學習者/講師介面是否有待改進與如何提升學習成效的問題。有鑑於上次個案的學習：解決問題前先釐清背後的問題。因此本小組在一開始討論即從”定義問題下手”。我們認為要解決的問題在於：如何讓維修人員學會維修技能，進而延伸到如何在產品發展階段，利用設計提升以減少後端的維修成本。

在此架構下我們認為應將此學習平台定義為「研發人員、維修人員與講師的共同知識平台」，將各階段遇到的問題藉由此學習平台，將任何人所遇的問題回饋到平台上，以利知識與經驗交流，並降低再犯錯的機率。除了線上學習平台外，再配合維修人員適用的”實踐模式”，透過同步/非同步(由分公司依其基礎設備選擇)的”集體”錄影帶上課方式，下課後再輔以讀書會討論模式，增強學習者的學習動能，並透過知識與心得交流，增加學習成效。而錄影帶除了原先關於基本維修知識外，也建議由總公司成立”教學部門”，透過講師維修技術人員搭配演出的維修教學帶，讓各公司的維修人員都能在可能未碰過實體產品的前提下，而有動態的範本參考。

透過老師與助教再次剖析問題與了解個案實際如何解決方案後，本小組也有些心得與回應。首先我們認為在提出個案前，應該了解學習的內容與學習者的情境與脈絡，確定應透過什麼樣的學習模式，學得什麼樣的技能。利用此分析做為設計基礎，再配合合適的學習過程以達最佳學習方式。而我們也為本次的個案做了檢討：首先本組太低估技術人員可能遇到的問題，由於維修部門遇到的每一個問題都可能是新的，透過經驗的交流是很重要的，因此首先理解維修的脈絡，應該是解決問題的第一步；此外本組也太低估日本公司功能性部門之間的隔閡，譬如由於組織過於僵固，維修與研發可能是沒有辦法協同設計。而本組也認為或許認知上沒效率的方式，可能在實行成效上最好的。例如：把大家聚在一起看錄影帶，要配合眾人時間可能是沒效率且成本更高，相較於自己在自己的位子上看，可能來的方便許多。然而個人透過電腦的學習效率，反而是更低，因此在操作上的便利(個人看電腦便利於集體學習)可能並不代表人情上合理(集體學習的互動性使學習成效較高)。因此本組最後認為：透過虛擬與實體的結合，考慮學習氛圍與學習的脈絡才是最有成效的學習方法。

案例二：〈學得越多、懂得越少〉心得一

組員: 陳維中、吳蔚宗、楊強英、劉芙妤、張駿義

本周的討論題目是「學得愈多，懂得愈少」。

由於對上星期案例-「乏人問津的專家」讓我們學習到要探究問題的根本，所以在一開始面對問題時，本組嘗試著去追綜問題的根源與本質，組員提出了花了大把銀子導入E-learning的學習系統是否為「殺雞焉用牛刀」，卻還是無法使組修人員順利的維修新產品。

但真正造成維修困難的主因是什麼呢?E-learing系統為什麼效果不彰?如何改善呢?這幾個個問題讓本組產生了激烈的討論。組員紛紛提出了各自的見解，「維修問題太複雜了，因為該公司的產品版本各地不一，所以主要零件需要模組化、一致性，才能使維修順利。」「研發人員與技術人員應該建立良好的溝通管道。」；「E-learning系統應該與資料庫做結合。」「加強技術人員的實作。」……

最後，本組認為「學得愈多，懂得愈少」的原因在於E-learning系統的功能只能局限在讓各國的技術人員得到充分的新產品訊息，而這只是技術人員順利得到解決維修問題的其中一塊拼圖，另一塊拼圖則是如何促進技術人員面對問題時發展出適當的解決方案。

面對此問題，本組決定以二個方向進行，一是組織面對維修問題時的變革作法，二是如何改善E-learning系統。

在組織變革方面，首先我們將要求產品品質的上升，並在新上市的市場提供極為優良的保固，如：在六個月的時間內低階商品免費換新、中高階商品先給予替代商品。如此一來，不僅能提升顧客滿意度與購買慾望，更可以為技術人員爭取時間，由真實的維修案例中取得實戰經驗。而E-learning系統方面，我們採行的是集中上課的模式，讓學員們在共同的空間來使用E-learning以提高學生參與度與學習意願，並使學員有著彼此交流實戰經驗的機會。並在學習線上環境中安排一個語言小助教來改善語言不通的問題。

雖然我們已有著E-learning的內容對於維修工作改善有限的反思，但是我們討論出的二個方案仍是有點天馬行空或對於問題改善的成效無法具體評估，如更換產品將面臨了背後龐大的成本問題。

所以當我們思考為何「學得愈多，懂得愈少」，雖然我們可以點出問題的關鍵之處，但是在思考解決方案的過程之中，我們往往卻忘了將維修人員的工作脈絡考量進來，最終局限了討論的內容的發展性。本週我們這組得到的心得在於跳出框架的思考問題之餘，最終還是要回到脈絡中，細細的追查其中蘊含的來龍去脈，在提出解決方案時才可說服於他人。