本人本身是一個碼農，已經服務了共和國各項事業(好像是說得有點漂，沒辦法段子看多了)大約一半工作時候了（按60歲退休的話），從一線的小碼農，到現在成了老農，出產了不少或優或劣的各種碼，幾乎啥都做過。近幾年慢慢沉澱到製造業信息化方面，主要是APS在生產計劃方面的應用，APS - Advance Planning and Scheduling. 高級計劃與排程；其實也就是做計劃，只不過使用了一些優化算法，另計劃的質量更高一些。從最開始被調去做ERP數據適配APS項目實施，到現在自己在爲公司開發排產引擎（當然規劃引擎用的是開源的，我可不是數學方面的專家）。從中也接觸過不少排程產品，掉過不少坑，身上算是留下了點APS的戰鬥痕跡吧。下面先講一下我在這方面的一些看法。等我有時間了，我再把這一年來，爲解決APS系統的引擎問題使用optaplanner規劃引擎的一些小積累分享一下，但這個時間嘛，還真的不容易擠呀，這一年來基本上每天晚上9點30前沒離開過辦公室，11點後跟晚班工人一起下班是常事（沒錯，我在一個製造企業上班，對APS有一個天然的實戰環境，這是公司給我的最大條件優勢）。
1. 排產的現狀
關於製造業排產的系統，目前人們關注得更多的是MPS（主生產計劃系統）的排期，即是公司甚至整個集團層面，根據產品的產工藝參數，結合訂單的數量與交期要求，生成以生產訂單爲基本單位的生產計劃，通常稱作主生產計劃（Master Planning).所謂的排期，或稱排計劃，更多的是對這些生產工單進行編排。例如根據這些工單的工藝要求分配到不同的生產單位（分廠、車間或承包商），並根據各個工序的生產時間需求，定出一個要求的完成日期，而這個日期其實是有水份的（下面會有解釋）。但這些工單去到具體的生產單位後（特別是公司自己的車間作爲生產單位時），其具體的生產計劃就較少涉及了。原因有二.
a. 複雜度與可變性太高。到了車間這一層，再下一層就是產線甚至機臺了，即車間的生產控制部門獲得上級下發來的生產要求之後，會結合在製品、資源與工單的具體要求，向上級單作出一個反饋，即回覆是否可按計劃的要求完，雙方討價還價確定了一個新的計劃版本之後，車間生產控制部門就會制定一個適合本車間的生產計劃，再把該計劃下發給生產調度部門進行生產。生產調度部門再會根據具體情況，按生產計劃進行生產。無論是車間生產計劃部門，還是調度部門，他們面臨的都是一些涉及一些非常複雜的細節規則，例如生產工單的工藝要求，投放到車間哪個產線，例如哪種甚至哪臺機器進行生產，生產過程中需要注意的具體細節等。都需要生產計劃部門有所考慮，當然到了調度部門有可能還會有一些更細節的實際情況及約束進行考慮，從而在生產過程中作出臨時調整。無論是車間的生產計劃部門還是生產調度部門，需要處理的邏輯細節都是很複雜繁多的。而作爲人類面對種類繁多，複雜且多變的規則，各種業務制約與各種要求，是無法滴水不漏地顧及的。更多的是通過經驗積累給出一些大概的，基於估量的安排。所以，車間各級部門給出的這個計劃其不確定性是非常高的，甚至有些情況下，在經驗老道的生產計劃人員及調度人員排出來的生產計劃，如果有足夠多的時候去推敲，即使是按目前的生產情況不變，到最後也是不可行，或者說計劃的質量要求（例如對成本、交期、產能利用率等要求）是非常低的。但往往在制定出來的初始階段基本上是沒人能推斷出來的，更不用說計劃推動了一段時間後，隨着過程中的各種條件變更發生，越往後就越偏離原來的初充了。所以，要能最大程度上做出一個好的計劃，是非常困難的，更多的是以經驗生成一個初始計劃，在生產過程中根據實際出現的情況，及在初始階段未能考慮的問題慢慢明確，再持續地作出調整。所以給別人的印象就是，車間的生產計劃毫無章法，質量太差，甚至有公司高層認爲，車間根本無計劃可言。但這是人思維的侷限性，而對遠超過其處理能力問題時，必然會出來的情況。因此車間層面的生產計劃會面臨一個嚴重的複雜度與可變性太高的問題。
b. 車間生產計劃被視作操作細節，被人爲未達到戰略層次，未得到足夠的重視與認識。因爲作爲公司級別的主生產計劃，它是直接作爲公司供應鏈的一環而存在的，這個環節的目標達成率高低是需要下面各個更細層次生產計劃的支持的。但作爲公司層面，往往要求的是，只要公司的主生產計劃保持在一定的達成率，那麼就可以滿足供應鏈其它環境的要求了。但事實上這個達成率是需要有冗餘的，也就是主生產計劃給制定車間生產計劃的時間，已經預計到一定的不可確定性存在，因此往往會留下一定的緩衝期。但這個緩衝期長短，是否合理，往往都是通過以往經驗得出。而同樣道理整個供應鏈對主生產計劃也會留有緩衝期，那麼可以想像，爲了能滿足要求，往往這些緩衝期加起來就會很長，往往比實際執行製造生產的CT還要長。這樣就會造成極大的效率低下，及產能資源浪費。但就是因爲越往明細的生產計劃，不可控、不確定性越大。因此，公司通常都只能夠棄小保大。久而久之，大家的焦點都只關注在MPS的層面上了。
綜上所述，目前我們所說的排產，或說生產計劃，更多的還只是停留在主生產計劃這個層次較高，較虛泛的範疇。而真真正正到了生產控制層次的，往往關注的是MES（生產執行系統）了，而計劃因爲車間、產線層面的生產調度計劃存在太多的難點，及很多方面技術上尚未成熟，令各大企業信息化產品對此較小涉及。大家也會留意到，無論多大、多出名的ERP系統，它關注的都是公司供應鏈層面的資源調配，而不會涉及具體生產環境，或者具體到庫存物流，或具體的訂單執行層面的內容。而目前這方面通常引入APS作爲支撐慢慢有些成功可用的方案在市場上推廣了。
下面就來看看APS(Advance Planning and Scheduling - 高級計劃與排程)技術，在生產製造業的一些應用.
2. 什麼是APS.
上面說了，APS就是一種高級計劃與排程技術，那麼爲什麼叫做高級呢？我的理解是，它是相對於以往的MPS的，它除了滿足一些生產製造過程中關於工藝、交期等等的硬性要求，還要在滿足這此硬性要求的基礎上，根據既定的一些設定、或稱策略進行不斷優化，從而得出最接近策略目標的計劃方案。這樣說可能比較虛，下面舉個例子說明一下。一個主生產計劃下發到車間，當前正處於工廠的和產旺季，那麼生產策略通常會被整理爲"保證交期"（可能談季的時候，因爲資源相對充足，交期的保證不再是難事，策略往往會是"降低成本"。），那麼車間生產計劃部門收到計劃，細分爲各車間、產線甚至機臺的計生計劃時，就會把生產計劃的策略大體上區分爲兩種，一種是保證硬性的要求不違反，例如產品質量要求、生產安全要求等。在此基礎上，就會設法安排這些生產訂，令其可以更快完成生產，從而可以保證產品所在訂單的交期，又可以爲後面更多的生產單儘早騰出資源，目標就是提高效率。對於前面的質量、安全的要求，是一些硬性的定性要求；而對於第二種效率的要求，是一種軟性的定量要求。對於定性的要求，那麼就會有好壞，或說能達到多好的程度評價。在人的角度上來講，經驗越豐富，他排出來的計劃效率越高，越符合這個軟性要求。這個就是APS的威力所在的，當然大家關注人工智能中的深度學習的信息，可能會發現，這個有一點人工智能的味道，確實是的，但目前還沒有聽說過這方面的研究。APS技術目前使用的還不是人工智能，而是基於有限資源、固定條件約束下的最優方案分搜尋技術。它的原理就如上面的例子，會把人們對計劃的要求劃會爲硬性約束與軟性約束。通過尋優算法（禁忌搜索、遺傳算法、模擬退火等）在浩瀚的組合方案中，在有限的時間內,找出的方案，需要在滿足硬性要求的前提下，最大程度上滿足軟性要求的方案。尋找這些方案的一些原理、算法，就涉及一些數學上的概念，例如NC問題，NPC問題等，在此就不再熬述了。如果有機會我另寫一些相關的文章講解一下。
總而言之，APS就是通過一些數學算法，在計算機的強大運算能力支持下，找出一些可能比人類排產老師傅更佳的生產調度計劃。\
3. APS的適用場景.
正如上面提到，現在製造業更多的關注於主生產計劃，而具體明細的車間產線層面的生產計劃、調度計劃，還是處於放養式的存在。而主生產計劃由於有足夠的關注，往往有更多的投入對其進行研究，而且它面對的問題更宏觀；綜合來講，相對車間層面的生產調度計劃就沒那麼多繁雜的制約因素了。所以，目前市上各種APS產品和技術，主要還是針對車間、產線甚至機臺的生產調度計劃，希望在這個層面的生產計劃有一些開創性的成果。但其實我們可以想象，APS可以處理車間、產線層面的生產計劃，那麼面對制約因素少得多，或寬鬆得多的主生產計劃，是完全卓卓有餘的。所以，雖然各大商家都把自己的APS產品瞄準車間、產線層面的生產計劃，其實如果在主生產計劃上面所需求，它也是可以對現有的主生產計劃作出些非常大的改善的。因爲儘管主生產計劃比較宏觀，但還是由公司計劃部門的人來制定的，那麼就必然有一定的侷限性。例如上面提到的計劃質量、緩衝期是否合理等等，APS在這方面可以作出很大的提升。當然，把APS應用於主生產計劃，其實還是需要下面層面的車間、產線生產計劃的支持的，畢竟在主生產計劃中，對各種資源與時間的預判，都要由車間、產線層面的生產計劃進行實現。而不是毫無根據地猜一個資源可用量，或完成時間的。
當然，目前在製造業裏面臨的最大問題還是車間、產線面層的生產調度計劃，目前各個APS產品與技術，都是號稱可以解決這類問題，都是衝着車間、產線這個層面去的。所以目前見得最多的APS適用場面，還是在車間、產線甚至機臺層面，針對已分配的工單，對各個車間、產線甚至機臺，在已有的可用資源條件下，基於具體的業務制約因素，將生產任務適當分配到合理的生產單位（車間、產線甚至機臺，工位），並根據計劃中各任務的關後關聯關係，確定每個生產任務的具體開始與結束時間。這個也是APS的核心價值所在。因爲目前在車間調度工作中，對於資源的把控也許會相對準確一些，畢竟有條件的工廠，在自身產能不足，但訂單要求有硬性規定的時候，可以通過引入外發加工來解決資源不足的問題。而生產時間的安排就沒那麼容易了。因爲這是一個運算量非常大，考慮各種綜合因素，考慮工序的前後關係，還要考慮工廠實現的班次等因素，綜合起來的計算結果。人類是無法快速運算、畢竟種個方案的。這樣的話，APS系統就可以基於自己內核所使用的各種最優解搜尋算法，基於各種約束；再利用計算的高速運算，快速地計算出各個方案的優劣，從而在短時間內對海量組合方案進行計算對比，從而往往能找出比人類更優的生產調度計劃，甚至是對於生產任務的開始結束時間，甚至是精確到分鐘的。因此，針對人類這方面的不足，通過大運算量，去生成的生產調度計劃，是目前APS的主要應用場景。
4. APS產品及引擎的選用
目前世界上可用的APS產品其實還是不多的，畢竟這是一個數學上都還在不斷探索的問題，目前APS產品或技術，主要有偏重於MRP方面的，例如英國FastRact, 還有一些是結合規劃引擎與實際排程經驗的產例如日本的Asprova. 還有國內也有一些新秀產品，而這些接觸不多。另外還有一種不算是產品，而是基於一些規劃引擎，結合企業自身的業務場景，自身以項目形式開發的APS系統。目前我所在的企業正是處於這種APS發展狀態。我們是基於Optaplanner + Drools作爲規劃與規則核心引擎，結合自身業務規則，將業務場景中的各類實體抽象，並將呼類繁多的業務規則抽象總結翻譯爲硬約束與軟件約束。再通過程序使用Optaplanner中的適當模式進行生產計劃的自動生成。目前我接觸過Asprova與Fastract(這個只是接觸過他們的顧問提供的信息，不沒有進行過項目實施).覺得Asprova確定是相對比較成熟的產品，雖然它的技術已經非常老舊，但基核心價值是引擎可以根據實際的排產經驗作出運算優化。如果覺得自己公司的業務相對比較複雜、奇葩，且自己公司具有一定的技術開發實力，建議還是使用Optaplanner進行定製吧。但還是要注意，在作技術選型時，還要充分了解自己業務上的情況，例如排產規則，自己業務跟各個引擎常用的模式有多大差異。這樣才能選擇一個真正適用的產品或技術。
上述都是自己這些年在APS上遇到各種坑後的總結，不一定對，歡迎大家拍磚。
謝謝。
End.
如果對此大家有何建議，歡迎大家加我企鵝一起探討：12977379或V信：13631823503。
其實 Optaplanner規劃引擎不需要對Java過份精通即可使用,因爲它使用到的都是Java最基本的知道，但還是需要有基本的Java知識才行，希望大家找我研究討論時，如果Java, Maven等方面仍接觸較少，請大家先行自補該方面的知識，本猿暫時只能跟大家探討Optaplanner, Drools的應用，而Java相關的知識，恕無法提供有效的幫助，畢竟本猿也只是個Java新手。先謝了。
另外，若對此文(或本系列任何內容)感興趣，歡迎轉載，但請尊重艱辛勞動，註明出處。爲謝！