上周大家擦槍走火，產生出了一串非常美妙的討論。 :D
大家先是從推裡短篇 學姊的祕密：大揭露 開始談起，不知道為何話題轉為軟體開發，又變成需求整合，最後則談到商業流程界定的議題。
我在那段討論後面有聊到，要組織把工作流程定義清楚，很多時候並不是大家想的這麼簡單。 Dauthi兄也有在其後補充，大部分老闆都覺得把流程定義清楚這件事情是不用花時間，甚至以為那些東西已經存在的。 他說，「高階主管 以為資訊萬能，沒有系統作不到的。以為所有單位的SOP作得非常好。」
但實際上那是一種美好的幻想！ 以我自己跟不同公司應對的顧問經驗來看，當你要一個組織(甚至只是幾個人)把日常生活轉換成可用的商業流程(Business Process)時，通常都要花兩到四週以上。 如果那些流程複雜，涉及到一個團隊以上，花上三個月到六個月都還不一定能讓人人認同；更別說要藉此當做程式開發的規則。 (不過平心而論，很多時候並非流程不存在；而是流程沒辦法沉澱的問題。 但那是另一個議題。)
這讓我想到這麼一件事，也是「商業流程與軟體工具」矛盾衝突的一個例子。 很多會來我們部落格的朋友，恐怕有在思考要找尋一個完美的「專案工具」。 剛好這搜尋的基礎假設也常常充滿了需求迷思，所以覺得剛好可以寫出來跟大家分享分享。
--------------
前段時間，我去參加一個研討會。 是關於一套專案管理軟體的介紹。 軟體名稱是甚麼並不重要；重要的，則是主持人談的東西。
主持人在台上口沫橫飛的講著軟體功能，其中一段特別讓我印象深刻。 他提到：「我們這工具，可涵蓋大部份PMBOK的流程喔！ 讓我來秀給你們看！」
接下來，他就談到PMBOK中關於起始專案時，應該有個專案篩選的流程。 然後就開始展示他如何可以在軟體中「提案」並讓老闆可以透過系統直接審核專案。 他先假裝自己是PM登入系統。 選擇「提案」的按鈕，填入專案名稱、輸入目標、填寫負責人、填寫部門、填寫要申請的預算、甚至一些定量的問卷，然後送出。 這時候又用老闆的帳號登入，在線上審核或駁回專案。
聽起來很美妙不是嗎？ 似乎符合PMBOK的精神，還可以減少紙張的浪費，更可以把所有流程都整合到工具中。 真是個完美的PMIS！
但我得說，這是很多人在篩選系統上最常碰到的錯誤。
以我的經驗與認知來說，我們對於PMIS系統關注的重點，絕非是系統有把PMBOK的流程都涵蓋；而是它到底能幫你解決多少「專案上最麻煩」的部分。 我並非說有那些功能不好，但那些往往是Nice to have而非Must to have。 甚至很多時候、無論是提案流程、變更流程、結案流程等，在真實的世界裡若要透過系統來處理，很可能反而讓你更麻煩。
以上面的例子來看。 若待過大公司的人，應會發現提案及審查的功能其實根本是好看但無用的。 甚麼意思？ 意思是，成案的流程，在大部分公司中幾乎都不太可能這麼自動在背後默默發生掉。
首先，提案的人常常並不是PM，很多時候是Salse、是公司高層、甚至是總經理自己。 真正提案前，這案子很可能私下已經運作好一段時間了，走廊上交頭接耳、跟大客戶吃飯斡旋、私下關起門討論成功能賺多少錢等等等等。 等到最後PM知道這案子時，該分析的有可能早分析完了。 換言之，在大部分公司裡，成案常常是個隸屬於PMIS「以外」的流程。 對，它是一個流程，而且也往往是個很重要的流程，只是它常常不歸PM管。
第二個問題，如果是一間重視事前審核或是案件篩選的公司，老闆要的資料其實更多。 財務構面的計算一定會要，但PMIS可不一定支援(或整合)財會資料。 市佔率呢？ 客戶關係的影響呢？ 財務面的風險評估呢？ 非財務面價值呢？ 其他主管的看法呢？ 這些常常都是要花時間面對面溝通、協調、甚至爭論的，很難訂出統一的規範(PS. 規範在此指的是「某種一定成案或一定不成案」的判斷式)。 勉強要在一個套裝軟體裡面做審核，其實最後大家還是會回歸到面對面，不是嗎？
再來，最不可行的一點。 就是「根本沒有」任何總經理會自己上系統去一個一個審合PM的提案，然後在系統上面同意或駁回。 表面聽起來很合理：「大家提案，總經理可以統合一起看，然後可以自己抽空審核或駁回，節省大家開會的時間。」 但這是非常工程師導向的想法，而完全不是管理實務導向的想法。 總經理哪可能同意大家偷偷摸摸在網路上提案然後最後是得他自己來一個一個幫你過濾？ 就算案子讓PM提，老闆也「一定」要你先來面對面跟他報告，說明所有你的考量。 然後才會在會議中裁示Yes or No。
好，有人會說，最少裁示後，總經理可以回去電腦線上簽核嘛，還是可以省下紙張浪費。 但實務上，這一樣不會發生。 因為總經理往往事情很忙，很可能常會忘記按核可。 但既然是電子流程，就表示事情將會因為審核點沒過而卡住不能進行。 最後呢，大家就會想再設計個例外規則，比方說讓總經理的秘書可以代替審核。 可是總經理秘書可能怕負責任，於是她搞不好又設計一個表單要送總經理簽呈。 最後事情不就又回到紙本了？ 電子流程不是反而讓一切更複雜化了？
這就是「流程設計的盲點」了。 電子簽核的原始出發點是甚麼？ 方便，快速，以及自動化。 但若某個流程改成電子簽核後反而讓事情不方便、拖慢執行、或是更不自動時，那這就只是為了電子化而電子化。 反而會創造出比人工處理更高的成本。
前篇討論中，Dauthi說到一段話我覺得很是重點，在此Highlight出來：
若是USER沒SENSE為資訊化而資訊化，明明沒有判斷準則的流程硬要作資訊化，明明人工處理更快... 只會造成以下悲慘的情況 :
1)開發時間冗長
2)程式架構不良
3)沒省到USER時間
4)開發完流程又變了
成案審查的這例子剛好就能符合Dauthi兄所談的內容。
真的，很多時候，流程其實並不需要電子化，也該不急著電子化。 成案流程變成電子化，大家若反而要跟很多例外對抗，那這最後創造的問題絕對比解決問題多更多。
如果這篇有任何主管階層的人有機會看到。 我在此順便建議，老闆永遠該思考：到底如何能讓流程更符合公司目標。 目標變動，流程也該跟著改變；流程若無法確定或是沉澱前，千萬不要去想甚麼「整合性」的系統。
但也別誤會我，我並非說公司不該有系統。 而是主管要思考，軟體要如何務實的使用？ 現有的流程是否已經適合把它轉化成軟體？ 我要再強調一次：專案管理大部分的問題都不是工具問題。 (請參考 你需要PMO嗎? 那篇文章) 而是流程設計、目標界定、以及思維轉換的問題。 (意思是說，做這些事情到底是為了甚麼目的而做。)
就算你開始導入工具，你也不需要立刻大量整合。 流程不明確或是沒共識時，分散的模組往往比大型怪獸來個更妥當。 流程不明確時，投資在流程界定(或是介面切割)的成效通常比投資在軟體上大的多(更比送員工上PMP大的多)。 我自己很多時候的顧問工作都是在試圖幫忙組織把流程收斂、沉澱、並取得共識。 我的經驗是：這些有共識後，導入系統(任何系統)就不會太難；但若流程沒沉澱前，硬要搞系統整合，那通常帶來的危害將大於幫助。 這經驗是希望大家要能記得的啊！
Chris在之前討論中，對此也有提到一個重點：
心中要永遠謹記系統的能與不能，要死守「系統最適合用來解決85%的麻煩事，而不是100%的所有事。解決特例從來就不是軟體的專長」這幾個原則(有尺)。包山包海就是必死。
換言之，若你要增加工具來協助PM，那先想辦法解決他們最感到麻煩的問題就好。 先確保軟體能在成本最低的方式下，解決最多的日常生活問題。 其他錦上添花的事情，如提案審查這件事，花最多工的通常是分析、計算、還有簡報製作。 真要有個工具協助提案，那也該是針對預算製作或是分析決策的系統，而非是電子簽核。 如果軟體不能簡化(或輔助)這些層面的東西，只是讓你把結果Key進去並要老闆上網審查，那就是根本上的本末倒置了。 電子簽核流程是可以等到專案成熟度很高時再來考慮的小細節。
千萬不要迷信「所有PMBOK流程都涵蓋」這樣的訴求。 涵蓋雖然不是壞事，但絕不是你能提升組織成熟度的關鍵。 重要問題不能解決，專案管理就只會流於口號與做官樣文章。 最後，很可能是甚麼成效都無法出現的。
下週，我會整理一下我去年某次演講的資料，想把那次演講的檔案公開出來跟大家分享。 那場演講中，我有談到我這幾年來，以SOFA這間公司為平台所導入PMIS、PMO、以及專案管理成熟度提升等顧問工作的一些做法與成效。
打算做這類事情的朋友，或許屆時可以有所參考。
延伸閱讀
專案管理軟體系統（PMIS）的角色
醫生、建築師、與管理顧問
你需要PMO嗎?
