2024年8月31日土曜日

長日夜勤システムで、公休数を±0.5で変化させる場合の問題

 ある顧客システムでは、半1というシフトで、補償するシステムになっています。

具体的には、

例えば、公休基準10の月とします。

半1が一個あると、0.5公休とカウントします。

仕様は、

<半1の仕様>

1個の場合の公休カウントは、10.5になる。 2個の場合は、2個の半1を1個の公休として、2個の半1+9個の公休=10になる



<長日勤の方が多い場合(最大で1個の違いまで認める)>
一か月間の長日勤(長日)回数が夜勤(夜)回数より1回多いときは、日勤1回ををam休pm日勤(半1)に変更する。この分は、0.5と公休数に影響する(カウントします)。また、日勤1回を am休pm日勤(半1)に変更後は、基準月の公休10個と一致しなくなり、公休は10.5となる。

<夜勤の数が多い場合(最大で1個の違いまで認める)>
一か月間の夜勤(夜)回数が長日勤(長日)回数より1回多いときは、公休(休)1回をam休pm日勤 (半1)に変更する。この場合は、予定半1がない場合、10個基準月に対して、それ以外の公休数は9個となり、計10個の公休数とカウントする。この分も公休数カウントに影響する。この場合、公休=0.5個(=半1)をカウントする。なので、10個基準月に対して、減らした公休1個を減じて公休0.5(=半1)を加えて、計9.5個の公休数とカウントする。
という風に実装できます。

このシステムの問題点

長日の扱いは、下記のような問題があります。

1)長日・夜勤差に纏わる問題

    長日・夜勤差をコントロールしようとすると、二つの問題があります。

■その制約自体が重い(問題の性質上、求解に時間がかかる)

■解空間を狭め、スタッフのQOLに少なからず影響する

    参考リンク:一般化した変則2交代 (nurse-scheduling-software.com)

 


これに加え、今回は、次のような問題があります。

2)±0.5日の公休差がもたらす不公平性

現実的には、あまり問題ないのかもしれませんが、各スタッフ間で±0.5/月の公休差が生じる可能性があります。理論的には、年間でみると最大12日の差が生じる可能性があります。











 



2024年8月28日水曜日

Kissat2024sc

 Armin Biere教授のKISSATが優勝しました。Paperは、

https://kfazekas.github.io/papers/BiereFazekasFleuryFroleyks-SAT24.pdf

解いた数は、殆ど変化はありません。しかし、解くスピードがイノベーションです。

問題をどのようにCNF化するか、というのは、一意ではなく、知識や経験においてSATソルバが解きやすい形態にすることは重要です。その意味において、ベンチマークインスタンスは、必ずしも最適な形態ではないので、その辺を解きやすい形に変換することがポイントだと思います。言い方を変えると、私のようにSATソルバの特性に熟知した人がモデル化したCNFとそうでない人がモデル化したCNFでは差があり、そのようなインスタンス群に対して効果がある手法だといえます。

今年のクラウドや、パラレルトラックについては、特に見るべきものはなく性能向上は誤差の範囲内だと思います。

2024年8月27日火曜日

SAT competition 2024

 SAT 2024 (satisfiability.org)

結果が発表されましたが、関連論文は、以下でダウンロードすることが出来ます。

通常年の通りだとすると、期間限定だと思います。

27th International Conference on Theory and Applications of Satisfiability Testing (SAT 2024) (dagstuhl.de)

今年は、疑似ブール制約のCompetitionも開催されたようです。

Pseudo Boolean Competition 2024 (univ-artois.fr)

こちらは、MIPとSATの間位の問題領域になっていて、NSPでも応用の可能性が期待できます。注目しています。


2024年8月22日木曜日

勤務表リリース後の予定変更

 Q.当初の月間割当以降の予定の変更については、通常、人力で修正するのか、あるいは、変更分を予定入力しスケジュールナースで未経過分の解を計算するのか?


Ans.

勤務表リリース後に予定変更があった場合、人力で修正することはお勧めしていません。やり方としては、以下の方法をお勧めしています。

■経過分については、過ぎ去った過去なので、変えることはできません。過去分は、実績も含め予定としてFILLINし全てハード制約とします。

■未経過分については、予定修正、および修正しなかった部分(前回の解をソフト制約予定として入力)します。そうすることで、リリースしてしまった予定に対する修正を最小の修正とすることが出来、スタッフとの折衝を楽にすることが出来ます。


また、人力修正の場合、修正を通せないため、やむを得ず本来Priorityが高い制約を反故せざるを得ないことが多いです。スケジュールナースの制約を使いこなして頂ければ、この辺も物理限界と予定変更量を勘案しながら解を構築していくことも可能です。実際の事例がありましたら、その状況を基にしたZOOMレクチャをすることが出来ます。プロジェクトが出来上がり、安定した折にご検討頂ければと思います。