專案實施範圍控制良好的典範 --- D專案

早在專案正式開工之前，合作方S公司就有派顧問去客戶現場做了業務調研。顧問透過召開若干個workshop的方式，與關鍵使用者多次溝通，弄清楚各個部門涉及到的業務流程，然後將這些調研結果形成文件，固化下來。

 

與此同時，S公司顧問團隊撰寫好了work item list檔案，就是所謂的專案實施範圍。這個work item list檔案，由顧問起草，確定了各個業務流程的主要核心步驟，那些步驟是系統外的，那些步驟是系統上要實現的；對於那些需要在SAP系統裡實現的步驟， 有具體談好大概的工時，比如配置多少個工時，測試多少個工時；如果有開發，那function consultant要多少工時，開發顧問需要多少工時等等。同時標註哪些步驟是must have/should have, 哪些步驟can have的。這個實施範圍檔案，顧問團隊與業務團隊反覆確認，最後由甲方乙方雙方管理團隊開會確認，形成最終實施範圍。專案實施範圍具體量化工時，體現了德國人嚴謹精細的工作作風。這個work item list是我們後續專案實施的綱領性檔案和基本法，同時也可以作為S公司評估工作量，確定專案週期的重要參考檔案。筆者第一次看到這個work item list, 讓人耳目一新，這是我這個做慣了美資企業客戶專案的顧問，開了眼界，漲了見識。

 

我們顧問進場後就開始了業務藍圖階段。根據work item list，我們確定各自模組的流程與功能清單，schedule相關的work shop，與關鍵使用者團隊review各個業務流程，畫好流程圖，由業務團隊review。最後客戶在無錫工廠的CEO/CFO以及各個部門經理組成的管理團隊逐個流程圖的review，最終順利定稿，完成了藍圖階段。後續以多個sprint的方式，逐步實現這些業務藍圖。

 

在專案的實施階段，隨著關鍵使用者團隊對於SAP系統理解的深入，挑戰性越來越強。他們經常提出各種要求，比如在某個環節，由SAP系統按照他們的格式列印某個單據出來；比如財務業務想對於修改過的vendor/customer, 財務經理在SAP系統上confirm這些change之前，希望SAP系統能阻止業務人員去下采購訂單/銷售訂單；比如倉庫使用者提出希望收貨之後，系統自動傳送郵件給相關業務團隊等等諸多標準SAP做不到的功能，也就是說需要額外開發的功能。此時，在別的專案裡，專案組很難拒絕這些要求。但是在D專案裡，我們專案組顧問可以翻開work item list，只要是這些要求不在work item list裡，我們就可以按照專案的流程，要求業務團隊走一個change request, 然後我們評估人天，提交給業務團隊，由其管理團隊審批，因為需要額外付錢。大多數這種額外的開發增強需求，都在客戶管理團隊稽核change request的時候，被CFO/CEO等拒絕，因為我們們人天貴，且這些開發評估的人天也不少。這使得D專案基本沒有超越早已定好的實施範圍，無論是顧問團隊的工作量大小與辛苦指數，S公司的專案預算等等，都在可控範圍內。對於筆者而言，除了PO FORM列印, 送檢單列印以及Metall Balance Report 三個開發物件之外，不再有其它的開發，工作量不算大，做這個專案當然就不會很辛苦了。

 

       筆者認為，D專案之所以能較好的控制專案實施範圍，主要還是在專案前期甲乙雙方就談好了超級細緻以數字量化好了的實施範圍，與工作量清單，並且固化成文件；當然更為重要的是，客戶方有較為嚴謹專業的契約精神，原意按事先談好的合同與流程辦事。D專案的甲乙雙方都是德資公司在中國的分公司，甲乙雙方的專案經理都是德國人。遵守合同契約，遵守流程，規規矩矩按部就班的做事，這樣大家都好辦事，避免了不必要的爭吵與消耗。

 

筆者參與的D專案，不能不說，在專案實施範圍控制方面做的很好。這使得筆者在內的顧問團隊，基本不用加班，就能輕輕鬆鬆的舒舒服服的完成專案的實施。在筆者看來，D專案又是一個超級好混的SAP專案，能做D專案，是筆者的又一個好運！

 

 

2018-01-14 寫於無錫市新吳區