mes實施失敗,責任在誰?
很多企業在做完 專案之後,如果感覺做得很糟糕,就會把罪責推到MES廠商身上,認為是他們的軟體功能不好。或者把罪責推到諮詢公司的實施顧問身上,認為是顧問們的水平不高,沒有幫企業把專案做好。總之在很多MES案例中, 或者諮詢公司成了專案失敗的替罪羊。
但是我們不得不承認,這些MES失敗其實主要是企業自己造成的。如果去媒體或者網路上檢視一些總結MES專案失敗原因的清單,我們就會發現,不管是哪個清單,透過檢視前面的五個原因,都可以明顯地瞭解到,企業要為MES專案的失敗負有不可推卸的責任。
退一步來說,即使MES廠商或者實施顧問是造成專案失敗的原因,那麼是誰把MES軟體買回來的,又是誰把這些顧問請到企業來的呢?這樣看來,罪魁禍首還是企業。
有些企業可能會說,大部分的實施工作都是實施顧問們牽頭完成的,現在專案沒有做好,如果不能怪他們,那麼要怪誰呢?
其實,實施顧問們牽頭去做MES專案,很多時候都是迫於無奈。當企業員工沒有積極地參與進來,導致MES專案的進度無可救藥地落後於計劃,顧問們實在沒有辦法,就只好自己去做那些原本應該由企業完成的實施工作。
企業一定要清楚,員工不積極參與MES專案的後果,不只是提高了實施成本,更糟糕的是,這樣去做MES專案是不可能做好的。很多企業高層領導在專案做完以後,會感到很奇怪,為什麼其它同行用得很好的一套MES系統,卻不能滿足自己企業的管理需求呢?殊不知主要原因在企業自己身上。就好像看別人開車開得很好,為什麼自己就開不好呢?能怪車子不好嗎?應該只能怪自己開車水平不高,或者怪自己學習的時候沒有好好學好好練。
從實施顧問的角度來看,雖然顧問們從這些消極參與以及知識缺乏的企業身上賺了很多錢(還記得我們在前面文章裡面所說的嗎,對諮詢公司來說,企業知道的越少,他們就會賺的越多),但是沒有顧問願意把MES專案做失敗,也沒人願意在自己的工作履歷上抹黑。
實際上,每個顧問都希望能夠讓企業滿意,都希望能夠把專案做好。但是由於很多原因導致專案進度一直在拖延,比如企業方實施人員總是找不到人、遇到問題的時候企業沒人來解決、需要企業方決策的時候也沒人做決策。尤其糟糕的是,企業總是在不斷地改變想法。
一方面是企業員工的消極參與,另一方面是上線日期越來越臨近,還有就是顧問們所在公司的領導也希望早點結束專案把款項拿回來,這種種壓力之下,顧問們就只好越俎代庖了。即使顧問們知道這樣做專案不會有好結果,也只好趕鴨子上架。
很多企業之所以會把沒有做好MES專案的罪責,推到MES廠商或者諮詢公司身上,還有一個很重要的原因,就是企業對外部顧問和MES軟體有很多不現實的期望。
企業認為,顧問們的水平應該很高,他們有責任也有能力牽頭把企業的MES專案做好。其實這只是企業的一廂情願。要知道,實施顧問們也是人,他們不可能無所不知,不可能總是做出正確的決定,也不可能總是做正確的事情。另外,當顧問們首次踏進企業門檻的時候,他們對企業是缺乏瞭解的,即使有些瞭解,也是非常有限的瞭解。
所以在MES專案上,如果企業放手讓外部顧問去做,那麼結果是一定不會好的。如果企業最後發現顧問們做的專案規劃、設計的業務流程以及制訂的管理解決方案,有很多地方是錯誤的,企業就不要感到驚訝了,誰叫企業自己的員工不積極參與進來呢?
如果MES專案被搞砸了,然後企業不得不透過二次實施來重新設計業務流程,重新配置系統引數,那麼這種二次實施對企業來說,從來都不是一件容易的事情,企業也一定會付出更大的代價。很多企業在MES系統上線以後,還要自己折騰兩年才能讓系統正常執行起來,就是這個原因。
企業除了對外部顧問有不現實的期望,對MES軟體同樣有很多不現實的期望,認為MES軟體應該是無所不能的。為什麼MES軟體不可能無所不能呢?答案很簡單,因為設計MES系統的人,不可能理解世界上每家企業的管理需求,更何況軟體只是軟體。
換句話說,如果企業在選型階段沒有做好該做的事情,導致所選的 存在太多功能上的缺陷,那麼企業就是在自找麻煩。如果MES軟體的功能本身有很多不足之處,那麼即使實施顧問使出渾身解數,也是很難讓企業滿意的。
總而言之,如果MES專案沒有做好,企業誰也不能怪,只能怪自己!
擁有強大而靈活的二次開發功能以及產品的高度可配置性和擴充套件性。產品的高度可配置性和擴充套件性不僅僅有利於系統的快速實施,更對實施後的日常維護和功能升級提供了極大的便利。效率科技MES開發團隊可以切實的幫助客戶提高質量、提升效率、降低成本。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69970554/viewspace-2698827/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 三大因素影響零信任實施失敗
- 【Ansible】ansible任務失敗控制
- 製造型企業MES實施方法
- 企業資料中臺實施過程中失敗的因素
- 軍工企業MES實施探討
- MES實施難點及改善對策
- 責任鏈模式的實踐模式
- 責任鏈模式在SpringAOP中的使用模式Spring
- 在 Homestead 下面更新 Composer 失敗
- 實施MES時要避免的五個錯誤
- ERP/MES製造系統實施的效益分析
- 責任鏈模式在 Spring 中的應用模式Spring
- 以失敗為機制:奇異人生中的真實失敗與虛構性失敗
- 在容器外部連線kafka失敗Kafka
- MES現場實施的關鍵選擇事項
- MES系統和ERP系統可以同步實施嗎?
- 軟體實施經理崗位職責
- 責任鏈模式模式
- Spark 叢集執行任務失敗的故障處理Spark
- Java的快速失敗和安全失敗Java
- 「責任鏈模式」栗子模式
- 責任鏈模式探究模式
- 責任鏈模式妙用模式
- IT企業實行FMEA是由誰控制並負責?
- git push程式碼失敗,鑑權失敗Git
- 快速失敗機制&失敗安全機制
- Composer 失敗
- 手繪PK機繪:在閱讀/學習的應用中誰勝誰敗?
- 使用函式式方式實現責任鏈模式函式模式
- 定義、整合並實施帶有控制元件的MES和ERP控制元件
- 23_責任鏈模式模式
- PHP-責任鏈模式PHP模式
- 這就是『責任鏈模式』?模式
- 責任鏈模式(Chain Of Responsibility)模式AI
- 5、php責任鏈模式PHP模式
- 《Netflix文化:自由與責任》
- mysql連線失敗:ArgumentException: 指定的值在“SslProtocolType”MySqlExceptionProtocol
- 最高院--返修責任與保修責任應嚴格區分,工程竣工驗收合格後保修責任的起算並不必然意味著返修責任的滌除