一個SAP vs Oracle的選型諮詢過程

今天看到一個Panorama公司為客戶提供的ERP選型諮詢案例,比較有意思,過程一波三折,真實地反映了企業應用選型的複雜和反覆。因為業內很少有“深喉”爆料類似的信息,所以翻譯出來供大家參考,並小小地點評一下。

一個SAP vs Oracle的選型諮詢過程

選型大PK

客戶是一家全球500強的分銷企業,在選型之前,北美分部使用的是Epicor。入選短名單有Oracle EBS,SAP S/4HANA和微軟的Dynamics 365,全是市佔率Tier1的ERP產品。出於擴展性方面的擔心,客戶不打算使用SaaS,哪怕Oracle和SAP極力推薦也不改主意。(點評:單一考慮擴展性這一個維度,顯然SaaS是強於On Premise的,客戶的顧慮估計是(1)實施商的成熟度;(2)SaaS的客製化能力

客戶在尋找Panorama幫助前,已經進行了BPR業務流程優化,找Panorama諮詢主要是評估技術和功能的適配性。所以Panorama花了幾個星期來梳理產品功能和客戶需求間的匹配。

客戶的CIO以前在另一家世界500強企業工作時用的是Oracle EBS,而且客戶當前的財務系統使用的也是Oracle的財務雲。不過,客戶和SAP也有關係。

評估的過程中,客戶經歷了一次大型的併購,從一家分銷型企業變成了製造業企業,產生了大量的新需求,尤其是拆解需求(從成品拆解出原材料,BOM的逆向過程)對於任何ERP產品都是一個薄弱的地方。

Panorama認為Oracle EBS和SAP S/4HANA都能滿足客戶對處理能力的要求,而微軟Dynamics 365不滿足擴展性的需求。從成功案例角度考慮,SAP S/4HANA在當時的狀態遜色於Oracle。(

點評:在需求描述如此含糊的基礎上,判斷Dynamics365處理能力不行是不嚴謹的,有悖於Panorama的專業性能力展現

至此,Oracle EBS勝出似乎十拿九穩了。不過奇怪的是Panorama最後推薦的是SAP S/4HANA,原因是S/4HANA的內存計算性能很高,同時在研發方面的投入很大,而Oracle由於強力轉向雲計算,對於On Premise的EBS投入幾乎停止。(點評:考慮產品的後續發展和研發投入,是值得我們學習的地方

事情的結果令人大跌眼鏡。首先,客戶的CIO沒有聽取Panorama的建議,仍然堅持Oracle EBS,並向董事會上報。其次董事會否決了CIO的意見,因為歐洲分部已經選擇了微軟的Dynamics 365。 最後,董事會決定Epicor的系統不換了,繼續使用,不過換到性能更強的IBM服務器上。

經過一個漫長的、令人疲憊的選型過程,最終卻回到了原點,Panorama不認為自己的工作沒有價值,相反幫助客戶對於SAP和Oracle產品的認知更加深入和客觀了。

總結

整個項目的最大敗筆是沒有明確的需求痛點,要解決什麼問題不明確,所以一切決策的根基就是漂浮的,最終回到原點也就不奇怪了。從文中的描述似乎可以得出客戶最大的需求是處理能力提升,如果是這樣,從硬件到軟件(數據庫、內存計算)能方面有很多容易的解決方案,沒必要一開始就上升到換平臺的思路上。

該項目中,最受傷的估計就是SAP和Oracle及其各自實施商的銷售了,折騰了一大圈顆粒無收,吐血的心估計都有了。客戶聚焦SAP和Oracle的比較一開始就值得銷售警惕,沒有明確需求故事的項目往往過程漫長,一波三折,最終決策不做的結果也時常發生。


分享到:


相關文章: