月曜の朝、営業事務の担当者が、メールで届いた注文をExcelに写しています。
そのExcelを見ながら、同じ得意先と品目を、販売管理システムにもう一度打ち込む。
本人にとっては、毎週の当たり前の作業です。
業務フロー可視化とは、こうした社内の業務の流れを、誰が見ても分かる形に書き出すことです。
ERP導入の前には、2枚の絵を描きます。
いまの流れ（As-Is）と、導入後に目指す流れ（To-Be）です。
2枚を並べると、差が見えます。
その差を「やめる・まとめる・そろえる」で縮めてから、製品の標準機能と照らし合わせる。
この順番を飛ばすと、ERPを入れても現場は前のやり方に戻りがちです。
では、どこまで細かく描けば足りるのか。
描き込みすぎて終わらない会社は、少なくありません。
この記事で分かること
- ERP導入の「前」に業務フロー可視化が要る理由
- As-Is（現状）とTo-Be（あるべき姿）の描き方
- 差を埋める順番：見える化→整理整頓→Fit&Gap
- 標準で収まらない業務の3つの選択肢
- To-Beの結果から、どの製品が合うか（入れないかも含めて）
なぜ「ERP導入の前」に描くのか
ERP（Enterprise Resource Planning）は、会計・販売・在庫などの基幹業務を1つにまとめる仕組みです。
ERPは、会社の業務の流れに沿って動きます。
流れがあいまいなまま導入を進めると、どうなるか。
「今のやり方をそのまま再現してほしい」という要望が先に立ちます。
冒頭の二重入力のような作業まで、新しいシステムに運ばれてしまう。
ERP導入がうまくいかない原因の多くは、製品ではなく進め方にあります。
導入段階の失敗は、ERP導入はなぜ失敗するのかで扱っています。
業務フローの可視化は、作業の棚卸しで終わりません。
「自社はどの業務で価値を生んでいるのか」を、経営の目で描き直す仕事です。
経営者が「なぜ変えるのか」を語れると、後の工程がぶれにくくなります。
As-IsとTo-Beの違い
- As-Is（アズイズ）：現状の業務フロー。今、実際にどう仕事が流れているか
- To-Be（トゥービー）：あるべき業務フロー。ERP導入後に目指す流れ
この2つは、セットで描いて初めて役に立ちます。
As-Isだけなら、「今の不便」を並べて終わります。
To-Beだけだと、現場の実態から離れた絵になりがちです。
両方を並べたときに見える差が、ERPで解くべきテーマです。
As-Is（現状）の描き方
As-Isは、今の業務を「ありのまま」描くところから始めます。
良し悪しの判断は、いったん脇に置きます。
- 対象範囲を決める：受注・在庫・会計など、ERPで扱う中心の業務から
- 流れを書き出す：「誰が」「何を」「どの順番で」を、関係者から聞き取る
- 図にする：部門・担当と、作業の順番が分かる形に整える
- 例外を脇に分ける：まれな処理は別枠でメモし、本筋を太く描く
図にする前に、次の表で書き出すと抜けが見つかります。
| 項目 | 書く内容の例 |
|---|---|
| 作業 | 受注の登録 |
| 担当 | 営業事務 |
| 使う道具 | メール・Excel・販売管理システム |
| 入力する情報 | 得意先・品目・数量・納期 |
| 次に渡す先 | 倉庫の出荷担当 |
| 困っていること | 同じ内容を2回入力している |
描くのは建前ではなく、実態です。
マニュアルに載っていない回り道こそ、書き留める価値があります。
「使う道具」の欄に個人のExcelやメモが出てきたら、そこが要注意の箇所です。
To-Be（あるべき姿）の描き方
To-Beは、現状の延長では描きません。
「ERPの標準に業務を寄せる」発想から始めます。
軸になる考え方は2つです。
- Fit to Standard：業務をパッケージの標準機能に合わせる発想
- クリーンコア：システム本体の作り込みを最小限に抑える設計の考え方
描く手順は4段です。
- 標準で何ができるかを知る：標準機能でまかなえる業務の範囲をつかむ
- 寄せられる業務を寄せる：今のやり方にこだわらず、標準の流れに合わせる
- 本当に特殊な業務を見極める：自社の強みに関わり、標準にない業務を切り分ける
- 理想の流れを描く：標準を土台に、必要な部分だけ調整した姿を図にする
最初から100点のTo-Beを狙うと、いつまでも進みません。
標準に寄せられる部分から固め、細かな作り込みは後に回します。
動かしながら磨くほうが、結果として早く成果が出ます。
差の埋め方｜見える化→整理整頓→Fit&Gap
As-IsとTo-Beを並べたら、差を埋めにかかります。
ここが業務改革の本番です。
ベンチャーネットは、差を次の3段で埋めます。
- 業務の見える化：第3章のAs-Isを、現場に聞いて描く
- 整理整頓：やめる・まとめる・そろえる業務を決める
- Fit&Gap：残った業務を、製品の標準機能と照らし合わせる
2段目で、とくに見つけたいのは「やめる業務」です。
惰性で続いている作業をそのまま運ぶと、新しいシステムの中に古い課題が残ります。
ブラックボックスの詰め替えです。
長年の業務を「やめる」と決めるのは、社内だけでは難しい。
「なぜこの作業を続けているのか」と、外から素朴に問う人がいると動き出します。
Fit&Gapは、業務と標準機能の合う・合わないを、一つずつ見る作業のことです。
合わなかった業務は、次の3つのどれかに決めます。
- 標準に合わせる：業務のほうを、標準機能に寄せる
- 開発する：追加の開発や、外部の仕組みとの連携で補う
- 残す：ERPには載せず、今の仕組みや運用で続ける
整理整頓を先に済ませると、照らし合わせる業務の数が減ります。
Fit&Gapの手間も、開発に回る量も、その分だけ軽くなります。
標準と作り込みの線引きは、NetSuite導入のFit&Gap分析で詳しく扱っています。
比較表｜「現行踏襲」と「Fit to Standard」
To-Beを描くときの分かれ道が、この2つの考え方です。
現行踏襲が、いつも悪いわけではありません。
標準にない特殊な業務では、筋が通ることもあります。
| 観点 | 現行踏襲（業務にシステムを合わせる） | Fit to Standard（標準に業務を合わせる） |
|---|---|---|
| 基本の発想 | 今の業務をそのまま再現する | 標準の業務の流れに自社を寄せる |
| 作り込みの量 | 多くなりがち | 最小限に抑える（クリーンコア） |
| 初期の費用・期間 | ふくらみやすい | 抑えやすい |
| 将来の更新 | 作り込みの確認と改修が重くなる | 定期的な更新を取り込みやすい |
| AIとの親和性 | 低。独自の作り込みが多いと、標準のAIの機能を活かしにくい | 高。標準のデータの形にそろい、AIの機能や外部のAIとつなぎやすい |
| 向いている場面 | 標準にない、真に特殊な業務 | 大半の標準的な業務 |
AIとの親和性は、生成AIなどの新しい機能を取り込みやすいかどうかです。
たとえばNetSuiteは、大きなリリースが年2回あり、数か月かけて段階的に更新されます。
更新の前には、Release Preview（確認用の環境）で自社の業務の流れを試せます。
（出典：Oracle NetSuiteヘルプ「Release Delivery」、2026年9月確認）
作り込みが多いほど、この確認の手間は増えます。
まずFit to Standardで考え、本当に特殊な部分だけ現行踏襲を検討する。
この順番なら、費用と将来の使いやすさの釣り合いが取りやすくなります。
判断の物差し｜To-Beから、合う選択肢を考える
To-Beを描くと、どの製品が合うかの手がかりが出てきます。
| To-Beの結果 | 合いやすい選択肢 |
|---|---|
| 大半が標準に寄せられ、複数の拠点や事業を1つにまとめたい | NetSuiteのようなクラウドERP |
| 費用を抑え、必要な業務から順に広げたい | Odoo |
| 国内の商習慣や帳票への対応が、To-Beの中心にある | 国産ERP |
| 標準に寄せられない独自の業務が中心で、業務がすでに固まっている | AIを使ったスクラッチ開発 |
| As-Isの段階で、やめる業務が多く見つかった | いまはシステムを入れず、業務の整理を先に |
最後の行は見落とされがちです。
やめる業務を減らすだけで、困りごとの多くが片づく会社もあります。
NetSuiteには、業種ごとの標準の進め方としてSuiteSuccessがあります。
事前に構成された形で、予測可能な期間と決められた予算で本稼働を目指す方法です。
あらかじめ設定されたKPI・レポート・ダッシュボードも含まれます。
（出典：Oracle NetSuite日本語公式サイト、Oracle NetSuite公式「What Is NetSuite?」、2026年9月確認）
標準の姿を先に見ておけば、To-Beを描く手間は減ります。
NetSuiteは世界220地域・44,000社以上で使われています（出典：Oracle NetSuite公式サイト、2026年9月時点）。
製品の比べ方は、自社に最適なERPを見つける比較選定で扱っています。
初めて入れる会社と、乗り換える会社
初めてERPを入れる会社
As-Isには、Excelや紙で回している業務が多く出てきます。
それ自体は問題ではありません。
探したいのは、「誰かの頭の中にしかない判断」です。
To-Beは、標準の姿を見てから描きます。
デモで標準の流れを先に見ておくと、寄せられる業務を選びやすくなります。
いまのシステムから乗り換える会社
乗り換えでは、As-Isが「今のシステムの仕様」に引っ張られます。
画面や帳票の都合で生まれた作業を、業務だと思い込みやすいのです。
- その作業は、業務のために要るのか、今のシステムのために要るのか
- 作り込んだ機能のうち、今も使われているのはどれか
- 保守期限まで、どれだけ時間が残っているか
保守期限が近いなら、描く範囲を絞って進めます。
保守切れへの備えは、基幹システムの保守切れリスクとはで扱っています。
可視化でよくある3つのつまずき
つまずき1：As-Isを細かく描きすぎて、終わらない
起きること：すべての業務を漏れなく描こうとし、めったに起きない例外まで描き込む。図がいつまでも完成しない。
原因：何のために描くのかを見失い、可視化そのものが目的になっている。
避け方：目的から逆算して、描く粒度を決めます。
大きな流れをつかみ、要の領域だけ深く描きます。
ベンチャーネットは「経営課題はモノの管理か、ヒトの管理か」を最初に聞き、優先する領域を絞ります。
つまずき2：現状をそのままTo-Beにしてしまう
起きること：As-IsとTo-Beがほとんど同じ。「今のやり方を変えたくない」という声が強く、惰性の業務も残る。
原因：社内の人だけで描くと、自分たちの「当たり前」が前提になる。部門をまたぐ見直しも、内部だけでは進みにくい。
避け方：第5章の整理整頓で、「本当に必要な業務」と「惰性の業務」を分けます。
第三者の素朴な問いが、見直しのきっかけになります。
業務の標準化は、『業務属人化』がDXを止めるで扱っています。
つまずき3：可視化を「作って終わり」にする
起きること：きれいな図はできたが、要件の整理や提案依頼書（RFP）につながらない。導入の現場で使われない。
原因：可視化がゴールになり、次の工程に接続されていない。
避け方：「可視化→要件の整理→RFP作成→製品選定→導入」の流れの中に置きます。
To-Beの図を、そのまま要件の一覧の目次に使えばつながります。
3つのつまずきと避け方をまとめると、次の図のとおりです。
可視化のあと、ERP導入に向けてやること
- 要件を整理する：To-Beの業務をもとに、ERPに求める条件を言葉にする
- RFP（提案依頼書）を作る：要件を、ベンダーに伝える文書にまとめる
- 製品を選ぶ：自社の経営課題に合うERPを比べて選ぶ
- 導入する：To-Beに沿って設定・データ移行・定着を進める
- 要件をRFPに落とす → ERP刷新を成功に導くためのRFP作成
- 製品を比べる → ERPを徹底比較
- 導入でつまずかない → ERP導入はなぜ失敗するのか
As-IsとTo-Beの2枚が、この後に続く工程すべての土台になります。
ベンチャーネットならこう見る｜製品が決まっていても、見える化から
「製品はもう決めた。可視化は省いて、設定から始めたい」
そう言われることもあります。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、製品が決まっていても、業務の見える化からやり直します。
今の機能の一覧には、使っていない帳票や、手作業で補っている業務が混ざっているからです。
一覧をそのまま要件にすると、要らない作業まで新しいERPに運んでしまいます。
進め方は、第5章の型のとおりです。
- 見える化→整理整頓→Fit&Gap：描いて、減らしてから、標準と照らす
- 標準に合わせる／開発する／残す：合わない業務は、この3つのどれかに決める
製品の話は、いちばん最後です。
ERPありきで描くと、To-Beが製品の機能の一覧になってしまいます。
体制にも、この考え方が表れています。
要件を聞き取るのは、営業ではなく導入コンサルタントです。
現場の話が伝言ゲームで薄まらないよう、描く人と設定する人をそろえています。
ベンチャーネットの仕事は、他社のあとの引き継ぎや、他システムとの連携が多くを占めます。
だから、描き直しから始めることを前提に進めます。
最初の打ち合わせで伺うのは、主に次の3つです。
- 経営者が変えたいことを、一言で言えるか
- 経営課題は、モノの管理かヒトの管理か
- やめられそうな業務に、心当たりはあるか
描いた結果、システムが要らないと分かることもあります。
そのときは、そのままお伝えします。
今日できること｜1つの業務を1時間で書き出す
- 受注から請求まで、よく起きる業務を1つ選ぶ
- 第3章の表の6つの項目で、作業を順に書き出す
- 「困っていること」の欄を、担当者に聞いて埋める
- 各作業に「やめる・まとめる・そろえる」の印を付けてみる
4つの手順を、確かめる項目の形にすると次のとおりです。
「やめる」が1つでも見つかれば、それが最初の成果です。
よくある質問
Q1. 業務フローは、どこまで細かく描けばよいですか
To-Beに必要な範囲が基準です。
大きな流れをつかみ、要の領域だけ深く描きます。
細かく描きすぎると、完成しないまま目的を見失いがちです（第9章）。
Q2. 自社だけで進めても大丈夫ですか
始めることはできます。
ただ、自社だけだと「当たり前」を疑いにくくなります。
第三者が入ると、「なぜこの作業を続けているのか」という問いが生まれます。
Q3. どれくらいの労力がかかりますか
業務の範囲と複雑さで変わります。
ERPで扱う中心の業務に絞り、段階的に広げれば、現実的な労力に収まります。
Q4. 図を描く道具は何を使えばよいですか
最初は表計算やスライドで十分です。
道具より、「誰が・何を・どの順番で」を正しく集めることが先です。
第3章の表で書き出し、必要になってから図にします。
Q5. 乗り換えの場合も、As-Isから描くべきですか
描きます。ただし、今のシステムの都合と業務を分けて描きます。
画面や帳票のために生まれた作業は、乗り換えでなくせることがあります（第8章）。
Q6. 製品がもう決まっていても、可視化は要りますか
要ります。
今の機能の一覧には、使っていない帳票や手作業の補いが混ざっています。
見える化→整理整頓→Fit&Gapの順で減らしてから照らし合わせると、開発の量も抑えられます（第5章・第11章）。
まとめ｜可視化は、ERP導入の成否を分ける最初の一歩
- ERP導入は経営プロジェクト。入れる前に業務を描き直す
- As-IsとTo-Beをセットで描き、その差を埋める
- 差は見える化→整理整頓→Fit&Gapの順で埋める
- 合わない業務は標準に合わせる／開発する／残すに分ける
- To-Beを見てから、どの製品が合うか、入れるべきかを考える
描く粒度は、To-Beに必要な範囲で足ります。
冒頭の二重入力のような作業を、まず1つ書き出すところから始めてください。
もう少し詳しく知りたい方へ
業務の整理からTo-Beの設計、導入後の定着まで、ご相談をお受けしています。
描いた結果、システムが要らないと分かった場合も、そのままお伝えします。
