ホーム/ 実務メモ/ システム導入の失敗、業務整理から始まる。
DX / 業務改善

システム導入の失敗、
業務整理から始まる。

システム選定の前に、業務の前提が整理されていない会社では、導入後もExcelや紙の運用が残り続けます。中小・中堅企業で繰り返される典型パターンと、その手前で必要な業務整理の進め方を整理します。

2026.05.24 更新 2026.09.25 約10分 eap 編集部
DX 業務整理 システム導入
この記事で判断できることDecisions
  1. システム選定の前に、何を整理するか現行業務 → 判断・例外 → 権限 → データの順に書き出し、そこから初めてシステム要件を決める(FIG.01)。
  2. 導入後も、なぜExcelや紙が残るのか言語化されていない例外が要件に入らず、現場が回避策を作り、直す人がいないまま定着するから(FIG.02)。
  3. どこまでをシステムに乗せるか頻度と定型度で分け、全部はシステム化しない。例外は運用ルールと人の判断に残す(FIG.04)。
FIG.01業務整理フロー

システム要件は最後の工程。現行業務から判断・例外、権限、データへと順に整理した結果として決まる

左から右へ(スマートフォンでは上から下へ)。05で漏れが見つかったら02に戻る

  1. 現行業務主要業務をプロセスに分け、担当・頻度・所要時間・使っているツールを書き出す現場担当・整理役
  2. 判断・例外得意先ごとの納期、口頭での規格確認など、頭の中にある例外を言葉にする現場担当・部門長
  3. 権限例外を誰が判断し、誰が承認するか。導入後に運用を回す人・直す人も決める経営者・部門長
  4. データ各工程で入力・参照するデータと、いまの置き場所(システム・Excel・紙)を確かめる整理役・管理部
  5. システム要件標準化できる業務だけを要件にし、Fit/Gapを確認する。例外は運用ルールとして別に書く整理役・ベンダー

05で満たせない業務が見つかったら、02に戻って「人の判断に残すか」を決め直す

経営者・部門長が判断する工程ベンダーに渡す成果物
ベンダー選定から始める会社は、05から手を付けて01〜04を後回しにします。要件定義で渡すのは、01〜04を書き出したシートそのものです。
要点
  • システム選定から始めると、現場で「結局Excelの方が早い」が起き続ける
  • 導入前にやるのは、業務の棚卸し・標準化・例外パターンの明文化の3つ
  • 完璧な業務整理を目指さない。Fit/Gapの優先順位だけ決めて、走りながら直す

1. システムを入れたのに、現場ではExcelが残り続ける

「3年前に基幹システムを刷新したのに、結局現場ではExcelと紙が併用されています」。社員数50〜300名規模の地場産業の経営者から、この話を聞かない月はありません。投資額は数千万円から1億円規模。ベンダー選定にも半年以上かけた。それでも、なぜか定着しません。

原因は、システムが悪いのではないことが多いです。製品としては優秀でも、現場の業務の前提が整理されていない状態で導入したため、現場が標準機能では業務を回せず、結局Excelに戻ってしまう。これは中小・中堅企業のDX失敗パターンの典型です。

2. その問題が起きる構造

地場産業の業務は、長い時間をかけて「現場の人が頭の中で覚えている前提」で動いています。たとえば、ある得意先には例外的に納期を1日延ばしている。ある商品はカタログ表記と実物の規格が微妙に違うので、注文時に毎回口頭確認する。ある配送ルートは、社長の人脈で20年同じ配送会社に頼んでいるため、システム上の最適化提案が現場感覚と合わない。

こうした「言語化されていない例外」は、業務フロー図には書かれていません。ベンダーが要件定義で訪問しても、現場担当者は「いつもの仕事」を見せるだけで、例外パターンを思い出して伝える機会がない。結果、システムは「標準パターン」だけ動く状態で本番を迎え、現場は「例外がさばけない」と言ってExcelに戻ります。この連鎖を1枚にすると、FIG.02のようになります。

FIG.02因果図

導入後もExcel・紙が残るのは、言語化されていない例外が要件に入らないまま本番を迎えるから

上から下へ。各段が、次の段の原因になっている

01 前提
業務は「現場の人が頭の中で覚えている前提」で動いている。得意先ごとの納期延長、カタログと実物の規格差の口頭確認、長年同じ会社に頼んでいる配送
02 要件定義
ヒアリングで現場が見せるのは「いつもの仕事」だけ。例外は業務フロー図にも要件にも入らない
03 本番稼働
システムは標準パターンだけで動く。例外が来ると、標準機能では処理できない
04 現場の回避
例外をExcel・紙・口頭で処理し始める。システムとExcelへの二重入力が生まれる
05 定着
運用責任者が決まっていなければ誰も直さず、回避策のExcel・紙がそのまま正式な運用になる
連鎖を断ち切れる段
断ち切れるのは2か所です。02の前に例外を書き出すこと(FIG.01の02)と、05の前に運用責任者を任命すること。どちらも、システムの機能ではなく導入前の業務整理で決まります。

3. 経営者が判断すべき論点

システム導入を成功させるために、経営者が決めるべき論点は3つです。ベンダー選定でも、機能比較でもありません。

  • 業務のうち、システムに乗せる範囲と、人の判断に残す範囲をどう切り分けるか
  • 「言語化されていない例外」を洗い出すために、誰が、いつまでに、どのくらいの時間を使うか
  • 導入後に運用を回す人と、運用を直す人を誰にするか(社内に置くのか、外部に依存するのか)

この3つを決めずに、機能比較表とベンダー見積りだけで進めると、ほぼ確実に「現場で使われないシステム」になります。投資判断の前に、この3つの論点を社内で共通言語にする時間を取るべきです。

4. 現場で実行するための具体策

業務整理は、ふわっとした「ヒアリング」ではうまくいきません。手を動かす段取りを決めて進めます。要は要件定義でベンダーに見える「標準」の下に隠れた、言語化されていない例外を先に拾い出す作業です(FIG.02の01〜02)。

01業務の棚卸し(2〜4週間)

主要業務を10〜20プロセスに分解し、1プロセスごとに「担当」「頻度」「所要時間」「使っているツール」「例外パターン」を1枚のシートに書き出します。粒度は「受注 → 在庫引当 → 出荷指示 → 配送依頼 → 売上計上」のレベル。現場担当者と1〜2時間ずつヒアリングを重ねるイメージです。書き出す項目は、FIG.03のシートにまとめています。

FIG.03記入テンプレート業務整理シート

要件定義の前に、プロセスごとに「例外・判断する人・データ・分類」までを1行で埋める

行がプロセス、列が書き出す項目。左から右へ埋め、最後の「分類」はFIG.04で決める

プロセス担当(個人名)頻度・所要時間扱うデータと置き場所(システム・Excel・紙)例外パターン判断・承認する人分類
受注
在庫引当
出荷指示
配送依頼
売上計上

表は横にスクロールできます

「例外パターン」が空欄の行は、まだヒアリングが足りていない候補です。このシートをそのままベンダーに渡せる状態にしてから、要件定義に入ります。

行は本文の粒度の例です。自社の主要業務に置き換えて使ってください。「分類」には「システム化」「システム+人の判断」「運用ルール」「人の判断に残す」のいずれかを書きます。

02標準化と例外の切り分け(1〜2週間)

棚卸ししたプロセスごとに、「これは標準化できる」「これは例外として人の判断を残す」を分類します。標準化できる業務は、システムに乗せる対象。例外として残すものは、システム外でハンドリングする運用ルールを作ります。「全部システム化」を目指さないことが鍵です。分け方の目安はFIG.04のとおりです。

FIG.04判断マトリクス判断例

システム化するのは「件数が多く、定型にできる業務」。それ以外は運用ルールと人の判断で解く

縦軸は発生する頻度・件数(上ほど多い)、横軸は手順を定型にできるか(右ほど定型)。FIG.03の各行をどこかのマスに置く

頻度・件数 少ない → 多い
多い × 定型にしにくい

システム+人の判断

記録はシステムに乗せ、判断が要る箇所だけ人に回す確認・承認の工程を要件に入れる

多い × 定型にできる

システム化する

標準化できる業務。候補システムの標準機能で回るかをFit/Gapで確かめる

少ない × 定型にしにくい

人の判断に残す

判断基準と相談先を文書にする。無理にシステムへ乗せない

少ない × 定型にできる

運用ルールで解く

手順書・チェックリストで回す。件数が増えたら、システム化を検討し直す

定型にしにくい(判断・例外が多い)定型にできる
システムに乗せる対象人の判断を要件に組み込む対象
右上だけがシステム化の本命です。左側の2マスを「全部システム化」しようとすると、カスタマイズが膨らみ、使われない機能が残ります。

この図は判断の一例で、実績を示すものではありません。法令対応や監査で記録が求められる業務は、件数にかかわらず記録の方法を個別に確認してください。

03Fit/Gap分析と要件定義(2〜4週間)

標準化対象の業務に対して、候補システムの標準機能で何が満たせて、何が満たせないかを洗い出します。Gapが大きいシステムは見送るか、カスタマイズコストを含めて再評価します。要件定義は、棚卸し済みの業務シートをそのままベンダーに渡せる状態にしておくと、認識ズレが激減します。

04段階導入と運用定着(3〜6ヶ月)

全業務を一度に切り替えず、1〜2業務ずつ移行します。最初の業務がシステム上で2サイクル回ってから、次の業務を移す。運用が回らない状態を作らないことを最優先にします。並行して、運用マニュアルと例外ハンドリングの判断基準をドキュメント化します。

5. 失敗しやすい落とし穴

業務整理の段で、よく見る落とし穴を3つ挙げておきます。

  • 完璧な業務整理を目指してしまう。すべての例外を洗い出そうとすると、棚卸しに半年以上かかり、その間に経営環境が変わります。Fit/Gapの優先順位だけ決めて、走りながら直す前提で進めるべきです。
  • 外部ベンダーに業務整理まで丸投げする。ベンダーは自社製品に寄せた整理をします。中立な視点で棚卸しできる人を、社内か社外に置くことが重要です。
  • 運用を回す人を決めずに導入を進める。導入後に「誰がこのシステムの運用責任者か」が決まっていないと、誰も例外対応をせず、現場が個別にExcelで回避する状態に戻ります。導入決裁と同時に、運用責任者を任命してください。
First Check

最初に確認する3項目

  1. 主要業務の「例外パターン」を書き出した紙があるか業務フロー図やマニュアルに、例外の欄があるかを見ます。なければ、FIG.03のシートの「例外パターン」列から埋め始めます。
  2. 導入後の運用責任者を、個人名で答えられるか例外対応を判断する人と、システムの設定を直す人が決まっているかを確認します。
  3. いまシステムの外で回っているExcel・紙を数えたか既存システムがある会社は、Excel・紙で処理している業務を1つずつ挙げ、それがどの例外を処理しているかを書きます。そのExcel・紙が、次のシステムで要件に入れるべき例外の一覧になります。

6. eapとしてどう支援するか

eapが業務整理に入るときは、まずベンダー選定を止めることから始めます。先に、棚卸し用のスプレッドシートテンプレートと、現場ヒアリングの質問リストを用意し、2〜4週間で主要業務の見える化を行います。標準化と例外の切り分けも、私たちが第三者として整理します。

そのうえで、必要ならRuffnote(グループ会社の開発会社)と連携し、SaaS導入では埋まらないGap部分を自社開発で補完します。市販パッケージで100%カバーできない地場産業の業務は、「標準SaaS+ Ruffnote製の補完ツール」の組み合わせで現場に定着させる構成が最も成功率が高いです。

システム導入の成否は、契約後ではなく契約前の3ヶ月で8割決まります。仕組みは、入れるものではなく、整えてから乗せるものです。

無料相談
まずは、業務の棚卸しから一緒に整理しませんか。
受託前提のヒアリングではなく、業務プロセスのうちどこから手をつけると効くかを、60分で整理してお返しします。すでにシステム導入を検討中の方、過去の導入が定着しなかった方どちらでも歓迎です。
↗
設計から実装まで
SaaSで埋まらないGapは、Ruffnoteで補完する選択肢。
市販パッケージで100%カバーできない地場産業の業務に対して、グループ会社ラフノートと組んで「標準SaaS+補完ツール」の構成を実装します。
↗

← 実務メモ一覧へ戻る