繼續接續上篇的內容 (上篇可點此 : 選擇專案管理資訊系統PMIS時該注意事情 (上) )

價錢不該是選擇重點

前篇提到管理工具的功能多寡不該是選擇重點，事實上價格也不該是。 CP值是個用來買「個人工具」的思維，但拿到組織環境中就未必正確了。

因為組織選擇管理工具的目的，要考慮的是否能創造資訊整合的價值！ 換言之，管理工具必須要能在多人環境中平順的使用 – 比起功能多寡與價格高低外，符合管理目的、解決關鍵問題、權限設定詳盡、維運成本低、佈署容易、資料統一便利、可輕易與其他系統整合(包含流程整合)、資料安全性、便於分工、系統效能、及數據正確會更重要。

通常昂貴的工具也會是「對企業環境」考量周延的工具，它們在這部份的設計通常會嚴謹而且深入。 這將會省去你後期在資料收集、維護、與導入的時間與金錢；相反的，便宜又大碗的，很可能都有「使用規模」上的限制。

當然，這也涉及是誰出來評選。 使用者單位想的跟管理單位想的是不太一樣的，使用者考量的可能只是我是否方便，但若你是身處PMO或是IT部門，那你除了廣義的功能與價格外，更該仔細考慮這些事情 :

1. 是否有助於規則統一 (這點非常重要。 是否能方便讓某些管理原則標準化，還是可能讓大家有各自為政的機會？ 舉例而言，ID、編碼數量、Issue狀態、資源清單、日曆、文管結構、進版規則、是否能被統一設定？ 還是其實很鬆散，大家都能修改或設定？ 若很鬆散，可能最後每個PM有自己的用法，企業會比不導入系統時更混亂。)
2. 是否可以細膩的調整權限(這會影響導入的容易度、資訊安全度、避免使用者接觸不該觸碰的資訊。)
3. 資料結構是怎麼被保存的 (歷史資料庫是否方便分析？ 比方說，跨專案分析人員工率、平均工期、標準化WBS工作包內容、組合報表製作、待審核的文件狀況、甚至讓日後建立專案時是透過WBS工作包組合拖拉的方式建立？)
4. 資料正確性的問題 (有些工具很便宜，那是因為對於複雜排程、運算、或進度認列上是採取簡單且不符合正統管理原則的方法處理。 甚至有些做法根本不符合專案管理的精神。 萬一你有規範、法規、或合約上的需求要滿足，是否能達到？)
5. 安裝與維護的方便程度 (有沒有可能工具軟體買起來很便宜、但安裝繁瑣，或日後維運很貴？ 比方說要維護多個資料庫、多個Server、在不同的OS上、多個模組、多組帳號，需要常態有人收集資訊等)
6. 資料交換的可能性 (除非你是甲方，不然萬一有需要跟業主資料整合甚至提送時是否方便？ 比方說以工程產業而言，很高比例的業主用P3或P6，如果你公司的內部的系統不一樣，屆時業主要你提送資料時，就變成你得做兩套。 這時候內控外控很可能就脫軌了，PMO也將無法掌握真實資訊。)
7. 使用者介面的便利度 (不同角色是否有合適的操作介面？ 若大家都用同一介面，大家其實會很難上手的。)
8. 有問題誰來支援、可以支援多久 (軟體很便宜、可是有問題時沒人可以協助那怎麼辦？ 或是開發團隊很小，公司又只懂技術，很可能團隊一下就解散了？)
9. 整合的可能性如何 (企業畢竟還有別的系統在運行、有資料雙邊交換的問題。 方便整合嗎？ 若沒有API、最少資料庫的Schema會開放給你嗎？)
10. 管理控制的客觀性如何 (企業經營還面臨舉證與法規符合的要求，工具是否設計夠嚴謹。 資料是否有很多人為修改的空間？ 或最少我可以把某些權限鎖住？)

至於若只是個人要用或是團隊及小，那當然可以純粹從CP值來挑選。 可是如果只是你自己、甚至三到五人的小團隊要使用，那其實現在市面上有很多免費工具，錢根本是可以省下來的。

有人可能也會問，那Open Source的工具呢？ 對，也有很多Open Source的工具，這些工具取得成本幾乎都是0元。 有需要的話，我也可以介紹一些還不壞的Open Source工具給大家 :D。 可是這類工具組織使用起來，看似初始成本極低，可是長期的使用成本恐怕未必合算。 因為除非你的團隊本身在軟體能力上就很強，並有長期維護的人力，不然日後找人調整或改版的成本一樣是很高的。 而且這類工具通常也未必有長期規劃的Roadmap，日後一切都得靠自己來解決。

簡單易學有時候是兩面刃

簡單易學為何是兩面刃呢？ 簡單易學有兩個可能性，一個是介面真的設計完美所以使用者直覺就能使用。 另一個可能性，是因為軟體本身提供的功能有限，所以一下就學完了。 XD

記得之前在Facebook有看到一個漫畫笑話。 說蘋果設計的的軟體只有Press Here這樣一個按鈕，可是你公司的軟體有一堆欄位要填寫、一堆下拉式選單要輸入。 這漫畫主要是要諷刺很多軟體設計的不像蘋果這麼直覺與人性。

我是不知道如果蘋果哪天也來做一個完整的專案管理系統、寫個CRM、ERP、或是PLM，是否可以同樣只有幾個按鈕與滑動選單？ 不過我猜機率很低，畢竟這些系統本來就是用來收集資料、整理資料、以及呈現資料的。 最後的呈現介面或許可以很簡潔，可是如果我們就是要有人填入一堆客戶資料、建立一堆的工作清單，總是要有地方填寫與輸入的吧？ 最終那些欄位跟選單還是跑不掉的…

講這一串是甚麼意思呢？

「簡單易用」與「功能深度」有可能是衝突的(雖然你可以把UI設計好，可是相對而言，功能深度重的軟體複雜度一定較高)。 功能深度重，設定也一定就多，畢竟設定多才能模擬出各類不同的環境變數。 換言之，既然設定複雜，那肯定不會簡單易學。

講的白話些，簡單易學的系統很可能意味著「功能廣而淺」。 這點對中小企業而言、對只管單一專案的PM而言未必是問題；可是若是大型組織要導入全面專案管理系統，這很可能就是問題。 所以簡單易用不一定是問題，只要你確定你的組織只需要廣而淺的功能時，這會是極佳的選擇。

可是另一方面也請注意，我也碰過很多組織，他們受限於目前組織的專案管理成熟度，所以並沒有察覺自己長期而言其實有很多分析是需要的。 若在初期先選擇一個廣而淺，剛好符合目前使用的工具，那後續(這後續有可能很快)有可能會傷腦筋。

所以在這點評估上，請思考一下，若之後組織擴張了、或是PM成熟度提高了，這樣的工具應用是否還符合？ 企業共用的軟體，一旦開始使用，重新轉換的成本非常昂貴。 如果一年兩年後就得把一個容易使用可是「管理助益低」的工具換掉，那其實是很大的一個挑戰。 因為要換成一個管理助益高、嚴謹的工具，那通常表示單一功能的設定會複雜得多。 這套軟體肯定不會太容易使用，這時候第一線使用者的抵抗，就夠你累的了。

隨手舉例，以工作管理的工具而言，容易上手的工具可能只讓你輸入工作名稱、完成日期、誰做、傳檔、加上留言也就沒了。 任何人在20分鐘內就能學會。 可是這樣的工具不能排程、不能分析要徑、不能比對計畫與實際差異、不能根據實際進度分析後面的時程變動、不能分析資源狀況、不能根據資源時間排程、以及還有很多不能做的事情。 但是可以做這類事情的工具，要輸入的資料多，上手也較難。 可說是各有利弊。

當然，並非所有公司都需要詳細的排程與網圖，所以後者的功能未必是你組織最需要的。 可是現階段的不需要，是否代表長期的不需要？ 這點可是評選時你要想清楚的！ 這也是為何我會說，容易上手有可能是優點、但也可能是缺點。

剩下還有幾點，下篇會繼續完成