普通企業的規劃類項目中，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作為規劃引擎更可行。

[Constraint satisfaction solver (Java™, Open Source)

​](www.optaplanner.org)

如需了解更多關于OptaPlanner的應用，請發電郵緻：[email protected]

或到讨論組發表你的意見：

https://groups.google.com/forum/#!forum/optaplanner-cn

若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或讨論組方式提出。(讨論組屬于google郵件清單，國内網絡可能較難通路，需自行解決)