勤怠管理システムの導入や乗り換えでは、製品選定に目が向きやすい一方、実際にプロジェクトが始まると、設定や検証、移行後の運用整備にも多くの時間を使います。
特に、シフト制・フレックス・変形労働・深夜勤務など、複数の勤務形態が混在する場合は、勤務形態ごとに設定内容を整理し、それぞれの集計結果を確認していくことになります。稼働後に想定とは異なる集計が見つかると、給与計算用のデータとして使用する前に、毎月のルーティン業務として確認や修正が必要になることもあります。
本記事では、複数の勤務形態が混在する企業で、既存システムからの移行と、その後の運用定着までをご支援した事例をご紹介します。勤怠システムの導入や見直しを検討する際の一例として、ご覧いただければと思います。
※本記事は実際のご支援内容をもとに、企業名・業種・規模・固有の運用内容を特定できない形に変更・要約してご紹介しています。
フォスターリンク株式会社
2000年の創業以来、人事領域の支援を手がける人事のベストパートナー。社会保険労務士の資格を持つ担当者が在籍し、勤怠管理・KING OF TIME運用支援の実務知見をもとに本記事を監修・執筆しています。
ご相談の背景
今回のご相談は、既存ベンダー経由で利用していた勤怠管理環境を見直し、システムの移行・再構築を検討したいというものでした。
状況をうかがうと、次のような点がありました。
・シフト制・フレックス・変形労働・深夜勤務など、複数の雇用区分・勤務形態が混在しており、設定内容が複雑になっていた
・システムでどこまで設定できるかの把握が十分でなく、設定で対応できる部分についても手作業が発生していた
・制度・システム設定・実際の運用に相違が生じており、全体を整理する必要があった
システムそのものの選定に加えて、現在の制度・設定・運用を整理し、移行後の環境へどのように反映していくかが、今回のご相談の大きなテーマになっていました。
勤怠システムの移行で、移行後の運用まで考えた理由
勤怠管理システムを移行する際には、データ移行だけでなく、勤務形態に応じた設定の見直しも発生します。
所定労働時間や休憩、割増賃金の計算ルールに加え、休暇の種類や取得ルール、勤務データからカウントする手当、残業が発生した際の運用、申請・承認フローなど、企業ごとの制度や運用に合わせて確認する項目があります。
勤務形態が複数ある場合は、それぞれについて設定内容と集計結果を確認していくため、検証する範囲も広がります。画面上の設定だけでは判断しにくく、実際の勤怠データを使って初めて気づく点もあります。
また、本稼働後にシステムを日常的に利用するのは、現場の管理者や従業員です。そのため、設定だけでなく、操作方法や社内の運用方法をどのように共有するかもあわせて考えることにしました。
今回のご支援では、こうした点を踏まえ、約半年をかけて4つの段階に分けて進めています。全体像は次のとおりです。
一度に切り替えるのではなく、設定と検証を進めながら段階的に移行する形を取りました。ここからは、それぞれの段階で行った内容をご紹介します。
STEP 1|現状把握と要件整理
最初に行ったのは、製品の比較ではなく、現在の制度や運用の整理でした。
秘密保持契約を締結したうえで、就業規則・労使協定などの資料を確認し、社内の勤務制度についてヒアリングを行いました。その中で、規程に記載されている内容と、実際の運用に違いがないかも確認しています。
実務では、規程上のルールと日々の運用が完全に一致していないケースもあります。また、制度上は同じ勤務形態でも、部署や雇用区分によって運用や設定が細かく分かれている場合もあります。
そこで今回は、設定を始める前に現在の制度・設定・運用を整理し、どの内容を新しいシステムへ反映するかを企業側と確認しながら進めました。
そのうえで、勤怠システムに求める要件・仕様を精査してシステムを選定し、勤務形態や雇用区分などによって細分化が必要となる設定項目を洗い出しました。
STEP 2|設定代行と検証
要件・仕様の整理と各設定項目の洗い出しを行った後は、その内容をもとにシステムへの設定作業を進めました。
今回のプロジェクトでは、最初からすべての設定を確定させるのではなく、まず暫定的に設定したうえで、実際のデータを使って検証し、その結果をもとに設定を調整していく形を取りました。特に時間をかけたのが、この検証の工程です。
設定後は、テスト部署とテスト従業員を作成し、実際の運用を想定した勤怠データで検証しました。勤務形態や雇用区分ごとにサンプルデータを確認し、想定していた集計結果になっているかを一つずつ見ていきます。
また、想定外の値や異常値が発生した際に担当者が気づけるよう、必要に応じてエラーやアラートが表示される設定も行いました。
勤怠設定では、実際のデータを入れてみて初めて分かることもあります。検証結果を確認しながら設定を調整することで、本稼働後に確認や修正が集中しないように進めました。
STEP 3|環境移行・リプレース
設定と検証を行った後、既存環境から当社提供の KING OF TIME 環境へ移行しました。
この段階では、事前に整理した設定内容とテスト結果をもとに、既存環境の設定内容を確認しながら移行を進めています。
先に要件整理と検証の工程を設けていたことで、移行時に改めて設定内容を検討する項目を減らし、本稼働に向けた環境を整えていきました。
STEP 4|運用変更と定着支援
システムの移行後は、新しい環境を社内でどのように運用していくかを整えていきました。
今回は、システム移行とあわせて残業申請方式も変更しています。運用方法そのものが変わるため、まず一部部署でテスト稼働し、その結果を確認してから全社へ展開しました。
また、システム管理者向けに、設定内容や管理者操作、従業員操作についてレクチャーを行いました。操作方法だけでなく、なぜその設定になっているのかという背景も含めて共有しています。
今後、制度や組織が変わった際に、社内で判断できる範囲を少しずつ広げていくことも、運用を続けるうえでは大切です。一方で、すべてを社内だけで対応する必要はないため、稼働後は軽微な設定変更などをご相談いただける月額サポートも継続しています。
今回の移行で確認したポイント
今回のプロジェクトでは、各段階で次のような点を確認しながら進めました。
| 段階 | 今回確認したこと |
|---|---|
| 現状把握 | 制度・システム設定・実際の運用に相違がないか |
| 設定・検証 | 勤務形態や雇用区分ごとにテストデータを使い、想定していた集計結果になるか |
| 移行 | 移行前に設定内容と検証結果を整理できているか |
| 定着 | 管理者へ設定内容や操作方法を共有できているか |
| 稼働後 | 制度変更や組織変更があった際に、設定について相談・見直しできる体制があるか |
製品を比較している段階では、機能や料金が主な検討材料になりやすい一方、実際の移行プロジェクトでは、制度や現在の運用を整理したうえで要件・仕様を精査し、設定後に検証を重ねる工程にも時間がかかります。
選定だけでなく、移行後の運用も含めて考える
今回のプロジェクトでは、システム選定だけでなく、要件・仕様の整理、設定項目の洗い出し、設定後の検証や運用整備にも多くの時間を使いました。
特に勤務形態が複数ある場合は、それぞれについて設定内容を整理し、実際の勤怠データを使って確認していくため、検証する項目も増えていきます。
今回は、暫定的な設定を行った後にテスト環境で検証し、その結果をもとに設定を調整しました。さらに、一部部署でのテスト稼働を挟みながら全社展開へ進めています。段階的に確認することで、本稼働前に把握できる点を増やし、移行後の運用についても事前に整理することができました。
勤怠管理システムの移行方法は、勤務制度や現在の運用、社内で確保できるリソースによっても変わります。今回の事例も、一つの進め方として参考にしていただければと思います。
あわせて読みたい
36協定・特別条項の発動手続きについて、確認すべき15項目のセルフチェックシートと、書面運用を電子化した事例をご紹介しています。
人事システムの見直しは、「乗り換え前提」にしないほうがいい理由
勤怠だけでなく、周辺の人事システムもまとめて見直したいというご相談の事例です。現状把握から比較案の策定まで、6つのプロセスをご紹介しています。
このような場合は、ご相談ください
・複数の勤務形態があり、設定方法を整理したい
・現在のシステムからの移行を検討しているが、どこから進めるか迷っている
・設定後の集計結果をどのように検証すればよいか確認したい
・導入後の設定変更まで社内で対応できる体制を整えたい
・制度変更にあわせて勤怠設定も見直したい
複数の勤務形態への対応や、現在の設定・運用の整理、システム移行、運用定着まで。
フォスターリンクのキングオブタイム導入支援・設定代行について、支援内容を営業資料で詳しくご紹介しています。
キングオブタイム 導入支援・設定代行の資料をダウンロード →
※本記事は実際のご支援内容をもとに、企業名・業種・規模・実施時期・固有の運用内容を特定できない形に変更・要約してご紹介しています。
※記載内容は作成時点の情報に基づいています。実際の設定方法や必要な対応は、貴社の就業規則・労使協定の内容によって異なります。
