ドライバー イベントのレビューとコーチング: 実用的なフリート ワークフローと記録テンプレート

1. 結論を出す前に信頼できる記録を 1 つ作成する

イベント ID を割り当て、元のソース ラベルをレビュー結果とは別に保管します。車両、デバイス、ドライバーの割り当て、イベントの時間、タイムゾーン、イベントが利用可能になった時間を記録します。ドライバーの割り当てが不確実な場合は、それを解決するか、その不確実性を記録に保存してください。

イベントが重複しているか、テストであるか、または別のオープンレビューの一部であるかを確認します。同じ信号を何度もカウントするのではなく、関連するレコードをリンクします。オフライン期間中に何が起こったかを確認します。クリップのアップロード時刻は、録画された時刻と異なる場合があります。

• 査読者: イベントをチェックし、結果を記録する人。
• アクションの所有者: 特定のフォローアップの責任者。マネージャー、ディスパッチャー、運転手、技術者などが考えられます。
• エスカレーション所有者: 異議のある結果や査読者の権限外の懸念を扱う人。

プラットフォーム全体で安定した識別子と同じ命名規則を使用し、ログを確認します。ワークフローに必要な個人情報のみを記録します。ワークシートでは、映像の広範なコピーを収集するのではなく、アクセス制御された証拠を参照する必要があります。

2. 証拠を確認し、運転手の説明を求めます

クリップまたはイベント レコードが正しい車両、割り当て、および時間に属していることを確認してください。カメラの視界、障害物、照明、録画ギャップ、デバイスのステータスを確認します。 GPSとビデオを組み合わせる場合は、時計を確認し、利用可能な更新間隔を把握してください。

記録が示すものと示さないものを書き留めます。たとえば、カメラによって生成された注意散漫ラベルは、関連する映像を確認することを保証するかもしれませんが、ドライバーの意図や周囲の状況を独立して確立するものではありません。参照 DMS の機能と制限 テクノロジーの境界線に向けて。

検討中のイベントについて説明し、ドライバーのアカウントを招待します。答えを誘導せずに、タスク、車両の状態、周囲の状況について質問します。修正または反対意見をソース記録と一緒に記録します。元のイベントラベルを黙って置き換えないでください。

映像の取得と適切なアクセスには、次を使用します。 車両監視とドライバーサポートのためのビデオテレマティクス。クリップが欠落しているか利用できない場合は、イベントが起こったか起こらなかったかの証拠として扱うのではなく、証拠の制限として記録する必要があります。

3. アラートの種類だけでなく、レビューされた結果を分類する

レビュー担当者が一貫して適用できる小さなカテゴリのセットを使用します。これらは、ラベルを運用するために提案されたものであり、法的所見や規定の懲戒制度ではありません。

複数のアクションが適切な場合もあります。イベントは、トレーニングのギャップと混乱を招く手順の両方を明らかにする可能性があります。各アクション、その所有者、フォローアップ日を分けます。レビュー担当者が同意しない場合は、合意されたエスカレーションプロセスを使用し、その理由を可視化してください。

4. レビューで裏付けられる場合は、集中的なコーチング会話を行う

関連する証拠と該当する期待値を準備します。ドライバーについて大まかに判断するのではなく、見直したタスクと実際的な次のステップに焦点を当てます。一部のレビューでは、コーチングではなく技術的または運用上のアクションが必要です。

1. レビューしたイベントについて説明する

   時間、タスク、観察について説明します。記録されたものと査読者が推測したものを区別します。

2. ドライバーの話を聞く

   何が原因なのか、記録の修正が必要かどうかを尋ねます。回答と未解決の点を文書化します。

3. 想定される実践を明確にする

   議論を関連するフリート手順に結び付けます。ドライバーがそれを実際のタスクに適用する方法を理解していることを確認してください。

4. 具体的な次のアクションに同意する

   何が変更されるのか、誰がそれをサポートするのか、完了がどのようにチェックされるのかを記録します。必要に応じて、管理または設備の変更を含めます。

5. フォローアップを手配する

   タスクと利用可能な露出に適したレビュー日を設定します。承認は、所見への同意とは別に記録してください。

の フリートの気晴らし方針と指導ガイド 気を散らす関連のレビューの背後にあるポリシーに対処します。この会話の概要はレビュー プロセスをサポートします。雇用または懲戒の決定は、引き続きフリートの該当する手順によって管理されます。

5. イベントを終了としてマークする前にアクションを確認します。

アクションが合意されたときのアクションの所有者と期日を記録します。ステータスと結果を切り離してください。レビューされた結果は、修正作業が完了したことを意味するものではありません。

• ドライバーのサポートまたはトレーニング: 合意された活動が行われたことを確認し、関連するタスクの理解を確認します。
• 技術的なアクション: 関連する動作条件下での取り付け、構成、またはデータ修正を検証します。
• 運用上の変更: 担当チームが改訂された指示またはワークフローを実装していることを確認してください。
• それ以上のアクションはありません: 理由とレビューされた結果を保持します。

完了の証拠とそれを誰がチェックしたかを記録します。対策が効果的でなかった場合、当初の懸念が解消されない場合、または新たな証拠によって結果が変わる場合には、レビューを再開します。承認だけでは検証の代わりにはなりません。

6. イベントレビューレコードでこれらのフィールドを使用します。

次のフィールドは、スプレッドシートまたは既存のケース管理ツールにコピーできます。承認されたリポジトリに証拠を保管し、証拠 ID または承認された場所を使用して参照します。

1 つのレビューに複数の所有者がいる場合は、別のアクション ログを使用します。広く共有されているワークシートに、無制限のビデオ リンクや不必要な個人情報を配置しないでください。市場ごとに固定の保存期間を設けるよりも、保存ポリシーの参照の方が望ましいと考えられます。

7. レビュープロセスが利用可能かどうかを確認する

レビューのバックログ、証拠の入手からレビューが完了するまでの時間、未解決のケース、期限切れのアクション、繰り返される機器の問題を監視します。各尺度を一貫して定義し、利用可能な証拠の欠如とレビュー担当者の能力の欠如を区別します。

レビュー担当者が同じレコードの小さなセットをどのように分類するかを定期的に比較し、違いについて議論します。完了したケースをサンプルして、ドライバーのフィードバックが記録されているか、アクションに所有者がいるか、終了が証拠によって裏付けられているかどうかを確認します。すべての違いがドライバーの問題であると想定するのではなく、意見の相違を利用して指示を改善します。

傾向を確認する際には、同様のルート、露出、撮影条件を比較してください。生の警告の合計が減少しただけでは、運転が安全になったことは証明されません。また、設定の変更、データの欠落、または記録時間の減少を反映することもできます。

よくある質問

すべてのアラートはコーチングにつながる必要がありますか?

いいえ、まず証拠を確認してください。イベントには、分類の修正、技術的な修正、運用上の変更が必要な場合もあれば、それ以上のアクションが必要ない場合もあります。

ドライバーの確認によりケースは終了しますか?

確認により、受信または参加が確認されます。閉鎖は、アクションおよび未解決の問題の合意された検証に従う必要があります。

ドライバーが結果に異議を唱えた場合はどうなりますか?

意見の相違と関連する背景を記録し、必要に応じて追加の証拠を確認し、フリートの文書化されたエスカレーション ルートを使用します。

ワークシートには新しいハードウェアが必要ですか?

いいえ、すでに利用可能なレコードから始めます。ワークフローで追加の監視または記録が必要な場合は、 DMS 選択チェックリスト 要件を定義してテストします。