許是曾有幾文承朋友看重,近受朋友相邀寫篇關于企業進行ERP選型的文章,說老實話,感覺這的的確確是個很好的題目,但又幾次猶豫不敢落筆。說好題目的因由是看國內企業實施ERP失效累累、怨氣滿天,這些實施之痛怕是最初的選型難以避責的。講遲疑落筆,又因若要講透ERP的選型,就必須能夠分析清國內企業實施ERP效果不佳的原因,如此反溯在ERP選型中需要注意的事項。很多時候,結果實是前期注定的事,在我們守著殘破怨恨的系統,用不順又丟不得的時候,可能最該反思的是我們當初選型時的決策。分析國內企業實施ERP失敗的文章很多了,講一把手工程也好,講管理基石優于系統構建也好,更有企業領袖談的“上ERP是找死,不上ERP是等死”或穿鐵鞋的“僵化、優化、固化”都似乎在強調ERP這個系統讓企業又愛又痛。
所以在我們談ERP選型之時,怕是還該細致的理解ERP到底是什么?ERP能夠幫助到我們什么?為什么現實中又沒能幫到我們?我們實施ERP期望最終的目標或要解決的問題是什么?在我們期望ERP幫助我們達到目標或解決問題時,我們還需要準備什么?而我們現在的情況是什么?
大約在去年年初的時候,曾同一個正在準備實施ERP的老板見面,交流中曾直接詢問這個老板,最初決定上ERP的動因是什么?期望ERP解決什么問題?老板說最初是因為說上市需求,后來也是期望能過實施ERP能夠把企業管理的方方面面看得更透徹,從而控制和降低生產成本,有效的幫助企業進行決策。就這位老板后一點的想法,我們認為他的期望應該也算是合情合理的,我們講企業實施ERP,通過信息化建設使企業物流管理透明,資金流管理可控,信息傳遞及時準確從而提升企業有效決策。但實際上這家企業花了兩百多萬上的系統,由最初計劃的十月份上線,拖到年底上線,再拖到今年二月份上線,又拖了一個月到今年三月份據說終于上線。歷經萬苦這個是否算成功了呢?是否磨難歷盡達到那位老板最初的期望了呢?估計這尚需要打個大大的問號。正常情況下,我們認為推動和促成ERP上線并不難,真正難的是使ERP發揮效用,真正的能夠幫助到企業達到降低生產成本、縮短交貨周期、提升決策能力。而該企業按預計的上線計劃多次延遲,且不論這是甲方還是乙方的責任,至少雙方對項目難度的預估就有偏差,項目風險控制失當,如此狀況的確讓人對后期效果產生疑慮。
漫談ERP選型四問

ERP到底是什么?
回到我們最初提出的第一個問題,ERP到底是什么?如果我說ERP就是相當于過去賬房先生用的算盤的話,估計很多ERP的從業者會很生氣。如果再看到筆者舊作的《ERP是鐵圈,軟件商是鐵匠鋪》,怕是更會被從業者怒斥筆者坐井觀天是否曾為鐵匠鋪所傷之事了。
其實也是,如果說ERP只是個算盤的話,那怎么還會那么難產生效果呀,道理很簡單,你如果用拿鋤頭的方式去使用算盤,怕同樣是數沒算出來,算盤先壞了。這時講的無論是算盤還是鐵圈的含義是說ERP只是工具,只不過就鐵圈的含義來講,這個鐵圈是前面很多獵戶根據自己的需求和習慣要求改進過了的,其用法和環境因素決定著鐵圈是否能夠發揮效用。
ERP能夠幫助到我們什么?
作為信息存儲、傳遞、計算的工具,ERP的的確確可以幫助我們提升管理水平,但這個前題是,信息存儲的是正確的,傳遞的是正確的,這樣才可能產生正確的結果,這就是在講ERP進去的是垃圾出來的也是垃圾一個道理。而信息的傳送需要的是具備正確的流通管道,否則信息管道不暢且不說可能傳遞失真的信息,既便是當時輸入的是真實信息,等到輸出端,因為時效因素,真信息也變成假信息了。這也是我說前面那個老板實施了ERP未必就一定會達到他的期望是一樣的道理。
就理論上來說,ERP的確是應該對我們的企業經營帶來幫助的,但現實卻是國內眾多的企業花了很多錢,實施的ERP效果卻不盡如人意,最終只是變成了財務或者庫存管理系統。為什么明明可以幫助企業提升經營效率和管理透明度的ERP系統在現實中卻又往往成為企業經營者抱怨的對象呢。
我們前面提到若使ERP系統能夠真正有效的幫助我們,信息管道的建設就尤為重要了。講這個管道建設,實際上就是我們經常提到的業務流程,這個就如同若要有效的發揮鐵圈的作用,首先獵戶要了解獵物的習性,知道在哪下套更為合適一樣。相同的獵物在不同的地區,也可能有不同的習性,獵戶狩獵必須了解獵物習性,才可能有效的利用相關工具捕到獵物。而新的獵戶,拿到別人的獵捕工具,在自己不熟悉的情況下,至少需要對別人的使用方法進行了解,而后結合自己的實際情況加以優化利用,這個同“僵化、優化、固化”是一個道理。
ERP選型的目的是什么?
正式開始談ERP選型時,還是要明確選型的目的,就是我們要明確這筆投資是為了達到什么目的,期望收獲什么回報。而后再結合企業的實際情況分析這種投資是否能夠獲得相應的回報,也就是可行性分析。另外還需要考慮的是,此次投資對未來三五年會產生怎么樣的影響,以免今天投資的錢,在系統還沒有上線時,企業結構發生變化了,需要重新再投資。以中國第一選型失敗案例河南某企業為例,最早期的選型是美國的SYMIX系統,在企業系統實施尚未上線時,企業經營結構發生了變化,各車間、大部獨立為公司了,結果原SYMIX不支持集團化管理,沒法再往下全面實施了,最終只在其供應處上了系統,后來在制造上了是K3,再后來全部推倒換EBS,時隔一年多后,在國電集團要求下再換成了SAP。象這種替換系統顯然是缺乏整體規劃,這也就是國企有錢,但民企同樣也可能會犯類似的錯誤。
如果說企業上ERP是為了宣傳或者上市增加一些名聲,只是為了對外宣傳的話,那么上ERP無論怎么選型都可能容易達到他們的目標的。但如果是期望通過實施ERP真正的能夠降低庫存、壓縮生產準備時間從而縮短交貨期,那就真的需要對企業現有運營中的問題進行分析,理清通過完善信息化手段是否就能夠真正的達到這個目的。類似存在帳物不清,月盤點都很少進行,產品變更流程混亂,現有BOM清單各部門各一套,各車間生產進度自行調節,在這種情況下,首先需要解決的就不是上ERP的問題,而是企業業務流程梳理的問題了。
筆者曾在重慶某企業集團進行調研,企業一個事業部的生產科長同我們報怨到說產品BOM混亂,他個人理了三個月都沒有理出來,其實這個很正常的,在流程沒理順時,你在清理舊產品BOM時,新的問題還在持續的產生呀。另有一次在吉林某企業,那個企業的庫存物資有很多連庫管員都無法識別出是什么,就更別提如何進行管理了,為此企業的總工程師建議說,如果不行的話,我們就組織全廠清理一次庫存,重新對物料進行編碼,在編碼中標注出這個物料是為哪個產品所使用的。大家仔細想想,這種方式不是正在制定大范圍的一物多碼的現象嘛。這樣的狀況下實施ERP可能產生效果嗎?但講老實話,這些問題ERP顧問是較少給企業有效建議的,當然他們也會提必須要一物一碼,但如何實現卻需要企業自己去理清,這個并不是說ERP顧問不負責,他們更多的長處是在其自身產品本身的應用上,另外就如同我們在前面中提到的一樣,他們由于自身的經歷與擅長方面的專項發展,在業務層面上較少可能給企業實質性的建議。那么是不是說這種情況下,企業就不適合上ERP呢?筆者認為在這種情況下同樣是可以考慮推進ERP項目實施的,只不過是在方法方面要有所考慮,在選型的同時,需要考慮到企業現狀,有策略的采取不同的措施來保證ERP實施的有效性。
在考慮ERP的選型時,還需要考慮到此次選型重點要解決哪一方面的問題,同時兼顧到未來其它方面的需求,否則就可能人為的利用信息工具造成企業內部信息壁壘,如有些企業,在這家選了套HR系統,那家選了套CRM系統、第三家又選了PLM系統,再加上原來不同廠商的ERP、OA系統,整個企業業務部門各站山頭,各行其事。這也并不是說所有軟件選型只能找一個軟件商,因為各軟件商的產品側重點可能不同,長處也不同,但在選型之初,至少應該考慮到三五年的發展,考慮到是否需要信息平臺最終的整合可能性。更有的企業集團,在不同的子公司獨立上的各自的單組織管理的ERP系統,企業與企業發生買賣或者內部交易協同,甚至集團報表方面都增添很多的麻煩。
很多國內企業強調做大,而且也的確國內商機較多,于是企業是四處開花,一個產值幾億的企業就可能是涉獵到不同的業態擁有多家子公司的集團企業。另外時代推動著企業經營模式的變革,很多企業開始考慮專業化管理的需求,在中心大城市設立研發基地、營銷中心以期獲得優秀的人力資源,而在偏遠地區設立生產企業,以期降低勞動力成本。這些都需要企業在選型階段加以考慮,當然也不是說考慮選型的系統會一直伴隨企業一生,但至少要考慮到能夠支撐企業可預見的發展狀況。前不久曾同一個集團老總進行交流,說前些年上的一套HR系統到現在也沒能用起來,原因是企業組織結構經常發生變化,而這種變化,使系統難以支撐,結果難以使用。
總結上述觀點時,是在論述企業在選型之初需要考慮到實施ERP最期望的是要達到什么目的,是否實施了ERP就可以達到這個目的,企業還需要進行哪些準備或者提升來確保實施ERP能夠達到期望目的目標。另外在考慮選型時,還需要考慮到企業在可預期的三五年里的變化情況,能夠使信息化支撐企業未來三五年可能發生的變化。
在我們講完選型的目的后,我們再來分析選什么。選型的目的是在講我們期望通過實施信息化所能達到或者收獲的成果,選什么是指我們在選型中需要側重關注哪些方面可以恰當的補充我們前面討論過程中的不足因素,從而確保最終結果離我們的期望最近。
我們在前面中講的最主要的內容實際上是分析國內外企業管理模式的差異,國內企業現有管理狀況與ERP系統應用思想(或誕生于西方企業管理模式上的ERP架構功能理念)的不同,從而找出為什么國內企業實施ERP時,連MRP都跑不起來的原因。
其實這個道理不難解釋的,就如同房地產行業的信息化建設基本上是由國內軟件控制的,為什么呢?因為中國房地產行業的迅速發展,而國外沒有類似行業成型的信息化,或者是同國內方式不同,伴隨著國內企業的信息化需求,且一定是國內企業主體業務的需求,軟件商加以配合開發的房地產行業的信息化管理軟件,這實際上同那篇【ERP是鐵圈……】一個道理的。那為什么在制造行業,就不能產生完全符合國內企業管理模式的軟件呢?這是因為企業在市場環境競爭過程中比拼的是經營實力,而在制造業西方的管理模式是遠超于國內企業的,在WTO把保護我們的圍墻打開以后,外資制造業大舉進入中國,我們國內的制造業需直面外企的競爭,同時在這個過程中也需要不斷的學習優秀的企業管理方式。其實我們也有基于國內企業管理方式的信息化系統,類似如前些年企業自行開發的,簡單的把手工作業轉為電腦中的MIS系統。當一個市場被充分開放后,先進的技術總是易于被模仿的,國內的管理軟件廠商基本上是善于總結國外管理軟件的特性,所以管理軟件的功能易具有趨同性。只不過是技術易于模仿,而管理卻難于移植,我們很多企業實施ERP實際上是用拿鋤頭的方式來擺弄算盤。這也是我們很多企業ERP失效的一個原因。
另外在某些行業,如商貿或者流通領域,其管理與應用的復雜程度相對較低,同時國內企業經營的財務制度又必須依照國家政財部的規定執行,所以在國內商貿流通行業實施信息化的難度是遠小于制造行業的,既便是制造行業,財務軟件實施的成功率其實也是很高的,只是在涉及到業務層面時,效果就會發生翻轉,而財務數據是源于業務的,所在固然財務軟件實施應用效果普遍不錯,但財務信息的真實度仍然是讓企業管理者都為之疑惑,難以查找到業務數據匯總過來的問題所在。
為此,在我們企業進行ERP選型時,需要明確我們所處的行業狀況,我們自身的管理狀況,我們企業未來三五年的經營戰略方向,從而決定我們在選擇ERP時,是重點選擇合作伙伴,還是選擇信息化支撐平臺或者僅是選擇適合我們的功能軟件。
假設我們的企業處于成熟行業,且管理相對簡單規范,或者管理體系較為成熟,再或者成功實施過類似的信息化系統或者軟件,并且如庫存、交期管理都取得過不錯的效果。那么可能我們的選型重點是放在軟件功能是否滿足我企業的實際業務需求方面。
如果我們企業所處是新興行業,或者是行業的領軍者,具有不斷的創新管理意識,這個時候,可能我們選型是重點是需要關注信息系統的平臺是否滿足企業未來發展創新的需求,這樣的企業往往有自己的信息化管理團隊,企業業務需求往往是現有標準產品無法滿足的,實際上這樣的企業最終的信息化成果往往成為行業管理軟件的標準,引領著行業管理軟件功能的完善。
最后是我們國內企業較為普遍的,自身管理狀況較弱,寄希望于通過ERP的實施來提升企業管理水平的企業群體。對于這樣的企業,其實不只是需要考查軟件產品的功能,更期望的是得到軟件商在管理流程方面的建議,實際上是在選擇合作伙伴,雖然這個愿望最終普遍性的落空。
對于這類企業的建議,其實引入第三方的獨立顧問,幫助企業推行信息化實施可能更為有利,這個主要原因在于,在完整的信息化項目實施過程中,企業需要面臨著項目環境、組織變革、流程調整、技術決策、項目管理等種種風險,面對過往項目的失敗教訓以及業界對ERP實施成功率之低的恐懼,如何控制和化解。另外企業內部IT項目管理人才匱乏,許多企業過去未曾實施過ERP項目,內部無IT項目管理經驗的人才,更沒有真正意義上的CIO,缺少同時具備豐富的業務管理經驗和信息化實施經驗的人才。既然內部沒有專業管理人才,因此引進站在企業角度的具有豐富業務與信息化實踐經驗的外部顧問,幫助企業有效的規避風險,既可以做個放心項目,又可以為企業培養相關人才。外部顧問應該具備多年不同企業的信息化管理經驗,同時具備優秀的企業的高層的實務管理經驗,具備企業通過實施信息化變革的成功推行經驗,這樣才能更有效的幫助企業。
ERP實施失敗的原因
我們可以用一個最為現實的例子來分析國內企業ERP失效的原因,就如同我們前幾天在管理漫步中討論過《MRP實施效益與業務實踐》中提到的,制造企業推行ERP,往往是上成了財務和供應鏈,而MRP卻跑不起來,或者跑起來卻不具備實際指導意義。其最終的結果是采購員仍然是利用EXCEL來算采購需求數或者依據需求部門的申請,再錄入到ERP系統中,這顯然是徒增了采購員的工作量,而并沒有給他們帶來幫助和便利,由此最終業務部門抱怨上套ERP就是為了財務服務。如此狀況,業務部門最終是迫于公司的壓力沒辦法補錄的相關單據,并認為是在替財務部門做財務部門應該完成的工作。
那么為什么MRP在很多國內制造企業無法發揮效用呢?是MRP本身的問題嗎?筆者96年在日企主導推行當時還稱之為MRPII的軟件,通過MRP的運行,庫存從實施ERP(當時稱MRPII)之前的0.6個保有月數(月庫存金額/月銷售額)降到0.3個保有月數。筆者當時曾問生產管理部的計劃課長堀君,其回答“當然是MRP的效果”。那么是什么原因使外企在90年代就能取得的成果,在21世紀我們很多國內企業還不能享受到呢?
我們都知道ERP本是個泊來品,其最初產生和應用于西方資本主義的市場經濟條件下,是企業尋求降低成本有效控制物流管理的一種工具,其尋求的是以最低的庫存提供最大的客戶滿意度,并在企業相互競爭中不斷的得以完善,而支撐系統有效運行的是企業的運營管理體系。那么國內與國外的運營管理方式有什么不同嗎?
中國是從半封建半殖民地社會一下跨越到社會主義,在建國初期,工業化程度極低。建國后,百廢待興,依照蘇聯模式,我們推行的是計劃經濟。當建國初期,計劃經濟集中優勢資源統一調配,在所有物資供不應求的年代,極大的促進了國民經濟的增長。當時企業經營強調的是以生產為中心,開足馬力,協調資源最大化的生產,由此最具代表性的生產一線的調度管控體系在工廠發揮著極大的作用,而計劃管理則形成虛設。反正生產什么,生產多少都是國家定下來的,生產是不需要考慮銷路的。在國內改革開放之前,在企業界有個潛意識的看法,如果一個企業的中層干部被調到計劃部門,就意味著此人失勢了,因為當時計劃部門的職責就是向工業局或者經委遞送報表的工作。實際上,既便是改革開發很長一段時間里,同樣很多企業的計劃員也只是充當簡單的把整機計劃分解發送各車間及后續進行統計相當的工作。
以國內生產組織模式來看,生產作業計劃(零件計劃)按月編排,每個月內各個車間的生產作業日程計劃是各個車間根據自已的情況編排的,他們可以把某個零件的加工作業時間排隊在月初,也可以排在月末,只要在本月完成即可。如果某個零件在一個車間內可以單獨完成,那么它的作業時間,在生產計劃部門那里認為是1個月,實際上該車間可能只需要幾分鐘就完成了。問題是如果該零件需要跨車間,比如說需要兩個車間的兩道工序才能完成,那么在生產計劃部門那里,就認為至少需要2個月的時間。
可以想象出來,如果某個產品有上百的零部件需要加工,其中有許多部件需要多個車間多次合作才能完成,原來的計劃周期就會延長到數月甚至一年多,其實這些零件的純工藝時間可能只需要幾個小時或幾秒種。
跨車間協作時,為什么不能在一個計劃期內實現呢?因為各個車間在編制自己的日程計劃時,不知道其他車間的情況。為什么生產計劃部門不能直接編制各個生產車間的作業計劃呢?因為計劃部門不了解車間現場的情況。
傳統的解決方法是:盡量把一個零件的所有工序安排在一個車間內部。企業人士稱之為半封閉式車間,即按對象專業化布局的車間。計劃經濟時代,國有企業比較普遍地采用對象專業化布局的方式,但在市場經濟環境下,越來越多的企業即不得不改變這種工廠布局方式,因為現在的生產工藝越來越復雜,生產設備的專業化要求企業采用工藝專業化布局方式。例如,高精尖的數控機床需要集中起來配備專門的技術人員進行管理。工廠布局的改變,許多企業現有的計劃管理方式無法適應,它極不合理地拖長了計劃中的生產周期。企業各級管理人員當然也認識到了這個問題,但是他們卻依靠加強調度指揮力量,來解決生產過程中頻繁出現的協調問題。
調度管控體系由于各車間生產狀況互不了解,而在面臨的外部市場壓力的情況下,客戶需求又需要保證,為此經常會發生銷售員或者內勤或者工廠長緊急催促組裝車間的生產,特別是在客戶需求臨時變動或者緊急插單的情況下,經常形成了組裝車間向上游車間發出緊急缺料單,由此聯動的緊急,打破了原有的生產運行計劃,又導致采購部門的緊急采購,產品的不齊套又導致庫存物資的不斷積壓。
而西方市場經濟強調的是企業以市場為導向,企業生產了如果沒有銷路,則意味著企業需要承受虧損甚至倒閉的風險。因此企業在市場開發、需求調研方面需要更為認真的考慮,如何使自己的產品更能受到客戶們的歡迎,而無疑,如果產品能夠相對于競爭對手的價格稍微便宜一些、質量稍微好一些、交貨時間稍微短一些,那么爭取到客戶的機率就更大一些。由此企業運營的核心是關注客戶眼下最迫切的需求,需求企業各部門圍繞的同步的是客戶的需求。在管理方面強調的不是以生產為中心,而是以經營為中心。落實到具體業務層面上講就是企業的銷售部門重心是在市場與客戶身上,而在企業內部則是以計劃為中心,協調相關部門在相同的時間,完成各自的工作最終的目標是保障最優先的產品,最優先的生產出貨。通過計劃部門的強有力控制,使各車間生產進度協調同步進行,永遠保持最合理批次,最優先生產順序。在任何一個環節出現問題時,信息首先由反饋到計劃部門,并視情況是否可以通過其它方式(選別、特采、外協)來進行調整,并在第一時間做出反應。而這點反應到ERP系統中就是MPS、MRP的運用。MRP強調的對物料的有序管控以期實現不早也不晚的制造或者采購不多也不少的產品及材料。以便實現用最低的庫存提供最大的客戶滿意度。而MRP的實現又需要具備如下四個條件:唯一的主生產計劃、唯一的物料識別(代碼)、準確的BOM、準確的庫存記錄。
由此又延伸出國內企業的管理問題,以唯一的物料代碼為例。在計劃經濟時代,國內產品的研發方式是以產品為中心,就是研發出一個產品共零部件往往注有產品標識,以標識此部件為此產品設計,但實際上產品的零部件又存在共通的可能性,雖然在能夠識別出的或者知道的零部件,在實際生產中會被加以“借用”,但同樣這種設計研發方式會造成大量的一物多碼現象的出現。另外包括工藝變更控制往往在生產現場根據實際狀況改變,造成了BOM不準確,粗放的現場材料管理造成的庫存數據的不準確,由此種種造成了既便是你運行MRP,數據也不敢為業務部門所用。由此在企業內部形成業務部門一方面仍沿用舊法管理著生產,另一方面又加班加點無奈的補錄著ERP的數據。試想一下,這樣的系統能讓業務部門滿意嗎?這樣的系統能夠幫助企業增加效益嗎?這樣的系統能實現前面那位老板的期望嗎?
那么我們在實施ERP的過程中,ERP顧問是否可能幫助我們理清流程,幫助我們完善管理,從而使ERP在規范的體系下有效的運用,從而提升企業贏利水平呢?這個問題其實企業老總最好能自己仔細思考一下,ERP實施顧問多數是IT出身,他們既便是有工廠經歷的,多數也未必有企業管理崗位的經驗,他們會比在企業工作過多年的干部職工們更懂企業管理嗎?單只一個庫存管理,如何提高庫存準確度,就有很多影響因素,甚至企業自身多年都沒有搞準確過,這些顧問會有辦法搞準確嗎?就更不要提業務流程梳理與優化了,也更不要提如何有效的進行供應商管理(評審、評價、扶植)以保證其有效交貨的準時性了。而ERP信息系統是假設系統中所有數據是真實的,在滿足假設條件下才使其建議具備可參考性。生產制造型企業的復雜性在于,哪怕是相同行業、相同規模的企業其管理風格也是不同的。ERP的功能顧問是否具備結合不同的企業經營特性風格,甚至于人員素質制定出有效的實施策略來呢?這個怕是企業老總自己也需要仔細考慮一下。而在企業變革過程中最難的又是人的改變,人的思維習慣的改變,強制,不理解的強制是難以取得好的效果的。
前面我們僅以某一點展開分析了國內企業實施ERP在流程與管理差別而造成的失敗原因。很多資料上講實施ERP要一把手重視,要一把手工程,其實筆者并不完全贊同,或者說認為這種說法不完全。我們在講實施ERP的一把手工程時,要能講清讓一把手在這個工程中干什么?你是讓他去整理基礎數據呀還是讓他學習操作?或者讓他督促業務部門推進工作?可能他自己都不知道如何推進的,而且他每天也一定有很多企業正常業務需要開展的工作的,總不能讓他放切一切來搞ERP吧,那樣的話,很可能ERP沒上線呢,企業倒掉了。
另一方面筆者也認同ERP的一把手工程,筆者認為這個一把手工程不是要求一把手學ERP的功能操作,而是在管理體系與流程方面認真分析學習與研究,從管理流程變革與改善方面下功夫,可以走出去向優秀的企業取經,也可以請進來同優秀的顧問交流或請優秀的顧問來診斷,這個顧問指的絕對不是ERP實施顧問,其原因前面已有分析。上有所好,下必焉之,當企業決策者真正開始關注管理提升時,才可能帶動企業中層干部們開始考慮是否還有更好的辦法來改進管理,也促使他們主動性的尋求相關的改善工具,使他們主動的配合和推動ERP的實施,從而化解所謂的“上頭急下頭急中間頂門杠不急”的狀況。實際上當企業決策者真正思考如何把握的管理問題理清了有效流程,那么在選型階段對甄別軟件功能也就有的放矢而不是任憑軟件商忽悠了。
有一點相信我們都會認可的,那就是如果單憑軟件就可以提升管理的話,那么只要我們買得起500強用的軟件,我們就都可以成為500強了,顯然這是不現實的。淮南的桔子到了淮北就成為了枳,我們在憂嘆花錢沒得到期望的效果時,還需要考慮我們是否創造了環境并恰當合理的運用了這個工具。前面我們談過了ERP的工具化屬性,又談到了ERP這個泊來品的出生地的企業管理運模模式與國內的差別,接下來的話題才是要開始談ERP的選型了……
ERP選型的八個要素
前面我們提到是為啥選?選什么?接下來我們要談的是如何選的問題。國內快速成長發展的經濟環境,創造了中國經濟的奇跡,同時使市場的誠信交易面臨具大的挑戰,在企業的ERP選型及實施過程中,由于市場不規范,一批公司不顧自己的實力、信譽、資質,只為眼前利益將項目爭取到手,結果建設了一批又一批的“豆腐渣”工程。另外由于前面提到的ERP是IT技術與管理思想結合的管理手段,而很多軟件商的顧問多數是熟悉自身的產品特性而缺乏對管理思想理解和管理經驗的沉積,故而其在企業推行信息化過程中也更多的只能是依據產品本身的功能而不是幫助企業理清管理問題針對性的推進信息化進程,由此同樣造成一批又一批的信息化“豆腐渣”工程。所以理性選型,分析清自己要干什么,自己還缺什么,通過什么方式來得到補充保證猶為重要。
就ERP選型實際過程,筆者大致列出如下步驟:項目規劃、招標發布、需求調研、方案呈現、產品演示、樣版客戶參觀、工作任務書確定、商務談判。企業根據實際情況可能會對選型過程進行調整。在項目選型的實際操作過程中,企業也可以結合自身實力考慮引入外部顧問參與選型評審,同樣很可能存在外部顧問只參與評審而不對最終項目效果負責任的情況。在此企業如果只是單純的引入外部顧問僅限于選型評審時,建議要能夠使外部顧問的知識轉化為企業知識,并消化吸收,評審最終結果還是需要由企業負責。雖然這個環節可能會因聘請外部顧問參與會發生費用,但如果真能有效控制了項目風險,這點投資其實是很值得的。想想國內有多少制造企業可以自豪的講,企業花了幾十萬、幾百萬甚至上千萬實施的信息化工程,真正的幫助企業降低了庫存、縮短了生產周期。
一.項目規劃:
我們在前面講了很多內容,實際上要解決的就是我們為啥選?上什么?有什么?目標是什么?怎么達成目?強調的就是要首先分析我們制定怎樣的規劃更有可能保證我們達到預期目標,但這個環節被很多企業忽略掉了,也因此相當多的企業花了很多的錢實施ERP卻看不到效果。橫向系統集成與企業階段上發展應用,縱向結合企業目前管理狀況與ERP有效運行環境對比差異,及改善策略,最終決定選型方式。在這方面如果企業自己缺乏認知和能力的情況下,我們是建議企業通過聘請經驗豐富的第三方獨立顧問或者與相關機構合作進行。
在開始提到的一再延期的項目,以及前面提到的一再換產品的集團公司的項目問題都是沒有進行有效的項目規劃或者根本沒有進行項目規劃。
項目規劃不只是結合企業發展目標,分階段實施信息化系統,更包括對企業管理現狀與問題的分析對策,在流程得到優先或管理得到提升后,通過信息化工具進行固化,以提升效率,而不是通過信息化實施就能自動的消除問題。這個實際上很多企業在選型階段對于這個問題沒有仔細的思考過,很多情況就是老板聽說實施ERP可以給企業帶來效果,可以解決庫存多的問題,于是就讓信息部門找幾家軟件公司,來同業務部門或者直接同信息部門交流調研一下,各家再加回去弄個方案,也可能要求進行產品演示,最后報個價,就確定了。
而企業一旦上套,很多時候就是受制于軟件商,除非你能夠忍痛割肉,而且企業最為擔心的還有怕對企業正常運營造成影響,這也是當應用一半時,卻又不敢全部拋開、丟不得的一個原因所在,除非再次全部重新選型,但往往這個時候,如財務部門可能也會提出要求,不要動財務部份以免影響公司穩定又選成再次選型的困惑。
有位朋友曾在我們管理漫步中介紹過他們企業經歷過的一次實施,說他所在的企業在選型時,在滿足基礎功能的前提下,只對比價格,最便宜入選,忽略了實施團隊和服務,最后上的系統多半是爛尾工程,因為支持不到位,回到之前說的:軟件方達不到簽約之前說的效果時,軟件公司總經理親自上陣談驗收以促收尾款。在聽了3-4個鐘頭企業客戶的抱怨之后,軟件公司總經理說了:我們的產品就是這樣,再需要改進不需要再加錢進行客制化開發,而且我們前期也投入了很多顧問資源的,如果再不能驗收結款,我們也沒法再繼續提供服務支持了。而客戶方也不敢冒然談崩,畢竟服務還是要的。最后結果往往是各讓一步,企業付錢免強湊合使用能用的功能,軟件商繼續提供服務支持,就這樣上百萬的ERP系統就變成了財務、供應鏈系統,而業務部門工作沒有得到便宜的情況,更多的是抱怨ERP系統的實施使他們增加了替財務部門錄入單據的工作。
另有一位業內人士對國內中小企業實施信息化有過另外一種情形的描述,他說“因為接觸的同行多了,國內中小企業最多。最初沒經驗的就會用K的、Y的或者T的,3家軟商商互相忽悠,如果實施沒達到效果,差不多都會考慮換系統,換了系統 又要第二次實施又沒效果,就換更加貴的高級咨詢。我用K的,遇到過開始用Y的效果不好被忽悠用K,用K的被忽悠用Y,或者K的Y的被忽悠用T”。應該說前面這位朋友對國內中小企業的信息化選型及實施描述的相當形象。包括一些有錢的大企業也是一樣,可能最初實施的是ORACLE,用的效果不好,便又換成SAP,但卻似乎從未認真分析過原先的實施為什么沒有達到效果,很多時候都是自欺欺人的把所有問題歸結到軟件上面來。要知道,同類型標準化軟件產品在功能方面本身就有很強的趨同性的,既便是這個功能你有我沒有而企業又熱衷這個功能時,很快沒有這個功能的軟件商就會在下一版本中推出相似的功能來的。
由此可看,項目前期規劃是極為重要的,但實際上,很多企業卻忽略了這塊極為重要的工作,更多的企業是因為這樣或者那樣的原因就拍拍腦袋決定要上這樣或者那樣的系統。充其量是由軟件公司幫助列出個三年的信息化規劃建議,如第一年上財務、供應鏈;第二年上計劃、生產;第三年再實施商業智能分析或者PLM、MES、CRM等產品的擴展性集成以及集團管控、風險監控等內容。而這些實際上往往忽略了企業自身的管理狀況,沒能從分析企業業務問題現狀出發,幫助企業進行流程優化,或者如我們前面講過的加強及完善流程管道的有效建設,在這種情況下單憑信息化手段是難以達到目標的,而這種分段階實施的信息規劃,名義講是支撐企業發展戰略的規劃,實際上去很難有效落地。
我們常講信息規劃是要支撐企業未來三五年的發展,而從如何使企業發展目標真正實現,既要分析企業未來的目標,更是要分析企業當下的管理現狀,從而確定企業未來的發展所需要落地支撐的工具,在我們期望借助信息化手段支撐企業戰略發展的同時,我們首先必須清楚的分析企業管理從組織框架到業務流程的立顧順問題與改善策略,這就如同我們在上篇談了很多國內企業流程存在的問題一樣,這些問題不能有效分析,就無從提出有效的流程優化建議,那實際上也就難以實現企業所期望的通過信息化支撐手段達到企業經營戰略的發展目標。
信息規劃流程一般包括企業管理診斷與IT能力評估、信息化管理基礎提升、IT規劃、系統選型規劃等幾部份。企業管理診斷及IT能力評估重點是對企業現狀進行分析,并結合企業未來發展戰略目標進行分析,找出關鍵性問題以及需要重點解決的對策。信息化管理基礎提升重點是對企業包括運營模式的優化(如是否建立研發中心、營銷中心、生產中心、分區域物流中心);業務流程的優化(從以生產為中心向以企業經營為中心的轉化);組織結構的調整(使權責利與管理職責有效結合,避免問題發生要么找不到責任人要么全是責任人的狀況);其它結合企業實際需規范性處理事務等。IT 規劃是在前兩項工作的基礎上進行的使業務實踐與信息化相結合的分階段分步驟推進的工作規劃,包括企業業務重點需求、網絡布局以及系統集成的考慮。最后系統選型規劃是在以上述工作為基礎,完善系統選型方案內容,包括下節我們要提到的招標書的相關內容,確定企業選型的重點是以功能性為主還是以系統大平臺建設為主或者以選擇合作伙伴為重點進行選擇。同時從企業自身角度確立信息化系統實施指導性方案建議。
二.招標發布:
在招標書發出前盡量了解管理軟件市場大致狀況,根據所屬行業、公司規模及生產特點來邀請相匹配的ERP廠商參與應標。甚至可以邀請國內外軟件廠商共同競標,既有利于拉低價格,又使競標水平有所提升。在發標同時,企業應結合項目規劃的需求設定評分表,可根據情況進行重點考核,并依重要性設定不同的評分標準。一般的管理軟件評分表會包括如下內容軟件服務商資格與信譽:服務商公司規模及財務業務穩定性、核心業務及范圍、本地化支持能力、產品在軟件商所有產品中的位置及發展前景。
需要注意的是軟件行業的特點就是人員流動較為頻繁,很可能同去年代表某個軟件公司同你談合作的業務員,在次年再次選型中就代表其對手公司出現了。因此軟件公司的業務員們特別是同一個城市的軟件公司,彼此都可能很熟,他們既是競爭對手,同時也可能成為合作伙伴。以國內知名的兩大軟件商為例,在國內各大城市都有分支機構,且對其中低端產品又推行了代理商制定,軟件廠商為了不使代理與直銷機構競相壓價,擾亂市場,實行的首報制度。就是如果一家機構或者代理商申報了潛在客戶,則其它代理商或分支機構就不能參與競標。
由于行業人員的流動性頻繁,就曾出現過A產品的機構或代理商得到某潛在客戶的信息化需求后,緊急向機構報備,并通知自己熟悉的B產品伙伴對B產品亦進行報備,從而阻斷B產品的機構或代理商參與競標,投最終贏標后與報備的B產品代理商共分利益,當然這種情況如何被軟件廠商總部發現后,銷售員或代理會受到處下。但這對軟件廠商來說既便是偶爾的一次,對于企業的損失卻是難以挽回的。所以建議招標發布開始階段不需要告訴軟件商都有哪些軟件公司參與投標以免造成圍標、壓標現象。同時根據前期的項目規劃,確定項目評標團隊成員,同時注意對項目評標成員名單進行保密,當然也不排除軟件廠商通過各種途徑探知相關消息,從而通過一些手段促使評標成員產生偏好。
在發標同時,企業應結合項目規劃的需求設定評分表,可根據情況進行重點考核,并依重要性設定不同的評分標準。一般的管理軟件評分表會包括如下內容:
軟件服務商資格與信譽:服務商公司規模及財務業務穩定性、核心業務及范圍、本地化支持能力、產品在軟件商所有產品中的位置及發展前景、投標團隊是直銷商還是代理商及經營年限。
服務商咨詢能力:是否有自己的咨詢團隊、咨詢專家的工作年限、行業年限、咨詢成功案例的行業特點、咨詢費用狀況,咨詢與信息化相結合的支持效果案例。
產品開發平臺相關技術情況:產品穩定性、集成性、擴展性、二次開發的便利性、用戶界面的友好與操作便利性、軟硬件要求環境說明與建議、開發的語言及軟件產品架構、操作系統與數據庫及硬件要求。
產品成熟度:產品上市年限、全產品功能客戶使用數量與使用情況、與企業需求模塊的功能上市年限、與企業需求模塊功能的客戶使用數量與年限。在這里特別提出的企業需求模塊功能上市與客戶使用數量說明是因為有些軟件商的產品可能上市很早,但對應的功能模塊或者行業模塊卻可能是剛開發的、或者上市不久且成功客戶使用的并不多。
產品系統功能:一般可以根據企業各業務部門的實際需求對照列出,并請軟件商在對應業務需求時可以依軟件服務商的理解介紹超出業務部門需求以外的建議功能。如業務部門可能只提到了同一商品對應客戶的不同價單,軟件商可以介紹對應不同客戶的不同價單以及定價方式或者配額比例。招標書在功能需求方面需注意不要以某一產品明顯的功能為參照,曾發生過某企業需求書一發布,某軟件商直接宣布放棄投標,因為從功能需求上看同另一家軟件產品極為相似,故認為招標書評選內容已被指定,放棄投標。
實施方法:確認服務商是否有成熟完整的實施方法體系、是否有多個項目應用的經驗、項目實施監控管理與風險預控體系是否建全、項目實施建議周期是否合理、調研工作安排及人員配置是否合理、是否考慮企業日常工作對計劃的影響及對策。
實施服務能力:擬定實施團隊的成員情況介紹、擬定實施團隊的項目經理經驗背景介紹、對實施范圍和目標的理解、項目危機處理機制、成功案例客戶介紹以及可供參觀考查的客戶名單、售后服務情況介紹、售后服務響應速度、本地化或就近服務團隊狀況。
商務報價:項目總成本及分項目成本報價說明、項目分期付款方式、年服務費計算方式、未來幾年許可數擴充的收費方式、產品升級成本、其它商務條款及說明。
三.需求調研:
在招標書發布后,確認參選軟件商名單后,選型小組會同軟件商溝通,共同制定軟件商到企業的調研計劃,這份調研計劃應該事前同各業務部門確認好時間安排是否合理,以使于業務部門可以安排好各自的工作,并進行相關準備。調研場合亦盡量安排在會議室,而非工作現場,以免影響調研工作的有序進行。調研時往往由業務部門先介紹本部門的基本情況和業務流程,然后根據調研顧問的詢問進行應對式回答。最后,各部門也可以針對困惑點和問題點進行詢問,并說出對系統的要求和期望。在配合軟件商調研時,牽涉到公司機密的,或與項目無關的,比如老板及內部人事關系等盡量避談。以免使項目選型介入同選型無關的事件來。而實際上,經驗老到的顧問在調研中往往會注意挖掘企業管理層的背景,甚至結合企業組織結構分析出項目選型的組織圖,識別出項目的決策者、關鍵因素影響者、建議者、參與者能不同層次,以供后續投標或者商務溝通時發揮作用,增進企業超出產品以及能力以外的好感。
軟件商一般都會安排售前顧問或方案顧問來調研。售前顧問一般都是專職售前經歷多,既可以講管理又能夠談產品有的顧問則會依據客戶的需求,告訴他們什么能做,什么不能做,什么需要變通一下去做。也有的顧問可以吹噓忽悠成份具多,什么都可以承諾。真正有經驗的顧問往往會判斷客戶的需求合理性,詢問客戶需求的深層目的,因為很多客戶根本不明白自己的需求,不知道為什么要這個需求。這就是優秀顧問的價值,他們不會一味地迎合承諾客戶,而是在考慮客戶所提當前需求時,還會考慮到客戶目前還沒意識到或考慮到的需求,這個過程實際上也可能促進業務部門人員對管理狀況產生思考及提升的一個機會。
實際上調整過程也可以成為企業對軟件廠商顧問能力的考核過程,企業可以提出自己的需求時,也要了解調研者是否可能從另一個角度審視企業當初的規劃以及需求分析可能的漏洞或偏差包括管理現狀的問題分析。筆者曾支持過一個老銷售的需求調研項目,事后他總結的是說筆者的調研方式同他們機構的售前顧問完全不同。說機構的售前顧問,多數就是了解企業的人員狀況,業務需求,而他發現筆者的調研往往是在交流過程中把企業的流程及管理問題揭示出來,并且深得業務部門的同感和信任,從而為后期方案對策包括選型打分都贏得加分因素。
所以在這里還要強調一個事,就是往往軟件商在調研階段派出的顧問和項目真正實施階段派出的顧問是兩批人。在軟件公司,售前團隊同實施團隊也是兩組不同的團隊甚至部門。這是因為對于軟件商來說,優秀的資源也限的,較多的公司是把優秀的資源放在售前打單過程中,包括咨詢行業也是一樣的,在售前分析問題捕抓客戶管理痛點的往往是業務經驗豐富的顧問。而在交付階段,軟件商更多是派出產品功能顧問,這個道理其實很容易理解的,一流顧問太少了,所以行業中有句話講叫“一流顧問干售前、二流顧問搞實施、三流顧問守售后”。
四.方案呈現:
如何辨別針對性方案還是標準方案,講標時間控制尺度,在需求調研結束后,軟件商往往需要一周的時間回去結合所調研的企業需求,制定解決方案。不過現在很多企業往往要求忽略這一步聚,而是直接進入到產品演示,甚至筆者建議方案還是應該要求講解的,這個實際也是在考察軟件商的服務能力的。除非企業自身對項目控制、風險把握有絕對的能力,只要買來的產品功能符合,就可以自己實施。
當然也有一些實力不強的軟件商往往通過兩三天的企業調研,只是了解到企業一些表面需求,未能有實質性的建議,便進入了標準產品功能PPT的講解環節中,提供的幾百上千頁的文檔,也往往是個標準化任何企業都適用的東西。筆者曾經被某企業聘請參與其項目選型評審,發現兩家投標軟件商都分別提供了一本比磚頭還要厚很多的項目建議書,而里面實際上就是軟件商的產品發布功能介紹說明書的內容,同企業實際需求看不出什么關系。最為可笑的是,曾經發生過投標書中竟然還有投標過其它企業的名字。
就企業來說,方案書的薄厚同對企業項目的重視不一定成正比的,主要還是要看方案書寫的是不是企業所需求的。
由于企業各部門有正常的業務,所以往往企業的選型小組或者IT部門的聯系人,擔心無法把業務部門人員聚齊,往往給軟件商的講標時間留的很短。筆者曾參與過一個企業講標過程,企業一天邀請六家軟件商同時講標,結果每家軟件商講標時間為20分鐘,答疑時間為10分鐘,像這樣的講標就流于形式了,對企業并不利。所以講標時間的安排盡量充分,如果企業連講標評標的時間都這么難擠出來,又如何保證在項目實施過程中的時間安排呢?也有些企業因為參與投標的軟件商較多,怕長時間影響生產,會把講標時間安排在周末或者晚上。對于不同的軟件商的講解時間的安排建議盡可能不要相隔太久,這樣一是便于評標者易于對比,二是防止信息泄漏對前者不公平而使前者的講標時有所保留。
軟件商的方案中往往會介紹公司背景和能力、系統主要功能、技術支持建議方案、成功樣版案例客戶等信息,對于這些信息,特別是樣版客戶的信息可以注意收集,并設想確認實際效果。
在講標結束后的答疑階段,交流過程中要敢于刨根問底式的詢問,更加深入的了解軟件商的實力,只有前期溝通充分、了解深入,后期合作才融洽。前面提到的那個企業聘請筆者做為企業顧問參與評審中就發現,軟件商講的成功案例客戶其實生產系統根本沒有真正運行起來,MRP都沒有跑過,軟件商還在吹噓項目有多么成功,客戶多么滿意的。而另一家軟件商更是講的什么已向集團申報要與企業達成戰略合作伙伴,企業多處的異地工廠的項目實施也將由軟件公司集團總部統一調配資源。而實際上,除非是新產品,當地軟件商不具備實施能力,才可能由總部統一調配資源實施,但這需要軟件公司機構向總部付費的,各部軟件公司都是獨立核算各自經營的。
對于這些在交流過程中軟件商的回答,評審小組不只是要對其回答有效性評分還要盡可能的對其回答的真實性加了甄別。講標結束后,評審小組成員根據理解情況對照評分表打分,由項目評審小組負責人或專干匯總,同時需要對打分情況需要嚴格保密。
五.產品演示:
筆者另文《實施ERP的532》中強調企業實施ERP重點是5分在人;3分流程,只有2 分產品。這是不是說產品的重要性很低呢,那么我們還費很大的勁選產品有意義嗎?要知道,我們談ERP532原則是指在實施效果方面的重要性比例,但并不是就說產品功能不重要,我們畢竟不可能拿鋤頭當算盤用的。所以2分產品雖然比重看視輕,但卻是硬件。講產品的2分性是相近規模的軟件商的相同行為產品來比較。軟件本身功能的趨同性很強,只不過是界面友好性、操作易用性方面可能有所區分,我們當然愿意盡可能選擇適用于我們的產品。類似集團型多工廠且內部交易較頻繁的企業選擇單法人應用軟件肯定不合適的,行業應用性差異較大或者跨業態產品的應用,也必然會增加很多的開發工作量,所以對產品的重點應用功能結合企業需求如產品的計劃外庫存、線邊倉、生產排程的管理需要對產品功能進行再確認。包括類似貴重金屬加工行業特另關注金屬平衡管理,涉及到委外業務的,往往需要對委外倉余量進行監控管理以及廢料屑沫的回收等功能需求都需結合企業實際業務重要性來評判。
在產品演示的時間安排方面,一般按供應商調研的順序進行,各家時間間隔不易太長,否則評審容易淡忘,難以比較。為了細致地考察各家產品功能的適用度,可考慮每家安排一到兩天的產品演示時間,產品演示可能在時間方面同大家本職工作有沖突,可以采取演示到哪個功能模塊,通知相關業務部門參加的做法,同時鼓勵各部門經理及項目組成員盡可能全程參加,因為這實際上也是一個免費的學習和培訓機會。
產品演示方式最好是要求軟件商根據企業所提供的演示數據(BOM、工藝流程)由擬派的項目實施顧問現場跑業務主要流程。雖然在這種情況下也可能有造假的情況,但至少其演示的功能80%是應該可以實現的,而且在這個過程中實際上也考查了未來充當項目交付的實施顧問的能力水平。曾經某企業選型階段查看軟件商的各項產品能功,認為都滿足企業的需求。但到了實際實施過程中,實施顧問告訴企業,某些功能還處于開發過程中呢,這是因為產品演示的表單是軟件商臨時開發的界面,根本跑不了數據的。
各業務部門在供應商產品演示時,可以積極提問,重點看其產品功能能否滿足自己的需求,以及應用的便利程度,做好記錄和總結,但盡量不要當場給予評價不要給軟件商任何有影響的信息,以免影響后期商務談判的交涉能力。
需要理解的是往往在產品演示環節,但系統太大,一個問題以可能其背后涉及到很多制造業和ERP基礎知識,每個人的基礎參差不齊,如果以前沒接觸過,在演示會這樣短的時間里要讓每個人弄明白是不可能的,遇到這種情況下也不要緊,本身將其當成一次學習培訓機會也是很不錯的。但也可能存在業務人員由于自己基礎較弱,以往工作接觸電腦的機會也較少,在初次看到復雜的系統演示時,可能會增添畏懼情緒,這也需要選型項目組人員進行引導。
六.樣版客戶參觀:
曾發生過某企業在實施項目啟動時,信心滿滿,軟件商亦強調全力配合,并表達在預定上線日期時,由軟件商召開全國性的上線表彰會議。結果到了上線前昔,企業的ERP系統僅是把總帳系統完成上線工作了,軟件公司項目經理張羅申報上線成功,企業很不滿意,向軟件商提出更換項目經理,同時由于錢已付出,還是指望軟件商能夠幫助企業完成后續工作,只能配合軟件商招開上線慶功現場會,并且接受軟件商邀請來的全國各地的潛在客戶進行交流。但實際上由于毫無成果體現,所以企業宣講的PPT都是軟件商幫助寫出來的,想現場參觀的客戶也以保密為由予以婉謝,項目延期幾個月后終于在軟件商更換項目經理后糊弄上線。但在上線四年后,在一次發貨差錯裭客戶提示而非自己工廠發現后,董事長終于憤怒的發出了:“我們至今還在背著ERP這個高效而又沉重的包裹前行”
為什么明明項目結果不好,客戶還會硬著頭皮配合軟件商搞市場宣傳呢?其際上在這種情況下,往往企業已經是進退不得,只能期望軟件商后繼能再支持把項目搞下去,甚至還有一絲絲夢想的期待在里面。實際上很多由軟件商推薦的允許潛在客戶參觀的企業,既便是效果不好,參觀者也是較難看到真實情況的,甚至曾經多次發生過潛在客戶去軟件商推薦的樣版客戶參觀,樣版客戶安排給參觀者講解ERP項目實施價值的人就是軟件公司的人穿著樣版客戶的工裝在進行介紹,想象一下這樣的結果。另外還有一個方面是很多企業是不希望被別人認為自己企業的信息化項目效果不好的,因為這樣會被外界認為企業管理水平低下。故而有些企業甚至把實際了信息化當成企業管理水平高低的一個區分因素。
所以說變樣的樣版客戶參觀往往流于形式,參觀者需要注意的接受參觀的企業是否是有意配合軟件商搞宣傳。參觀者需要注意的是客戶改善的情況,而不是功能的應用,另外,別人的成功,不代表你也會成功,相反別人的失敗,倒是可以提醒你在相同的地方多加注意。考察軟件商的樣版客戶時,由于接受參觀的企業本身也有自己的工作,參觀交流的時間不可能很長,所以一些好問題盡量提前列出來,帶著問題去做有針以性的溝通和考察。一個朋友曾提到他們企業經常接受參觀者,說有些客戶參觀只是嘆息抱怨自己企業的管理水平低下,達不到要求,當然也有水平高的客戶參觀時更注意去抓住關鍵問題如計劃如定制定、如何監控制行、如何進行有效調整的。
另外也可以從軟件商方案中介紹的樣板客戶中自己通過一些關系,聯系到這些企業私下交流,可能會探聽到更有價值的信息,另外參觀ERP廠家也可以了解到軟件商的實力和企業文化,了解服務體系,因為選擇了合適的供應商只是成功的一半,更大的挑戰是后面的實施和服務,招標選型需考慮軟件商的實施能力、二次開發能力等綜合要素。
七.工作任務書:
很多時候,合同簽完后,由于合同約定往往較粗,只是明確了合作關系購買的產品以及階段性付款,而忽略的雙方各自需要在交付過程中承擔的責任和義務,包括實施的模塊功能,產品落地的實現,不滿足功能的二次開發需求等。另外每個企業都可能有自己的獨特需求是標準產品中滿足不了的,這個很正常,軟件商在方案中應該明確的表達出對不滿足功能的解決方案,如二次開發或者對企業信息化人員的開發技能的轉移,這些應該在工作任務書中加以明確。甚至包括承諾的指定項目組人員必須到位,但實際上也很可能軟件商以這樣那樣的借口說指定人員離職或者病假的原因以替代者到現場交付,此種情況在工作任務書中亦應明確對替代者的考核,還包括軟件公司銷售代表的一些口頭承諾都應要求寫入工作任務書當中去。
工作任務書一般需明確如下具體事項:
項目范圍:項目范圍主要需說明項目總體計劃及分階段計劃;企業實施的主體包括哪些經營實體,如幾個工廠或者事業部;實施的產品功能包括那些,需要二次開次的內容有哪些;系統需要集成的產品與接口方案;接口數據的轉換由哪一方執行,哪一方需進行配合等信息。
項目實施過程控制:包括甲乙雙方實施組織的建立;實施小組日常工作場所的確定;實施項目啟動組織的動員;項目調研的配合要求;項目主計劃的制定;關鍵用戶的培訓計劃;業務流程的整理確認;最終設計藍圖的確認;基礎數據的整理;系統初始化以及試運行的準備;最終的項目驗收。
項目組織與管理:包括項目組成員的確定;雙方項目成員聯系溝通方式與信息傳遞渠道;約定的工作內容及交付物;雙方項目組的工作職責;項目管理協調機制的確立,如周計劃、執行確認、周例會、項目文件管理、項目決策機制及爭議解決機制和獎罰機制
項目移交:項目實施上線后,乙方的實施團隊會將項目支持工作轉給軟件商的運維部門,并將項目相關信息及問題包括后續仍然注意或協助處理的事項列入項目移交報告中,項目移交報告應得到甲方簽字確認。
項目完工程序和標準:在每個階段試運行完成后,由乙方項目經理以書面報告的形式申請階段性驗收,甲方項目經理簽字認可為完成階段驗收,一般在驗收確認的時限往往需雙方協商確認,但時間往往不會太久,乙方為保護己方利益,往往會要求,甲方超期未予簽字驗收且未提異議時,視為驗收完成。甲方在接到驗收申請,而對項目階段性成果認可時,應提出推遲驗收說明書,雙方根據前面的項目驗收標準共同確認。
項目變更控制:項目實施過程中,由于任何一方的原因,導致項目無法依原計劃進行時(如實施范圍、功能需求或者例外情況),應由當事方提出項目變更申請建議,再由接收方根據實際情況進行確認或者相互再交涉,最終達成雙方認可的結果,而后才能實行變更。為此需要事前制定好確明確的項目變更審批流程。
主要假定事項:是指為了保證項目的正常推進以及最終達成理想目標,雙定認定一些事項,如項目組成員其投入在本項目中的時間是會得到充分保證的;對于一些關鍵業務環節,雙方是可以保證及時完成或者進行回復;雙方的工作環境是會充分得到保證的;在項目推行過程中雙方領導都將會積極協調各方資源予以配合等等。
項目終止或暫停:項目暫停是由于各種原因,項目需暫時停止,在未來有預期的時間內,項目將重新起動。項目暫停指令必須由項目領導小組發出,在項目領導小組發出項目暫停指令之前,項目工作還需要按原計劃進行。如果項目復工時,需要保留原來的顧問團隊,則保留顧問團隊的成本將需要事前在本條目中予以說明。項目終止亦須由項目領導小組決定,終止計劃內往往會涉及到相關費用亦需在本條目中予以說明。
有效的工作任務書有助于理清合作雙方的職責,以免使后續實施過程中發生很多不必要的麻煩甚至最終項目失敗而相互指責分不清是哪一方在哪些方面沒有做到導致的原因。
八.商務談判:
在明確了工作任務書后,也就是到了最后的商務談判階段,由于在工作任務書中明確雙方的責任以及項目的范圍、目標,確定了雙方投入的資源,實際上也為價格談判提供了參考依據。
我們講在商務談判中,通常認為這將是零和游戲,但就實際情況而言,筆者是不贊同甲方一味的壓低合同價格的,實際上那樣的結果往往最終還是甲方損失更大。因為乙方在確認項目既將虧損時,往往會中止資源的再投入。曾經在中國的南方某城市發生了,當時簽約時,項目價格壓的過低,而需求又很多,項目實施到一半時,軟件商不愿再投入資源,甲方要求退貨又無法實現,在中國這類合同糾紛往往也是最不易理清的,最終的結果是扯破了臉皮,但甲方的損失必然是最大的。
但這也不是說甲方就必然需要付高價,根據工作任務書明確的工作內容如果理性的分析談判,畢竟雙方的本意是希望合作共贏的。而且甲方亦是多家比較評估最終才會確定結果的,如果甲方企業是初次實施IT項目,最好的建議是甲方企業或引入有經驗的甲方項目經理來負責,或者引入外部顧問幫助甲方規避風險。
在項目總價格確認后,項目的付款方式也是需要雙方進行交涉的,IT項目的實施不同于單純的購買產品或者服務,所以付款是根據項目的幾個里程碑來決定付款周期和數額的。曾經發生過一些企業同軟件商簽約,首付額度很大,軟件商當地機構當年業績完成不錯,總經理提職,而接任總經理卻需要在后續產品交付過程中不斷的投入實施資源,但由于大部份款項已付,收益業績是全部記入上一任總經理,導致后任總經理不愿再多投資源在客戶身上,或者要求客戶再購買其它相關產品進行擬補。
這個原因往往是在于項目付款往往是分成產品費用、實施費用和服務費用的,服務費用往往第一年可能得到減免,產品費用往往是需要客戶一次付清的,實施費用是根據項目進展階段支付。作為甲方在商務談判時,不只是需要關注總體項目金額,還應關注產品成本與實施成本的分項價格,這樣可能更有利于在分期付款談判時取得有利自己的保障。
筆者總結:
選型結束往往是正式實施的開始,就筆者個人觀點,輔導企業的ERP依期上線并不算難,因為實際上在上線期間,無論是藍圖還是系統實現都沒有真正的觸碰到業務的實際業務,充其量是要求企業各業務部門提供一些基礎數據,對產品操作進行一些培訓,或者通過認證考試的方式促使員工們認真學習產品操作功能。這個考驗的就是企業的配合度以及雙方項目經理的控制能力,而較難反應出項目方案以及業務流程規劃的合理性,真實能否體現出實施效果往往是需要系統上線運行半年后,在相關業務部門能夠熟練操作系統時,企業的各項相關經營指標是否得到了改善。
實施ERP的業界有句話叫“上頭急、下頭急、中間頂門杠不急”,講的是企業實施信息化工程,往往是決策層期望最快的見到效果,下面基層員工呢,因為一是涉及到實際操作,二是對系統操作與業務結合的不熟練,三是可能相關數據傳遞不及時擔心自己工作受到影響,所以也著急。但很多企業對推行信息化中,往往是把推行工作落實到各部門的關鍵用戶身上,而部門經理的精力全都投入到日常工作中來,所以介入項目的工作不深,很多部門經理就是來開幾個會,就拉倒了。
軟件商的項目實施最為關注的是依期上線收款,在實施過程中會盡可能的考慮如何控制實施過程中的風險,盡可能減少不必要或者不確定的麻煩及需求,一切以上線為目的,而不是考慮細化方案的合理性。軟件顧問呢,原本對企業業務也不熟悉,項目的藍圖階段的調研也往往是流于形式或者說只了解到業務的表面情況。最終落實到系統的解決方案時,也會發生很多與實際情況不符的現象。在項目后期既便是出現業務與前期調研有偏差時,往往是只是采取臨機方案應對。
如某企業項目由于調研不細,在臨上線前才發現客戶銷售分類的一個重要需求,于是采取在雜發處理過程中用帳戶別名進行處理,而不是用分類碼,如果每處理一次業務就需要增加一次帳戶別名。甚至于某個集團企業在上線前才發現最初考慮在系統設置的各子公司間業務關聯問題無法解決,匆忙更改方案增加一個實體來應對。以至于項目結案后,軟件商開總結會時,有的顧問對前期的藍圖設計存在的必要性產生懷疑,因為最終上線的同前期規劃的偏差太大了。當然這也說明這家軟件公司實施顧問的能力不足,未來在前期有效的幫助企業進行流程梳理甚至于都未能理解企業業務模型。想象下這樣實施最終企業系統正式運行時,能沒有問題嗎?
所以筆者認為,真正的項目實施考驗實際上是在企業ERP系統上線后半年這段時間的磨合情況,真正的項目成果是企業信息化上線半年后,企業各項經營指標的改善情況。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:漫談ERP選型
本文網址:http://www.guhuozai8.cn/html/consultation/10820114613.html