Ans.
プロジェクトファイルを拝見したところ、確かに遅番が0人のところが多くなっています。
当該制約は、下記レベル3になっていました。慣例ですと、この重みは、3で軽い制約の部類となります。そこで重みがソフト制約の中では最も重いレベル7に変更してみます。
求解します。
遅番の重みは、増したのでその効果が表れ、全日で1名を確保できました。

目的関数値UBの変化を見てみましょう。変更前と、
変更後です。
変わっていないことに注目してください。特に重み3のエラー数は変わっていません。重み3は、遅番重みを3→7に変更したので、その分のエラー数は少なくなってしかるべきですが、その分別なエラー(今回は、早番が主体)が増えていて、目的関数値自体は変化していないことが分かります。
変わっていないことに注目してください。特に重み3のエラー数は変わっていません。重み3は、遅番重みを3→7に変更したので、その分のエラー数は少なくなってしかるべきですが、その分別なエラー(今回は、早番が主体)が増えていて、目的関数値自体は変化していないことが分かります。
重みで、優先度は如何様にも変えることができますが、
一方で、リソース制限下において、あちらを立てればこちらが立たずのトレードオフの関係にあります。
重みを変えることで、リソース制限下で、管理者の欲する狙い目に近づけることは出来ますが、この例のように、他への影響は、避けて通れない、ということを心しておきましょう。
一般には、両方満足させる解は、リソース(人的資源)を増やさないと物理的に無理です。最適化システムにおいては、限界までリソースを使い切っているので、目的関数値自体は、あまり変化しないのです。
例外として、例えば、チームA/Bで偏りがあるときは、全体リソース制約下での物理制約ではないので、チームA/Bの偏りを改善すれば、改善することが出来ます。
0 件のコメント:
コメントを投稿