申請フォームに必要事項を書いて、資料を添付し、承認に回す。
ここまではいつもの流れですが、しばらくして画面を確認すると、申請は差し戻されている。
結果を見て、申請者はこう思います。
「これ、前回は同じ条件で通っていたはずなんだけどな」
承認業務の話を聞いていると、こういう場面は珍しくありません。
承認ルート自体は決まっていますし、過去の履歴も残っています。それでも前回は通った申請が、今回は差し戻されることがあります。
予算の状況が変わったのかもしれないし、前回だけ急ぎの事情があったのかもしれません。
前回と何が違ったのか。承認者は今回、どこを気にしたのか。
そこが分からないままだと、次に似た申請をするときも、また同じところで迷うことになります。
承認業務でも、AIで省ける手間はいくつもあります。
長い申請文を短くまとめたり、書き漏れや資料不足を見つけたりすることは、AIでもかなりやりやすくなっています。過去の似た申請も探せます。申請する側からすれば、毎回ゼロから文章を考えなくて済みますし、承認する側も、まず要点を見てから必要なところを確認できる。
申請書を整えるだけでも手間は減りますが、実際の承認で止まる理由は、書き漏れや資料不足だけではありません。
過去の履歴を見ていくと、金額も申請理由もよく似た案件が出てきますが、前回はその条件で通っている。
ここまでは分かります。
ところが、残っているコメントが「問題ありません」の一言だけだと、その先が見えません。何を確認したうえで「問題ない」としたのかが分からず、今回も同じ考え方でいいのか判断に迷います。
前回は急ぎだったから認められたのかもしれませんし、何か別の条件を確認したうえで通していたのかもしれません。
そこが残っていなければ、似た案件を見つけても「今回も同じでいい」とは言い切れません。
結局、当時の事情を知っていそうな人を探して、
「前回は通っていますが、今回も同じ考え方で大丈夫ですか」
と確認することになります。
現場では、「承認者によって基準が違う」という話もよく聞きます。
「この人に回ると細かく見られる」
「この部長なら比較的すぐ通る」
「たぶん一度は差し戻される」
承認者が違えば、見るところも変わります。予算を預かる立場なら費用対効果が気になるでしょうし、契約やセキュリティに責任を持つ人なら、別のリスクに目が向きます。
その違いは「承認」「差し戻し」という結果だけでは見えてきません。
申請者から見れば、前回は通ったのに今回は止まった。その理由が分からなければ、「承認者によって基準が違う」と感じるのも無理はありません。そうなると、次からは差し戻されないように先回りするようになります。
資料を念のため多めにつけたり、申請前に上司へ見せたりする。内容によっては、関係部署にも先に聞いておく。
一つひとつは大した確認ではなくても、積み重なれば、正式な承認に回す前に何度も確認することになります。
承認画面だけを見ていると、この時間はなかなか見えてきません。
アシストAIテラス（AIT）でも、承認そのものをAIに任せることを目指しているわけではありません。
例外として認めるのか、どこまでのリスクなら受け入れるのか。そこは、最終的に承認する人が決めるところです。
ここでいう承認判断の再現性は、毎回同じ結論を出すことではありません。どの条件を見て、なぜその判断になったのかを、次の人もたどれる状態にすることです。
値引申請のような業務では、値引率によって申請不要で進められるもの、自動承認できるもの、部門長や事業部長の判断に上げるものを分けることがあります。
大事なのは、AIが「承認してよい」と決めることではなく、今回の申請がどの基準に当てはまり、過去の似た申請では何が論点になったのか、承認者が見るべき条件はどこなのかを、判断前にそろえることです。
申請者が「この条件なら誰に回すべきか」「今回は何を説明しておくべきか」を把握したうえで申請できれば、承認者も最初から論点の確認に入れます。
今回の申請と過去の案件を比べて、「前回と違うのはここです」と先に出せるだけでも違います。以前似た理由で止まった案件があれば、そのとき何が問題だったのかも知りたい。社内規程についても、承認者に回ってから初めて気づくのでは少し遅いでしょう。
ここまで分かっていれば、承認者も申請書を最初から全部読み直す必要がなく、今回どこを確認するかに目を向けられます。
「これで大丈夫ですか」
と丸ごと判断を預けるのではなく、
「前回と違うのは、対象範囲と費用の2点です。今回はここを確認したいです」
と話せる。
AIに任せるのはここまでです。
承認システムを見れば、履歴そのものはかなり残っています。
誰が申請して、誰が承認したのか。金額や申請日、最終的な結果も残っています。
でも、次に似た申請をする人が本当に知りたいことは、少し違います。
「この申請は、なぜ通ったんだろう」
「こっちは、何が引っかかって差し戻されたんだろう」
結果は残っていても、その理由までは残っていない。承認履歴ではそんなことがよくあります。
「差し戻し」と一口に言っても、理由はかなり違います。
「資料不足」と書かれていても、添付漏れなのか、費用対効果の説明不足なのか、法務確認が終わっていないのかでは、次に取るべき行動が変わります。
「確認してください」というコメントだけでは、次の申請者はまた同じ場所で止まります。
だから本当は、「添付資料が足りない」「予算の前提が説明されていない」「規程上の例外に当たる」といった形で、次の申請者が何を直せばいいのか分かるところまで理由を残したいところです。
理由の違いが残っていなければ、過去の差し戻しを次の申請に生かせません。
例外として承認された案件も同じです。「通った」という結果だけではなく、なぜ今回は例外として認めたのか。その理由まで残っている必要があります。
判断の理由まで残っていれば、「前回も通ったから」だけで考えなくて済みますし、前回はどんな条件で通ったのかを見て、今回は同じ条件なのかを確かめればよくなります。
承認業務を改善するとき、承認までにかかった時間は分かりやすい指標です。
3日かかっていたものが1日になれば、改善したように見えますが、その裏で、申請者が承認に回す前に何人もの人へ確認していたら、業務全体の手間はあまり減っていません 。
承認が終わっても「結局、何が基準だったのか」が分からなければ、次の申請でもまた同じ確認が繰り返されます。同じ理由で何度も差し戻されているなら、個々の申請者の注意不足ではなく、過去の判断が次の申請に生かせる形になっていない可能性があります。
AIによって、申請書を記述する時間が10分短くなったとしても、そのあと30分の確認が残っていれば、結局現場の進み方はあまり変わらないのです。
AIに任せたいのは、過去の申請内容、承認コメント、差し戻しの理由、添付資料などから、今回の申請で確認されそうな論点を先に揃える部分です。
前回通った申請と今回の申請は、何が同じで何が違うのか。
過去に似た条件で差し戻されたとき、何が足りなかったのか。
ここが申請前に見えていれば、申請者の出し方は変わります。
「これで大丈夫ですか」と聞くのではなく、「過去の承認案件と比べると、今回違うのはこの条件です。以前差し戻された論点は先に補足しています」という出し方に近づきます。
これで、承認者も毎回ゼロから前提を確認するのではなく、本当に見るべき例外やリスクから確認できます。
重要なことは、すでに業務の中に残っている承認履歴や差し戻し理由を、次の申請で使える形にすることです。
承認が早くなったかだけでなく、次の申請で同じ確認が減っているか。
承認業務を改善するときは、そこまで見ておきたいと思います。