繼續接續上篇的內容，談另外四個我覺得在選擇PMIS時該注意之處。
(上篇可點此 : 選擇專案管理資訊系統PMIS時該注意事情 (上))
(中篇可點此 : 選擇專案管理資訊系統PMIS時該注意的事 (中))
關於系統自動化通知
這點有可能純粹是我的偏見，但既然要談PMIS，我覺得還是可以說出來給大家參考一下。
我碰到很多人都會希望系統可以自動提醒(如發Email、簡訊給工作到期的人、或設定複雜的條件自動寄Email)，因為他們抱怨PM(或工程師、或主管)不看系統，所以想買套不一樣的系統、並透過別的方式提醒。
可是，我個人一直覺得這不是一個理智的認知。 因為如果你的組織中PM或是工程師「目前」是需要系統「以外」的提醒機制。 這表示發生了下面六件事情的任何一件：
1. PM缺乏規劃的能力 (因此造成系統資料與實際狀態沒有關聯)
2. 組織沒有誘因讓團隊有紀律的做事及規劃。 (大家自然覺得多一事不如少一事)
3. 日常所需的管理功能是目前系統不提供的 (我要管的根本不是系統有的功能)
4. 人員沒有受到足夠的訓練 (不會用、或是明明系統能做但他以為不行)
5. 組織的競爭很強烈，他不願意自己的東西被公開。 (你們公布你們的，我的還是留在自己電腦就好)
6. 組織缺乏好的績效考評機制，所以系統放的僅是一套脫身用的計畫 (反正都會被罵，不到最後關頭，決不放出真實的資料)
也因為有這些狀況，所以系統內的資料當事人可以完全不去看。 可是不看系統，就表示沒有管理嗎？ 通常也不是如此，因為我可以跟你保證，他絕對有一套自己的系統、也肯定自己有保留某些「自我管理機制」在他電腦中。
換言之，如果你不能找出根源問題，並解決這個根源問題，那就算換一個會發Email、會發簡訊、會直接腦波溝通的系統，問題還是不能解決的。 不用系統的還是不用系統。
所以當你發現內部人員不願意使用某個已經存在的系統與流程時，你應該先找出問題在哪裡，而非找一個會發通知的系統來試圖解決問題。 事實上，PMIS應該是要變成專案的資訊總平台；好的PM也應該有習慣使用PMIS做為自我管理的工具。 就類似開車的儀表板一樣，專業駕駛不可能不看儀表板。 換言之，如果組織的主管階層都夠專業，在專案進行中所有參與者自然都該每天打開PMIS來使用與查看的。 你沒聽過有車子會把儀表板資訊發EMAIL出來的吧？ PMIS自然也不應該。
不要急著客製
另一個很多人常急著在，一套軟體連能做甚麼都還不清楚，就開始考量客製海量的新模組了。 除非這新模組完全只是為了強化其資訊呈現(比方說Report or BI)或強化輸入介面而啟動，不然太早做這件事情，將造成導入的困難度。
為何呢？
因為客製模組，表示要花時間做前期的需求訪談。 可是，以我們的經驗來看，大部分想導入新工具的組織，使用者在一開始會「過度高估自己的需求，或是過度精緻化」自己對於管理資料的需要。 若在這階段，就一鼓作氣地把所有認為的需求都開始客製，你有可能永遠都無法上線。
這意思是說，很多一開始的需求常常源自於一個「過度理想化的Use Case」，或這Use Case是一個主管「認為」該做的方式(可是通常根本不是現實的做事方式)。 主管又不是那個跟著後續開發的人，他會把開詳細需求的責任丟給最後的使用者單位。 可是使用者單位又根本不買單主管的想法，最後就是大家花很多時間討論「到底哪個方法較好」，或是揣摩「主管要甚麼」。 加上大部分組織都會覺得，既然還在調整，現在先用一部分好像也很奇怪，不如等都改好再說。
可是隨著客製模組開始後，客製的需求幾乎不會減少，反而常常越來越發散。 這是因為隨著模組開發好後，使用單位與主管的爭議可能才剛好達成某種折衷的共識，所以流程這時有可能又要大翻盤。 或是一些原本想像完美的作法，真正寫出來後發現不切實際。 總之，也是需要大調整。 以至於一年兩年過去了，甚麼真正的功能都沒開始使用，還是一直在討論與改造的過程中打轉。
以我的經驗來看，導入PMIS較好的方式，是規劃可以有長期的視野，可是導入過程中必須逐步加深。 比方說，一套有一百個功能的工具，先使用一到兩個最關鍵的。 或許先讓大家能清楚地列出WBS與工作清單。 等這部分能正確落實了，然後才增加排程的要求，再來要求涵蓋資源規劃。 等到各專案都以相同方式規畫後，才來考慮還有哪裡不足需要微調。 這樣才會讓事情慢慢往前動。 若是希望一次大改，然後一次上線，就可能永遠都不會上線。
自己開發所帶來的靈活性未必是好事
這點很多人可能會很訝異。 為何根據自己的需要量身打造一個系統不一定是好事？
這源自於幾個原因。
1. 自己開發因為彈性太大，所以大家會傾向甚麼都要有。
我自己接觸過很多公司，他們考量自己開發的主要原因，就是因為覺得自己很特別。 (產業特別、流程特別、做事方法特別等) 覺得市面的套裝軟體不能100%符合內部流程，所以想自己重頭寫一套。
寫一套不是問題，會出問題的在於專案管理要成功，重點其實在於流程上通常需要改造，尤其每個部門都得做些妥協，才會讓整體流程最順暢。 可是大部分的公司，這類系統開發案的最高負責人通常運氣不好都是IT部門。 IT部門不可能去決定某個流程該被調整、更不可能決定誰該被調整，只好盡量把所有部門的需求都想辦法透過IT技術來解決。
最後，這極可能是個疊床架屋的做事方法 - 每部門需求都被滿足，可是卻不適合用來管專案的作法。 尤其因為軟體是自家寫的，各部門在需求上很難會願意退讓。 每個山頭都覺得，我部門目前的作法在系統上都要能滿足，不然我就堅持這需求該被放入。
要自我開發也不是不行，只是一定要有一個懂專案管理以及公司經營的高階長官(如公司總經理)「親自」監看、裁決(對，實際上幾乎沒有高階長官想做這種事)，或是你已經有一個不用系統也運作順利的專案型組織，自己開發才符合利益。 不然自己開發，通常只是助長各部門各自為政的基礎，因為當軟體開發完後，各自衝突的流程甚至變成了軟體的一部分，並紮根在組織中了。
套裝軟體這時反而有好處。 以我們的經驗顯示，一套非常符合專案管理程序的工具，有可能跟現行組織的作法大不相同(畢竟現在組織大部分都是功能型結構)。 但因為他是別人寫的，原廠可不會只幫你一間公司改。 大部分組織也就較能接受「每個部門都得稍微調整習慣」這件事。 這反而有可能因為導入系統，而改善流程。
2. 自己開發的導入時間通常較長
如同想要自己客製一堆功能的公司一樣。 想自己開發整套工具的組織，通常野心很大。 使用者在一開始會過度高估自己的需求，或是過度精緻化自己對於管理資料的需要。 若在這階段，沒人來協助收斂，之後就可能讓事情變成不可思議的複雜。 甚至因為一開始設想的太周全、查核機制卡的太嚴密，等到測試上線一用，大家都覺得好像不太對勁。 這時候又要來做些簡化或是鬆綁的動作，可是這類大型系統因為牽連甚廣，一些調整可能又會產生其他的交互影響。
但相較於採取套裝軟體，尤其是已經在大部份產業廣為接受的工具，在整個專案生命週期中該輸入的資訊、彼此的交互影響、參數的設計都已經盡可能的彈性化了。 甚至還有其他一百個你現在用不到，但將來很可能會開始需要的功能。 你要稍微調整使用方式，通常對於整體影響不至於很大，也就有可能在較短的時間內達到穩定的使用方法。
請記得，調整軟體使用方法所花的時間，絕對比調整這套軟體來的快得多。
3. 其實開發的總成本會不可思議的高。
就是因為要完全符合組織現況，你得花很長的時間做需求訪談、需求分析、系統設計等事項。 後續的開發、使用者推翻原來想法、重新調整，都可能在花去極長的時間。 除了開發人力的投入外，這些使用者單位為了配合開發所參與的會議時間、做文件的時間，都是組織投入的成本。
可是，目前的流程是否就是最好的專案管理方式？ 很可能並不是，所以開始使用半年一年後，各部門又提出很多要改的意見。 可是這類意見有可能彼此衝突、有可能需要更多的討論與會議。 所以整個公司為了要「符合現有這個不完美的流程」耗損了大量的人力物力。 更糟糕的是，等到組織成熟度真正提升後，這套系統可能又不能用了，後續改版、調整、不斷的翻版都是大量成本的投入。
可是套裝軟體的好處在於，通常他是已經根據業界行之有年的方法去設計，彈性也都有做保留。 雖然不可能100%符合公司現行的做法，可是只要大家願意摒棄成見，做法上適度修改還是能很快導入。 自己得調整做事方法，可是這其實是好事。 因為這逼著大家改用更好的做事方式，而非讓現有的做事方式更難拔除。
至於採購成本，除非你的組織很小，需求明確確實，流程又已經完善，否則任何套裝軟體以整個使用週期來計算時，幾乎都會比自己開發來的精省。
安全性與權限
這是很多人缺乏概念的地方。 當你採購PMIS時，你除了功能外還要考慮PMIS在權限設定上到底有多大的彈性。 原因在於PMIS會是企業共同使用的平台，所以安全性、管理的便易性、以及不同角色在功能上使用調整度其實非常重要。 一個功能強大的PMIS，可是高階主管卻不會用，那資訊等於還是不透明。 一個單機的PMIS，卻無法滿足組織在專案治理上的需要，那等於也是不及格的。
以我自己的經驗，PMIS的安全性與權限，應該考慮到以下三種需求：
1. 觀看上的權限
2. 操作上的權限
3. 專案治理上的權限
觀看上的權限，指的是是否能把資料做某種程度上的區隔。 比方說高階主管是否能方便查看？ 查看者應該不跟計劃者用同一個介面，也不應該會不小心改到資料。 觀看上面是否可以設定不同的層級？ 比方說有人可以看到專案成本、有人只能看到工作清單。 PMO等單位可以容易看到整合的企業資訊，真有需要則也可以看到專案層級、WBS層級、甚至工作層級的細節。
操作上的權限則指的是否能根據不同的層級決定能做哪些事情。 比方說PM可以做完整的專案規劃，Leader或是外包商可能只能建立WBS以及工作包內的工作，工程師只能回報工時、或是上傳文件等。 有些人可以看到進度、有些人可以看到錢、有些人則完全不能看到錢、有些人可以上傳文件、有些人可以核可文件、有些則只能看到某部分的資訊這類的設定。 甚至公司通常還有很多別的系統，如CRM、ERP、PLM、文管、合約、財務、人資等系統，這些資料進來後，是否能鎖定不讓非授權的人調整與改動？
更重要的，其實是專案治理上的權限。 甚麼是專案治理呢？ 是中央單位(如PMO)是否能簡單的做稽核以及監管。 比方說Baseline是誰在控制？ 進度百分比的回報方式是否能統一？ 成案的流程是否能統一？ 資料是否會透過合宜的審查與控管？ 會不會有人偷改歷史資訊？ 是否方便跨組織的分析資料？ 專案組合的進度是否方便取得？ 專案組合是否能方便看出與組織策略的連動？ 過往專案的工作包能否轉換成標準作業程序甚至WBS層級的樣本？ 策略分析？ 未來的人力與資源預估是否方便進行？ 畢竟專案管理的另一個目的是讓組織不斷的學習與成長，並讓專案的進展能跟組織策略作結合。 這些都能做到，PMO才有價值，企業才能從每次的專案中不斷進不。
結語
PMIS是個複雜的工具，不管在使用上或是規畫上都是很難的一件事。 可是這工具對於一個以專案執行為營收來源的公司而言，卻是非常重要的。 我們自己在這領域雖然有著十數年的導入經驗，至今都還不敢說能完全掌握導入成功的關鍵。 但還好，導入失敗的原因卻非常清楚。 也因此，藉由這三篇把我們的一些心得分享給大家，希望在日後大家做相關決策時，能起到一些些的助益。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
