對于項目管理，目前市面上有不少管理平臺或軟件，但基于PLM平臺，以制造業(yè)的產(chǎn)品開發(fā)或研發(fā)為視角的項目管理平臺較少，而且使用PLM平臺進行目管理也鮮有贏得客戶口碑的案例。有鑒于此，本文以甲乙雙方不同人員的視角，試圖復盤某企業(yè)的項目管理實施過程，分析從業(yè)務調(diào)研，技術實施乃至項目管理過程中的得失，以期拋磚引玉，促使后續(xù)其他項目能更為健康有序的實施。

　　本期項目是PLM的二期工程，一期已經(jīng)實現(xiàn)了基本的產(chǎn)品數(shù)據(jù)管理，具體完成內(nèi)容如下：

　　1.Creo與Windchill集成，實現(xiàn)通過MCAD數(shù)據(jù)生成EBOM。

　　2.物料及各類圖紙發(fā)布和變更流程。

　　3.數(shù)據(jù)查詢，可通過字段進行常規(guī)數(shù)據(jù)查詢，也支持通過Solr引擎進行模糊搜索。

　　4.產(chǎn)品庫，文件夾結構，權限管理，實現(xiàn)基本的數(shù)據(jù)存放及取用。

　　5.物料取號，結合物料分類（和SAP）獲取物料料號。

　　6.SAP集成，實現(xiàn)物料基本視圖及產(chǎn)品結構（EBOM）向下游自動準確傳遞。

　　項目管理的幾個先決因素

　　對于項目管理的實施，而且還是基于PLM平臺的項目管理，需要甲乙雙方步調(diào)一致。雙方至少需要明確：這是一個中高層級的項目，要站在更高的角度，宏觀的來看待。對于項目管理這類項目，應該要對下述問題進行正面回答：

　　1.平臺給誰用

　　項目管理平臺通常涉及的部門、人員非常廣泛，那么如何回答這個問題才能最符合企業(yè)當下的實際情況？項目管理平臺通常是企業(yè)第一次實施，此時最需要考慮得就是企業(yè)管理層面的需要。具體來講涉及以下幾點：

　　a)項目類型定義及劃分

　　在項目管理實施初期，切忌求全思想。通常企業(yè)內(nèi)部的項目有如下幾種：產(chǎn)品開發(fā)（變型設計及訂單交付）、產(chǎn)品預研（包括市場調(diào)查、競品分析、工業(yè)設計等）、技術預研（這部分主要為超前技術研發(fā)，例如含WIFI功能的插座面板、多插座轉換器等）、精益設計/生產(chǎn)項目等等。

　　通常，沒有經(jīng)過管理咨詢的企業(yè)，其項目類型的定義及劃分的邊界是不清晰的，所以往往在實施過程中，會經(jīng)歷頻繁的變動，在此建議甲方，在未經(jīng)過實際實施及驗證的情況下，不要貿(mào)然進行類型及劃分的修改，應在有使用平臺的經(jīng)驗后再進行調(diào)整。

　　b)項目交付物及齊套性檢查

　　對于訂單型交付項目，需要將產(chǎn)品研發(fā)過程中的交付物進行統(tǒng)一管理。部分企業(yè)為了避免相似問題的頻繁發(fā)生，會考慮進行交付物的過程管理，所以需要進行項目交付物管理。這部分實施內(nèi)容包括：交付物模板管理，交付物編號/版本管理，交付物的齊套性檢查（按項目階段），交付物變更管理等。

　　c)項目進度及基線管理

　　在企業(yè)領導層的日常管理中，常需要關注項目進度。當企業(yè)制定了年度戰(zhàn)略目標后，就會根據(jù)目標并將其拆分給每個部門，并訂立KPI考核基準。所以年度目標是否能完成，就勢必依靠項目計劃來進行統(tǒng)籌?？紤]到各任務的難易度不同，每個項目也會給予不同的緩沖時間。所以項目實際總周期及項目預計總周期是PM及PMO都十分關注的重要信息。

　　d)項目變更及控制管理

　　項目執(zhí)行時，會因各種情況（計劃內(nèi)或計劃外）而導致項目周期、交付物、人員、費用、范圍等發(fā)生變化。此時若對項目總周期或階段周期有較大變化時，則必須要進行項目變更管理控制。但控制到何種程度？給予PM多大的自由則需要根據(jù)企業(yè)的實際情況進行斟酌。

　　e)資源負載均衡管理

　　目前企業(yè)常面臨著骨干工作量過多的現(xiàn)象，具體表現(xiàn)為：只要有新的重大項目就需要技術骨干參與，新員工或者技術較弱的員工常處于“游離”狀態(tài)，結果就是技術骨干隨著資歷增加工作忙碌程度也日益增加，且也時而發(fā)生多項目并行而顧此失彼的現(xiàn)象，出錯也就在所難免了。所以企業(yè)急需一套行之有效的人員狀態(tài)管理工具，以便于項目執(zhí)行及新項目開發(fā)時，進行資源負載平衡。

　　f)項目報表管理

　　項目報表作為項目監(jiān)控的主要依據(jù)，需要體現(xiàn)項目的實際情況。但對于企業(yè)，必須要選擇合適的數(shù)據(jù)以避免失真的數(shù)據(jù)影響PM或者PMO的判斷。所以除了要求用戶使用系統(tǒng)，并從系統(tǒng)獲取原始數(shù)據(jù)外，還需要制定適合當下的規(guī)章制度。讓所有人在同一套制度下協(xié)同辦公，這才是企業(yè)項目管理能獲得成功的必要條件。

　　2.平臺怎么用？平臺使用目的是什么？

　　只有在確定系統(tǒng)主要給哪些部門或者哪些角色用之后，才可以回答使用的方式及目的。其使用方式有：全手工，手工 系統(tǒng)，全系統(tǒng)3種方式。使用目的可根據(jù)企業(yè)自身情況分為：資源合理安排及交付物管理（側重項目安排），進度及風險管控（側重監(jiān)控）以及全流程全要素協(xié)同（側重協(xié)同）。

　　使用方式

　　三種模式的差異，并不一定意味著哪種模式最好。而是要根據(jù)企業(yè)當前的現(xiàn)狀，結合項目類型進行選擇及剪裁。

　　a)全手工

　　適用于企業(yè)成立時間較短，尚未形成穩(wěn)定且統(tǒng)一的項目制度，難以提供出一套適用于所有項目相關部門的執(zhí)行制度。

　　也適用于技術預研或產(chǎn)品預研類型的項目，對于未知領域，項目的執(zhí)行不能完全按照WBS，需要根據(jù)每一個任務的實際情況進行手工微調(diào)。甚至當預研出現(xiàn)較大變化的時候，需要及時止損并暫停項目，歸檔項目執(zhí)行過程中的所有交付物，以便后續(xù)條件合適時再重啟。當然也有可能因為外部條件變化，導致項目永久關閉。

　　b)手工 系統(tǒng)

　　適用于企業(yè)已具備一定的項目制度，但因種種原因導致項目執(zhí)行效率并不樂觀，所以除系統(tǒng)按WBS執(zhí)行時，還需要輔佐一定的人為干預，此類情況大多為臨時性的，一旦企業(yè)理順項目類型及進度任務關系，并適當修訂規(guī)章制度后則可全部轉為全系統(tǒng)執(zhí)行。另外如果因為任務涉及核心技術或者交付物中涉及戰(zhàn)略客戶，則為了保障信息不被泄密，可以將核心信息暫存他處，并沿用手工 系統(tǒng)執(zhí)行的方式。

　　c)全系統(tǒng)

　　適用于企業(yè)已制定較為完備的規(guī)章制度，且項目相關人員可以在此制度下默契執(zhí)行項目。此類模式主要應用于成熟產(chǎn)品的改型設計及訂單交付，很少適用于研發(fā)性質的項目。

　　使用目的

　　通常使用目的得根據(jù)主要使用部門來定，比如項目管理部作為主要使用部門，研發(fā)、工程、物流等部門為配套部門時，多以項目進度及交付物為主要管控目的，所以此時偏重于訂單合規(guī)交付以及項目進度的糾偏。

　　若以研發(fā)、工程部門為主要使用部門，則多以項目質量為重。所以綜合來看：當企業(yè)初具規(guī)模時，因各條件尚不具備，所以項目經(jīng)理多以資源協(xié)調(diào)及交付物管理為重。當項目管理平臺使用半年后，整體項目管理模式成熟及項目經(jīng)理可以通過數(shù)字化平臺縱覽全局后，則能提升至項目進度監(jiān)控及風險管控。此時項目經(jīng)理會根據(jù)各成員執(zhí)行情況進行干預甚至提前協(xié)調(diào)任務優(yōu)先級，并管控訂單交付或研發(fā)過程中的部分質量問題，此時WBS及交付物可能出現(xiàn)比前期更為頻繁的變更，所以此階段的各部門磨合期會持續(xù)較長時間。從PMO管理甚至企業(yè)戰(zhàn)略的角度來看，企業(yè)高層在此時應更多的處理好部門及角色的職能邊界問題，當崗位職能及執(zhí)行策略都形成具體的“方法論”后，則進入至全流程全要素協(xié)同的狀態(tài)（可參考IPD）。

　　2.1 創(chuàng)建項目計劃

　　分解復雜項目和方案成可管理的組件，在一個非常大的項目或者方案中，定義一個頂層結構，接著定義一級的活動計劃和任務接受者，一級任務接受者可定義二級的活動計劃，三級的依次類推。

　　1.WBS在項目立項階段，其定義過程如下（包括前后事件關系）：

　　2.項目經(jīng)理根據(jù)項目類型（ODM/OEM……etc.）通過模板創(chuàng)建項目；

　　3.系統(tǒng)支持將現(xiàn)有項目另存為新項目。

　　4.通過項目模板創(chuàng)建項目，同時項目經(jīng)理將OA中關于項目立項的信息填寫在創(chuàng)建的項目屬性中；

　　5.由項目經(jīng)理或者財務、產(chǎn)品經(jīng)理完善項目相關的財務、采購等信息；

　　6.項目經(jīng)理維護項目團隊及其主要成員，例如各職能擔當；

　　7.線下通知擔當，由擔當將項目過程中所需要的其他成員添加至團隊中；

　　8.在項目啟動前項目經(jīng)理與各職能擔當一起完善WBS，并針對具體的活動設置必要的交付物；

　　9.當項目經(jīng)理及擔當都完成WBS及交付物定義后，由項目經(jīng)理做最終確認，并執(zhí)行“啟動”操作，至此立項階段所有工作事項完成。

　　以企業(yè)某項目實例為例：

圖1 項目計劃（WBS工作分解結構）

　　系統(tǒng)可根據(jù)子任務的完成情況，自動計算其父活動的工時。并且通過逐級計算的方式，自動統(tǒng)計項目所使用的工時，便于項目經(jīng)理實時瀏覽查閱。

　　2.2 項目一級計劃鎖定

　　在項目執(zhí)行過程中，會因為各種計劃內(nèi)或計劃外的情況變化而導致項目周期及交付物、甚至參與人員發(fā)生變化，若項目經(jīng)理經(jīng)常隨意改動WBS及參與人員，則會導致PMO對項目進度、質量、費用的監(jiān)控失敗。但是如果不授予項目經(jīng)理一定的權限，則又會導致變更在逐級審批時的時間浪費，從而影響項目的實際執(zhí)行。為折中兩種情況并兼顧崗位職能，所以僅針對一級計劃進行PMO層級的管控，以確定大的項目周期變更處于可控范圍內(nèi)，同時授予項目經(jīng)理修正除一級計劃外的其他任務權限。

　　在WBS中，一級門檻計劃需要被設置為鎖定。非一級計劃可視情況需要定義其是否鎖定。鎖定意義為：

　　1.此任務的所有信息都不可被更改，但不包括交付物。

圖2 項目一級計劃鎖定

　　2.當任務完成后（百分比為100%），系統(tǒng)自動將任務設定為鎖定。

　　非一級計劃的交付物不受鎖定限制。其保證項目在進行過程中，可以對過往交付物進行變更或者替換，項目經(jīng)理可通過“齊套性檢查”查看項目所有交付物狀態(tài)。

　　3.一級計劃解鎖需要上傳變更單。

　　將本地的變更單上傳后，所有鎖定的任務將臨時解鎖24小時。若在24小時內(nèi)修改沒有完成，則尋求PMO項目管理員協(xié)助，重新解鎖。

　　若24小時后發(fā)現(xiàn)項目經(jīng)理修改不正確，則線下執(zhí)行糾錯流程，通過后由PMO項目管理員手動重新打開鎖定，項目經(jīng)理線上重新調(diào)整。

　　2.3 項目資源管理

　　建立多層級的資源庫管理架構，滿足不同企業(yè)的組織架構需求和業(yè)務擴展需求；例如：針對一個集團性的企業(yè)組織結構，不同的子公司定義和管理自己的資源庫，這些資源將用于每一個子公司的項目。

圖3 項目資源結構樹

　　多層級的企業(yè)資源庫,以下是系統(tǒng)中每一個組織的資源庫。如果要管控項目的資源成本，則需要為每一個資源定義單位成本（價格）；同時，需要為人力資源定義角色。每一個人力資源可以承擔多種角色。

圖4 項目資源池

　　關于資源費用這部分，為保證系統(tǒng)的可擴展性以及兼顧未來與HR系統(tǒng)對接，預留人力資源成本內(nèi)容，現(xiàn)階段可不用考慮維護這部分屬性信息，待后續(xù)時機成熟，再引入人力資源成本信息，以統(tǒng)計項目的人工費用。

　　針對某個項目的團隊，可以根據(jù)企業(yè)的實際業(yè)務定義，靈活的添加角色，以及在角色下添加相應的成員。項目的團隊模板可以提前定義，便于提高項目團隊定義的效率。當項目創(chuàng)建后，團隊成員也可根據(jù)實際情況進行調(diào)整。

圖5 項目團隊

　　基于資源，系統(tǒng)可以依據(jù)企業(yè)的業(yè)務需求按多維度統(tǒng)計透視資源（按部門、按職位、按項目）。基于項目計劃工作量估算，可實現(xiàn)資源短期沖突分析。

　　ODM/OEM/策劃/精益的角色與新產(chǎn)品開發(fā)項目保持一致，若實際項目發(fā)生偏差，可在項目啟動時進行角色裁剪。

　　2.4 工時管理

　　工時是WBS的一個有機組成部分，不可或缺。系統(tǒng)根據(jù)WBS的主要功能，結合實際業(yè)務場景，定義了一系列的計算規(guī)則，現(xiàn)將影響工時的因素羅列如下：

　　1.日歷

　　根據(jù)不同國家/企業(yè)，定義系統(tǒng)唯一的日歷。例如：周一-周五為工作日，周六周日為雙休。

圖6 項目工作日歷

　　2.資源及資源使用率

　　在系統(tǒng)中，每一條任務都會自動計算工時。任務工時的統(tǒng)計量由承擔任務的各個資源乘以其使用量再乘以其工期計算得出。因任務持續(xù)時間（工期固定），所以系統(tǒng)默認將所有資源對于任務的使用工期都定義為任務的工期。

圖7 項目活動

　　以上圖T0制作任務為例，共使用市場擔當、采購擔當?shù)?4個不同類型的資源，同時默認每天8小時工作時間，持續(xù)工期為38天工作日，所以總工時為14*8*38=4256工時。

　　若將市場擔當?shù)馁Y源使用率改為20%，則工時為13*8*38 8*0.2*38=4012.8工時

圖8 項目活動及其資源分配

　　其業(yè)務含義為：在固定的38天工期內(nèi)，由14人資源組成的團隊，根據(jù)其不同的使用率，計算出此任務的工時總額。

　　若將此任務類型改為固定工時，則以上一次修改的總工時倒算出所需的工期。例如以4012.8工時為例，現(xiàn)將類型改為固定工時。同時將資源由14人調(diào)整為22人，且每人的使用率為100%，則工期為4012.8/22/8=22.8天。

圖9 資源負載及工時統(tǒng)計的關系

　　2.5工時填報

　　當項目經(jīng)理及擔當完成了工時及工期定義后，就會發(fā)起項目。項目在執(zhí)行過程中，每個任務的參與人員都要根據(jù)實際情況，進行工時匯報。單個任務工時匯報如下：

圖10 跟蹤工時

　　在WBS界面中，找到跟蹤工時按鈕，點擊進入工時填報界面。系統(tǒng)會自動根據(jù)自己所使用的資源情況，計算出可以填報的總工時。工程師需要根據(jù)業(yè)務情況，填寫任務完成百分比。

　　例如：

　　1.任務完成50%

圖11 完工率填報

　　系統(tǒng)會根據(jù)完工率*工時得到實際工時，此處為50%*182.4=91.2小時。

　　2.任務完成16小時

圖12 工時填報

　　系統(tǒng)計算邏輯為：

　　完工率=實際工時/工時=16/182.4=8.7%≈9%

　　剩余工時=工時-實際工時=182.4-16=166.4小時

　　2.6項目基線及交付物管理

　　計劃基線會創(chuàng)建計劃在某一時刻的快照，在計劃基線中可捕獲以下對象：

• 　　計劃

• 　　活動、匯總活動和里程碑

• 　　可交付結果

• 　　資源

• 　　資源分配任務

　　項目基線的主要目的在于項目計劃變更前后的對比，用以使項目經(jīng)理快速獲悉變更的差別。比較A：

圖13 基線對比（概覽）

　　活動計劃與當前計劃進行對比，通過查看排程中的差異比較視圖

圖14 基線對比（無差異）

　　因兩基線工時及工期都沒有偏差，所以差異顯示為0。比較B：

圖15 基線對比（概覽）

　　因兩基線工時及工期都有偏差，所以差異比較頁簽中顯示如下：

圖16 基線對比（含差異）

　　基于交付物管理業(yè)務，對項目管理（ProjectLink）功能進行分析，定義系統(tǒng)實現(xiàn)的業(yè)務邏輯，實現(xiàn)交付物管理模板、交付物完成率校驗、質量評判和過程交付物齊套性管控。

圖17 交付物與WBS的關系

　　另外，在 ProjectLink 中構建交付物的文檔類型，將輸出交付物的模板在系統(tǒng)進行統(tǒng)一管控，做到過程交付的標準化與規(guī)范化管控。

　　基于計劃活動的關聯(lián)交付物校驗機制，并增加項目計劃活動實際完成時間的設置機制，校驗交付物完成 100%、計劃活動匯報 100% 后系統(tǒng)自動設置計劃活動的實際完成時間，供項目過程監(jiān)控管理進行項目執(zhí)行進度偏差率的統(tǒng)計，進而掌控關鍵計劃活動的進度情況，盡早識別項目過程風險，調(diào)配團隊資源和計劃活動的執(zhí)行方案，或加強項目執(zhí)行過程溝通，使計劃活動按照預定的流程和時間節(jié)點執(zhí)行。

　　項目團隊的成員進入項目頁面后，切換至計劃頁簽。點擊交付結果，系統(tǒng)自動刷新以下界面：

圖18 交付物齊套性列表

　　2.7項目風險及問題管理

　　想要消除風險對項目的消極影響首先應該將其識別出來，比如風險的來源、產(chǎn)生的條件等，并分析該風險發(fā)生的概率和對項目造成的影響。項目風險的識別并非是一蹴而就的事情，應當貫穿于項目的整個生命周期內(nèi)。

　　記錄風險的相關信息，風險的的描述，風險的信息可以根據(jù)業(yè)務的需求進行擴展，指定風險處理的負責人。風險因未發(fā)生，所以只做風險登記，尚不需要流程審批。

　　在項目進行過程中，應當建立一套健全的問題管理機制，這樣在發(fā)生一些問題的時候可以快速反應，有效決策，防止問題的進一步擴大。

圖19 項目風險列表

　　當項目問題單獨定義為產(chǎn)品問題，除產(chǎn)品以外的問題，則可暫不在PLM系統(tǒng)中管理。其具體管理方式如下：

　　1.項目經(jīng)理（問題管理員）將問題處理區(qū)分為需短期處理措施的問題及需長期處理措施的問題。

　　2.項目經(jīng)理線下召開會議討論問題的處理辦法。

　　3.討論確定后，根據(jù)Excel模板，填寫相關內(nèi)容，線上導入至系統(tǒng)中，系統(tǒng)根據(jù)Excel單元格位置，自動提取相應數(shù)據(jù)。

　　4.短期措施處理的問題導入后直接處于已發(fā)布狀態(tài)。

　　5.長期措施處理的問題需執(zhí)行問題關閉確認流程。

　　6.長期措施的問題，支持項目經(jīng)理線上編輯（應對措施駁回）。

　　7.當所有內(nèi)容確定無誤后，項目經(jīng)理（問題管理員）手工選擇需長期措施解決的問題，將問   題提交問題措施確認流程。若流程通過，則批量提起的所有問題都通過。若被駁回，則所有問題都被駁回。

圖20 產(chǎn)品問題清單

　　2.8項目看板及報表管理

　　通常項目經(jīng)理通過報表及看板來監(jiān)控項目的運行狀態(tài)，并根據(jù)具體信息進行糾偏。所以此部分信息的準確性則尤其重要。但從項目管理推進的角度來看，在項目管理第一期就制定詳細的項目報表則風險非常大，其原因在于：項目管理平臺上線使用初期，會伴隨著磨合甚至職能調(diào)整的情況。在此之前就進行報表的規(guī)劃會因為業(yè)務的調(diào)整而面臨報表信息變化的可能，而且這種可能性會非常大，建議企業(yè)在項目管理平臺落地后再行規(guī)劃。

　　但本次企業(yè)依舊對項目報表提出了如下實施內(nèi)容：

　　1.項目預算

圖21 項目預算看板

　　2.項目變更

圖22 項目變更看板

　　3.單項目看板

圖23 單項目報表原型

　　4.項目問題報表

圖24 項目問題報表原型

　　5.人員負載表

圖25 資源負載表原型

　　6.多項目看板

圖26 多項目看板原型

　　項目管理模塊是很多企業(yè)繼PDM項目實施后會跟進實施的項目，但常因實施結果不理想，對企業(yè)內(nèi)部的項目管理起不到作用而廢棄不用。究其原因在于，項目實施時一味的求大求全導致項目實施困難重重，又因企業(yè)內(nèi)控不佳，導致崗位責任制度不明確，一味的求效率而忽視職能之間的配合，最終使項目管理流于表面，并未解決項目的實際問題。

　　在本次項目實施過程中，最值得注意的就是如何進行部門權益之間的平衡，本身產(chǎn)品開發(fā)過程中就會牽涉多個部門，如何平衡各部門的關切是需要甲乙雙方重點關注的內(nèi)容。

　　項目管理功能還需要在實際應用中不斷優(yōu)化，項目成員也在項目不斷中磨合，以期讓projectLink發(fā)揮應有的作用，為客戶的項目管理提供有力支撐。

　　系統(tǒng)是最終將企業(yè)規(guī)章制度落地的工具，切不可將業(yè)務問題寄希望于系統(tǒng)來解決。管理問題終歸需要管理來解決，不可緣木求魚。每個公司的管理方式和關注點都不相同，本文只拋磚引玉，希望能與同行切磋交流并共同提升項目管理能力。