ワークフローの退職者対応は退職日だけでは片付かない
退職者のワークフローアカウントは、退職日に止めれば足りるのか
退職者のアカウントを、ワークフローでいつ止めるか。IdPと連携していれば、退職日に合わせて自動で止める設定にしている企業が多くなります。情シスの退職チェックリストでも、ワークフローはほかのSaaSと同じ1行に並んでいます。
それでも9月の後半には、ワークフローにだけ問い合わせが届きます。営業の課員から、出張の申請が課長のところで止まったまま動かない、という連絡です。
課長はすでに最終出社を終え、いまは有給休暇を消化しています。情シスもその日付は受け取っていて、PCの回収や社員証の返却は、最終出社日に合わせて済ませました。ただしワークフローの停止だけは退職日の行に並んでいます。アカウントは生きていて、承認の依頼も届き続けている。見る人がいないだけです。
退職日に止める設定は、アクセス管理としては正しい形です。ただし、ワークフローのアカウントは、他人の申請の途中に組み込まれています。退職日に一括で止める運用だと、承認は止める前から止まり、申請は止めたあとに戻ってきます。
本記事では、退職者のアカウントが持っていた役割を、手放す日ごとに並べます。退職の連絡を受けてから何をいつ確かめるかを決めるときの、たたき台として使ってください。
退職者のワークフローアカウントは、いつ止めればよいですか
ログインを止める日は、退職日で構いません。ただし、そのアカウントが持っていた役割は、本人が手放す日と、役割そのものが終わる日がそれぞれ違います。止める日を1日に決める前に、役割ごとの日付を並べるところから始まります。
ワークフローの退職者対応とは、退職者のアカウントが担っていた承認者・代理人・申請者・記録上の名義の役割を、誰かに渡すか残すかを決めて片付けていく作業です。IdPの停止が扱うのは、このうちログインの可否だけです。
本記事では、次の1件を通し例として使います。営業第2課長が9月30日付で退職する。最終出社は9月中旬で、残りは有給休暇の消化に充てます。後任の課長は10月1日付で発令されます。
この課長のアカウントには、次の4つが重なっています。
- 課員8名の経費精算と出張申請で、1段目の承認者に入っている
- 営業部長が不在のときの代理に指名されている
- 最終出社の日に、自分の出張旅費の立替精算を1件申請した
- 6月に起票した展示会の出展稟議は決裁済みで、10月の検収と支払依頼は後任が引き継ぐ
役割 | 本人が手放す日 | 役割が終わる日 |
|---|---|---|
承認者 | 最終出社日 | 後任が発令される日。承認者を申請の時点で確定する製品では、その段に残った申請が片付く日 |
代理人 | 最終出社日 | 代理を頼んでいた人が指名し直した日 |
申請者 | 最終出社日。それまでに引き受ける人を決める | 自分の申請が最後に完了した日。退職日より後になることがある |
記録上の名義 | 手放さない | 保存期間が終わる日 |
退職日に合わせて片付くのは、ログインだけです。本人が役割を手放すのはそれより前で、役割が終わるのは退職日の後になります。
有給消化中に承認が止まるのは、なぜですか
アカウントも経路の設定も退職日まで有効なまま、承認する人だけが業務を離れているためです。役職で承認者を引く経路でも、後任が発令されるまでは、その席に本人が座ったままです。
経路の承認者には、個人名で指定するものと、「申請者の所属課の課長」のように役職で引くものがあります。止まると気づかれやすいのは個人名の指定で、見落としやすいのは役職のほうです。
役職で引く経路は、組織変更に強い形です。ただし席の中身が入れ替わるのは、人事の発令が出たときです。後任の発令が10月1日なら、9月の後半も、営業第2課長の席には辞める課長が座っています。
課員の側からは、承認待ちの表示が続くだけで理由は見えません。この時期に止まるのは、出張の事前申請や、その都度出す精算です。
期限を過ぎた申請を上位者へ自動で引き上げる設定を持つ製品もあり、ここで拾える分もあります。ただし、申請は毎回その期限まで待たされるため、出張の事前申請のように急ぐものは間に合わないことがあります。引き上げ先が部長なら、次の節の2つ目の手と同じ形に落ち着きます。
代理人の役割は、もっと気づかれにくいところです。課長が部長の代理に指名されていると、部長が出張した週に、代理で回るはずの申請が課長の画面に積まれます。代理を頼んでいた部長の側からは、指名した相手がもう出社していないことは見えません。
有給消化中の承認を回す手は、何通りありますか
3つあります。どれを選んでも申請は動きますが、引き受けるものが違います。
取る手 | 動き方 | 引き受けるもの |
|---|---|---|
本人が代理を設定してから最終出社する | 課長が隣の課の課長を代理に指名して休暇に入る | 代理先が規程上の代決者と合っているかを誰かが見る。退職日に代理が外れる製品では、その翌朝に作り直しになる |
経路の承認者を上位へ付け替える | 最終出社日から、部長が1段目も兼ねる | 部長の段が2つ並ぶ。同じ人の2回目を自動で通す設定なら、その期間の申請は1段分短くなる。発令後に戻す作業も残る |
後任の発令を最終出社日に寄せてもらう | 人事が後任の課長を前倒しで発令する | 情シスだけでは決まらない。人事と規程の側の判断になる |
1つ目は、休暇の期間が短く、代理先が規程で決まっている企業に向きます。2つ目は、代理の設定を本人に任せていない企業で選ばれやすい形です。3つ目は経路の手当てが要らなくなる代わりに、発令の時期という別の話に移ります。
決める人は、1つ目が本人、2つ目が情シス、3つ目が人事です。どれを選ぶにしても、手を打てる日は最終出社日の前にあります。その人が承認者に入っている書式の洗い出しは、経路を個人名で指定している箇所が多いほど重くなります。
退職日の翌日と翌月には、何が残りますか
退職日の翌日には、止める作業と入れ替わる作業が重なります。翌月には、申請者の役割が差し戻しという形で戻ってきます。
通し例なら10月1日に、IdPの停止、後任の発令、組織マスタへの反映が同じ日に来ます。
このとき課長の段に残っていた申請がどうなるかは、承認者がいつ確定する作りかで決まります。申請の時点で確定する製品なら、段には辞めた課長が残ったままです。そこで止まるか、段を飛ばすか、管理者が動かすまで待つことになります。段に届いた時点で確定する製品なら、後任の課長へ振り直されます。発令日をまたぐ申請の違いは、ワークフローの組織変更、当日に残る作業は2つに分かれるで整理したものと同じ構造です。
無効化と同時に、そのアカウントに紐づく代理設定が外れる製品もあります。有給消化中に代理で回していた申請が、10月1日の朝にもう一度止まる形です。代理承認の設定は、本人だけに持たせて足りるかで触れた、席が空いた状態に移ります。
申請者の役割は、翌月に形を変えて戻ってきます。課長が最終出社の日に出した立替精算を、経理が10月に確かめます。領収書の日付と出張日がずれていて、差し戻しになりました。経理の差し戻しは規程どおりで、コメントにも理由が正しく書かれています。ただし、それを受け取る人がもうログインできません。差し戻された申請を、管理者の操作で完了にできない製品もあります。
IdPの停止さえ漏れなく走ればワークフローに固有の作業は残らない、という見立てがあります。ここで合わなくなるのは、経理も情シスもそれぞれ手順どおりに動いたうえで、申請だけが宙に浮く点です。どちらの手順にも、退職者の申請という状態が入っていないためです。
取れる形は4つあります。
- 最終出社日までに精算を出し切ってもらい、経理に退職予定者の分から先に見てもらう
- 差し戻さずに進める。経理が本人にメールで確かめる、承認者が内容を直して承認できる製品なら直して通す
- 申請の持ち主を、上長など別のユーザーへ移す。移せるかどうかは製品の仕様次第
- 取り下げて、上長や経理が代理申請の形で起票し直す。立替えたのは退職者なので、名義と実態がずれる
上から順に、退職日より前に打つ手から、退職後にしか打てない手へ並んでいます。退職日を過ぎてから打つ手ほど、申請者の名義を動かすことになります。
退職者の名前は、承認履歴にいつまで残りますか
保存期間が終わるまでは、残しておく必要があります。実際に残るかどうかは止め方で変わり、無効化なら残りますが、削除すると過去の履歴の表示が製品ごとに変わります。
記録上の名義には、その名義で残った申請を誰が読めるかも含まれます。10月の検収と支払依頼は後任が起票し、その根拠として6月の出展稟議を参照します。申請の閲覧を申請者と経路上の承認者に絞っている設定だと、後任はその稟議を開けません。
閲覧できる範囲を部署や役職で決めていれば、後任の発令とともに見えるようになります。個人に閲覧を付けていた場合は、付け替えが要ります。決裁が済んでいても、後続の申請が残る限り、閲覧の引き継ぎが要ります。
弱点の重さは、止め方で違います。無効化したアカウントがID課金の人数に含まれる製品なら、費用はかかり続けますが、契約や棚卸しで見直せます。削除した名義のほうは、あとから戻せません。退職直後は進行中の申請が残っている時期でもあり、削除の判断は役割の片付けが済んでからになります。年限と削除の関係は、ワークフローの保存期間は規程の年数だけでは決まらないが詳しく扱っています。
退職のチェックリストの中でワークフローの行をどこに置くかは、企業ごとの持ち方で変わります。確かなのは、ワークフローの手当てが退職日の1行には収まらないという点です。
まとめ
ワークフローの退職者対応が退職日だけで片付かないのは、1つのアカウントに、手放す日と終わる日の違う役割が重なっているためです。
- ワークフローの退職者対応とは、承認者・代理人・申請者・記録上の名義の役割を、渡すか残すか決めて片付けていく作業
- 退職日に合わせて片付くのはログインだけ。本人が役割を手放すのは最終出社日で、役割が終わるのは退職日の後
- 役職で引く経路でも、後任の発令までは席に本人が座ったまま。有給消化中の承認は、代理・付け替え・発令の前倒しのどれかで回す
- 退職日の翌日には停止と発令が重なる。残っていた申請が後任へ振り直されるかは、承認者が確定する時点で分かれる
- 差し戻しは退職後にも戻ってくる。打つ手が遅くなるほど、申請者の名義を動かすことになる
- 記録上の名義は保存期間まで残す。後続の申請があれば閲覧も引き継ぐ。無効化の費用は見直せるが、削除した名義は戻せない
退職の連絡を受け取ったら、ワークフローの行を最終出社日・退職日の翌日・翌月の3つに分けて置く。役割の片付けは、そこから順番が決まります。
よくある質問
承認者が退職したら、承認待ちの申請は消えますか
消えることは多くありません。アカウントを止めた時点で、その段で止まる、段を飛ばして進む、管理者が動かすまで待つ、後任へ振り直される、のどれかになります。承認者を申請の時点で確定する作りか、段に届いた時点で確定する作りかで分かれます。テスト用のアカウントで申請を1件止めてから無効化してみると、自社の製品でどうなるかを確かめられます。
退職者が出した申請が差し戻されたら、どうすればよいですか
本人はもうログインできないため、再申請以外の形で進めることになります。経理が本人に確かめて差し戻さずに通す、申請の持ち主を上長へ移す、取り下げて代理申請で起票し直す、のいずれかです。後ろの手ほど申請者の名義が変わるため、できれば最終出社日までに精算を出し切ってもらう段取りが取りやすくなります。
異動の場合も、同じ対応が要りますか
異動ではアカウントが残るため、申請者の役割はそのまま本人が持ち続けます。残るのは承認者と代理人の役割で、こちらは異動の発令日を境に入れ替わります。後任が前任の申請を読む必要があるなら、閲覧の付け替えも異動のときに同じく残ります。