定期報告プロセス/日報・ミーティング確認・登録確認・社員研修用

業務日報は、社員研修としても利用される. 文章力の向上と報告作業の定常化を目的として簡易な日報の業務プロセスを定義する.

報告された内容はトレーナーによってチェックされており、ミーティングを起点に報告が行われる為、報告内容の質及び報告実行の確実性が期待される.

概要

 * 1) 1日の業務内容をトレーナーが出席する日報ミーティングにて報告する.
 * 2) 報告の中で指摘された内容やトレーナーの発言した内容を報告者はメモを取る.
 * 3) 日報提出者はミーティングの内容ををシステムに用意されているフォームへ入力
 * 4) 入力されたフォームの内容をトレーナーはチェックを行い、コメントを記入する.
 * 5) 報告者はトレーナーのチェック内容を確認する.

日報の内容は事前にミーティングにてある程度話し合われ、まとめを報告者が行うことになる. トレーナは報告をチェックしチェックバックを繰り返し確認された内容にて日報の完了が行われることとなる. 日をまたぐ可能性もある.

プロセス担当者

 * 任意の部門(any-section@company.com)
 * トレーナー(leader-section@company.com)
 * 日報提出者(person@company.com)

研修を行っている社員の業務内容のチェック等のトレーニングを行う先輩社員をトレーナーとして位置づける.

プロセスオーナー
トレーナー(leader-section@company.com)

業務日報を利用した社員研修においては企業全体で取り組む場合も存在するが、部門内での状況により業務プロセスが変化することが考えられ、部門内で研修対象社員のトレーナーが業務プロセスを決定しているケースが考えられる 本サンプルプロセスにおいては部門内で規定している業務プロセスとして扱う.

プロセスダイアグラム例
digraph developing_capability { compound=true; graph [size="10,5",rankdir=LR]; node [shape=box, style=rounded]; edge [color="#444444", labelfloat=true]; //label text float OFF(=true)

subgraph clusterg{ labeljust=l; label="any-section@company.com(任意の部門)"; subgraph clusterl { labeljust=l; label="leader-section@compay.com(トレーナー)"; L1 [label="L1:議事録のチェック"]; L2 [label="L2:日報の承認 \n 内容の確認と \n チェックバック"]; L1 -> L2 [style=invis]; } subgraph clusterp { labeljust=l; label="person@compay.com(日報提出者)\n\n\n"; PX [label="", shape=circle, width="0.2"]; PY [label="",shape=circle, width="0.2", style=bold]; P1 [label="P1:報告会開催 \n 議事録を入力"]; P2 [label="P2:日報の作成／編集 \n 承認結果の確認"]; PX->P1 [weight=10]; P1->P2 [style=invis,minlen=2]; P2->PY [arrowtail=odiamond,weight=10,label="\n承認結果が \n 承認",tailport=e,minlen=2]; } P1->L1 [headport=w,tailport=n]; P2->L1 [dir=back,tailport=w,headport=e]; L2->P2 [dir=back,tailport=s,headport=n,arrowhead=rcrowlvee,label="承認結果が \n 承認以外"]; L2->P2 [tailport=e,headport=ne]; } }

メリット

 * プロセスの簡易性
 * 開始の担保
 * ミーティングより業務プロセスが開始されることから開始が担保できる.

デメリット

 * 終了遅延の可能性
 * 日報の承認はトレーナーが行う為、トレーナーの承認が遅れた場合、その日の日報のプロセスは終了しない.