你遇上了?告訴你SAP實施十大誤區(轉)
如果你正考慮要實施SAP的R/3產品,那麼你可要小心了:這不是一種機械的改變。一個一般的價值50億美元的公司得為這個專案在軟體、硬體、系統整合、人員上花上5千萬美元左右。如果你的公司正打算花這筆錢,最好能確保實現預期的投資回報率。為了把你從這場災難中解救出來,我們在這裡將列出應該避免的十大錯誤。
誤區一:認為只要系統能夠執行了,專案就結束了
Deloitte諮詢公司負責SAP大客戶服務的合夥人Clive Weightman說:太多公司認為SAP實施專案有明確的開始和明確的結束。我們認為,應該把ERP開始執行的那天當作專案另一階段的開始,而不是專案的結束。
美國賓夕法尼亞州Diagonal諮詢公司最近的一個客戶由於沒有做好系統執行後的計劃,不得不聘請諮詢員進行額外的六個月的現場指導。對此,Diagonal諮詢公司的負責人Paul Krant說:“正常情況下,在客戶能夠進行自我維護之前,我們要進行3-4周的執行後支援。這個客戶的失敗就像是,舉行了婚禮,但卻沒有對婚姻生活做好準備。”
誤區二:沒有開發業務用例
不要僅僅因為CIO認為需要一個ERP軟體,就貿貿然開始一個SAP專案。在這樣的一個基礎上前進是十分危險的,其代價也及其昂貴。美國Accenture諮詢公司SAP專案的負責人Mark Willford認為:“SAP專案必須由利益驅動,必須有一個具體的業務用例。”
沒有業務用例的風險在於,你會把SAP專案看作是一個普通的軟體實施專案,而沒有重新設計業務流程發揮SAP潛在的業務流程改進功能。BearingPoint諮詢公司北美的SAP專案負責人Michael King說:“如果只是按照原來的業務流程實施SAP,那麼你最終只是白忙一場。你擁有了一個新的系統,但是根本沒有解決存在的業務問題。”同時,所有你向CEO承諾過的商業利益都不會出現。[$page$]
誤區三:沒有提供最好的員工給實施小組
Michael King說,他經常看到SAP專案小組成為一個垃圾場,客戶把一些它不知該如何處置的人員都扔給了專案組。但是如果要為公司重新設計業務流程,那麼就應該給專案組配備公司各個部門最聰明、最優秀的員工。雖然可能各個部門都想抓住這些優秀員工不肯放,但只有他們才能按照預算準時完成專案,為企業願景提供最相配的最佳化了的業務流程。Michael King說:“為了讓客戶明白優秀的專案小組有多重要,你要做好準備與客戶進行一場奇怪的戰鬥。”如果沒有優秀的實施小組,還可能出現更糟糕的情況。Clive Weightman指出:“如果你的實施小組很糟糕,那麼你的專案永遠也別想有個結束。如果中途中止專案實施,那麼公司很可能倒閉。”
誤區四:採用與公司不相融的解決方案
對此,Clive Weightman舉了一個國際化學公司的例子。這家公司本來是以非集中式的方式執行的,想透過SAP專案轉換成集中方式,結果實施卻遭到了徹底的慘敗。從技術上說,SAP的技術完全能夠把公司集中起來。“但是這只是問題的一個方面,問題的另一方面就是企業文化。在這個公司裡,高階員工習慣於為公司運營做出各種決定,他們不願意放棄這種權力。這個例子給我們的一個啟示就是,不要把技術作為一種改變公司文化的工具。”[$page$] 誤區五:僱用沒有經驗的諮詢員
Paul Krant建議諮詢小組的成員應該是新手和熟練人員的平衡組合。他說:“許多諮詢公司都透過‘學術’手段來培訓員工,給他們上一些培訓課程,然後就直接送到客戶那裡去做諮詢了。這根本就行不通。諮詢小組必須有有經驗的人參加。公司最好事先看一下諮詢人員的簡歷,確定專案小組有有經驗的人參加。”
誤區六:對系統使用者的培訓不夠
Diagonal諮詢公司的總裁Paul Scherer說,這種錯誤會導致在系統實際執行後,諮詢員還得留下來進行幾個月的現場指導。如果沒有充分的培訓,員工們會按照他們自己的方式做事情,這樣就無法對公司的新流程進行管理。這會導致每個業務領域都產生問題。
誤區七:不能控制“範圍爬升”
許多公司在它們開始專案前會建立一個業務用例,但接著它們就會因為ERP軟體擁有一些其他的功能,而把這些功能胡亂的新增到專案範圍裡來。它們從來不會回頭想一想最初的業務用例,思考一下“這項功能是否支援這個業務用例?”對此,Paul Scherer說:“1000個小傷口也可以造成死亡。同樣,每個對專案範圍的改變可能都是一個很微小的改變,但是這些改變合起來卻可能使專案超出預算,落後於計劃時間,甚至更糟——最終沒有產生任何預期的效益。”[$page$] 誤區八:把SAP專案看成一個技術專案
Clive Weightman認為,一個SAP實施專案涉及到人、流程、技術的平衡。如果實施小組90%是技術人員,而沒有各個業務部門的代表參加,那麼最終的結果可能是一個空想的技術實施專案,對公司增強競爭力毫無幫助。這聽起來似乎很明白,但是還是有很多公司在犯這種錯誤。
誤區九:無視系統整合人員的建議
Clive Weightman說他曾經為一個化學公司做諮詢。這個化學公司那時正在進行它第三次的SAP實施,所以Clive Weightman以為這個公司很有經驗。但事實並非如此。雖然這個專案的系統整合人員在全球範圍內做過了許多類似的實施專案,所有的經驗絕對比這個公司兩次三次的實施經驗多得多,但是這個化學公司卻沒有采納他們的建議。結果,這個專案比預計的時間延遲了五個月才完成,並大大的超過了預算,公司也損失了五個月的業務利潤。
誤區十:分塊實施SAP
許多公司試圖透過分階段實施SAP專案來迅速獲得競爭優勢。比如說,先實施財務模組,然後實施人力資源模組,接著是銷售模組,等等。但是,這樣做就不能很好的獲得一個最終整合的系統。因為在你準備好進行下一階段的實施的時候,你已經被前一階段的作出的一些定義束縛住了。這種情況下,你不得不對前面階段的工作進行大修改,使其能夠與後面階段的模組進行有效地整合。對於這種情況,Clive Weightman建議:“我們可以對業務流程進行邏輯分組,然後按照邏輯組一步步的進行實施,否則你可能需要比原來多一倍的時間來進行分步實施。”
誤區一:認為只要系統能夠執行了,專案就結束了
Deloitte諮詢公司負責SAP大客戶服務的合夥人Clive Weightman說:太多公司認為SAP實施專案有明確的開始和明確的結束。我們認為,應該把ERP開始執行的那天當作專案另一階段的開始,而不是專案的結束。
美國賓夕法尼亞州Diagonal諮詢公司最近的一個客戶由於沒有做好系統執行後的計劃,不得不聘請諮詢員進行額外的六個月的現場指導。對此,Diagonal諮詢公司的負責人Paul Krant說:“正常情況下,在客戶能夠進行自我維護之前,我們要進行3-4周的執行後支援。這個客戶的失敗就像是,舉行了婚禮,但卻沒有對婚姻生活做好準備。”
誤區二:沒有開發業務用例
不要僅僅因為CIO認為需要一個ERP軟體,就貿貿然開始一個SAP專案。在這樣的一個基礎上前進是十分危險的,其代價也及其昂貴。美國Accenture諮詢公司SAP專案的負責人Mark Willford認為:“SAP專案必須由利益驅動,必須有一個具體的業務用例。”
沒有業務用例的風險在於,你會把SAP專案看作是一個普通的軟體實施專案,而沒有重新設計業務流程發揮SAP潛在的業務流程改進功能。BearingPoint諮詢公司北美的SAP專案負責人Michael King說:“如果只是按照原來的業務流程實施SAP,那麼你最終只是白忙一場。你擁有了一個新的系統,但是根本沒有解決存在的業務問題。”同時,所有你向CEO承諾過的商業利益都不會出現。[$page$]
誤區三:沒有提供最好的員工給實施小組
Michael King說,他經常看到SAP專案小組成為一個垃圾場,客戶把一些它不知該如何處置的人員都扔給了專案組。但是如果要為公司重新設計業務流程,那麼就應該給專案組配備公司各個部門最聰明、最優秀的員工。雖然可能各個部門都想抓住這些優秀員工不肯放,但只有他們才能按照預算準時完成專案,為企業願景提供最相配的最佳化了的業務流程。Michael King說:“為了讓客戶明白優秀的專案小組有多重要,你要做好準備與客戶進行一場奇怪的戰鬥。”如果沒有優秀的實施小組,還可能出現更糟糕的情況。Clive Weightman指出:“如果你的實施小組很糟糕,那麼你的專案永遠也別想有個結束。如果中途中止專案實施,那麼公司很可能倒閉。”
誤區四:採用與公司不相融的解決方案
對此,Clive Weightman舉了一個國際化學公司的例子。這家公司本來是以非集中式的方式執行的,想透過SAP專案轉換成集中方式,結果實施卻遭到了徹底的慘敗。從技術上說,SAP的技術完全能夠把公司集中起來。“但是這只是問題的一個方面,問題的另一方面就是企業文化。在這個公司裡,高階員工習慣於為公司運營做出各種決定,他們不願意放棄這種權力。這個例子給我們的一個啟示就是,不要把技術作為一種改變公司文化的工具。”[$page$] 誤區五:僱用沒有經驗的諮詢員
Paul Krant建議諮詢小組的成員應該是新手和熟練人員的平衡組合。他說:“許多諮詢公司都透過‘學術’手段來培訓員工,給他們上一些培訓課程,然後就直接送到客戶那裡去做諮詢了。這根本就行不通。諮詢小組必須有有經驗的人參加。公司最好事先看一下諮詢人員的簡歷,確定專案小組有有經驗的人參加。”
誤區六:對系統使用者的培訓不夠
Diagonal諮詢公司的總裁Paul Scherer說,這種錯誤會導致在系統實際執行後,諮詢員還得留下來進行幾個月的現場指導。如果沒有充分的培訓,員工們會按照他們自己的方式做事情,這樣就無法對公司的新流程進行管理。這會導致每個業務領域都產生問題。
誤區七:不能控制“範圍爬升”
許多公司在它們開始專案前會建立一個業務用例,但接著它們就會因為ERP軟體擁有一些其他的功能,而把這些功能胡亂的新增到專案範圍裡來。它們從來不會回頭想一想最初的業務用例,思考一下“這項功能是否支援這個業務用例?”對此,Paul Scherer說:“1000個小傷口也可以造成死亡。同樣,每個對專案範圍的改變可能都是一個很微小的改變,但是這些改變合起來卻可能使專案超出預算,落後於計劃時間,甚至更糟——最終沒有產生任何預期的效益。”[$page$] 誤區八:把SAP專案看成一個技術專案
Clive Weightman認為,一個SAP實施專案涉及到人、流程、技術的平衡。如果實施小組90%是技術人員,而沒有各個業務部門的代表參加,那麼最終的結果可能是一個空想的技術實施專案,對公司增強競爭力毫無幫助。這聽起來似乎很明白,但是還是有很多公司在犯這種錯誤。
誤區九:無視系統整合人員的建議
Clive Weightman說他曾經為一個化學公司做諮詢。這個化學公司那時正在進行它第三次的SAP實施,所以Clive Weightman以為這個公司很有經驗。但事實並非如此。雖然這個專案的系統整合人員在全球範圍內做過了許多類似的實施專案,所有的經驗絕對比這個公司兩次三次的實施經驗多得多,但是這個化學公司卻沒有采納他們的建議。結果,這個專案比預計的時間延遲了五個月才完成,並大大的超過了預算,公司也損失了五個月的業務利潤。
誤區十:分塊實施SAP
許多公司試圖透過分階段實施SAP專案來迅速獲得競爭優勢。比如說,先實施財務模組,然後實施人力資源模組,接著是銷售模組,等等。但是,這樣做就不能很好的獲得一個最終整合的系統。因為在你準備好進行下一階段的實施的時候,你已經被前一階段的作出的一些定義束縛住了。這種情況下,你不得不對前面階段的工作進行大修改,使其能夠與後面階段的模組進行有效地整合。對於這種情況,Clive Weightman建議:“我們可以對業務流程進行邏輯分組,然後按照邏輯組一步步的進行實施,否則你可能需要比原來多一倍的時間來進行分步實施。”
來源:支點網
責任編輯:昭然
責任編輯:昭然
轉自:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/113825/viewspace-63018/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何實施標準作業?這篇文章告訴你
- 【轉】kafka-告訴你什麼是kafkaKafka
- 35 歲前端轉不轉管理 這 5 個前輩告訴你前端
- 實在智慧RPA告訴你,高效快速才是你的《狂扁小朋友》
- 你真的瞭解你的團隊嗎? ONA告訴你真相
- 一篇文章告訴你Dalvik 和JVM的區別JVM
- 化妝品怎麼選?新匯通告訴你告訴你包裝很重要!
- 那些售前不會告訴你的SAP系統部署方式的坑坑道道
- 一文告訴你資料和資訊的區別
- volatile和synchronized到底啥區別?多圖文講解告訴你synchronized
- 碼教授告訴你大資料與人工智慧的區別大資料人工智慧
- 龍象之爭:資料告訴你真實的差距
- 告訴你什麼是Pixelmator Pro for Mac!Mac
- 大神告訴你如何理解微服務框架微服務框架
- 三段實習經歷告訴你找實習的真相
- 讓機器學習告訴你,你的siri在想什麼!機器學習
- 一分鐘乾貨告訴你區塊鏈究竟是啥?區塊鏈
- 告訴你架構師與程式設計師的區別在哪裡架構程式設計師
- 如何確定你的伴侶真的愛你?複雜數學公式告訴你公式
- 如何看懂DOE分析報告?這篇文章告訴你
- 遊戲是如何告訴"你快要死了”?遊戲
- 一篇告訴你什麼是SpringSpring
- PAT乙級 | 1086 就不告訴你 (15分)
- 【vue】用圖告訴你響應式原理Vue
- 0.1+0.2=?在前端裡,告訴你:≠0.3 !前端
- 資料告訴你,胡歌的微世界
- 一張圖告訴你什麼是GraphQL?
- 告訴你 Redis 是一個牛逼貨Redis
- 斐訊用一頭牛告訴你 區塊鏈還有哪些新玩法!區塊鏈
- SAP ERP系統實施價格?上一套SAP系統需要多少錢?SAP代理商重慶達策告訴您
- 看完這篇文章你就可以告訴領導你精通Zookeeper了
- 2021年國慶你的朋友去哪浪了?讓Python告訴你!Python
- 請你告訴我合併兩個陣列,你有多少種方法陣列
- 7個步驟,告訴你如何打造“爆品”
- 創業如何選擇?智慧經營告訴你創業
- CODING 告訴你如何建立一個 Scrum 團隊Scrum
- 誰告訴你 Flutter 會幹掉原生開發?Flutter
- 一些告訴你做人的道理的故事