在制定生產計劃過程當中,必然是存在某些制約因素,知足某些需求才能進行的,或是交期保證、或是產能限制、或是關鍵工序制約。即TOC理論 - 任何系統至少存在着一個制約因素/瓶頸;不然它就可能有無限的產出。就是說,若是不存在這個(或這些)制約因素,生產計劃就不必「排」了,只需隨意地,毫無約束地把任意一個或多個生產任務歸入生產日程,都能知足生產、營業等全部業務要求。那也不須要人的智慧參投入其中了。微信
而現實環境中,資源是有限的,且每每是在資源不足,並須要儘可能知足制約因素狀況下進行計劃制定。在制定計劃的時候,不一樣的公司,基於不一樣的經營策略,須要遵循不一樣的原則。即便是同一個公司,在不一樣的業務場景(例如淡/旺季),其須要遵循的原則也可能不一樣。例如旺季由於生產任務緊張,須要保證交期;而談季相對來講可用產能會較充裕,保證交期就會不太困難,進而又須要遵循另一些原則,譬如儘可能下降生產成本等。而在這些原則以外,還有一種相對來講是比較固定,或者比較約定成俗的原則,就是儘早開始(As soon as possible),和即時生產(Just in time)。其中即時生產,是精益生產中的一個概念。本農上一家公司已推行了比較成熟的精益生產體系(精益絕對不是5S喔,更注重的是流程優化,識別並消除不增值活動,減省不增值但必須的活動)。因此當時設計APS系統時,不少時候就遵循即時生產的原則。此原則由整個供應鏈中最後一個環節驅動(例如出貨環節),從而推進前工序的生產安排。而不少不太強調精益生產的製造企業,在老生產計劃員來看,制定計劃的時候,除了較低程度上實現批量生產,以便高資源利用率,而進行對小批量生產任務稍做停留等待外,一般是按儘早開始的原則進行的。由於一般人們的想法是,將來的生產任務和產能具備不可預見性,你不知道將來會不會忽然由於客戶加單,機器故障等客觀且不可控因素致使產能吃緊,甚至令生產單位措手不及。若是這種意外狀況真的出現,那麼一開始使用盡早開始原則安排生產計劃,令到後面的產能較充裕,應對起這些「意外」起來,就相對輕鬆多了,這類原則下的生產計劃優點就體現出來了。而實時生產原則,則有可能由於預留在較後時間的資源(例如機臺產能)是比較「準確」的,那就相對按儘早開始原則制定的計劃來講,就更加被動了。但即時生產原則下的生產計劃,應對這種「意外」,也是有不少相應措施的。例如使用適當的緩衝機制,和實時計劃機制來應對。緩衝機制就是根據過往歷史經驗,在按即時生產原則制定生產計劃時,預留必定程度的冗餘資源做儲備,當出現「意外」時,可使用這些冗餘的資源進行補救。而實時計劃相對來講「先進」一點了(先進二字加個引號,是由於這只是我以爲這種方法先進一點)。這種所謂的先進,主要體如今經過自動化的排產引擎,將計劃制定到足夠細緻且精確,對任務的生產狀況(包括既有任務的執行狀況,資源使用狀況和新任務的增長量等)進行實時監控,使計劃實時地對這些狀況做出反映,並及時給出新的應對方案。例如:當有新任務出現時,即時更新新增的任務到計劃中;有資源出現突發意外(例如機臺忽然故障)也能夠反映到計劃中,並即時做出反映,及時給出修正後的計劃。但經過實時計劃是相對比較複雜的的方案,在Optaplanner中也有real-time planning的功能,我將會在Optaplanner相關的系統列文章中,單獨撰一篇來說解實時計劃。另外就是執行層面對實時計劃的執行依從性問題了,如何制定的計劃很精確,但執行過程相對來講是沒法精確達到,比較粗糙的,例如:手工工序,人的執行能力相對機器來講,準時性會差很遠的。網絡
既然即時生產如此繁瑣,爲什麼還要採用呢?爲什麼不所有采用盡早生產的原則來制定計劃呢?其實還真不是那麼簡單,相對生產環境的「繁瑣」,對於老闆來講商業上的利潤更爲重要。若是你們理解精益,就知道它不少狀況下,要精簡的活動就是 - 「等待」,由於等待這個活動在整個價值鏈中,是不增值且沒必要要的,因此它是首個被除掉的活動。爲什麼這樣理解?由於若是對於一個並不很是緊急的產品,你一開始就完成了它的一大堆的半成品,或成品,佔用了大量原本能夠優先用於其它生產任務的的資源(庫存、資金等資源),從而令到資源的利用率隆低了,對於老闆來講,資源利用率高低但是實打實地影響到最終利潤呀。本農曾參與過國內某一線生活用紙企業的產銷協調平臺的需求調研,記得討論到關於目前的環境下,車間的批量生產是否能節省成本、是否仍有價值的問題時,當時的物流總監安奈不住情緒發飆了 - 大家到底會不會算賬? 少投幾回料,少清幾回機省出來的那點紙漿價值,大量生產出來的這些產品,放在北京一個物流倉裏,一天的成本是多少?一個批次使用這種所謂的批量生產輸出的成品,不到一個星期,庫存成本就已經把全部生產環節省出來全部成本都吃掉了。因此,實時生產對於一些在製品成本高的企業,是能有效下降WIP,進而實打實地降整個供應鏈成本的。這也是即時生產的魅力所在。工具
上面講解了儘早生產與實時生產兩種原則的區別和各自的優劣,你們須要跟據本身的具體場景去採用,下面咱們就針對這種原則的排產方式展開討論。先不講這兩種制定計劃的原則,在生成規劃引擎Optaplanner上的實現方式的區別。假設咱們是生產計劃員,面對這兩種原則,咱們應該如何制定生產計劃呢?優化
先說盡早生產,其實說白了,就是有一個產品的一系列生產任務,一旦準備就緒了,就能夠將它排入計劃中,且排在時間軸上越靠前越好,不一樣工序對應的生產任務,在遵循固定的工序前後時間關係的基礎上,越早開始越好,正常狀況下上下任務之間是FS關係(即必須等上工序完成了,下工序才能開始),而在精益的優化流程中,特別是一些離散製造的場景,是能夠實現SS的(便是上一工序一旦有工件完成,便可對這些工件開始下一工序的加工)。因此不一樣工序對應的任務是緻密的,從而很好地實現了儘早生產。因此,咱們可想而知,對於儘早生產原則下的生產計劃,它是基於每一個任務的就緒時間進行排產的,也就是說一個任務一旦就緒了,那麼它在生產計劃中的開始時間就是就緒時間的下一個時間單位了(這個時間單位多是分鐘或各車間本身制定的最小時間間隔)。當一個產品的首個工序時間在生產計劃中肯定了,按儘早生產的原則,可能推算出這個產品的後下全部生產工序對應的加工任務的最先開始時間,由於可能存在資源上的限制,並不必定可以在每一個工序對應加工任務的最先開始時間開始加工,但仍是遵循了儘早計劃的原則,就是一旦上工序生產完了,當前這個工序的資源就位了,那就能夠開始生產。若是按照上述的原則定製出來的生產計劃,在甘特圖上能夠看到,全部生產任務都是盡能夠靠前的且儘可能緻密的。google
再說說即時生產。上面已經說過,即時生產的原則是供應鏈最後一個環節來驅動的,一樣地在供應鏈中的生產環節裏,也是基於最後一個生產工序來驅動全部生產工序的加工任務的。也就是說,最後一個工序(例如包裝)的生產任務要求什麼時間要完成的,那就基於這個完成時刻 ,往前推算(例如,在要求完成時間,減去加工任務的時長,再減去一些準備時間等),就能夠推算出前一個工序的生產任務的要求結束時間.....如此類推,就能夠推算到整個產品的首個工序的生產任務的開始時間,從而獲得全部生產任務的具體生產時間(包括開始時間與結束時間)。由於這種方式下制定生產計劃是從後而往前推算的,因此從計劃的甘特圖上看,全部任務在時間思上是儘可能日後靠且緻密的。設計
上面咱們已經知道,咱們的生產計劃人員,是如何排出儘早開始與實時生產兩種計劃的。若是咱們使用規劃引擎Optaplanner來輔助咱們智能快速地制定這兩種生產計劃,應該如何設計呢?首先須要交待一下 Optaplanner在處理這些時間分配的要求時,它是如何實現的。經過前面Optaplanner系列文章中一些簡單的示例咱們知道,Optaplanner作規劃的基本方法,就是對於被規劃對象(例如生產任務),從可能的資源列表中,取出相應的資源對各個被規劃對象進行嘗試,經過分數的計算對比來肯定資源應該如何分配才獲得更好的方案。這裏面的資源一般都是一些具體的物理物件,例如機臺、工人等.沒有說起時間這種資源是如何實現分配的呀。而咱們全部的生產計劃,事實上也就是在兩個維度上的資源分配;分別是時間與空間上的分配,就是肯定一個被規劃對象的時空。例如肯定一個任務應該分配在哪個機臺上(空間),須要在何時開始生產,須要在什麼時間結束(時間)。事實上,Optaplanner的設計者早已考慮到這個問題,並提供了較完善的實現方案。針對時間維度的分配,Optaplanner提供了三種模式來實現(見圖Assigning time to planning entitis),對於這三種模式,在Optaplanner系統列文章中,也將會有專門文章會講解,在此不展開。在這三種模式中,其中一種叫作Chained Through Time pattern模式,我面對過一些複雜的排產場景,通過多翻嘗試和掉過各類坑,仍是以爲這種模式最爲適合,它能夠提供三種時間分配模式中最爲豐富和靈活的接口,供咱們實現一些特殊的需求,具體的應用再去參考相關文章,在此真的不夠篇幅展開。這個模式的原理是,Optaplanner並非分配哪一個時間資源到哪一個任務裏去,而是對於全部的被規劃對象,Optaplanner會把它們串成一個鏈(見圖Chain principles),一個接着一個,Optaplanner要嘗試規劃的是這些被規劃對象在鏈上的位置,它體現爲當前的被規劃對象,它的前一個對象是誰,每一個對象有一個屬性用於指向它在鏈中的前一個對象,而這個屬性就是它的Planning Variable. 而且,Optaplanner提供了接口,當這個Planning Variable因當前對象在不一樣的鏈之間切換,或在同一個鏈中的不一樣位置切換的時候,這個接口可讓你告訴Optaplanner這個位置切換影響了被規劃對象的另外的哪些屬性(見圖Planning Variable Listener),這些被Planning Variable的變化而被影響的屬性就叫作Shadow Variable.這樣的話,咱們就能夠應用這種機制,把Shadow Variable定爲被規劃對象(下面就以制定生產任務爲案例,將被規劃對象稱做任務,這樣更容易理解)的開始時間。那麼咱們就有:當一個任務處在不一樣鏈的不一樣位置時,它的開始時間就會受影響了。具體的實現方法是,當一個任務的位置變化先後(其實體現爲它的前一個任務變化了),Optaplanner會觸發關於這個前任務變的一系列事件。咱們就在這些事件的處理方法中,去推算這個任務的開如時間,完成修改後,須要通知Optaplanner進程咱們的修改,讓它去計算分數來評價這個方案的優劣。從而實現了任務的位置變化,影響了開始時間,開始時間的變化,就能夠推算出具體的結束時間。3d
其實上面是咱們在使用Chained Through Time pattern模式最經常使用的情景。若是實現了上述的方案,就已經排出了儘早生產的計劃了。由於每一個任務變化的時候,咱們推算的都是它的開始時間。固然這個開始時間不只僅是依據當前任務的前一個任務的結束時間推算出來的,還須要參照當前任務的就緒時間(如有的話),和當前任務的準備時間(如有的話)。但即便考慮了這些因素,它仍然是儘早開始的。那麼若是咱們而對的項目是須要實行精益生產的,須要實現即時生產的,應該如何作呢?其實大概的實現方式是同樣的,只不過須要把生產任務造成的這條鏈的方向從時序上反轉。在儘早生產的場景下,在鏈上的是以首個任務的開始時間做爲基點,推算後面的其它任務的時間,進而推算其後方的其它任務的開始與結束時間。在即時生產的場景下,由於是由後工序驅動的,咱們能夠反過來,鏈的起頭再也不是首個任務的就緒時間了,而是最後一個任務的結束時間做爲基點,往前推它的開始時間,而在鏈上的下一個下任務,而實在業務上對應的是它的上一個工序對應的任務,如此推算出來,就獲得上一任務的結束時間,進而推算它的開始時間,如此類推,計算整條鏈的全部任務的結束時間與開始時間,在鏈尾就獲得首個任務的開始時間了。把它反映在計劃甘特圖上,全部任務都是趨緊向後工序的,也就是實現了即時生產了。固然,上述提到的緩衝機制,你們應該很容易理解,也很容易在鏈中實現。對象
經過上的兩種計算的生成過程,你們應試注意到一個細節,就是儘早生產,它是基於第一個任務的就緒時間來向後推算後面任務的時間。形象點就是說,它一旦定好了開始時間,就按這個時間日後排計劃了,就是告訴引擎,反正我這個時刻開始的,你就按這個時刻,根本必要的考慮因素和約束,從前日後推算出一個計劃來吧。因此咱們把它稱爲前推式生產計劃。而另一種即時生產原則下的生產計劃,它是相反的,它肯定了最後一個任務的開始時間,再往前推算前面各個任務的結束與開始時間,其實也是往前推算出來的時間。但由於它是基於供應鏈中的最後一個環節來驅動前面的生產活動的,因此咱們形象地把它稱爲後拉式計劃。也就是說,反正我定了哪一個時刻須要完成的,大家前面的任務就貼着這個時間來安排結束時間和開始時間吧,就像從最後一點把前面的任務日後拉出一個生產序列來,所以咱們把它稱做後拉式生產計劃。blog
至此,咱們分別探究了儘早生產(前推式生產)和即時生產(後拉式生產)兩種排產原則的考慮因素,計劃方案和在規劃引擎Optapalnner上的實現原理。具體的實現我將會經過兩篇文章來描述,一篇用於描述Optaplanner對時間的分配模式;另外一篇將會以Chained Through Time pattern模式爲基礎,以生產任務的制定過程,探究一下Optaplanner是如何實現複雜場景下的生產計劃制定的。例如目前我負責的一個排產項目,及一些朋友的產品中,就涉及一些任務之間的前後次序制約,任務之間須要根據條件放置一些不屬於常規生產任務的操做等。這些林林總總的奇怪而又現實的要求,若是僅僅使用Optaplanner最基本的Planning Entity + Problem Fact進行規劃的模式,是沒法實現的。須要經過Chained Through Time pattern模式提供的事件接口,來實現一些咱們本身的業務邏輯,纔有可能把這些現實的業務需求體如今生產計劃中。接口
本系列文章在公衆號不定時連載,請關注公衆號(讓APS成爲可能)及時接收,二維碼:
如需瞭解更多關於Optaplanner的應用,請發電郵致:kentbill@gmail.com
或到討論組發表你的意見:https://groups.google.com/forum/#!forum/optaplanner-cn
如有須要可添加本人微信(13631823503)或QQ(12977379)實時溝通,但因本人平常工做繁忙,經過微信,QQ等工具可能沒法深刻溝通,較複雜的問題,建議以郵件或討論組方式提出。(討論組屬於google郵件列表,國內網絡可能較難訪問,需自行解決)