談談親歷的WMS、MES與ERP的整合之路

談談親歷的WMS、MES與ERP的整合之路

<章一>困惑篇

2016年集團資訊部初建。領導、決策層對企業資訊化的重視與認知，作為實踐者倍感壓力巨大，大面積的周邊系統遷移與基礎建設忙得不可開交。然而當希冀與現實發生完美邂逅的時候，卻倍感慶幸，能去付諸實踐、去逐步完成設想與規劃。同時不得不感慨自己的渺小，決策當前，怎麼多管齊下、有條不紊的進行工作。這一年裡，在領導帶領下團隊完成了流程系統的支撐、訂單前端系統的開發、決策資料收集、展示以提供資料支撐、資料與業務雙驅動。
在2017年時決策層在遵循試、快、用原則下從集團企業中優選了一家做試點，旨在建立WMS、MES智慧工廠。
選型階段時，多方齊動。業務需求方匯點成面，多維度梳理、評估與制定業務需求；IT團隊從軟硬體方面更多考慮支撐完善度與二次開發功能的擴充套件能力；供方從專業角度答疑解惑，藍圖初構。
隨著需求明確，軟硬體評估，以及供方的最終確定。從決策層的目標指向上我們把這次專案的重點管控列為：系統間互動與智慧響應；管理方案、體系化建立（量化、流程化、標準化）；軟體業務層實現與管控。不難理解，軟體層將由內外雙方共同擬定方案及實現落地，這也是供方的基本交付能力；同時雙方應共同建立管理方案、業務及管理能量化的量化、不能量化的流程化，不能流程化的標準化來管控業務流向、過程約束，達到簡單操作、高效健壯執行提升效率。然而多個供方溝通後背我們首先列入可識別風險的重要項都指向：介面互動怎麼實現。
在意識首當其衝的大難題時，內部團隊與WMS、MES廠商進行了第一次面對面的深入溝通，當然做為小白的我們，正以待哺的姿勢接受第一次洗禮：
1.開放ERP查詢及回寫介面給對方查詢或排程；
2.ERP端觸發到WMS、MES廠商提供的中間庫，以供對方定時載 入，同時定時抓取WMS、MES廠商傳回的資料回寫ERP；
3.人工處理。

面對困惑，已然不再是庸人自擾，而是難以支撐決策，從現實來看，當時還在服役的ERP沒有介面、無法掛載觸發器(當然也不推崇，後文有敘)，此為軟體之困惑；集團下屬此企業屬於小批量多品種生產，業務單據變更猶如波詭雲譎，業務需求方顯然無法接受人工大量干預，IT團隊面臨技術與人員配備困惑。

誠然，與會人士眾多，都各懷己見。又到了團隊頭腦風暴的時刻，此時此刻的你心所向為何？在我們集各種方案思考、各抒己見後覺得這無論是我方、還是WMS、MES供方，甚至試圖溝通的第三方都是一條難以逾越的鴻溝。想必每逢此景的IT團隊，心裡都有一杆秤衡量它：理想中的介面互動應是各大軟體整合商聲聲念念的無縫整合、即時互動、握手驗證等等。因為這個概念目標在於降低運營成本、降低維護成本，縮短溝通時間、提高服務效率，提供歷史記錄。
那麼問題來了，怎樣才能實現它？
誰來實現，是供方、第三方、還是作為“消防員”的我方？
凡事謀定而後動，知止而有得，從管理維度怎麼構建平臺？
懷著不矜不伐、敏而好學的端正態度我們不難發現有很多概念已被提出：
EAI（Enterprise Application Integration，企業應用整合）：介面整合、業務過程整合、應用整合、資料整合、平臺整合五大型別。
ESB（Enterprise Service Bus），企業服務匯流排，面向服務的體系結構已經逐漸成為IT整合的主流技術。面向服務的體系結構(service-oriented architecture，SOA)是一種軟體系統設計方法，通過已經發布的和可發現的介面為終端使用者應用程式或其它服務提供服務。
就像歌詞寫的：我跌跌撞撞奔向你，你也不能一個人離去，我們在一起說過，無論如何一起經歷風雨。前方高能已經指明方向，我等將勢必跟隨。當然這次崇拜式的追隨，熱情與念頭也就如後面歌詞：平平淡淡安安靜靜的死去。
當我們對上述系統進一步研究後得出它的重大功能：轉換和整合。轉換是指轉換協議和訊息格式，整合是指將原子服務按照要求有規律的進行串接。詢過專業上述整合廠家，最後得出的結論：系統太過昂貴(免費開源的Mule ESB也二次開發、應用過，坑太多，執行不穩定，或者認定為技術要求太高，非一般人玩得轉。)用它同樣需要大量繁瑣的開發工作才能幫助他們實現互聯互通，且要求頗高太過陳舊，已難適應輕量、快速響應、開發難度高、冗餘的配置功能變得非常不靈活。
作為IT決策者你是否會考慮到雖前期轉嫁了風險、卻低估甚至忽略了後續的運維及管理？你是否有魄力重金之下，求勇夫？

<章二>初嘗篇

上篇困惑每逢回想起至今尤寒，雖前路不明，也定要披荊斬棘，誰讓你擔當這現代化建設者，誰讓你履行“消防員”的責任。

自然，我們拋棄了供方提供的方案3.人工處理的方式，理由也非常充分：資料量、單據量大，操作完一個系統需配備一定素質的人繼續另外系統的操作，效率低下，出錯率最高，且並非所願，雖然大企業大批量可以這樣玩，即便你玩得很開心，不乏人力，但是不low嗎？很low，妥妥的，且以後的自動化述求何時能實現？不積跬步,無以至千里.不積小流,無以成江海。

方案1，我們將把需求的實現轉嫁給ERP或WMS、MES廠家或者第三方，需評估以下方面:
1> 需求制定、開發、測試周期；
2> 沒有介面的ERP的開發模式決定了難度，比如單據外掛開發模式需要考慮單據量(功能考慮不周將導致週期與預算大大超出)，又比如按鈕事件開發模式需要評估和制定操作功能標準(在世的眾多ERP都面臨單據有按鈕操作，列表有操作，其他單據也能後端操作等等)；
3> 二次開發帶來的升級、遷移弊端(如果開發帶來嚴重影響升級或者升級包執行後二開失效請謹慎再謹慎，”消防員”寧赴死卻承擔不了靈魂的拷問啊。)。
4> 當然就是成本與維護的考慮了，初次預算下來起碼需交付幾十萬，雖風險已轉嫁，但維護、優化卻受制於人，且重用性基本為零，更談不上管理，IT決策者請試想怎麼有效的管理及運維它，付出與得到差距甚遠。

方案2，在此基礎上，我們第一次最終無奈選擇了它，確實無奈、請恕在下無能。此次整合部分全部由內部團隊對ERP各個資料表以及關聯表附寫定時排程查詢功能，以時間戳記錄為篩選依據，進行了浩浩蕩蕩的資料轉移到中間表。回寫部分梳理了業務關聯性，從少量資料傳回前提下，去抓取上下游關係資料，回寫ERP業務資料表。為時一月有餘，戰戰兢兢地上陣。

此處談談為什麼建議慎用觸發器：主要原因是合理的觸發器編寫對設計者和編寫者的要求很高，必須比較全面的分析相關業務，同時全面瞭解觸發器工作原理。也就是說寫出的觸發器要求在業務上考慮全面，在技術上作到最好，才能不影響業務和效能。觸發器也確實不容易被注意，給後期維護帶來困難。同時業務往往需要考慮觸發器的掛載，例如單據存在子表、孫表的時候需要驗證業務系統事務處理的機制以及是否在事務中，否則資料不完整，邏輯不完善都會帶來嚴重的後果，同時對效能和開銷都要有一定的考慮，更有系統廠商鑑於觸發器造成的資料混亂會告誡不在維護之列。

當後來我們還沉浸在完工的喜悅時，自覺得會不斷的修復bug來完善此方案，現實的打擊接憧而至：
1> 業務從開始1小時定時排程不滿逐步轉成30分鐘定時、5分鐘定時、1分鐘定時甚至更甚，因為理由確實充分，生產在等資料才能操作。此時發現了越來越多的資料紊亂，天生的時序已經出現了各種問題，雖不斷修復，但我們已經痛苦不迭，每日埋沒在修改資料的事務之中，業務抱怨紛繁踏至；
2> 資料雖然在傳輸，但是業務之間始終沒有相互制約，舉個例子ERP採購訂單下發後，A料採購數量100PCS，WMS供應商已經釋放條碼，包裝，甚至送貨途中，ERP因特殊原因變更了採購數量為80PCS，WMS何其無辜的說了聲，你叫我修改的，好，那麼修改後多餘的20PCS後續會出現怎麼對待的問題，此時WMS彌補性的再發聲，我加一個校驗返回到中間表不能修改，ERP再定時去抓取禁止ERP修改，長此以往，資料穿插互動猶如蛛網，IT每日都在頭暈之中，誰來為這現實埋單？是制定標準用管理來約束？還是配備人員在不斷的查證糾錯修改工作中辛勤耕作？答案往往都很難具備說服力，限制功能往往帶來更復雜的操作才能撤銷和彌補，大量的維護也將得不償失，效率低下。
可想而知在這一年多裡，心有所絆，卻非念想，何其無奈。IT外出團建都帶著電腦，產線加班都有IT默默在陪伴。如果幸運的你在幾班倒的企業，是決定做你的男人24小時不睡覺待命還是翻牌伺寢，當然也不乏樂在其中的人兒，想想興許還有點其他福利，或者自覺得不可或缺。
就像夾在和田籽料裡面的水石，雖外表一樣光滑亮麗，但它終不是來自崑崙經山流水千萬年歲月的沉澱，結果可想而知。

<章三>求索篇

長此以往，IT雖勞苦，但收效甚微，很能理解給業務帶來的工作困難與無奈，於是團隊決策者開始靜下來著手解決之道，箇中不斷尋求系統廠商助力，但似乎都已成世紀難題。從尋求專業的系統整合解決商，例如ESB、資料中臺等等，尋而往來，卻不得解，路漫漫其修遠兮，吾將上下而求索！
知己所需還應知彼長短。初心未變，變的是歲月，此情此景我想聊聊我們對服務互動探索的淺見：
人工處理實現：人工傳遞、手工錄入，不限於兩邊系統對照、郵件等溝通後人工在各自系統中錄入、匯入、修改等方式；大量及重複的操作、查詢溝通才能處理，雖適合大批量，少單據、少變化的企業。但終不是正確之道。短期方案可備選。
中間庫模式：各自系統實現邏輯傳遞到中間庫，同時相關資訊各自獲取進行後續處理；難以完成時序、邏輯校驗，優勢在於邊界清晰，錯誤定位責任清晰；但資料複雜，查詢問題困難，處理問題往往需要在紛繁的事務中不斷摸索、優化。此模式目前為90%左右實施方標準方案，為啥？管殺不管埋，保證雙方責任邊界清晰，同時有記錄，專案得以必要保障。
排程模式：適用於雙方系統提供查詢、回寫介面，需求方定時獲取資料及變化來更新目的庫資料，同樣需要在時間段內去對比資訊，事務處理非常困難，同樣難以承載時序、邏輯校驗。
資料庫觸發器開發模式：適用於簡單基礎資料類對接(無邏輯處理)，其他業務要求考慮全面，在技術上作到最好，才能不影響業務和效能。觸發器也確實不容易被注意，給後期維護帶來困難。同時業務往往需要考慮觸發器的掛載和事務處理。此方法目前大量被乙方實施公司採用，主要原因為實現快，邏輯相對於簡單，它不用考慮操作端侷限，只監聽資料庫對應的變化。作為甲方我們應該嚴格抵制它，這種不完善的方案終將如深埋的雷，往往帶來的風險、後果會超出你的想象。慎用之更應禁用之。
程式碼開發模式：適用於定向開發，優勢明顯在於可靠實現清晰的業務流程，資料互動，握手校驗，劣勢也非常明顯，在於開發很多不瞭解業務，業務很多講不清需求，理解不了開發架構。在企業業務變化為不變的真理時，往往會大量投入資源來應對，同時週期及交付難以把控，常常會牽涉多方溝通、管理接入、調整難，維護更難的局面，管理者應重視管理、運維、系統遷移、改造、程式碼管理等等情形。同時應考慮怎麼合理分配資源，協調資源可靠、快速完成以及人員培養定位、團隊建設。
平臺模式：要實現系統的整合，底層的結構、軟體、硬體以及異構網路的特殊需求都必須得到整合。平臺整合處理一些過程和工具，以保證這些系統進行快速安全的通訊。平臺兼備管理、運維、訊息等機制。

通過對比分析、取長補短，毋容置疑，平臺模式為我們奮鬥的目標，選擇的根本，不難發現我們需要的平臺功能它應該具備:
必須建立一套完善的系統來管理所有資料傳輸，並能夠快速擴充套件以響應客戶變化的需求，滿足應用程式可用性和使用者數目的增加。
需要正視網路非可靠傳輸的因素，應建立端、或者類似閘道器的機制，可本地部署、雲部署或者混合部署解決安全可靠、跨域的問題，實時系統監控,自動警報。
輕量、高效、標準不失靈活的平臺功能，具備服務治理管理、更新管理、應具備核心的轉換和整合開發功能，同時提供視覺化、快速實現、運維的需求。
應杜絕大量繁瑣的工作才能實現互聯互通，建立服務生態系統，服務開放即可重用，系統遷移或新上時，更多傾向考慮本身API的功能即可互動。
應具備清晰的資料記錄、結果記錄、應對系統業務不可重現時平臺需支援資料互動的傳遞及運維，同時應具備完整的操作日誌、執行日誌、訊息機制的推送等。
應具備完整的安全機制、加密機制，身份驗證，授權和訪問，通用的訪問管理解決方案整合相容，多種認證機制，標準和令牌型別等

平臺開發啟動同時啟動了ERP的介面開發：此次開發監管ERP資料底層，在ERP本身功能及API上進行二次開發封裝，實現了ERP觸發時機、對接資料、單據流關聯等視覺化配置操作，例如標準採購(訂單)指定組織，
由開立→稽核觸發非同步模式新增服務到WMS系統中，
由稽核→稽核觸發變更修改服務，同步模式校驗WMS資料，校驗成功允許修改，否則彈窗報錯不允許修改，事務回滾。
由稽核→開立觸發刪除服務同步模式校驗WMS資料，校驗成功允許刪除，否則彈窗報錯不允許刪除，事務回滾。
同時啟動了WMS、MES介面開發與封裝；

接著我們將此子公司的介面全部進行測試、遷移、優化，將近三個月，發現業務互動事件化，清晰透明，追溯查詢方便；在後面幾個分子公司的系統上線時，介面配置，上線僅僅只用了一個星期。從以往的開發多方溝通實現，轉變為由實施人員根據業務自主配置實體觸發、手工批量觸發等方式來完成及交換。上線後異常服務提示對應人員，分析查詢問題變得非常容易，資料不再是底層不可見的互動。同時對平臺實現自動分發，即時互動，服務上傳即生效，設計節點接收、傳輸資料，大大降低當機、網路傳輸帶來的資料丟失。支援同步模式:系統間需要握手互動驗證；非同步無序：負責資料傳輸、無序系統間校驗，效率最高；非同步有序：資料包執行需考慮先後順序執行。

<章四>感想篇

經過幾年的求知之路，更加堅定了設想的初衷，所謂正確的選擇，更多的是認準了思路。雖然專案是短期的經營活動、資源的分配利用、以及成果的交付，但作為資訊化的支撐團隊，我們更應像掌舵者，雖然路途漫長，過程艱辛。但苦中帶甘。更加覺得企業應自身強大起來，成為資訊化自主的實現者、管理者、決策者、運維者以及引路人。是以分享經歷，學知識，傳遞己見，贈人玫瑰，手留餘香。在這個我認為的平行世界裡，也許存在眾多的同道者、困惑者，還望不吝賜教，相互學習。再次感謝撥冗翻閱拙文，如若不棄，可互友把酒桑麻。