列制約とは、縦の列のことです。
トップの日の看護品質をさらに向上させることではなく、最も低い日の看護品質を引き上げて、一定以上の看護品質を保つことが目的です。全ての日が、一定水準以上になるように平準化することが目的になります。平たく言うと、医療事故を防止すること、です。
一般に、列制約については、かなり厳密に運用されていると思います。人力解でも上のような制約エラーが多発する勤務表を見ることは少ないです。これは、管理項目として、実際に日々縦のラインをチェックしている結果であると思います。これに対して、行制約の方は、一般に緩く、頂いた仕様に対して結構なエラーが生じる傾向にあります。
求解させれば、スケジュールナース解が出ます。
ほぼ、列制約エラーは、消えました。(初日に出ているのは、先月の人力解の影響です)
<上記赤ラインを必要以上に高くとったときの問題>
下記は、人力では到底できないような複雑な列制約です。
これに対して、予定を元に戻して求解させれば、スケジュールナース解が出ます。
ほぼ、列制約エラーは、消えました。(初日に出ているのは、先月の人力解の影響です)
人力解とスケジュールナース解とでの比較でみると、
スケジュールナース解の目的関数値は、UB=141
となっていて、5倍以上の差が生じています。特に、重篤なエラーが少なくなっています。
人力解の目的関数値は、UB=877
スケジュールナース解の目的関数値は、UB=141
となっていて、5倍以上の差が生じています。特に、重篤なエラーが少なくなっています。
それなら問題ないじゃないか?と思われるかもしれませんが、実は問題があります。
二つの問題が生じます。
(1)解空間が必要以上に狭まる
(2)メンテナンスが困難になるメンテナンスのない勤務表は存在しません。組織変更、人事異動、退職、妊娠・出産等により、月々に変更することが付きまといます。制約が複雑であればあるほど程、融通が利かないので、誰かが制約を変更しなければならない確率が高まります。
結論としては、現時点で運用中のルールをそのまま仕様化することをお勧めします。往々にして願望を仕様化すると、複雑で高すぎる制約となります。
スケジュールナースを使いこなす上でも、バランス感覚は必要です。Githubにも色々な実践的プロジェクトファイル例を挙げています。どれも、上のような複雑な列制約はありませんので参考にしてください。
0 件のコメント:
コメントを投稿