ERP知識シリーズ ビジネスプロセスフローの書き方《前編：フローの問題点と設計技法》
ERP導入プロジェクトにおいて、ビジネスプロセスフローは最も基本的かつ重要な成果物のひとつです。このフローを基にしてCRPや運用モデル評価が実施され、新しい業務の姿が徐々に形づくられていきます。ところが実際のプロジェクトでは、このプロセスフローにさまざまな問題が見られ、業務の見直しやTo-Beプロセスへの移行を阻む要因となっているのが現実です。
では、どこに問題があるのでしょうか。よくある問題のパターンとその影響について、順を追って見ていきます。
- 始まりと終わりが定義されていない
最初に確認すべきなのは、業務がどこで始まり、どこで終わるのかという“業務の区切り”です。ところが、多くのフローではこの始点と終点が明確に定義されていないため、「何がトリガーで業務が始まり、何をもって完了とするのか」が曖昧になってしまいます。この段階で設計がぼやけると、後続に問題が連鎖して発生します。 - フロー同士の“つながり”が不明瞭
個別の業務フローが描かれていても、前後のプロセスとの接続関係が明示されていないと、業務全体が「つながらない点の集合体」になってしまいます。例えば「在庫引当」というフローがあっても、「どの受注処理から接続されているのか」「引当後はどのプロセスに移るのか」が分からなければ、全体の業務フローとして連続性を持たせることができません。こうした断絶は、全体最適の検討やプロセス再設計を困難にします。 - 構造化されておらず、業務の因果が見えない
プロセスフローは本来、鳥瞰図（レベル1）から業務フロー（レベル2）、操作手順（レベル3）へと構造的につながっている必要があります。
しかし、こうした階層設計がそもそも存在しないと、各フローが業務全体のどこに属するものか分からず、個別の処理が断片的に並んでいるだけの状態になってしまいます。
その結果、処理の位置づけや前後の接続関係が見えず、業務としての因果や流れがまったく読み取れないフローとなってしまいます。これでは、検証や説明の起点にもなりません。 - ただの“システム手順”になっている
フロー図がERPの画面名や処理名の並びに終始していると、新しい業務を流れとして“再生”するだけの図になってしまいます。
例えば「製造オーダーリリース → 製造指図書発行 → 材料払出 → 完成報告」といった記述では、リリース対象範囲が何で、どのような判断基準で進み、誰が関与しているのかといった業務の意味が抜け落ちます。
その結果、フローが操作手順に留まり、To-Be業務の検証や改善評価に必要な情報が不足した状態になってしまうのです。 - フローの範囲が曖昧で、重複とばらつきが生じる
フローごとの「対象範囲」が明確に定義されていないと、あるフローは業務全体を広くカバーしている一方で、別のフローはごく一部だけを扱うなど、範囲のばらつきが生じてしまいます。
このように設計方針が曖昧なままフローを描いていくと、複数のフローに同じ処理が繰り返し登場し、内容の重複や整合性のズレが避けられません。
その結果、どのフローで何を扱うのかが分かりにくくなり、業務全体の見通しが悪くなると同時に、保守・更新の負担も増大していきます。 - 分岐の設計方針が曖昧で、フロー全体の構成が崩れる
業務パターンをひとつのフローの中で分岐として扱うのか、それとも別々のフローとして分けるのか？ この設計方針が曖昧なまま進めてしまうと、フロー全体に一貫性がなくなります。
例えば「仕入処理」において、不良品が発生した場合の対応を「仕入フロー」の中に分岐として描くのか、それとも「品質管理フロー」として切り出すのかが曖昧だと、同じ処理が複数の図に繰り返し描かれたり、逆に本来分けるべき処理が一つのフローに詰め込まれてしまいます。
その結果、ユーザーは「どのフローを参照すればよいのか」「どこまでがこの業務の範囲なのか」が分からなくなり、検証や教育、運用の場面で混乱が生じます。 - ヒアリング結果が反映されていない
ヒアリングの段階で問題点やニーズは一覧化されているものの、それらがTo-Beプロセスフローのどこに関係するのかが明記されていないと、CRPなど検証時に見落としが生じる原因となります。
こうした問題の本質は、業務を単なる操作や機能の連なりとして捉えている点にあります。とりわけ、「ERPの標準機能をそのまま使えば、FTSで業務が回る」といった考えのままプロジェクトが進むと、フロー設計が業務視点を持たないまま形骸化し、現場との乖離が顕著になります。
そうして作られたフローは、業務の実態を反映していないため、CRPでユーザーから「製品トレーニングと何が違うのか？」「業務のどこを検証しているのかわからない」といった声が上がり、最終的には「業務の姿がまったくイメージできない」と、とどめを刺されるのです。
このあとは、こうした状況を打破するために必要な設計の考え方、すなわち、ビジネスプロセスフローを“構造として捉え、意味が読み取れる図”にしていくための実践技法をご紹介します。それぞれの技法がどのような設計効果をもたらし、業務理解・業務検証・運用移行の支えとなるのか。その視点から順に解説していきます。
- 「BPMN（Business Process Model and Notation）による可視化」で、部門・役割・責任の関係を図解する
（→ 対応：すべての問題に関係する“基盤技法”）
業務全体の構造や関係性を、標準記法であるBPMNによって図に落とし込みます。プール・レーン・タスク・分岐を用いることで、業務の流れ・関与部門・責任の所在が視覚的に明確になり、業務プロセスの全体像が一目で把握できるようになります。
この技法は、問題点で挙げたすべてに共通する基盤的な解決手段となります。始点・終点の接続（①②）、鳥瞰図との構造整合（③）、業務としての意味の補強（④）、分岐の整理（⑤⑥）、改善点の明示（⑦）すべてがこれによって可視化されます。 - 「始点・終点の明示」で、“業務の区切り”をつくる
（→ 対応：① 始まりと終わりが定義されていない／② フロー同士のつながりが不明瞭）
業務は、何かのきっかけ（トリガー）で始まり、何らかの成果を次に渡すことで終わります。
「始点」と「終点」を明示することで、業務の開始条件・完了条件・接続先が明確になり、フロー間のつながりや業務範囲の境界が整理されます。
これにより、業務の起動タイミングが人によってブレたり、前後のプロセスとの断絶が起こるといった設計上のズレを防ぐことができます。プロセスを“流れの中の一部”として捉えるための出発点となる技法です。 - 「IPOの視点」で、業務を実践レベルに引き上げる
（→ 対応：④ ただの“システム手順”になっている）
業務プロセスは、インプット（Input）をもとに、処理（Process）を行い、アウトプット（Output）を生み出すという因果関係で成り立っています。IPOの視点で各タスクを設計することで、「なぜこの処理をするのか」「何を根拠に、何を出力しているのか」が明確になります。
この視点を取り入れることで、単なる画面操作の羅列にとどまっていたフローが、“意味を持った業務”として再構成され、CRPや教育の場でも再現性のあるプロセスへと変わっていきます。業務が単に“進む”だけでなく、“理解できる”ようになる。それを支える設計技法です。 - 「分岐設計」で、業務フローの構成を明快にする
（→ 対応：⑤ フローの範囲が曖昧／⑥ 分岐の設計方針が曖昧）
業務には「標準処理」と「例外処理」があり、それらの構造を整理することがフロー設計に求められます。この技法では、まず通常ルート（標準的な処理）を明確に描いた上で、例外処理は分岐として枝に分けて整理します。例えば仕入処理において、不良品が発見されるルートは分岐を設け、品質管理フローへと接続させます。
こうした設計により、「どこまでをこのフロー内で表現するか（＝分岐で描く）」「どこから別のフローに委ねるか」が明確になり、フローの冗長化や分岐の迷路化を防ぐことができます。
あらかじめ分岐の基準を定めておくことで、業務パターン全体（分母）の中から、どの処理を一つのフロー内に含め、どの処理を他のフローで扱うかを判断できるようになります。その結果、CRPでシナリオを準備する際にも、どの経路を辿るシナリオなのかが明確になり、設計の網羅性と整合性を自然に保つことができます。 - 「現場の課題 × タスク × MoSCoW」で、To-Be業務に根拠を持たせる
（→ 対応：⑦ ヒアリング結果が反映されていない）
ヒアリングで得られた課題や要望を、対応するタスクと結びつけた上で、優先度（Must／Should／Could／Won’t）を設定することで、「このプロセスで何を検証すべきか」「どこに業務改善の焦点があるのか」が明確になります。
これにより、関係者の間で「残すべき業務」「見直すべき業務」が共有され、納得感のあるTo-Be設計へとつながります。CRPでの検証軸や、運用合意を得るための基盤としても機能する重要な設計技法です。 - 「自動／手動の記号化」で、業務改善ポイントを“視覚化”する
（→ 対応：⑦ ヒアリング結果が反映されていない）
To-Beフローでは、どの処理が自動化され、どこに人の判断や操作が残るのかを明示すると良いでしょう。
各タスクに「自動（バッチ・システム処理）」または「手動（ユーザー操作）」の記号を付けることで、手間がどこで削減されるのかを一目で理解できるようにします。
この可視化は、業務改善の成果を“図”として伝える手段となります。
ここまで、ビジネスプロセスフローに潜む典型的な問題と、その背景にある設計上の課題を整理してきました。後編では、前述した設計技法を用いて、これらの問題をどのように解消し、ユーザーが「業務の意味」を自然に読み取れるような構造的なフローをどのように設計するかを、技法ごとに具体的に解説していきます。あわせて、ERPベンダーがあらかじめ提供するビジネスプロセスフローについても、これらの設計技法を基準に、その質や適合性をどう見極めるべきかを考えていきます。
（後編へ続く：2025年8月7日公開予定）
