なぜこの範囲に絞ったのか。なぜ作らなかった機能があるのか。備品・消耗品の購入申請フローを題材に、SupplyFlow の設計意図と実装判断を整理します。
購入申請が、申請中・差戻し・承認済み・発注済み・納品済みのどこにあるかを、申請一覧と申請詳細で確認できるようにしました。
単なるステータス表示ではなく、「承認待ち」「発注待ち」「納品確認待ち」など、購入申請フローの次の対応が分かる設計にしました。
承認者が差戻した理由が口頭やチャットだけで消えないように、申請詳細と再申請画面で差戻し理由を確認できるようにしました。
申請一覧で直接状態を変えず、承認 / 差戻し、発注更新、納品確認をそれぞれ専用画面で行う構成にしました。
業務フローの見える化という主題から焦点がずれる機能は、今回のサンプルでは対象外としています。
帳票・ファイル系
発注書・PDF出力
今回の目的は、発注書を発行することではなく、承認済みの申請が発注済みになった事実を記録することです。
添付ファイル / 見積書管理
見積書や納品書の添付を入れると、ファイル管理が主題になりやすいため、今回は扱いません。
通知・承認系
通知機能（メール / Slack）
通知は便利ですが、このサンプルではまず画面上で状態と次の対応が分かることを優先しました。
承認経路設定 / 多段承認
承認経路を可変にすると、ワークフローエンジン寄りになります。今回は単純な承認者ロールに絞りました。
購買管理系
発注先マスタ管理
発注先管理を作ると購買管理システムに近づくため、今回は自由入力による記録に留めました。
支払処理 / 請求書確認
支払や請求書確認は経理業務に広がるため、今回の購入申請フローからは切り離しました。
集計・管理者操作
高度な集計ダッシュボード
グラフやKPIよりも、申請がどこで止まっているかを見えるようにすることを優先しました。
管理者による割込み更新
管理者を万能ユーザーにすると責任分界が曖昧になるため、管理者は閲覧主体にしています。
SupplyFlow では、備品購入業務のすべてを管理するのではなく、「申請が今どこにあり、次に誰が何をするか」を見えるようにすることを優先しました。
今回あえて作らなかった機能は、将来的に追加可能です。
承認待ち、差戻し、発注待ち、納品確認待ちをメールやSlackへ通知できます。
見積書、納品書、請求書などを申請に紐づけることで、証跡管理を強化できます。
部署や金額に応じて承認者を変える場合は、承認経路設定を追加できます。
発注先を自由入力からマスタ管理に変更することで、入力ゆれや集計の精度を改善できます。
承認待ち件数や発注待ち件数、滞留日数を可視化することで、業務改善に使えます。
公開デモとして運用する場合は、定期的にデータを初期化する仕組みを追加できます。
設計判断が実際の画面にどう反映されているかを紹介します。
LIST VIEW
現在ステータスと次の対応を分けて表示し、申請が今どこで止まっているか、次に誰が対応するかを一覧で把握できるようにしました。
ORDER UPDATE
承認後の状態更新は一覧上で直接行わず、専用画面で記録する構成にしました。発注日と発注先を記録し、状態を発注済みに更新します。
DELIVERY CONFIRMATION
納品確認の内容を記録し、購入申請フローを最後まで追えるようにしました。納品確認メモを残し、納品済みへの更新でフローが完了します。
SupplyFlow は、備品・消耗品の購入申請を題材にした業務フローサンプルです。 目的は、高機能な購買管理システムを作ることではなく、現場で起きやすい「依頼が散らばる」「承認状況が見えない」「発注や納品確認が追いにくい」という小さな業務の詰まりを、最小限の画面と状態管理で整理することです。
そのため、あえて機能を広げすぎず、申請が今どこにあり、次に誰が何をするべきかが分かる構成にしています。
SupplyFlow