Ans.
固定した勤務で、平日のみに出勤することが決まっているならば、スタッフに入れない方がよいです。スケジュールナースは、決まっていないシフトを割り当てるソフトです。
対象は出来る限り少なくした方が、求解速度は上がるので、上記目的外のスタッフは、下のようにチェックを外すか、行削除して、当該プロジェクトの対象スタッフではなくします。
2024年11月20日水曜日
2024年11月19日火曜日
Q.ペア制約名は、フルネームじゃなくて名字だけでもいいんですか？
Ans. 制約名は、何であってもよいです。スタッフ名である必要はなく、例えば、AとBとかでもOKです。他の制約と区別できることが唯一の条件です。
ですのでユニークな名前にしてください。
例
プリセプタプリセプティで、スタッフ名12とスタッフ名13が、常にペアになって夜勤を行う例の記述です。「スタッフ名12」と「スタッフ名13」という固有名詞が含まれている必要はありません。制約名は、制約を特定するための目的のために存在するので、自由に名前をつけてください。名前がユニークでさえあれば、空白以外の何であってもOKです。
＜ペア制約について＞
現在、上記のように固有名を用いて記述は可能ですが、記述することは推奨しておりません。退職等でスタッフがいなくなるとエラーとなるためです。
GitHUBの挙げている例の通り、
スタッフプロパティシートは毎月メンテすると思いますので、忘れることは少ないと思います。
2024年11月18日月曜日
Q .解約手続きの流れを教えて頂けますか？
Ans.
マイクロソフトアカウントにログインして、
サブスクを停止してください。来月から課金されなくなります。
https://www.nurse-scheduling-software.com/japanese/service/pausing_subscription/
ご利用ありがとうございました。
2024年11月17日日曜日
Q.医師当直表 医師間でばらつきが大きいようなんですが..
Q.下図、宿日直回数と休日拘束数とで、医師間のばらつきがいつもより大きいような気がします。何故でしょう？
Ans. １２月勤務表では、１月年始も取り込んで作成している影響だと思います。（物理的要因です。）
試しに、制約最終日を１２月３１日に変更してみました。
上図をよく見比べると、医師間のバラつきは、
制約最終日 宿日直数 休日拘束数
１月５日版 2－４ 4－6
１2月31日版 0－2 2－4
となっており、バラつき（偏差＝２）で変わっていません。全体が多くなっている傾向になっているだけ、ということです。これは、制約日数が5日だけ増えている影響とみることが出来ます。
この勤務表のスタッフプロパティシートは、制約区間全体に効いてくるので、適宜最適値に調整してください。
変更前
変更後
変更後の結果
エラーが殆ど無くなったので求解時間も数秒に短くなりました。
また偏差も2以下に収まっています。
休日の丸1日の宿日直、あるいは休日拘束1回に対してカウントは、２です。つまり、回数に直すと1回の偏差となります。この1回の偏差は物理制約による限界です。全員が偏差0とするには、
Σ宿日直％医師数==0
になる必要があります。平たく言うと、端数が0になる必要があります。逆に言えば、全員が偏差0となるには、端数0となるときだけです。
例えば、宿日直コマ数総和40に対して、医師が10人いれば、全員4回で均等にできますが、41の場合は、割り切れず、必ず偏差が１となります。5回行う方が1人だけ生じます。
つまり、1回の偏差が生じるのは物理限界であって、なんら不思議ではありません。
2024年11月15日金曜日
First Order GPU実装
大変、参考になる論文が出ました。
PDLPは、諦めていたのですが、GPU実装を使えば、可能性があることが示されています。最近のGurobiもGPUを使い始めたのは知りませんでした。
Simplex、内点法、FirstOrderの比較考証もされています。Simplexのマルチスレッド化は、LU分解のパラレル化が困難でした。Julian Hall教授の実装もありますが、CPUキャッシュに収まりきれないと性能が出ない問題があります。また、従来IPMにしてもスパースコルスキー分解を上手くGPUに載せるのは、難しいと考えられてきました。
ここにきて、FirstOrderは、激しく性能向上争いが続いていて、ADMMを用いた方法も注目しています。
以上のトレンドを鑑みて、GPUによる実装を検討してみようと思います。（あくまで記録更新用なので、一般の実装には影響しません。ABIP+にせよPDLPにせよ、ユーザにとっては、精度と速度が出れば何でもよいです。）
＜Simplexは必要ないか？＞
依然として必要です。なぜなら、HotStart（WarmStart）によく駆動は、Simplexによるからです。INRC2規模では、Simplexのhoststartによる方が速いのでSimplexは欠かせません。一方、超大規模、SchedulingBenchmarksのInstance23/24規模になると、SimplexはHotstartを使っても無力です。この場合、内点法かFirstOrderによる方法となります。（FirstOrderによるHotStartは、Starandmarkさんの論文にあるのですが、大して効果がなかったような印象が残っています。）
上記論文で使われているGPUは、とんでもなく高価なものですが、上のような背景の私の用途としては、普通の世代落ちしたもので十分効果があるだろう、と見ています。
CUDAが使えるＧＰＵは、以下のページで分かります。
CUDA GPUs - Compute Capability | NVIDIA Developer
とりあえず、GPUを購入して勉強・評価して、COPTを使用するかどうかを判断したいと思います。
AIの流行により、一気に花開いたGPUですが、アークテクチャを見ると、ハードウェアとソフトウェア（コンパイラ技術）の見事なバランス感覚で成り立っており、両分野に精通した人の設計なんだろうな、と思います。CPUでマルチスレッドにするとキャッシュメモリがボトルネックとなり、その部分を分離できるという意味においても一時の流行に終わることがなく、今後も汎用化が加速していくのでないかと推測します。
ZOOMの録画が変わった模様
今まで、ユーザさまのPCにローカルファイルで保存することを推奨してきたのですが、その選択がなくなり、勝手にクラウドに録画される仕様に変更になったみたいです。
で、この録画、AI要約があったり、文字起こしがあったりで、再度見たい箇所を素早く探すことが出来るようです。ダウンロードではなく、パスコードリンクを送ることで、ユーザさまも文字起こし付のサイトで視聴できる、ということのようです。
AI要約は、次のレベルでまだまだ、です。
次は、昨日行ったAI要約です。
--
ミーティング後、ユーザさまにパスコード付きのリンクを私菅原氏とｘｘ氏は、クラウドレコーディングシステムの導入やスタッフの休暇管理、システムにおける制約の重要性について話し合いました。 また、スケジュール変更のプロセス、ソフトウェア制約の使用、スタッフ定義を設定し、過剰と不足を調整することの重要性にも焦点が当てられました。 会話は、新しいシステムの実装、複雑な制約に対応できるシステムの必要性、ソフトウェア制約を維持することの重要性について議論で終わりましたが送れば、ユーザさまの視聴が可能です。
菅原さんとｘｘさんは、Excelの使い方をｘｘさんに教えることに焦点を当てた4時間のセッションを行い、菅原さんが指導や制限事項を提供しました。 セッションは、菅原が後でｘｘにファイルを送ることを約束して終了しました。 両参加者は、このセッションに感謝の意を表しました。
--
プロジェクトファイルが、全く動かない状態からのスタートでした。なので、制約を一から作りこむレクチャを行いました。
■仕様の聞き取り・確認
■頂いたプロジェクトファイルをベースにしながら、一から制約を作りこんでいきました。
■特に留意する点、注意事項など、その都度、質問を受けながら
■全ての実装したい制約を実装
し、その場で、ブランク予定でエラー０まで実装確認を行いました。
知人からの紹介とのことで、「知人のプロジェクトファイルをベースに、サブスクをご契約頂いて著書も購入したけれでも、全くどうすればよいか分からない」
とのことでしたが、出来栄えにご納得頂けたと思います。気づけば４時間程経っていました。OJTで、なおかつプロジェクトファイルが出来上がりました。
勿論、ご自分で一から練習してみるのが最も大事、というお話しはさせていただきました。４時間分の録画はあるので、見たいところや聞き逃したところ等、見返すことが出来、これと併せて、その職場にマッチした最適な学習教材（当該プロジェクトの解説資料５０ページ添付）にもなったと思います。
が、これほど短時間に実装できるスケジュールナースは、
凄いな！スケジュールナース！
と改めて思った次第です。慣れれば最強は疑うところなし、です。
2024年11月14日木曜日
筑波大 繁野麻衣子先生
先生には、RAMP発表の折にお世話になっていて、ORの学術世界を垣間見ることが出来ました。著書も購入しています。
Amazon.co.jp: IT Text 数理最適化 : 久野 誉人, 繁野 麻衣子, 後藤 順哉: 本
この本は、分岐限定法と妥当不等式について解説している殆ど唯一の日本語本だと思います。
ふと巻頭言を見る機会がありました。
-数 理 の 専 門家で ない 人 が ， 対象 を的確 に捉 え，必要 な とこ ろを抽象化 してモ デル を作成する こ とが で きれ ば， コ ン ピ ュ ー タの 性能が一段 と向上 してい る現在で は ， 我 々 の 研 究成果 が応用 され る機会が増す と考え る．誰 もが モ デ リン グの技術を身 に つ け るた め に は ， ど うすれ ば よい か 欲を言 え ぱ ， 数理 的な思 考 をと しない 人 に も対象を整 理 して モ デ リン グの 方向性が わか る よ うなそ ん な指針 を構築 したいと常 日頃考えて い る．
これは、私が常々、感じ考えていることと全く同じであります。ソフトの使い方以前に、考えを整理する術が必要です。
最近ZOOMレクチャを意図的に多くしています。（メール回答で終わらずにZOOMで解説）分からないことが分からない自分にとって、有益な機会であることが多いです。
1年のサポート中、大体が3回程度以下で済みます。プロジェクト作成で、私が生み出したバグもあるし、お客さまの仕様変更もあるし、ですが、その後は、殆どサポートしなくとも運用出来ているようです。
2024年11月13日水曜日
年末年始の実装その３
今回は、実装その３です。
１）制約終了日を１月５日する
２）１２月の公休区間を作成する
従来の「今月」は、制約終了日を年始１月５日としたために、１２月１日ー１月５日が「今月」扱いになってしまいます。このため、公休数区間は、１２月１日－12月３１日となるように新たに定義します。
新たな定義をした集合名が「今月区間」になります。ちゃんと１２月１日から１２月３１日までにマーキングされていますね。これは、スケジュールナースに組み込み済み定義「次月」という集合から作った「次月でない」と従来の「今月」のANDを作ることによって作成しています。これで、メンテナンスフリーとすることが出来ます。（１月勤務表では、空集合です。結果、今月＝＝今月区間と自動的になります）
３）公休数を制約しているところを「今月」⇒「今月区間」に置き換えてやります。
夜勤数については、従来通り「今月」なので、１２月１日ー１月５日区間での夜勤数になることに注意してください。
４）スタッフプロパティシートを調整する
夜勤数は、年始まで含んだ夜勤数になるので、普段より多めに設定する必要があります。
公休数については、普段通り、１２月の公休数を入力します。
５）オプション
以上が基本の枠ですが、多分、年始の各スタッフの夜勤数については制約する必要があるでしょう。
次のその実装例です。
年始分の夜勤回数をスタッフプロパティシートかマクロで制約します。スタッフプロパティシートで行う分には、使わないときに、ブランクにするメンテナンスが必要になります。
次は、マクロで行う例です。
マクロでは、メンテナンスフリーに出来ますが、スタッフ毎の調整が出来ません。
一長一短です。このほかに、出てきた解を予定で調整してしまうのもアリだと思います。
どれを使ってもOKです。自分が分かり易い方法が一番です。
以上３回に渡って年末年始の実装を解説しました。
2024年11月12日火曜日
年末年始３つの実装その２
今回は、実装２です。
この方式は、特殊です。スケジュールナースの実装というよりは、クジの作り方のようなお話です。
前提条件として、以下のような職場の仕様です。
１）年末年始区間が定められており、その期間にｘ回以上の公休を取るように事務局から通達がある。
２）年末年始を除いた公休数は事務局より通達があり定められている。
３）年末年始区間の希望は取らない（取れない）完全にクジで決まる。
え、希望は出せないの？と思うかもしれませが、それについては後述します。
で、クジの作り方です。以下は、クジの説明図です。
勤務するスタッフA-Pまでクジを作ります。クジには、年末年始区間の勤務パターン記されています。このパターンは１）要求も満たすようにつくられています。それを引いたスタッフはそのクジのパターン通りに働かなければなりません。希望があって、働けない場合は、同じスキルレベルのスタッフ間でやり取りして調整することになっています。
このクジは、必要な夜勤数や日勤数が必ず揃うようになっています。（完成した全体パターンをハサミで切り取ってクジにしています）
クジによって、年末年始区間の勤務は完全に決定します。これを１２月・１月の勤務表各々において、予定として取り込めばよい、ということになります。
完全に神様任せでありながら、組織や事務局の要求を完全に満たすという優れた方式だと思います。これなら文句を言われることがありません。「希望不可」という一見トリッキーでありながら、誰からも文句を言われない素晴らしい方法ではないかと思います。
で、この場合、クジで決まった予定をスケジュールナースに入力することでよいので、年末年始に関わる制約を記述する必要はありません。唯一、年末年始を除いたところの公休数は、12月と1月が通常から変わるので、その部分だけ制約を追加する必要があります。
これは以下のように記述しておくとメンテナンスフリーに出来ます。
「特別の日の設定」年末年始を年間カレンダで設定します。
公休区間を定めます。「今月」を変更し「年末でない」「年始でない」のANDにします。
公休の制約期間を「今月」から「公休区間」に変更します。
以上です。
2024年11月11日月曜日
年末年始３つの実装その１
年末年始がやってきました。
そこで、スケジュールナースでの、年末年始の実装をまとめてみたいと思います。年末年始の実装方法としては、3種類あります。
１）通常のプロジェクトファイルを変更せずに、１２月と１月の勤務を各々別につくる（普段のプロジェクトと変わらないが年始希望を考慮して予定を組み込む）
２）年末年始区間は、くじ方式。年末年始外の公休数を別に制約
３）年末月は、年始の希望を含んで制約する
以上の3つです。
早速、第一の方法を説明します。
１）通常のプロジェクトファイルを変更せずに、１２月と１月の勤務を各々別につくる（普段のプロジェクトと変わらないが年始希望を考慮して予定を組み込む）
この場合、特に年末年始に特別な制約を加えることはなく、普段通りに作ります。１２月勤務表を作ったあと直ぐに１月勤務表も作ります。ただし１月勤務表で実際に採用するのは、年始区間のみです。
１）１２月の勤務表を完成させる。決定した解を１月勤務表では予定に送ります。
１月勤務表解を予定に送ります。下は、送られた解ですが、１月６日以降はカットします。
３）１月６日以降は、カットした予定とします。１２月２０日頃に締め切られる１月の希望休み予定を入れて、通常通りの１月勤務表を再度求めることになります。
１２月予定では、１月の年始の希望予定を含んではいません。ソルバは、１月の希望予定を知らないので、１２月年末と１月年始希望休み（希望勤務）が矛盾する可能性があります。
この矛盾がないように、予め年始希望休みを考慮して、１２月に予定を組み込んでおく必要があります。具体的には、行制約の次の３点に留意します。
A）パターン制約
B）夜勤間隔制約
C）連続勤務制約
＜パターン制約の配慮＞
パターン制約とは、決まっているパターンのことです。例えば 夜⇒明⇒休は決まっているでしょう。職場によっては、長夜明休まで決まっているかもしれません。極端な話ですが、１月１日の勤務が明けだとすると、１２月３１日は入りでなければなりません。しかし１月１日の勤務はソルバは分からないので、この場合は、１２月３１日に夜という予定をエントリする必要があります。特に、長夜明が強制される職場である場合、拘束長が長いので注意してください。いずれにしても、スタッフの年始をにらめっこしながら、年始の予定をエントリしていきます。以下の制約をマニュアルで行うということになります。
＜夜勤間隔＞
正月、旦那様の実家に行きたくないので、意図して夜勤を希望する場合もあります。そういう場合は、１月の年始に夜勤が入った場合は、１２月年末は夜勤禁止を入れて、極端に短い間隔を防止する必要があります。これも以下の夜勤間隔制約をマニュアルで実装する、ということになります。
＜連続勤務＞
通常連続勤務は５日間です。上の夜勤もそうですが、長い拘束勤務、例えば長夜明があるとすると、年末から数えて５日を上回ってしまう場合があります。その場合は、年末に休みをエントリして、そのような事態にならないようにします。これも、以下の連続勤務制約をマニュアルで実装する、ということになります。
以上です。
この方式は、年末年始に特別な制約を持ってくるのではなく、通常のプロジェクトファイルを使います。12月末に1月年始予定をみて矛盾がないように予定を入れるのが面倒ですが、マニュアルで作っていた経験があれば、同じことです。「制約をいじるよりは..」
という方にお勧めする方法です。
2024年11月10日日曜日
Q.異動してきたので、1回だけ新人と同じ夜勤体制としたい
Ans.新人は、夜勤者数にカウントしないので、1回だけ異動者は夜勤者数にカウントしなければよい、ということになります。この実装としては、既に、
「新人初回夜勤区間は、新人を含めないで通常夜勤者数を確保したい」
であります。この例と同じようにすればよいですが、今回は、マクロを使わないで実装してみます。
「異動新人」ではなくなった月は、スタッフプロパティシートをメンテナンスすることです。「異動新人」をブランクにし、「異動区間の夜勤回数」をブランクにする必要があります。
また、「異動新人」が入ってきたときは、またそのスタッフに「異動新人」を設定し、「異動区間の夜勤回数」を設定すればよいです。
2024年11月9日土曜日
Q.新人も成長してきたので、夜勤は他スタッフと同じ。ただし..
Q.新人も成長してきたので、夜勤関係は他スタッフと同じとし、新人ではなくしたい。ただし、Aチームから新人以外1名、Bチームから新人以外1名は、残したい。
Ans.成長した新人を準新人と定義します。準新人と新人では、仕様が異なるので、集合を分ける必要があります。そのために、「準新人」を導入します。
ただし、毎年、「新人」⇒「準新人」は、同じように推移すると思いますので、今までの「新人」も残して、各々「新人」「準新人」として動作するように設計します。
「新人属性」に「準新人」を追加します。
制約します。マウス中ボタンで、集合を確認します。以上で変更は完了です。
2024年11月8日金曜日
Q.日勤のみのスタッフが居る
Q.会計年度職員や、妊婦のため、日勤のみにするには？
Ans.「スタッフ毎の設定」で、そのスタッフの日勤以外のシフトのチェックを外します。
下図で、夜勤や明け等出来ない勤務のチェックを外します。
注意点としては、この制約はハード制約であることです。そのため先月部に勤務があるとエラーとなってしまいます。煩わしいので、このエラーを自動で回避するオプションにチェックを入れておきます。（下図参照）
夜勤の設定が入っている場合には、ブランクにします。
最後に、動作確認します。夜勤関係が0であることを確認し終了です。
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位です。以前にCOPTを評価したときは、内点法の実装がなくSimplex Onlyでした。そのときも、この問題は、内点法ソルバの方がフィットしますよ、というアドバイスをもらっていたので、そのときから、一気にトップに駆け上るポテンシャルを秘めていたのだと思います。
2024年11月4日月曜日
Q.出来れば、土日に2連休を１回取得したい
Ans. 次のように、休日の集合で２連休パターンを作り、パターン最初の曜日を「土」にします。最小を１としてソフト制約にすれば、「出来れば１回以上」になります。
＜「出来れば、土日２連休」は、「明け後なるべく２連休」と深く関わっている＞
ちなみに、この制約は、「明けの後はなるべく２連休」という制約と関係があり、この制約追加によって、「明けの後はなるべく２連休」制約の実現が難しくなります。
下図は、その様子です。土日休み１回以上が全スタッフ達成しているのに対して、「明けの後の２連休が、かなりの部分出来ていません。スタッフによっては、４になっているところがありますが、これは、４回エラーつまり、夜勤４回も２連休ではなかった、ということになります。
＜明け後２連休の不出来は、埋め込み予定数と深い関係がある＞
重みを７⇒１にしたとき、多くのセルで予定変更が行われ、より重い制約である、
「明けの後の２連休」や、「土日２連休」の実現が優先された、ということになります。
＜職場の特性を知ろう！＞
＜職場の特性を知ろう！＞
このように、スケジュールナースでは、求解ページの値をちょっと変えるだけで劇的な変化を直ぐに得ることが出来ます。
変更されたセルは、解上でマーク出来ます。
また、予定上でもマーク出来ます。
この例は、極端ですが、現実のベストな落としどころは、師長の考え方によるのではないでしょうか？
A■何が何でもスタッフ希望休みを取るか？（予定をハード制約とする）
B■スタッフ希望数を限定して、全員が平等に明けの後の２連休とするか
C■A/Bの中間とするか
スケジュールナースでは、予定の重みを分けること（C方式）を提案していますが、スタッフ希望最優先となったままのところが殆どだと思います。しかし、上記で見たように、その結果は、「明け後の２連休が、かなりの部分出来ない。」をもたらし、その影響が、最悪誰に来るか分からない（明け後２連休が４回出来ないスタッフと、全部出来ているスタッフで不公平が生じています）ことになるのです。
＜全体として幸せ方向にベクトル化する＞
今まで、そういう事象は、分からなかったし、分かっていたとしても、やりようがなかったので、仕方がなかったと思いますが、
今は、スケジュールナースがあるので、全体がより幸せになるやり方を考えることが出来ます。
師長からみれば、スタッフ分の１であっても、当該スタッフにとっては、そのキツイ勤務は記憶に残るものでしょう。
これは、「機械が考えた結果だから。。」という前に、ご一考してみては如何でしょう？
正解はないと思いますが、今のやりかたよりも改善する可能性はあると思います。
登録:
投稿 (Atom)