部署が自作した申請フロー、全社に移すときに切る位置

こんにちは。シンプルなのに多機能で圧倒的に使いやすい、クラウドワークフロー「kickflow」のメディア運営チームです。

「部署が自作した申請フローを全社に移したい。でも、台帳への転記まで自動でやっている部分はどうするのか」
各部署の有志が承認の流れを自分で作り始めた会社で、情シスからこうした声が聞かれます。
情シスが気にしているのは承認の記録の置き場所で、部署が手放したくないのは転記や通知の自動化だからです。

申請だけを移して転記を手作業に戻せば、管理は一本になります。
一方で、部署が減らしたはずの手作業が戻り、移行への協力を得にくくなります。
そこで今回は、自作フローを段に分けてどこで切るかを決める考え方と、作った人の異動日までに済ませることを解説します。

この記事の要点

• 部署の自作フローは、申請の受付、承認の記録、転記や通知の3つの段からなります。受付と承認は同じ申請画面にあるため、移すときは一緒に動きます
• 転記の段が統制の対象になるかは、転記先が正本か控えかで決まります
• 全社の管理に寄せる方法は、転記まで全社側で組み直す、承認の段だけ移す、所有と記録の置き場所だけ移すの3つです
• 作った人が異動や退職でいなくなると、フローの所有者を替えられなくなる場合があります。承認待ちの申請が流れ切る日を異動日より前に置き、記録の書き出しと所有の追加を済ませます

受付と承認と転記の段

部署の自作フローは、申請の受付、承認の記録、転記や通知の3つの段からなります。
受付と承認は一緒に動き、転記の段だけが転記先によって扱いが変わります。

部署の自作フローとは、情報システム部門を通さずに、利用部門の社員がノーコードの自動化ツールなどで作り、社内に展開している申請や承認の仕組みのことです。
Power Automateで作る承認フローの仕組みは、Microsoft 365でワークフローは実現できる？作成方法やメリット、運用時の注意点を徹底解説で整理しています。

例えば、資材部の担当者が作った「取引先マスタの新規登録申請」があるとします。
申請者がフォームに取引先名や口座情報を入力すると、資材課長、経理課長の順に承認依頼のメールが届きます。
承認が終わると、フローが内容を資材部の取引先台帳に書き込み、資材部のチャネルに完了を知らせます。
支払先としての正式な登録は、経理が承認済みの内容を見て会計システムに入力します。
申請は月に20件ほどで、作った担当者は来年4月に別の部署へ異動する予定です。

この例で支払先の正本は、経理が入力する会計システムです。
転記の段は、もしフローが会計システムに直接書き込んでいれば、承認した内容のとおりに登録されたかを示す段になり、統制の対象に入ります。

承認の段を全社で管理するかは、決裁権限規程や経理規程にその手続きの承認者が書かれているかで決まります。
規程の1行がワークフローのどこに対応するかは、決裁権限規程の1行は、ワークフローの4か所に分かれるで扱っています。

全社の管理に寄せる3つの方法

全社の管理に寄せる方法は3つあり、統制の対象になる段がどこまで及ぶかで選びます。
承認だけが対象なら承認の段を、正本への転記も対象なら転記まで全社側で組み直します。

規程の対象ではない確認でも、自動化が正本を直接書き換えているなら、1行目の方法に寄せます。
正本への書き込みを部署の工夫のまま残すと、誰の承認で正本が変わったかを全社の側から示せないためです。

取引先マスタの例は、承認が経理規程の対象で、台帳は控えなので、承認の段だけ移す方法が合います。

1. 申請者は、全社のワークフローに用意した「取引先マスタ登録」の申請フォームから申請する
2. 資材課長と経理課長の承認は、全社のワークフローの経路で回る。承認者は組織図の役職から決まる
3. 承認が完了すると、全社のワークフローが資材部のチャネルに完了を通知し、あわせて外部のアプリケーションへ完了を送信する
4. 部署の自動化は、その送信を受けて台帳に書き込む

チャネルへの通知を標準の機能で届けられる製品なら、部署が作り直すのは台帳への書き込みだけです。
3から4へのつなぎは、完了を外部に送信する仕組み（Webhook）を持つ製品で組めます。
送信の設定は外部連携を扱う権限を持つ情シスが行い、受け側の仕組みは部署か情シスの開発になります。
設定する前に、送信の対象を取引先マスタの申請だけに、送る出来事を承認の完了だけに絞ります。
対象を絞らないと、ほかの申請の内容まで受け側に届くためです。

同じ知らせが2回届くこともあるため、受け側には同じ申請を二重に書き込まない処理を入れます。
送信の失敗が続くと自動で止まる製品もあり、止まったときに受け側を直す人を決めておきます。

作った人の異動日までに済ませる3つのこと

作った人が異動や退職でいなくなる日が、自作フローを整理する期限になります。
いなくなったあとでは、フローの所有者を替えられなくなったり、その人のアカウントで動いていた部分が止まったりする場合があるためです。

私も、自作フローの相談で、全社のワークフローでできることから説明してしまったことがあります。
打ち合わせの終わりに、知りたかったのは作った人がいなくなっても回し続ける方法だった、と言われました。

例えば、Power Automateでは、ソリューションに入っていないフローは、所有者が全員いなくなると所有者を変更できず、コピーから作り直すことになります。
組織を離れた人の接続を使う段は、失敗する可能性があります。
取引先マスタの例なら、来年4月の異動日が期限です。
退職する承認者のアカウントの扱いは、ワークフローの退職者対応は退職日だけでは片付かないで別に整理しています。

済ませることは3つあり、手作業で代われないものから順に並べます。

1. 承認の記録を共有の場所に書き出す。承認結果が作った人のメールや個人の保存場所に残っていると、異動のあとでは誰が何を承認したかを揃えられないことがある。転記は止まっても手作業で代われるが、承認の記録は代わりがない
2. 切り替え日を決める。切り替えの日に承認待ちになっている申請は自作フローで最後まで回し、新しい申請から全社のワークフローで受ける。承認待ちが流れ切るまで旧フローは作った人の接続で動くため、切り替え日は異動日より承認にかかる日数以上前に置き、流れ切ったあとに1の書き出しを1回で済ませる
3. 部署に残す段の所有を、部署のグループに広げる。旧フローは切り替えまでのあいだ、作った人のほかに直せる人を置く。新しく作る受け側の自動化は、最初から部署のグループの所有で作り、接続をどのアカウントで持つかをツールの管理者と決める

まとめ

部署の自作フローを一覧にし、1本ずつ作った人の異動予定と、転記先が正本か控えかを書き込むところから始めると進めやすくなります。

よくある質問

部署が新しく自作フローを作るのを止めるべきですか？

止めるかどうかより、作る前に届け出てもらう範囲を決めるほうが運用しやすくなります。
例えば、承認者が規程に書かれている手続きと、正本を書き換える自動化だけを届け出の対象にすると、部署の小さな自動化まで情シスが見る必要はなくなります。

誰が受け側の自動化を保守しますか？

作った部署が保守し、止まったときの連絡先を情シスにも届けておく分け方があります。
全社のワークフローの側で送信の対象や送り先を変えると受け側が動かなくなるため、変える前に部署へ伝える手順を決めておきます。

どこまで旧フローを残しておきますか？

承認待ちが流れ切ったら申請フォームへのリンクを社内ポータルなどから外し、新しい申請を受けない状態にします。
フローそのものは、書き出した記録と突き合わせが済むまで、実行を止めて残しておくと確認しやすくなります。
リンクが残っていると、切り替えのあとも古いフォームから申請が届きます。

この記事の整理が、自作フローの一覧を作るときの手がかりになれば幸いです。