サプライチェーンは「企業横断型ワークフロー」だ

業務プロセス管理（BPM）活動の多くは、『企業内』の作業手順（ワークフロー）を管理し、そのカイゼンを図る。
しかし実際にアレコレ作業手順を見直す活動をしていると、『企業内』より『企業間』の業務プロセスの方がヤリガイがある事に気づく。主な理由は以下の通りだ。

• 業務定義しやすい： そもそも各社の役割分担が明確である
• 通信に無駄が多い： 文書（メール／FAX／郵送）のやり取り手間を許容している
• 保存に無駄が多い： 各社それぞれに、それぞれの方法でデータ管理している
• 丁寧な改善を行う： 社外の人に迷惑はかけられないと言う緊張感をもって改善プロジェクトを遂行する

※（もちろん『企業間業務プロセス』の場合、コンセンサスを図るのがタイヘン）

今や「電子メール」ですら歴とした"文書"だ。もちろん日本の法律においても裁判証拠になる。「紙」の文書は少しずつでも減らしていきたい。

以下のワークフロー定義は、取引の多い企業同士における「見積書＋発注書＋発注請書」を全面的にペーパレス化（電子文書化）する事を主眼においている。平たく言えば『得意先様用発注システム』だ。（SCM）

＜各タスク名＞
1.見積依頼、2.見積回答予定入力、3.見積書作成、4.見積書承認、5.見積書内容の発注、6.修正対応、7.修正承認、8.受注確認

[見積処理: 「3.見積書作成」画面]

＜各プロセスデータ名＞

• 件名≪見積依頼者名　例：佐藤（Ａ商事） 6月7日8時9分≫

▼見積依頼情報▼

• 日付型: 希望納期
• テーブル型: 発注内容
• 選択型: 商品番号のリスト
• 数値型: 数量
• 掲示板型: 備考通信

▼見積書情報▼

• 数値型: 見積総額
• 文字型(複数3行): 見積書備考
• ファイル型: 見積書ファイル

▼フローコントロール▼

• 日付型: 見積回答予定日
• 選択型: リーダ確認フラグ(要リーダ確認/不要)
• 選択型:承認フラグ( 承認/却下)
• 選択型: 注文フラグ(発注/要修正/破棄)

この作業手順（ワークフロー）定義は、見積依頼にはじまり見積書作成・発注・受注まで、スムーズに進めば「1→2→3→5→8」の5ステップで処理が終了す る。見積依頼額が高額な場合などリーダ決裁が必要な場合であれば「1→2→3→4→5→8」の6ステップだ。発注側が価格交渉をする場合には 「1→2→3→4→5(→6→7→5)→8」の様に「5→6→7→5」の部分でループする事になる。

以下のワークフロー定義は、タスク『6.修正対応』をタスク『3.見積書作成』に同化し、シンプルに表記しなおしてみた。しかしこの場合「価格交渉中案件の存在」を明示的に認識しづらくなる。
ちなみに『注文フラグ』が「発注」になっている終了プロセスの一覧は、「過去の発注一覧」と言うことになる。

＜各タスク名＞
1.見積依頼、2.見積回答予定入力、3.見積書作成、4.見積書承認、5.見積書内容の発注、8.受注確認

• 見積〜受注処理
• 見積〜受注処理-単純化