【ERP】這個名辭
以前,大家都說【電子資料處理, EDP 】。專科學校在早期有開設【電子資料處理科】。
後來,可能【EDP】這個名辭太低階,於是有大學把【電子資料處理科】升級成為【資訊管理系】,這樣才能反應大學傳授的知識之高、大、上。
幾年後,可能有人認為【EDP】一辭缺乏 管理精神,於是又出現【 ERP】這個融合 電子資料處理技術與 管理 於一體的新名辭。
2019年初或更早,開始流行一個涵蓋範圍比【ERP】寬廣的新名辭 — 【數位轉型,digital transformation】。
新名辭層出不窮,多是舊瓶新裝、概念和名辭炒作。其實【商業資訊應用軟體系統,business information application software system】這個老舊名辭最樸實無華。但是它太長,今年少有人聽得懂,而且有點土。為方便溝通,於是入境隨俗,本文一致使用這一代人都聽過、簡短、尚未被時代淘汰的【ERP】這個名辭。
其實【ERP】這個名辭仍有爭議:
- 個性保守的張三認為:【ERP】僅限於軟體範圍。
- 李四堅持:有一款【ERP】,它不只是軟體而已,軟體商更加持高深、奧妙的世界一流管理理念在其軟體裡面,融合管理與數位科技二者。說它是「軟體」等於在貶抑管理科學的價值,說那些軟體只是昂貴DVD的人是在毀謗軟體商的清譽。
- 王五主張:【ERP】只是軟體,而軟體只是工具而已,其單獨重要性不高。一旦剝離管理,則【ERP】猶如殭屍,只剩下沒有精神的軀殼。最重要的是人。也就是說,用戶企業唯有禮聘管理大師做其顧問,佐以富含管理心法的上線輔導,【ERP】的作用才能有效顯現。否則,【ERP】專案把軟體推上線都有困難,何況期待發揮它對企業的管理效益!
因為本文聚焦於技術,所以【ERP】一辭在這裡專指商業資訊應用軟體系統,也就是第1.項的範圍之內,不論及管理。
ERP品質的重要性
ERP軟體品質決定ERP專案的成敗。理由:
- ERP軟體的核心品質無法於推動ERP專案過程中大幅度改良。
- ERP專案輔導顧問,可以隨時增加人數,也可以隨時用學歷更高、經驗更豐富的專家取代顧問團成員。
- ERP專案推動過程所採用的管理策略、品質保證和監督機制、溝通技巧和頻率、對使用人的訓練時數和品質,都可以隨時加碼、調整、改良,甚至重複實施。
大量案例證明:一旦ERP軟體的核心品質不良,則第2.和第3.項調整措施完全無效。那些採用劣質ERP軟體的ERP專案只有三種結果:
- 直接以失敗告終,軟體廢棄不用。
- 勉強使用會計和銷售等1~2個模組,但是對外仍宣稱「成功上線」。
- 企業用戶持續加碼人員和硬體,做困獸之鬥。
ERP品質最終將在其企業客戶的損益表和資產負債表上面呈現。ERP品質深遠影響其用戶的營運成本、成長動力、企業形象、研發與客服以及公關等各部門人員的士氣。
所以,ERP架構師必須兼顧下列角色的利益以設計【頂級ERP】:
ERP必備核心功能
再陽春的ERP也必須提供下列全部基本功能。
- 提供機制供IT人員設計畫面,供終端使用人輸入、讀取、修改、刪除資料。
- 提供機制供IT人員設計業務邏輯處理器,供終端使用人執行。例如:金錢交易生成會計分錄、會計結帳、計算薪資、計算MRP、計算保費或理賠金額。
- 提供機制供IT人員設計報表,供使用人列印報表。
- 提供與外界交換資料的機制。
頂級ERP的特質
頂級ERP必須簡潔。它兼具下列特質:
- 萬用
- ERP平臺
- 高彈性
- 簡單、輕巧、低系統開發門檻
- 資料庫驅動
- 使用PostgreSQL
- 三層運算架構
- 高速後端軟體
- 客戶軟體輕巧
- 使用人容易操作
- 國際化
- 提供報表
- 高雅的會計模組
- 附掛檔案機制
- 提供簡單、高效率的API
- 具安全保護機制
- 預留SaaS和PaaS發展空間
1. 萬用
萬用ERP同時具備下列特質:
- 適合各種行業的企業使用,包括政府、學校、非營利事業…等。也就是具有「多產業」能力。
- 適合各種規模的企業使用,從一人公司到跨國集團。
1. 擺脫ERP只能應用在特定產業的傳統限制:
- ERP也許可以給業務性質單純的工廠將就使用,但是不適用於出租車企業、人壽保險公司、連鎖零售商、天然氣公司、醫院、銀行、郵局、電力公司、晶圓廠、石油公司、輪胎工廠、自來水廠、貨運代理、學校…等非製造業企業和政府部門。
- ERP也許可以給要求不高的製造業工廠將就使用,但是嚴格要求「批號」控管的藥廠、鞋廠、服裝工廠買它會很慘。
- ERP的架構不適合用來開發人力資源系統。
- 「鞋廠專用ERP」不能用在工具機工廠。
- 適合企業使用,不適合政府部門使用;或相反。
一套只適合特定產業使用的ERP,一旦硬塞給不同產業的企業用戶,其使用範圍可能被用戶企業縮減到剩下會計模組,甚至被架空成資料儲存中心。
唯有萬用ERP才有資格銷售給來自各種行業的企業和政府部門。
2. 擺脫ERP只能應用在特定規模企業的傳統限制:
- ERP適合大企業使用:因為過於複雜,小企業和一人公司用不起來。
- ERP適合小企業和一人公司:因為過於陽春且僵化,如果拿去給大企業使用,有太多功能短缺且不允許擴展。
2. ERP平臺
為達萬用目標,有多種策略被採用。
一、霰彈槍策略
這個策略又稱萬金油、萬靈丹策略。其極致發揮,就是盡其可能,根據經驗或猜測不同企業可能需要的全部軟體功能,一一預製程式或模組,等候企業客戶挑選或全部捆綁出售。
按照這個策略做出來的ERP預製品,體積龐大、複雜難用:
- 畫面多、程式(「transaction」)多、開關多、參數多。
- 隱藏機制多、連動機制多、機制互相牽制或排斥。
- 手冊和線上說明難以清楚涵蓋,手冊錯誤或過時、與軟體不一致。
這種軟體具有下列缺陷:
- 預製品未能滿足一些企業的「特殊」或邊緣需求。
- 因為複雜,所以可能不存在那種打通奇經八脈,完全弄懂ERP全部甚至單一模組的顧問,導致使用ERP的企業常年在「急徵顧問」。
- 因為ERP架構具有重大先天性缺陷,軟體商自己和導入顧問也無法按照計畫時程開發完成商業應用軟體以即時交付企業用戶使用。
- 因為難用,所以對使用人訓練的過程艱辛,使用人產生排斥,專案出現強大阻力,導致上線困難甚至失敗。
- 因為程式龐大甚至系統架構僵化,所以IT人員不易擴增或修改ERP功能。導致IT部門人數居高不下,形成企業的沈重人事費用負擔。
- 後端軟體跑不快,迫使企業用戶購買昂貴硬體、設置龐大的基礎設施(infrastructure)IT人員。
二、程式產生器策略
在M$ DOS時期已經出現「程式產生器」概念。筆者於數日前開始耳聞「citizen low-code development platform」或「low-code development platform」名辭,甚至有人主張用人工智慧( AI )產生軟體。
待解疑問:現在有哪些商轉程式產生器,其生成的軟體,
- 能否用來處理各行各業的商業資訊?
- 能否取代現有ERP軟體?
- 執行速度是否比目前手工打造的傳統軟體高?
- 能否人工介入除錯、強化、擴展?
假設現在需要一個人事薪資模組如下,有沒有程式產生器或AI機器人能自動設計出來?
- 三班制:07:00 ~ 15:00, 15:00 ~ 23:00, 23:00 ~ 07:00
- 大夜班有點心。
- 遲到30分鐘以內,扣薪500元。
- 記2次大功者,頒發3日工資做為獎金。
- 遲到1 ~ 4小時者須請半日假。
- 曠職扣2日工資。
- 提供全勤獎金。
- 記警告1次扣一日工資。記大過1次扣3日工資。
- 除了經理級以上人員以外,全員刷上、下班卡。
- 工廠有職級 — 薪資表。
- 外籍勞工提供住宿。
- 提供折價餐給現場人員。
- 實施勞保、健保、薪資所得扣減機制。
因為有諸多未解疑問,所以這種策略到此為止。
三、積木策略
很早以前就出現「 CORBA」。不知何時出現「 SOA 」、「micro service」等名辭與之抗衡。
因為沒聽過有哪些ERP是採用這種策略而製成,所以無法評論這個策略。
四、平臺策略
這個策略以設計出能實現前述【ERP必備核心功能】的ERP平臺為目標。平臺也可以稱之為「框架,framework」。
本文自此以下專指這個ERP平臺。
3. 高彈性
ERP能萬用的前提是高彈性。那些預製的套裝軟體,無論有多少模組、多少開關、多少產業樣板、多少最佳配置方案、預製幾百萬列程式,都屬於 霰彈槍 之流,不能被歸類在高彈性系統,不堪用於「特殊」企業和政府部門。
這裡必須澄清一個觀念。「特殊」其實是錯誤用語。不應該只因為ERP不適用於非製造業,就指其他更多行業為「特殊」。
要怎樣架構ERP才能符合高彈性原則?
「你要高彈性?程式語言的彈性最高了!乾脆賣COBOL的兄弟姊妹、4GL、Java、Python、C語言、甚至組合語言給客戶,叫他們的MIS人員自己去開發其商業應用軟體好了?」
那不是筆者原意。使用程式語言去開發各行各業的應用系統,雖然確實具有最高彈性,但是因為它有一個重大缺點 — 最低生產力,所以這種策略不可取。
4. 簡單、輕巧
小學生都知道:傻瓜總是把簡單的事情複雜化。
架構頂級ERP應該力求簡單而非複雜,輕巧而非龐大。
只有簡單的ERP才會有高彈性 。
- 它節省企業客戶的硬體投資:能在一般規格的硬體上面高速運轉,瞬間回應使用人。反之,一套複雜的軟體猶如恐龍:它在高檔硬體上面緩慢拖行。
- 它減少企業客戶開發應用系統的人力成本和時間:因為容易維護、修改、擴充並投放在多種環境中運行,所以IT人員、系統整合人員、以及顧問具有高生產力。反之,一套複雜的軟體不聽MIS人員的指揮、拒絕被馴服、無法調校而導致全部參與者人心渙散、專案進度一再延後。
- 簡單 :整套ERP只有少數元件構成。而非疊床架屋、千絲萬縷牽扯不清、原始程式碼數百萬列、安裝檔案達數百MB、資訊人員和軟體商自己都無法參透的那種複雜軟體。
- 輕巧:整套ERP的原始碼很小。例如:未經壓縮,小於300 KB的製造業程式,含成本、MRP等計算,任何資訊人員都能輕鬆維護。
- 低系統開發技術門檻:因為頂級ERP平臺具備少撰寫程式的開發平臺特質,所以資訊人員能輕鬆擴展和維護應用系統,而且平民資訊系統開發人員成為可能。換言之,企業也可以把「終端使用人」納入應用軟體開發成員。這裏的「終端使用人」可以包括會計部的人員、精算部的人員、銷售部的人員…等。
5. 資料庫驅動
ERP軟體必須電子化企業業務(作業、流程)。
筆者經驗:大部分的企業業務可以用CRUD畫面實現。
以企業的銷售業務為例,其流程包括:
如果能設計3個CRUD畫面,提供使用人執行上述業務全部CRUD操作的話,則換言之,3個CRUD畫面已全部實現該企業的銷售業務流程。
這時候,如果ERP平臺可以透過簡單的定義方式,不需要撰寫任何程式就完成這3個CRUD畫面的話,則這套ERP平臺稱為「資料庫驅動」。
「資料庫驅動」不是追求時髦或炒作新名辭,而是為了架構出具有最高生產力的ERP平臺,讓技術人員能在它上面以閃電速度開發完成各種企業資訊應用系統,速戰速決,於短期完成ERP專案。
6. 使用PostgreSQL
ERP必須搭配使用資料庫管理系統(Data Base Management System, DBMS )。
頂級ERP平臺搭配PostgreSQL使用的理由:
- PostgreSQL是全球最先進的開放原始碼DBMS,其性能滿足優質ERP平臺的要求。
- 企業客戶免除購買DBMS授權和維護費用。
- PostgreSQL提供極佳品質的手冊。
- 容易取得高品質的技術服務。
7. 三層運算架構
- 二層運算架構:
這種運算架構具有下列缺點:
- 當DBMS連接大量客戶軟體時,其性能快速下降,佔用大量記憶體。
- 如果在公開網路上運行ERP,則DBMS在公開網路暴露,易遭惡意攻擊。
- DBMS與應用程式二者之間的資料傳輸量高,遠程ERP使用人感覺系統回應速度緩慢。
- DBMS與應用程式二者之間的資料傳輸不加密,無機密保護機制。
- 三層運算架構:
- 四層以上運算架構:DBMS←-→後端服務軟體←-→前端服務軟體←-→客戶軟體
這種運算架構不允許前端軟體連接DBMS。後端服務軟體提供大量且複雜的API供前端服務軟體呼叫。該架構因為疊床架屋而具有下列缺點:
- 學習曲線陡峭,開發業務應用系統的困難度高。
- 整套系統複雜、不易維護,容易出錯錯誤。
- 運行速度緩慢。
- 需要高硬體投資。
為了趕流行,一些中國大師們於2018年起開始為這種運算架構取了一個全球獨一無二的新名字「中台」並且大做文章。
頂級ERP平臺採用三層運算架構。
8. 高速後端軟體
隨著客戶數的增加以及業務邏輯的複雜度提高,ERP伺服器軟體的冗長回應時間容易被詬病。緩慢運轉的ERP伺服器軟體浪費其使用人的寶貴時間,降低其工作效率。
稍具理智和自尊心的正常人不會盲目崇拜自己不懂的東西。但是資訊產業卻盛傳 「軟體越龐大、越複雜難懂,則其能力越強大」迷信,大師們極力灌輸普羅大眾奴才心態:「品質最高的軟體,就是你平庸之輩一生也摸不透、搞不定的那種」。
常識101:越複雜、龐大的ERP伺服器軟體,其運行速度越低,隱藏錯誤越多,耗用越多硬體資源。它是一套設計不良、過時的劣質ERP架構。
因為ERP伺服器軟體運行速度遲緩,一些ERP廠商轉而要求其客戶購買高檔主機以供其伺服器軟體在上面執行。這種安排,錯在這裡: ERP整體系統的運轉速度瓶頸在軟體而非硬體,所以ERP 企業用戶投資金錢在硬體上面,對系統的整體運行效能改善不顯著 。
腦筋清醒的資訊產業人士都心照不宣的事實:有軟體商利用其軟體缺陷去哄抬其產品售價,搜刮其企業客戶的現金。
為甚麼一些ERP龜速?因為 它們在伺服器軟體處理業務邏輯 ,所以具有無可救藥的先天缺陷:
- 伺服器軟體龜速運行。
- 伺服器軟體和DBMS之間佔用大量網路頻寬。
這種ERP這樣運作:
- 從客戶端程式接到執行MRP的請求後,伺服器軟體首先從DBMS讀取資料。伺服器軟體接著掃描讀進來的資料。在掃描每一筆資料時,伺服器軟體又再對DBMS讀取更多資料記錄。這樣一直層層反覆深入,連鎖地向DBMS讀取資料。這種資料處理策略當然低效率:
- 伺服器軟體盡可能從DBMS讀進大量資料,越多越好。所以它吃掉大量RAM和CPU。
- 如果伺服器軟體和DBMS不在同一部硬體主機的話,那麼,企業用戶就必須投資高檔的網路設備以供大量資料在伺服器軟體和DBMS二者之間高速往返。
- 在伺服器軟體處理資料的效率,遠低於讓DBMS直接處理。其理由非常簡單-全部臺面上的DBMS,尤其是PostgreSQL,都會優化其處理資料過程。DBMS就是知道如何、何時、是否該讀進哪些資料,以耗費最低的CPU、RAM、和硬碟的成本。但是伺服器軟體就是少有能力控制這些資源。
把簡單的問題複雜化,再去發明一堆有的沒的神奇機關,都是枉然,其最終效益極可能呈現負數。
輕巧、簡單等於優良。設計高速ERP伺服器軟體的最高效策略就是:
- 業務邏輯交給DBMS執行
- 伺服器軟體扮演客戶端軟體和DBMS二者之間的仲介角色
這種架構以無人能敵的閃電速度運行:
- MRP、結會計帳、計算薪資…等業務羅輯全部在DBMS的stored procedure(即PostgreSQL的function)執行。
- 接到客戶程式的請求後,ERP伺服器軟體即確認請求方的身份和權限。
- ERP伺服器軟體在快取搜尋所需結果。如果找到,則二話不說,直接回應此結果給客戶軟體。
- 如果ERP伺服器軟體沒在快取找到答案,則向DBMS轉送請求。從DBMS接到答案後,ERP伺服器軟體立即回覆客戶端程式。
優質ERP伺服器軟體就是扮演這樣單純的角色,不多也不少:
- ERP伺服器軟體幾乎不從事計算工作。
- 更動業務邏輯無須更動ERP伺服器軟體
- 其軟體簡單、容易維護、幾無bug。
- 能在1 GB RAM的主機上面以閃電般的速度運轉,瞬間回應海量客戶程式的請求。
9. 客戶軟體輕巧
客戶端軟體動輒4片CD的那種ERP早已落伍了。頂級ERP平臺的客戶應該這樣設計:
- ERP客戶軟體應有高相容度。以瀏覽器為基礎的ERP客戶軟體短期內應該不會消失。
- 如果設計桌面ERP客戶軟體,則應該遵循兩項原則:
- 輕薄短小,壓縮其體積到10 MB以內。
- 單一執行檔案,使用人直接雙擊執行。使用人無須安裝,資訊人員無須分發、部署客戶軟體。
10. 使用人容易操作
容易操作的客戶軟體減少訓練工作,縮短系統上線期,提高使用人的工作效率,降低使用人對ERP的排斥。
- 減少CRUD畫面和菜單數量。使用人容易上手。使用人在少數畫面操作ERP,就能完成其日常工作。避免迫使使用人開啟多個CRUD畫面,來回切換、比對、翻找畫面與畫面之間的資料、操作CRUD。
- 手冊頁數少。使用人參閱數分鐘即可實際操作軟體。
- 以各種語系提供廣泛的線上說明。畫面說明、欄位說明、報表用途說明、報表參數說明、業務邏輯處理器說明、業務邏輯處理器參數說明。使用人不必翻找年久失修的過期手冊。
- 每一個畫面外觀布局完全相同。適應ERP的操作畫面需要時間。應該避免設計出這類系統:不同CRUD畫面,其欄位的位置安排隨性,按鈕、彈出窗等機制都不一樣。
- 容易搜尋資料。例如:使用人可以就CRUD畫面上每一個欄位搜索紀錄。畫面上顯示的紀錄都允許使用人下載。
- 提供選單給使用人。避免強迫使用人背誦程式代號(「transaction」)。
11. 國際化
多語系、多時區、多曆法:
- 多語系:
- 一套程式支援全部語系。不是那種相同功能的程式寫4個版本:版本一支援正體中文、版本二支援簡體中文、版本三支援英文、版本四支援越文。
- 客戶軟體允許使用人線上切換語系,不必先登出再登入。
- IT人員設計完成一份報表之後,使用人以各種語系列印報表。
- 支援阿拉伯文、波斯文、希伯來文等,由右至左書寫文字。
- 多時區:以【出貨日期】為例,倫敦的ERP使用人看到2019–12–25 11:09:03.356505+00,臺北的ERP使用人看到2019–12–25 19:09:03.356505+08。
- 多曆法:同時支援Gregorian曆法和Solar Hijri曆法
12. 提供報表
- 整合報表在ERP裡面:IT人員設計完成一份報表之後,使用人立即在選單中挑選並列印報表。IT人員不必分發報表給各使用人。避免外掛報表功能,脫離ERP而獨立。
- 完整的報表能力:允許IT人員高速設計完成各種報表,以滿足使用人多樣、複雜的需要。
13. 高雅的會計模組
- 首先,架構師應絕對避免寫出那種企業用戶必須花45天才能完成會計月結的劣質會計模組。
- 會計模組必須與各業務模組無縫整合,及時生成分錄,令分錄永續保持最新狀況,令財務最新資訊隨時可得,無須等到月結,隨時提供企業經營績效訊息,使用人無須等到次月初會計結完帳。
- 會計人員只需負責極少量的日常與月結工作。免除會計人員月結過帳、過帳失敗、反過帳等工作。ERP保證不出現負金額、借貸不平、負數量…等狀況。
- 絕對防止出現資料在模組之間不一致現象。例如:item A,
- 在銷售畫面或報表顯示:售出10個,銷貨成本2元/個。
- 在庫存或成本畫面顯示:售出11個,銷貨成本3元/個。
14. 附掛檔案機制
為貼近無紙化目標,ERP應提供機制,讓使用人上傳檔案,附掛在資料紀錄之下,並允許日後下載。例如:
- 研發人員上傳加工說明圖檔,附掛在項目item A之下,供加工現場下載參考。
- 專利事務所人員上傳往來書信,附掛在專案申請進度日期2020–1–1日之下,供日後查閱。
15. 提供簡單、高效率的API
ERP平臺應提供API一套優質ERP有能力簡單、高效率、安全地與外界交換資料。
ERP伺服器軟體應允許客戶的IT人員以設定方式而提供RESTful API供諸如IoT和MES等外界設施呼叫,直接對指定的資料庫table操作CRUD。
基於生產力考量,技術人員都避免和學習曲線陡峭、需要嘗試錯誤的API打交道。
筆者推薦JSON,不推薦XML、SOAP。遠離ActiveX等專屬界面。
16. 具安全保護機制
設計ERP平臺時,應該設想安全保護機制,例如:
- 資料傳輸過程加密。
- 預防SQL injection攻擊。
- 預防Resource exhaustion attack攻擊,例如:
- 使用人輸入BOM循環項目(例如:子項目等於父項目)。
- 使用人在前端調出大量後端資料。
17. 預留SaaS和PaaS發展空間
頂級ERP平臺是SaaS和PaaS時代的唯一方案。
效益與風險
簡潔是架構頂級ERP平臺最重要的基礎。因為簡潔,所以才有前面提到的各項【 頂級ERP的特質 】。
架構師完成頂級ERP平臺之後,
- IT技術人員在這個平臺上面幫來自各產業的大、中、小、微企業量身訂做100%符合業務需求的ERP應用系統。
- 使用這個平臺在大企業推動大型ERP專案,其失敗的可能性趨近零。
這個頂級ERP平臺不是另一次空泛概念炒作,而是既成事實;它既是觀念復古,也是技術創新;它重回過去的簡單,形成IT產業的未來主流。
原文出處: https://www.terarows.com.