在企業的規劃、優化場景中，均需要開發規劃類的項目，實現從各種可能方案中找出相對最優方案。如排班、生產計劃（包括高層次的供應鏈優化，到細粒度的車間甚至機臺作業指令）、車輛調度等。因爲這類場景需要解決的問題，均可以歸約爲數學中的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的應用，請發電郵致：[email protected]
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)