造船、ドライドック、レトロフィット、大規模な船舶のアップグレードは、日常的な船舶管理業務ではありません。これらは設備投資プロジェクトです。そして設備投資プロジェクトには、プロジェクト管理とプロジェクト単位の統制が必要です。
船主や船舶管理会社にとって、船舶を造船所に入渠させることは、船主の技術チーム、造船所、協力会社、サプライヤー、船級協会、機器メーカー、金融機関、用船者、保険会社が関わる、一時的でありながら極めて重要な運用環境を生み出します。
数百万ドルが数週間のうちに投じられることもあります。数百、数千の作業項目が同時に実施されることもあります。仕様は変わります。機関を開放したり鋼材を検査したりした後で、追加工事が発生します。引渡日は商業上、引き続き極めて重要です。
しかし経営陣は、多くの場合、数百キロ、数千キロも離れた場所にいます。
そこで根本的な問いは次のようになります。
船舶管理会社は、物理的にあらゆる場所にいなくても、どうすれば「造船所の中の目」を持てるのでしょうか？
答えは、ダッシュボードをもう一つ増やすことではありません。スコープ、工程、コスト、調達、品質、文書、そして実際の実行を一つの管理された環境に結び付ける、海事プロジェクト管理プラットフォームです。
船舶管理会社と造船所の間にある可視性のギャップ
従来の船舶管理ERPは、技術管理、計画保全、調達、配乗、会計、コンプライアンス、運航業務など、船舶の運用ライフを管理することに優れています。
しかし、大規模なドライドック、改造、レトロフィット、新造船プログラムは、異なる性質を持ちます。
そこには定められたスコープ、予算、完了日があります。元請けや協力会社が関与します。作業は出来高と照らして測定されなければなりません。変更には承認が必要です。調達は計画された作業を支えなければなりません。検査と品質記録は実行に伴って作成されなければなりません。
そして最も重要なのは、時間とコストが常に相互に影響し合うことです。
これらの活動をスプレッドシート、メール、メッセージングアプリ、孤立した工程管理ツール、造船所からの報告書で管理していると、経営陣が受け取るのはプロジェクトそのものではなく、その断片です。
その結果、可視性のギャップが生まれます。
発注書が発行されたことを知るだけでは不十分です。経営陣が知るべきなのは、どの作業パッケージがそれを必要としたのか、その作業は工程どおりか、資材は到着したか、予算に対していくらかかっているか、そして遅延が船舶の引渡しを脅かしていないかです。
ドライドックはプロジェクトです。プロジェクトとして管理しましょう
大規模なドライドックを考えてみましょう。
入渠前の段階で、船舶管理会社はすでに、鋼材修理、塗装、機関のオーバーホール、法定検査、船級要件、機器交換、計画的なアップグレードを含む計画仕様を持っています。
船舶が造船所に入ると、現実が計画を変え始めます。
検査によって追加の鋼材更新が判明します。機関に予期せぬ修理が必要になります。サプライヤーが納期を変更します。船級協会が追加工事を要求します。造船所が変更を提出します。新たな協力会社が加わります。
あらゆる変更が、コスト、工程、再引渡しに影響する可能性があります。
従来のワークフローでも、これらの出来事を記録することはできます。しかしプロジェクト管理プラットフォームは、より重要なことを行うべきです。
それらを結び付けることです。
それこそが、次の製品の設計思想です： ProjectVIEW ERP。
ProjectVIEWは、BoQ/スコープ ↔ WBS/工程 ↔ Cost Codesというプロジェクトの軸を通じてプロセスを結び付ける、統合されたプロジェクト環境を中心に設計されています。プラットフォームは、プロジェクト・ポートフォリオ管理、ワークフロー、分析、一元化されたプロジェクトデータをサポートします。
船舶管理会社にとっては、用語を海事の業務に合わせて読み替えることができます。ドライドック仕様書または作業パッケージが商務上のスコープとなり、WBSが計画された実行を表し、Cost Codesが管理上および財務上の管理構造を提供します。
経営陣に「造船所の中の目」を
デジタルな可視性は、作業が行われる場所から始まるべきです。
プロジェクトチームは、本社で後から何が起きたかを再構成するのではなく、造船所から出来高、要請、検査、リソース、調達イベント、文書、変更を記録できるべきです。
ProjectVIEWのアーキテクチャは、一元化されたプロジェクト情報と、さまざまな場所や端末からの管理されたアクセスを前提に設計されています。造船・修繕環境向けのプロジェクト特化型の実装では、オフィス、造船所、生産現場、ベンダー、サービス会社、協力会社、顧客にまでコラボレーションを広げながら、プロジェクトのプロセスをスコープ、工程、コストの各軸と関連付けます。
これにより、経営陣の問いは次のように変わります。
「造船所で何が起きているのか？」
から：
「昨日から何が変わったのか、何が工程から遅れているのか、何が予算を超過しているのか、何に私の承認が必要なのかを見せてほしい」
これこそが本当の状況把握です。
造船所の出来高からリアルタイムのコスト管理へ
コストを伴わない出来高は、不完全な情報です。
出来高を伴わないコストは、さらに誤解を招く可能性があります。
たとえば、ドライドック予算の65%がすでに消化されているのに、計画作業の45%しか完了していないとします。あるいは、調達のコミットメントが大幅に増えている一方で、いくつかの重要な作業パッケージが工程から遅れているとします。
経営陣は、造船所の最終請求書を受け取った後ではなく、まだ介入が可能なうちにこうした差異を特定する必要があります。
ProjectVIEWのビジネスロジックは、予算とコスト管理をプロジェクトの工程計画や日々の取引と結び付け、実際のプロジェクト活動をベースラインと比較できるようにします。そのコスト管理手法は、工程と財務記録を別々の世界として扱うのではなく、BoQ/スコープ、WBS、Cost Codesを結び付けます。
船舶管理会社にとってこれは、ドライドックを最終コストの突合せ作業ではなく、継続的に管理されたプロジェクトにできることを意味します。
調達はプロジェクトに従うべきであり、その外側で動くべきではありません
海事プロジェクトは、調達への依存度が非常に高いものです。
鋼材、塗料、スペアパーツ、専門機器、OEMサービス、外注工事は、該当する作業が必要とするタイミングで到着しなければなりません。
発注書が「承認済み」であっても、プロジェクトが守られているとは限りません。
本当に問うべきことは次のとおりです。
どの作業がその資材を必要としているのか？いつ必要なのか？サプライヤーは確認したのか？到着したのか？到着しなければ船舶の再引渡しはどうなるのか？
ProjectVIEWは、資材要請、購買申請、見積依頼（RFQ）、サプライヤーの見積、発注書、受入、在庫の各プロセスを、より広いプロジェクト環境の中で結び付けます。調達ワークフローはプロジェクトの要件から開始でき、サプライヤーの比較、購買、資材の受入を支援します。
船舶管理会社にとって、これにより調達は切り離された管理業務ではなく、プロジェクト実行の一部となります。
変更を白紙小切手にしてはなりません
ドライドック中の最大の商業上のリスクの一つは、追加工事です。
ある程度の変更は避けられません。問題は、追加工事が断片的なメール、電話での会話、スプレッドシートを通じて、その累積的な影響がすぐに見えないまま承認されるときに始まります。
すべての変更は、次の4つの問いに答えるべきです。
なぜ必要なのか？いくらかかるのか？工程にどう影響するのか？誰が承認したのか？
構造化されたワークフローは、要請から技術評価、商務評価、承認を経て実行に至るまで、追跡可能な連鎖を生み出します。
ProjectVIEWは、ワークフロー主導のプロセス管理と一元化された文書管理をサポートし、スコープの無秩序な拡大を許すのではなく、変更に対する責任の所在を明確にするのに役立ちます。造船所向けの構成では、コスト管理や出来高管理と合わせて、変更要求のリアルタイム管理を特に組み込んでいます。
品質とは証拠であり、宣言ではありません
船主や船舶管理会社にとって、引渡しの成功とは単に船舶をドライドックから出すことではありません。
プロジェクトは、監査可能な記録を残さなければなりません。
検査報告書、証明書、承認図面、試験結果、写真、RFI、パンチリスト、船級関連文書、機器証明書、最終記録は、後に不可欠な証拠となる可能性があります。
これは社内だけでなく、契約上および規制上の要件に応じて、船級協会、融資元、用船者、保険会社、その他の権限を持つステークホルダーに対してプロジェクトの状況や資産の健全性を示す際にも重要です。
したがって、アクセス管理、バージョン管理、ワークフロー、プロジェクトとの関連付けを備えた一元的な文書環境は、単なる文書保管ではなく、プロジェクトガバナンスの一部となります。ProjectVIEWのプロジェクト環境は、業務ワークフローと並行して、一元的な文書管理と管理されたコラボレーションを組み込んでいます。
目的は明快です。
作業が正しく完了したとステークホルダーに伝えるのではなく、それを証明できるようにすることです。
海事プロジェクトのライフサイクル全体を一つのプラットフォームで
同じ原則は、ドライドックをはるかに超えて当てはまります。
船舶管理会社は、アジアでの新造船プログラム、スクラバーやバラスト水処理装置のレトロフィット、エンジンの改造、損傷後の大規模修理、船舶の寿命延長プログラム、そして複数の定期ドライドックを同時に監督していることがあります。
それぞれを独立したスプレッドシートやメールのやり取りで管理していては、ポートフォリオ全体の管理は極めて困難です。
一元化されたプロジェクトプラットフォームであれば、これらのプロジェクトに共通の運用モデルを確立できます。
- スコープと作業パッケージの管理
- プロジェクト予算とコスト管理
- 工程計画と出来高
- 調達と資材
- 協力会社およびサービス会社の管理
- 変更管理
- 検査、QA/QC、文書管理
- 承認と監査証跡
- 経営ダッシュボードとプロジェクト・ポートフォリオ報告
ProjectVIEWは、複数企業・複数プロジェクトに対応する環境として設計されており、個々のプロジェクトを新たな情報のサイロに閉じ込めるのではなく、一元化されたプロジェクト情報と役割に応じた分析を提供します。
ProjectVIEWは海事ERPを置き換えるものではありません
この区別は重要です。
船舶管理会社はすでに、船舶運航、保守、購買、財務、配乗をカバーする成熟した海事ERPを導入している場合があります。
目的は必ずしもそれを置き換えることではありません。
ProjectVIEWは、資本集約的な海事プロジェクトのためのプロジェクト実行・管理レイヤーとなることができ、必要に応じて既存の基幹系、財務、海事、専門システムと連携します。
ProjectVIEWはAPIフレームワークを備え、サードパーティのアプリケーションとの連携を前提に設計されている一方、そのプロジェクト環境はプロジェクト型の実行に必要なビジネスロジックを提供します。
このアーキテクチャでは、海事ERPは引き続き船舶を運用資産として管理します。
ProjectVIEWは、その資産に対して実行されるプロジェクトを管理します。
これはまったく異なる要件です。
遠隔監督からデジタルなプロジェクト管理へ
船舶管理会社に必要なのは、造船所からの報告書をさらに増やすことではありません。
必要なのは、実行状況への直接的で構造化された、タイムリーな可視性です。
何が計画され、何が完了し、何が変わり、何がコミットされ、何が支出され、何が未完了で、何が引渡しを脅かしているのかを知る必要があります。
2,000万米ドルのドライドックや5億米ドルの新造船プログラムにおいて、昨日のスプレッドシートを待つことはプロジェクト管理ではありません。
未来は、スコープ、時間、コスト、調達、品質、文書、説明責任が継続的に現実と照合されるデジタルなプロジェクト環境にあります。
そこでProjectVIEW ERPは海事管理システムを補完し、船主や船舶管理会社が造船所の中にデジタルの目を持つために必要なプロジェクト管理レイヤーを提供します。
