勤怠エラーの自動通知を現場で実証｜RPA・業務自動化の導入事例で月間83時間を削減
グループ子会社Bの前田千尋です。「勤怠エラーの自動通知」は一度目のやり方では思うような成果が出ず、設計を見直したテーマです。今回は、最初につまずいた点と、RPA・業務自動化として現場に受け入れられるまでに変更した内容を中心に紹介します。成功結果だけでは判断しにくいため、検証に使った47件の記録も残しました。
当初の状況は、自動化済みの処理でも担当者しか例外対応を理解しておらず、休暇時に停止する問題がありました。現場説明では理解を得られたつもりでしたが、実際の作業では例外が多く、担当者が従来手順へ戻る場面がありました。そこで利用率だけを見るのをやめ、使わなかった理由、途中で止めた理由、誰に確認したかを記録し、技術上の問題と運用上の問題に分けました。
再設計では、処理を入力、判定、登録、通知の四つに分け、各工程でログとスクリーンショットを保存する設計にしました。全体展開をいったん止め、影響の小さい範囲で5週間の再試行を実施しました。毎週のレビューでは管理者が結論を決めるのではなく、実際に操作した人から改善案を出してもらい、次の一週間で一つだけ変更して差を確認しました。
見直し後は「月間83時間を削減」となり、確認漏れや再作業も8％減少しました。特に、例外時に手作業へ戻す基準を明確にしたことで、止まったまま放置されるケースが減りました。ただし、短期間の数字だけで成功と判断せず、担当者交代後も同じ結果になるかを追加確認しています。
現在も、自動化前の業務に無駄が残っていたため、処理そのものを見直してから再構築する予定です。今回の経験から、機能の多さより、やめる条件と助けを求める先が明確であることが定着には重要だと分かりました。改善履歴には採用しなかった案と理由も残し、次の担当者が同じ検討を繰り返さないようにしています。
同じような自動化を行っている拠点では、画面変更への追従や担当者不在時の復旧をどのように運用していますか。保守工数の実績もぜひ共有してください。
※この投稿はデモンストレーション用のサンプルです。人物や企業、内容は架空のものです。
コメント
九州工場で生産管理DXと表計算業務の自動化を担当しています。「勤怠エラーの自動通知」で月間83時間を削減という結果は参考になります。画面変更で停止した場合、現場で再実行できる範囲とシステム担当へ連絡する範囲をどう分けていますか。
木村遼さん、具体的な質問をありがとうございます。入力不備は現場で修正し、画面構造や認証の変更はシステム担当へ連絡する二段階にしました。まだグループ子会社B内の検証結果なので、「勤怠エラーの自動通知」の次の測定値も追記します。
本社DX推進室から、近いテーマに取り組んだ経験を共有します。完全自動化を目指すより、例外だけ一覧にして人が確認する方式のほうが定着しました。今回の勤怠エラーの自動通知でも、適用条件を一緒に残すと横展開しやすいと感じました。
鈴木健太さん、実例の共有ありがとうございます。ご指摘の点は今回も議論になりました。例外は無理に自動処理せず、理由付きの一覧で担当者へ戻しています。試行中の例外率は約6％でした。 「勤怠エラーの自動通知」の横展開資料には、うまくいかなかった条件も追記します。
製造データ基盤と拠点横断のデータ活用の観点から拝見しました。共通部品を更新した際の影響範囲を一覧化すると、横展開後の保守事故を減らせると思います。特に「勤怠エラーの自動通知」は結果だけでなく、変更前の判断基準も共有されると再利用しやすいです。
東日本工場でも「勤怠エラーの自動通知」への関心があります。月間83時間を削減という効果が別拠点でも再現するか、まず少量データで比較してみたいです。使用した確認表や手順書で共有可能な部分があれば参考にさせてください。
品質改善の拠点比較と再発防止策の横展開を担当している立場から、運用負荷も気になりました。効果が出た期間の後に担当者が変わっても続くか、例外処理と保守時間を一か月ほど追うと、成功事例としての再現性がより伝わると思います。勤怠エラーの自動通知の続報を期待しています。