上篇困惑每逢回想起至今尤寒，雖前路不明，也定要披荊斬棘，誰讓你擔當這現代化建設者，誰讓你履行“消防員”的責任。
自然，我們拋棄了供方提供的方案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小時不睡覺待命還是翻牌伺寢，當然也不乏樂在其中的人兒，想想興許還有點其他福利，或者自覺得不可或缺。
就像夾在和田籽料里面的水石，雖外表一樣光滑亮麗，但它終不是來自昆侖經山流水千萬年歲月的沉淀，結果可想而知。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/169989.html
標籤：企業信息化