背景
在過往參與的一些項目支持工作，以及平臺發佈後各位小夥伴使用過程中，經常遇到這樣的問題：你這個引擎性能怎麼樣？可以處理多大數據量的排程?我有數萬個任務，這個引擎多長時間可以排產結果? 這個問題會引出整個生產計劃過程中計劃方式的問題。本文將分3篇探討對於此類問題的3個不同維度的解決方案，分別是：
- 分階段規劃 - 解決大規模規劃問題的粗、細規劃方案
- 分區規劃 - 解決大規模規劃問題在空間維度上分區規劃方案
- 持續規劃 - 解決不同計劃週期之間的連貫性問題
- 實時規劃 - 實現對時間要求高的實時作業調度方案
規劃問題屬於NP-Hard問題
事實上關於規劃引擎運算出結果，可能大家有點誤解。需要使用求解器(OptaPlanner就是一個求解器)進行規劃運算的，通常是一種稱NP-Hard的問題。相關概念大家可以自行搜索，通俗一點講，就是一種沒有辦法通通有限時間算法推導出結果的問題，只能對它的解空間進行搜索，找到一個最佳結果；但事實上這些問題的解空間非常大，可以理解爲，當一個NP-Hard問題規劃(即數據量)足夠大時，它的解空間並不是目前世界的電算機算力可以遍歷完的。需求解器就是內置了一種叫做啓發式算法的邏輯（例如遺傳算法、禁忌搜索法）用於提高獲得更佳解的效率和機率。那麼NP-Hard問題的解空間有多大呢？以圖是OptaPlanner在對一個俗稱爲八王后問題的大小計算。這個問題已經是各種NP-Hard問題場景中幾乎最爲簡單的場景了。
N王后的問題大小
現實中的大規模規劃問題
而我們在規劃過程中，面對的APS（生產、項目排程），VRP（車輛路徑規劃）等問題，因爲其複雜程度高得多，導致問題規模，也就是問題的解空間比八王后問題大得多得多！如果一次過規劃數萬個任務，甚至上萬個工單，按工展序開後超10萬的任務。對於NP-Hard問題來說，已經屬於超大規模問題了，當然除了數據量外，問題規模還需要考慮約束的複雜性，越複雜的約束運算所需時間越多。事實上，而對這種規劃的排產問題，我們需要一些技巧來對問題進行化簡，而不是一味追求高性能的程序來處理, 當然建立調質量的模型來提升規劃效率，也需要不懈努力，不能停止。
其實，真正產生這種超大規模規劃問題的場景並不多，很多情況下是人們未能從本質上理解場景，未對問題進行合進的分析、演化和化簡而導致的。若不採取合理的優化措施，只是看到一個簡單的規劃問題，然後就簡單粗暴地建立簡單的規劃模型，就直接提交給求解器進行求解，就算當前的場景能解決，以後隨着數據量增大，約束增加，最終還是出現無論如何增大計算機運算能力都處理不了的時候。
本文將分兩篇探討一下對於這類“超大規模問題”的處理方法，本篇會從業務角度對問題這類問題進行分析，展現一下如何通過滾動計劃的方式，對規劃數據在時間上進行由粗到細、分階段劃分，實現遠粗近細的多層次規劃，從而避免一鍋端方式帶來的對算力的無盡浪費。各位小夥伴可以根據自己的業務場景分析一下，這種方式能否優化大家的業務需求。
分階段規劃
場景
我們做軟件開發項目管理過程中，都需要制定項目計劃，需要對未來項目工作的進度與資源分配，根據當前認識的條件作出一定程度的預計，即由誰在什麼時間完成什麼工作。對於一些規模較大的項目，當然持續時間足夠長時，我通常會使用滾動的方式來制定整個項目計劃 - 稱爲滾動計劃。即對於時間較接近，資源情況較爲有把握的部分工作，需要精準安排時間、調配資源的工作，需要定出儘可能準確的作業任務；而對於時間較靠後、資源安排較不確定的工作，則可以暫時制定較粗的原則性計劃。因爲時間較遠的工作，資源確定性差，其依賴工作確定性也不高，制定過於精確的計劃其價值並不大，卻會造成極大的工作浪費。
區分精粗計劃
對於我們生產製造場景亦然。在我們實際的生產製造企業裏，銷售工作是持續進行的，客戶下單所需的交貨其也千差萬別，交付方式也各單差異巨大。有可能同一個月獲得的銷售訂單中，各個訂單的交付期分配在未來一個月到半年甚至一年時間。也有可能有些戰略型的訂單下的是未來整個季度或半年的總訂購量，這個總量卻是在未來的大段時間分階段交付的。基於滾動計劃的原則，對於近期需要加貨的訂單，我們可以製造精確的精細生產計劃，即通過APS對這類需求的工單進行資源分配、時間排序，從而獲得一個精準的生產作業序列。而對於一些可能需要一個月甚至兩三個月後才交付的訂單，因爲生產這些訂單產品所需的資源（原料、產能等）以當前的條件預判來說，可靠性極差。例如：未來3個月的工人班次、生產設備維保計劃、原料訂購計劃等都未確定。因此，對於這類交付不急且依賴因素不確定的訂單我們可以對其排出一個主生產計劃，即MPS，一個以訂單爲規劃對象(而非工序)的粗放計劃。它的各個要素可如下定義：
- 計劃的對象是訂單，或子訂單(即大的戰略項目劃分成多個子訂單交付)
- 預估每個訂單的持續時間與產能需求
- 對需要採購的外部產能假設爲無限
- 對未來的產能做大概預估。
以下是OptaPlanner用戶手冊中一個，使用多階段規劃處理鐵路時刻表的示例
通過上圖我們可以看到一個簡化的鐵路調度時間策略示意圖。因爲在空間上，全國的鐵路形成一個網狀關係，而且各個車次對鐵路的佔用具有獨佔性要求，各個區域和車次調度需要通盤統一考慮。但是從時間上來看，從粗到細，按以下三個層次進行區分：
- 戰略計劃(或稱戰略規劃): 對於以月來單位、計劃時間是未來月甚至數年的部分，可以製造一個戰略計劃。例如未來一年哪個地區客流、物流需求受各種政策影響，需要對用量、負荷作出一個粗放計劃，其目的是用於對鐵道、站臺等配套設施的調整。
- 戰術計劃： 對於未來一到兩個月的運行計劃，製造一個以周爲單位的戰術計劃，即計劃到每週的工作調配。通常用於人員安排等較近期的工作調度。
- 運營計劃：對於我們普通人接觸到的列車運營時刻表，則需要作出最爲細緻的計劃，它的運營精度會確定到分鐘；而發佈時間則細到按小時發佈, 相當於我們的實時規劃，因爲鐵路運行情況時刻在變，我們平時遇到的晚點、加開等事件與措施，主是在運營計劃中產生的。
同樣地，對於我們企業中各個層次的計劃，也可以據此劃分，分爲以集團爲單位發佈，精確到月分、涉及未來一年的粗放規劃，主要作用在於作爲運營決策。再針對每個生產單位（生產廠或車間）發佈未來一到兩週的生產計劃主要用於資源調配。而最細的則是車間中調度部門制定的具體作業計劃，精確到每條產線、或每個機臺、每個工位；其目標是安排每個產線、設備的具體作業工作。當然，各種具體的場景需要視實際情況劃分，有可能只需要兩個層次，也有可能需要劃分到更細-四層。每個層次都可以使用規劃技術進行運籌優化，從而獲得一個相對最優的計劃方案。但解決每個層次需要建立的規劃模型肯定是不一樣的。我們的通用智能規劃平臺，下一個目標就是實現精細兩個方案的銜接。即在MPS階段對各個訂單進行優化分配，在此基礎上對所產生的工單進行展開、分配資料、排定加工順序與依賴關係。當然，未來我們還會提高層次的戰略計劃，其目標是提供一個產能預測、MRP等領域的優化引擎，從而實現更高層次的規劃優化。並把不同層次的優化有機銜接起來，以杜絕每個層次部署各種異構系統帶來的過度建設問題。
本篇我們先討論企業中整個計劃過程按階段劃分的問題。下一篇我們討論這個過程中另一個方案 - 持續規劃
《End》
以下是一翻推廣：
誠邀大家使用我們的【易排通用智能規劃平臺】，它基於OptaPlanner對APS的一些常用規劃邏輯進行封裝，大家只需要管理、維護好自己系統(使用MES、MOM、ERP中的計劃模塊)中的工單數據，即可快速地實現一個APS模塊。後續我們還會添加【VRP - 車輛路徑規劃】和【在線調度】模塊，敬請期待。可以通過以下鏈接查看更多該平臺的使用方法。
與平臺相關疑問，可以添加本人微信探討，或關注我們的公衆號【讓APS成爲可能】及時接收相關消息。