選擇專案管理資訊系統PMIS時該注意的事 (下)

選擇專案管理資訊系統PMIS時該注意的事 (下)

繼續接續上篇的內容,談另外四個我覺得在選擇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是個複雜的工具,不管在使用上或是規畫上都是很難的一件事。 可是這工具對於一個以專案執行為營收來源的公司而言,卻是非常重要的。 我們自己在這領域雖然有著十數年的導入經驗,至今都還不敢說能完全掌握導入成功的關鍵。 但還好,導入失敗的原因卻非常清楚。 也因此,藉由這三篇把我們的一些心得分享給大家,希望在日後大家做相關決策時,能起到一些些的助益。

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

2 則讀友回應

  1. susan 2013-01-02 14:56:28 第 2 則

    我對第2、4、5點很感同身受啊~而且肥蝦大哥說得很有道理,這麼多的自動化系統反倒讓使用行為變得不自動,這似乎又跟原本要導入的原意有所出入了...

    BTW,其實我是想藉這個機會問Joe,你們何時會再開PMO相關的課程呢?

    • Joe Chang 2013-01-03 11:39:54

      其實問題還是回到原點 : 企業希望管甚麼? 希望達到甚麼目的?
      如果有必要,降低自由度、降低自動度有時候是必要之惡
      如果企業搞不清楚自己要甚麼,只是有功能就用,那自然就不對了~!!

      至於502課程我們暫時沒打算開公開班
      若對於企業專案管理有興趣的,倒是可以先報名503課程
      不過這是小眾課程,何時會湊滿人我們倒不知道 XD

  2. IT肥蝦 2012-12-07 08:46:39 第 1 則

    肥蝦喜歡Joe在開頭的地方說的:為何大家不喜歡看系統!
    就肥蝦的感受,要不是PMIS很複雜!就把它弄得很簡要!

    複雜不是在輸入的資料或運作的邏輯夠多!而是反過來減少了成員在填報時的困擾!比如自動匯入人資部門的出差,休假,員工成長等資訊,可協同配合會計部門的資訊與處理,可納入採購部門的訊息與流程,其他公司資訊系統portal,MIS,...~~~
    這一切的重點在簡化成員與PM人員所要維護的資料,並可有效且確實的反應公司,部門,專案的實際狀況!

    不然就把PMIS弄得簡易些,只就必要的資料進行維護,減輕成員除專案外的工作負擔~~~

    肥蝦常碰到的就是PMIS的進度,工時要寫,會計部門還有另外的timesheet要填,上下班要另外打卡;請假要登入公司的MIS記錄,也要到PMIS在登入記載;專案的相關支出要填部門的採購,會計部門的申報,~~~~
    這麼多的自動化系統的結果就是人變得不自動!