ワークフローツールの導入には、一定のルールに従って申請・承認が行える、社外からでも対応できる、紙の申請書を電子化できるなど、多くのメリットがあります。
申請者から見れば、
申請する
↓
上長が承認する
↓
総務・人事が承認する
↓
完了と進むため、かなりの部分がシステム化されたように見えます。
一方で、忘れられがちなのが、各種申請に付帯する「手当」の処理です。
申請自体はワークフロー上で完了していても、その後に総務や労務が給与システムを開き、手当を追加・変更・削除しているのであれば、その部分には手作業が残っています。
ワークフローを導入したからといって、必ずしも申請に関連する業務全体が自動化されるわけではありません。
今回は、ワークフロー導入時に見落としやすい「手当」の後続処理について考えていきます。
1. 申請に付帯する「手当」
企業では、法律上必要となる割増賃金とは別に、さまざまな手当を独自に設けています。
最も分かりやすいのは、通勤手当ではないでしょうか。
あまりにも一般的なので、経費のように当然支給されるものと感じることもありますが、通勤手当そのものは法律で一律に支給が義務付けられたものではなく、企業が就業規則や賃金規程等に基づいて設けているものです。
例えば従業員が引っ越したとします。
従業員は身上変更申請で新しい住所を会社へ届け出ます。
しかし、住所が変われば通勤経路が変わり、定期券代が変わる可能性があります。
つまり、
住所変更
↓
身上変更申請
↓
通勤経路変更
↓
通勤手当変更という一連の処理が発生します。
同じような例はほかにもあります。
- 結婚、離婚、出生、扶養家族の変更などに伴う「家族手当」
- 引っ越しに伴う「通勤手当」「住宅手当」
- 異動、昇格、降格などに伴う「役職手当」「職務手当」
- 出張に伴う「出張手当」「日当」
- 転勤や赴任に伴う「赴任手当」や、条件によっては「住宅手当」
などです。
つまり、従業員の勤務環境や家庭環境に何らかの変化が発生すると、それを起点として手当の追加・変更・削除が必要になる場合があります。
2. ワークフローは自動で「手当」の変更まで対応しているか？
ここで考えたいのが、
「身上変更等の申請がワークフローで完了すれば、手当も自動的に変更されるのか」
という点です。
これは、ワークフロー製品の機能、給与システムとの連携、そして会社独自の手当ルールによって大きく変わります。
技術的には、自動化しやすい手当もあります。
例えば役職手当です。
仮に、
課長：月30,000円
部長：月50,000円という明確なルールがあり、人事システム上の役職変更と給与システムが連携しているのであれば、
課長から部長へ昇格
↓
役職情報変更
↓
役職手当30,000円を削除
↓
役職手当50,000円を追加という処理は比較的ルール化しやすいでしょう。
家族手当についても同様です。
結婚、出生、家族情報変更などを起点として、会社の家族手当規程と照合できれば、技術的には対象者を判定できます。
出張手当についても、
「国内出張1日につき3,000円」
というような単純なルールであれば、出張期間から自動計算しやすくなります。
ただし、実際に一般的なワークフロー製品が標準機能としてここまで処理してくれるとは限りません。
ワークフローの中心的な役割は、
申請
↓
承認
↓
決裁という業務フローを電子化することだからです。
承認された情報を使って、その後に給与マスタまで自動変更するには、給与システムや人事システムとの連携が必要になる場合があります。
3. すべての手当をルール化すればよいわけではない
一方で、すべての手当をシステム上で自動判定することが効率的とは限りません。
例えば住宅手当です。
企業によっては、
- 独身であること
- 家賃が一定額以上であること
- 賃貸物件であること
- 本人が世帯主であること
- 一定年齢以下であること
- 会社から一定距離以内であること
など、複数の条件が設定されていることがあります。
さらに、
- 本人名義で契約しているか
- 会社都合の転勤なのか
- 社宅制度との併用は可能なのか
といった条件まで存在するかもしれません。
これらすべてをシステム上の判定ロジックとして実装し、規程変更のたびにメンテナンスするのであれば、発生件数によっては担当者が申請内容を確認した方が早い場合もあります。
赴任手当についても同様です。
会社命令による赴任だけを対象とするのであれば、その異動が手当の支給対象となる「赴任」に該当するのかを機械的に判定できるかが問題になります。
自動化できるかどうかだけでなく、
自動化するほど発生件数があるのか
まで考える必要があります。
4. ワークフローが終わっても、総務の仕事は終わっていない
ここが本記事で最も考えたいポイントです。
ワークフローを導入すると、従業員側からは業務がかなり自動化されたように見えます。
住所変更をオンラインで申請する。
上長がオンラインで承認する。
人事総務がオンラインで確認する。
ステータスが「承認済み」になる。
ここまで非常にスムーズです。
しかし、その後に総務担当者が、
給与システムを開く
↓
従業員を検索する
↓
通勤手当を変更する
↓
住宅手当の対象条件を確認する
↓
必要なら給与担当者へ連絡するという作業をしているのであれば、バックオフィス側ではまだ手作業が残っています。
つまり、システム導入時には、
「申請が電子化されたか」だけではなく、「承認された後に誰が何をしているか」まで確認する必要があります。
5. 「手当を付ける」より「手当を外す」方が怖い
手当管理で注意したいのは、手当の付け忘れだけではありません。
むしろ総務実務では、「外し忘れ」の方が厄介になる場合があります。
例えば、
- 営業部門から異動したが「営業手当」が残っていた
- 引っ越しによって住宅手当の支給条件から外れたが、そのまま支給されていた
- 扶養状況が変わったが「家族手当」が残っていた
- 一定年齢までという条件の手当が、年齢到達後も支給されていた
といったケースです。
従業員自身が会社のすべての手当について適用条件を把握しているとは限りません。
また、手当がなくなることについて、従業員からの自己申告だけに依存する運用にも限界があります。
そのため、手当を正しく公平に管理するのであれば、
「何が起きたら手当を付けるか」だけではなく、「何が起きたら手当を外すか」もルール化しておく必要があります。
特に外し忘れが数か月続いた後で、
「本来は3か月前から対象外でした」
となれば、その後の対応も難しくなります。
身上変更や異動のタイミングで手当が変更されるのであれば従業員側も理解しやすいでしょう。
一方で、会社側の処理漏れによって数か月後に突然手当がなくなれば、従業員との間にしこりが残る可能性もあります。
6. システム導入前に「承認後」を棚卸しする
ワークフローシステムを検討すると、
申請フォームを作れるか。
スマートフォンから承認できるか。
承認経路を柔軟に設定できるか。
代理承認できるか。
といった機能に目が向きがちです。
もちろん、これらも重要です。
ただし総務・労務の業務効率化を目的とするのであれば、その一歩先まで確認した方がよいでしょう。
例えば身上変更なら、
身上変更申請
↓
承認
↓
人事マスタ変更
↓
手当の対象判定
↓
給与情報変更
↓
必要な行政手続
↓
完了までを書き出してみます。
そのうえで、
どこまでシステムが処理し、どこから総務・労務の手作業になるのか
を確認します。
これは手当に限りません。
ワークフローを導入しても総務の仕事が思ったほど減らない場合、「承認後の後続業務」がそのまま残っていることがあります。
まとめ
ワークフローツール導入の条件として、
「申請に付帯するすべての手当まで自動管理できること」
を必須条件にする必要はないでしょう。
手当業務には、
- ① 発生頻度がそれほど高くないものがある
- ② 手当そのものの新設・統廃合があり得る
- ③ 支給条件が変更される可能性がある
- ④ 会社固有の判断が必要になる場合がある
という特徴があります。
すべてをシステムへ実装しようとすると、想定以上の開発・設定・保守コストが発生する可能性があります。
発生頻度によっては、そのコストを回収できないことも考えられます。
システム側に業務を合わせることは、業務効率化における一つの考え方です。
しかし手当管理については、
- 手当の適用条件を明確にする
- 必要に応じて手当を統廃合し、制度を複雑にしすぎない
- 手当を「付ける」「変更する」「外す」契機を明確にする
- 身上変更や異動が発生した際のチェック方法を標準化する
といった運用面の整理を先に行った方が効率的な場合もあります。
そのうえでワークフローベンダーに、
「この申請が承認された後、給与側の手当変更までどこまで自動化できますか」
と確認してみるのはよいでしょう。
API連携や給与・人事システムとの連携、申請データの引き継ぎなど、想定していなかった方法で対応できる場合もあります。
ワークフロー導入時に見るべきなのは、申請画面だけではありません。
「承認」ボタンが押された後に、総務・労務が何をしているのか。
そこまで確認して初めて、システム導入によって実際にどの程度業務が減るのかが見えてきます。
