2024年11月7日木曜日

Q.新人を夜勤人数から除きたい・Aチーム・Bチーム共新人以外で1名夜勤にするには?

 Ans.まず、グループ定義で「新人属性」を定義します。新人属性の一要素として「新人」を定義します。

スタッフ定義に戻って、「新人」に相当するスタッフは、誰なのか分かるように、「新人」で指定します。


<欲しい集合は、グループ集合で作成>
欲しいのは、「新人以外」です。欲しい集合は、グループ集合で作成します。
「新人以外」が出来上がると、「Aチーム」と「新人以外」のANDを取れば、「Aチームの新人以外集合」が出来ます。このようにして任意の欲しい集合を作成できます。グループ集合名をクリックすると当該集合のスタッフ名が下図の下の方にある(図範囲外にある)ブロック上に表示されるので、確認してください。

後は、出来上がった集合を選択すればよいだけです。ここでも、マウス中ボタンを押すと、
集合が表示されるので、確認してください。

欲しい集合は、一つづつ、演算結果を確認しながら作成できます。最終的には、上の制約にあてはめるのですが、そこでもマウス中ボタンで集合を確認することが重要です。

自分が欲しい集合は、演算子を使って作成していきます。演算子は、「でない」、「または」、「かつ」の3種類しかありません。このどれかを使えば、必ず欲しい集合が作成できます。作成過程からスタッフ集合が表示されるので、どなたでも必ず出来るようになります。慣れです。自分て手を動かしてやってみることが何よりも大事です。


2024年11月6日水曜日

GOOGLE OR-TOOLS PDLPを評価

 First Orderのリニアソルバは、前にも評価しました。HIGHS版では、PDLPのGPU版もあるのですが、Google OR-TOOLS版では、また別な改善がされているということなので評価してみました。

Scaling up linear programming with PDLP

が、残念なことに、「収束速度、精度から言って、問題がある」、INRC2や、SchedulingBenchmarksの記録更新用途には、使用に耐えないという結論に達しました。問題の性質上、Barrior Solver(内点法)によるソルバが有効である、というのは分かっていて、HIGHSの改善版

Funding for the IPM solver and beyond

を待っていたのですが、一向に出る気配がないので諦めてCOPTに依頼することにしました。

NEOSサーバ上のCOPTは、Simplexなので遅いです。CLPと大差ありません。

しかし内点法によるMittlemanBenchmarkによれば、圧倒的に1位です。

plato.asu.edu/ftp/lpfeas.html



2024年11月4日月曜日

Q.出来れば、土日に2連休を1回取得したい

 Ans. 次のように、休日の集合で2連休パターンを作り、パターン最初の曜日を「土」にします。最小を1としてソフト制約にすれば、「出来れば1回以上」になります。

これだけでOKです。


<「出来れば、土日2連休」は、「明け後なるべく2連休」と深く関わっている>

ちなみに、この制約は、「明けの後はなるべく2連休」という制約と関係があり、この制約追加によって、「明けの後はなるべく2連休」制約の実現が難しくなります。

下図は、その様子です。土日休み1回以上が全スタッフ達成しているのに対して、「明けの後の2連休が、かなりの部分出来ていません。スタッフによっては、4になっているところがありますが、これは、4回エラーつまり、夜勤4回も2連休ではなかった、ということになります。



<明け後2連休の不出来は、埋め込み予定数と深い関係がある>

一方、予定のソフト制約の重みを7⇒1にしてみた様子が次です。こちらの方は、殆ど出来ていることになります。ほぼ毎回夜勤で2連休を達成していることがお判りでしょう。



この原因というかカラクリは、予定の入れすぎにあります。茶色の枠があるものがソフト予定化したセルです。予定の重みが7だったときは、予定変更は1か所だけでした。しかし、
重みを7⇒1にしたとき、多くのセルで予定変更が行われ、より重い制約である、
「明けの後の2連休」や、「土日2連休」の実現が優先された、ということになります。


<職場の特性を知ろう!>

このように、スケジュールナースでは、求解ページの値をちょっと変えるだけで劇的な変化を直ぐに得ることが出来ます。

変更されたセルは、解上でマーク出来ます。

また、予定上でもマーク出来ます。


この例は、極端ですが、現実のベストな落としどころは、師長の考え方によるのではないでしょうか? 

A■何が何でもスタッフ希望休みを取るか?(予定をハード制約とする)
B■スタッフ希望数を限定して、全員が平等に明けの後の2連休とするか
C■A/Bの中間とするか

スケジュールナースでは、予定の重みを分けること(C方式)を提案していますが、スタッフ希望最優先となったままのところが殆どだと思います。しかし、上記で見たように、その結果は、「明け後の2連休が、かなりの部分出来ない。」をもたらし、その影響が、最悪誰に来るか分からない(明け後2連休が4回出来ないスタッフと、全部出来ているスタッフで不公平が生じています)ことになるのです。

<全体として幸せ方向にベクトル化する>

今まで、そういう事象は、分からなかったし、分かっていたとしても、やりようがなかったので、仕方がなかったと思いますが、
今は、スケジュールナースがあるので、全体がより幸せになるやり方を考えることが出来ます。

師長からみれば、スタッフ分の1であっても、当該スタッフにとっては、そのキツイ勤務は記憶に残るものでしょう。

これは、「機械が考えた結果だから。。」という前に、ご一考してみては如何でしょう?
正解はないと思いますが、今のやりかたよりも改善する可能性はあると思います。





2024年11月2日土曜日

Q.保健所の監査がありxx日の日勤は10名に増員したい

特別の日の設定で、日勤増員日を指定します。CTLキーを押しながら、日にちをクリックすると複数の日を選択できます。


 

一応、今月とANDを取っておきます。この作業は無くても可です。


10名以上は、通常制約7名以上に何ら矛盾しません。上のように包含関係にあります。

なので、単純に追加の記述のみでOKです。(包含関係になければ、単純な追加では済みません。)


必要に応じて、ソフトレベルを変えて、実現の優先度を変えます。

特別の日を高くしたときに、通常日に比べて、10名だけは実現させたい、という意味になりますし、

逆に低くすれば、平日7名キープを優先した上で、
あまり期待しないけれど10名取得できればラッキー、みたいな意味合いになります。

特別の日は、年間カレンダであり、来月になると、空集合になります。なので、何も制約しないという意味になります。来月のメンテは不要で何ら悪さをすることはありません。必要な月だけ再定義すればよいことになります。

このようにメンテナンスフリーの実装にしておくことを心掛けることが肝要です。大体来月になると、制約の中身は覚えていないので。

2024年11月1日金曜日

Q.長日勤と夜勤の数を絶対に同じにするには?

 Ans. ハード制約化すればよいです。

以下は、行制約レベル4でソフト制約されて例で、そのエラー許容量=0とすればよいです。ただし、ハード制約化することによって「解がない」状態になるリスクがあることに注意してください。



2024年10月31日木曜日

Q. 長日勤と夜勤の数を同じにしたい

 Ans.

次のように記述します。


この制約ページは、次のようにすることで出現します。詳しくは、
行制約 の同値カウント制約をご参照ください。



2024年10月30日水曜日

Q 各種勤務時間、年7、年6、年5...等、沢山勤務体系としては存在するのですが、どのように記述すればよいでしょうか?

 Ans. 

どれをシフトにして、どれをその別名とするかは、何を管理対象とするか?に依存します。

例えば、その日の日勤者を何名以上、という風にしたい場合は、日勤という勤務を管理する必要があることになります。その場合、何を日勤と定義するか?は、職場に依存します。フルタイムで働く場合に、日勤とするのは依存ないと思います。時間休が1時間の場合の記号「年7」、時間休が2時間の「年6」を、日勤者のカウントに入れる場合は、日勤の別名にすればよいでしょう。要するに、日勤者としてカウントする勤務をシフト「日勤」に代表させて、別名ラベルを割り当てれば良い訳です。

一方、日勤とはカウントしたくない勤務、例えば「年2」があったとすれば、「研修」というシフトを用意しておいて、その別名として、「年2」としておくとよいでしょう。「研修」を日勤者カウントしないようにしておけば、目的の管理が実現できるでしょう。

このように、何を管理対象とするか?でシフトの定義が変わってきます。例えば、管理単位が「半日」もしくは、「時間」であれば、シフト定義を変える必要があります。

しかし、通常の制約は、日勤者数、夜勤者数といった単純な仕様が殆どだと思いますので、最初に述べた方法で良いと思います。別名を駆使して、シフト状態数を減らすことは、求解速度の面で好ましいです。