船舶修繕業務には、プロジェクト水準のERPが必要です。実務上、それは迅速な再見積り、入渠中のスコープ変更、応急工事の原価追跡、乗込みクルー管理、リアルタイムの原価完成見通しの可視化を意味します。
汎用ERPや資産管理システムでは不十分です。なぜなら、船舶修繕は保全計画ではなく、プロジェクト業務だからです。ProjectVIEW ERP by DANAOS Projectsは、そのためにBoQネイティブの原価統制を提供します。
船舶修繕が資産保全ではなくプロジェクト業務である理由
船舶修繕ヤードは、運用中の資産保全とは根本的に異なるビジネスモデルで運営されています。まず、すべての修繕案件は固有です。また、損傷査定の過程で、当初は見えなかった構造上の問題、隠れた腐食、機械不具合が明らかになるため、スコープも絶えず変化します。さらに、時間制約は極めて厳しく、船舶が入渠中に発生するオフハイヤー費用は、船種や市場料金により1日あたりUSD 20,000~100,000に達します。その結果、変更指示は例外ではなく通常運用になります。
船級協会の要件は、規制面の複雑さをさらに加えます。船体検査、機関証明、法定検査が完了し文書化されるまで、船舶は運航を再開できません。要するに、これは保全計画ではなくプロジェクト管理です。各修繕は、時間制約があり、予算制約を受け、スコープが変動する、コンプライアンスと耐航性の提供業務です。
一方、ベンダーは、汎用の資産管理システム(eMaintenance、CMMS)を、定期予防保全、予備品在庫、予知監視向けに設計しています。しかし、これらのシステムでは、迅速な再見積り、複数職種の下請け業者連携、緊急調達、請求の複雑さには対応できません。また、プロジェクト原価統制も備えていません。つまり、見積原価、実績、コミット済み原価を並行して追跡し、超過をリアルタイムで管理者に警告する機能です。
船舶修繕の3つのモード
計画入渠
このモードは、定期保全、船体処理、機関オーバーホール、規制検査を対象とします。ここでは、ヤードが修繕仕様を事前に定義します。まず、数量表(BoQ)を作成し、次に下請け業者へ発注し、予算を合意し、船級・法定の期限に合わせて作業を計画します。
計画入渠は通常4~12週間です。予算の大半は前倒しで確定するため、コストは比較的予測しやすいものの、塗装検査で追加腐食が見つかったり、機関分解で隠れた摩耗が露呈したりすると、スコープ変更が発生します。だからこそ、計画作業であっても入渠コスト統制が重要です。
応急工事
応急工事とは、計画外の緊急修繕です。例えば、航行中に船体損傷、機関故障、構造異常などの事故が発生します。その場合、船舶は最寄りの修繕ヤードへ向かわなければなりません。損害査定は迅速に行われ、ヤードはその場で修繕仕様を作成します。同時に、下請け業者を直ちに動員し、プレミアムコストで調達を急ぎます。したがって、速度と原価の可視化が極めて重要です。
特に、船主と保険鑑定人は、スコープの承認または制限を判断するため、完成見通しの原価をリアルタイムで把握する必要があります。応急工事は2~8週間に及ぶこともあり、コスト変動も大きくなります。
乗込みクルー/航海中修繕
これらは、船舶の運航航海中に海上または寄港地で行う修繕です。たとえば、乗組員や外部技術者がヘリコプターまたは補給艇を通じて、応急補修、故障部品の交換、暫定措置を実施し、船舶が本格修繕ヤードに到着するまで運航を維持します。
これらの修繕は短期間で、遠隔で連携されます。それでも、ヤードはそれらを追跡し、船舶案件または航海案件へ請求し直さなければなりません。チームは、現地または緊急供給網を通じて資材と労務を確保します。その結果、作業が分散した場所で行われるため、文書管理と原価追跡が断片化します。
船舶修繕ヤードに求められるERP機能
BoQベースの見積り
まず、ヤードは修繕仕様を構造化された数量表として定義する必要があります。これは、船体工事、機関工事、艤装工事、認証について、数量、単位、単価、項目別総額を示す明細です。このBoQが、その後の調達、下請け契約、原価追跡、変更管理の基準となります。
実行中のリアルタイム原価統制
次に、システムは実績コスト(労務費、資材費、下請け請求書)を記録し、それをBoQ見積りとリアルタイムで比較しなければなりません。また、コスト超過、コミット済み原価(発注書、下請け変更指示)、完成見通し原価も把握する必要があります。管理者がスコープ拡大を承認するか、作業を抑制するかを判断するには、この可視化が不可欠だからです。
変更指示管理
さらに、ERPは入渠中のスコープ変更(追加の腐食修理、機関不具合、規制上の追加要件)を正式な変更指示として記録しなければなりません。各変更指示には、新しいBoQ項目、コストと工程への影響、承認フロー、船主への請求が含まれます。ERPは、元スコープ、承認済み変更、実行実績も追跡する必要があります。
下請管理
船舶修繕は多職種の業務です。鉄工、溶接工、塗装工、電気技師、機関技師、ダイバー(水中船体工事)、ロープアクセス専門家などが関わります。通常、各職種は別々の下請け業者です。したがって、ERPはBoQ項目を下請け業者へ割り当て、進捗証明と承認を追跡し、工程に対する進捗を監視し、請求書と変更対応を管理しなければなりません。
修繕仕様に連動した資材調達
同様に、ヤードは修繕仕様に合わせて鋼板、塗装システム、締結具、配管、バルブ、シール、消耗品を調達しなければなりません。応急工事では、調達は緊急かつ高コストになります。そのため、ERPは調達をBoQに紐づけ、発注、受領、請求を追跡し、工程に影響する遅延を警告する必要があります。
機関予備品管理
エンジン、ポンプ、コンプレッサー、ボイラー、補機類には、特定の予備品が必要です。したがって、ERPは機種に連動した予備品ライブラリを維持し、在庫を追跡し、廃番品や長納期品を警告する必要があります。機関原価統制との連携により、予備品費用が正しい修繕スコープに計上されます。
多通貨請求
船主は国際的です。たとえば、パナマ籍で、シンガポールで管理され、ロンドンで保険加入され、ドバイで修繕される船舶には、複数通貨で原価を整合させる請求処理が必要です。USD(労務費と国際下請け業者)、EUR(一部の職種)、AED(現地サービス)、その他の通貨が含まれます。したがって、ERPは多通貨での原価計上と請求に対応しなければなりません。
船級協会連携
最後に、ERPは証明書のマイルストーン、検査日程、船舶の船級協会(Lloyd’s、ABS、DNV、ClassNKなど)による承認サインオフを追跡する必要があります。検査スケジュールに不適合があると、船舶の運航再開が遅れ、オフハイヤーペナルティが発生する可能性があります。
船舶修繕向けERPおよびソフトウェア比較

船舶修繕業務向けのProjectVIEW ERP
DANAOS Projectsは、ProjectVIEW ERPをBoQネイティブのフレームワーク上に構築しました。つまり、数量表が後付けではなく中核データ構造です。ProjectVIEWのすべてのモジュールはBoQに接続しています。
予算見積りと入札
ProjectVIEWは、修繕仕様から迅速にBoQを作成できます。積算担当者は、項目(鋼材修繕、塗装、機関オーバーホール)、数量、単価を定義します。その後、システムが総見積原価と資材計画を算出します。応急工事では、チームは短時間でBoQを作成し、数時間以内に船主へ共有できます。
原価統制
作業の実行に伴い、システムは実績コストをBoQ項目に対して記録します。また、発注書、労務実績表、下請け請求書を各項目に照合します。ProjectVIEWは次を算出します。見積原価(予算)、コミット済み原価(発注書+下請け契約)、実績原価(請求書+労務費)、完成見通し原価。実績が見積りをしきい値以上に上回ると、差異アラートが発生します。これが、コスト超過を最速で把握し、是正措置を承認する方法です。
変更指示管理
スコープ変更が発生した場合(追加の鋼材修繕、発見された機関不具合、規制要件)、チームは正式な変更指示を作成します。そこには、新しいBoQ項目、コストと工程への影響、承認フローが定義されます。ProjectVIEWは、元スコープ(ベースラインBoQ)、承認済み変更(承認済みCO)、現行スコープ(元スコープ+承認済み変更)を追跡します。その結果、システムは未承認のスコープ膨張を防ぎます。
下請管理
システムは、BoQ項目を職種ごとに下請け業者へ割り当てます。たとえば、鉄工には船体修繕項目、機関技師にはエンジン/ポンプ項目、塗装工には表面処理を割り当てます。ProjectVIEWは、各下請け業者のスコープ、中間進捗、中間証明(船級協会検査官による承認)、請求を追跡します。中間証明はBoQ完了マイルストーンに紐づくため、最終支払い前に証明を義務付けることができます。
調達と資材管理
チームはBoQ要件に基づいて資材と予備品を調達します。応急工事では、ProjectVIEWが長納期品を警告し、緊急調達を開始できます。すべての発注書がBoQに連動しているため、原価追跡は一元化されます。見積 → コミット済み(PO) → 実績(受領と請求書)。
機関管理
機関の原価追跡は修繕仕様に直接連動します。たとえば、BoQでエンジンオーバーホール、ボイラー管交換、コンプレッサー交換を項目として定義します。機関モジュールは、各機関設備ごとの予備品、労務費、下請け費用を追跡し、それをBoQの原価ベースラインと照合します。これにより、機関工事が統制不能な領域へ逸脱しないようにします。
現在、船舶修繕ヤードはどのERPを使っていますか?
多くのヤードでは、レガシーシステムまたは分断されたツールを使っています。設計にはBIM、スケジューリングにはMS Project、原価管理にはスプレッドシート、会計には別のソフトを使うのが一般的です。BoQネイティブの原価統制を統合している例はほとんどありません。そのため、可視性の欠落と、変更指示承認の遅延が生じます。
汎用ERPで船舶修繕に対応できますか?
部分的には可能です。汎用ERP(SAP、Oracle)は、財務、調達、人事は管理できます。しかし、BoQネイティブの原価統制、迅速な再見積り、複数職種の下請けワークフローは備えていません。導入には12~18か月かかり、大規模なカスタマイズが必要です。船舶修繕は、これらのプラットフォームの設計中心ではありません。
入渠コスト統制と応急工事のコスト統制の違いは何ですか?
入渠は計画済みで、事前に予算化され、ベンダー契約と調達サイクルを管理する時間があります。応急工事は計画外で、リアルタイムの再見積りと承認が必要であり、迅速性ゆえに高コストで運用されます。ERPは、計画モード(予算固定)と応急モード(迅速な差異可視化)の両方を支援しなければなりません。
ProjectVIEWは航海中の乗込みクルー修繕をどのように扱いますか?
乗込みクルーによる修繕は、船舶案件内のサブプロジェクト、または別のコストコードとして記録できます。労務費、資材費、第三者技術者費用は、モバイルまたは遠隔入力でリアルタイムに記録され、船舶の原価ベースラインに集約されます。これにより、航海中修繕を船舶の修繕ライフサイクル全体に統合できます。
船舶修繕ヤードでProjectVIEW ERPを導入するにはどのくらいかかりますか?
一般的な本番稼働までの期間は5~7か月です。内訳は、現状把握(4週間)、設計と設定(8週間)、テストと研修(4週間)、切り替え(2週間)です。ヤードは導入期間中に、並行して1件の修繕を試行運用し、ワークフローを検証し、早期に不足点を把握することがよくあります。
結論
要するに、船舶修繕は資産保全ではありません。むしろ、固有で、時間制約があり、スコープが変動し、リアルタイムのコスト圧力を受けるプロジェクト業務です。計画入渠、応急工事、乗込みクルー修繕はいずれも、迅速なBoQベースの見積り、リアルタイム原価統制、変更指示管理、下請け業者の統括という同じ中核能力を必要とします。
しかし、汎用ERPや資産管理システムでは不十分です。BoQネイティブの原価統制がなく、船舶修繕が求める速度に対応できません。ProjectVIEW ERPは、資本集約型のプロジェクト産業向けに特化して設計されています。その三位一体のBoQ ↔ WBS ↔ Cost Codesフレームワークにより、修繕ヤード、造船所、海事オペレーターにプロジェクト水準の原価統制を提供します。
船舶修繕ヤードがコスト超過、変更指示の遅延、下請け業者や資材全体の可視性分断に悩んでいるなら、ProjectVIEWは、より速く、よりシンプルに統制へ移行する道筋を提供します。
