2024年2月16日金曜日

3月の勤務表づくりは、大変 ー大量の希望休・リフレッシュ休暇をどう捌く?

 ある介護施設での事例ですが、よくありそうな事例ですので、共有します。


3月は、リフレッシュ休暇の締めであり、期の最後である3月で、消滅してしまいます。

それで、皆さん、こぞって出してしまいます。

さらに、条件が悪いのは、3月の公休数が10個あり、休みに人が取られてしまって、夜勤、早番1・2、遅番、日勤リーダに人が廻らない、という問題が発生し易い、ということです。

看護師勤務表ならば、休日が多いと夜勤後の2連休が取りやすかったり、休日日勤者数が少なくてよいので、Welcomeな事の方が多いのですが、介護施設の場合、基本的に土日でも勤務者数は変わらず、公休数が多くて良いことはないように思います。


当然のことながら、組織の要件である列制約の夜勤者数、早番1数、早番2数,遅番数が満足できません。(赤部レベル7、黄色部それ以外のエラー箇所)
相当数の箇所が出来ていません。
そこで、リフレッシュ休暇を、公年(公休またはリフレッシュ)に置き換えます。
こうすると、休み希望日を維持しながら、全体休み数(リフレ分+公休数)を抑制させることができます。今、全体休み数が多すぎるために、早番、遅番に人が割り当てられないことは、分かっているので、リフレ休暇の代わりに公休を割り当てることもある、しかし、休み希望日は維持する、という意味になります。つまりリフレ休暇は消滅することもありうる、ということです。これは、事前に師長がスタッフに伝えていたということです。

結果は、改善は見られるものの十分ではありません。赤、黄色エラー箇所が残っています。

小手先の回避手段では、十分ではないので、なんとか改善することを考えます。

まずは、赤マークがついているところの原因を調べます。

予定を見ると、明らかに当該日の23日は、予定が詰まっていて夜勤の捻出が出来ないことが分かります。


物理的に不可能は、明らかです。グレーの日早は、公的行事日用で割り当てていますが、この部分をソフト制約化することで、赤の夜勤不足は解消できると考えられます。

次に行うことは、最低限譲れないラインを決め、ハード制約化します。

今、多くの列制約を満足出来ていません。現状は、全てソフト制約としていますが、

最低限、これは譲れないという制約は、ハード制約に変更します。


次が、譲れない線をハード制約化したものです。


次に、公休数をソフト制約化します。公休数は、本来ハード制約です。上でハード制約、予定もほぼハード制約では、解があるはずがありません。そこで、公休数をソフト制約化することで、人員の欠如を顕在化させます。

数を数える制約を基数制約、最近は、不等式制約という呼び名で呼んでいます。

レベル7なので、赤マークとなり、次のようにエラーが出ています。本来10回のところ、

8や、9になっています。


この制約で重要なのは、ソフト化する範囲指定です。範囲指定は、許容エラー数で指定します。今、2に設定しているので、10に対して±2,8から12までがソフト範囲となります。7以下および、13以上は許容しない(ハード制約と同じ)という意味です。2までは、解が存在したのですが、これを1にすると、解はありませんでした。つまり、公休10に対して、どうしても、公休8まで許さないと解が存在しないということです。つまり、リソースが足りていない、ということを意味しています。

列制約、予定制約、行制約、全てがハード制約ならば、解はありません。今、最低限必要な列制約をハード制約としました。予定も23日を除けば、ハード制約のままです。従い、行制約のリソースに関わる制約、公休数制約をソフト化することによって、解を出現させるようにします。全部が公休10に限定するならば、それは、ハード制約と同じ、許容エラー0ということであり、やはり解はありません。許容エラー1、つまり、公休数を9まで許すとしたときも解はありませんでした。公休数を8まで許す(許容エラー2)のとき、初めて解が出現しました。つまり、リソースが足りてないということが、ここで理解できます。


ところで、赤マーキングが出ているのは、下に集中していることに気づきます。

プロパティの選択を変えてみると、明らかに、人員不足は、3階に集中していることが分かります。逆にいうと、2階は、全く充足しています。


ということは、2階の人員を3月だけ3階に回せば、廻るのではないか?という発想が当然出てきます。そこで、2階の人員の一人を3階に回すと以下のとおり、公休エラーも無くなりました。解があるということは、全てのハード制約は満たすということです。(列制約部分は表示していませんが、解がある→自動的にハード制約は全て満たすなので、問題なく目的部は満たしています。)

夜勤後の休みが確保できていない箇所がありますが、この程度ならば、当該エラー箇所の予定を変更で対処できるでしょう。


公年は、下のように重み8にして、ソフト制約でも高い重みとして、なるべく当初の休み希望を満足させています。日早は、重み3としました。


結果、重み8のエラーは、2個、重み3のエラーは、4個出ていることが分かります。

当初のリフレッシュ休暇希望箇所は、50個近くありましたが、希望休み日に休みが取れなかった箇所が僅かに2か所、行事に参加できなかった人が4人という結果です。

以上のようにして、当初の、「どうにもならない」かに見えた勤務表も、何とかなる形に持っていくことが出来ました。人力では、どうしようもない大量の希望休もスケジュールナースでは、なんとかなってしまいました。


指針として、

1)必要最低限を定めハード制約とする

2)しわ寄せ解析、リソースのどこが足りていないのかを解析する

3)部分的なリソース不足であれば、手はあるかもしれない(2階から3階に回す 等)

ということだと思います。最悪の最悪は、公休を借金する手もあるでしょう。

いずれにせよ、きちんと問題と向き合って、一体何が起きているか?どこが足りていないのか?を解析することは、必要な作業です。人的リソースを極限まで使いきるのであれば、それなりのスキルが必要になってくる、ということだと思います。(リソースに余裕がある職場では不要な作業です。)

私は、以上の解析を15分位で行いました。慣れれば、誰でも出来るようになると思いますが、車の免許と同じで、やはり十時間程度の教習は必要と思います。

ちなみに2月の勤務表では、全く上記の作業は必要なく予定を含む全ての制約を満たしていました。大量リフレッシュ休暇+3月の10日公休、という月の環境要件による違いだけで、これだけの差になってくるのか?という思いは私も同じです。

一方、施設側としては、比較的楽な月もあり、楽でない月もあります。リフレッシュ休暇は、比較的楽な月に消費させないと、今月みたく廻らない可能性が高くなる、ということだと思います。今回は、前任管理者の問題でお気の毒に思いますが、全ての管理者が、心得ておくべきことではないかと思います。

自分で言うのも何ですが、ベンチマーク性能上は勿論のこと、実使用上も世界最高のソルバーだと思います。ただ、現在、上のレベルで出来る方は、それ程多くはありません。当たり前のスキルとなる日が来ることを望んで止みません。本稿がその一助となれば幸いです。

→本稿での経験を基にトレーニングプロジェクトを作成してみました。リソースが殆どないところでどうやって捻りだすかについて、トレーニングするプロジェクトです。これが出来れば、スケジュールナースを自在に操れる有段者と認定出来ます。

schedule_nurse_practical_training.pdf (nurse-scheduling-software.com)







0 件のコメント:

コメントを投稿