2023年9月30日土曜日

ユーザ勤務表からスケジュールナース予定へのインポート

 顧客仕様を実装するにあたって、最初に行うのは、仕様の検討です。具体的な実装の目安がついたら、次に行うのは、顧客勤務表Excelから、予定へのインポートです。つまり、人力解(Excel)から、予定へインポートする作業です。それには、一部署でしたら、手入力してもよいのですが、多数の部署の場合は、インポートするスクリプトを書きます。

インポートの目的は、

1)初期状態の把握(人力解の達成度把握)

2)実装の検討、確認用

です。

で、インポートしてみると、多数のハード制約違反が見つかるのが普通です。私の理解の誤りも見つかりますが、大半は、お聞きしていた仕様そのものが達成されていないことにあります。

実装にあたっては、本当に達成そのものが難しいものがあります。当然そのような制約は、ソフト制約としますが、例えば、6連勤務の禁止や、明けの後の休み、等、これは当然ハード制約だろう、と思える制約も、時々達成出来ていないことが把握できます。

しかし、多くの達成できていない中でも、達成できている項目があるのも事実です。そういう風に人力勤務表を眺めていると、作成者が何を最重要視しているかが、判るときもあります。

お伝えしたいのは、多くの労力を要した勤務表作りの経験は、スケジュールナースにおいて無用ということではありません。むしろ、必要なことなのではないか? とも思います。何が大変か?という経験は、ほぼそのままスケジュールナースのエンジンでも、同じように大変なことなのです。

<インポートスクリプト例>


import os
import ctypes
import win32gui, win32con


def get_open_file_name(title):
    filter='xlsx\0*.xlsx\0'
    customfilter='Other file types\0*.*\0'
    fname, customfilter, flags=win32gui.GetOpenFileNameW(
    InitialDir=project_file_path, 
    Flags=win32con.OFN_ALLOWMULTISELECT|win32con.OFN_EXPLORER,
    File='', DefExt='xlsx',
    Title=title,#'Excel予定シートを開く',
    Filter=filter,
    CustomFilter=customfilter,
    FilterIndex=0)
    print ('読み込みファイル名:', repr(fname))
    print(fname,flags)
    return str(fname)

def output_question():
    MessageBox = ctypes.windll.user32.MessageBoxW
    res=MessageBox(HWND, 'スタッフ希望を入力しますか?', '人力解全体を出力しますか?', 3)
    print(res)
    if res==7 or res==2:##いいえ、キャンセル
        return False
    return True

def post_main():
    
    #import pdb
    #pdb.set_trace()
    print('\n\n*********ポスト処理を実行中です。*************\n')
    import win32com.client#pywin32をインポート

#すでにExcelが起動されている場合はそのタスクが使われる
#エラー終了するとタスクは残ります
    try :
        xl = win32com.client.Dispatch("Excel.Application")
    except:
        print("can not invoke excel")
        exit()
    #動いている様子を見てみる
    xl.Visible = True
    os.chdir(project_file_path)
    #file=os.path.join(project_file_path,"ex1.xlsx")
    #file.replace("/","\\")
    file=get_open_file_name("人力解を開く")
    wb=xl.workbooks.Open(file)

# Excelシートオブジェクト
    ws = wb.Worksheets(1)
 
    # 指定したシートを選択
    # Select()の使用前にシートのActivate()が必要
    ws.Activate()
    #v=ws.Range("A3").Value
    #print(v)
    wk = ws.UsedRange 		# 使用範囲を取得
    columns = wk.Columns.Count	# 行数
    rows = wk.Rows.Count		# 列数
    cells = wk.Value
    days=0
    day_list=[]
    for col in range(0,columns):
        v=cells[0][col]#,colws.Cells(1,col).Value
        if v!=None:
            days+=1
            day_list.append(v)
            #print(v,v.year,v.month, v.day)
    
    print('Days',days)
    name_list=[]
    data_list=[]
    preferred_list=[]
    for row in range(3,1000,3):
        v=ws.Cells(row,1).Value
        if v !=None:
            print(v)
            name_list.append(v)
            list=[]
            plist=[]
            for col in range(2,2+days):
                v=ws.Cells(row+2,col).Value
                list.append(v)
                v=ws.Cells(row+1,col).Interior.ColorIndex
                plist.append(v)
            data_list.append(list)
            preferred_list.append(plist)
        else:
            break
    wb.Close()
    print("persons=",len(name_list),len(data_list))
    print(data_list)
    print(preferred_list)
    output_preferred_schedule=output_question()
    file=get_open_file_name("書き込みする予定ファイルを選択")
    wb=xl.workbooks.Open(file)

# Excelシートオブジェクト
    ws = xl.Worksheets(1)
 
    # 指定したシートを選択
    # Select()の使用前にシートのActivate()が必要
    ws.Activate()
    start_col=0
    for col in range(2,100):
        v=ws.Cells(2,col).Text
        #print(v)
        if v!=None and v=="1":
            start_col=col
            break
    print(start_col)
    start_row=4
    wk = ws.UsedRange 		# 使用範囲を取得
    columns = wk.Columns.Count	# 行数
    rows = wk.Rows.Count	
    for r in range(rows+1):#len(name_list)):
        name=ws.Cells(r+start_row,1).Value
        processed=False
        for k in range(len(name_list)):
            if name==name_list[k]:
                processed=True
                for c in range(days):
                #print(r,c)
                    if output_preferred_schedule:
                        if preferred_list[r][c]>0:
                            ws.Cells(r+start_row,c+start_col).Value=data_list[k][c]
                    else:
                        ws.Cells(r+start_row,c+start_col).Value=data_list[k][c]
        if not processed:
            for c in range(days):
                ws.Cells(r+start_row,c+start_col).Value=''#clear

    wb.Save()
    wb.Close()
    xl.Quit()

post_main()

2023年9月28日木曜日

スケジュールナースでの制約設計の考え方

制約設計に携わる方々のためのガイドです。 

1)能力差を知る

対決! 勤務表作成名人 vs 最強エンジン (nurse-scheduling-software.com)

素の能力が違います。どんなに能力に長けていても、最後は、トレードオフとなります。しかし、人のそれと、スケジュールナースのそれとは、全くレベルの異なるものです。スケジュールナースユーザは、物凄く精緻な制約でのトレードオフを行いがちなのですが、初期の能力差を思い出してください。人間には、出来ない次元でのトレードオフになっていると思います。つまり、人間より良い勤務表という意味では、とっくに達成されています。そこに時間をかける意味があるかどうか?自問自答する必要があると思います。

スケジュールナース適用前の人力解の実力を把握しておくことは、以降機会がないと思うので、特に適用前に測定しておくことをお勧めします。

2)稼動時と制約設計時では、考え方が異なる

制約を設計するときは、しっかりと原因解析を行います。ハード制約違反が、ルールの設定ミスを教えてくれることもあるからです。しかし、稼動時は、エラー指摘に従い、入力の修正だけを行い、エラー解析はしません。解析自体が面倒でありスキルを要するので、一般の方が行うには、ハードルが高すぎます。

希望休み数が多い職場が良いとは言えない (nurse-scheduling-software.com)

予定ブランクでは、エラーがない、もしくは殆どない、ということが目指すべき状態です。スケジュールナースの能力を最大に発揮するためです。エラーがない、ということは、未だ余裕があることを意味します。つまり、解空間がまだ広い状態です。どれだけ広いかは、分かりませんが、余裕があることだけは確かです。で、ブランクでも既に余裕がない状態、つまり、エラーがある状態からのスタートは、解空間に余裕がないのですから、残された選択肢もあまりない、という状態からのスタートになってしまいます。

3)制約することは、解空間を狭める。効率の良い制約設計

制約することは、解空間を狭めます。全員の負荷をフラットにすることも解空間を狭めます。

制約は出来るだけ少ない方が良いのです。

例えば、多くの職場で共通にある要望は、夜勤後の2連休を出来るだけ増やす、ということです。これに関連してのユーザから要求を多々頂くのですが、却ってその達成を難しくする制約も含まれていることがあります。

https://schedule-nurse.blogspot.com/2023/09/blog-post_5.html

一般に、

■行パターンの長い制約

■==制約

■プリセプタプリセプティ・会議

は、重い制約となります。(計算リソース負荷が重い制約と、解空間を極端に狭める制約と2種類あります。計算リソースを食う制約を実装すると解空間はそれほど狭めていないはずなのに、求解性能が落ちます。ソフト制約も広くはこの類になります。上二つは、計算リソースを食う制約、最後の一つは、明らかに解空間を狭める制約です。)

また、ギチギチに負荷分散すれば、まともに解が出なくなります。負荷分散を適度に緩めつつ、2連休達成を阻害する制約を、実装しないようにします。制約が多くなれば、難しくなるからです。多くの細かい制約を実装し、達成することは、Primary制約、夜勤後の2連休の達成を難しくします。Primary要件を達成した上での「もしも可能ならば」制約なのか? それとも、Primary要件よりも優先すべきなのか、を意識するようにしましょう。(往々にしてあるのは、多くの細かな制約を実現しようとして、Primary制約の方の達成度が落ちるという事象です。)

ユーザ要求の全てを満たせなくても良しとしましょう。1)で見たように、既にスケジュールナースの解は、人のそれを遥かに上回る精度と品質を同時に達成しています。




2023年9月23日土曜日

放射線技師の勤務表

 放射線技師の勤務表 (nurse-scheduling-software.com)

ユーザさまのプロジェクトを最近のスタイルに変更し一般化の処置を施したプロジェクトになります。手順は、スタッフ名を変更し、スタッフ毎のシフトと、予定を元のプロジェクトからコピペします。

前は、Pythonで書くしかなかったものも今は、GUIでかなり書けます。看護師、介護士に限らず、今は、殆どのプロジェクトがGUIだけで書けると思います。

IVR,CT,MRI,RI等の専門用語だらけのプロジェクトですが、見る人が見ると判ると思います。

2023年9月22日金曜日

書店のシフト最適化(パート・アルバイトのシフト最適化)

 書店のシフト最適化 (nurse-scheduling-software.com)

南山大学の学生の卒論を題材にしたプロジェクトです。実用性まで今一歩という感じですが、

似たようなプロジェクト作成の参考にはなろうかと思います。

スケジュールナースは、最も難しいナーススケジューリング問題を専門にしているので、こうした分野のプロジェクトは、あまりないのですが、それでもこうした要求は時折あります。いずれにせよ、この種の設定で、他のソフトが出来て、スケジュールナースが出来ない事例は考えられません。逆の事例は、沢山あると思います。


書店のシフト?と思いきや、意外にこうしたシフトは多いので、対応ソフトは激戦区です。

ところで、書店のシフトは奥深いようです。

超書店員によるシフトの作成方法【Part1】 │ 超書店員 (bookseller.work)

2023年9月21日木曜日

医師の働き方改革による医師当直表アップデート

 医師の働き方改革による医師当直表アップデート (nurse-scheduling-software.com)

この勤務表は、最高難度に属します。とても難しいです。今後さらにアップデートが予想されます。

それは、ともかくも、看護師や、介護士も働き方改革が必要ではないでしょうか?


2023年9月20日水曜日

勤務表作成名人vs最強エンジンの補足説明

 対決! 勤務表作成名人 vs 最強エンジン (nurse-scheduling-software.com)

スケジュールナースの目標は、二つあり、一つ目は、娘の前職のような、人力作成による無茶苦茶なシフトパターンを一掃することです。

二つ目は、妻のように、病院備え付けのソフトがありながら、人力作成せざるを得なかったような実力を伴わないソフトを一掃することです。

究極的にはDefact Standardにしたいと思っています。

そのために、個人で使える価格にしております。よろしくお願いします。

2023年9月19日火曜日

2023年9月17日日曜日

予定ラベルの順番検討

 検討を行いましたが、構造的な大変更が必要となること判り、断念せざるを得ない、と判断しました。

代わりに、数字KEYもしくは、ファンクションKEYのバインドを実装しようと思います。予定ラベルの順番変更に比べれば、設計工数は、微々たるものです。

設計途中なので、目処がついたところで、再度報告します。

=>https://schedule-nurse.blogspot.com/2023/11/blog-post.html

申し訳ありません。

2023年9月16日土曜日

「手術:外来病棟属性シフト名が重複」の表示エラーになります。

 今月のアップデートで、シフト名と、グループ属性要素の重複を許さないような仕様変更を行いました。その関係でエラーが生じています。

申し訳ありません。プロジェクトをサポートにお送り頂ければ修正してお返しします。

実インスタンスで厳密解を阻んでいる要因

<ナーススケジューリング問題は終わっていない>

塾講師配置問題の最適化 - Qiita

実世界のインスタンスで、Reasonableな時間内に厳密解を示せることが最終目標ですが、未だ道半ばという認識です。

スケジュールナースが殆どのベンチマークテストで、厳密解を示してきたのに対して、実務インスタンスでは、そうなっていないのは、ペア制約の有無にあります。

ベンチマークテスト→ペア制約がない

実務インスタンス→ペア制約の記述がある。感覚的には、5割以上のプロジェクトで記述がある

<アルゴリズムの要因>

Defaultのアルゴリズムでも、厳密解を出せる場合があります。UB=0のときは、いうまでもなく厳密解です。そしてエラーの数が数個レベル以下のときも、厳密解を出せる場合もあります。しかし、その場面は、多くはなく、大抵の場合、ソフトタイムアウトを待って処理終了となるでしょう。タイムアウトを待って処理終了としているので、厳密解ではありません。Defaultアルゴリズムが厳密解を出せるのは、限られているということです。Defaultアルゴリズムが、得意なのは、AND,OR,NOT等のboolean operationです。数を数えることも出来ますが、それは、コンピュータが数を数えるのと同じ原理で数を数えるしかありません。数を数えるのは、得意ではありません。最も困難なのは、掛け算です。定数との掛け算も容易ではありません。


<数理ソルバ>

エラーが多いときは、数理ソルバに利があります。そこで、アルゴリズム3,4の登場となります。数理ソルバは、線形ソルバを基礎にしています。線形ソルバが出来るのは、定数x変数と、変数同士の足し算(引き算)のみです。変数同士の掛け算は、出来ません。

<線形ソルバは、And OR演算は不得意>

一般的には、AND OR オペレーションは、線形的ではありません。なので、AND/ORで表現される ペア制約は、相性がよくありません。

 実インスタンスで数理ソルバの厳密解を阻んでいる要因は、ペア制約にあります。ペア制約は、「禁止」と「AならばB」の二つがありますが、問題は、「AならばB」にあります。

逆に言えば、ペア制約の「AならばB」を使っていないプロジェクトでは、アルゴリズム4で、かなりのインスタンスが厳密解を出せると思います。

また、ペア制約があるプロジェクトでもペア制約のチェックを外せば、かなりのプロジェクトが厳密解を出せる筈です。(全部ではありません。整数最適化アプローチへの入門 (ieice.org)のように、小さくても難しい問題は存在します。)

つまり、実インスタンスでスケジュールナースの厳密解を阻んでいる主因は、ペア制約にあります。

<なぜペア禁止は、阻害要因とならないか?>

ペア禁止は、列制約に書き換え可能です。ペア禁止したい集合があったとして、その集合内で、ペア禁止は、二つの同じシフトが無いことなので

ΣX[p][day][shift]<=1

と制約すれば、禁止とすることが出来ます。つまり線形和で表現できます。

<列制約は、線形和である>

列制約の表現は、全て線形和で表現できます。禁止にしろ強制にしろ、

Σa[i]X[i] =b[lower:upper]

という線形和形式で表現できます。

<AならばBは、線形には表現できない>

ここで、ペア禁止に戻ると、AならばBは、単純な線形和では表現できません。

つまり、線形和で表現出来ない部分が、複雑にしているとも言えます。この複雑にしている部分を、線形和で表現するというモデリング変更を行えば、普通の線形演算のみで構成することが出来ます。

<モデリングを線形和形式に変更する>

そこで、ペア制約も線形和形式でモデリングすることを考えます。この辺の話は、Integer Programming と呼ばれ、アカデミックのようでいて、ノウハウのようでもあり、不思議なトリックの世界です。全てを線形トリックに変換できるとは思わないのですが、考え方変更で、かなりの部分を線形和形式にすることができます。で、線形和形式に全てできたときに、厳密解を得る公算がかなり高まります。

<まとめ>

■ソフトエラーが多数のとき、数理ソルバに利がある

■数理ソルバは、線形ソルバを基礎に置く。線形オペレーションが得意

■列制約は、線形である

■ペア制約も、線形にモデリングすることによって、不得意部を無くす⇒得意演算のみに出来る

■ペア制約を入れ込んだベンチマークにすべき。⇒アカデミック領域で、ベンチマークテスト開発、提案



2023年9月15日金曜日

シフト予定の順番について(質問と回答)

 Q1.希望(シフト予定入力)の入力時、上にシフト内容が出てきますが、その内容の並び替えができれば楽になるのになと思いながら使用させていただいてます。

順番(シフト定義)の並び替えをしましても、順番が変わることはあるのですがうまく並び替えができません。

可能な方法はありますか?

Ans.

シフトの定義順に並びます。しかし、別名ラベルについては、コントロールすることは現状できません。また、シフト集合、その他オブジェクトについても現状コントロール出来ません。

10月終わり、または11月終わりのリリースで、改善を行うべく検討を行います。検討前ですので、必ず実装するとは言えないのですが、実装すべく検討します。=>検討の結果、実装しないことにしました。

なお、シフトの順番変更について、本稿の最後に方法を書いています。


Q2.またシフト予定入力の際にショートカットキー(ファンクションキーや数字キーでの入力)が使用できれば・・・と思うのですが機能としてあったり、実装は可能でしょうか…?

Ans.今回、実装は見送りたいと思います。⇒Q1を実装しないので、代替として実装を予定しています。詳細は続報をご覧ください。=>

https://schedule-nurse.blogspot.com/2023/11/blog-post.html

理由は、以下の通りです。

■実装の難易度が高い

■ユーザさまによっては、数十ものラベルを使用されている方がおられるので、なんらかの代表ラベルだけの対応となり、一般的な使用法にはなりにくい

■他の操作への影響があり、誤操作を招く可能性がある

なお、今後の参考として、他のアプリ等で参考になる事例があれば、教えてください。


<現状でのラベル順番>

次の通りです。

■シフトラベル →(別名ラベル群)

■シフト集合ラベル

■その他オブジェクト群のラベル



<シフトのオーダ変更の仕方>

1)順番を変更したいシフトのラインを選択します。


2)もう一度No.列のところをクリックしてアンダーバーを出現させます。



3)そのままアンダーバーをドラッグして目的のところで、離します。



4)設定ボタンを押します。

5)プロジェクトを保存します。

6)予定シフト画面


2023年9月14日木曜日

Kindle本unlimitedを解除

 諸般の事情により解除しました。1250円での販売になります。

Kindle Unlimitedで購入済みの方は、そのままご使用になれます。

2023年9月13日水曜日

Youtube紹介でずっと無料に(しかもプロジェクト作成付き)

 スケジュールナースをYoutubeで紹介してくれた人に買い切り版、プロジェクト作成付き(11万円相当)をプレゼントします。


2023年度中限定です。お急ぎください。

Youtube記事の内容は限定しませんが、スケジュールナースの圧倒的なパワーを皆さんに知っていただき、日本から理不尽なシフトパターンを一掃したいと思っています。


御問い合わせはサポートまで。


2023年9月12日火曜日

介護施設による違いー阻害しているのは人だった

 介護施設で介護士をやっている娘が転職をしました。転職前後の両方とも自動勤務ソフトは使っていません。どちらも人力解ではありますが、明らかな差があります。

<作成速度>

前:作るのが遅い。2週間位かけて作っている

後:作るのが早い。2-3日内に作っている。

<作成者の夜勤>

前:0

後: 3回入っている

<トンデモパターン>

前:トンデモシフトパターンがある。7日間に夜勤3回があったことがある。遅→早パターンがときどきある

後:なし

<作成後のフォロー>

前:なし。ときどき、予告なく予定を変えられる

後:希望休みが3日がフルに入っていないと、入っていないけどいいの?と聞いてくれる


ということで、人力にしても全く違うことが分かります。

前者は、勤務表を作ること自体が、仕事の目的になっています。しかも、自分では、夜勤も早番も一切しませんでした。本来ならこのような上司の上司が対処すべきなのですが、施設の体質なのでしょう。3年間変わることはありませんでした。(退職者も多く3年間の間に職員は殆ど入れ替わりました。)


後者は、自分でも夜勤をしており、希望休みが足りていないときは、自分の予定を替えても、スタッフに寄り添う姿勢が見られます。

夜勤要員の人数の違いはあるかと思います。しかし、そうした施設による違いよりも上司である人の違いが決定的であると思います。

この日本から理不尽なシフトを一掃したいとの思いで、破格設定にしているのですが、上の事象を考えると、必要なのは、スケジュールナースではなくて、前者のような上司の一掃であるという、皮肉の結果になってしまいました。前者は、勤務表を作ることが主な仕事なので、スケジュールナースがあると仕事が無くなってしまいます。なので「つくりたい勤務表が自動で作れます!」アピールをしても響くはずがありません。

ともあれ、後者のような方には、自身が行いたいと考える勤務をコンピュータ上で素早く実現して空いた時間を他の仕事に振り分けていただけたら、と思います。

日本のようにシフト16hと言う国は、知りません。少なくとも欧米では、このような過酷なシフトは法律で規制され、存在しません。大学で介護福祉を学んでいながら、基本給は15万位でした。介護は、本来、認知症と向き合うため専門知識が必要で、高い専門性と体力、ケア力が必要です。看護師と比べると待遇の面でまだまだ差があります。また欧米とは雲泥の差です。


2023年9月11日月曜日

希望休み数が多い職場が良いとは言えない

 何度も、同じ主張をして申し訳ないのです。

しかし、スケジュールナースでは、人力とは違い、何度でも条件を変えて解が得られるので、より良い着地点を探し出すのは、それほど手間ではないと思います。

希望休み数が多い職場が良いとは言えない (nurse-scheduling-software.com)


2023年9月10日日曜日

ペア制約の検討を開始

 多くのベンチマークでは、厳密解が得られているのに、多くの実務インスタンスで厳密解が得られない理由の主原因はペア制約にあると考えられます。

そこで、ペア制約で厳密解が得られやすいオペレータを追加することを考えています。モデリング方法の変更を意味しますが、等価なモデリングであれば、問題なかろう、と考えています。

具体的な検討作業はこれからであり、上手くいくかどうかも判りません。ナーススケジューリング問題に取り組んで10年、ほぼ完成形に近づいたとおもいますが、そのなかでも最大のやり残した仕事だと思います。

インスタンスの提供をまたお願いするかもしれませんがその際は、よろしくお願いします。


2023年9月9日土曜日

2023年9月8日金曜日

pならばq

 現代の高校生がわからなくなった数学の基本問題 「p⇒(ならば)q」の否定文から考える数学教育(東洋経済オンライン) - Yahoo!ニュース

これを読むと、却って分からなくなる人も多いのではないでしょうか?

何度も書いていますが、A→B=~A|B と覚えてしまうことです。

A|B  |C

----------

0| x  | 1

1 |  0 | 0

1 | 1  | 1

~(A→B)=~(~A |B)=A&~B

従って、「天気がよい」⇒「遠足に行く」の否定は、天気がよい、かつ、遠足に行かないこと、になります。

パターンABで考えるとA→Bまたは、A←Bですから

(~A|B) | (A|~B)なので、

=~((A&~B) &(~A&B))

つまり、定型パターンとなります。



もっとよい説明は次です。P→Qは、集合の包含関係を表しています。

必要条件と十分条件の意味・3つの覚え方・例題 | 高校数学の美しい物語 (manabitimes.jp)

高校数学の美しい物語は、いつもお世話になっています。


2023年9月6日水曜日

子育て制約

 子育て中のスタッフは土日のどちらかを休みにしたい (nurse-scheduling-software.com)

独身の方からは、不公平との声が聞こえてきそうな制約です。しかし、土日の休みを増やすのではなくて、諦めてもらっている部分もある、ということを理解してもらうことも必要ではないでしょうか?

さて、技術の方の話ですが、毎度のドモルガンの定理で、良く使います。

A|B=~(~A&~B)

パターンは、AND形式の一択なので、&で表現する必要があります。シフトのパターンは、任意のNOT=チェックマーク で表現できます。また~()の~は、禁止と解釈できます。なので、次のようにパターン禁止でも実現できます。

しかし、この場合は、1回でもペナルティが入ってしまいます。今回のように1回までは、ペナルティとしない(あってもよい)としたい場合は、


パターン禁止ではなく、最大ー最小の最大を規制することになります。


2023年9月5日火曜日

実装しない制約

 顧客の要求を全て実装する訳ではありません。

スケジュールナースは、制約で解を求めるシステムですが、制約には、良い制約と悪い制約があります。良い制約システムとは、効率の良い制約で、求める解に、少ない制約で解が得られるシステムです。反対に悪い制約システムとは、効率の悪い制約で、求める解に、多大な制約リソースを使いそれでいて、中々求める解に到達しないシステムです。

様々な制約を実装してきて、必ずしも、顧客の要求全てを実装することが、効率良く、求める解に到達することではない、ということがあります。

効率の悪い制約とは、どのようなものがあるでしょうか?

例1 夜勤のペア組を全て異なるものしたい

仮にこれを実装したとして、どれだけ求める解に近づけるか? ということが視点としてあります。例えば、HCUでは、4:1であり、16床のとき、4人、24床のとき夜勤6人が常に必要となります。ICUは、2:1であり16床のとき、8人、24床のとき夜勤12人が常に(日勤、ロング日勤、入り、明けに関係なく)必要となります。

全て異なることを制約するとなると、HCU夜勤人数は、通常3人/夜勤要員24人なので、通常だと48人必要になります。なので、その組み合わせ総数は、48C6となります。

それが、一月(31日)に渡って一緒にならないことを保証するには、48C6*31の計算項が必要になります。380416872がその総数です。多大な計算リソースが必要となり、実際的には破綻してしまいます。

もう一つの視点は、効果です。多くの場合、解を見ていて、まず、目に付くのは、スタッフ間の夜勤数のばらつきだったり、2連休の数だったり、各スタッフの夜勤の集中度合いだったりするのが常です。

申し上げているのは、そういう主制約をまず実装して、それでも余裕があるならば、さらに制約を追加することも意味がありますが、そうではなく、それすら達成していない状態で、実装したとしても殆ど意味がないばかりか、主制約の実現を邪魔しかねない

ということです。この制約の場合、計算リソースを馬鹿食いするだけでなく、主制約の実現を邪魔する制約となる可能性が高い

ということが言えます。それならば、最初から実装しない方が良いのです。

制約が効率の良い制約か、そうでないかは、実装を検討してみないと判りませんし、経験を積まないと見通しを得るのは難しいです。

一言で言えば、「労多くして益なし」制約は実装しません。

効率の悪い制約例は、Kindle本でも述べているので参考にしてください。



    







2023年9月4日月曜日

育児部分休業

 勘違いしていたのですが、育児休業と育児部分休業は違います。

育児部分休業の場合は、勤務時間が短縮になります。なので、殆どの取得者は、早く帰ることを選択するみたいです。

新スタイルでは、これをスタッフ毎のシフトで設定しています。

公休制約が異なる場合のみスタッフプロパティシートの設定が必要になってきます。



2023年9月3日日曜日

長期休みでない

 どのような組織であっても、育児休暇、産休等で、長期離脱するスタッフはいます。で、そのようなスタッフの予定は、育、産等のラベルで埋めてしまいますが、その際に、通常制約と相容れず、ハードエラーとなってしまいます。

戻って来たときのスタッフプロパティシート設定は、覚えておきたいし、ハードエラーはなんとかしたいし、という状況での設定の仕方です。

長期休み者は、ラベルで埋めてしまいます。


長期休みのプロパティを設定します。その他の設定はそのまま残しておきます。

制約時は、グループ設定を考慮します。6日内に必ず公休が含まれないといけない、という設定ですが、長期休み以外の人が対象にすることによって、育児休暇で埋められた予定は、対象外となります。

その他の制約も同様にグループプロパティを考慮します。

グループ集合で、欲しい集合を定義します。


長期休みのスタッフが戻ってきたら、長期休みプロパティをクリアにすればよいです。また、現在長期休みのいない職場でも、将来必ず長期休みになるスタッフは出てきますから、そのような制約にしておくことがロバストな(外乱に強い)勤務表になります。




2023年9月2日土曜日

新しい記述スタイル

 介護施設のシフト勤務表のつくりかた (nurse-scheduling-software.com)

積極的にスタッフ毎のシフトとタスク集合を集合記述に使って記述します。

これを使うと、個別にシフトとタスクを禁止する記述が不要になります。


さらに、このグループ集合を使って、制約します。

月が変わると、スタッフ毎のシフトタスクを変更する場合もありますが、従来だと、先月部でハードエラーが生じることがありました。それが、オプションをEnableすることによって、Conflict部は予定がソフト制約になるので、ハードエラーが生じることはなくなります。
今後の記述は、全てこのスタイルを推奨していきます。従来スタイルも引き続きサポートしているので、記述変更する必要はありません。

なお、上記記事を動画にしてプロモーション動画をつくる予定です。


2023年9月1日金曜日

AUG282023ビルド版配信中

 昨日の時点で、私のPCのうち3/4台が新しい版に置き換わっていたので、おそらく、今週中には、配信が完了すると思います。完了後は、制約FAQSのサンプルもダウンロード可能になるのでご利用ください。

追加機能・Notes

1) タスクカウント

https://www.nurse-scheduling-software.com/japanese/manuals/user_manuals/chapter10#task_count

https://schedule-nurse.blogspot.com/2023/08/blog-post_20.html

https://schedule-nurse.blogspot.com/2023/08/blog-post_23.html

時間割作成問題タスク版 (nurse-scheduling-software.com)

2) リフレッシュ

3) Group集合名にスタッフプロパティのシフトとタスクを追加

https://schedule-nurse.blogspot.com/2023/08/blog-post_19.html

https://schedule-nurse.blogspot.com/2023/09/blog-post_72.html

4) スタッフプロパティのシフトとタスク 先月部の矛盾する予定をソフト制約化

https://schedule-nurse.blogspot.com/2023/08/blog-post_18.html

https://schedule-nurse.blogspot.com/2023/08/blog-post_17.html

介護施設のシフト勤務表のつくりかた (nurse-scheduling-software.com)

5)フェーズパターンのNOT禁止

https://schedule-nurse.blogspot.com/2023/08/not.html