はじめに
典型的な光景を思い浮かべてください──営業が金曜納品を約束したのに、現場のプランナーが木曜の夜になって初めて知る。しかも設備や保守はERPの管理対象外だった。こうした情報の断絶を埋めるのが本ガイドの狙いです。
簡単なテーブルの部品表作成から、意図的に難易度を上げたレベル10の生産パズルまで、十のシナリオをクリック手順付きで並べました。
Odooの保守モジュールは、実際のものの流れ（在庫、ロット、ピッキング、生産）と顧客や経理が期待する記録をつなげる場所です。うまく回れば二度手間が減り、失敗するとERPのせいにされます。
多くの工場や倉庫は経験やWhatsApp、“FINAL_v3.xlsx”といったExcelで回っています。それで回っているうちは問題になりませんが、拠点が増えたり規模が拡大すると途端に脆弱になります。
保守はOdooのモジュール群の一部で、担当責任の明確化、手順の標準化、検索できる履歴を求めるチームが導入します。要するに、設備管理、予防保全、修理履歴を正しく記録することで、予算承認や監査に必要な根拠が揃います。
保守を導入すれば、受入→保管→ピック→製造→出荷→スクラップ→補充といった実務の流れをシステム上にモデル化できます。各工程が記録され、後から振り返れる証跡になります。
この記事では、初めての部品表作成から現場のバーコード運用まで、実際の会社例を交えた10のユースケースをお見せします。
主な想定読者はオペレーション責任者、倉庫責任者、生産計画者です。開発者も後から参加できますが、まずは現場ビジネスの言葉で説明します。
内容は難易度順のTop10です。Level 1（簡単）からLevel 10（上級）まで、各レベルに実際のOdoo上でのクリック手順を番号付きで示します。
見栄えのために最初からレベル10を選ぶ必要はありません。まずはチームが無理なく取り組めるところから始めましょう。
続いて「抱えている問題」セクションを読み、自分のチームに合うレベルを開いてください。
このガイドで分かること：
- 一般的な企業システムの中で保守が担う役割
- 現場が最も摩擦を感じるポイント（なぜそうなるのか）
- 初心者向けから上級戦略までの10のユースケース
- 自動化や連携で外部パートナーを招く価値が出る場面
抱えている問題
営業が金曜納品と約束したのに、その情報はメールに残ったままで保守側には届いていなかった――結果、木曜夜にプランナーが初めて気づく。急送費で利益が削られ、経理は月末になって初めて在庫差異に気づく、というよくあるパターンです。
現場が経験ベースで回る一方、在庫や生産データはOdooの外にあることが多く、そのギャップが欠品や緊急発注、月末の驚きにつながります。
思い当たる節はありませんか？多くのチームがぶつかる壁：
- 営業の約束と一致しない在庫台帳
- 実在庫を反映していない生産・購買計画
- 顧客や監査人に問われたときの追跡性の欠如
良いニュースは、すべてを一度に変える大改修は必要ないことです。下のユースケースのどれか一つを30日間Odooで運用し、結果を計測してください。
保守のトップ5ユースケース
ここではOdoo保守の使いどころを5段階に絞り、Level 1（今日でもできる）からLevel 5（エキスパート）まで順位付けしました。各項目は「何を作るか」と「Odooでのクリック手順」に答えます。
Level 1は導入の入り口、最終レベルは夢のような高度シナリオで単独で作るのは稀です。
まずは自分のチームに合うレベルを選び、テスト環境で手順をたどってください。慣れたら段階を上げていきます。
1. 機械が故障したときに最初の保守依頼を記録する Level 1 — Easy
Level 1は最小限の保守操作です：技術者一人、壊れた機械一台、追跡すべき一件の依頼。自動化やルーティングは使わず、付箋ではなく正式な記録を残すだけで価値があります。
Odooでの基本手順（概略）：
- 保守アプリをインストールし、Maintenance → Maintenance → Maintenance Requests → New を開きます。
- 該当設備を選び、保守タイプを“是正（Corrective）”、優先度を設定し、不具合内容を記入します。
- 依頼を技術者に割り当て、写真・エラーコード・短い動画を添付します。
- ステータスをNewからIn Progressに進め、作業時間を記録し、修理完了でRepairedにします。
- 設備のかんばんを開けば、ダウンタイム、使用部品、労務コストが履歴として確認できます。
得られるもの：故障対応が一つの記録で終始管理され、ダウンタイムや費用がWhatsAppや個人ノートに埋もれません。
2. シリアル、マニュアル、設置場所付きの設備台帳を構築する Level 2 — Easy
Level 2では設備（Equipment）機能を本格運用します。各資産に対してシリアル、設置場所、担当チーム、マニュアルを紐づける“正しい台帳”を作ります。
Odooでの基本手順（概略）：
- Maintenance → Equipments → New で製造元、型式、シリアル、稼働開始日、設置場所を登録します。
- ユーザーマニュアル、保証書、サプライヤー連絡先をそのまま添付しておきます。
- 設備の所有チームと日常対応する技術者を設定します。
- 機械分類（機械系、電気系、ソフト系）や経理向けの減価償却日を定義します。
- Equipmentsのかんばんを場所・カテゴリ・チームでフィルターすれば、資産を瞬時に見つけられます。
得られるもの：誰も更新しないExcel台帳を廃止し、現場の誰でも2クリックで参照できる一元化された設備レコードに置き換えられます。
3. 予防保全プランを立てて、故障を未然に減らす Level 3 — Medium
Level 3は予防保全プランの導入です。これでチームの対応は“その場しのぎ”から予定に基づく運用へ変わります。生産計画者が信頼できるカレンダーを持てるようになります。
Odooでの基本手順（概略）：
- 設備を開いてMaintenanceタブから“Preventive Maintenance”を追加します。
- 発生頻度を月単位、または稼働時間ベースで設定します（どちらか早い方を採用）。
- 期日14日前に自動で保守依頼が生成されるように設定します。
- 自動生成された依頼には設備に登録したチェックリストが紐づき、技術者はそれに従って作業します。
- 保守リクエストを完了すると次回分が自動でスケジュールされます。手作業は不要です。
- レポート → Maintenance Analysis で「予防：是正」の比率が上がるのを確認できます。
得られるもの：計画外のダウンタイムが大幅に減り、保守カレンダーが曖昧な約束ではなく生産計画の入力になります。
4. 保守を製造の作業場と予備部品管理に結びつける Level 4 — Hard
Level 4は保守と製造（ワークセンター）、在庫（予備部品）、SLAによるエスカレーションを連携させます。壊れた機械が生産ラインや経理に“不意打ち”を与えなくなります。
Odooでの基本手順（概略）：
- 製造 → 設定 → Work Centers で各ワークセンターに該当する設備を紐づけます。
- 是正保守リクエストが上がると、関連するワークセンターは計画上「使用不可」として自動的に反映されます。
- MRPは該当の製造オーダーを別ワークセンターへ再割当てするか、スケジュールを後ろへずらします。手作業は不要です。
- 依頼上で技術者が予備部品を専用ロケーションから消費すると、そのコストは設備に計上されます。
- 目標時間を超えてIn Progressのままの依頼はプラントマネージャーに通知するSLAルールを設定します。
- 保守分析とMRP実績を掛け合わせたレポートで、設備ごとの実際のダウンタイムコストが見える化されます。
得られるもの：保守と生産が分断されず、故障は製造の逸失生産・稼働時間・納期遅延という形で定量的に表れます。
設備とワークセンターの紐付け、予備部品の消費連携、SLAエスカレーションを跨いだ設計は、Dasoloがパートナーとして支援する典型的な作業です。
5. IoTとAIで予兆保全を回し、OEEをリアルタイムで可視化する Level 5 — Expert
Level 5は完全な運用基盤です。IoTセンサー、Studioの自動化、AIによる故障予測で技術者の派遣や部品確保まで自動化し、OEEダッシュボードで可視化します。
Odooでの基本手順（概略）：
- Odoo IoT Boxを設置し、振動・温度・電流・稼働時間などのデータをMQTTやModbusで流します。
- Studioでセンサーが一定値を超えてから60秒継続したら保守依頼を“Critical”で作る自動化を作ります。
- AIエージェントは稼働履歴を読み、故障の可能性を予測して適切なスキルを持つ技術者を割り当て、在庫で必要部品を確保します。
- 顧客向けのヘルプデスクチケットは設備に紐づけられ、過去の履歴から想定解決時間が自動で反映されます。
- サービスレベルを超えるダウンタイムが発生したら、マーケティングオートメーションが影響先へメールやWhatsAppで通知します。
- スプレッドシート／ダッシュボードで稼働率（Availability）、性能（Performance）、品質（Quality）、予測精度をプラント別・設備別にリアルタイムで追跡します。
得られるもの：反応型の介入が年内で半減し、ダウンタイムコストは四半期レビューでの漠然とした不満から経営KPIへと変わります。
IoTセンサ設計、AI予測ロジック、ヘルプデスク連携、OEEのリアルタイム化など、複数モジュールにまたがるアーキテクチャはDasoloがパートナーとして設計します。
専門家に依頼すべきケース
Level 1〜3で十分なら、標準のOdoo保守機能と社内の責任者、そしてテスト用のサンドボックスがあれば多くは自社で対応可能です。
Level 4以上になるとリスクが高まります：誤った自動メール、Studioの無秩序なカスタムで将来のアップグレードが困難になる、夜間にAPI同期が止まるといった問題が起きます。
これはチームの失敗ではありません。設計、テスト、ガバナンスの重要性が浮き彫りになっているだけです。
複数アプリの設計、国ごとの法令対応、複雑な連携、あるいは既に社内で決まっている本番稼働日がある場合はパートナーを入れてください。
Dasoloと一緒に進める理由
Dasoloは実務に沿ったOdoo導入を支援します：カスタムアプリ、明瞭な連携、コンサル退任後も現場が使えるトレーニングを提供します。
保守のロードマップに本ガイドの上位ユースケースが含まれるなら、まず短期の成果を作り、その後ステップ的に自動化や連携を進める段階的計画を一緒に描けます。
お客様はスコープと予算を管理し続けられます。私たちはOdooに関する深い知見を提供し、本番で高くつく学習を避けます。
無料相談のご案内：