結(jié)案前還是結(jié)案后的風(fēng)險都必須事先做好風(fēng)險識別、分析、制訂風(fēng)險管理計劃和對風(fēng)險加以處置等工作。而如果向前追溯的話，許多應(yīng)對與規(guī)劃工作必須在項目啟動與計劃階段就加以完成。
1. 項目結(jié)案前：
1) 對應(yīng)既定方案的系統(tǒng)是否與企業(yè)的實際業(yè)務(wù)過程關(guān)聯(lián)在一起，如果沒有，項目組應(yīng)對的策略是什么;
2) 相關(guān)的歷史數(shù)據(jù)準備工作是否完成以及所準備數(shù)據(jù)的正確性是否通過恰當?shù)脑u估;
3) 正式生產(chǎn)服務(wù)器是否已經(jīng)準備就緒，并經(jīng)過必要的性能調(diào)優(yōu);
4) 是否建立起系統(tǒng)切換的領(lǐng)導(dǎo)機構(gòu)和問題處理處理機制并經(jīng)過項目高層管理機構(gòu)的批準;
5) 如何安排對最終用戶進行必要的培訓(xùn)，如何對培訓(xùn)效果進行必要的考核;
6) 如何對用戶驗證測試過程中發(fā)現(xiàn)的問題制訂必須的處置策略;
7) 正式系統(tǒng)上線是否經(jīng)過反復(fù)的預(yù)演，并根據(jù)預(yù)演的結(jié)果擬訂最終確認無誤、切實可行的上線切換計劃;
8) 預(yù)留的系統(tǒng)切換時間是否足夠(對涉及需向ERP系統(tǒng)發(fā)數(shù)據(jù)的情況，此條尤為重要);
9) 在發(fā)生不可預(yù)見的問題時，項目組的備份方案是什么
2. 項目結(jié)案后：
以往項目執(zhí)行過程中，一個常見的誤區(qū)在于：項目結(jié)案會一開，所有的事情就萬事大吉了。其實項目的結(jié)案只能標記著項目執(zhí)行的結(jié)束，而不能說PLM項目就一定能平穩(wěn)地投入到后續(xù)運行中了。系統(tǒng)的維護和技術(shù)支持工作是一個持續(xù)不斷的過程。對一些成熟的客戶，自己的隊伍在項目結(jié)束時，就已經(jīng)可以承擔起系統(tǒng)正常運維的工作了，而在項目結(jié)束后，通過正常渠道延展客戶方與顧問方的支持服務(wù)關(guān)系也不失為一種可行的做法。此時需要重點考慮如下問題：
1) 客戶是否具備獨立支持系統(tǒng)正常運作的能力和做系統(tǒng)改進調(diào)整的能力，如果沒有(倘如此，一定是在前期的風(fēng)險管理中已經(jīng)出現(xiàn)問題了)，如何在短期具備這樣的能力;
2) 基于已有的運行維護與支持能力，是否建立了一套行之有效的運行維護的管理過程，避免因系統(tǒng)未及時備份而帶來的嚴重損失(知易行難，很多企業(yè)在這方面都有過慘痛的教訓(xùn));
3) 如何保證在客戶遇到涉及產(chǎn)品本身問題，而不是開發(fā)訂制問題時，能夠從原廠商處得到必要的技術(shù)支持(一個典型案例：系統(tǒng)在正常運行1年半后，基于成本的考慮客戶沒有再購買必要的技術(shù)支持服務(wù)，當他們遇到系統(tǒng)問題時，所需的花費要比及早購買技術(shù)支持的花費大了許多，因為它包括了系統(tǒng)宕機帶來的實際損失)
這里有一條重要的現(xiàn)象需要指出：系統(tǒng)維護的早期正常投入，其代價通常會遠比問題發(fā)生后再加以解決所帶來的成本低得多。因此在項目結(jié)案后，客戶的系統(tǒng)運維支持部門需要時刻提醒自己：未來有一天當系統(tǒng)發(fā)生問題時，我們的對策是什么以及如何才能把對最終用戶的影響降到最低?這其實仍然是風(fēng)險管理手段在項目結(jié)束后的繼續(xù)應(yīng)用。
結(jié)語
回到本文開頭那句英文“We don’t go mountain climbing with a rope because we plan to fall, but we’d be all too grateful for the rope if we did.”。這里嘗試翻譯如下“我們不是因為我們打算墜入深淵而在登山時準備繩索，但在我們有過墜入深淵的體驗時，會感念登山繩索對我們的莫大救助”。其實PLM項目的風(fēng)險管理何嘗不是我們登頂企業(yè)信息化巔峰時的救命繩索呢?