需求評審會常常是產品經理的“噩夢”，會議冗長、效率低下，甚至可能因意見不合導致項目停滯不前。本文作者憑借豐富的電商和游戲產品經驗，分享了如何通過創新方法提升需求評審會的效率。

———— / BEGIN / ————

我的職業過程有三個關鍵階段，第一個階段就是做大型企業的數字化項目，主要側重供應鏈方面的解決方案。

這里要分享的項目經歷，也就是在那個階段中所經歷的事兒。

初生牛犢不怕虎，這句話講得非常有道理。

剛入行的頭兩年，我自認為學習了這個行業的很多知識和技能，所以有一種年輕人的無所畏懼，覺得什么項目做起來那不都是手到擒來。現在回想起來，只能感嘆還是太年輕了。

正是由于那時的盲目自信，被現實狠狠的打臉。那是一個燙手的數字化項目，對應企業是一家上市公司，在全國40余座城市中有近1000家直營門店，整體體量還算是挺大。

整個項目背景是當時O2O電商（即Online線上網店Offline線下消費）發展迅猛，需要將品牌下所有門店及加盟商打通，實現線上的電子商務平臺和背后的采購、生產、銷售、倉儲、財務的一體化管理。

從本質講這是電商平臺和ERP兩件事兒，當時就廣義的稱之為ERP項目。雖說是ERP項目，但是它又不純粹。這是由于這家企業其實已經上了一套ERP，用的是用友U8這個產品，那么為啥又要新起一個ERP項目，這是由于它們這個行業的特殊性，和電商平臺的訴求，導致U8中的物料、組織架構等信息已經無法滿足這些新的業務場景。

再加上之前為了上U8，花費了不少的人力物力，企業的老板們不想要完全摒棄這一套東西，于是就提議要保留U8的財務核算功能，重新去打造財務模塊之外的電商平臺、主數據、采購、生產、銷售和倉儲的系統。

所以從系統層面來分析，就涉及到電商平臺與主數據、倉儲、銷售模塊對接。整個產供銷過程中產生的原始憑證和存貨核算再與用友U8對接。

講到這里，是不是頭都聽大了？

當時也是這個情況，團隊中很多人都不愿意去接這個單子，最后這個項目落到了我和另外兩位老大哥的手上，其余開發實施人員由項目經理領導。

那我們三人小團隊也各有分工，其中一位老大哥和我負責業務調研、分析和出解決方案，另一位則做詳細設計文檔輸出，對接開發實施團隊。

于是一個草臺班子就搭建起來了。

我還記得第一天去客戶現場的場景，和我們對接的業務負責人有三位，一位負責電商，兩位負責ERP。電商負責人的態度是推陳出新，不破不立。ERP負責人則主張小步慢走，或臥倒不動。

所以當時在會議室就充滿了濃烈的火藥味兒，那時的我哪知道如何化解這樣的矛盾，這也為后面的工作推進埋下了艱難的種子。

記得第一天在業務現場調研，就感受到了電商業務負責人和ERP負責人之間濃烈的火藥味兒。于是我們后面就展開了分頭行動的策略，周一周三聊電商業務，周二周四聊ERP，如此一來，確實避開了他們之間的爭執。

一個月下來，我們把整個項目的范圍和邊界調研的七七八八，原本計劃是電商平臺和ERP一齊上線，這樣就可以避免后期方案變動導致線上問題。

但是電商平臺負責人不知道是不是有什么KPI壓力，要求三個月內就要上線電商平臺。雙方的高層領導也經過多輪溝通未果，卑微的乙方只能將重心調整，先落實電商平臺的搭建。

這里面就發生了一些故事，講一個印象很深的細節。有些讀者朋友可能知道電商平臺中，對于商品管理，有SPU和SKU的概念。舉個例子，一輛汽車，有白色和黑色，那么在電商系統中一般只維護一個商品編碼，然后有兩個規格屬性。但是在ERP中，這種情況一般是維護兩個物料編碼，便于成本核算和生產計劃的拆解。

當時也和客戶溝通了后續可能造成的風險，但客戶不聽勸，一定要按照電商的標準做。

就是為了滿足用戶前端能夠在同一商品下選擇不同的屬性。

時間緊，任務重，由不得想那么多，于是大家只好按照甲方的意思展開。好在兩個月下來，一個融入了眾多甲方想法的電商平臺V1.0.0版本上線了。

接下來的重心就是ERP了，前面說過調研第一天ERP負責人和電商負責人就有分歧。

對于ERP物料主數據的維護，ERP負責人堅決要按照屬性分開維護物料，而且長期規劃只在ERP中維護物料主數據，其他系統都從ERP取數。

道理是這樣的，我們無法反駁；但當時做電商平臺的時候，電商負責人可堅持的是維護一個SPU，這不就自相矛盾。

奈何沒有辦法改變兩方的想法，那么就只能換個方向，用技術換空間，改變系統。

以ERP維護的物料作為最小SKU，然后在電商平臺進行二次打包操作，相當于聚合為一個SPU商品，呈現出多個屬性。

這個風波當時算是用技術解決了，但是否真正合理，打個問號。后續的一兩月就繼續圍繞著類似這些問題，來來回回的溝通、妥協、修改方案，項目組可謂水深火熱，每個人盡顯疲態。

終于ERP V1.0.0版本計劃在一個月底上線，這又是一場硬仗。

之所以選擇月底，是因為ERP上線前需要做期初財務數據。

這時候前面埋的雷開始爆炸，電商平臺在ERP未上線前就開始了銷售業務，又加上前面說的商品和物料的復雜關系，導致這部分數據的銷售成本核算異常艱難。

最后通過線上線下數據清洗和分析，弄了兩天，算了一個近似值，才算結束了這個關鍵的里程碑。

隨著電商和ERP V1.0.0版本上線，我就和前面提到的兩位老大哥退出了這個項目組，算是脫離苦海吧?，F在回想起來，真是一言難盡，只能說給當時的我狠狠地上了一課。

這個項目的整個過程，給了我太多的經驗和教訓，有些方法和環節如果控制得當，那么進展可能順利一些，不說有多順利，但不至于如此痛苦。

總結了下，大概有幾個方面，首先是項目入場環節，當時就開門見山，直接開始了調研工作，哪知道方向不對，努力白費，跑得再快也是徒勞。犯的最大的錯誤就是沒有確定好甲方的關鍵干系人，也叫一把手，需要其能夠平衡電商負責人和ERP負責人之間的利益和沖突，起到關鍵地決策權。

這樣就能夠避免兩個負責人之間的意見沖突全靠乙方團隊來平衡的問題，被兩邊牽著走，簡直是吃力不討好，最后兩邊各執己見，系統只能兩邊遷就，亂作一團。

這樣的遷就又催生出下一個問題，那就是失去了原則。一再的向甲方妥協，讓講究標準化、結構化、系統化的數字化軟件工具變得扭曲。這個事就教會了我要堅守原則，做正確的事情固然困難，但困難不是不做正確的事情的理由。

如果上ERP不是僅僅為了面子工程，那擺事實講道理在這樣的大型項目上至關重要。因為企業要做管理咨詢，無非就是久病而不自知或者是自知而不能自治，當醫生通過望聞問切開出藥方后，病人卻不按藥方煎藥要換自己認為正確的藥，這是很難痊愈的，醫生則是那個堅守原則的人。

有了解決方案后，但是在實施過程中，三番五次的修改，這也是當時面臨的另一大問題。大家知道特別是軟件系統建設，對于流程和結構的調整有多痛苦，好比炒了番茄蛋，要吃青椒蛋。

關于如何解決這個問題，是后面和四大會計師事務所之一的德勤公司，合作的一個500強企業ERP項目中找到了答案，后面再去詳細分享我在這個項目中的故事。這里只聊一下這個項目是如何處理方案變更問題的。

當時，在項目上劃分了幾個關鍵里程碑，就有項目調研、藍圖設計、詳細設計、項目實施、驗收培訓這幾大環節。在每一個環節產生的交付物經過雙方評審后，均需要企業的關鍵用戶和一把手簽字蓋章確認。只有落實清楚再開展下一步工作，這樣做的目的就從流程上控制了甲方變更方案的風險。

最后就是多系統交互，當時的數據流向呈現混亂狀態，導致系統建設乃至后續甲方運維工作都很不便利。這讓我明白系統搭建之初，對系統上下游的界定、系統的優先級層次、數據結構、傳導方式等的提前確定有多重要，為后續實施階段起到關鍵避坑作用。

這個故事就分享到這里。

本文來自微信公眾號：產品真經，作者：產品真經

想持續學產品，沒方向？沒人脈？沒資源？點擊加入“產品經理進化營”圈子，和1000+優秀產品人一起進化成長！