Resource Scheduling Optimization で勤務時間外の移動時間を許可する
既定では、Resource Scheduling Optimization が移動が技術者の定義済み勤務日の一部であるかのように振る舞います。 ただし、フィールド サービス組織ごとに技術者の移動に関するポリシーが異なるため、この規定が常に理想的であるとは限りません。
たとえば、技術者が午前 8 時から午後 5 時までを就業日を定義しているとします。 この構成がない場合、最適化により、技術者は午前 8 時に移動を開始するようにスケジュールされます。つまり、技術者は午前 8 時以降になるまで到着または作業を開始しません。
最適化目標で 勤務時間外の移動時間を許可する を有効にすると、技術者が勤務の 1 日を少し早く開始させるための最適化許可を与え、その間は作業はおこなわず移動に費やされていると想定します。 最適化により、技術者は勤務時間前に移動を開始し、1 日が始まると (定義された制限内で) 作業指示場所に到着するようにスケジュールされます。
次のスクリーンショットは、勤務時間外の移動時間を許可する を有効化されていない、毎日のスケジュールです。
次のスクリーンショットは、勤務時間外の移動時間を許可する を有効化した、毎日のスケジュールです。
技術者の勤務時間の一部として移動時間を考慮しないことにより、スケジューラはリソース使用率の向上を確認できます。
この記事では、Resource Scheduling Optimization で勤務時間外の移動時間を許可するを有効にする方法について説明します。 詳細については、次のビデオの詳細説明を参照してください。
前提条件
- Resource Scheduling Optimization v3.x + (Field Service v8.x+)。
Resource Scheduling Optimization 制約を編集する
Resource Scheduling Optimization>最適化の目標 の順に移動して、最適化の目標を選択または作成します。
最適化目標で、制約 労働時間内でスケジュールする を削除します。
勤務時間外のスケジュールのためにリソースを有効化する
最適化目標が実行中に勤務時間を無視するということがわかったら、勤務時間外の移動について検討するリソースを定義します。
予約可能なリソースに移動し、次に スケジューリング セクションに移動します。
勤務時間外のスケジュール については、次の値のいずれかを入力できます。
- 作業時間前の移動を許可
- 作業時間後の移動を許可
次に、移動制限 (分単位) を入力します。これは、Resource Scheduling Optimization でリソースの勤務時間からどれだけ離れた時間を考慮できるかを知らせます。 この例では、Resource Scheduling Optimization は、このリソースの定義済み勤務時間から 30 分までの移動時間を考慮します。
最適化を実行する
次に、作業をテストしてみます。 Resource Scheduling Optimization は手動、定義済みスケジュール経由で実行することも、ワークフロー経由でトリガーすることもできます。
次のスクリーンショットに示すように、移動時間が勤務時間の開始前に始まります。
例として 30 分の移動時間の制限を使用したため、この最適化されたスケジュールの例ではそれが尊重されていることがわかります。
前の例では、移動時間が勤務時間外の制限時間を超えた場合、移動時間は調整され、制限時間を遵守するために作業開始時間を少し後にプッシュします。
構成の考慮事項
- 勤務時間の前後で異なる移動制限を設定することはできません。 たとえば、勤務前に 30 分の移動制限、そして勤務後に 60 分の移動制限を構成することはできません。
"勤務時間内のスケジュール" 制約と "勤務時間外の移動" の勤務終了時のの比較
勤務時間外の移動が構成されている場合、予約の終了時間は勤務時間内になり、リソースの終了場所に戻る移動時間は勤務時間外にすることができます (1 日の終了時間は空白として表示されます)。
勤務時間内のスケジュール 制約が目標の一部である場合、終了時間は労働時間内になり そして 最後の予約からリソースの終了場所までの移動時間は、勤務時間内になります。
勤務時間内でのスケジュール制約が目標の一部ではない場合、予約の終了時間は勤務時間内になりますが、リソースの移動時間は勤務時間外になる可能性があります。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示