本文關(guān)鍵字 信息化咨詢 IT咨詢 ERP監(jiān)理 ERP評估

案例中王志這樣的項目經(jīng)理是比較負責的，遇到問題時主動爭取更多的客戶資料來配合項目的進展;而更有比較被動(或者說不負責任)者在項目實施過程中與客戶扯皮、互相推諉責任。

作為IT 服務商(也有叫系統(tǒng)集成商、實施廠商等，這里不再細分)針對案例里的這些問題應該怎么想、怎么做才能提出較好的解決方案?下面僅談一些個人的觀點:

甲方?乙方? 其實是一家人。

IT 服務商與客戶合作，以甲乙方的身份簽訂商務合同，雖然各有利益責權(quán)，但“項目做得好大家一起笑，項目做不好大家一起哭”，雙方可以建立基于項目的整體理解和全局觀念，爭取有效而統(tǒng)一的管理。

先從項目資源計劃開始

到底怎樣做才能將雙方的有限資源有效整合呢? ERP 是企業(yè)資源計劃，那么我們自己在做事情的時候是不是也應該先做好項目的資源計劃呢?文章中提到“公司要黨政學習、制造部要放假、業(yè)務要運作、外派業(yè)務人員調(diào)回困難”等現(xiàn)實問題影響到了項目的進展，而這些無非是資源計劃不到位而導致的問題。

首先項目資源應該包括參與項目的所有人、財、物、時間以及可以利用的一切直接、間接的資源。這些資源(不論是甲方的、乙方的)都必須由項目資源管理小組統(tǒng)一管理、統(tǒng)一安排，然后再根據(jù)各自的分工分割為項目實施小組、關(guān)鍵用戶小組，如圖所示:

其次，項目資源管理小組應該從企業(yè)實際運作的需要和項目實施的需要雙方面來統(tǒng)一管理。文章中提到的“公司要黨政學習、制造部要放假、業(yè)務要運作、外派業(yè)務人員調(diào)回困難”等，這些都不屬于突發(fā)事件的緊急對應，甲方的管理人員應該提前甚至很久以前就知道了，但是由于沒有通過項目資源管理小組的統(tǒng)一管理和信息共享，導致在乙方的項目實施計劃中并沒有這些安排。結(jié)果是甲方必須在保證業(yè)務正常運作的情況下調(diào)整資源，加班加點來盡可能配合乙方的工作計劃。因此，不妨試試在項目之初就把所有的資源，不分甲方乙方，放在一張表上進行統(tǒng)一管理，相信可以在很大程度上規(guī)避這類問題。最后，對于資源計劃中發(fā)生的變化，如:請假、人事變動、組織學習等都必須經(jīng)過項目資源小組的審批，同時伴隨著進行資源計劃的統(tǒng)一調(diào)整和正規(guī)的變更管理，才能保證項目可以有序、高效率地進行。

盡量把系統(tǒng)測試放在設計階段

不僅是對乙方，對甲方更想談一下這個問題:都到系統(tǒng)測試階段了，大家居然都不知道做出來的系統(tǒng)是不是能夠“走得通、走的對” ——大家就不害怕么?“甲方的壓迫(時間、成本)、乙方的無奈、軟件墳場上的悲哀”，幾乎所有的項目都是這副德行。為什么呢?個人認為是前期設計工作和中后期變更管理沒做到位。

說到設計工作，大多數(shù)人想到的是系統(tǒng)需求設計書、概要設計書、詳細設計書等等，但是這些都只是為了說明系統(tǒng)要做什么。其實設計工作中還有一項非常重要的事情，就是要說清楚系統(tǒng)最終做成什么樣子;也就是在做各種設計書的同時，應該同步做出對應的測試計劃書。測試計劃書中應該列舉出明確的數(shù)據(jù)和實例用以論證對應的設計書的正確性。關(guān)鍵用戶論證設計是否正確不應該只看設計書，還應該用設計書結(jié)合測試計劃書來進行系統(tǒng)正確性的論證，之后才能進行系統(tǒng)的開發(fā)、改造、環(huán)境準備等工作。

有的朋友會說:“前期準備再充分也都是無用功，客戶在中后期會不停地變動需求啊”。沒錯，這屬于變更管理的范疇。每次客戶需求的變動首先應該進行變更的申請，經(jīng)過項目資源管理小組進行討論，判明該不該變以及輕重緩急之后，放在變更計劃中分步實施;同時必須保證變更的可追溯性。不言而喻，這個過程也可以讓甲方清楚地了解到變更給項目實施過程帶來的風險和增加的成本。

最后要提醒朋友們注意的是進行變更處理的時候一定要保證需求、設計、測試、系統(tǒng)、手冊和環(huán)境等的版本統(tǒng)一。需求的變更經(jīng)常是牽一發(fā)動全身的事情，因此必須要通過項目資源管理小組進行統(tǒng)一的管理。