配送最適化（ケーススタディ ２）
注意：このケーススタディは，幾つかの企業のコンサルティングから抽出したもので，特定の企業を想定したものではない．データや登場人物は，架空のものである．
ロジスティックネットワーク設計の結果を上司にプレゼンしたところ，最適化された倉庫から実際に配送可能なのか質問された．さらに取締役へ報告したところ，配送費用が正しく評価されているか調べるように命令された．さて，あなたは次に何をすれば良いのだろうか？
SCMOPTには配送最適化ソルバー METRO IVが入っている．ロジスティックネットワーク設計モデルで得られた倉庫をデポと考え，配送最適化モデルを解くことによって，実際に配送が可能かを検証し，実際の配送費用を計算してみる．
まず，ネットワーク設計で開設すると決められた倉庫と，それらの倉庫に割り当てられた顧客の情報をもとにして，顧客のクラスタリングを行う．各倉庫をデポとした独立な配送最適化問題を作成して，配送最適化ソルバー METRO IVで求解する．
顧客の需要量は，年間稼働日数を200日と仮定して日割りにし， 各デポ（倉庫）には，20トン車(容量は20000kg）のトラックを，必要台数分だけ配置する．1つの顧客の総需要量がトラックの容量を超過した場合には，需要を分割して複数の顧客を設定する．
1日の稼働時間は10時間とし，0から36000秒の時間枠を設定する．各顧客上での作業時間は0とし，荷物は配達のみとする．地点間の移動時間と距離は，OSRMを使って計算する．また，ルートが見つからない地点間に対しては，大圏距離の5倍の距離を設定し，そこを時速50kmで移動すると仮定して移動時間を計算する．
目的関数は稼働時間の合計を最小化するものとし，配送しきれない顧客がいた場合にはペナルティを与えるものとする．
METRO IVで扱うのは，複数時間枠制約付き，多次元容量非等質運搬車，配達集荷，積み込み・積み降ろし，複数休憩条件付き，スキル条件付き，優先度付き，パス型許容，複数デポ配送計画問題であり，以下の仮定を持つ．
- 運搬車ごとに始点・終点を定義できる．そのため，複数デポの問題も容易に記述できる．
- 総費用は運搬車の移動時間の合計とする．
- 1つのルートに含まれる顧客の需要量の合計は，運搬車の積載容量を超えない（これは複数の尺度ごとに定義できる）．
- 運搬車の台数は事前に与えられており，積載容量と稼働時間（１つの時間枠として定義されている）が与えられている．
- 顧客の集合は事前に与えられており，運搬車が到着時刻する時刻に対する複数の（任意の数の）時間枠を定義できる．
- 点（運搬車の始点・終点と顧客の総称）間には，移動時間が与えられている．
METRO IVの入力データには，以下のものがある．
- 地点 node: 需要（集荷・配達を合わせたもの）の発生地点と運搬車の出発・到着地点（デポ）の位置情報を保管する．
- ジョブ job： 荷物の集荷もしくは配達を希望している地点をジョブと呼ぶ．ジョブデータでは，集荷・配達の情報を保管する．
- 輸送 shipment： 運搬車の出発地点（デポ）以外での荷物の積み込みと積み降ろしの組を輸送と呼ぶ．輸送データでは，積み込み・積み降ろし情報を保管する．
- 運搬車 vehicle： 運搬車とは，輸送手段の総称であり，容量や時間枠をもつ．運搬車データでは，輸送手段の情報を保管する．
- 休憩 break : 運搬車の休憩情報を保管したデータである．
- 移動時間 time: 地点間の移動時間を保管したデータである．地図を用いて，緯度経度情報から直接移動時間を計算する場合には，使用しない．
デポごとに最適化した結果は，以下のようになる．（スライダーで各デポに対する配送経路を見ることができる．）
すべてのデポに対して配送最適化を行うと数分で近似最適解が得られる．
総移動時間は6797198秒，総移動距離は135201515mとなる． ロジスティックネットワーク設計と同じ仮定（トラックの時間あたりの費用8000円，1kmあたりの費用20円，年間稼働日数200日）で比較する．ロジスティックネットワーク設計における総配送費用3379672000と比較してみると，約5%ほど高いことが分かる．
((6797198)/3600 * 8000 + 135201515/1000*20 )*200 /3.379672e+09
>>1.0538842079612722
すべてのデポの問題を一度に最適化することもできる．計算時間は10分程度かかり，結果は総移動時間は7017639秒，総移動距離は139976582kmとなり，ほんの少しだが悪化する．これは，ジョブ数が1385の大規模な問題例であるため，複数デポから配送可能な柔軟性よりも，求解が不十分であったことによる解の悪化が上回ったと考えられる．運用上も日々割り当てデポを変えることは煩雑なので，デポごとに最適化することが推奨される．
結果の図から，北海道に2箇所のデポがあり，統合可能であると社長から指摘された．これは，ロジスティックネットワーク設計において倉庫・顧客間の最大道路距離を300kmと設定していたためであり，再計算の必要があるだろう．沖縄デポは数件しか配達していないので，自社で倉庫をもたずに，3PLに委託することも検討すべきだ．
上司からはトラックがどの道路を通るべきか質問された．METROでは，実際の道路距離と時間を使用しているので，最適化に使用したルートが以下のように表示できる．（地図も3種類から選択でき，Uターンを避けるルートにもすることができる．）
実際には，工場から倉庫までの輸送費用も正確に計算し，ロジスティックネットワーク設計を再び解く必要があるだろう．また，倉庫の候補地点も，顧客上に配置するのではなく，より適切な候補地点を探す必要がある．このように，複数の最適化モデルを交互に利用しながら，徐々に詳細な意思決定を行っていくのである．
アナリティクス
実際の配送最適化には，様々な付加条件が付く．それらに対処するためには，単に最適化を行うだけではなく，データの分析（アナリティクス）が重要になる．
たとえば，デポの位置を決めるためには，顧客の需要量の大きさや，デポからの移動時間が重要になる．通常は，単に土地が安いだけでなく，利便性を考えてインターの近所を物色することになる．その際には，デポ（の候補地点）から顧客への移動時間のヒストグラムを見ると良い．
デポに配置する運搬車の数も重要な意思決定変数である．どのような種類のトラックを何代準備しておくかは，中期の意思決定モデルであり，配送最適化は短期の意思決定モデルである．そのため，需要の不確実性だけでなく，傭車の費用なども考慮して，最適化を行う必要がある．また，時間枠も重要な要因である．(積込みと積み降ろしを考慮した）需要量と時間枠は相互に影響するので，時間帯ごとの運搬車の必要量を概算しておくことが重要になる．そのためには，以下のような時間帯別のトラックの必要台数の概算を見ると良い．
他にも実際には，時間枠のための待ち時間や休憩制約（何時から何時までの間に何分の休憩をとる必要があるという条件）を考慮する必要がある．もちろん，時間枠や休憩は複数考える必要がある．これを可視化するためには，ガントチャートを見ると良い．
METROには，20年以上の実際問題へのコンサルティングをもとに，実務で発生しうる様々な付加条件を取り入れてあります．また，実際には機能追加をしなくても，最適化をツールとして使うことによって，解決できる場合が多々あります．そのためのノウハウも重要になってきます．弊社では，そのような経験と知識を有する専門家によって，より現実的な問題解決を目指しています．
本ケーススタディで使用したのは配送最適化システム METRO (MEta Truck Routing Optimizer)は，サプライ・チェイン最適化システムSCMOPT に含まれています．
SCMOPTデモ＆トライアルはこちら