Pleasanterで社内の届出業務をシステム化することになり、複数の承認者を経由するワークフローを設計しました。申請フォームそのものは比較的早く形になります。しかし実際に業務として使おうとすると、「差戻しは誰へ戻すのか」「承認途中の申請は誰まで見られるのか」「完了後も編集できてよいのか」「過去日で申請された場合はどうするのか」といった判断が次々に必要になりました。この記事では、画面を作る前に決めることになった運用ルールを、実際に迷った順に整理します。現在は本番で運用しています。
画面を作る前に、承認の順番を一つずつ言葉にした
今回対象になった業務は、担当者が登録して終わる申請ではありませんでした。担当者が申請した後、一次確認者、管理部門の承認者、業務上必要な最終確認者へ順番に回し、すべての確認が終わった後で担当者へ完了を通知する流れです。
既存業務では関係者が経験で理解している部分もありましたが、Pleasanterへ設定するには曖昧なままでは進められません。「最初の承認者は誰か」「次の承認者は固定か」「差し戻されたらどこへ戻るか」「承認者が不在ならどうするか」といった点を、一つずつ確認していきました。
この作業を通じて感じたのは、ワークフロー構築で時間がかかるのはボタンや項目の設定ではなく、現行業務を説明できる形にすることだという点です。人が暗黙的に処理していた判断も、システムではルールとして表現する必要があります。
Pleasanterの設定を始める前に、申請開始から完了までを一本の流れとして整理したことで、必要なステータスや通知、権限も決めやすくなりました。
最終的には承認段階が分かるステータスを用意した
現在の申請がどこまで進んでいるかを一覧から判断できるよう、承認段階ごとにステータスを分けました。最終的にはこの構成です。
- 申請中
- 一次確認中
- 管理部門確認中
- 最終確認中
- 完了
- 必要に応じて差戻し状態
ただし、設計時にはステータスを細かくしすぎると利用者が現在地を理解しづらくなるため、承認者や利用者から見て意味のある段階に絞ることを意識しました。システム内部の都合だけで状態を増やさないことは重要です。
承認よりも先に考えておきたかったのが差戻しだった
ワークフローを考え始めると、どうしても「承認ボタンを押せば次へ進む」という正常ルートを中心に設計してしまいます。しかし、実際の運用では入力漏れや内容確認による差戻しが発生します。
そこで今回の設計では、差戻し時にコメントを残す運用を組み込みました。単に状態を一つ前へ戻すだけでは、申請者は何を修正すべきか判断できません。「日付を修正してください」「添付資料を追加してください」といった理由を残すことで、差戻された側が次の行動を取れるようにします。
また、最終確認者から差し戻す場合に、直前の承認者へ戻すのか、申請者まで戻すのかも業務ルールとして考える必要があります。Pleasanterで機能を作れるかどうかよりも、そのとき業務としてどうしたいのかを先に決める必要がありました。
差戻しは例外処理のように見えますが、実運用では必ず発生し得ます。承認ルートと同じ段階で設計しておく方が、後から作り直す範囲を減らせます。
回付中と完了後で、見せ方と編集権限を変えることにした
設計に時間がかかったもう一つの項目が権限です。申請途中の情報をPleasanterの利用者全員へ見せる必要はありません。そのため、回付中は申請者、現在の承認者、管理上必要な利用者など、業務上必要な範囲だけが閲覧できるようにしました。
さらに、「閲覧できること」と「編集できること」を分けて考えました。承認途中に関係のない利用者が内容を書き換えられると、承認した内容そのものが変わってしまう可能性があります。
一方、承認完了後は、情報共有の目的から閲覧範囲を広げています。ただし、承認済みデータが後から自由に変更されるのは避けたいため、完了後は原則として読取専用にしました。
ワークフローでは「誰が操作できるか」だけでなく、「いつから誰に見せるか」「完了後に誰が変更できるか」まで決めておかないと、運用開始後に権限変更が増えやすくなります。
開始日は過去日を許可し、終了日だけ開始日＋1年で制限した
今回の届出には開始日と終了日を入力する項目があり、終了日は開始日から1年以内にする必要がありました。そこで、終了日が開始日の1年後を超えていないかを確認する入力制御を設けました。
設計時に迷ったのが開始日です。システムだけを考えれば、「開始日は今日以降」と制限した方がデータはきれいに見えます。しかし実際の業務では、届出を忘れていて開始日を過ぎた後に申請する可能性もあります。
その場合、過去日を入力できないようにすると、実際の開始日とは異なる日付を利用者に入力させることになります。そこで、開始日については過去日も許容し、終了日だけを「開始日＋1年以内」に制限する仕様にしました。
この判断は小さなものですが、業務システムでは重要です。入力制限を厳しくすれば正しいデータになるとは限りません。現実に起こるケースを受け止められるルールにした方が、結果としてデータの正確性を保ちやすくなります。
承認後もすべてPleasanterに閉じ込める設計にはしなかった
今回の業務では、承認完了後に担当者がPDFを出力し、既存の掲示や後続業務へ利用する想定がありました。そのため、申請から最後の業務までをすべてPleasanter上で完結させる設計にはしていません。
システム化というと、紙をゼロにすることや既存業務を全面的に置き換えることが目標になりがちです。しかし、そこまで範囲を広げると関係者が増え、導入までの負担も大きくなります。
今回は、申請、承認、進捗確認、履歴管理という部分をPleasanterへ移し、その後はPDFを使って既存業務につなげる形を選びました。少なくとも申請書を人が持ち回る必要はなくなり、「現在誰の確認待ちなのか」をシステム上で管理できるようになります。
すべてをデジタル化すること自体を目的にせず、どこを変えると業務上の効果が大きいかを基準に範囲を決める考え方です。
本番前に、少人数で1週間の運用テストを行った
本番利用前には、管理部門内の数名で約1週間の運用テストを行いました。確認したのは、承認順、差戻し後の再申請、通知、権限切替、日付チェック、PDF出力です。
作成者が自分で操作すると、どこに何があるか分かっているため、無意識に正しい手順を踏んでしまいます。実際に申請する人に触ってもらわないと、どこで迷うかは見つかりません。そのため、いきなり全社へ公開するのではなく、少人数で一通り流してから本番運用に入りました。
ワークフロー作成では機能より業務ルールの整理が先だった
今回Pleasanterで承認ワークフローを設計して分かったのは、システムの機能を知っているだけでは業務システムは作れないということです。
誰が承認するのか。差し戻すときはどこへ戻すのか。申請途中は誰が閲覧できるのか。完了後は編集可能なのか。開始日の過去入力を許すのか。承認後のPDFを誰が使うのか。こうした業務上の判断が決まった後に、初めてPleasanterのステータスや権限の設定が決まっていきました。
Pleasanterの柔軟さを活かすには、最初から機能を盛り込むより、現在の業務を一つずつ整理し、必要な部分だけを設定へ落とし込む方が進めやすいと感じました。
コメント