社内承認の自動化：明確なルートと期限を決める

社内承認の自動化とは、休暇から経費、値引きまで、すべての申請が決まったルートで進むようにすることです。種類と金額に応じて誰が承認するのか、その人が不在のとき誰が代わるのか、エスカレーションまで何時間待つのか、そして誰がいつ何を承認したかを示す記録です。シリーズの第 2 回では、業務を実際の動きどおりに可視化しました。おそらく承認待ちが最も長い工程として浮かび上がったはずです。全 7 回の第三回となる本記事では、承認ルートを作る 4 つの要素と、直近 10 件の申請とそれぞれの待ち時間を追跡する演習を紹介します。

自動化がしばしば承認から始まる理由

承認は形の上では小さな工程ですが、影響は大きなものです。申請そのものは数分で済んでも、上司が出張中だったり、メッセージが忙しい WhatsApp のチャットに埋もれたり、申請者が誰が決めるのかさえ知らなかったりして、何日も止まってしまいます。誰かの落ち度ではありません。メッセージでの承認はチームが小さいうちはうまく機能しますが、社員や拠点が増えるたびに負担が増していきます。

承認は最もわかりやすい最初のワークフローです。ルールが通常すでに経営陣の頭の中にあるからです。申請の種類、金額、責任者です。ここでいうワークフローとは、社員が手で持ち回るのではなく、書かれたルールに従って申請が自動的に次の工程へ進むことを指します。この考え方は多くの申請に当てはまります。休暇、経費と小口現金、購買申請、見積もりの値引き、契約変更などです。

承認マトリクス：誰が何をどの上限まで承認するか

最初の要素は承認マトリクスです。ひとつの問いに答える一枚の表です。この種類の申請で、この金額なら、誰が承認するのか。人が辞めるたびに変わらないよう、名前ではなく役職で書きます。

• 申請の種類：休暇、経費、購買、値引き、契約変更。種類ごとに一行ずつ設けます。
• 上限：決裁者が変わる金額、期間、値引き率です。他社から借りた数字ではなく、自社が実際に運用している上限を使います。
• 承認者：各上限の範囲内で承認する役職と、二段階の承認が順番に必要になる場合です。
• 条件：申請が承認者に届く前に添付すべきもの、たとえば見積書や休暇残日数です。これで申請が不備で差し戻されるのを防げます。

すでにほかで作ったものを作り直す必要はありません。購買申請についてはPurchase Requests and Approval Limits: Who Signs What?で、休暇と労働法の要件についてはLeave Under Saudi Labor Law: An Approval Path, Not WhatsAppで詳しく解説しました。ここで大切なのは、すべての種類をシステムが従えるひとつのロジックにまとめることです。

承認者が不在のときの代理人

二つ目の要素は代理人です。申請を最も止めるのは却下ではなく、承認者の不在です。休暇、出張、長い会議などです。そのため、マトリクスの各役職には事前に指名した代理人が必要で、3 つのシンプルなルールを設けます。

• 期間を区切った委任：二つの日付で始まり終わり、承認者が戻った後も開いたままにはしません。
• 上限付きの委任：代理人は小さな申請だけを扱い、大きな申請は権限者を待つかエスカレーションします。
• 委任は記録に残す：本人の名前だけでなく、誰が誰の代わりに承認したかを記録します。

これで承認者は休暇中にスマートフォンを開く必要がなくなり、社員も誰に聞けばよいか迷わなくなります。

期限とエスカレーション

三つ目の要素は期限です。承認の各工程には経営者が決めた最長時間が必要で、それを過ぎたら申請を宙に浮かせるのではなく、決まった動きが起きるようにします。エスカレーションとは、期限が過ぎたときに申請が自動的に上位の階層または代理人へ回ることです。書くルールはシンプルです。承認者が期限内に応答しなければシステムがリマインダーを送り、さらに二つ目の期限が過ぎたら申請は上位者または代理人へ回ります。

期限は上司へのプレッシャーではありません。会社として、申請の種類ごとにどれだけ待てるかを事前に決めたということです。緊急の修理依頼と年間契約の変更は同じではありません。本記事の演習から得た現実的な期限から始め、ひと月運用した後に見直してください。

承認記録：誰がいつ何を承認したか

四つ目の要素は記録で、監査証跡とも呼ばれます。各申請について、誰が提出し、誰が承認または却下し、いつ、どの権限で、どんなコメントを付けたかを保存する、編集できない一覧です。内部監査担当者、監査人、経営陣の質問に、古いチャットを探さずに答えられます。契約書や覚書など、決定に文書への署名が必要な場合は、Electronic Signatures in Saudi Arabiaを参照し、システム内の承認で足りるのはどんな場合か、電子署名が必要なのはどんな場合かを確認してください。

休暇などの申請には社員の個人データが含まれます。SDAIA のサイトで公開されている個人データ保護法（PDPL）は、第 19 条で、管理者は個人データを保護するために必要な組織的、管理的、技術的な措置と手段を講じなければならないと定め、第 31 条で、管理者は個人データの処理活動の記録を規則で定める期間保存すると定めています。権限が明確で記録がはっきりした承認ルートは両方に役立ちますが、期間と内容は施行規則が定めます。これは法的助言ではありません。SDAIA または弁護士に確認してください。

Origami の視点

私たちは、システム、アプリ、システム連携、AI ソリューションを開発するサウジアラビアのテクノロジー企業です。承認ルートを作るときは、どんな画面よりも先に、経営陣と一緒に紙にマトリクスを書くことから始めます。誰も合意していないルールをシステムは適用できないからです。そして、申請が実際に存在するシステムとルートをつなぎ、誰もデータを再入力しなくて済むようにします。

例外が可能で、かつ記録に残ることも大切にしています。緊急の申請は道を見つけますが、それは別のメッセージではなく記録上の痕跡を伴います。規律と柔軟性のこのバランスが、私たちの開発の土台です。詳しくは私たちのサービスのページをご覧ください。

演習：直近 10 件の承認申請を追跡する

5 営業日のあいだに、同じ種類の直近 10 件の承認申請を集め、それぞれについて次を記録します。

• いつ提出されたか、最終承認がいつ届いたか、その差は何時間か。
• 何人の承認者を経たか、不在の人がいたか、誰が代わったか。
• 不備で何回差し戻されたか、どの情報が欠けていたか。
• 承認がどこに保存されたか：システム、メール、WhatsApp、紙のどれか。
• 今日、誰にも聞かずに、誰がいつ承認したかを証明できるか。

ここで計算した平均待ち時間が最初の期限の基準になり、どんな一般的な数字よりも正直です。

次回

申請が明確なルートで進むようになっても、時間のかかる作業がもうひとつ残ります。文書をシステムに打ち直す作業です。シリーズ第 4 回「手作業のデータ入力：システムが文書を読むとき」では、システムが仕入先の書類、納品書、申込書からデータを取り出し、不確かなものを人に回して確認してもらう方法を解説します。

出典

• 個人データ保護法（PDPL）— サウジアラビアデータ・人工知能庁（SDAIA） — 個人データを保護する組織的、管理的、技術的措置に関する第 19 条と、処理活動の記録に関する第 31 条。
• 個人データ保護法施行規則 — SDAIA