普通企業的規劃類項目中，OptaPlanner更適合做爲APS的規劃優化引擎

在企業的規劃、優化場景中，均須要開發規劃類的項目，實現從各類可能方案中找出相對最優方案。如排班、生產計劃（包括高層次的供應鏈優化，到細粒度的車間甚至機臺做業指令）、車輛調度等。由於這類場景須要解決的問題，都可以歸約爲數學中的NP-C或NP-Hard問題。而解決此類問題，均須要通用的求解器才能實現。這類求解器也稱規劃引擎，經過它才能從天文數字的可能方案中，找出一個可行且相對優化的方案。

規劃引擎的本質，是運用規劃中的各類優化算法（目前用得比較多的是啓發式算法），對一個NPC或NP-Hard 問題尋找最優解的過程。面對不一樣的問題、場景，會衍生出各類各樣的運籌優化變種。但事實上這些問題均可以視做數學規劃問題，可以使用運籌學中的對應方法來處理。例如生產計劃的排程，車輛路線規劃與實時調度，工單的劃分和開料問題等，均可以經過數學規劃並優化。而求解器則提供了各類優化算法的軟件，用於求解這類問題，也被稱爲規劃引擎。

使用約束求解器實現求解，其中關鍵的步驟是問題進行建模。建模過程實際上是把業務場景中的參數、變量、規則和優化目標等要素，轉化成可被規劃引擎識別，並運算的優化模型。在常見的商用求解器中，這些問題均須要被建模成數學模型，用數學語言來表達從業務流程中提練出來的業務規則與要求。求解器對數學模型求解，尋找並輸出模型的最優解。客戶端的程序再將最優解（即最優方案）轉化成業務方案再，並傳遞給其它企業使用系統（例如ERP， MES等）。

目前市場上求解品的概況

商用求解器

當前市場上成熟的求解器並很少，且都被國外企業壟斷並且價格昂貴，如Cplex, Gurobi等。這些都是目前世界上頂級的求解器，已發展多年；不管是性能與通用性上，都是首屈一指的水平。其次，這些產品一般也會開放學術版本，只要提供符合要求的學術單位證實材料，便可得到學術版本，學術版一般是無償使用的，但僅限於學習、科研使用。商用場景則須要付費得到使用受權；所以，這類求解器很受運籌學領域的學術界歡迎。由於這些有運籌學或應用數學背景的高級人才，在學習、研究階段已對這些求解器有必定應用基礎，當他們畢業後從事相關領域工做時，這些他們熟悉的商用軟件也相應地更有優點，更容易佔領市場。

固然，依託大量資源的投入和長時間的技術積累和改進，商用求解器在性能、穩定性及售後支持方面佔有絕對優點。但事物必然存在兩面性，商用求解器也有它的不足之處。除了它的價格相對昂貴外，其實在某些條件下，仍是存在必定使用上的劣勢，下文詳述。

開源求解器

開源求解器數量相對商用求解器更少，緣由衆多。優化核心的技術門檻，資源投入是主要因素。畢竟求解器所用到的優化算法，在學術上仍有很多改善空間，更不用說將技術理論實踐到求解器中了。此外，開源技術主要依靠開源社區，或某些公司資助的團隊負責開發與維護，與IBM等巨頭可投入的資金與資源是比，有天壤之別的。所以，這方面的開源產品很少，開源的成熟產品更是少之又少。而目前較成熟的開源求解器，目前只有兩個，一個是OptaPlanner, JBoss開源社區維護，主要由受僱於Red Hat的團隊負責開發與更新。另外一個是Google的OR-Tools, 由Google發佈並維護；主要維護團隊也是由Google資助。上述兩個開源求解器都基於Apache License 2.0開源軟件協助，對商用友好，且無開源傳導性。對使用過它的系統並無開源要求，僅需做出開源引用聲明便可。

規劃類項目(如APS項目）的設計開發過程

傳統的商用規劃引擎，一般直接面向數學優化問題，須要提供直接的數學模型，才能進行求解優化。所以，使用這類求解器，須要具體必定的數學功底，在業務模型的基礎上設計數學模型。具體過程是:

業務分析與抽象

規劃類項目（以APS項目爲例），首先要對業務場景進行分析。從業務流程中獲取並概括業務實體、規則與優化目標。該工做的主要目的是對業務進行抽象、提練和業務模型設計。識別出業務實體，各個業務案例中有哪此約束，找出當前須要優化的要求。例如：生產計劃中，結合訂單與工藝信息，定義工單或生產任務。車輛路線規劃場景中，根據車輛參數、運送物料的特性與要求等信息，識別出線路要求，走訪節點順序，最大運載量，節點走訪時間限制等特性。在真實項目場景中，這些工做應該由經驗豐富的APS顧問和業務顧問來完成。APS顧問應該從兩個方面掌握這些抽象技巧。其一，必須掌握業務場景中的流程、規則和要求；必須識別出真實的規則，有哪些規則是同義且可合併的，有哪些規則是相沖的；並在此基礎上做出最大可能的簡化。其二，必須具有豐富的分析與抽象經驗，掌握各類業務場景下的規則與要求，知道各類業務案例與要求，應該如何概括成APS系統中的業務實體，規則約束和優化目標。

數學模型創建

完成了業務建模（即識別出業務實體，規則和優化目標）後，下一步則須要對這些業務模型轉化成數學模型。由於常見的求解器（即規劃引擎）其求解過程，實際上是對數學模型最優解的尋找過程。各類優化規則與目標，須要經過各種參數與數學表達式來描述。對於有運籌或應用數學背景的研究人員，且經歷過必定的數學建模實踐訓練後，這些工做並不困難。但咱們常見的普通企業裏，這類人才相對缺少。一般狀況下只能與高校、科研單位合做，才能獲取此類人才資源。所以，數學模型這一步，也是普通企業難以解決的一步。而OptaPlanner規劃引擎正好爲咱們省去這一步，只需完成業務分析、概括，創建業務模型，便可做爲引擎的輸入進行求解。

求解

求解過程就是規劃引擎對輸入的模型+數據，在約定的規則範圍內，在有限的求解時間內，經過各種優化算法，尋找相對最優解的過程。不管是常見的商業求解器，仍是開源求解器，該過程都比較相似。但不一樣的求解器在不一樣的領域，求解的性能有較大的區別。有的面對大模型問題較有優點，有的則面對規則密集的場景能獲取更佳質量。各求解器的具體特性，能夠參照一些相關的評測文章。

OptaPlanner的求解特色

在求解過程當中，OptaPlanner與其它求解器有所區別。由於OptaPlanner無需直接輸入數學模型，僅須要經過Java+Drools表達的業務模型便可表達優化模型（將來的發展方向，將會側重脫離Drools，直接經過Java便可表達豐富的約束，但目前的條件下，與Drools結合應用的方式並不會拋棄）。所以，在OptaPlanner求解過程的初始階段，會有一個從業務模型到數學模型的轉化過程，也就是把業務模型轉化爲規劃核心程序可識別的數學模型，例如對於用Drools腳本表達的約束與優化目標（硬約束和軟約束），編譯成Java函數。而這些編譯後的函數，能夠反映出相應的數學模型。即OptaPlanner幫咱們實現了從業務模型到數學模型的轉化工做。

普通企業規劃類項目限制與求解器使用

在普通企業（相對於各種資源豐富的央企或各種Top500企業）的IT部門，或較小型的軟件公司；各級設計、開發人員，每每不具有深厚的數學建模能力，或有這方面背景的技術人員，但相關的優化項目實踐經驗也相對缺少。由於，就算其中有部分人員在校時是研讀相關專業，但若這類人員畢業後並無持續這方面的工做，未能積累至關的規劃方面項目經驗，在面對零散、複雜的業務實體、約束與目標時，也很難將這些場景很好地建模成數學規劃模型。所以，從業務模型到數學模型的轉換，成了普通企業在進行規劃類項目的最大門檻。

OptaPlanner在普通企業的規劃類項目中可發揮的優點與限制

因應普通企業的人才資源限制，一個能夠省卻業務模型到數學模型轉換的求解器，可讓規劃類項目門檻下降很多。OptaPlanner則是這樣的一個求解器。OptaPlanner能夠經過Java的POJO來完整地表達業務實體；經過Drools腳本，或Java函數，或Java8以上的stream特性來表達約束和優化目標。所以，企業中的IT設計與開發人員，只需掌握這方面的技術，便可完成從業務模型到求解過程的過程，無經歷困難的數學建模過程。由於，上述提到的OptaPlanner業務模型表達技術，都是一些與程序設計相關的技術，在以程序設計人才爲主的普通企業中，這方面人才並不缺少，掌握這方面的技術也不算很是困難。

但OptaPlanner也有必定的難點，主要表如今兩方面的學習成本上，存在如下兩個方面的成本：

Drools規則引擎的學習成本

在OptaPlanner目前主流的約束表達體系中，Drools仍然是不可或缺的，且是主流的技術。Drools是一個開源的規則引擎（注意：Drools是規則引擎，OptaPlanner是規劃引擎，它們同屬於開源項目KIE），它具備本身的語法、語義和表達方式。在OptaPlanner中，它是起到規則判斷做用。但這種規則引擎在普通企業中，使用並很少。所以，對於IT設計、開發人來講，須要掌握Drools也須要必定的學習成本。但根據OptaPlanner項目的發展趨勢力來看，將來將會擺脫對Drools的依賴。其實如今也能夠徹底擺脫Drools，而徹底使用Java來實現規則與約束的表達。但當前的版本特性下，不少場景下可表達的豐富性和靈活性，徹底的Java語言仍是難與Drools匹敵。而從最近的OptaPlanner數個版本發佈的內容來看，未來會加大對Java8及以上版本的stream特性的支持。目前已經發布了一些基於stream的評分API，稍後有時候我將會寫一篇這方面的文章。

求解的評價體系學習成本

OptaPlanner只須要使用者關注他們熟悉的業務，並對這些業務創建好相關的業務模型，便可實現規劃求解。可是不管你是使用Drools，仍是Java語言做爲評分邏輯的實現方式，都須要掌握其評分體系，它是與表達方式無關的，在設計規劃實體和約束時候的一種方法論。簡而言之，OptaPlanner把數學規劃模型中的限制條件，即s.t.,也即subject to.以及目標函數都經過約束來表達。suject to在OptaPlanner中可視做硬約束, 目標函數則對應於OptaPlanner中的軟約。那麼從業務上識別出哪些是硬性約束，哪些是優化目標後，應該如何經過約束實現不一樣的規則與優化目標，則須要對OptaPlanner中的評分體系有必定的理解，不然會較容易超出OptaPlanner的一些設計限制，引導各類異常，從而影響優化質量和結果的準確性。或所設計的評分規則沒法真切地表達業務本意。本人在使用OptaPlanner過程當中，總結了數種典型和異常狀況，或約束表現正常，但並未能表達業務規則惟一性的狀況；並分析了其中緣由，之後有機會，我將會着重分享這些狀況，詳細論述各類異常，約束歧義和相應的規避原則。

不管如何，雖然OptaPlanner不須要咱們把業務模型轉化成數學模型，但能準確把業務模型中的各個實體、約束和優化目標轉化成Java實體，約束表達腳本，仍是須要必定的學習成本的。但這種能力的學習與實踐，普通的IT軟件設計人員便可掌握，而不須要具有應用數學或運籌學相關的學術人才。

總結

儘管OptaPlanner也有本身的學習成本，但在普通企業中，這此學習成本仍是比培訓數學建模相對更容易些，畢竟對人員的要求更低。畢竟使用OptaPlanner咱們面對的都是一些軟件設計的問題，這對於有豐富經驗的軟件開發人員，並非不可逾越的鴻溝。但使用基於數學規劃模型的求解器，則須要必定的應用數學背景和相關的數學知識和能力，且須要通過必定的數學建模實踐訓練，達到必定水平後，能才保證建模質量。不管是入門仍是深刻，後者對一普通企業來講，確實是更爲困難。所以，我認爲有規劃方面項目的普通公司，仍是優先使用OptaPlanner做爲規劃引擎更可行。

本系列文章在公衆號不定時連載，請關注公衆號（讓APS成爲可能）及時接收,二維碼：

如需瞭解更多關於Optaplanner的應用，請發電郵致：kentbill@gmail.com
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
如有須要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人平常工做繁忙，經過微信,QQ等工具可能沒法深刻溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)