採用プロセス/応募通知・内定者上限条件・応募方法確認・応募方法変更依頼

アルバイトや社員の募集から面接を経て採用内定を行う業務プロセス.

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

概要

 * 1) 採用要望部門の部長は採用したいアルバイトや社員の要望を登録する.
 * 2) 人事部の採用担当者は'要望の確認を行う.
 * 3) 担当者は応募方法を登録し、応募開始を採用要望部門の部長へ確認を行う.
 * 4) 担当者は応募者を受付け、面接を実施する
 * 5) 担当者は採用内定者を登録する.

(注)応募者の受付から面接の採用内定者の登録まで採用内定者が希望人数になるまで繰り返し続ける.

プロセス担当者

 * 採用要望部門(any-section@company.com)
 * 部長(any-section-leader@company.com)
 * 人事部(personnel@company.com)
 * 採用担当者(personnel-person@company.com)
 * 応募者(someone@general.com)

プロセスオーナー
人事部採用担当者(personnel-person@company.com)

採用方法や採用面接の流れについては採用担当者に任されるケースが多い.

メリット

 * 応募活動の把握が容易
 * 応募開始の連絡の徹底が図られ、現在の応募数や採用内定者が把握しやすい.

デメリット

 * 採用内定者決定の遅延
 * 採用内定者の最終決定のタスクは採用内定者が要望数に達するまで開始されない為、採用内定後の手続きが遅れる可能性がある.
 * 誤操作による不要な応募方法変更
 * 「応募方法内容の指摘」と「応募に入ってからの応募方法の変更依頼」の２つの応募方法の変更のきっかけがある. この為、応募に入ってからの応募方法の変更依頼において「応募方法変更依頼」を「要」のままにした場合、不要な応募方法の変更を行ってしまう可能性がある.

特徴

 * 応募方法の確認
 * 応募する媒体(Webサイト・情報誌等)によっては費用が必要となる. その際の予算としては要望部門が負担するケースも存在する.
 * よって費用を含めた応募方法内容の確認が必要となるケースがある.
 * 採用プロセス/応募通知・内定者上限条件　との違いは応募方法の確認にあり、より費用対効果を意識した業務プロセスと言える.
 * 応募の見直し
 * 応募が期待に比して集まらないケースがある. その際には費用や他の応募方法を追加することにより応募を増加させることとなる. 応募数に応じて応募方法を見直すことのできる業務プロセス.

プロセスダイアグラム例
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 clusterl{ labeljust=l; label="any-section-leader@company.com(採用要望部門部長)"; LX [label="", shape=circle, width="0.3"]; L1 [label="L1:採用要望登録"]; L2 [label="L2:応募方法確認"]; L3 [label="L3:面接結果確認"]; LX -> L1 [weight=10]; L1 -> L2 -> L3 [style=invis]; } subgraph clusterp { labeljust=l; label="personnel-person@company.com(人事部採用担当)\n\n\n\n\n\n\n"; P1 [label="P1:採用要望確認"]; P2 [label="P2:採用応募方法登録"]; P3 [label="P3:面接結果登録"]; PY [label="", shape=circle, width="0.3",style=bold]; P1 -> P2 [arrowtail=rcrowlvee]; P2 -> P3 [arrowtail=rcrowlvee, label="承認"]; P3 -> PY [arrowtail=odiamond, label="採用内定者数上限\n達成",minlen=2]; } subgraph clusters { labeljust=l; style=dotted; label="someone@general.com(応募者)"; S1 [label="S1:面接応募 \n (メール/Webフォーム等)",style="dotted,rounded"]; } LX -> P1 [style=invis,weight=20]; L1 -> P1 [weight=10,tailport=sw,headport=nw]; P1 -> L1 [arrowtail=odiamond, label="要件修正要",weight=10]; P2 -> L2 [arrowtail=odiamond, label="未入力 \n or却下 \n or変更依頼有"]; L2 -> P2 [tailport=sw,headport=nw]; S1 -> P3 [style=dotted]; P3 -> L3 [arrowtail=rcrowlvee, label="採用内定者数上限\n未達"]; L3 -> P3 [arrowtail=rcrowlvee, headport=nw,tailport=sw]; L3 -> P2 [arrowtail=odiamond, label="応募方法\n変更依頼有", tailport=w]; }


 * (注)「P3:面接結果登録」の採用内定者数要望上限達成／未達分岐については採用要望人数と採用内定決定人数の比較により行われる.

プロセスデータ例

 * (注)「採用内定決定人数」「採用決定者情報」がP3、L3のタスクにて書き込み可能にしているのは部長が採用者の決定を変更したい場合に対応している.
 * (注)「採用応募方法変更依頼」の属性がRW(変更可能)の指定としているのは「L2:応募方法確認」において部長が「採用応募方法変更依頼不要」をセットすることを想定している.