【DXコラム】第3回 作業申請システム ~FAX・メール申請からWEB申請へ~

■「作業申請」とは?

駅や車両内への広告掲出・保守作業を行う前に「作業申請」というステップがあります。
行いたい作業を申請して頂き、その日その場所で安全に作業ができるかの判断をするというステップです。
この業務は長年の間、FAX・メール・Excel・紙などを使用していましたが、工数や管理の煩雑さが課題でした。

1. 従来の方法 ― メールとExcelと紙のリレー

申請から完了報告までの一連の流れは、図1のようなリレー形式で行われていました。
1件の申請が完了するまでに、メールやFAXでやり取りを行いながら、Excelを更新して申請の管理を行っていました。

図1:従来の申請フロー
図1:従来の申請フロー

それぞれの手順は難しくありませんが、申請が届くたびに台帳へ転記し、作業予定の一覧表と目視で突き合わせ、メールとFAXで関係先とやり取りする。

どのファイルが最新版なのか分からなくなり、FAXを送るためにオフィスにいなければならない。今どの申請がどの段階にあるのか、過去にどんなやり取りがあったのかを追いかけるのもひと苦労でした。

また、承認済みの申請書や完了報告は書類として保管され、保管・管理そのものにもコストがかかっていました。

2. なぜシステム化に踏み切ったのか

狙いはシンプルで、「これまで紙やメールで行ってきた運用を、システム上で完結させて簡易化すること」です。具体的には次の3点を目標に置きました。

① 人的労力の軽減と運用コストの削減。
Excelへの転記やFAX・メールの往復といった手作業をなくし、申請・承認にかかる工数を減らす。

② Webでの簡易化・共有化による利便性の向上。
申請の状況を関係者がいつでも同じ画面で確認できるようにする。PCだけでなくスマートフォンからも閲覧できるようにして、現場からのアクセスも容易にする。

③ 保管管理コストの削減。
申請書や報告書を紙で保管する運用をやめ、データとしてシステム上に蓄積する。必要な情報をいつでも簡単に閲覧することができる。

図2:システム化の狙い
図2:システム化の狙い

3.申請から報告まで、ひとつの画面で

新システムでは、これまで書面やメールで行っていた作業申請・承認・帳票の出力・完了報告までの一連の流れが、すべてシステム上で完結するようになりました。
なかでも大きな柱となっているのが、作業可否の判断を支える「イベント登録」の機能です。

駅では、鉄道運行に伴う保守作業などにより、広告掲出作業ができない・避けたほうがよい日程があります。従来はこうした「作業不可日」をExcelで管理し、人が申請と突き合わせて確認していました。

新システムではこの日程を「イベント」として優先度付きで登録しておくことで、申請時に自動でチェックがかかるようにしました。

優先度「高」のイベントと日時・駅・作業場所が重なる申請は、注意文言が表示されそもそも登録できません。
そもそも登録が出来ないということはこれまで目視で否認していた申請を劇的に減らすことになります。
優先度「中」の場合は、注意文言が出たうえで登録は可能、というように段階的に制御しています。

また、申請段階ではなにもイベントがなかった日に、後からイベントが入ることがあります。
そのような場合に備え、申請後に優先度「高」のイベントが後から入った場合は、該当する申請をシステムが自動で否認し、関係者へメールで通知する機能を設けました。

システムが自動で否認を行う為、省力化だけでなく、確認漏れの心配がなくなるという利点があります。

図3:イベント優先度による自動チェック
図3:イベント優先度による自動チェック

申請には「入力中」「申請中」「承認」「否認」「作業完了」といったステータスがあり、一覧画面で検索・並び替えができます。いま何がどの段階にあるのかがひと目で分かります。

承認・否認の結果は申請者へ自動でメール通知されるので、「返信を待って何度も確認する」やり取りも不要になりました。
承認後に修正が必要になった場合も、承認者が「差し戻し」をすれば申請者側で内容を更新できます。

図4:申請のステータス遷移
図4:申請のステータス遷移

作業後の完了報告もシステム上で行います。

作業日を過ぎても報告が済んでいない申請には、毎日「作業未完了に関するお知らせ」メールが自動送信され、報告が完了するまで続きます。

メールは申請者と同じ会社のユーザー全員に届くため、担当者が不在でも組織として報告漏れに気づける仕組みになっています。

3. 従来のフローからの移行

本番切り替えの前に、テストリリース期間を設けました。この期間中は従来どおりの方法で申請しつつ、同じ内容を新システムにも登録してもらう二重運用です。あくまで従来フローの情報を「正」として扱い、システム側に不具合や入力ミスがあっても業務に影響が出ないようにしました。

同時に、不具合や使い勝手を記入してもらうフィードバックシートを配布し、利用者の声を集めながら改善を重ねる形をとりました。
二重登録の負担をお願いすることになりましたが、切り替え後の完成度を上げるうえで欠かせないステップだったと考えています。

テストリリース期間には、利用者の皆様から不具合報告や使い勝手のフィードバックをたくさんいただきました。

ご協力いただいた皆様、本当にありがとうございました。

4. おわりに

どのように業務フローをシステムに落とし込むかという点で苦労しましたが、当初の目的を達成できたと感じています。

最も効果的だったイベント登録は、従来Excelで管理していた頃と比べて工数を約8割削減できました。

このような業務システムは作って終わりではなく、使われながら育っていくものだと思います。
今後も更なる改善をして、関わる方全員の負担を減らせるシステムに磨いていこうと考えています。

コラム一覧に戻る