「おかげさまで、無事に稼働しました」。導入プロジェクトの報告でこの一言が出ると、部屋の空気がふっと緩みます。
ところが3週間後、経理から「旧システムと売掛金の残高が合わない」と連絡が入る。営業の何人かは、まだExcelで受注を管理しています。経営者の耳に届くのは、たいていこの頃です。
慌てる必要はありません。稼働後の30日に点検の手を入れれば、ずれは直せるうちに拾えます。
稼働（ゴーライブ＝新しい仕組みを本番で使い始めること）はゴールではなく、点検の起点です。入力の迷いや想定外の取引が出そろうのが、稼働後の1か月だからです。
見るのは「データ・人・業務・次」の4つの群に分けた10項目です。たとえば移行データの件数は、各アプリの標準的な一覧やピボットで見比べれば足ります（データが正しいか）。
30日の点検で、たとえば次のことが変わります。
- 件数や残高の差を、理由を説明できる形で早めに合わせられる
- 一度もログインしていない人や、代行入力の偏りに気づける
- 最初の月次の締めで、手作業が残った工程が分かる
- 30日目に、導入目的の数字が見えているかを経営者が確かめられる
ただし、点検の途中で、Odooの標準では業務が回らないと分かることもあります。そのときは仕組みを見直す選択肢も並べます。
では、見つかった問題を放置させないには、どう扱えばよいのか。答えは点数ではなく、担当と期日にあります（30日で満点を目指さない）。
CommunityとEnterpriseの区別について
件数の確認や集計は、各アプリの標準的な一覧・ピボット・グラフとして両版で使えます。一方、月次の締めに関わる会計のフル機能はEnterprise版が前提です。
ERPの稼働日は、いちばん危ない30日の入口
導入プロジェクトは稼働日を目標に走るため、稼働した途端に緊張が緩み、体制も静かに解散していきます。
一方で、現場の新しいやり方が始まるのは翌朝からです。入力の迷いや想定外の取引が出そろうまでに、1か月ほどかかります。
体制がいちばん薄い時期と、問題がいちばん出る時期が重なる。ここを埋めるのが30日の点検です。
稼働日をゴールと見ると、稼働と同時に体制が解散し、ずれに誰も気づかないまま半年後に手戻りが来ます。点検の起点と見れば、30日は体制を残し、直せるうちにずれを拾えます。
稼働までの90日の進め方は、Odoo導入 最初の90日プランにまとめました。
群1：データが正しいか（3項目）
最初に見るのはデータです。ここがずれると、以降の数字がすべて狂います。
移行したデータの件数が合っているか
移行前のシステムとOdoo側で、取引先や品目などの件数を見比べます。確認は、各アプリの標準的な一覧やピボット（縦横に集計する表）で十分です。移行の進め方はOdooへのデータ移行の進め方で扱っています。
並行稼働と検証の考え方は、NetSuiteの教科書の基幹システムのデータ移行ガイドも参考になります。製品を問わず使える手順です。
日々の取引が実際に記録されているか
稼働したのに、現場が従来のやり方を続けている例があり、受注や入出庫の登録件数を日別に見れば分かります。
在庫や残高が実態と合っているか
帳簿と現物、帳簿と通帳の差異を、早い段階で一度合わせます。差が出ること自体より、理由を説明できないことが問題です。
群2：人が使えているか（3項目）
データが正しくても、人が使っていなければ定着しません。
全員がログインしているか
一度もログインしていない人がいないかを見ます。使っていない人は不満すら言わないので、こちらから見に行きます。
入力が特定の人に偏っていないか
本来の担当が入れず、詳しい誰かが代行している状態です。登録者ごとの件数を見て、偏りがあれば理由を聞きます。定着の進め方はOdooを社内に定着させる方法で触れました。
「使いづらい」の中身が集まっているか
声を集める窓口が決まっているかを見ます。窓口がないと、声は雑談のなかで消えます。分解の視点は「このシステム使いづらい」の原因と解決策にまとめました。
群3：業務が止まっていないか（2項目）
月次の締めができたか
稼働後の最初の締めが、想定した日数で終わったかを見ます。延びていれば、どこかの工程に手作業が残っている証拠です。
例外処理の回し方が決まっているか
返品や締め後の修正など、想定外の取引は必ず出るため、誰がどう判断するかを決め、1枚に書き出しておきます。
群4：次につながっているか（2項目）
当初の目的に対する数字が見えているか
何のために導入したのかをもう一度確認し、その数字がいま取れるかを見て、取れないなら何が足りないかを洗い出します。
改善の要望が記録されているか
見るのは、出た要望が消えずに残っているかどうかです。対応する・見送る・保留するに分け、見送った判断も残します。運用の回し方はOdooの運用・保守で押さえるポイントで扱いました。
ここまでの10項目を群ごとに1枚にまとめたのが、次の図です。
稼働後チェックリストは30日で満点を目指さない
10項目を挙げましたが、30日で満点を目指さないでください。
稼働直後にうまくいかないことがあるのは普通です。「何個できていれば合格」という基準を作ると、点数を上げること自体が目的になります。
目指すのは、「できていない項目が放置されずに、誰かの手元にある状態」です。チェックリストの狙いは、問題を見える形にして担当を決めることにあります。
「項目5はできていない。担当は営業部長、次の確認は2週間後」。この3つが書けていれば合格だと、ベンチャーネットは考えています。
点検で見つかった状態は、次の表で読み替えると会議で扱いやすくなります。
| 見つかった状態 | まず疑うこと | 次の一手 |
|---|---|---|
| 件数や残高が合わない | 移行時の抽出条件や締め日のずれ | 差の理由を1件ずつ説明できるまで追う |
| Excelや旧システムと並行している | 入力の手間か、新しい数字への不安か | 並行をやめる日を決めて全員に伝える |
| 入力が詳しい人に集中している | 操作に慣れていないか、権限の設定 | 本来の担当と並んで入力する時間をとる |
| 締めが想定より延びた | 手作業の工程が残っている | 工程を書き出し、設定と運用のどちらの問題か分ける |
| 導入目的の数字が取れない | 入力項目か、集計の仕方が足りない | 項目を足す前に、何の判断に使う数字かを決める |
この点検の良い点と、気をつけること
30日の点検は、体制がいちばん薄い時期に手間を足す作業です。それでも続ける価値があるのは、次の5つの良い点があるからです。
- ずれを直せるうちに拾える：点検しなければ、ずれた数字が積み上がり、半年後に手戻りが来る
- 問題が放置されない：見つけた問題に、その場で担当と期日をつける
- 会議で扱いやすい：見つかった状態を、上の表で「まず疑うこと」と「次の一手」に読み替えられる
- 導入目的の数字を確かめられる：30日目に、経営者と一緒に目的の数字が見えているかを見る
- 合わないことに気づける：Odooの標準では業務が回らないと分かれば、仕組みを見直す選択肢を並べられる
気をつけることは、次の4つです。
- 30日は体制を残す：導入プロジェクトの体制を、稼働と同時に解散させない。業務側と情報システム側の2人体制を勧めている
- 満点を目指さない：合格の基準を作ると、点数を上げること自体が目的になる
- 報告とは別に時間をとる：データを見る作業と人に会って聞く作業は、稼働報告と別の時間に置く
- Community版は障害時の担当を決める：ホスティング・保守は自社の責任。止まったとき誰が動くかを先に決めておく
両方を1枚の図に並べました。
1週目から30日目までの具体的な順番は、稼働後の1か月、ベンチャーネットが立ち会う順番にまとめています。
稼働後の1か月、ベンチャーネットが立ち会う順番
ERPは、ITではなく経営のプロジェクトです。ERP導入支援を手がけるベンチャーネットは、稼働後の1か月を次の順番で一緒に確かめます。
- 1週目：件数と残高を照らし合わせる。基準は、差の理由を説明できるかどうかです。説明できない差は、2週目に持ち越しません。
- 2週目：入力者の偏りを見て、現場に会いに行く。代行入力の理由を聞き、Fit to Standard（標準機能に業務を合わせる考え方）で直せるかを見ます。
- 最初の月次の締め：手作業が残った工程を書き出す。設定で直すか、業務の手順を変えるかを、工程ごとに決めます。
- 30日目：経営者と一緒に、導入目的の数字を見る。見える化→わかる化→儲かる化の順で、まず数字が見えているかを確かめます。
見える化の先に何を置くかは、儲かる化とはで全体の地図を描きました。
この途中で、Odooの標準では業務が回らないと分かることもあります。その場合、ベンチャーネットは合わないと正直にお伝えし、3〜5年後の姿から逆算して、仕組みを見直す選択肢も並べます。
CommunityとEnterpriseで変わること
Community版は無料のオープンソース、Enterprise版は有償のサブスクリプションです。10項目のうち、版で進め方が変わるものがあります。
| 確認したいこと | Community版 | Enterprise版 |
|---|---|---|
| 件数の照合・集計 | 標準的な一覧・ピボット・グラフで確認できる | 同じく確認できる |
| 月次の締めの確認 | 請求書発行など基本的な範囲の会計まで | 財務諸表の出力や分析会計を含むフル機能が前提 |
| 稼働直後の障害対応 | ホスティング・保守は自社の責任 | 公式サポートを利用できる |
なお、版ごとの対応範囲は改定されることがあります。導入を検討する段階で、Odoo公式のエディション比較ページで最新の内容をご確認ください。
Community版では「止まったとき誰が動くか」を先に決めておきます。空白のまま稼働日を迎える例は少なくありません。
よくある2つの失敗
失敗1：点検を稼働報告と一緒にしてしまう
報告の場では、うまくいった話が集まりやすくなります。データを見る作業と、人に会って聞く作業は、別の時間に置きます。
失敗2：問題を見つけて、そこで終わる
よくあるのは、一覧に書き出したあと、担当が決まらない項目が残る形です。見つけた問題には、その場で名前と期日をつけます。
よくある質問
30日という区切りに根拠はありますか？
厳密な根拠はありません。最初の月次の締めが一巡し、現場の迷いが出そろう期間として扱いやすいからです。
10項目を一度に見る必要がありますか？
必要はありません。群1のデータ、群2の人、群3の業務の順が現実的です。群4はそのあとで構いません。
点検は誰に任せればよいですか？
導入プロジェクトの責任者に続けてもらうのが自然です。1人で抱えると形式的になりやすいため、業務側と情報システム側の2人体制を勧めています。
できていない項目が多いとき、経営者は何を見ればよいですか？
項目数より、放置されている項目があるかを見てください。業務と標準機能のずれが大きいなら、設定と運用のどちらの問題かを切り分けます。
稼働後のチェックリストには、何を入れればよいですか？
データ・人・業務・次の4つの群で10項目を見ます。
データは件数・日々の記録・在庫と残高、人はログイン・入力の偏り・「使いづらい」の窓口です。業務は月次の締めと例外処理、次は目的の数字と要望の記録です。1つずつの見方は、データが正しいかから順に書きました。
まとめ：ERPの定着は稼働後30日の扱いで変わる
- 稼働日はゴールではなく、問題がいちばん出る時期の入口である
- 体制が薄くなる時期と、問題が出る時期は重なっている
- 10項目は「データ・人・業務・次」の4つの群で見る
- 満点ではなく、放置されている項目をなくすことを目指す
- 見つけた問題には、その場で担当と期日をつける
ERP（基幹業務システム）が定着するかは、稼働後の最初の1か月の扱いで変わります。
規模が大きくなり連結決算が視野に入るなら、NetSuiteなど上位のERPが候補です。比較はOdooとNetSuiteの違いにまとめました。複雑なグローバル要件ならSAPも検討の対象です。パッケージに乗らない固有業務が中心ならAIスクラッチ開発もありますが、開発費と保守費が別途かかります。
1年後、稼働1周年の会議で開くのは、30日目に作った点検表の続きです。担当と期日の欄が埋まり続け、残高の差もExcelでの並行管理も、もう議題に上がっていない。そんな会議を目指してください。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
「稼働はしたが、このまま任せてよいのか判断がつかない」という整理から、ご相談を承っています。
関連記事
