- 提案されたシフトとは何ですか： 従業員は「このシフトを好みます」と言い、優先度1から3で自分の希望を示します。
- リクエストはどこに行くのか: すべてのリクエストは、SMSや紙の代わりに、システム内の一つの構造にまとめられ、ヘドネルスが確認できるようになっています。
- 配置はどのように行われるのか: リクエストの配置エンジンは、規則、役割、部門、各シフトの容量を確認し、容量の充足度に基づいて並べ替えることができます。
- 信頼はどこから来るのか: システムはテーブルを埋める際に規則を破らず、完了できないシフトを報告し、配置の理由を説明します。
提案されたシフトとは何か、そしてどの問題を解決するのか？
多くの病院やシフト制の施設では、月は共通の悩みとともに始まります。何十人もの人がさまざまな方法でシフト希望を申請します。ある人はSMSを送り、ある人はメッセンジャーグループに書き込み、ある人は電話で調整し、ある人は紙で提出します。ヘッドナースやシフト担当者は、これらの散在する申請をまとめ、各部署や各役割の規則を覚え、シフトごとの容量を管理し、最終的に部門のカバーを維持しつつ、できる限り個々の希望を尊重する表を作らなければなりません。スタッフの人数が増え、規則が複雑になると、この一見簡単な作業は、些細な変更でもいくつかの部分をやり直さなければならない数日かかるプロセスに変わります。
推奨シフト これは、Accis Pulseシステムでリクエストを登録する主要な二つの方法のうちの一つであり、まさにこの問題のために設計されています。この方法では、スタッフはシステム内で希望する日やシフトを選択し、各選択に対して リクエストの優先度 自分自身を特定します。これらすべてのリクエストは一つの場所に集まります；ヘドナースはそれらを一括して確認し、システムの配置エンジンはプログラム作成時に同じリクエストを計算の基礎として使用します。簡単に言えば、「SMSや紙 ← 手作業での収集 ← 法規の主観的確認 ← 表作成 ← 何度もの修正」という経路の代わりに、「構造化登録 ← 自動集約 ← 法規に基づく確認 ← 配置 ← 管理者承認」という経路が置き換えられます。この方法は包括的ガイドの一部です。 シフト管理 であり、もう一つの方法である 希望シフトと並行して使用されます。、二つの経路がシステムの申請登録を構成します。
優先順位1から3の登録とリクエストを1つの構造にまとめること
提案された方法の核心は「優先順位」の概念です。従業員は、どのシフトを希望するかだけを言うのではなく、各シフトについても述べます。 どれくらい 希望します。製品のドキュメントによると、リクエストには三つの優先レベルが設定されています：優先度1は非常に望ましいことを意味し、優先度2は望ましいことを意味し、優先度3は好ましいことを意味します。このシンプルなランク付けだけで大きな違いを生みます。なぜなら、システムは割り当て時にどのリクエストが個人にとって重要かを理解し、限られた容量に対して複数のリクエストが競合する場合には、この優先度と部門の規則に基づいて決定できるからです。例えば、子供の試験の夜に必ず日勤である必要がある看護師は、その日を優先度1で登録し、単に希望しているだけのシフトは優先度3で指定します。システムは計算の際にこの強度の違いを考慮します。
🎯 優先度1：非常に望ましい
従業員にとって重要なシフトについては、システムはこれらのリクエストにより多くの重みを置きます。
👍 優先度2：望ましい
次の本人の希望する選択肢で、空きがあり、規則に適合する場合にプログラムに反映されます。
📌 優先度 3: 優先的
重要度の低い優先事項は、可能であれば対応されますが、より高い優先事項と矛盾する場合は後回しにされます。
🗂️ リクエストの統合管理
すべてのリクエストは優先度とともに一つの構造にまとめられ、ヘドナーは何十もの散在するメッセージの代わりに、単一のビューを見ることができます。
重要なポイントは、リクエストの集約は単に「まとめる」ことではないということです。各リクエストは個人の身元、役割、関連部署、およびそのシフトに適用されるルールに結びついています。つまり、ある部署で30人がリクエストを提出した場合、ヘドナスは要求リストだけでなく、各リクエストの容量やルールに対する状況も見ることができます。この結びつきこそが、次の段階である配置を可能にするのです。もしあなたの組織の構造がまだ規則化されていない場合は、この記事を参照してください。 シフトの設定 法律に基づいた配置の原則をよりよく理解するのに役立ち、配置後の監督に関する理解のために、記事 シフトコントロール 次の道は勉強です。
容量完了に基づく並べ替えおよび整理エンジン
申請が登録され集まった後、システムの主要な部分の番になります： シフト配置モーターこのエンジンは、登録した人々のリクエストを確認し、プログラム内で定義された規則と収容能力に従ってそれらを配置します。規則とは、管理者が各部署、役割、シフトごとに一度定義したものであり、各シフトの最小・最大人数から役割や性別に基づく収容能力、日・週・月ごとの制限まで含まれます。システムは各リクエストについて、その人物をそのシフトに配置することがこれらすべての条件に適合するかどうかをチェックし、適合する場合にのみ配置を行います。
レイアウトエンジンの注目すべき動作の一つは、 シフトの充足率に基づいてリクエストを並べ替える 定員がほぼいっぱい、または全く空きがないシフトは、まだ多くの空きがあるシフトとは異なる優先順位が与えられます。この作業の論理は明らかです：定員が埋まりかけているシフトはより敏感であり、容量が無駄にならず、潜在的な衝突も早く明確になるように、早めに決定する必要があります。それに対して、空きがあるシフトは、リクエストの変更に対してより柔軟です。この容量中心の並べ替えによって、最終的なスケジュールの組み合わせは、よりバランスの取れた、実際のカバレッジに近いものになります。このエンジンの位置を全体のプロセスで理解するために、ガイドを見直します。 シフト管理 推奨されます。
エンジンによる配置は、マネージャーの決定の代わりではありません。それは彼の計算アシスタントです。ルールはマネージャーが決定し、出力はマネージャーが確認して承認し、システムは規則に対するリクエストの大量のチェックだけを担当します。
再配置、一時的な観察、完了不可能なシフトの通知
シフト計画は本質的に繰り返しの作業です；初めに作成された組み合わせが最終的な組み合わせになることはめったにありません。だからこそ、システムのオプション 再配置 マネージャーの手に委ねられます: プロセスを再実行することで、システムは最初から新しい組み合わせを作成します。この機能により、マネージャーはさまざまな配置のシナリオを評価し、規則の変更や新しいリクエストの追加による影響を確認し、最終的に部門のカバー範囲やリクエストへの対応の観点からより受け入れ可能な組み合わせを選択することができます。再配置は以前の作業を捨てることを意味するものではなく、比較して意識的に選択する機会を持つことを意味します。
は他の機能、 、プログラムの状態をリアルタイムで確認する リクエストの入力と同時にシステムが動作します。システムはプログラムを生成するために、別の長い段階である「計算の開始」を必要としません。各リクエストが登録されると同時に情報は処理可能であり、管理者は何人がリクエストを送信したか、各シフトのどれくらいの容量が満たされているか、どのシフトにまだ空きがあるか、リクエストの全体状況がどうなっているかを見ることができます。このリアルタイムの透明性により、月の管理は「締め切りの終了まで待ってから配置を始める」という状態から脱し、積極的なフォローが可能になります。例えば、締め切りの3日前に半数のスタッフしか登録していない場合、管理者は早めにフォローします。
- 定義された条件に従って適切な人員をシフトに配置できない場合、システムは規則を破ることなく、そのシフトは完了できないと知らせます。
- 管理者はいつでも申請状況と各シフトの容量完了率をリアルタイムで確認できます。
- 再配置により、新たな組み合わせを作成し、最終確認前にオプションを比較できます。
このリストの最初の項目は、システムへの信頼の最も重要な原則の一つであり、別途強調する価値があります：Axis Pulsはシフトを強制的に埋めるために、規則を無視しません。もし部門の規則に適合する仮想的な人員の組み合わせが一つもなければ、システムの出力は一見完全な表であっても、規則を破るものではなく、むしろ 「このシフトは定義された条件に従って完了できません」と明確に通知する ことで、管理者は十分な情報に基づいて管理上の判断を行えます；例えば、容量を再検討したり、補助人員を割り当てたり、特定の規則を修正したりすることです。この挙動により、システムの出力は検証可能で信頼性が保たれます。
配置の理由の説明；なぜこの人がこのシフトに入ったのか？
あらゆる計画システムに関する最も一般的な疑念の一つは、その「ブラックボックス性」です：表が提供されますが、なぜ各人が正確にその位置に配置されているのかを誰も知りません。アクシスパルスシステムは、この同じ疑念に応えるため、意思決定の論理が説明可能な場合には、 配置の理由 次のことを明確にします：なぜある人が特定のシフトに配置され、なぜ他のシフトに配置されなかったのか、そしてどの制限がその配置を妨げたのか。例えば、ある看護師の朝シフトに対する優先度1の希望が、そのシフトの定員がいっぱいであったために反映されず、その代わりに彼または彼女の優先度2の希望が午後シフトで対応された、または夜シフトに配置されなかったのが、その月の夜シフトの上限に達していたためである、ということが明らかになる場合があります。
この透明性の実用的な価値は三つの場面で見られる。まず、 プログラムの防衛 抗議に対してである；従業員がなぜ自分のリクエストが考慮されなかったのか尋ねると、マネージャーは一般的な回答の代わりに、具体的な理由を示す。第二に、 法律の改正 です；もし「特定の法律のためにカバーされない請求」の繰り返しパターンが見られる場合、管理者はその法律自体が見直しを必要とするかもしれないことに気付く。第三に、 段階的な信頼醸成 それは、数か月間意思決定の理由を見ているチームは、より自信を持って申請を行い、後の数か月での参加も増えるからです。だからこそ、製品のドキュメントは、マネージャーが単に最終的な表だけに頼る必要はないと強調しています。マネージャーはシステムの意思決定の論理を確認してから、最終的な承認を出すことができます。
提案されたシフトと希望シフトおよび開始ステップの比率
自然なこととして、この質問が生じます：もし提案されたシフトがあるなら、 希望シフトと並行して使用されます。 どのような立場にありますか？簡潔な答えは、提案された方法では、従業員が「このシフトを希望します」と言い、システムがスケジュールを組むのに対し、希望方式では、従業員が「許可された選択肢の中からこのシフトを選びます」と言い、システムがその場で容量とルールをチェックする、ということです。提案された方法は、管理者がすべてのリクエストを一度に確認したい、シフトのバランスを自ら調整したい、最終的な組み合わせを承認したい部門により適しています。特に、24時間体制のカバレッジと役割の組み合わせが重要な入院部門のような混雑する病院部門で有効です。希望方式の詳細は「希望シフト」の論文をご覧ください。より大きなイメージについては、 シフト管理ガイド 戻ってください。
部門で提案されたシフトの使用を開始するには、製品の文書に従った推奨手順は次の通りです：まず、部門の構造、役割、シフト、およびそれらの容量をシステムに一度定義します；次に、従業員が部門専用コードで参加し、その役割がマネージャーによって承認されます；その後、申請登録の期限が通知され、各個人が自分の優先順位を登録します；スケジューリングエンジンがプログラムを作成し、マネージャーが確認し、必要に応じて再編成を行った後、最終版を承認します。月の途中で変更が必要な場合、手順は 休暇とシフトの管理 これは同じプロセスの続きです。治療部門の経験のような 看護師のシフト は、部署のルールがより詳細に定義されるほど、配置の結果が現実に近づき、手作業での修正の必要性が減ることを示しています。また、この精度の基本原則については、 シフトの設定 および シフトコントロール で確認できます。