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

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

繼續接續上篇的內容 (上篇可點此 : 選擇專案管理資訊系統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值來挑選。 可是如果只是你自己、甚至三到五人的小團隊要使用,那其實現在市面上有很多免費工具,錢根本是可以省下來的。 像我們就有一堂課是教這類免費工具的,有需要的歡迎參考 :D (103 簡易專案管理工具 (7PDU))

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


簡單易學有時候是兩面刃

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

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

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

講這一串是甚麼意思呢?

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

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

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

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

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

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


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

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

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

Joe G+ ICON Joe LInkin ICON

1 則讀友回應

  1. IT肥蝦 2012-10-27 10:06:25 第 1 則

    版主所言,甚有感受~~~

    說真的~~~~
    每天在弄案子WBS的內容要項就搞不完了!還要填那些專管的資料,真是沒有心思去花時間!

    尤其是軟體開發,也許一下子靈感來了先處理那一段!很多小東西不用循序!很多大東西人又容易反悔,計畫趕不上變化~~~
    這就造成的專案統計上的一個小困難!!!

    人不是機器人,專案不是作塑膠椅的全自動生產線!
    如果有一個專案工具,能把專案所需的資料就綁在專案團隊的WBS要作項目之上,讓每人都簡易上手或不知覺中就作了它,以求得最實質確實的資料!

    在衡量單位上不要拘泥於傳統的時間,人時,成本金額;而是改像TOC理論用更接近實務的衡量單位-如:EV(純用金錢來看進度,但前提是成本可反應事實,但想想看,還是有一點落差)!
    ;但也要相對較容易計算的單位,EV需要的人為資訊似乎有點多,越多的人為輸入,可能就意謂著更多的欺瞞!

    個人覺得,實際資料的取得與正確性,隨著案子的主生產工具是"人"的成分比例,是成反向的!而且不是單一斜率,而是指數狀的!

    • Joe Chang 2012-10-27 11:20:11

      軟體專案雖然需求可能變動
      但我倒覺得工作包下的工作還是可以標準化的
      這或許是起點?

      至於EV的衡量還是有其盲點
      這也需要專案起始規劃很正確才行
      EV比光看要徑難多了,如果PM連長一份Schedule都有問題
      EV應該還離很遠
      因為你會沒有PV

      其實以你案子的屬性,也可以考慮用Scrum的Burndown list的概念?