那個ERP項目,讓人后怕!
在入行前三年里,有一個ERP項目經(jīng)歷,現(xiàn)在回想起來還印象深刻。之所以深刻,不是因為美好,而是因為它的痛苦。
前面在這篇《一個IT人的,ERP學(xué)習(xí)之路》文章中,講過我的職業(yè)過程有三個關(guān)鍵階段,第一個階段就是做大型企業(yè)的數(shù)字化項目,主要側(cè)重供應(yīng)鏈方面的解決方案。這里要分享的項目經(jīng)歷,也就是在那個階段中所經(jīng)歷的事兒。
初生牛犢不怕虎,這句話講得非常有道理。剛?cè)胄械念^兩年,我自認為學(xué)習(xí)了這個行業(yè)的很多知識和技能,所以有一種年輕人的無所畏懼,覺得什么項目做起來那不都是手到擒來?,F(xiàn)在回想起來,只能感嘆還是太年輕了。
正是由于那時的盲目自信,被現(xiàn)實狠狠的打臉。那是一個燙手的數(shù)字化項目,對應(yīng)企業(yè)是一家上市公司,在全國40余座城市中有近1000家直營門店,整體體量還算是挺大。
整個項目背景是當時O2O電商(即Online線上網(wǎng)店Offline線下消費)發(fā)展迅猛,需要將品牌下所有門店及加盟商打通,實現(xiàn)線上的電子商務(wù)平臺和背后的采購、生產(chǎn)、銷售、倉儲、財務(wù)的一體化管理。
從本質(zhì)講這是電商平臺和ERP兩件事兒,當時就廣義的稱之為ERP項目。雖說是ERP項目,但是它又不純粹。這是由于這家企業(yè)其實已經(jīng)上了一套ERP,用的是用友U8這個產(chǎn)品,那么為啥又要新起一個ERP項目,這是由于它們這個行業(yè)的特殊性,和電商平臺的訴求,導(dǎo)致U8中的物料、組織架構(gòu)等信息已經(jīng)無法滿足這些新的業(yè)務(wù)場景。
再加上之前為了上U8,花費了不少的人力物力,企業(yè)的老板們不想要完全摒棄這一套東西,于是就提議要保留U8的財務(wù)核算功能,重新去打造財務(wù)模塊之外的電商平臺、主數(shù)據(jù)、采購、生產(chǎn)、銷售和倉儲的系統(tǒng)。
所以從系統(tǒng)層面來分析,就涉及到電商平臺與主數(shù)據(jù)、倉儲、銷售模塊對接。整個產(chǎn)供銷過程中產(chǎn)生的原始憑證和存貨核算再與用友U8對接。
講到這里,是不是頭都聽大了。當時也是這個情況,團隊中很多人都不愿意去接這個單子,最后這個項目落到了我和另外兩位老大哥的手上,其余開發(fā)實施人員由項目經(jīng)理領(lǐng)導(dǎo)。那我們?nèi)诵F隊也各有分工,其中一位老大哥和我負責(zé)業(yè)務(wù)調(diào)研、分析和出解決方案,另一位則做詳細設(shè)計文檔輸出,對接開發(fā)實施團隊。
于是一個草臺班子就搭建起來了,我還記得第一天去客戶現(xiàn)場的場景,和我們對接的業(yè)務(wù)負責(zé)人有三位,一位負責(zé)電商,兩位負責(zé)ERP。電商負責(zé)人的態(tài)度是推陳出新,不破不立。ERP負責(zé)人則主張小步慢走,或臥倒不動。
所以當時在會議室就充滿了濃烈的火藥味兒,那時的我哪知道如何化解這樣的矛盾,這也為后面的工作推進埋下了艱難的種子。
記得第一天在業(yè)務(wù)現(xiàn)場調(diào)研,就感受到了電商業(yè)務(wù)負責(zé)人和ERP負責(zé)人之間濃烈的火藥味兒。于是我們后面就展開了分頭行動的策略,周一周三聊電商業(yè)務(wù),周二周四聊ERP,如此一來,確實避開了他們之間的爭執(zhí)。
一個月下來,我們把整個項目的范圍和邊界調(diào)研的七七八八,原本計劃是電商平臺和ERP一齊上線,這樣就可以避免后期方案變動導(dǎo)致線上問題。但是電商平臺負責(zé)人不知道是不是有什么KPI壓力,要求三個月內(nèi)就要上線電商平臺。雙方的高層領(lǐng)導(dǎo)也經(jīng)過多輪溝通未果,卑微的乙方只能將重心調(diào)整,先落實電商平臺的搭建。
這里面就發(fā)生了一些故事,講一個印象很深的細節(jié)。有些讀者朋友可能知道電商平臺中,對于商品管理,有SPU和SKU的概念。舉個例子,一輛汽車,有白色和黑色,那么在電商系統(tǒng)中一般只維護一個商品編碼,然后有兩個規(guī)格屬性。但是在ERP中,這種情況一般是維護兩個物料編碼,便于成本核算和生產(chǎn)計劃的拆解。
當時也和客戶溝通了后續(xù)可能造成的風(fēng)險,但客戶不聽勸,一定要按照電商的標準做。就是為了滿足用戶前端能夠在同一商品下選擇不同的屬性。時間緊,任務(wù)重,由不得想那么多,于是大家只好按照甲方的意思展開。好在兩個月下來,一個融入了眾多甲方想法的電商平臺V1.0.0版本上線了。
接下來的重心就是ERP了,前面說過調(diào)研第一天ERP負責(zé)人和電商負責(zé)人就有分歧。對于ERP物料主數(shù)據(jù)的維護,ERP負責(zé)人堅決要按照屬性分開維護物料,而且長期規(guī)劃只在ERP中維護物料主數(shù)據(jù),其他系統(tǒng)都從ERP取數(shù)。道理是這樣的,我們無法反駁,但當時做電商平臺的時候,電商負責(zé)人可堅持的是維護一個SPU,這不就自相矛盾。
奈何沒有辦法改變兩方的想法,那么就只能換個方向,用技術(shù)換空間,改變系統(tǒng)。以ERP維護的物料作為最小SKU,然后在電商平臺進行二次打包操作,相當于聚合為一個SPU商品,呈現(xiàn)出多個屬性。
這個風(fēng)波當時算是用技術(shù)解決了,但是否真正合理,打個問號。后續(xù)的一兩月就繼續(xù)圍繞著類似這些問題,來來回回的溝通、妥協(xié)、修改方案,項目組可謂水深火熱,每個人盡顯疲態(tài)。
終于ERP V1.0.0版本計劃在一個月底上線,這又是一場硬仗。之所以選擇月底,是因為ERP上線前需要做期初財務(wù)數(shù)據(jù)。這時候前面埋的雷開始爆炸,電商平臺在ERP未上線前就開始了銷售業(yè)務(wù),又加上前面說的商品和物料的復(fù)雜關(guān)系,導(dǎo)致這部分數(shù)據(jù)的銷售成本核算異常艱難。最后通過線上線下數(shù)據(jù)清洗和分析,弄了兩天,算了一個近似值,才算結(jié)束了這個關(guān)鍵的里程碑。
隨著電商和ERP V1.0.0版本上線,我就和前面提到的兩位老大哥退出了這個項目組,算是脫離苦海吧?,F(xiàn)在回想起來,真是一言難盡,只能說給當時的我狠狠地上了一課。
這個項目的整個過程,給了我太多的經(jīng)驗和教訓(xùn),有些方法和環(huán)節(jié)如果控制得當,那么進展可能順利一些,不說有多順利,但不至于如此痛苦。
總結(jié)了下,大概有幾個方面,首先是項目入場環(huán)節(jié),當時就開門見山,直接開始了調(diào)研工作,哪知道方向不對,努力白費,跑得再快也是徒勞。犯的最大的錯誤就是沒有確定好甲方的關(guān)鍵干系人,也叫一把手,需要其能夠平衡電商負責(zé)人和ERP負責(zé)人之間的利益和沖突,起到關(guān)鍵地決策權(quán)。
這樣就能夠避免兩個負責(zé)人之間的意見沖突全靠乙方團隊來平衡的問題,被兩邊牽著走,簡直是吃力不討好,最后兩邊各執(zhí)己見,系統(tǒng)只能兩邊遷就,亂作一團。
這樣的遷就又催生出下一個問題,那就是失去了原則。一再的向甲方妥協(xié),讓講究標準化、結(jié)構(gòu)化、系統(tǒng)化的數(shù)字化軟件工具變得扭曲。這個事就教會了我要堅守原則,做正確的事情固然困難,但困難不是不做正確的事情的理由。
如果上ERP不是僅僅為了面子工程,那擺事實講道理在這樣的大型項目上至關(guān)重要。因為企業(yè)要做管理咨詢,無非就是久病而不自知或者是自知而不能自治,當醫(yī)生通過望聞問切開出藥方后,病人卻不按藥方煎藥要換自己認為正確的藥,這是很難痊愈的,醫(yī)生則是那個堅守原則的人。
有了解決方案后,但是在實施過程中,三番五次的修改,這也是當時面臨的另一大問題。大家知道特別是軟件系統(tǒng)建設(shè),對于流程和結(jié)構(gòu)的調(diào)整有多痛苦,好比炒了番茄蛋,要吃青椒蛋。
關(guān)于如何解決這個問題,是后面和四大會計師事務(wù)所之一的德勤公司,合作的一個500強企業(yè)ERP項目中找到了答案,后面再去詳細分享我在這個項目中的故事。這里只聊一下這個項目是如何處理方案變更問題的。
當時,在項目上劃分了幾個關(guān)鍵里程碑,就有項目調(diào)研、藍圖設(shè)計、詳細設(shè)計、項目實施、驗收培訓(xùn)這幾大環(huán)節(jié)。在每一個環(huán)節(jié)產(chǎn)生的交付物經(jīng)過雙方評審后,均需要企業(yè)的關(guān)鍵用戶和一把手簽字蓋章確認。只有落實清楚再開展下一步工作,這樣做的目的就從流程上控制了甲方變更方案的風(fēng)險。
最后就是多系統(tǒng)交互,當時的數(shù)據(jù)流向呈現(xiàn)混亂狀態(tài),導(dǎo)致系統(tǒng)建設(shè)乃至后續(xù)甲方運維工作都很不便利。這讓我明白系統(tǒng)搭建之初,對系統(tǒng)上下游的界定、系統(tǒng)的優(yōu)先級層次、數(shù)據(jù)結(jié)構(gòu)、傳導(dǎo)方式等的提前確定有多重要,為后續(xù)實施階段起到關(guān)鍵避坑作用。
這個故事就分享到這里。
本文由 @產(chǎn)品真經(jīng) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)
僅個人想法:不太理解你說的SPU和SKU對于兩個業(yè)務(wù)方的沖突點在哪里?
– 電商要一個SPU,ERP要SKU,這是業(yè)務(wù)屬性;
– 實現(xiàn)上SPU對SKU,為1:N,可以分開編碼,給電商邏輯只展示SPUID,給ERP展示SKUID;
業(yè)務(wù)不關(guān)心你怎么實現(xiàn),按他需求給他處理就好了;
所以這個不是業(yè)務(wù)矛盾,應(yīng)該是產(chǎn)品方案設(shè)計啊
是的 這里我也沒讀明白 電商要求一個用戶端在一個商品下選擇不同的屬性 看起來是一個正常的需求呢 不知項目組原本是打算怎么去實現(xiàn)?
項目經(jīng)理不作為也是一大原因。
項目開發(fā),基本都是在妥協(xié)中進行,像我們純乙方,和甲方溝通也就是在初期,大部分甲方確認方案后其實就不會太過多對已有功能指手畫腳,最多是臨時加點新需求或壓縮工期。即時是這樣的甲方,在溝通上不出問題的情況下,開發(fā)過程中內(nèi)部都會不可避免地遇到很多問題,需求確認和評估階段和開發(fā)溝通好的效果,在開發(fā)過程中不斷變形,要求逐漸從好用下降到能用能交付就行;從產(chǎn)品角度而言更多是無奈,全都縫縫補補給優(yōu)化好,工期肯定不夠;只是能用的程度拿去交付,后期再進行維護優(yōu)化,客戶不愿意增加成本,項目組又接了新項目,沒辦法再兼顧已交付的項目,越做越無奈;市面上的項目和產(chǎn)品都是早就玩爛了的東西,大部分公司不會劍走偏鋒搞創(chuàng)新,不會有過多不明確或者沒見過的需求,參考市面上的產(chǎn)品和項目做調(diào)研,不會花太多時間基本都可以明確需求和架構(gòu),相比于團隊項目經(jīng)驗和實力,個人感覺一個團隊有好的項目和流程管理更重要,大部分項目出問題都是在項目管理混亂