題目在精，不在多；解答在求打通任脈，而不是背答案。

肥蝦我喜歡回應好友們關於PMP題目的疑問，因為一方面可以助人外，最主要還是能清楚的明白自己的成長，以及PM觀念與邏輯的融會。

但是近來發現一些有趣的地方與自己的觀念，提出來予大家討論與溝通！

最近我週遭的朋友或網友喜歡上網或到處去搜集題目，花了很多的時間在作題目！但對於題目的來源，以及答案的正確性，似有不求甚解的現象。

朋友們作了很多我以前沒作過的題目，但對於他們拿著答錯的問題，或相關聯性的問題來討論之時，最直接回應：「答案就是這麼寫的！」

一聽到這個回應，肥蝦就想到曾在IT邦幫忙看到一些IT人對於PMP不屑的原因之一：就在於台灣把PMP當作考試，而不是知識。

朋友們拿著回答錯的題目來討論，直接開頭就問：「為什麼是這個答案!」肥蝦起初都是一臉茫然，因為如果友人是說：「他這個答案好奇怪，因為我認為...。」我都會非常高興！因為肥蝦可以明瞭不同人對於同一個題目的想法跟思考模式，我一直認為PMI所推出考試的目的不在讓別人通過考試；而在把較佳的專案管理模式與思維推廣到每個人的心中！

肥蝦近來在看唐納德．高斯與傑拉爾德．溫伯格寫的"從需求到設計(Exploring Requirements: Quality Before Design)"一書，書中主要提到如何去正確認知使用者的需求，如何以適當的方法與工具釐清溝通者間的"語意曖昧"。

這就拿一次與我家兩位小孩溝通的狀況。我說：「一杯思樂冰$10，您們買兩杯，那爸爸給您們$50，那7-11的姐姐要找給爸爸多少錢？」大女兒接口說出：「$30！」，但小女兒馬上反口說：「不對，是$0！」看著她們兩個低頭私語地進去7-11，我跟我內人去水果攤買個水果。過了一會出來後兩個異口同聲地說：「那7-11的姐姐找給爸爸$0！」我看著她們手上只有兩杯思樂冰，沒有別的!結果姐姐說：因為(1)那7-11的姐姐給她們$30(2)而她們決定不把$30給爸爸=>所以結論是：「那7-11的姐姐找給爸爸$0！」

這對專案管理來說也是一個好的例子！當我們在專案中不管在作溝通或者需求搜集，常會犯的一個毛病：就是認為對方應該要懂的，或對方應該要舉一反三。其實整個活動的流程是有兩個步驟的，我已經先預設了我的假設(她們拿到錢就會給我)！這個假設不就也是風險所在嗎?

肥蝦當初雖不是以非常高分通過PMP，但我在意的是準備考試的過程！我是否瞭解PMBOK的邏輯，在題目的選擇上儘量是在精不在多！因此我只作課程中老師提供的題目，以及RITA每章後面的題目！

因為我個人對於題目的認知是：「題目在精，不在多；解答在求打通任脈，而不是背答案。」肥蝦是發現一些友人已經可以一瞄到題目的一句話馬上就知道答案的地步，但真正在管理或參與專案之時有所謂的最佳或標準答案嗎?現實的環境不是一道四選一的考題模擬的出來的。

對於自己以往作答錯誤的題目，會將其先記入於控管的EXCEL表格中，然後到PMBOK、或RITA、或網站、或其他參考書籍找資料！至於上網問問題，也會把自己的想法或思考寫出來，希望獲得的解答是弄通我思考的邏輯，而不是要答案然後去記他。
肥蝦舉一個我以前問問題的寫法：
=======================================================================
Question : The product audit should NOT contain:
A.Project baseline and current project status.
B.Audit methodology.
C.Future change recommendations.
D.Corrective actions

正確答案是D
在TT中有明確audit有quality audits(8.2),risk audits(11.6),inspections and audits(12.5),procurement audits(12.6)。其它有帶到audit字眼的有inspection,configuration management system。其中有明確提到有audit of product應該只有configuration management system。但PMBOK中並未明確說明product audit。
個人以為答案A與B是無庸置疑的！所以就C跟D中選擇的話，個人選C。
因為在PMBOK第190頁QA的Recommended corrective actions有提到corrective action is an action that is recommended immediately as a result of quality assurance activities, such as audits and process analysis.
另外對於答案C個人覺得"future"這個字眼似乎不太適當
=======================================================================

現在呢！肥蝦知道答案為什麼是D了！
因為product audit參考的是Approved Corrective actions，決不會是直接就是Corrective actions！產出的也應該是Recommended Corrective actions也不會直接就去執行Corrective actions！

雖然有人以為這題目在玩文字遊戲，但對肥蝦個人而言，我更深的體認到一句俗諺：「不在其位不謀其政。」這句話在專案管理的應用意義！

以往(甚至現在)在參與專案的過程中，常會覺得為什麼那個人那麼差勁！明明事態就是這麼顯明，就是要這樣作，他為什麼不作！然後就越俎代庖。後續上事態的發展，如果作對了！也許長官會稱讚您，但對專案成員的互動上就有了不良的影響！如果作錯了，那就更不用說了！

專案管理的學習是無止境的，PMP的考試只是其中的一個里程碑，重要的是把這所有學到的一切融入個人的工作與生活中，我想這才不會讓人瞧不起PMP這張證照！

肥蝦的專案"瞎"日誌-邊界難定的範圍界定

這幾天心中不斷地思考著要如何去界定WMONEY應用系統的範圍！其實整個專案的範圍界定最麻煩也是最困難的不在範圍的中心地區，而在如何界定範圍的邊界！WMONEY應用系統為自原有產品進行升級，因此基本的交易自是不可免除，也不會招致爭議。但是如何界定邊界就是明確標明排除條款，講明什麼東西是未來系統不提供的，這就非常棘手！

小甜業務多年來實地接觸客戶，難免的會將一些客戶的"wants"想趁此次的升級加入未來的系統之中。而此次計劃可能採用微軟dotNet的新架構，一把刀工程師也是磨刀霍霍，想趁此次一顯身手，對於一些的作法與整體架構提出他的看法。而當初的收集需求產生的requirements documentation，是在阿強機器人與韓舊都的把持之下產生，此次韓舊都病倒送醫至今未醒，小甜業務也希望能回頭修改requirements documentation。但是肥蝦知道此時回頭再翻版可能引起更多的麻煩與誤會，只得跟小甜業務口頭敷衍的說：「因為requirements documentation已送呈給John協理了，現在此刻，如果沒有重大的理由，不太適合再從頭去修改requirements documentation，可否先討論WMONEY的範圍後再來重新檢視！」

今天討論一開始，肥蝦首先表明：「此次範圍界定的會議我們將依據三月二十八日的會議記錄，逐條的對requirements documentation的需求要件討論！」開會的時候先界定一些規則是很重要的，以免會議偏離了主題或落入意氣之爭的窘境。

經過四小時的討論會議，初步的產生了WMONEY的專案範圍說明文件(Project Scope Statement)。在會議的討論中有兩點肥蝦認為可以寫出來分享給大家的。

(一)功能要求－專案範圍的排除(Project Exclusions)

原系統的功能這部份比較沒有爭議，因為基本上都必須保留。另外對於權限的控管與作業流程的方式上，大家也同意以現有方式為基準。最重要的癥結在小甜業務提到了：「我們客戶常常反應我們目前的系統提供的訊息廣播服務沒有提供編、審、放、移除的權限管理功能，只能單純的把訊息與發佈對象或群組打上去，不符合客戶現有的內控規章，因此希望把權限控管與作業流程功能加入訊息廣播服務。」馬上阿強機器人就提出異議：「我們是交易作業系統(TPS)耶！如果客戶需要這個服務應該去買另外的系統嘛！」其實肥蝦也是限入兩難的境地！因為訊息廣播的功能服務是現有的，可是要作到訊息廣播的作業流程管，可不是如此容易地！加以目前的權限管控是以交易為基礎，並不會再根據交易的內容分類進行管控；而且以肥蝦先前的經驗，這部份將來會因為每個客戶內部作業規章的不同會有不同的修改。因此肥蝦趕緊出面說：「我們在此次的會議記錄先寫下小甜業務的提議，因為正如阿強機器人所說的我們是交易作業系統，因為我們可能要採用新的架構，升級原有的功能服務的風險已經很大了，而且我們採用的是開放的系統架構，也許將來可以開發新的模組的達成小甜業務的建議，但是此次我建議先不考慮在這一次的專案範圍內。」

在PMBOK的Project Scope Statement要項內有特別標明需要列出Project Exclusions，這一部份在如上述"wants"是處於模糊地帶時是非常困難界定的，這就要憑藉一些經驗與知識進行判斷了！

(二)連結資料庫的方式與那個資料庫比較好？－選擇方案的確認(Alternative Identification與Project Assumptions)。

因為原有系統會連結微軟資料庫(MS SQL)，小甜業務說：「微軟的資料庫要成本，有時後客戶會希望我們用自由軟體如MySQL，以減低報價。」阿強機器人可是微軟的擁護派，馬上接著反對：「MySQL如果發生問題怎麼辦？而且用MS SQL已經那麼久了現有的functions都是現成的，不應該換成MySQL。」沒想到平常冷若冰霜、沉默不語的一把刀工程師突然說話：「聽說微軟現在有一種LINQ的技術，可以作到更換不同的資料庫只要變更設定並不需要修改原有程式與語法。」肥蝦心中歡喜著：「我想小甜業務與一把刀工程師所說的，也許我們可以先把它當成此次專案假設(Project Assumptions)，但我想首先要去釐清LINQ的確實功能，如果LINQ真得work那我們就可以不管資料庫的種類了！不過這部份可否請一把刀再去詳細瞭解，我們就先列在專案範圍文件內。

其實很多時後一些選擇方案的採行與專案的假設有緊密的關聯。我們會選擇特定的一個方案通常是基於某些認知或假設，一旦我們選擇了該方案，就應特別列註其所使用的認知或假設，以便去檢測，管理專案的風險。

會議之後，肥蝦得專心整理一下會議記錄，並寫出WMONEY應用系統專案範圍文件。以便進行分割與定義工作包(Work Package)的討論了！

看醫生我會怕！－專案的風險回應與品質控管

最近一年來，發現自己的命盤與木柵x芳醫院與台北xx大學出來的醫生不合，使得我對臺灣的醫療品質有些擔心。自從去年十月輸尿管結石被x芳醫院弄到病假一個半月；日前又因為二月於木柵x牙醫診所特聘x芳醫院的醫生補牙，結果發現所補的牙齒，在把原補的地方打開後內部腐爛了，只得作根管治療。因此個人已徹底失去對台北xx大學的教學與醫療品質的信心，如有友人欲至木柵x芳醫院就診，莫不懇切的忠告個人的案例，希望友人能重新思考。

記得去年在北市衛生局與x芳醫院暨醫師公會的代表調解爭議時，醫師公會的代表醫師所說的一句話：「輸尿管結石手術重點在排除腎的積水，而不是輸尿管毀損；因為輸尿管因手術難免損傷，所以我們會放置雙J導管。」而我的情況是因為輸尿管結石手術後的輸尿管毀損，導致體內感染，因此不禁懷疑台灣的醫學教育不會學習品質管理嗎?還是台灣現在交出來的醫生已忘記病人求醫的目的，在學七年只是一味的記憶跟背誦標準醫療程序(SOP)。

我以為我可用一例來說明我的輸尿管結石的醫療問題。

就像我們執行一個工程專案，依據客戶的需求，擬定專案的目標、工作範圍與風險應對…。

(一)目標：為保障附近居民的安全，防範因為堰塞湖的阻塞，再後續的河水繼續灌注下溢流崩毀。

(二)專案工作項目是：移除阻塞，恢復河水的順暢，將河水導引回原有的河道。

(三)風險疏緩計劃：在專案的計劃時，因為考量執行過程中，可能因為工程影響原有河道毀損，導致堰塞湖的湖水氾流至附近民宅，所以擬定的風險疏緩計劃為加高河道兩側的堤防。

不幸的，因為堤防工程有損兩旁的國家景觀無法施行，但堰塞湖阻塞移除工程還是繼續進行，結果就導致湖水灌入河道附近的民宅。

從上例個人所舉的案例中這個工程專案的執行是否成功?我想大部份人都會同意該專案是失敗的。原因何在？

因為專案管理理論(如：PMBOK第十一章的風險回應計劃)告訴我們：當主要(primary)的風險回應策略無法奏效或無法實行之時，應立刻更換為備援(backup)的風險回應計劃，補救(fallback)計劃或者是Workaround。

當我的主治醫生發現我的雙J導管引起輸尿管動脈微血管出血，移除雙J導管之時，就像例子中的堤防工程無法建置。就個人專案的經驗，如果遇到此等問題之時，而且預估河道好似可以胃納湖水的排放，那所採取的策略應該是隨時緊密觀測原有河道的排放湖水狀況，並設置警示高度，並準備好相關的補救(fallback)計劃或者是Workaround。再就品質保證的角度(如：PMBOK第八章的品質保證)，當發現專案的程序不適用特定的專案之時，並不進行流程改善計劃，執意以以往的經驗一意孤行，結果無法滿足客戶的期望與需求。

再來就我個人就醫的最大期望與需求是恢復身體健康，而不僅是把結石拿掉而已。就如同例子中的工程專案原目標是保障附近居民的安全；而手段(專案工作項目)是移除阻塞，恢復河水的順暢。而工程的實行確是導"果"為"因"，變成以完成手段為首要目標。結果導致河道附近居民身家損害，因此客戶的期望與需求均未達成。

再拿我所補牙的狀況，我要去診所補牙，是希望解除疼痛，且牙齒的形狀以人工材料復原。因此正常的專案流程應該是先把設法原有牙齒內的疼痛病源與污染移除，再行以人工材料回復牙齒的形狀。但該名醫生可能因為專業的經驗與知識，作業執行上缺乏品質控管的應有程序，並未將原有污染移除乾淨，就以人工材料覆蓋其上；或者缺乏應有的專業道德，稍微清除後，就以人工材料復原，給客戶一個表面上的合格的交付物。後續上，客戶在使用交付物，卻引發衍生出更大的災禍。

個人以為就專案的定義來說(臨時性與獨特性)，雖然輸尿管結石手術與牙齒補牙的作業程序都是一樣的，但是每個病人的身心都是獨特的，就向蓋大廈一樣，每個病人的每次醫療診治，都可視為是一個專案。醫生應具備專案管理的思維去進行醫療行為，而不是把醫療視為一個日常重覆性的作業。

醫療關係建立在病人對醫生的信賴度上，也就像執行專案時甲方對乙方的信任是專案成功最重要的基石。如果現在與未來的醫生不能有如像專案管理師一樣的思維，可預見醫療糾紛勢將層出不窮，臺灣的醫療品質將日落江河。

「2009台灣軟體品質與資訊安全研討會」與會後心得感想

本月二十三日與二十四日，筆者自費參加中華民國軟體品質協會所舉辦的「2009台灣軟體品質與資訊安全研討會－採購者與供應者實證經驗分享」，全場共有三十五場的講題，主要區分為流程改善、資訊安全、軟體工程實作經驗與工具。筆者因為二十四日下午另有公事不克參加外，其他時間共參與了九場演講，有幸聆聽先進們的教誨與經驗分享。

這一天半的參與下來，除了由學術單位的教授所講授的內容外，筆者所聽到的均是言必稱CMMI，感覺比較像是CMMI的推銷說明會，而且講課的企業似乎都是特定公司的客戶，其中雖也有IT界的前輩講說精彩，但感覺上無法與胡理事長所稱的：「想建立一個資訊交流平台的願景。」其間似乎落差過大。

個人決無意批評或是挑戰CMMI，IT軟體業導入一個合理且國際化的標準，絕對是有益而無害，但若是太過一家之言，似乎有些遺憾。

個人參與的場次計有：
(1)從ROI談資安技術佈局：臺灣科技大學 吳宗成教授。
(2)政府採購作業發展策略：研考會 簡宏偉高級分析師。
(3)資訊安全管理新思維與新趨勢：中央警察大學 林宜隆教授。
(4)資訊安全管理系統（ISMS）標準化之回顧與前瞻：樊國楨教授。
(5)凌群電腦經驗分享-創造雙贏的軟體專案管理：凌群 陳奇民產品經理。
(6)CMMI-ACQ與政府採購法的整合：寶發 胡詠晴顧問。
(7)精誠資訊- FFPA 軟體規模估算經驗分享：精誠 李克精協理。
(8)協助企業導入CMMI之組織流程改善及度量分析工具：鼎升 劉立堯副總經理。
(9)知識管控解決方案：鈺新 黃鈺峰總經理。

其中個人比較欣賞吳宗成教授、林宜隆教授、李克精協理與劉立堯副總經理四位講師的內容與態度。由於一場次只有短短的四十分鐘，內容上也僅能略為介紹，無法深入討論，殊為遺憾！

至於其他場次的內容，個人有一些淺見：
(1)簡宏偉高級分析師可說是第一天的風雲人物，為人親和，且有多年中央政府二級單位的經驗。但個人自以為是的以自己四年立委助理經驗建議：「簡先生在撰擬國家的資訊採購政策時，應多去基層與不同的單位走走，實地瞭解像鄉鎮公所與中小學校的資訊採購與後續維護作業的困境。」

【資訊採購二級化】雖是立意良善，期望藉由擴大政府資訊標案的金額，讓資訊軟體廠商能進一步壯大。但個人愚昧地以為政府的資訊專案應予分級，中央單位是可以以二級化為思考主軸，地方政府則建議以縣市為單位，國營企業則以機構主體自行規劃為宜。

考量臺灣獨有的文化與軟體產業的架構，應可建立軟體產業縱深的結構，再經由層級間的合縱連橫，利用層級間的競爭與合作不斷的注入新活水。在國際競爭上，以工業局所推導的旗艦船隊模式，擴展一些未開發或開發中國家的海外市場(資訊發展低或類同於台灣的地區)，藉由海外資金的溢注，協助國內軟體產業的發展，以跟上先進國家的標準與規模。

台灣的資源有限，無法全面俱到，但我們的發展主軸為何？則可進一步思考！軟體產業不似硬體廠商，創意與規模經濟之間應作不一樣的思考。個人以為台灣IT軟體產業未來要走的道路不在系統軟體，而在應用軟體。

(2)樊國楨教授的學識涵養豐厚，見解獨到，對於資訊安全標準更是國內第一把好手。但個人竊竊以為您光憑資訊安全的議題，就認為國內廠商發展沒有遠見，國內IT軟體業者無法承接到銀行核心系統的專案是罪有應得，個人以為實在太過偏頗！

俗諺云：「殺頭生意有人作，賠錢生意沒人作。」就光以您所口口稱：「Master卡前次來台主辦的credit card議題，無IT軟體廠商參加」為例，個人以為是您不瞭解credit card的軟體產業結構。台灣credit card的主體是銀行與聯合信用卡中心，台灣的IT軟體廠商只不過是賺賺寫程式或導入國外系統的血汗錢罷了。IT軟體廠商投資再無法預期可獲得報酬的情況下去，進行投資或參與，就產業而言，是違反公司法第一條：「以營利為目的」！

其次，再以您所稱：罪有應得的，因為資安資訊能力不夠，活該接不到國內銀行核心系統的案子為例！後進不當的發言說：「若一家IT軟體廠商給您一千萬，您能協助拿到專案，並開發完成銀行核心系統的資訊安全的部份嗎?」

另外對於協會所舉辦的目的與程序，個人有些建議可供為下次會議主辦的參考：
(1)會議的主軸：個人以為此次會議如要扮演採購者與供應者間的溝通橋樑，則可依據採購者的角色進行區分。感覺上此次的某些場次主要聽講的對象應該是政府單位，如：「CMMI-ACQ與政府採購法的整合」。因此協會應請求政府單位多派員參與！如果是廠商的經驗分享，同一個議題應由多家不同規模與市場定位的廠商發表經驗分享；如果是學產間的交流，則應以會談的方式舉行，而不是學術界單方指導業界要如何發展！並可能的鼓勵【由學者提出理論思考，再由企業加以商品化】的合作模式。

(2)會議的流程：本次研討會的重點在【品質】，整場卻看不到有品質管控的作業或程序，最簡單的如：【滿意度調查問卷】，一天半下來也看不到一張。

(3)整個會場與會的長官、學者，雖口口稱是產官學，但個人實際的感受是學官產，因此感到不免有點悲哀！

以上是個人小小的心得感想，套句樊國楨教授的名言：「如有得罪，還請多多海涵！」

在職碩士班面試感想-"到底什麼是在職碩班的目的?"

上週日，肥蝦跑去世新資管系面試在職碩士班！在面對四位老師的目光下，肥蝦表現的不盡如意，也回答的太直接了！面試的過程如下：

(1)自我介紹三分鐘！

(2)為什麼報考世新？

(3)研讀計劃？

(4)研究方向？

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？

我答得有點渾渾噩噩，最近的腦袋已經完全被WMONEY系統的開發給佔據了，根本無法想些有得沒得，應付面試官。我是據實回答以上的問題，內容摘要如下：

(1)自我介紹三分鐘！：經濟碩士，銀行資訊軟體產業十年。

(2)為什麼報考世新？：離家近，之前參與一個案子有間接跟 貴系老師合作過。

(3)研讀計劃？：物件導向分析設計、資訊安全、資料探戡與應用、系統資源規劃整合。

(4)研究方向？：系統資源規劃整合，銀行系統繁多，一般銀行欠缺整合的資源規劃。

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？坊間訓練機構課程已不符所需。

面試官對於肥蝦報考世新的理由最感詫異，也覺得好笑。沒錯啦！我是該亂編一些理由說世新有多好、多好。可是說實在的，除了那位之前間接合作過的世新老師外，先前我帶過世新資管畢業的，只有給我"釘"的印象。真正的問題點是："世新"碩士文憑對我來說又有何意義！我要的是實質的學習收獲！

我要的不是一張文憑(何況我已經有一個國立大學的碩士文憑了)！我要的是加深我理論的基礎跟應用的擴展。外間的一般課程已無法滿足我的需要，肥蝦已經脫離coding或實際設定的階段。在進行系統分析、設計，或專案管理上，我需要的是更進一步的紮實基礎與全面的觀點。問題是這一部份不是一般坊間訓練課程的重點了！記得去年報名的PHP認證班與SECURITY+認證班，只有SECURITY+的老師讓我覺得值回報名價。

也許就像我同事跟我說的：「你怎麼知道在職碩班的課程能符合需求？」但我總得試一試！我希望能從別人的經驗學習所花費的成本，去抵減自己經歷所耗費的時間。

不管此次面試的結果如何？肥蝦追求成長的心態是不會變的！給自己加油！

您賣(買)的是一個"package"?還是"solution"?

上週約了兩位經研所同學在桂林路的家樂福吃個飯，並聊一聊互相的近況。以大家現在工作的年資，都大約是中低階主管的資歷了，最是勞心勞力的一群，每天面對著繁瑣的工作，總會讓人感到心力憔悴。

其中一位同學現任職於xx壽險的放款科長，他知道我在IT軟體產業，他問我一個問題：「一年計息天數基礎(Days in year)為什麼系統不可以提供給使用者參數的型態，讓使用者自行決定，為什麼一定是360？印度的顧問竟敢要求我們修改作業規則去適應他們的系統，這可不是內部的作業規則，而是金管會的規定，放款的計息天數基礎是365。」

我想很多人的第一反應就是那個系統太爛，設計不良！但我不是如此思考！因為該外商的產品可是已經行銷好幾國，問題真正癥結點是出在當初合約的規範！當初xx壽險招標之時他所設定的想法：「他要買的是一個"package"?還是"solution"?」若是xx壽險所要的僅是一個套裝軟體，而且合約或Request for Proposal(建議書徵求書上)未明載計息天數基礎的需求。沒錯，就如那位印度顧問所言：「這是客戶的問題，要求客戶自己處理。」但如果xx壽險當初所要的是一個解決方案，而且合約已有載明系統必須能提供計息天數基礎的參數設定，那這問題就回歸到廠商的身上。

一般人或許以為這個修改很單純，不過改一下數字嗎？但在金融應用軟體上，基層參數與架構的修改可是牽一髮動全身喔！有些金融應用軟體是每日計息，有些是每月計息；計息天數基礎參數有的是所有產品別一體適用，有的是根據產品類別，有的是根據每一契約。這還牽涉到提前還款，解約，逾期…等不同的繳款狀態；而繳款的方式不同－現金臨櫃、便利商店繳款、支票繳納…－也會造成影響。因此這可不是改一個數字就好了的簡單想法。

個人近來忙於北部一家地方性金融機構的建議案，此次我們所提供的是一個解決方案"solution"。本案中我們除了包括一部份系統外，更擔任了系統整合商的角色。在合作的五家廠商中有的是提供套裝元件，有的是需要提供客製化修改，因此專案管理的責任跟風險就在系統整合商的身上。

日前聽說：「永豐銀行已簽約更換現有的Unisys銀行核心系統為Temenos系統。全程以英文為溝通的語言，而且以現有Temenos系統的功能為交付的功能，不進行修改。」若真得如此！則整體風險將在客戶的身上，廠商其實就只有安裝跟協助使用。

從以上的例子，我的客戶要的是一個"solution"；而永豐銀行要的僅是一個"package"。這其中的價格差異可是很大的！屆時永豐銀行在無法更改"package"下，勢必要修正一些作業規則，或者自行在"package"外面加以包裝，以符合實際的需求。

個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。但因為台灣的競爭激烈，業務們當成"solution"去賣，以致後續可能必須以非IT的能力去結案。這個就是一個非常大的盲點：「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。

MBA乎？PMP乎？-兩種管理"專業人材"之我見

就業市場一度上紛紛擾擾，很多人在討論企業管理與專案管理孰重孰輕？就筆者自己的觀點：拋開商業利益的糾葛，其實兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

一般我們都將企業管理概分為：產(生產)、銷(行銷)、人(組織)、發(研發)、財(財務)，現在很多人又把資訊管理列入；而專案管理則區分為：九大領域：整合、範圍、時間、成本、品質、人力資源、溝通、風險、外購，以及五大程序：起始、規劃、執行、監視與控制、結束。

其間的異同何在? 其實這是一個很大的議題，筆者僅能以自己觀點管中窺天，分享自己的看法。
筆者試著從架構面、功能面、執行面來說明為何兩者間無法切割與區分的原因；最後則試舉一例加以說明。

(一)性質面
(1)長度(時間性)：企業強調的是永續經營；專案追求一定時間內完成。

(2)廣度(全面性)：企業管理的目的是追求企業在不確定的環境中追求成長茁壯；專案管理是要求因應不確定內外環境，追求明確的目標。

(3)深度(周密性)：企業管理首要是確立企業使命，設定企業目標，發展策略，擬定戰略；專案管理是在達成目標的基礎上，遵從戰略的指導，因地制宜的擬定執行計劃。

(4)精確(驗證性)：企業使命一般是無法衡量的，目標與策略的驗證一般可能為廣泛性的數字指標，如：營業額、市佔率、稅前(後)純益、獲利率、股東報酬率…。戰略與計劃則應有非常明確的指標，如：客人流動率、坪效、到訪率、實獲值…。

(二)功能面：
就個人對企業管理的初淺知織，針對企業永續經營的目的作了如下的企業思考與行動的功能結構層級。
(1)使命(Mission)：企業在全球社會中所要扮演的角色。

(2)目標(Target)：企業在使命的驅使下，所要達到的預期成果，可再細分為短、中、長期目標。

(3)策略(Strategy)：為達成目標，因應內外環境的限制與挑戰，整合內外部資源，所訂定的認知地圖。

(4)戰術(Tactic)：在認知地圖的引領下，取得局部領域優勢的可實行方案。

(5)作業計劃(Executive Plan)：執行特定方案的細部執行步驟。

(6)作業程序(Executive Procedure)：執行日常經營活動的執行步驟。

針對已上的企業經營思考與行動的層級，專案的定義在那裏呢？
根據PMBOK 2008對專案的定義：臨時性的(Temporary)，產出獨特產品、服務、或結果(Unique product, service, or result)。因此一般將專案鎖定在作業計劃(Executive Plan)的層級。

但讀者若跳脫臨時性的(Temporary)的特定跼限，以PMBOK對臨時性的(Temporary)的定義：明確的起始與結束時間(definite beginning and end) 則依據結構中對目標的說明，如企業能進一步把短、中、長期明確界定期間(如：一年、五年、十年)，在明確的期間，達成特定目標，這不就是專案的定義嗎？因此在PMBOK 2008的第八頁圖1-1Protfolio, Program, and Project Management Interactions 所表示的三個層級不就正好對應的策略(Strategy) 、戰術(Tactic) 與作業計劃(Executive Plan) 。

(三)執行面
企業管理有六個面向(領域)－生產管理、行銷、組織管理、研發、財務管理、資訊管理；在專案的九大領域中的整合與外購不是就要生產產出，與購入生產過程中需要的產品、服務、或結果，這不是跟生產管理的部分理論雷同。因此筆者依據專案九大領域，排列了一個需要應用到企管六大領域專業知識的對應表。
(1)整合：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(2)範圍：生產管理、行銷、資訊管理。
(3)時間：生產管理、資訊管理。
(4)成本：生產管理、財務管理、資訊管理。
(5)品質：生產管理、資訊管理。
(6)人力資源：組織管理。
(7)溝通：行銷、組織管理。
(8)風險：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(9)外購：生產管理、財務管理。
因此一個專案的執行，需要仰賴企管六大領域相關的執行理論與技能。

(四)舉例
ABC有機食品商，立志成為社會中每個家庭的安全、健康的補給站(使命)，因此立定了為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」因此總經理擬定了行銷策略與生產策略。在戰術上可能選定人口八十萬以上的都會區為集中戰場，利用宅配與網路的通路，以達到市佔率30%；為強化產品優勢，可能希望建置中央供應站或中央廚房，提供五十樣以上的天然食品。
同樣地我們也可將為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」設為一個專案許可證(Project Charter) ，進行一個大型專案(或可稱為Portfolio)－臨時性(為期三年)，獨特結果(提供50種天然食品，給1萬個家庭)。