ERP二次開發的‘知’與‘行’
回頭看看,行業內對ERP二次開發的聲討10年由來沒有停止過:有過一種思潮說ERP標準功能代表行業最佳實踐模型,沒必要二次開發,遵守學習就行了;又有過一種思潮說ERP實施是給客戶提供最佳解決方案,該開發時就開發;再有過一種思潮說我們現在倡導ERP實施過程按需求開發會使ERP變味,我們要停止開發…ERP二次開發招誰惹誰了?
一、ERP二次開發招誰惹誰了?
芒果累滿枝頭的季節,剛好驗收一個ERP二次開發的專案,經歷了半年的專案終於要關閉,再一次感到一段新奇歷程結束時的喜悅。於是拿起電話打給一個朋友,他是東莞一家服裝製造公司IT主管,手頭也正在進行著ERP庫存模組的優化專案,他在電話裡抱怨這次優化成果剛剛上線,修改後ERP系統很不穩定,每天都在救火,不是搞亂了資料就是修改效果不符合終端使用者意見要返工,完全不能支援最初的流程優化設想,上線以來一直象夢魘。還不住的抱怨工程師們沒搞清需求,開發質量差。
掛上電話,我陷入了沉思:不管作為甲方IT還是乙方服務商,最終目的都是為業務部門做好服務,作為ERP實施顧問,我最不願意看到甲方對專案有如此失望,就好象是自己親自破壞了他們的ERP系統,導致他們疲憊不堪。回頭看看,行業內對ERP二次開發的聲討10年由來沒有停止過:有過一種思潮說ERP標準功能代表行業最佳實踐模型,沒必要二次開發,遵守學習就行了;又有過一種思潮說ERP實施是給客戶提供最佳解決方案,該開發時就開發;再有過一種思潮說我們現在倡導ERP實施過程按需求開發會使ERP變味,我們要停止開發…
ERP二次開發招誰惹誰了?
作為一個實施顧問,我看到的很多企業成功了。他們早就成功實施了oracle ERP很多年,根據企業發展需求有的已經在標準功能的基礎上,又成功二次開發了高階排程、高階備料系統,幾經耕耘並且還在繼續優化流程。我認為,我們是時候來思考ERP二次開發的‘知’與‘行’了。
二、開發目標,決策對了嗎?
不要過早抱怨技術工程師開發的功能很彆扭,挖掘不出(或堅持不了)真正的優化需要,最終作出的開發當然是四不像,這樣企業方和服務商雙方都有責任。看看以下從真實專案的案例:
一家熱水器製造公司生產採購部門領導提出,要減輕採購員下達採購訂單的工作量把工作中心轉移到採購缺料跟蹤上。明確向其IT部門提出需求:由採購部們出資,IT出人主導,要求幫其二次開發批量下達、批量審批採購訂單的功能。IT部門在主導立項時,將其定位成明確的批量下達採購訂單功能,並且這樣的開發被定性為比較簡單。企業方任命了2名採購員作為關鍵使用者,這2名採購員對ERP系統非採購模組不熟悉,在專案開展調研階段,他們認定,自己每天都要花很長時間在系統錄入一張張訂單,的確耗費不少工作量,開發一個批量下達的功能真的很好。顧問方根據關鍵使用者提出的意見,分析之後認為做到批量下達可行,同時開展了緊湊的開發測試過程。上線後,採購員門望著靈活的批量下達功能,一下子不敢在系統下達訂單了。
採購員的工作效率被誰偷去了?最後經過多方走訪,發現採購員們每天被採購價格不確定、主計劃善變所干擾,每下訂單都要重複確認某些物料的價格、詢問某些物料的採購計劃是否有變化、衡量儲備庫存要保持多少才好……是這些因素在起關鍵作用桎梏採購工作效率,一個簡單的批量下達功能是無法從根本上解決這些問題的,儘管確實方便了部分人可以通過全選、下達等功能批量下達一了百了,但這顯然是不負責任的做法。
根本問題出在:提出優化需求的人,沒有把自己的要求明確傳遞給授權參與專案的關鍵使用者;IT在立項內容中縮小了問題考慮範圍,ERP優化不同於一般的小系統優化,往往牽一髮而動千軍,立項之前首先企業內部沒有進行過評估分析,同時IT也有必要站在全域性的角度考慮這個開發需求是否合理;顧問在有限的資源支援下,得不到完整的客戶需求問題點,更無從分析評估主計劃為什麼不剛性、供應鏈管理價格為什麼不規範。
二次開發‘知’與‘行’。以上案例中的專案甲乙方,無不互相抱怨,甲方抱怨乙方作為顧問公司沒有替使用者考慮全面;乙方委屈甲方沒有配備正確的使用者,沒有提出合理的專案範圍。既成事實,後悔已晚。讓我們來思考如何做好需求決策吧:
a)凡是實施了大型ERP系統的公司,其組織架構必然也比較比較龐大,任何工作流程的優化必然涉及其他部門,不穿越部門壁壘的流程很少,ERP軟體的管理思想就是由一組組緊密關聯的流程組成,所以在評估需求何調研需求時,企業IT都應該要特別重視ERP二次開發專案的需求調研範圍;
b)企業實施了ERP標準功能之後,需要不斷自我審查在日後的流程執行過程,是否有偏離,對於不健康的ERP系統運作,何談優化?因為根本無從下手去優化了,本案例中的需求,調查到最後其實可以通過業務流程規範來解決,可能最後根本不需要ERP二次開發了,這一點必須依靠企業的主觀能動性來檢討。不得不重視的是,顧問公司在接到訂單那一刻,基本沒有太多理由告訴客戶說這個專案不用做了,因為當顧問公司給出這樣的結論時,是對這個專案立項可行性的質疑,通常情況下,顧問公司不會如此做。除非專案立項之前,企業邀請了顧問公司來作評估分析,這一邀請行為可以成為專門的專案了,因為顧問人天都比較貴,況且企業IT應該承擔起ERP系統運作是否健康的監察責任;
c)企業持續培養知用善用人才的很重要。根據多年的專案實施經驗,不少企業在最初實施ERP系統時,培養了一批優秀的關鍵使用者,但在後來的建設和維護階段,因人員流動而喪失了這些熟悉系統原理的人才,我們往往發現很多優化專案中推選的關鍵使用者,其實對ERP系統原理後臺的資料邏輯並不清楚,他們只知道操作,出現疑問並不能有效自我診斷和思考;
d)作為顧問公司,在接觸到這樣的ERP優化專案時,要對客戶提出的果決的需求問題點,進行初步分析,以此來評定工作量以及合同細節,以免專案真正開展起來,出現如案例所述的時候,互相抱怨,進退兩難,賠了夫人又折兵,最終做了客戶不滿意的專案。同時,從行業分工來講,顧問公司具備優質資源,也應該承擔把握專案方向的主動權。
原文網址: http://www.chinasie.com/newsie/zyjj_view.asp?id=416
一、ERP二次開發招誰惹誰了?
芒果累滿枝頭的季節,剛好驗收一個ERP二次開發的專案,經歷了半年的專案終於要關閉,再一次感到一段新奇歷程結束時的喜悅。於是拿起電話打給一個朋友,他是東莞一家服裝製造公司IT主管,手頭也正在進行著ERP庫存模組的優化專案,他在電話裡抱怨這次優化成果剛剛上線,修改後ERP系統很不穩定,每天都在救火,不是搞亂了資料就是修改效果不符合終端使用者意見要返工,完全不能支援最初的流程優化設想,上線以來一直象夢魘。還不住的抱怨工程師們沒搞清需求,開發質量差。
掛上電話,我陷入了沉思:不管作為甲方IT還是乙方服務商,最終目的都是為業務部門做好服務,作為ERP實施顧問,我最不願意看到甲方對專案有如此失望,就好象是自己親自破壞了他們的ERP系統,導致他們疲憊不堪。回頭看看,行業內對ERP二次開發的聲討10年由來沒有停止過:有過一種思潮說ERP標準功能代表行業最佳實踐模型,沒必要二次開發,遵守學習就行了;又有過一種思潮說ERP實施是給客戶提供最佳解決方案,該開發時就開發;再有過一種思潮說我們現在倡導ERP實施過程按需求開發會使ERP變味,我們要停止開發…
ERP二次開發招誰惹誰了?
作為一個實施顧問,我看到的很多企業成功了。他們早就成功實施了oracle ERP很多年,根據企業發展需求有的已經在標準功能的基礎上,又成功二次開發了高階排程、高階備料系統,幾經耕耘並且還在繼續優化流程。我認為,我們是時候來思考ERP二次開發的‘知’與‘行’了。
二、開發目標,決策對了嗎?
不要過早抱怨技術工程師開發的功能很彆扭,挖掘不出(或堅持不了)真正的優化需要,最終作出的開發當然是四不像,這樣企業方和服務商雙方都有責任。看看以下從真實專案的案例:
一家熱水器製造公司生產採購部門領導提出,要減輕採購員下達採購訂單的工作量把工作中心轉移到採購缺料跟蹤上。明確向其IT部門提出需求:由採購部們出資,IT出人主導,要求幫其二次開發批量下達、批量審批採購訂單的功能。IT部門在主導立項時,將其定位成明確的批量下達採購訂單功能,並且這樣的開發被定性為比較簡單。企業方任命了2名採購員作為關鍵使用者,這2名採購員對ERP系統非採購模組不熟悉,在專案開展調研階段,他們認定,自己每天都要花很長時間在系統錄入一張張訂單,的確耗費不少工作量,開發一個批量下達的功能真的很好。顧問方根據關鍵使用者提出的意見,分析之後認為做到批量下達可行,同時開展了緊湊的開發測試過程。上線後,採購員門望著靈活的批量下達功能,一下子不敢在系統下達訂單了。
採購員的工作效率被誰偷去了?最後經過多方走訪,發現採購員們每天被採購價格不確定、主計劃善變所干擾,每下訂單都要重複確認某些物料的價格、詢問某些物料的採購計劃是否有變化、衡量儲備庫存要保持多少才好……是這些因素在起關鍵作用桎梏採購工作效率,一個簡單的批量下達功能是無法從根本上解決這些問題的,儘管確實方便了部分人可以通過全選、下達等功能批量下達一了百了,但這顯然是不負責任的做法。
根本問題出在:提出優化需求的人,沒有把自己的要求明確傳遞給授權參與專案的關鍵使用者;IT在立項內容中縮小了問題考慮範圍,ERP優化不同於一般的小系統優化,往往牽一髮而動千軍,立項之前首先企業內部沒有進行過評估分析,同時IT也有必要站在全域性的角度考慮這個開發需求是否合理;顧問在有限的資源支援下,得不到完整的客戶需求問題點,更無從分析評估主計劃為什麼不剛性、供應鏈管理價格為什麼不規範。
二次開發‘知’與‘行’。以上案例中的專案甲乙方,無不互相抱怨,甲方抱怨乙方作為顧問公司沒有替使用者考慮全面;乙方委屈甲方沒有配備正確的使用者,沒有提出合理的專案範圍。既成事實,後悔已晚。讓我們來思考如何做好需求決策吧:
a)凡是實施了大型ERP系統的公司,其組織架構必然也比較比較龐大,任何工作流程的優化必然涉及其他部門,不穿越部門壁壘的流程很少,ERP軟體的管理思想就是由一組組緊密關聯的流程組成,所以在評估需求何調研需求時,企業IT都應該要特別重視ERP二次開發專案的需求調研範圍;
b)企業實施了ERP標準功能之後,需要不斷自我審查在日後的流程執行過程,是否有偏離,對於不健康的ERP系統運作,何談優化?因為根本無從下手去優化了,本案例中的需求,調查到最後其實可以通過業務流程規範來解決,可能最後根本不需要ERP二次開發了,這一點必須依靠企業的主觀能動性來檢討。不得不重視的是,顧問公司在接到訂單那一刻,基本沒有太多理由告訴客戶說這個專案不用做了,因為當顧問公司給出這樣的結論時,是對這個專案立項可行性的質疑,通常情況下,顧問公司不會如此做。除非專案立項之前,企業邀請了顧問公司來作評估分析,這一邀請行為可以成為專門的專案了,因為顧問人天都比較貴,況且企業IT應該承擔起ERP系統運作是否健康的監察責任;
c)企業持續培養知用善用人才的很重要。根據多年的專案實施經驗,不少企業在最初實施ERP系統時,培養了一批優秀的關鍵使用者,但在後來的建設和維護階段,因人員流動而喪失了這些熟悉系統原理的人才,我們往往發現很多優化專案中推選的關鍵使用者,其實對ERP系統原理後臺的資料邏輯並不清楚,他們只知道操作,出現疑問並不能有效自我診斷和思考;
d)作為顧問公司,在接觸到這樣的ERP優化專案時,要對客戶提出的果決的需求問題點,進行初步分析,以此來評定工作量以及合同細節,以免專案真正開展起來,出現如案例所述的時候,互相抱怨,進退兩難,賠了夫人又折兵,最終做了客戶不滿意的專案。同時,從行業分工來講,顧問公司具備優質資源,也應該承擔把握專案方向的主動權。
原文網址: http://www.chinasie.com/newsie/zyjj_view.asp?id=416
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/25533643/viewspace-690623/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- ERP二次開發的多與少
- 承接用友NC ERP與外系統介面以及二次開發外包
- 【ERP軟體】ERP體系二次開發有哪些危險?
- 機械行業ERP管理系統開發怎麼選?機械行業erp系統開發行業
- 考研大資料爬取與分析工具二次開發進行中。。。大資料
- 還在用ABAP進行SAP產品的二次開發?來了解下這種全新的二次開發理念吧
- banq與各位,請進,有關jive的二次開發??
- 網站修改二次開發,網站二次開發流程網站
- Dresdon二次開發
- ThinkS二次開發
- ORACLE ERP維護與開發中常用到的變數Oracle變數
- Voyager 的使用及二次開發
- 基於ecshop的二次開發
- 一個開源的OJ二次開發
- ERP 開發的真諦(轉)
- ERP管理系統是如何進行倉庫管理的呢?ERP管理系統開發
- 一次二次開發中的經驗與教訓(一)
- 一次二次開發中的經驗與教訓(二)
- SOLIDWORKS二次開發Solid
- ebs二次開發1
- ebs二次開發2
- ebs二次開發3
- ebs二次開發4
- ebs二次開發5
- ebs二次開發6
- ebs二次開發7
- NX二次開發-使用NXOPEN C++嚮導模板做二次開發C++
- 我的ECshop二次開發從零開始
- 【 Fenng】 關於 Discuz! 的二次開發
- 開發行業化ERP是大勢所趨(轉)行業
- Revit二次開發知識分享(八)控制顯示隱藏的圖元按鈕
- 杭州ERP生產管理系統開發的應用與優勢
- 電商企業如何選擇erp系統開發?erp系統開發
- UG二次開發筆記筆記
- SOLIDWORKS二次開發形式Solid
- kubernetes 二次開發
- 基於 solox 二次開發
- Revit二次開發-曲線三連:對curves進行排序排序