定期報告プロセス/日報登録・上司確認

業務日報は、社員研修としても利用される. 文章力の向上と報告作業の定常化を目的として簡易な日報の業務プロセスを定義する. 管理者による最終確認が行われ報告プロセスが終了する.

研修の成果として日報の提出回数や提出内容／添削を受けた内容が記録され研修終了の際に上司にて研修結果の確認を受けることとなる. (評価プロセスとなる為、本プロセスには含めない)

概要

 * 1) 日報提出者は業務日報の内容をメールにて作成する.
 * 2) 日報提出者は作成したメールを社員研修のトレーナーに送信する.
 * 3) トレーナーはメールの内容を添削し、メールにて日報報告者に対して返送する.
 * 4) 日報提出者はトレーナーによって添削されたメールの内容を確認し登録を行う.
 * 5) 登録された内容を管理者が確認しコメントを返す.
 * 6) 管理者のコメントをトレーナー、提出者それぞれ確認する.

プロセス担当者

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

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

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

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

メリット

 * プロセスの簡易性
 * メールを利用することによる簡易実現
 * メールによる提出とメール返信による添削により既存にあるインフラを活用し実行に移し易い.

デメリット

 * 実行確認
 * 日報提出者が起点となる為、メールの提出がなければ日報の提出の有無が誰にもわからない.
 * 添削後の確認
 * 添削後に結果を参照するプロセスが無いため、日報提出者が添削返送した内容を確認しているかの確認が行えない.
 * 登録時改竄
 * メールでの日報に対する指摘のやり取りであるため、登録の際に改竄を行い添削が無かったようにすることができる.

KGI/KPI
デメリットにもあるように「実行確認」が提出の際にとれないという問題がこの業務プロセスには存在する.

最終的に「研修の目的」である「文章力の向上と報告作業の定常化」を達成する為には成果の確認は欠かせないものとなる為、以下に設定事例を記述する.

KGI

 * 日報の提出が業務日数の80%以上であること.
 * 日報の確認返送にて添削されている日数が提出日数の80%以内であること.

KPI

 * 提出回数が18日/月以上であること.
 * 日報の確認返送にて添削されている日数が18日以内であること.

副次的な効果として管理者からのコメントをもらうことによる「提出者の報告品質の向上」「トレーナーのコーチング能力の向上」が期待できる.

プロセスダイアグラム例
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:日報の確認 \n メールにて添削を返す",style="dotted,rounded"]; L2 [label="L2:上司コメント確認"]; LY [label="",shape=circle, width="0.2", style=bold]; L1 -> L2 [style=invis]; L2 -> LY; } subgraph clusterm { labeljust=l; label="parent-leader-section@compay.com(管理者)"; M1 [label="M1:日報確認 \n コメント"]; } subgraph clusterp { labeljust=l; label="person@compay.com(日報提出者)"; PX [label="", shape=circle, width="0.2"]; PY [label="",shape=circle, width="0.2", style=bold]; P1 [label="P1:日報の作成 \n メールにて作成",style="dotted,rounded"]; P2 [label="P2:日報の登録 \n 登録システムに登録"]; P3 [label="P3:上司コメント確認"]; PX->P1 [weight=10]; P1->P2->P3 [style=invis]; P3->PY [weight=10];

} P1->L1 [style=dotted]; L1->P2 [style=dotted]; P2 -> M1; M1 -> {P3,L2}; } }

(注釈)
 * 利用者の判断のみ(システムの介在しない)部分である P1 及び L1 のアクティビティは点線で囲む形で表現している.

プロセスデータ例

 * (注)管理者の提出者、トレーナーへのそれぞれのコメントはそれぞれ自分宛でないコメントは参照できない.