静岡の会社で申請業務を見せてもらうと、紙の様式よりも、用紙の端に書かれた付箋や担当者同士の声掛けに本当のルールが隠れています。申請書だけを画面へ移しても、そこが抜ければ現場は結局、電話と紙へ戻ります。
私が受託開発の打ち合わせで先に確かめるのは、入力項目の数ではありません。誰が判断し、どんな場合に戻し、通常どおり進められない案件をどう扱っているか。その流れです。
承認者は役職名ではなく「条件」で決める
「課長が承認する」だけでは設計が足りません。金額、申請の種類、店舗や事業所、取引先との関係によって判断者が変わるからです。静岡市内に本社があり、清水区や焼津市にも拠点がある会社なら、現場責任者の後に本社が見る案件と、拠点内で終わる案件が混ざりやすくなります。
たとえば社内の目安として、少額の備品は拠点長、一定額以上の購入は本部、契約を伴う申請は担当部門も確認する、といった分岐を一件ずつ言葉にします。一般的な正解を当てはめるのではなく、現在の決裁規程と実際の運用を照らす作業です。
承認経路ごとに決めておく項目
- 申請者本人が承認者を兼ねる場合の扱い
- 不在時の代理者と、代理できる期間
- 金額や案件種別で経路が変わる境目
- 途中で担当部署が変わったときの引き継ぎ先
人名を直接登録すると、異動や退職のたびに改修が必要になります。役割と所属を基本にし、誰がその役割を担うかは管理画面で変更できる形が現実的です。
「差し戻し」と「却下」を同じボタンにしない
記入漏れなら直して再提出できます。一方、予算外や規程外で受け付けられない申請は、内容を直しても進みません。この二つを同じ「戻す」で処理すると、申請者は次に何をすべきか分からず、口頭確認が増えます。
差し戻しでは、戻す相手、修正箇所、再提出後にどの段階から審査を再開するかを残します。却下は終了扱いとし、再申請するなら別の申請番号を発行する。申請者による取り下げも別にしておくと、後から件数を見たときに判断の経緯が崩れません。
理由の入力欄は必須にしたいところです。ただし長文を強制すると使われません。「添付不足」「内容確認」「予算確認」などの選択肢に短い補足を添える形なら、現場の負担と記録の質を両立しやすくなります。
急ぎ案件をシステム外へ逃がさない
製造業の部材不足、建設現場の追加手配、店舗設備の故障。業務には、通常の順番を待てない場面があります。ここを想定せずに運用を固めると、「急ぎなので先に進めました」という連絡がチャットや口頭だけに残り、システム上の記録と実態がずれます。
例外は抜け道ではなく、記録できる正規ルートにする
緊急申請、事後承認、添付書類の後日提出、上位者による代理判断など、起こり得る例外を洗い出します。そのうえで、例外を選べる人、理由、期限、後から確認する人を設定。通常案件と区別できる印も必要です。
例外の利用が増えたら、現場が規則を守らないと決めつけず、通常経路が遅すぎないかを見ます。仕組みの改善材料になる数字です。
開発前に「実際の十件」を時系列で追う
会議室で理想の流れだけを聞くと、例外はなかなか出てきません。そこで私なら、直近の申請から通常案件、差し戻し、急ぎ案件を含む十件程度を目安に選び、受付から完了までを時系列で並べます。個人情報や取引情報は必要な範囲に絞ります。
- 誰が、いつ、何を記入したか
- 誰へ渡り、何を見て判断したか
- 止まった時間と、そのときの連絡方法
- 紙以外に転記した台帳や表計算があるか
- 最後に原本をどこへ保管したか
この確認をすると、入力画面より先に作るべきものが見えてきます。申請一覧の検索かもしれませんし、承認待ちの通知、添付資料の不足表示かもしれません。受託開発では、初回に作る範囲と次回改善へ回す範囲を分ける材料にもなります。
完成後に困らないため、履歴と権限まで決める
承認済みの内容を誰が修正できるのか。修正したら再承認が必要か。申請者、承認者、管理者が見られる範囲も、着手前に線を引きます。特に従業員情報や見積書を含む申請は、全員が検索できる設計にしないこと。
残したい履歴は、操作した人、日時、変更前後、判断理由です。保存期間や出力方法は、社内規程や税理士など関係する専門家の確認を踏まえて決めます。運用開始後は、承認にかかった日数、差し戻し理由、例外利用の件数を月ごとに見れば、次に直す場所を感覚ではなく事実から選べます。
紙を持ち込むところから相談できます
NIR株式会社では、今ある申請書や承認印の流れを一緒に確認し、必要な機能と後回しにできる機能を切り分けています。まだ要件書がなくても、普段使っている用紙と困っている場面が分かれば整理を始められます。静岡の拠点事情や現場の動きも含めて検討したい場合は、システム導入・開発を無料で相談するから状況をお聞かせください。