はじめに：業務フローの見直し方は、システム刷新の方向性によって変わる
こんにちは。ソフトウエア・サイエンス ビジネスソリューション事業部の徳岡です。製造業における業務／システム分析や、機器の制御・実績収集を専門に行っています。
さて、当社では様々なシステム刷新のプロジェクトをご支援していますが、システム刷新を進める際、最初に考えるべきことの一つが業務フローをどのように見直すかです。
ただし、業務フローの見直し方は、どのようなシステム刷新を行うかによって大きく変わります。
代表的なのが、次の2つのパターンです。
- ERPなどのパッケージソフトを導入する場合
- スクラッチ開発で自社に合わせたシステムを構築する場合
どちらも、現行業務であるAs-Isを把握し、あるべき業務であるTo-Beを検討する点は共通しています。しかし、To-Beの考え方や、業務フロー見直しの進め方には違いがあります。
ERP導入では、パッケージの標準機能を前提に、業務をどこまで合わせるかが重要になります。一方、スクラッチ開発では、現行業務や目指す業務に合わせて、システムをどのように設計するかが重要になります。
この記事では、ERP導入とスクラッチ開発で異なる業務フロー見直しの進め方を、As-Is / To-Be整理やCRPの考え方も含めて解説します。
この記事でわかること
- ERP導入とスクラッチ開発で、業務フロー見直しの考え方がどのように異なるのか
- ERP導入時に、標準機能と業務をどのようにすり合わせるべきか
- スクラッチ開発時に、As-Isを基にTo-Beを検討する進め方
- As-Is / To-Beの運用フローを整理する重要性
- ERP導入とスクラッチ開発それぞれのメリット・デメリット
この記事はこんな方におすすめです
- ERP導入を検討している情報システム部門の担当者
- スクラッチ開発で業務システムの刷新を検討している方
- パッケージ導入と個別開発のどちらがよいか判断に迷っている方
- システム刷新に向けて、As-Is / To-Beの整理を進めたい方
- 業務フローとシステム要件の関係を整理したい方
ソフトウエア・サイエンスでは大規模製造業（複数製品の生産工場）の基幹システムへのERPパッケージ導入について以下のような支援に実績があり、今回はその中で培ったノウハウをお伝えします。
- 製造工場の既存システム調査
- ERPパッケージ導入時における、パッケージ外システムとのIF連携機能の設計・開発
- データ移行
- BI機能の設計・開発
ERP導入とスクラッチ開発では、業務フロー見直しの考え方が異なる
業務フローの見直し方は、システム刷新の方向性によって大きく異なります。
ERPなどのパッケージソフトを導入する場合は、パッケージの標準機能を確認しながら、業務をどこまで標準に合わせられるかを検討します。
一方、スクラッチ開発では、現行業務を基に、業務効率や現場展開のしやすさを考慮しながら、To-Be業務を検討します。
大きく整理すると、次のようになります。
| 観点 | ERP導入 | スクラッチ開発 |
|---|---|---|
| 基本的な考え方 | 標準機能をベースに業務を見直す | 業務をベースにシステムを設計する |
| To-Be検討の起点 | ERPパッケージの標準機能 | 現行業務と改善したい業務 |
| 重視すること | 標準機能への適合、アドオンの抑制、保守性 | 業務効率、現場展開のしやすさ、要件への適合 |
| 注意点 | 業務効率や競争力が低下しないか確認が必要 | 開発・保守コストが増えやすい |
| 向いているケース | 標準業務に合わせられる業務、全社統制を重視する場合 | 独自業務や競争力の源泉となる業務を重視する場合 |
どちらが正しいということではありません。重要なのは、選択する方式によって、業務フローの見直し方も変える必要があるということです。
実務上、次のような相談を受けることがあります。
- システムを刷新する際の対応案と、それぞれのメリット・デメリットは何か？
- 方式を判断するための既存システム調査や、システムの視える化はどうしたらいいか？
システム刷新の方式を判断するためには、既存システムの調査と視える化が非常に重要です。
まず共通して必要なのは、As-Is業務の把握と整理
ERP導入でもスクラッチ開発でも、最初に必要なのは、現行業務であるAs-Isの把握です。
現場で実際にどのような作業が行われているのか、どの画面やシステムを使っているのか、前工程・後工程とのつながりはどうなっているのかを確認します。
こうした情報を確認しなければ、To-Be業務を正しく検討することはできません。
現場ヒアリングで確認したいこと
As-Is業務を把握する際には、現場へのヒアリングが重要です。
単に「どのような作業をしていますか」と聞くだけではなく、実際の作業内容や、使用している画面、システム、帳票まで確認します。
特に確認したいのは、次のような点です。
- どの業務を、誰が担当しているのか
- どの画面やシステムを使って作業しているのか
- 入力・確認・承認・出力の流れはどうなっているのか
- 前工程からどの情報を受け取り、後工程へ何を渡しているのか
- 業務の目的は何か
- 例外処理や属人的な判断はどこにあるのか
- 帳票については、後工程での使用目的を確認する
業務を一つの作業だけで見るのではなく、前工程・後工程を含めて一気通貫で把握することが重要です。
As-Is業務は「業務＋システム」の観点で整理する
現場ヒアリングで把握した内容は、As-Is業務として整理します。
このとき、業務手順だけを見るのではなく、業務とシステムの関係も併せて整理することが重要です。
たとえば、次のような観点です。
- どの業務で、どのシステムを使っているのか
- どのタイミングでデータが入力・更新されるのか
- どの帳票や画面を確認しているのか
- 業務上の判断と、システム上の処理がどのようにつながっているのか
- 現行システムの制約によって残っている運用はないか
この整理が不十分なままTo-Beを検討すると、業務の実態に合わないシステム設計になったり、導入後に現場で混乱が起きたりする可能性があります。
運用フローでは、業務とシステムの関係性を表現し、視える化できます。
運用フローの利点と使用例
- As-Isにおけるシステム全体の把握
- 業務とシステムの関連性の整理
- システム間の課題の抽出
通常作成するドキュメントでは、業務フローとシステムフローを別々に表現することが多いですが、その場合、後工程で両者の間にギャップが発生する可能性があります。
そのため、業務とシステムを一緒に表現できる運用フローを提案しています。
また、To-Beを検討する際には、システム間の関係が分かりやすくなり、課題も抽出しやすくなります。
ERP導入における業務フロー見直しの進め方
ERP導入では、パッケージの標準機能を前提に業務フローを見直します。
ERPは標準機能の幅が広く、設定変更で対応できる範囲もあります。そのため、自社の業務をそのまま再現するのではなく、標準機能でどこまで対応できるのかを確認しながら、To-Be業務を検討することが重要です。
1. As-Is業務を把握する
まず、現場ヒアリングを通じてAs-Is業務を把握します。
実際の作業内容、使用している画面やシステム、前工程・後工程とのつながりを確認し、現行業務を一気通貫で理解します。
ERP導入の場合でも、現行業務を把握しないまま標準機能だけを当てはめると、業務上重要な判断や例外処理を見落とす可能性があります。
2. As-Is業務を整理する
次に、把握したAs-Is業務を、業務とシステムの観点で整理します。
どの業務でどのシステムを使っているのか、どの作業が手作業で、どの作業がシステム処理なのか、どのデータがどこで発生し、どこに引き継がれているのかを確認します。
こうした内容を運用フローとして整理することで、現行業務の全体像が見えやすくなります。
運用フローを作成する際は、次の資料も併せて作成します。
- IF一覧・レイアウト
- 帳票一覧・レイアウト
- その他のExcelツールなど
運用フローは業務を起点に、すべての業務を時系列で表現します。処理のタイミングを正確に記載し、手動・自動の区分や、自動処理の場合は動作時間も明記します。
3. ERPパッケージの標準機能を整理する
ERP導入では、導入予定のパッケージが持つ標準機能を整理します。
ここで重要なのは、単に機能一覧を見ることではありません。自社の業務と照らし合わせながら、標準機能で対応できる業務と、標準機能だけでは対応しにくい業務を分けて考えることです。
ERPには、設定変更によって業務に合わせられる範囲があります。そのため、パッケージ選定や導入検討の段階で、どの範囲まで標準機能で対応できるかを確認しておく必要があります。
4. 標準機能をベースにTo-Be業務を検討する
ERP導入では、標準パッケージをベースにTo-Be業務を検討します。
このとき重要なのは、現行業務をそのまま新しいシステムに持ち込むのではなく、ERPの標準機能に業務を合わせる視点を持つことです。
もちろん、すべての業務を無理に標準機能へ合わせればよいわけではありません。企業の競争力や業務効率に関わる部分まで標準化してしまうと、かえって現場の生産性が低下する可能性があります。
そのため、標準機能に合わせる業務と、独自性を残すべき業務を見極めることが重要です。
5. CRPで業務運用が可能か確認する
To-Be業務とパッケージ機能の整理ができたら、CRPを実施します。
CRPとは、Conference Room Pilotの略で、実際の業務シナリオに沿って、パッケージ上で業務を運用できるか確認する検証です。
CRPでは、主に次の点を確認します。
- 検討した業務運用が実施可能か
- As-Is時の企業競争力が低下しないか
- 効率よく業務を実施できるか
- 業務効率が低下する場合、RPAなどの対策が必要か
ERP導入では、CRPを通じて、机上で考えたTo-Be業務を実際に運用できるか確認することが重要です。
6. CRP結果を基にTo-Be業務を見直す
CRPの結果を踏まえて、To-Be業務を再検討します。
このときの対策は、優先順位をつけて考えることが重要です。
優先順位は、次のように整理できます。
- 可能な限り、業務の変更で対応する
- 必要に応じて、外部アプリケーションの導入を検討する
- 最後の手段として、パッケージへのアドオンを検討する
アドオンは、標準機能では対応できない要件に対応できる一方で、保守性や将来のバージョンアップに影響する可能性があります。そのため、安易にアドオンを増やさず、業務変更や外部アプリケーションで対応できないかを先に検討することが重要です。
7. To-Be運用フローを作成する
CRP結果を反映したうえで、To-Be業務の運用フローを作成します。
To-Be運用フローでは、業務の流れだけでなく、ERP上での処理、外部アプリケーションとの連携、手作業で残る部分なども整理します。
これにより、導入後の業務運用を関係者間で確認しやすくなります。
8. 最終CRPで業務運用に問題がないか確認する
最後に、作成したTo-Be運用フローを基に、最終CRPを実施します。
この段階では、業務を問題なく実施できるか最終確認します。特に、部門間の連携、例外処理、データ連携、承認フローなど、実運用に近い観点で確認することが重要です。
運用フローを基に、ERPパッケージを使用した場合のTo-Be案を作成することで、できることとできないことを明確にできます。
そのうえで、ERPの標準機能で業務を運用できるか検証します。CRPで対応できないことを明確にし、どのように対応するかを検討します。
対策案は、次のとおりです。
- 業務を変更して対応する
- 外部機能を利用して対応する
- アドオン開発で対応する。ただし、アドオンは最終手段とする
ERP導入で注意したいポイント
ERP導入には、標準機能を活用することで、比較的低コストかつ短期間で導入しやすいというメリットがあります。一方で、業務を標準機能に合わせる判断が必要になるため、業務効率や競争力への影響も確認しなければなりません。
ERP導入のメリット
- パッケージを導入することで、比較的低コストで導入しやすい
- 標準機能を活用できるため、開発範囲を抑えやすい
- 次回以降の更新やバージョンアップがしやすい
- 全社的な業務標準化を進めやすい
ERP導入のデメリット
- 標準機能に沿わない場合、業務効率や競争力が低下する可能性がある
- 汎用性が高い反面、操作性が低下する可能性がある
- 標準から外れる場合、アドオンなどの対応コストが発生する可能性がある
- 利用状況によっては、ライセンス料が高くなる可能性がある
ERP導入では、「標準機能に合わせること」と「自社の業務上必要な強みを残すこと」のバランスが重要です。
スクラッチ開発における業務フロー見直しの進め方
スクラッチ開発では、As-Is業務を基に、To-Be業務を検討します。
ERP導入のようにパッケージの標準機能へ業務を合わせるのではなく、業務のあるべき姿を基にシステムを設計できる点が大きな特徴です。
そのため、業務効率や競争力を維持しやすく、現場展開もしやすいという利点があります。一方で、開発コストや保守コストは増えやすいため、必要な機能と過剰な作り込みを見極めることが重要です。
1. As-Is業務を把握する
スクラッチ開発でも、まずはAs-Is業務の把握から始めます。
現場ヒアリングを通じて、実際の作業、使用している画面やシステム、前工程・後工程の流れを確認します。
特に、現場でどのような判断が行われているのか、どの作業が業務効率や競争力に関わっているのかを把握することが重要です。
2. As-Is業務を整理する
把握したAs-Is業務は、業務とシステムの観点で整理します。
現行業務を整理することで、どの作業を残すべきか、どの作業を効率化できるか、どの業務をシステム化すべきかが見えやすくなります。
この整理が不十分なまま開発を進めると、現行業務の属人的な運用や非効率な作業まで、そのままシステムに組み込んでしまう可能性があります。
3. As-IsをベースにTo-Be業務を検討する
スクラッチ開発では、As-Is業務をベースにTo-Be業務を検討します。
このときのポイントは、現行業務を大きく変えすぎないことです。
もちろん、業務効率化は重要です。しかし、現場の運用と大きくかけ離れたTo-Beを設計してしまうと、導入後に現場へ展開しにくくなる可能性があります。
そのため、As-Isをベースにしながら、業務を効率化できる部分を見極めることが重要です。
4. To-Be業務を基にシステム要求定義・要件定義へつなげる
To-Be業務を検討したら、それをシステム要求定義や要件定義へつなげます。
スクラッチ開発では、業務のTo-Beがシステム設計の土台になります。
つまり、「どのような機能を作るか」よりも先に、「業務としてどのようにあるべきか」を整理することが重要です。
業務のTo-Beを曖昧にしたまま要件定義を進めると、機能単位の要望が積み上がり、結果として複雑で使いにくいシステムになる可能性があります。
5. システム設計結果を基にTo-Be業務を確定する
システムの要件定義や設計を進めた後、その結果を基にTo-Be業務を確定します。
この段階では、業務側の理想とシステム設計上の実現性をすり合わせることが重要です。
業務上は実現したいことであっても、システム化するとコストが大きくなる場合があります。また、システムで実現できるとしても、運用が複雑になりすぎる場合もあります。
そのため、業務とシステムの両面からTo-Beを確定する必要があります。
6. As-Is / To-Beの運用フローをセットで作成する
スクラッチ開発では、As-Isに対するTo-Beの運用フローを作成します。
As-IsとTo-Beをセットで整理することで、現場に展開する際に、これまでとの違いを説明しやすくなります。
たとえば、次のような点が明確になります。
- どの作業がなくなるのか
- どの作業がシステム化されるのか
- どの承認や確認が変わるのか
- 現場の役割分担がどのように変わるのか
- どの画面や機能を使って業務を進めるのか
As-IsとTo-Beの違いが見えることで、現場の理解を得やすくなり、導入後の混乱を抑えやすくなります。
スクラッチ開発の場合でも、現行業務を完全にそのまま再現するケースは多くありません。業務の効率化や共通化など、業務変更を行う可能性があるためです。
As-IsとTo-Beを比較することで、業務部門にとって差分が分かりやすくなり、自分の作業がどのように変わるかをイメージしやすくなるというメリットがあります。
スクラッチ開発で注意したいポイント
スクラッチ開発は、自社業務に合わせてシステムを設計できるため、業務効率や競争力を維持しやすいというメリットがあります。
一方で、自由度が高い分、開発コストや保守コストが増えやすくなります。
スクラッチ開発のメリット
- 業務効率や競争力を維持しやすい
- 自社の業務に合わせた設計ができる
- 現場展開しやすい
- As-Isをベースにした業務効率化を検討しやすい
スクラッチ開発のデメリット
- 開発コストが増えやすい
- 運用・保守コストが増えやすい
- 要件が膨らむと、システムが複雑化しやすい
- 将来の変更や拡張に備えた設計が必要になる
スクラッチ開発では、「業務に合わせて作れる」ことが強みです。ただし、その自由度をそのまま要望の積み上げに使うのではなく、業務として本当に必要な機能に絞り込むことが重要です。
ERP導入とスクラッチ開発の比較表
ERP導入とスクラッチ開発の違いを整理すると、次のようになります。
| 比較項目 | ERP導入 | スクラッチ開発 |
|---|---|---|
| 業務フロー見直しの起点 | ERPの標準機能 | As-Is業務とTo-Be業務 |
| To-Beの考え方 | 標準機能に業務を合わせる | 業務に合わせてシステムを設計する |
| 要件定義の進め方 | 標準機能との差分を確認する | 業務のTo-Beを基に要件化する |
| 検証の進め方 | CRPで業務運用を確認する | 設計結果と業務運用をすり合わせる |
| 現場展開 | 標準業務への変更説明が必要 | As-Is / To-Beの比較で説明しやすい |
| コスト | 比較的抑えやすい | 増えやすい |
| 保守性 | 標準機能中心なら保守しやすい | 設計次第で保守負荷が変わる |
| 業務適合性 | 標準に合えば高い | 自社業務に合わせやすい |
| 注意点 | アドオン増加、ライセンス費、業務効率低下 | 開発費・保守費増加、作り込みすぎ |
この比較からも分かるように、ERP導入とスクラッチ開発では、業務フロー見直しの目的や進め方が異なります。
ERP導入では、標準機能を活かしながら業務をどのように見直すかが重要です。一方、スクラッチ開発では、業務のあるべき姿をどのように要件定義や設計につなげるかが重要です。
この違いを理解しておくことが、システム刷新を進めるうえで重要です。
既存システムの刷新では、複雑な業務に合わせて構築されたシステムが多くあります。
ERPパッケージを導入する場合は、大幅な業務変更（Fit to Standard）が必要となることがあります。そのため、業務を大きく変えることが、自社の市場競争力に影響を与えるかどうかが判断基準となります。
- ERPパッケージ導入：コストを抑えやすい一方、標準機能に業務を合わせる必要があるため、業務効率などの観点から判断する必要があります。次回以降の更新では、標準機能を利用していれば、比較的低コストで更新でき、品質も一定に保ちやすくなります。
- スクラッチ開発：コストはかかりますが、これまでの業務運用を維持しやすく、システムや業務を見直すことで、業務効率の向上も検討できます。一方で、次回の更新時にも同様のコストがかかる可能性があるため、コスト面での判断が必要です。
ERP導入かスクラッチ開発かを判断するポイント
ERP導入とスクラッチ開発のどちらを選ぶべきかは、単純にコストだけでは判断できません。
業務の標準化を重視するのか、自社独自の業務を競争力として残したいのか、将来の保守性を重視するのか、現場の運用にどこまで合わせる必要があるのかを整理します。
こうした観点を整理したうえで判断する必要があります。
ERP導入が向いているケース
- 業務を標準化したい
- 全社統制を強めたい
- パッケージの標準機能で多くの業務をカバーできる
- アドオンを最小限に抑えられる
- 将来の更新や保守性を重視したい
スクラッチ開発が向いているケース
- 自社独自の業務プロセスが競争力になっている
- 標準パッケージでは対応しにくい業務が多い
- 現場の操作性や業務効率を重視したい
- As-Isをベースに段階的に業務改善したい
- 業務に合わせた柔軟なシステム設計が必要
ただし、実際にはERP導入とスクラッチ開発のどちらか一方だけでなく、組み合わせて考えるケースもあります。
たとえば、基幹部分はERPで標準化し、競争力に関わる周辺業務は外部アプリケーションや個別開発で補うという考え方です。
重要なのは、システム方式を先に決めることではありません。まず業務を整理し、そのうえで、どの領域を標準化し、どの領域を個別最適化するのかを判断することです。
既存システムを調査し、運用フローを整理することで、システム刷新の方式（スクラッチ開発／ERPパッケージ導入）を判断するための支援が可能です。
方式決定後も、運用フローを使って業務を見直すことが可能です。
- ERPパッケージ導入：業務の見直しが必要になるため、導入時の検討に活用できます。
- スクラッチ開発：既存業務を視える化し、業務効率の見直しなどに活用できます。
よくある質問
Q. ERP導入とスクラッチ開発では、業務フロー見直しの進め方は何が違いますか？
ERP導入では、パッケージの標準機能を前提に、業務をどこまで合わせるかを検討します。一方、スクラッチ開発では、As-Is業務をベースにTo-Be業務を検討し、その内容をシステム要求定義や要件定義につなげます。
Q. ERP導入では、業務を標準機能に合わせるべきですか？
基本的には、標準機能を活用することで導入コストや保守コストを抑えやすくなります。ただし、すべての業務を標準に合わせればよいわけではありません。業務効率や企業競争力が低下しないかを確認したうえで判断する必要があります。
Q. CRPとは何ですか？
CRPとは、Conference Room Pilotの略です。実際の業務シナリオに沿って、ERPパッケージ上で業務を運用できるか確認する検証を指します。
Q. スクラッチ開発では、なぜAs-Is / To-Beの運用フローが重要なのですか？
As-IsとTo-Beをセットで整理することで、現場に対して「これまでと何が変わるのか」を説明しやすくなるためです。現場展開時の理解促進や、導入後の混乱防止にもつながります。
Q. ERP導入とスクラッチ開発は、どちらがよいのでしょうか？
どちらがよいかは、業務内容やシステム刷新の目的によって異なります。業務標準化や保守性を重視する場合は、ERP導入が向いていることがあります。一方、自社独自の業務や競争力を重視する場合は、スクラッチ開発が適していることもあります。
Q. 業務フローの見直しは、どのタイミングで行うべきですか？
ERP導入でもスクラッチ開発でも、システム方式を決める前、または要件定義に入る前に行うことが望ましいです。As-Is業務を整理しないまま方式や要件を決めると、後から業務との不一致が判明し、手戻りが発生しやすくなります。
既存システムを調査し、運用フローを整理することで、システム刷新の方式（スクラッチ開発／ERPパッケージ導入）を判断するための支援が可能です。
方式決定後も、運用フローを使って業務を見直すことが可能です。
- ERPパッケージ導入：業務の見直しが必要になるため、導入時の検討に活用できます。
- スクラッチ開発：既存業務を視える化し、業務効率の見直しなどに活用できます。
まとめ
業務フローの見直し方は、システム刷新の方向性によって大きく変わります。
本記事で整理したポイントは次のとおりです。
- ERP導入では、パッケージの標準機能をベースにTo-Be業務を検討する
- ERP導入では、CRPを通じて実際に業務を運用できるか確認する
- スクラッチ開発では、As-Is業務をベースにTo-Be業務を検討する
- スクラッチ開発では、To-Be業務をシステム要求定義や要件定義につなげる
- ERP導入は低コスト・保守性の面でメリットがある一方、標準機能との適合確認が重要
- スクラッチ開発は業務効率や競争力を維持しやすい一方、開発・保守コストが増えやすい
- どちらの場合も、As-Is業務の把握と、業務＋システムの観点での整理が欠かせない
システム刷新では、ERP導入かスクラッチ開発かを先に決めるのではなく、まず現行業務を整理し、どの業務を標準化し、どの業務を個別最適化すべきかを見極めることが重要です。
そのうえで、ERP導入、スクラッチ開発、外部アプリケーションの活用など、最適な選択肢を検討していくことが、システム刷新を成功に近づけるポイントになります。
- ERP導入を検討しているが、自社業務をどこまで標準機能に合わせるべきか判断できない
- スクラッチ開発で進めたいが、要件定義や業務整理に不安がある
- As-Is / To-Beの運用フローを整理したい
- ERP導入とスクラッチ開発のどちらが適しているか相談したい
- 業務整理からシステム刷新まで一貫して相談したい
このような課題をお持ちの場合は、SSIにご相談ください。
業務整理やERP導入・スクラッチ開発の検討だけでなく、方式決定後の支援も可能です。
主な支援内容は、次のとおりです。
- 製造工場の既存システム調査（As-Is）を利用した、To-Beイメージの作成
- 新システムと外部システムとのIF連携機能の設計・開発
- 既存システムから新システムへのデータ移行
- 新システムで利用できるBI機能やExcelツールなどの設計・開発