odoo導入之所以容易失敗的原因(文長)

淺談企業E化設計之差異以及變遷

Smith Lin

大家好,

標題殺人又一樁XD

今天要淺淺的談odoo與過去企業在E化時在系統架構與理解上的差異,
並由此引導出odoo的導入過程中最容易面對的困難點

今天的立論基礎,是以在下的過去經驗為基礎來立論以及分享~

如果跟實際狀況有差異的狀況,也請大家多多包涵與指教歐~~

企業E化以及ERP的發展,至今已經超過40年,市面上大大小小的產品玲瑯滿目

光國內就有超過300家以上的ERP廠商,更不用說國際品牌的數量了~

要說到ERP系統在系統架構的差異,以我一個企業流程設計人員的角度來觀察,大概有三種種類

1.企業文件表單(WORD /EXCEL)

 當一個公司到達一個規模時,為了加速企業流程以及建立內部SOP

 【表單化】是必定的過程

 而每個企業手上基本上都會有的辦公室軟體office就是最初始的E化工具

 透過企業內部規定的格式,以文件進行編輯、透過列印進行內部流程送簽

 這些都在我們目前的辦公室情境中可以說還屬於大宗!

 word/excel的特性是文件編輯的方便性以及高度直觀,

 但以他人協作、表單版本、文件資料更新、異地存取以及資料彙整工作困難等等需求就是他的弱點!

 有時候甚至會影響到企業的SOP穩固性!(如被核准的報價單內容等等)


 因此當公司到一定程度時,漸漸會思考要透過一個內部系統,將企業文件表單E化

 進而使企業的SOP能更加持久永續!


2.企業功能式表單之E化系統概念

 在企業E化的第一個概念,就是將企業文件表單整個複製並抓進來系統,

 利用系統的運作,解決前面所提的WORD/EXCEL的缺點:協作性、表單一致性、文件內容更新、異地查詢資料,並且透過資料庫架構解決後續資料彙整工作困難等問題。

 而最後,最好系統可以將系統表單內容轉為Word/Excel,因為這些格式是大家最熟悉的~

 對,似乎企業表單E化把問題都解決了~天下太平 YA

 但在實行了幾年後,新的問題才漸漸浮現~

 A.系統客製的開發成本高昂:
       這個問題來自於客製系統二字,因應每個企業的內部表單與流程的差異,每間公司在提出E化的需求時必定是不同的內容與表單,當在投入A公司系統開發的工作時間無法應用到B公司的軟體開發案時,自然A公司的報價就必須納括所有投入在A公司的開發成本。(當然,使用的語言也會影響到開發的成本)因此後續的軟體市場自然演變成規格化的軟體,以及每個產業所對應的軟體各有山頭的服務模式。

 B.表單E化造成企業在流程掌握的自由度下降:
       這個問題發生的原因主要來自於公司的系統不一定是由自公司團隊開發,再者開發人員亦有可能更替,因系統程式等並非Word/Excel等工具容易被理解或被教導,因此造成企業流程的彈性以及自由度下降。


 C.無止盡的軟體調整需求:
       一來提供企業表單E化的軟體商基本上不是系統的使用者,造成的問題很可能是開發人員想像的使用情境與軟體使用的實際情境具有差異,或是開發過程中系統存在的各種bug等等。再者需求變更等也是非常常見的調整需求型態,在過去經常是透過長期維護合約的模式進行服務。

當然又回到這些軟體調整需求,如果是for該產業的所有公司使用,也許在後續維護上就相對容易(如文中在每次政府稅務表格的調整之於台灣會計師服務產業),但如果是給單一公司使用的客製就會造成後續服務的成本增加。


 D.重複性的資料表新增:
       當每個表單進行獨立開發時,很有可能造成的是資料的零星化以及資料連貫性不足,例如在A表單建立了客戶資料、在B表單建立了供應商資料,當同時具有兩者身分之合作夥伴時則必須建檔兩次等等。如此的問題也造成資料後續在應用以及分析時可能造成新的困難。

因應以上的問題,軟體市場漸漸地有以下行為作法(沒有好壞只是提出觀察結果XD):

A.軟體服務由客製化轉向產業套裝化,推展所謂企業流程重整的觀念,減少該產業系統流程的歧異性

B.軟體的語言持續更新,但遇到大更新時因應成本考量仍有侷限

C.系統架構的重新整合,以概念方式進行抽離,並逐漸朝底層化運行

3.底層化的系統架構設計概念
在過去的軟體公司提到"底層"一詞,一般而言的理解是在於系統環境、使用介面等底層,而底層化的系統設計一詞,在軟體產業的用語則是"抽離共用模塊工程",針對表單式的E化系統把共用性高的模塊進行概念抽離,得以達到模組化的系統開發,減少開發成本,同時具備了模組間的資料一致性。我們可以在odoo的系統架構觀察底層化的系統設計,最簡單的例子是跨模組使用的產品以及供應商資料庫,而比較難去理解的是odoo的庫存系統以及財務會計系統,同樣也是底層化的設計架構。


而就實際odoo的導入現場經驗發現,

因"抽離共用模塊"的觀念相較於直觀之表單式的E化系統更為抽象,
(尤其在庫存系統,獨具的複式庫存核心重新解構並重整了一般人對庫存系統的理解),

也是造成相較於其他E化軟體而言,odoo獨具的【系統理解門檻】

也造成許多導入案在導入中經常遇到重大困難的原因!

(內外部)導入顧問要先願意花時間投入odoo抽離式的系統設計架構的研究~

並且還要再導入案中教授系統使用者系統觀念,還要引導他們能接受系統的設計~


以上這些還不討論如何進行模組客製解決既有模組沒達到的問題~

整麼想也覺得是很困難的事~ 但相同的也體現了顧問的價值所在!

因其特殊性,若odoo在台要能夠更有效的開展,

自然必須要有人願意投入系統底層架構的研究,

並且將研究成果有體系的進行傳播,

減少顧問必須要投入研究的時間成本,
並提升台灣生態系的導入應用能量!

我們相信那句話:

『一個人,走的快;一群人,走得遠!』

人類社會之所以能夠持續成長,

不就是因為透過走的快的人持續嘗試並深度研究,

並且將已知的結果回饋給大部隊往哪個方向前進,可以更好,

只有大家一起進步了,社會才會創造了那麼一點不同!

這同時也是元植應用課程設計的初衷,

我們目標在減少各位兄弟(以及姊妹)各自登odoo這座山的「辛苦」以及「孤獨感」,
我們永遠記得登頂時,目見第一道曙光的感動~
也希望將這個感動可以傳播給更多人!

希冀課程可以成為台灣odoo生態系有一個新的可能性,

在不論是在系統導入應用人員以及系統開發人員間建立溝通語言!

在相同的基礎與國度中,因而可以有進一步的擴大與發展!

Odoo圖像文字塊

20190818 筆於板橋

認同請+1 並分享~

留下評論

您應該 登入 張貼評論