救援投手 -
我當ERP導入PM的經驗
新的舊專案
在我顧問公司PM最後工作的印象，都是做救援投手。在棒球比賽中的救援投手，都是先發投手或是主力投手已經沒辦法繼續投球的時候。不管現況是贏是輸，都要想辦法在後面的比賽中不要失分，贏得比賽。
而在ERP顧問這個行業，前一個PM沒辦法繼續現在的專案而要救援投手上陣的理由很多。眾多的理由裡面，因為自己心力交瘁而不想做這個案子的不會理由。因為每一個ERP專案都是PM的重要履歷，除非這個PM不想在這個圈子混了，不然再苦也會想辦法把專案做完。
遇到比較多需要我這種救援投手的案例一般都是和客戶無法繼續合作下去，我們一般都說被退貨。不管多有經驗的PM，都可能因為能力；和客戶磁場不合；專案無法交付等原因被客戶要求換PM。也有一些case是對於一些簽約時談到的模糊的需求有爭議時，因為PM要替公司爭取權益而被迫和客戶發生衝突，我們業界叫這種是犧牲打。我這次救援的案子比較特別，是因為多次系統上線測試都不順利而沒辦法上線。公司已經換了三個救援投手都陣亡。我已經是第五隻砲灰。由於這個客戶是業界的標竿。第一次去客戶那裡的時候，還是公司總經理帶我過去見客戶的。
我到客戶公司的時候正值最熱的八月底，系統上不了線，甲方(就是客戶方)和乙方(就是我們顧問公司)為了釐清(推卸)責任已經吵架吵了兩年多了(專案執行一般是十個月)。接待人員把我和總經理進到會議室時，我覺得一個裡面坐了二十幾個中高階主管的會議室的溫度彷彿比外面低了十度。每個高階主管臉上寫的都是無奈。”老娘我事情這麼多，顧問公司又派一個來送死的PM為什麼還要我出席”。我嘗試很熱情的做完自我介紹以後問大家有沒有問題。會場上的主管們連轉頭看其他人的動作都沒有，只是靜悄悄地看著我，那時我心裡只有一個念頭”我死定了”。
信心建立
客戶端PM
接了這個專案以後，我第一件事情就是尋求客戶端的PM的支持。客戶端的PM一般是一開始在他們公司推動這個專案的核心人物，因為專案是她說要做的，所以這專案的成敗也關係到他的烏紗帽。從某個角度來說，我和客戶端PM是生命共同體。在這次專案，客戶端PM是IT部門的第二把交椅，他負責調配資源和向上溝通。除了她以外還有一個副PM是負責判斷專案執行細節的， Scheduling整理；議題管理；各項報告本來就是我們顧問公司PM要做的事情，但是這個副PM姐姐因為對工廠系統很熟悉，所以要判斷很多技術上的細節。
因為這專案拖太久，所以兩位姐姐很有結構的跟我解釋了這個專案到目前的瓶頸。主要問題在於資料品質和客製程式開發的問題無解。這裡科普一下，其實任何系統都是資料和邏輯的互動，如果一套系統資料或是資料的運作邏輯沒辦法搞定就不能執行。而我這專案很榮幸的同時有這兩個問題。身為有經驗的PM，在我跟姊姊們熟了以後，也開始問每一個專案關係人(stakeholders)對於這專案的態度和個性。聽起來像是聊八卦，但是要了解專案的每一個關係人是PM最重要的工作(沒有之一)。當然，姐姐們也會很主動的跟我抱怨我之前所有PM的不是。這專案甲乙方已經對立成這個樣子並非一日之寒，台灣的產業都是OEM起家的，大家都是對產品品質負責，不會像日本企業一樣重視客戶的聲音。而台灣的顧問公司的人都是美國體系訓練出來的，配教育要重視合約精神，但是台灣顧問公司自己又不把合約寫清楚。所以誤會越來越大。我很認真的聽兩位姐姐抱怨，取得他們的信任，是我避免成為砲灰的最重要一步。
顧問團隊
我在取得姊姊們信任之後。第二件事情就是要取得自己團隊的信任。自己的團隊和客戶同等重要。這麼大的一套ERP，不管是工作量和專業技術，都不是我一個PM可以處理的。如果團隊願意合作，我就只要做專案管理的工作就好。如果團隊不願意合作或甚至內部有矛盾，我就得自己跳下去處理技術問題。更恐怖的，是如果有一些資深的顧問對PM不服，就會像病毒一樣把負面的情緒和對於PM的不信任擴散到團隊其他成員以及甚至客戶那裏(擴散到客戶那裏就是職業道德問題)。
在顧問公司，顧問團隊都是臨時組隊的。有點像是航空公司的飛行員。只要任務一結束，大家都分別被派到其他的專案。所以也理所當然的PM對於這些顧問的考績是沒辦法評價的。
我的Case的好處是這個團隊非常團結且專業，壞處是他們對前一個PM很信任。所以對於新來的我的能力有嚴重懷疑。依照某些教科書的教法，是要把PM批評一頓，建立自己的權威。我的方法則不是，我是說蕭規曹隨，既然之前配合得很好就繼續依照原來溝通方法做。
ERP這種案子，一般會有FI, CO, MM, PP, SD這五大模組，原則上都會有五個主顧問帶著副顧問執行他們模組的工作。五個主顧問原則上會依照在業界的經驗年數論資排輩。如果最大的兩個顧問年資都很高的話，CO模組的顧問講話會比較有份量，因為ERP系統最重要的目的是要計算成本。我這個案子的兩大支柱是FI模組以及MM模組。所以我就以這兩位的意見為團隊的主要意見。技術團隊對於”服不服從PM”的態度都是以PM對ERP的熟悉程度為主。我雖然是碼農出身，但是我對ERP的設定很弱，所以在團隊裡我把自己扮演成一個對客戶溝通的橋樑。至於技術面的專業判斷，除非嚴重跳脫我的邏輯與常識，不然我都尊重顧問們的決定。也就是民主化專案管理。
Stakeholders (專案利害關係人)
建立完自己內部團隊的共識以後，又要回來重建客戶團隊的信心。客戶的ERP團隊一樣依照模組分成五個，我就請PM姊姊幫我借了第一天差點被凍死的大會議室。讓這些User們把問題列出來，我做完紀錄以後依依詢問細節。一般來說，user對於重複性的問題會覺得很煩。”每陣亡一個PM就要問我一次，你為什麼不去問那些陣亡將士”。但是我的問法會帶著我的愛。我不只是問他們目前作業方式怎麼做；為什麼這樣做。我還會問問題問到心坎裡”你每天單這麼多，要弄到幾點才下班?” “所以你到月底要結帳的時候，小孩幼稚園怎麼辦” “系統導入之前你一定要撐住，這公司不能沒有你”。就是這些看似聊天的對話中，我就可以慢慢套出專案無法執行的很多政治面或是溝通上的原因。有很多資深的PM或是顧問因為對於技術太熟悉了，所以問問題的時候都沒有溫度，這樣只能處理表面的問題而不知道實際原因。這些看似無關緊要的關心和閒聊，不但讓我知道很多系統開發窒礙難行的的問題的背後原因；也讓我取得這些user的信任。
不只是在會議中和團隊建立信任感。我幾乎每兩週都會寫信給所有團隊成員，快要六十人。目的是要像是做廣告一樣持續刺激這些成員對於專案的重視。讓他們每週一一打開信就看到這個專案。
當然，這方法不是對每一個人都有效。例如這個客戶的業務副總就不好搞。這副總除了對專案團隊不滿以外；和工廠也有心結。我特別抽了一天時間到業務辦公室去跟他開會。我在我的報告中尋找任何和這副總可以共鳴的話題。我試著用國際化；資訊化；客戶關係等話題都看不到她有共情的眼神。直到我快要放棄，說到客製化議題的時候，我不經意地說”我從來不相信同一套ERP可以套用在任何公司，如果每個公司都用ERP都能執行他們的業務，那每個公司都跟我XXX公司一樣，這樣我們XXX公司還有什麼競爭力”。這時我注意到她不但眼神融化了，而且開始把所有的想法傾囊而出。那時我暗自想，我很有可能不是第五個砲灰了。
專案反抗份子
最後一個要解決的是IT團隊中的反抗份子。固然User中也有很多人牴觸新的ERP，但是IT自己牴觸會是最棘手的。IT之所以會牴觸是因為他們依賴著原來的ERP可以在公司作威作福，一但換了新的ERP他們就要跟菜鳥一樣從頭開始學習(這觀念其實不對，ERP重要的是流程而非程式)。有了姐姐的支持，我就開始要求IT單位在做資料轉檔以後要寫資料檢查程式，這樣才能再把資料匯入ERP之前確保資料夠乾淨(專有名詞叫data cleansing) 。反對派首領當場告訴我說這種程式很難寫，他沒空陪我弄這個(合約上是沒說要做這個)。我不等姊姊幫我罵人，我當場拿了他們的data在會議室花十分鐘把sample程式的主架構寫出來，質問反對派首領說，剩下的程式連大學剛畢業的都會寫，你要我陪大家繼續寫下去嗎? 反對派首領當場不敢講話，事後姐姐也誇獎我，說，這種做黑手的人就是要比他還黑才制得住。
解決問題
我永遠相信，專案成功最重要的關鍵在人心。但是並不是建立了信任關係專案就成功了。前幾代PM留下來的問題不會因為有決心就奇蹟般的自然消失，還是要付出實際行動。
文件品質
前代PM們留給我的第一個問題是專案文件品質的問題。ERP的顧問的時薪很高，所以客戶對顧問公司交付文件的要求也會很高。和一般的文件不同。ERP的規格與教育訓練文件會隨著這套系統使用十年二十年，即使是未來剛入職的員工也會用到這份文件。所以如果文件有令人誤會或是甚至錯誤的地方，這些錯誤就會跟著系統遺臭二十年。
顧問們年紀都長這麼大了，雖然寫錯字在所難免，但是被人家指出錯字這種低級錯誤，誰都會面子掛不住。”客戶是故意找我碴嗎?幾千個字的文件要我自己確認錯字!”。
PM有很多種，有些強勢專制的PM會跟顧問說”寫錯字就是寫錯字，我不管你的文件有幾千字，把字寫對就是你的責任。你知道你自己的價值嗎?”。但是我的”民主PM”風格在接這個案子的時候就已經定性了。我不能跟顧問來硬的。我唯一辦法就是另外找一個人幫我檢查時幾個顧問共同寫的幾萬字文件的錯誤。但是公司怎麼可能派這種小秘書給我。
小秘書沒有，虛擬秘書卻不是不可能。我觀察到顧問群會犯的文件錯誤有兩種。一種是中文錯字，尤其是電腦拼音輸入法的Bug造成的；另一種是對於同一個系統專有名詞，因為一開始都是英文，所以每個人對同一個字的翻譯會有差異。
找出來了以後就建立一套”錯字與同義字字典”，和顧問們一起定義好所謂的錯字和英文翻譯過來的字之後。就讓電腦程式去看著字典掃描那幾萬字的文件，讓電腦告訴我哪個文件的哪裡有哪些問題字詞就好。就這樣，本來是甲乙方的文件交品質的政治問題，就讓我用資訊科技的技術問題給解了。
資料品質
如果說文件品質問題是阻礙專案進行的小坑，那麼後面資料和客製程式兩個問題則是阻礙專案進行的大山。
資料是專案成敗的核心之一，而資料的責任在合約上明顯寫著資料是客戶的責任。所以只要碰到和資料有關係的事情。顧問公司就會把防火牆設定好。顧問公司對待客戶的資料就像對待輻射物質一樣，客戶把資料放到顧問公司的指定位置，然後顧問公司小心翼翼地把資料送進系統，結果是陽性就跟你說你失敗；陰性就恭喜你。絕對不會關心客戶是怎麼做；什麼方法；什麼心情把那個資料做出來。顧問公司都假設客戶在正常的狀況下提供合約上期望看到的完美資料。如果不完美，也是客戶自己要負責。這就是顧問公司所謂的"合約精神"。
其實Data cleansing的觀念和技術早在三十年前就已經有了，也是大學資訊專業的必修課。如果客戶不理解這套技術，就花點時間教他們這概念就好。顧問公司也沒有必要真的下手幫他們寫程式。但是顧問公司為了確保這個"資料的責任屬於客戶"這合約條款的防火牆沒有漏洞，所以連這種簡單的知識都不願意說。
我其實不是為了避免成為下一個砲灰而教客戶這觀念，只為了那個合約的防火牆而藏在心裡會很難受。我真心地認為如果我能分享的知識可以解決眼前的問題，就可以和客戶一起讓專案成功。所以我不但教他們怎麼寫。也親自下手做一些資料檢查程式的示範。
就這樣，因為資料品質的大幅改善，資料轉檔時間從過去的超過一個月簡化到只需要一天半。解了我第一個大問題。
客製化程式
再來就是客製化程式。主要是因為這案子的客製程式太多了，完全沒有預算可以完成專案所需要的客製化程式。
一般ERP的套裝程式，主要都希望客戶儘量用ERP的原有功能，不要因為過去的習慣而修改ERP的功能。但是像給客戶的訂單格式，或是會計公司要求的報表，或是自動拋帳這類的，很難因為系統更換而更換。ERP專案很難在專案開始以前就知道客戶需要什麼客製化程式，是必須要在充分理解客戶的需求之後才有辦法提供客戶客製化的價格。為了讓客戶放心未來顧問公司不會在專案開始之後對客製化程式獅子大開口，顧問公司的業務也會提供軟體開發工程師的每小時報價(這報價和業界其他程式差不多)。然而，在專案的藍圖階段結束，我們顧問公司提供的客製化程式報價還是遠高於客戶的預期。原因之一是: "所謂報價是單價乘以時數，我在時數上灌水就好啦"。
客製化程式也是顧問公司的重要收入之一，我們公司的這套ERP使用的電腦語言和外界不同，所以花的程式開發時間沒辦法和外界大家使用的電腦語言(python, Java這類的)相提並論。台灣島這麼小，能寫這種特殊電腦語言的公司也只有其他同類型顧問公司。而其他同類型顧問公司都不願意接競爭對手的客製程式開發的專案。換句話說，從這個專案和我家顧問公司簽約那一刻起，客製程式要多少錢就是我家顧問公司說了算。這就是現實。
兩個PM姊姊就是吞不下這個現實，硬要用外界系統開發公司的價格和ERP的開發成本比。就這樣，這個矛盾對峙了一年多。最後前代PM就體貼的把這個企業合作的結構性問題放在我的手上。
和資料的技術問題不同。這是甲乙方的認知差異問題。打破這個僵局，我要有一個第三方公正人，讓甲方知道這ERP的程式的開發成本就是比其他程式高。我也要讓乙方(我自己的公司)知道，客戶有能力選擇其他方法解決問題。
解決方法是業界的另一個特殊領域，叫做freelancer。中文翻譯成"自由職業者"。這些人不隸屬於任何顧問公司。他們透過人脈自己去找寫程式的case來賺錢，一般來說，他們接的案子比較是顧問公司把系統導入之後幾年，客戶要增加功能的時候幫忙寫(他們也不想得罪顧問公司)。但是在這個案子上，他們可以當我的第三方公正人。
當然，顧問公司不可能允許任何顧問(尤其是PM)去自己找freelancer。從某個角度看，PM不讓自己公司賺錢就是吃裡扒外，要是Freelancer價格真的比較低，這部分利潤丟了怎麼辦。但是PM的天職就是要讓專案成功，如果我再陣亡，公司也收不到原本專案的錢。
所以，我就找了台灣和大陸認識的freelancers，打好招呼以後，在某個場合中"不小心"把這些freelancers的聯絡方式掉在桌上，被姊姊們"撿走"。姊姊就會積極地和這些人聯絡。最後，果然證明我們顧問公司的價格還是太高了。雖然我不樂見公司以外的第三方團體合作專案(設計和開發永遠都有很多衝突)。但是為了專案。這是必要的犧牲。