ワークフローの退職者対応は退職日でなく最終出社日で区切る

退職者がワークフローに残すものは、アカウントだけではない

ワークフローの支払依頼が退職者の承認待ちで止まっている。経理からそう連絡を受けて申請を開くと、3段目に先月退職した課長の名前が残っています。アカウントは、人事から届いた退職日どおりに止めていました。

承認待ちは12件あり、そのうち数件は取引先への支払期日が今週です。経路の設定を開くと、3段目は役職ではなく課長の個人名で指定されていました。

アカウントを止めても申請が止まる、という連絡は、退職のあとに情シスへ届きやすいものです。情シスが手順を飛ばしたわけではありません。退職の連絡は、人事から情シスへ1本で届きます。一方で、退職者がワークフローの中で持っているものは、経路は管理部門、書式は各部門、ビューは本人と、持ち主が分かれています。

よくある対処は、退職時のチェックリストにワークフローのアカウント停止を1行足すことです。ただし、1行では片づきません。ワークフローでは、本人が他人の仕事の途中に入っているためです。

本記事では、退職者がワークフローに残すものを4つに分け、どの日付で区切るかを整理します。人事から連絡が来たときに、どこから確かめるかを選ぶ材料として使ってください。

ワークフローの退職者対応とは、何を片づけることですか

退職する人が持つ申請・承認・設定を引き渡し、記録の名前を残したままアカウントを止めることです。目指すのは、止めたあとも業務と証跡が途切れない状態です。

本記事では、次の1件を通し例として使います。経理部の課長が10月31日付で退職する。最終出社日は10月9日で、そこから先は有給休暇の消化です。

この課長がワークフローの中で持っているのは、次のようなものです。

1. 自分が起票した、外部の専門家への報酬の支払依頼。添付した請求書の金額違いで差し戻されたまま
2. 支払依頼の経路の3段目。役職ではなく個人名で指定されている
3. 経理部で毎朝見ている、月内の支払予定の共有ビュー。作ったのは課長本人
4. 過去3年分の支払依頼に残る、承認者としての記録

退職者がワークフローに残すものは、どの4つに分かれますか

途中にある自分の申請、自分の前で止まる他人の申請、本人が持ち主になっている設定、過去の記録に残る名前の4つです。退職後に何を失うかが型ごとに違うため、片づける日付もそこから決まります。

途中にある自分の申請

差し戻された支払依頼は、課長が請求書を差し替えて出し直すのを待っている状態です。差し戻された申請を直して出し直せるのは申請者本人だけ、という作りのシステムは少なくありません。

退職後は、管理者が申請者を後任に付け替えるか、取り下げて後任が出し直すことになります。手続きはどちらでも進みます。ただし、請求元とどんなやり取りをして金額が違っていたのかは、課長の頭の中にしかありません。

なお、課長自身の立替精算は、この型から外して考えます。立替精算は会社が課長に払うお金で、申請者を付け替えると誰が立て替えたかの記録が崩れるためです。有給消化中も在籍していてアカウントは動くので、本人が出し直せます。期限になるのは最終出社日ではなく、最終の給与とあわせて精算する締め日です。

自分の前で止まる他人の申請

支払依頼の3段目に課長が個人名で入っている以上、課長が退職しても申請は課長の前で待ち続けます。

役職で経路を組んでいれば後任に切り替わる、と考えられがちです。ただし、切り替わるのはまだ届いていない段だけ、という作りのシステムもあります。すでに課長の前に届いている申請は、届いた時点の承認者のまま残ります。

個人名で指定された経路が組織の変化についていけない問題は、承認経路のメンテが終わらない理由で扱いました。退職は、その弱さが1日で表に出る場面です。

本人が持ち主の設定

経理部が毎朝見ている支払予定のビューは、作った課長のものです。課長のアカウントに紐づいた設定は、アカウントを止めた日に一緒に見えなくなる場合があります。

この型は、止まってもすぐには誰も気づきません。ビューが開けない、連携で届くはずの通知が来ない、と分かるのは、使う人が次に探したときです。作り直すことはできても、なぜその絞り込みの条件にしたのかは、作った本人に聞くしかありません。

ビューのほかにも、書式や経路を管理する権限、誰かの代理として承認する設定、外部のシステムとつなぐための連携の登録などが、この型に入ります。代理承認をどこまで本人に持たせるかは、代理承認の設定は、本人だけに持たせて足りるかで整理しています。

過去の記録に残る名前

過去3年分の支払依頼には、課長が承認者として記録されています。監査で問われるのは、この支払を誰がいつ承認したかです。

アカウントを止めても、この名前は残ります。問題になるのは、ユーザーを削除したときです。システムによっては、削除すると過去の記録の名前が別の表示に置き換わったり、記録ごと参照できなくなったりします。

なぜ退職日ではなく、最終出社日で区切るのですか

理由は型によって2つに分かれます。途中にある自分の申請と本人が持ち主の設定は、本人にしか分からない文脈を引き渡す必要があるためです。自分の前で止まる他人の申請は、最終出社日から承認待ちが溜まり始めるためです。

本人の文脈は最終出社日までしか引き渡せない

申請者を付け替えさえできれば退職後でも片づく、という見立てがあります。付け替え自体はできます。合わなくなるのは、差し戻しのコメントが指している直し方が、後任には分からない場合です。手続きは進んでも、中身を判断できる人がいません。

有給消化中の課長にも、連絡をすれば聞けないことはありません。ただし、休暇中の人に業務の問い合わせを重ねる形は、人事の側が避けたいところです。文脈を引き渡せるのは、本人が業務をしている最終出社日までです。

役職の切り替えは発令日まで起きない

課長の最終出社日は10月9日、退職日は10月31日です。この3週間、課長は在籍していて、アカウントも動いています。

人事の発令は、多くの場合、退職日の翌日付で後任の着任や役職の解除が効きます。人事システムと同期している組織や役職の情報も、その日付で切り替わる設定が一般的です。そのため役職で組んだ経路でも、3週間は課長に申請が届き続けます。形式の上では、この期間の決裁権限者はまだ課長です。

有給消化中なので承認の通知は見ない、と課長が考えるのは自然なことです。承認を頼んだ側も、3段目で止まっているとは思っていません。

この3週間に課長の段を誰が引き受けるかは、決裁権限規程にもとづく職務代行者の指名で決まります。本人が休暇中も承認を続ける、という決め方もあります。どちらにするかを決めるのは規程を持つ管理部門で、経路の設定だけで決められることではありません。

区切りは4つの日付に分かれる

課長の場合、10月9日までにやることは3つです。

1. 差し戻し中の支払依頼について、請求元とのやり取りを後任に話してもらう
2. 支払予定のビューの絞り込み条件を、後任と一緒に確かめる
3. 3段目を職務代行者に回すか、本人が続けるかを管理部門に決めてもらう

10月31日にアカウントを止めても、過去3年分の承認記録の名前はそのまま残します。

支払期日は、段の引き受け手が実際に承認できる状態にしておけば守れます。後から取り返しがつかないのは、最終出社日を過ぎると失われる本人の文脈と、削除すると失われる記録の名前の2つです。

無効化と削除は、どこで分けますか

無効化はログインを止めて記録を残すこと、削除はユーザーの情報ごと消すことです。退職に伴ってアカウントに行うのは、無効化までにとどめます。その人が関わった文書の廃棄が終わるまでユーザーは削除しない、という分け方が1つの軸です。

名前が残る期間は、文書の保存期間と同じとは限りません。1人の承認記録でも、書類の種類によって保存年数や起算日が違うためです。その人が承認者として残る文書のうち、最後に満了するものまでが目安です。永年保存の文書に関わっていれば、削除しないという判断もありえます。保存期間の考え方は、ワークフローの保存期間は規程の年数だけでは決まらないで扱いました。

人事システムやIDの管理基盤とユーザーを自動で同期している場合は、もう1つ確かめることがあります。退職の情報がワークフロー側に、無効化として届くのか、削除として届くのかです。IDの管理基盤でユーザーを削除すると、しばらくしてから削除として届く設定もあります。

なお、削除すると何が消えるかは仕様として確かめられますが、退職者の名前をいつまで残し、いつ消すかは、文書管理規程と個人情報の扱いの方針で決まります。いつ消すかを決めるのは、規程を管理する側です。

最終出社日から退職日までのアカウントは、どう扱いますか

扱い方は、段を最終出社日に外すか退職日まで本人に残すかと、アカウントをいつ止めるかの組み合わせで3つに分かれます。どれを選ぶかは、決裁権限規程が休暇中の本人の承認を想定しているかと、IDの管理基盤と止める日を揃えたいかで決まります。

どの扱い方を選ぶ場合でも、人事からの連絡に2つの項目が要ります。最終出社日と、職務代行者の名前です。

退職日しか届かない連絡では、引き渡しの期限も、課長の段を誰に回すかも分かりません。退職の連絡票にこの2つの欄を足すことは、どの扱い方を選ぶ前にもできる手当てです。

まとめ

ワークフローの退職者対応は、アカウントを止める1回の作業ではありません。日付の違う複数の区切りで進む作業です。

• 退職者がワークフローに残すものは、途中にある自分の申請、自分の前で止まる他人の申請、本人が持ち主の設定、過去の記録に残る名前の4つ
• 申請と設定は本人の文脈を引き渡すために、他人の申請は段の引き受け手を決めるために、最終出社日で区切る
• 役職の切り替えは発令日まで起きない。最終出社日からの期間に段を誰が引き受けるかは、規程を持つ管理部門が決める
• アカウントに行うのは無効化まで。関与した文書の廃棄が終わるまで、ユーザーは削除しない

止める日付の前に、引き渡す日付を決める。そこから退職者対応の段取りが組めます。

よくある質問

退職者のユーザーを削除すると、過去の申請データも消えますか

システムによって分かれます。申請データは残るものの名前が別の表示に置き換わるもの、記録ごと参照できなくなるものがあります。削除の前に、テスト用のユーザーで申請と承認を1件ずつ作っておきます。そのユーザーを削除して記録がどう見えるかを確かめると、判断の材料になります。

退職者が承認者のまま止まっている申請は、どう処理しますか

管理者の代理承認、承認者の差し替え、差し戻しての再申請のどれで処理するかは、その段が決裁権限規程で誰に割り当てられているかで分かれます。監査の面では、誰がどの権限で処理したかが記録に残る方法を選んでおくと、後から説明しやすくなります。

休職や育児休業の人も、退職者と同じ扱いでよいですか

戻ってくる前提がある点で、退職とは分けて考えることが多くなります。過去の記録と本人の設定はそのまま残し、自分の前で止まる他人の申請だけを、休職のあいだ職務代行者に回す形が考えられます。異動の場合は組織変更と重なるため、ワークフローの組織変更、当日に残る作業は2つに分かれるの整理が近くなります。