, ,

ERP知識シリーズ　ビジネスプロセスフローの書き方　《後編：フローの設計技法》

前編では、ERP導入プロジェクトでよく見られるビジネスプロセスフローの問題点を７つ取り上げ、それらが業務構築にどのような影響を与えるかを明らかにしました。問題の本質は、業務を操作や機能の連なりとしてではなく、「構造」として捉える視点が欠けていることにあります。
後編では、そうした問題を解消し、ユーザーが「新しい業務」をスムーズに理解できるTo-Beプロセスの設計方法について解説します。

ここで紹介する設計技法は、ERPにあらかじめ用意された業務フローの質を評価する際の視点にもなり、またCRPで検証するシナリオ作成のベースにもなります。単に「図を描く」のではなく、「業務を理解し、活用できる状態にする」こと、それが本稿の目的です。

ビジネスプロセスフローは三層構造で設計する

ERPプロジェクトで作成するプロセスフローは、すべてを一度に描くのではなく、3つの階層に分けて段階的に設計していきます。

  1. 全体のつながりを俯瞰する「鳥瞰図（レベル1）」
  2. 実業務の流れと判断を表現する「ビジネスプロセスフロー（レベル2）」
  3. 操作単位に落とし込んだ「オペレーションフロー（レベル3）」

レベル1の鳥瞰図は、業務を「販売予算」「販売予測」「在庫計画」「生産計画」「受注」「引当」「出荷」「月次締処理」「年次締処理」といった業務単位ごとに区切り、業務の大まかな流れとつながりを時系列で整理します。

なお、生産形態が見込み生産（Make to Stock）か受注生産（Make to Order）かによって、受注の位置づけが変わることがあります。見込み生産では受注が出荷の直前に来ますが、受注生産では受注が生産より前に入ります。このような違いがある場合でも、鳥瞰図は基本的に1つに統一し、「受注がどのタイミングで入るか」を分岐として表現すると良いでしょう。こうすることで、業務単位そのものの構成は共通のまま、生産形態の違いに柔軟に対応できるフローとなります。

鳥瞰図の目的は、詳細に入りすぎずに業務全体のつながりを把握することです。各プロセスがどう連携するのかを一目で捉えられる設計が求められます。

レベル2のビジネスプロセスフローは、鳥瞰図で示した業務単位を始点と終点として、CRPで実機検証できるレベルまで分解したものです。後述する内容の多くは、このレベル2のプロセスフローをより良いものにするための設計技法に関するものです。それはこのフローの出来栄えがTo-Beプロセス全体の質を大きく左右するからです。

なお、レベル2については、ERPベンダーがあらかじめ用意しているTo-Beプロセスフローを活用するケースが一般的です。その際には、これから紹介する設計技法をチェックリストとして活用し、用意されたフローの質を評価しながら、必要に応じて改善していくことが求められます。

レベル3のオペレーションフローは、CRPで検証済みのビジネスプロセスフローをベースにして、そのフローに記載された業務処理を実際に“どの画面・どの手順で操作するか”に落とし込んだものです。目的は、To-Be業務を「どの画面で・どの項目に・何を入力するか」まで明文化することにあります。ここでは、以下の観点でフローを整理します。

  • 使用するアプリケーションや画面ID
  • 入力する項目とその意味
  • 使用する機能キー、メニュー選択
  • 例外が発生した場合の操作手順

このフローは、受け入れテスト、教育マニュアル、運用手順書へと展開される情報源でもあります。つまり、ビジネスプロセスフローが「業務を理解するための図」であるのに対して、オペレーションフローは「業務を実行するための図」です。

次からは、レベル2のビジネスプロセスフローを中心に解説していきます。

業務の始点はAs-Is、フロー全体はTo-Beで描く

フローには必ず「始点」と「終点」があります。これは図の出発点と到達点を示し、業務としての因果関係やプロセス間の接続性を定義するものです。

始点とは、業務が動き出す“きっかけ”を表す

始点は、その業務がどのような条件で開始されるのか、つまりトリガーイベントを明示するものです。大きく以下の3つに分類されます：

  • 外部イベント：顧客からの注文、仕入先からの分納の連絡など
  • 内部イベント：上流プロセスの完了、工場での仕損など
  • 定期イベント：毎月1日、毎週金曜などスケジュール駆動の処理

始点は原則としてAs-Is業務に基づいて設計されるため、ユーザーにとって最も直感的に理解しやすい要素です。例えば受注処理であれば、「顧客からのEDIデータ受信」、月次処理であれば「毎月1営業日22時にバッチを開始」など、現行業務で実際に発生しているトリガーを起点として描かれるため、To-Beの業務像も現実感を持ってイメージしやすくなります。また、As-Is業務の始点を網羅しておくことで、業務の実行タイミングを把握するだけでなく、業務の漏れの防止にもつながります。なお、To-Beではこの開始手段が自動化されるなどの変更が加わる可能性があるため、その点も含めて設計上は意識しておく必要があります。

処理の中身はTo-Beで再設計する

始点がAs-Isに基づいていても、それ以降の処理はTo-Be業務に沿って再構成していく必要があります。新しいERPで標準機能がどう適用されるか、判断ロジックの実装有無、手作業がどの部分で排除されるか。そうした要素を踏まえて、「あるべき処理の流れ」を再設計していきます。

このように、「始まりは現実、流れは理想」で描くことが、To-Beプロセス設計の基本になります。

終点とは、業務の“完了条件と接続先”を表す

終点は、その業務が何をもって完了とみなされるかを定義します。

例えば「受注」プロセスの終点は、各受注明細の価格が決定し承認され、「引当可能」または「欠品として保留」など、次のプロセスである引当処理に渡すべき状態に分類・確定されていることです。

終点の定義には、次の2つの観点が含まれます：

  • 完了条件：どんな成果が得られたときにこのプロセスは終わったといえるか
  • 接続先：その成果を、次にどのプロセスへどのように引き渡すか

この2つが明示されていることで、プロセス間が因果でつながり、鳥瞰図との整合性を保ち、システムや人が迷わず業務を進められる状態がつくり出されます。

IPOの視点で、運用イメージを持つ

ERP導入における業務構築では、「その処理は何をきっかけに行われ、何を根拠に、何を生み出しているのか」という因果構造を明らかにすることが重要です。そこで設計の軸となるのが、IPO（Input → Process → Output）の視点です。

この視点が曖昧なままでは、業務は“それっぽい操作”の繰り返しになってしまい、To-Beプロセスの整合性やCRPでの検証の焦点が失われていきます。

【具体例】受注確認プロセスにおけるIPOの整理

例えば「受注確認」という業務を考えてみます。

CRPの場面では「とりあえず受注照会画面を開いてください」といった曖昧な操作指導になりがちですが、それでは確かに画面は開けても、「どの受注を、何をキーに検索するのか」が分からず、業務を再現したとは言えません。

実際には、

  • Input：顧客からの問い合わせ（例：「顧客PO番号12345の出荷状況を教えてほしい」）
  • Process：受注照会画面でPO番号をキーに検索し、該当オーダーを特定
  • Output：出荷状況を含む受注明細情報が画面上に表示され、問い合わせ対応が可能な状態になる

このように、「なぜその情報を選べたのか」「そのためのキーは何か」を確認できて初めて、業務としてのプロセスが成り立ちます。

もしこのIPOの視点が設計段階で抜け落ちたまま「とにかくこの画面を開く」といった操作ベースのフローが完成してしまうと、CRPでは一見問題なく動いて見えるかもしれません。しかし、運用フェーズに入った途端、ユーザーが「何を根拠にこの画面を見るのか」「どの情報を使えばよいのか」が分からず、業務が滞るという事態が起きてしまいます。

IPOはユーザーが自らERPを運用できるようにするための最も身近な設計技法です。そしてこの技法が、実務に即したTo-Be設計を支えるのです。

BPMNで描く：プールとレーンで役割と接続を整理する

プロセスを図で表現するには、BPMN（Business Process Model and Notation）という標準記法を使います。

  • プール：フロー全体の枠組み（例えば「受注業務」）
  • レーン：部門や役割（顧客、営業、物流、経理など）
  • タスク（ボックス）：業務単位の処理

例えば「受注確認」プロセスを例にすると、始点は顧客からの注文データ（EDIなど）の受信、終点は受注内容の確認・修正を経て、明細ごとに引当対象や保留状態として確定されたことです。このプロセス内で営業担当や業務部門がどのように関与し、どこで処理を引き渡しているかをBPMNのレーンとタスクで明示することで、部門間の接続や責任の所在がクリアになります。

分岐は判断条件を明確にし、分かりやすく

実業務には、「金額によって承認フローに入るかどうか」「在庫が足りないときは別プロセスへ切り替える」といった条件付きの処理分岐が数多く存在します。

プロセスフローでは、こうした分岐を明確に表現するために、排他的分岐（XOR）と並行分岐（AND）を区別し、それぞれの判断条件を具体的に記述する必要があります。並列分岐は主に処理がレーン（一般的には部門）を跨ぐ時に利用します。

分岐ごとにシナリオが必要

「どんな条件でどのルートを通るのか」が一目でわかる設計にできれば、CRPでのシナリオ作成やユーザー教育において混乱が生じるリスクが低くなります。

CRPで準備するシナリオは、分岐ごとに異なる経路をひとつずつ取り出して構成されます。つまり、分岐の数だけ、確認すべき業務シナリオが生まれるということです。

例えば在庫引当のプロセスであれば、「在庫が足りていた場合」と「在庫が不足していた場合」とで、少なくとも2つの異なるシナリオが必要になります。それぞれのシナリオには、それらに応じた在庫状況を再現できるテストデータ（在庫がある状態／ない状態）も必要です。

【よくある失敗】構造化されていないフローで起こる分岐の弊害

分岐の設計が不十分で構造化されていないフローでは、次のような事象が起きやすくなります：

  • 判断条件が曖昧なまま分岐が増え、ルートが複雑化する
  • 同じ業務処理が、複数の分岐先で繰り返し登場する
  • 分岐を分けて描いたはずなのに、結局すべて同じ結果に戻ってくる
  • ルートが多すぎて、どれが標準フローか分からなくなる

例えば、引当処理では、「在庫がある場合／ない場合」「仮引当か確定か」などの分岐条件を曖昧にした結果、全ルートに在庫確認が出てくるといった設計ミスが起こります。

意味ある分岐設計のために必要なこと

こうした混乱を防ぐためには、以下の2点を意識して設計することが重要です：

  • 分岐の基準となる判断条件を明示すること 　例：「10万円以上の注文は上長承認が必要」「在庫が0のときはバックオーダー処理へ」
  • 分岐先に共通処理がある場合は、前提条件を整理した上で再利用する設計にすること

分岐とは、処理を無闇に増やすことではありません。業務上の“判断”を視覚化し、標準フローと例外処理を分けて見せるための設計技術です。「なぜこの分岐があるのか」「何が違うのか」が読み手に自然と伝わるように描くことが大切です。

課題や要望とMoSCoWにひもづけ、業務を“イメージできる”フローに

現場からヒアリングした課題や要望をどの機能・処理でどのように対応するのかを表現しておくと、CRP時に「どの機能が何の問題を解決しているのか」が明確になります。

例えば、受注処理に対する「手間がかかる」「入力ミスが多い」といった声があれば、それを解決するタスク（例：EDI自動取込）にコメントとして添えておくことで、CRP時に「この処理はこの問題を解決している」という理解が深まります。

さらに、各要求にはMoSCoW（Must／Should／Could／Won’t）の優先度を付けておくと、検証観点の整理にも活用できます。どこまでが本番時の必須要件か、どの要求が見送り可能か、といった判断材料として機能するので、それに基づいて本稼働時のフローを作成すると同時に、本稼働後の機能強化に基づいたフローをイメージできるようになります。

“自動／手動”の明示で、To-Be像の変化を伝える

業務課題の多くは、「手間がかかる」「属人的」「抜け漏れが起きる」といった手動処理に起因するものです。To-Beフローでは、こうした課題がどの処理によって、To-Beフローに置き換えられたのかを明示することが重要です。

その第一歩として、各タスクボックスに「自動（バッチ／システム処理）」か「手動（ユーザー操作）」かを区別する記号やラベルを付けておくと良いでしょう。ただし、ここで伝えたい本質は、表示方法そのものではありません。真に重要なのは、“自動化のために何を変えるか”というBPR（業務改革）の内容を、業務フローにきちんと表現することです。

そこでポイントとなるのが、「自動化するための前提条件」をフロー上で適切に表現しておくことです。例えば、As-Is業務では購買計画の立案後、人手で納期や数量を調整してから発注していたとします。これをTo-Beフローでは「購買計画に基づく自動発注」に変えるとしたら、単なる自動化では済みません。納入日制約や配車制約、安全在庫レベルの見直しなど、従来は人が担っていた判断をロジックとして明確化し、自動化の前提として業務フローに記載しておく必要があります。

つまり、「自動化」という表面的な変化だけでなく、なぜ自動化できるのか、どのような業務設計上の工夫やBPR（業務改革）が必要なのかをフローに反映しておくことで、To-Be業務の本質的な変化と改善の成果が伝わるフローになります。業務を単に“簡略化した”のではなく、「どのように意思決定や判断の質を高め、属人性を排したのか」その背景を読み取れることで、業務全体への理解が深まり、組織としての納得と定着にもつながっていきます。

なお本題からやや外れますが、ERP導入による標準化や生産性向上といった効果を本当に実現しようとするならば、その裏側には必ずと言っていいほどBPRの存在がある、ということは強調しておくべきでしょう。

操作マニュアルへとつなげて、業務を実行可能にする

プロジェクトの後半では、レベル2のプロセスフローをベースに、ERPの画面単位まで落とし込んだレベル3（オペレーションフロー）を整備します。

どの画面で、どの入力項目に、どのような状況で、何を入力するのか。例外が発生したらどう処理するのか。こうした“実行可能な業務”へ詳細化させて完結します。

まとめ

ビジネスプロセスフローは、新しい業務を“理解し、検証し、運用する”ための設計です。後編で紹介した各種設計技法は、To-Be業務の全体像と構造を明らかにし、ERP導入における検証と運用を支える基盤となります。ユーザーが業務の意味を正しく理解し、自ら活用できるようにするために、ビジネスプロセスフローは構造と目的をもって描かれるべきなのです。