前回、解がない場合の解析を行いました。実務場面で、ここまで詳しく見る必要はありません。単に、「9月19日、グループAの夜勤明けリソースが足りないのだな」ということだけ分かれば、十分です。
しかしながら、実務場面で、予定を入れるたびに、こうしたことに頭を悩ませるのは、好ましいことではありません。ブランク予定で、UB=0が保証されていれば、機械的手順で、予定が変更される部分は分かりますが、一定のスキルを要するので、出来れば、そういう事態は避けるような、恒久的プロジェクトの改善を行うことが好ましいです。
1)列制約のソフト化
2)行制約のソフト化
3)グループA/Bに関わるのでバランスを整える
グループAのリソースが足りないので、グループBのリソースに余裕があれば、改善する可能性があります。その月で、もし変えることが可能ならば、カットアンドトライでやってみる価値はあります。
4)グループA/B両方対応できるスタッフがいないか?
スタッフ1は、丁度そのようなスタッフなので、グループ集合を変更して制約を変更します。
<まとめ>
夜勤明けリソースが居ない問題について
1)予定変更
2)列制約のソフト化
3)夜勤明け後の休みのソフト化
4)グループバランス
5)グループA/Bの両方に対応可能なスタッフ記述
対応する方法を述べました。列行どちらの選択をするかは、重みの選択によります。
一つの解がない問題について掘り下げました。ハード制約間の矛盾で解がない事態となってしまうので、基本的には、予定・列・行のいずれかをソフト制約で逃げる必要があります。
大事な事は、解がない⇒原因は様々ある⇒ソルバは、原因に関するヒントを列挙はしますが、上のどの対応が適切かは分かりません。管理者だけが正解を知っているということです。
そして、その正解は、予めソフト制約や重みによって自動的に選ばれるようにしておくことが、恒久対策となる、ということです。
上のような解析は、開発時だけのもので、稼働時には、常に管理者にとっての正解が示されるようにしておく、ということがポイントです。
0 件のコメント:
コメントを投稿