自動勤務表ソフトの使いかた 病棟勤務表事例で見る実践的使いこなし術 2016.Mar.17 菅原システムズ.

Presentation on theme: "自動勤務表ソフトの使いかた 病棟勤務表事例で見る実践的使いこなし術 2016.Mar.17 菅原システムズ."— Presentation transcript:

1 自動勤務表ソフトの使いかた 病棟勤務表事例で見る実践的使いこなし術 2016.Mar.17 菅原システムズ

2 自動勤務表は魔法の杖ではありません リソースを超えて配置することはできません。 計算機に教えるルールが整理されていないと失敗します。 何かを優先することは、何かを捨てることです。

3 用語集 ソルバ 答えを出す脳、に相当するソフトウェア 制約 勤務のルール 解 制約を満たす答え ハード制約 必ず満たさないといけない制約。
ソフト制約 出来れば満たしたい制約 オプティマイズ 最適化。エラーの数を1個づつ減らして最小化すること。 リソース 人的資源。使用例）リソースがない➡人がいない 行 横方向の列 列 縦方向の列 充足 制約を満たすこと エラー 失敗。誤差（目標値からのずれ、ペナルティ） ボトルネック その制約を満たすことが難しいために解がない状態 トレードオフ 何かを達成するために別の何かを犠牲にしなければならない関係のこと。

4 用語集２ プロジェクトファイル 制約,予定入力や解を収めたお客様専用設定ファイル通常月毎に名前を変えて作成します。 弊社SE
弊社システムエンジニア ハードエラー 解が存在しないこと（ソルバが矛盾を認識したときに出すエラー） solution1 1番目の答え、solution2は、2番目の答え

5 自分ではなく、他人に理解してもらう文章にしましょう。
計算機にルールを入力する前に 明文化しましょう。 自分ではなく、他人に理解してもらう文章にしましょう。 計算機は、曖昧さが苦手です。 国語が大事

6 コア機能と希望仕様 コア仕様 - 守らなければならない必要最低限、または禁止事項
コア仕様 - 守らなければならない必要最低限、または禁止事項 希望仕様 - 出来たら実現したい、または出来れば避けたい事項 お客さま 計算機入力(菅原システムズ） 希望仕様 ソフト制約 コア仕様 ハード制約 土台が重要！

7 コア仕様記述例（お客さま側で作成していただきます）
コア仕様記述例（お客さま側で作成していただきます）　 2交代　夜勤入明け型 夜勤スタッフ24名 看護師長1名　夜勤しない 夜勤入回数は、4回以下3回以上 夜勤明回数は、4回以下3回以上 夜勤回数制限者が1名、夜勤3回以下2回以上 夜勤回数制限＋土日しか夜勤はできないスタッフが1名 休み日勤は6名 平日日勤者は10名以上 夜勤明けの後は休み 土日連続フリー休み1回以上 6日連続勤務禁止（最大連続勤務は5日まで） 最小夜勤間隔は5日以上 休み日勤は各グループから3人以上

8 希望仕様例（お客さま側で作成していただきます）
希望仕様例（お客さま側で作成していただきます）　 夜勤回数はできるだけ平準化 リーダ回数は平準化 夜勤明けは、基本は休み、早番は禁止、休みが不可なら遅番、遅番も不可なら日勤 ケアスタッフは、出来れば平日3人、最低でも平日2人以上 夜勤は、看護師1人以上

9 制約の入力はお任せください 頂いたコア仕様、希望仕様をベースに細かな点を弊社SEがヒアリングします。 計算機への翻訳作業は弊社SEが行います。

10 改善を経て使えるシステムに 一度の制約入力で済むことはありません。 １００の病棟があるとすると１００の違うルールがあります。 さらに、月々、細かな変更が発生するのは常です。最初の数か月は、勤務表作成日に常駐して変更の仕方をお教えします。サポートなしに、細かい変更については、出来るようにすることが目標です。

11 勤務表は行と列の制約から成ります スタッフ毎の制約：行制約 Day毎制約：列制約

12 望ましい解を得るには、正しいルールを教えてやる必要があります。
制約が適切だと望みの解が得られます 望ましい解を得るには、正しいルールを教えてやる必要があります。

13 制約がないと出鱈目な割り当てとなります。
ソルバは、与えられた制約下で満たす解を探すだけです。制約がないなら、自由に割り振ってよいと解釈します。 数独のルール：各行1-9、各列1-9、各ブロック1-9がダブることなく割り振られること

14 制約に矛盾があるとき解がないと言います 時間内に見つからないときも解がないと言います
オプティマイズ時間。通常10秒、時間を掛けるとき60秒位

15 solution2(解2)が無かったと言っています。言い換えると、解１は求められたことが分かります。
複数解出力で、それ以上別解がないとき solution2(解2)が無かったと言っています。言い換えると、解１は求められたことが分かります。

16 行制約-弊社SEが入力します。 ブランクはハード制約 スタッフ集合指定 ソフト制約　ただし１はリザーブ 最大4個まで可。5は禁止

17 列制約 弊社SEが入力します スタッフ集合指定 1以上1以下=>Onlyone Day集合指定

18 提出のプロジェクトファイルで求解します。

19 解が得られるのでチェックして終了

20 制約はAND集合からなります 解は、赤部集合 夜勤回数4回以下 平日スタッフ7人以上

21 制約が多いとそれだけ解の範囲が狭くなります
夜勤回数4回以下 平日スタッフ7人以上 解集合 休み日勤は6名 明けの後は休み

22 スケジューリングは制約の積み重ね スケジューリングは、制約という積み木の積み重ねです。最後まで倒れずに積み重ねができたときだけ、解があります。 積み重ねは、AND　を意味します。 制約という積み木をどんどん積み上げて行くと、一つ一つの制約は難しくなくても、すべての制約を満たさないといけないので次第に難しくなっていきます。 途中で崩れてしまう（矛盾があると）と、解がありません。

23 部分的にブランクにて可能な別解個数を調べる
途中の解 解が完成しない状態で出して、後はギブアップしてしまうソフトウェアがあります。 しかし、スケジューリング問題は縦と横が複雑に絡んでいて局所部分での別解は殆どないことが普通です。（予定入力制約により解の範囲が狭くなることが原因です。） ⇒結局、全体見直しを余儀なくされます。 部分的にブランクにて可能な別解個数を調べる

24 ハード制約を一つでも満たさないと解がありません。
必ず満たすべき制約です。 必ず満たせる制約である必要もあります。 ハード制約を一つでも満たさないと解がありません。 ハード制約のみの場合、いわば、１か０のデジタル世界です。解があればよし、無ければ＊なにも出力されません。 満たせない可能性のある制約はソフト制約にします。 ＊原因解析機構はあります。

25 ソフト制約 必ず満たす必要はないけれども、できれば満たしたい制約です。 ハード制約は１か０だったのに対して、ソフト制約は、アナログ的です。
個別にみると1か０ですが、全体として総数で見た場合に、できるだけ理想に近づける機構（最適化）が働きます。 ソルバは、望ましくない勤務をエラーとして各エラーを加算し総和数を最小化します。

26 ソフト制約 ７レベルの優先度設定が可能です 重要度 ハード 大
レベル１　（最低　、リザーブ　通常使わない） レベル２ レベル３ レベル４ レベル５ レベル６ レベル７　（最強） ハード ７レベルの優先度設定が可能です 小 重要度 ハード 大 レベル７より強い制約はハード制約になります。重要・基礎的な部分はハード制約とします。制約の大半はハード制約になります。ソフト制約は４レベル程度までをお勧めします。

27 通常意識する必要はありませんが、内部的には更に、レベルが分かれています
ソフト制約 通常意識する必要はありませんが、内部的には更に、レベルが分かれています 予定制約 行制約 列制約 外部制約

28 ソフト制約設定例 弊社SEが入力します 遅番早番禁止 ハード 明早番禁止 明休みが望ましい ソフト制約レベル３ 明日勤は望ましくない
ソフト制約レベル２

29 オプティマイズ中。エラーの数を一個一個減らします。
ソフト制約要因 各ソフト制約は適用チェックボックスで適用することができます。 チェックした制約だけ適用される オプティマイズ中。エラーの数を一個一個減らします。

30 1個のエラー。ハード制約にしていたら解がなかったと言えます。
ソフト制約設定結果　（年休消化） 全員が1回取得のソフト制約に対して殆どの人が年休1回（す）取得出来ている 1個のエラー。ハード制約にしていたら解がなかったと言えます。

31 何を優先するということは、何かを切り捨てること
特にリソースの限界に近いシステムでは、ソフト制約は必須です。 優先度の高い制約は優先的に確保されますが、反対に低い制約は、満足行かない結果になるかもしれません。 何を優先するということは、何かを切り捨てることです。高速求解により、この辺のトレードオフを複数パターン試してみることをお勧めします。 最も望みの結果に近い、優先レベル設定、エラー数設定、求解時間をユーザ様自身で発見してください。

32 複数の人（将来含む）に当てはまる制約 ➡スタッフ毎の設定で変更可能な制約化 その月、そのスタッフだけ ➡ 予定入力
制約化するか予定入力か？ 恒久的な仕様　➡　制約化 複数の人（将来含む）に当てはまる制約　➡スタッフ毎の設定で変更可能な制約化 その月、そのスタッフだけ　➡　予定入力 師長さんへ 準夜：土曜日以外、日～月可。 深夜：水曜　金曜のみ　（日深）可 深準：　準まで連続でできます。第2第3週目に多めにつけてもらえると助かります 土日祝日勤　可能ですが、土曜日は、保育園が6時までなので、日祝を多めにしてもらえると助かります。 制約化は 無理です

33 その個人だけ・その月だけ ⇒制約化するよりも予定入力で入れてしまった方が速い。

34 GUI設定-スタッフ毎の設定（弊社SEが初期設定します）
運用の経過に伴い増えていく傾向があります。 各スタッフ毎の属性を設定 月々の変更はほぼこのページの変更だけで対応 スタッフの諸事情を考慮してます

35 スケジュール開始日・終了日を変更します。 前月末の解を今月に移動します。 解がすぐ出てくることを確認します。 スタッフの休み希望を入力します
毎月の勤務表作成方法 スケジュール開始日・終了日を変更します。 前月末の解を今月に移動します。 解がすぐ出てくることを確認します。 スタッフの休み希望を入力します 時々解があることを確認しながら、制約化されていない予定入力を入力します。 最終リリースで、時間を掛けて求解して終了。 必要に応じて複数解のなかから選びます。 予定がなければ解くのは容易の筈

36 スケジュール開始日の設定 スケジュール期間の設定

37 前月末の解を移動 （解があることを確認をします。）
前月末の解を移動　（解があることを確認をします。） 表示スタート日 スケジュール開始日 前月結果 スケジュール終了日

38 休み希望を入力します。（解があることを確認）

39 看護師長が考える制約外のこだわりを入力します。
さらに、思いを 追加

40 求解して解を得ます。

41 戻した解をブランクにして再編集／再求解も可能
解を入力に戻す 解を全部入力に戻して、マニュアルで気に入らない箇所を修正していくこともできます。（制約化もご検討ください。） 解画面 予定入力編集画面 戻した解をブランクにして再編集／再求解も可能

42 原因解析機構が自動で働きます。指摘された原因を取り除いてください。
解がないとき 原因解析機構が自動で働きます。指摘された原因を取り除いてください。 エラーの要因を列挙します。 エラーの潰し方をナビゲートします。

43 エラーは複数の要因間の矛盾で発生します。
「解がない」格闘を回避する　 崩れた積み木の原因がどこにあるかを調べるのは技術的にも難しい問題です。 原因となる要因を列挙する機構を持っています。通常一つのエラーに対して複数個の要因を持っています。 複数個のエラーがあると列挙された要因も多数に渡り原因を特定して解決するのは難しくなります。 そこで、制約の変更前後で解の存在を確認しながら少しづつ変更を行うようにします。 解があったら上書き保存しましょう。 エラーは複数の要因間の矛盾で発生します。 崩れてしまった原因を探すのは難しい エラー 要因１ 矛盾 要因２ 要因３ エラーが複数あるとなおさら難しくなる

44 予定入力時のエラーの対処　原因の特定 予定入力を全てソフト制約にして解を求めると解が存在するための最小の変更を知ることが出来ます。

45 日勤を準夜にしないと解がないことが分かります
予定変更の最小解を知ることもできます 予定入力と違うところを反転しています。 日勤を準夜にしないと解がないことが分かります

46 予定入力においては、Restore/Undo機能が便利です。入力の巻き戻しが出来ます。
Redo

47 解が気に食わないとき 複数解を見る ソフト制約優先度をいじる 列方向ならペア禁止制約・ペア制約追加を検討 制約を追加する　➡　菅原システムズに依頼、または、自分で直す 解を編集する　➡　最後の手段。　ただし、元の制約を無視した変更になっていることが多いです。それでもよければ良いのですが、ルーチンワークなら制約を見直した方がベターです。

48 ペア禁止・ペア制約 ペア禁止は、あるスタッフとあるスタッフを同じ勤務にしたくないときに使います。経験的に多めでもボトルネックにはならないようです。 ペア制約は、プリセプタ・プリセプティの関係あるいは、会議のように同じ勤務を強制しますが、少数(1組）でもボトルネックになってしまうことが多いようですのでソフト制約とするか期日を指定しましょう。

49 こんな使い方もー勤務希望に優先度をつける
希望が多ければ多いほど、解の空間は狭まり良い解が得にくくなります。 希望数の多い職場ほど、逆にスタッフのQOLを下げる要因になっています。 例えば、絶対に取リたい休み、できれば取りたい休みとして優先度をつければ、相互に利益があるのではないでしょうか？

50 サポート上での経験ーよくある誤解 人間の方が良い勤務表が書ける　➡ある意味正しいですが、ある意味正しくありません。計算機に制約を入力すると否応なく、制約を満たさない答えは排除されます。脳内制約下で出来るのは、(無意識に）ルールを捻じ曲げる（満たさない）からです。計算機は、融通が利きません。このことに慣れるのに時間がかかります。同じ制約下なら、人間に勝ち目はありません。 言葉にできないルールがある　➡そうかもしれません。でもいつも行っているルーチン的な修正ならそれは制約化できるかもしれません。是非サポートまでご相談ください。

51 今までのやり方とは違います 高速求解により、計算機と対話しながら作り上げていくことが初めて可能になりました。スタッフの諸事情や看護師長の思いをこれまでより反映することがことが出来ます。 もし、いつも行っているルーチン作業があったならそれは制約化、すなわち自動化できる可能性があります。サポートまでご相談ください。 自動スケジューリングの肝は、制約化にあります。この事を理解して活用することが勤務表という仕事の設計書を優れたものにする極意です。

52 道具として使いこなす 今まで人間が出来なかった筈の制約は、いつの間にかできることがあたり前のようになってきます。しかし、計算機が行っているのは、限りある人的資源を最適利用するだけで、魔法の杖ではありません。資源には限界があるので、あるところでそれ以上良い解が得られないということになります。計算機が得意なのは与えられた制約下で解を素早く見つけ出すことだけです。 一方、計算機に何が重要で何が重要ではないかを教えられるのは人間しかいません。また、出てきた複数の結果の良し悪しを判断できるのも看護師長しかいません。道具を使いこなして頂ければ、開発者として望外の喜びです。 　ご清聴ありがとうございました。