PMO的目標與願景

這篇也是原本於公司內部貼出的宣導文章。

 

前篇提到一般PMO的常見目標。 包含「監管專案」、「協調資源」、「統一做法」、「保存經驗」、「開案評估」、「稽核內控」、與「訓練人員」等目的。簡單的講,就是希望透過這些面向的統一規劃來提升整個組織的「專案成熟度」及確保專案順利下能帶給公司營運的成功。

雖然專案管理的概念本身是跨產業的,但在不同產業型態中,關注的管理重心還是有些不同。 比方說,工程營造或國防產業會較在意進度與合約,資源重視材料,但人力投入的統計常相對而言較不重要;但軟體業或是我們這種人力為導向的產業,則會較在意人力盤點、利用率、工時、流程改善或是經驗學習等。所以不同組織的PMO,期專注的重點也會不同。

以我們集團而言,我從2006年底開始一路以來定義PMO的核心目標是下面幾項:

  • 專案管理成熟度提升 Project Management
    方法與知識 Methodology
    時間與花費追蹤 Time and Expense Tracking
    變異分析 Variance Management
    資源管理 Resource Management
  • 製程提升 Process Improvement
    查核監控
    標準化
  • 知識管理 Knowledge Management
  • 專案組合管理 Portfolio Management
  • 預備專案之規劃 Backlog Management

大部分都是些需要長期深耕的目標,有幾項甚至在三年後的今天都還稱不上有芽萌出來,另一些項目也恐怕還會在往後的過程中逐步調整。總之,這五個面向的細節我會在接下來的幾篇中慢慢來說明。 這篇要跟大家分享的,會是要達成這些目標下的一些中程方向。

比方說,接下來一兩年的中程方向會是類似下圖的這些事情:
EMO PMO的組織目標

當然,我暫時Focus的重點還是會以SOFA為主。 畢竟影片的製作是非常典型專案導向的工作,加上SOFA人力資源較多,所以在如何提高人員利用率、增加工作效率、統一流程、及提高專案透明度,是管理需求上最為具體的單位。也因此,上圖大部份的重點,都是以SOFA為主的考量。

上面這張圖若快速瀏覽一遍,除了大家應該至今已多少都理解的「流程繼續改善」、「知識管理」、或「人員培育」等持續進行的活動外,今明兩年最重要的目標恐怕是「整合管理工具」的開發這項事情上。


所謂「整合管理工具」是甚麼呢?

這指的是一個要以「專案流程」為導向來統一設計與開發的「軟體管理工具」。 目標是希望把流程上的所有瓶頸或是縫隙盡量的加以填補。而縫隙指的是下面這兩樣東西:

1. 資訊
2. 產出物

一般來說,如果流程設計不良(或是工具太分散),這些東西在製作過程中可能會因傳遞不順而遺漏在流程的縫隙中。 這樣會造成該收到的人沒收到,或是需要的人找不到。

以「資訊」而言,目前我們有很多管理工具如Outlook、P6、如Wiki、如Issue Traker或是記錄各項工作相關訊息的表單,比方說Cutlist、Item List、請假訊息、專案變動與調整、會議記錄等。 但隨著工具增加、工具長相用法都不同,光是介面學習對很多人來說就很傷腦筋了。此外,各平台跟平台之間是毫無溝通與聯繫的,在Cutlist紀錄的東西,別的工具無法看到,退修或是下一個該接手的人也不會主動收到通知。尤其常因為資料不相通,管理單位還得花很多時間對照表單、把同一訊息在多個系統中搬移。 東西做完了沒有? 存在哪裡? 檔案要到哪裡找? 何時要開會? 會議有甚麼結論?這都無法簡單的讓大家察知,也就造成了時間浪費、無效率、混亂、爭執、甚至得多花時間與人力做整理。

「產出物」傳遞也是類似的情況。 Alienbrain是目前我們版本控制(Configuration Management)的系統。 透過這樣的工具,它讓我們大幅減少了檔案遺失、錯誤覆蓋、找不回過往歷史等問題。但當案子規模不斷擴大,資料庫中檔案也將變得越來越多。 若這些資訊無法跟其他系統相互接軌下,就又產生新的不便利了。 比方說,要重複利用過往用過的物件。 除非你很熟過去SOFA的製作歷程,否則別說找出那個檔案了,連有沒有做過都不知道。 後面接手的人,也不會自動被通知,東西做好也不會自動出現在進度紀錄上(如Item List或Cutlist上)。 其他議題追蹤、會議結論的回溯、可重複使用的資料庫等,都還是需要一直有專人在維持,而無法一樣工具中更新後,所有表單都自動更新,或讓專案所有相關眾人都自動Push取得資訊。 所以,大家可以清楚理解還有很多軟體工具是需要被開發與建置的。

而且更重要的是,這類工具的建置,不能是各顧各的獨立開發。 因為獨立開發就有資料無法傳遞的問題、也有可能會跟別的流程衝突。那樣不但無法減少縫隙、反而可能加大縫隙。 所以必須要從公司的未來性、專案流程、訊息傳遞、減少錯誤、甚至為專案工作中的每個人量身訂做使用者介面,從「整體」來判斷與考量。


這也是為何前面兩三年我們花很多時間在看不到的基礎建設上。 比方說,培養大家好的工作習慣、盡量確定製作與管理流程、鼓勵效率、收集工時訊息、標準化存檔位置、標準化檔案名稱等各式各樣大家覺得煩瑣或是奇怪的事情。因為我們不希望等到某一天組織大到無法掌握時才來整合做事方法,而是希望在目前的逐步擴張下,就同時試著減少「未來」的混亂。 (但代價是一直得面對現在的混亂,而不能像鴕鳥一樣暫時不理它。) 方法統一下,系統才會有幫助。 (舉例來說,若每個案子Cutlist都長不一樣,那如何整合系統?)

老實說,哪天能真正達成無縫式的製作環境我並不知道。 但最少事情一直在往前推動著,也一直有所進展。 整合管理工具的概念甚至其實從幾年前就開始推動過,只是當時因為很多內部製程在需求或管理流程與規則上都還不明確,加上當時試圖一次把所有功能都放入,最後結果並不很理想。但今年,我們將重頭來過。 而且這次的開發將委由富士康南京軟件園區的軟體團隊們一起合作。 在我寫這文章時,我們與他們已經做了好幾次討論與會議,並已敲定要在接下來的一到兩年中,由他們來協助我們做這些相關工具的開發。

但我得說,就算有他們的幫忙,往下走也不必然會是輕鬆的路。 因為軟體開發的同時公司不可能停擺。 一方面大家要兼顧公司的營運、要讓案子一路順利下去,還要花心力做各類整合、測試、或是流程的優化。這絕對會是我們接下來的一大挑戰。

但不管挑戰多艱難,要做出成就,事情就得咬著牙推動下去。 所以,才藉此機會分享這些訊息給公司及集團中的大家,也希望接下來大家對於各項計畫的繼續支持。

尤其希望大家多給PM的團隊們一些加油與鼓勵。 他們從幾年前在毫無工具幫助下,徒手的跟環境奮鬥、架構表單、管理結構、整理資料、理出頭緒、定義流程、整合各人員、並讓案子順利進行。就算是現在,他們多了不同的工具,也還是得投入大量的工時、面對各方的壓力、細心面對各項挑戰。 達成使命之餘,還得邊學新工具邊測試新軟體、甚至接下來怕還得陪著軟體開發工程師們談論需求與測試功能。

我在此也要感謝一路以來對這整件事情共同努力並支持的同仁們。 我相信,最終有一天我們會很不同的。 這裡一直讓我覺得很有意思。有著一批對於創作有心的人、有著一批對於製作技術努力專研的人們、有著明知困難但奮力支持產業的老闆。 更重要的事情是,很大比例的同仁都是願意不斷挑戰現有做法,不斷把其他人拉出安適區的鬥士。

如同Good to Great那本書中所提,當我們有最強的創意、最強的技術力、並開始透過科技搭配我們的管理能力時,這一切終將轉化成組織成功的加速器。 最終,這一切將產生一個啟動後就不會停止的巨輪,直到把我們帶出一片美好的成就。

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

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

Joe G+ ICON Joe LInkin ICON

9 則讀友回應

  1. susan 2010-07-16 16:53:27 第 9 則

    呃...怎麼突然覺得沒看蝙蝠俠黑暗騎士這部電影是個錯誤的決定
    不知道除了這2條路之外,有沒有其他的options啊?
    我沒本事作hero,可是我也不想變成villain啦~

    • Joe Chang 2010-07-16 22:17:19

      你說對了,沒看真是虧大了 XD

      你看,你完全誤會了....變成Hero反而是沒本事的象徵啊......

  2. susan 2010-07-15 17:25:22 第 8 則

    不好意思
    最近忙著搞定一些事情
    沒能上來回覆

    謝謝大家的關心
    我從這些意見中得到了不少啟發
    也非常謝謝小林還特地抽空打電話給我
    和我分享一些他的經驗與看法
    在經過幾次與內部主管的討論之後
    原則上對於適當進行資源分配和PMO的定位總算是形成了初步的共識
    不過還得先過sales這關,獲得他們的支持
    才能繼續往下一步邁進
    我現在只求自己別被捲入政治風暴的中心啊...

    • Joe Chang 2010-07-16 11:49:24

      哈,我不想打擊你,但我要先提醒。 做這角色時,請隨時記得蝙蝠俠黑暗騎士中的某段引言 : Either you die a hero, or you live long enough to see yourself become the villain..... :D

  3. Joe Chang 2010-07-13 08:53:33 第 7 則

    給Susan: 所以這部分回答有解決到你的問題嗎? 還是你能再多提供些問題的背景資料?

  4. 小林 2010-07-09 16:04:27 第 6 則

    Susan,
    如果你的問題是怎麼分配人力
    首先你當然要先知道那個人有空
    就像我們在活動中完成的資源直方圖一樣
    這時timesheet會是一個可以用的參考工具
    (可別完全相信它,總是會有人為了field earning在上面灌水)
    建議在consulting部門要有PMO的人
    你的分配會比較smoothing
    而且應該要求sales在和客戶kick off meeting後
    應和被分配的consultant再次拜訪客戶
    再根據第2次kick off meeting的結果
    提出proposal
    這樣會比較好

    這是因為consulting service買的是"人"
    所以業務不一定是靠sales
    多半要靠consultant
    因為他們是直接處理客戶反應的人
    如果他和客戶不對盤
    你的服務客戶也不一定會滿意
    這時sales要出面跟客戶解釋
    搞不好要換人

  5. susan 2010-07-09 12:28:04 第 5 則

    我們目前想將公司內部的資源重新整合
    再依據各類專案需求進行分配
    主要目的之一是希望擺脫過去由sales直接決定資源或是主導部門主管分配資源,而造成資源不均分配或不當使用的問題

    不過由於我們的業務形態有蠻重的比例是consulting service
    其中,某些可作為PM角色的人員同時也是consultant role
    sales在與客戶方洽談業務時,會需要consultant的協同
    在functional position上,這些consultants隸屬於該部門主管
    從資源角度來看,他們也同樣視為專案資源之一
    而sales不見得有指定consultant一起參與sales stage的活動
    在專案尚未發生,前景不明,sales需要資源support,而又想透過PMO的資源分派機制來處理的話
    該如何設計會比較適合呢?

    • Joe Chang 2010-07-09 22:33:52

      小林回答了一大部分了。 我補充幾個點 (或說是問幾個問題)

      照這狀況來看,Sales應該最了解客戶需求,可能也比較清楚內部顧問誰比較能搞定這類客戶(比方說做過類似案子)。 所以,如果直接讓Sales提Request,這會有甚麼問題嗎? 換言之,讓PMO等單位,純粹扮演"媽媽桑"的角色呢? XD