採用プロセス/段階面接・部長判定

常に募集を掛けている社員募集からの募集を受け、複数回の面接を経て採用内定を行う業務プロセス. 合否は人事部長が判断を行う.

採用内定後は社内稟議を経て正式採用となる. (本業務プロセスでは対象外)

概要

 * 1) Webサイトから社員応募を受け付ける.
 * 2) 人事部の採用担当者は応募受付を確認し書類審査を行う.
 * 3) 担当者は人事部部長を伴い面接を行い1次審査を行う.
 * 4) 担当者は各部長の中から2名を伴い面接を行い2次審査を行う.
 * 5) 担当者は各取締役の中から1名を伴い面接を行い3次審査を行う.
 * 6) 担当者はそれぞれの審査が終了した時点で審査結果を人事部部長へ報告を行う.
 * 7) 部長は審査結果の最終報告を確認する.

(注)各面接において不合格となった場合には本プロセスは終了する.

プロセス担当者

 * 人事部(personnel@company.com)
 * 部長(personnel-leader@company.com)
 * 採用担当者(personnel-person@company.com)

プロセスオーナー
人事部部長(personnel-leader@company.com)

部長により最終の合否判定が行う業務プロセスである為、部長の管理が望ましい.

メリット

 * チェックの充実
 * 担当者及び部長、取締役の合否判定を基に人事部部長の判断が行われる為、全社的な判断が加えられることが期待できる.

デメリット

 * 面接予定の調整の煩雑
 * 業務プロセスが応募者単位となる為、多数の応募が発生した場合、同時並行で多数の業務プロセスが実行されることとなる.
 * 業務プロセス進行速度
 * 必ず部長の判断が入るため、業務プロセスの遅延が予想される.

特徴

 * 不定期な募集への対応
 * 採用プロセス/応募通知・内定者上限条件に比して恒常的に募集を掛ける場合に適用できる業務プロセスである.
 * 段階を踏んだ審査による効率性
 * 書類審査から3次審査に至るまで段階を踏む為、必要最低限の参加者によって審査を進行することが期待される.

プロセスダイアグラム例
digraph developing_capability { compound=true; graph [size="10,8",rankdir=LR]; node [shape=box, style=rounded]; edge [color="#444444", labelfloat=true]; //label text float OFF(=true) subgraph clusterA { labeljust=l; label="anonymous@example.com (応募者)\n\n"; style=dotted; A1 [label="他システム\nWebフォーム", style="dotted,rounded"]; A2 [label="通知メール\n受信\n(書類審査)", style="dotted,rounded"]; A3 [label="通知メール\n受信\n(1次審査)", style="dotted,rounded"]; A4 [label="通知メール\n受信\n(2次審査)", style="dotted,rounded"]; A5 [label="通知メール\n受信\n(3次審査)", style="dotted,rounded"]; A6 [label="通知メール\n受信\n(最終結果)", style="dotted,rounded"]; A1 -> A2 -> A3 -> A4 -> A5 -> A6 [style=invis]; }

subgraph clusterps { labeljust=l; label="personnel@company.com(人事部)"; subgraph clusterp { labeljust=l; label="personnel-person@company.com(人事部採用担当)\n\n\n\n"; PX [label="M", shape=circle, width="0.3"]; P1 [label="P1:書類審査"]; P2 [label="P2:1次審査\n(人事部面接)"]; P3 [label="P3:2次審査\n(部長面接)"]; P4 [label="P4:3次審査\n(取締役面接)"]; P5 [label="P5:面接最終結果\n登録"]; PX -> P1 ; P1 -> P2 -> P3 -> P4 ->P5 [style=invis]; } subgraph clusterl { labeljust=l; label="personnel-leader@company.com\n(部長)"; L1 [label="L1:面接結果\n確認\n(書類審査)"]; L2 [label="L2:面接結果\n確認\n(1次審査)"]; L3 [label="L3:面接結果\n確認\n(2次審査)"]; L4 [label="L4:面接結果\n確認\n(3次審査)"]; L5 [label="L5:面接最終結果\n確認"]; LY [label="", shape=circle, width="0.3",style=bold]; L1 -> L2 -> L3 -> L4 -> L5 [style=invis,weight=100]; L5 -> LY; {rank=same;L5,LY}; } {L1,L2,L3} -> P5 [arrowtail=odiamond, taillabel="不合格"]; P1 -> L1 [sytle=invis,weight=10]; L1 -> P2 [arrowtail=rcrowlvee, label="合格"]; P2 -> L2; L2 -> P3 [arrowtail=rcrowlvee, label="合格"]; P3 -> L3; L3 -> P4 [arrowtail=rcrowlvee, label="合格"]; P4 -> L4; L4 -> P5 ; P5 -> L5; } A1 -> PX [label="(API)", style=dotted,weight=10]; PX -> A1 [style=invis,weight=10]; L1 -> A2 [style=dotted]; L2 -> A3 [style=dotted]; L3 -> A4 [style=dotted]; L4 -> A5 [style=dotted]; L5 -> A6 [style=dotted]; }

プロセスデータ例

 * (注)「書類審査結果」「1次審査結果」「2次審査結果」「3次審査結果」のプロセスデータにおいて採用担当者のみならず部長のタスクにおいて RW(編集可能) 指定となっているのは採用担当者の提案により部長が最終決定(最終編集)できることを示している.