25年以上にわたり、DANAOS Projectsは建設、インフラ、EPC、造船の分野で請負者やプロジェクト型組織とともに取り組んできました。また、海洋・オフショア、鉱業、採石、プロジェクト型製造といった、汎用ERPでは対応しきれない分野に向けた機能も開発しています。
異なる業界。異なるプロジェクト。異なるリスク。
しかし、繰り返し現れる教訓が一つあります。
プロジェクト型企業は、プロジェクトを汎用ERPの中の単なる一つの軸として扱うだけでは、効果的に管理できません。
請負者は単に資材を購入し、人を雇用し、機械を稼働させ、請求書を発行するだけではありません。調達、協力会社、労務、機器、生産、出来高認定、変更、キャッシュフロー、リスクを継続的に管理しながら、定められたスコープを工程と予算に沿って完遂しなければなりません。
同じ原則は、船舶を引き渡す造船所、機器集約型の業務を管理する鉱業請負者、エンジニアリング仕様に基づいて製作するプロジェクト型製造業者にも当てはまります。
これが、ProjectVIEW ERPが異なる発想で構築された理由です。
そのビジネスロジックの中心にあるのは、次の関係です。
BoQ ↔ WBS ↔ Cost Codes
数量明細書（Bill of Quantities：BoQ）は商務上のスコープと予算を定義します。作業分解構成（WBS）は時間と計画された実行を定義します。Cost Codesは社内のコスト管理構造を提供します。
ProjectVIEWはこれらの軸を結び付け、業務上の取引をスコープ、時間、コストに照らして継続的に評価できるようにします。
その結果は、取引を記録する場所がもう一つ増えることではありません。何が見積もられ、何が計画され、何が起きていて、それにいくらかかっているのかを、現実と継続的に照合する仕組みが生まれます。
以下は、実際のプロジェクト環境から私たちが得た、特に重要なERPの教訓です。
1. 建設・インフラ：予算は施工への引き継ぎを経ても生き続けなければなりません
繰り返される問題
建設業における最大の問題の一つは、ソフトウェアがないことではありません。システムと部門の間の断絶です。
積算担当者はBoQとスプレッドシートで作業します。工程計画担当者はOracle Primavera P6やMicrosoft Projectを使います。調達部門はサプライヤーと発注書を管理します。現場チームは出来高とリソースを記録します。財務部門は全社ERPに取引を記録します。
それぞれのシステムは個別の役割を果たしているかもしれません。
問題は、経営陣が次のように問うときに表面化します。
このプロジェクトで、今日の時点で本当に利益が出ているのか？
その答えを得るには、多くの場合、複数のシステムやスプレッドシートを突き合わせる必要があります。
ProjectVIEWのアプローチ
ProjectVIEWは、積算から施工まで、BoQ、プロジェクト予算、WBS、リソース、Cost Codesの関係を維持します。
そのため、プロジェクトの出来高、労務、機械、資材、協力会社を含む実際の現場取引を、プロジェクトのコストベースラインと比較できます。ProjectVIEWのコスト管理プロセスは、BoQ予算をPrimaveraおよび日々の現場取引と具体的に結び付けます。
メリット
経営陣は、コストが発生した後の財務報告を待つのではなく、コストと出来高の実績対予算を継続的に可視化できます。
教訓
建設のコスト管理は、コストが発生した後に財務部門で始めるものではありません。入札から始まり、施工を通じて続けなければなりません。
2. EPC請負者：調達はプロジェクト管理の一部です
汎用ERPでは、調達は通常、取引プロセスとして捉えられます。
購買申請 → RFQ → 発注書 → 受入 → 請求書
EPC請負者にとって、それは物語の一部にすぎません。
繰り返される問題
プロジェクトチームは、さらに多くのことを知る必要があります。
何を購入するのか？なぜ必要なのか？どのプロジェクトのどの作業が必要としているのか？予算化されていたのか？現場にいつ必要なのか？すでに在庫はあるのか？過去の価格はいくらか？納期遅れは施工に影響する可能性があるのか？
つまり、購買は財務的には正しくても、業務的には誤りである可能性があるのです。
ProjectVIEWのアプローチ
ProjectVIEWは調達をプロジェクト構造と結び付けます。
資材の所要量はBoQや現場の要件から発生し、購買申請、サプライヤーへのRFQ、見積比較、発注書を経て、最終的に入荷および在庫プロセスへとつながります。
調達ワークフローには、サプライヤーの見積比較、過去のコスト情報、倉庫管理、協力会社の調達、BoQおよびWBSの要件に基づく調達が含まれます。
メリット
購買は孤立した管理業務ではなく、プロジェクトのコスト管理と実行管理の一部となります。
教訓
最も安い購買が、必ずしもプロジェクトにとって最も低コストな判断であるとは限りません。
3. 造船・修繕船：船舶は会計上のプロジェクト以上のものです
造船と修繕船は、汎用ERPの限界を特にはっきりと浮き彫りにします。
船舶プロジェクトには、設計、製作、作業指示、調達、在庫、協力会社、専門労務、機器、顧客の承認、認証、商務上の変更が組み合わさることがあります。
繰り返される問題
造船所、生産チーム、営業部門、倉庫、協力会社、財務部門が、同じプロジェクトについてそれぞれ異なるビューで作業してしまうことは珍しくありません。
変更は問題をさらに難しくします。
新たに判明した修理やスコープの変更は、労務、資材、協力会社、工程、コスト、そして最終的には顧客への請求額に、即座に影響を及ぼす可能性があります。
ProjectVIEWのアプローチ
ProjectVIEWは造船所管理情報システムとして機能し、共通のプロジェクト環境を通じて、オフィス、造船所、生産現場、ベンダー、サービス会社、協力会社、顧客を結び付けます。
その造船所モデルは、業務プロセスをBoQ、WBS、Cost Codesと関連付け、変更管理とあわせてコストと出来高の実績対予算の監視を可能にします。
メリット
造船所は、生産と商業上の業績を切り離された環境で管理するのではなく、コスト、出来高、リソース、プロジェクト変更を造船所からオフィスまで可視化できます。
教訓
造船所向けERPは、製造業向けERPに「船舶」という項目を追加しただけのものであってはなりません。
プロジェクト、生産、修繕、リソース、商務の各側面を同時に理解していなければなりません。
4. 海洋・オフショア：遠隔地の業務には単一の業務情報が必要です
海洋・オフショアプロジェクトには、もう一つの課題が加わります。距離です。
業務は、本社、製作ヤード、建設現場、船舶、オフショア拠点に分散している場合があります。
繰り返される問題
業務情報が経営陣に届くのは、出来事の後になることがあります。
実際の労務、機器稼働、資材、協力会社の実績、出来高がERPに反映されるころには、業務上の判断はすでに下されているかもしれません。
ERPは、能動的なプロジェクト管理プラットフォームではなく、過去の記録システムになってしまいます。
ProjectVIEWのアプローチ
ProjectVIEWは、一元化された環境を通じて現場とオフィスのプロセスを結び付け、目的別のWebアプリとモバイルアプリがプロジェクトデータの収集とコラボレーションを支援します。
ProjectVIEW全体のアーキテクチャは、オンラインおよびオフラインでの運用、プロジェクト・ポートフォリオ管理、役割ベースのアクセス、業務プロセスとプロジェクトのコスト・工程との統合をサポートします。
メリット
経営陣は、地理的に分散したプロジェクト業務全体について、より迅速な状況把握が可能になります。
教訓
遠隔地のプロジェクト管理は、報告書を増やすことでは実現できません。作業が行われる場所の近くで、より良い業務データを収集することから始まります。
5. 鉱業・採石：機器稼働率こそがコスト管理です
鉱業と採石は、非常に資産集約的な事業です。
掘削機、ローダー、トラック、クラッシャー、削岩機、その他の機械は、単なる貸借対照表上の資産ではありません。その稼働可能性と稼働率は、業務実績とコストに直接影響します。
繰り返される問題
従来のERPは、会社がどの機械を保有し、その会計上の価値がいくらか、そして場合によっては保守履歴を経営陣に示すことはできます。
しかし現場の業務には、別の答えが必要です。
機械はどこにあるのか？使用可能か？どのプロジェクトが使っているのか？稼働率はどの程度か？運用コストはいくらか？どの保守が近づいているのか？
ProjectVIEWのアプローチ
ProjectVIEWの機械管理は、機械一覧、配置と取引、機器の稼働可能性、コスト分析、燃料、保守、予防修理、保険の監視をカバーします。
機械は、積算時にプロジェクトリソースとして割り当て、その後のプロジェクト実行中に測定することもできます。
メリット
機器は単なる固定資産ではなく、測定可能な業務リソースおよびプロジェクトコストのリソースとなります。
教訓
どの機械を保有しているかを知ることは資産管理です。それをどれだけ効果的に使っているかを知ることが業務管理です。
6. プロジェクト型製造：生産とプロジェクト管理は同じ言葉を話さなければなりません
プロジェクト型製造は、ERPにとってまた別の課題を生みます。
その企業は製造を行いますが、必ずしも反復的な大量生産ではありません。プロジェクト固有のエンジニアリング要件に基づいて、独自の構造物、部品、組立品を製作する場合があります。
繰り返される問題
製造用ソフトウェアは生産を管理できます。
プロジェクト用ソフトウェアはプロジェクトを管理できます。
しかし経営陣は、生産、資材、リソース、作業指示、工程、コストが、実行中のプロジェクトの収益性にどのように寄与しているかを理解する必要があります。
これらのプロセスが別々に運用されていると、その関係は見えにくくなります。
ProjectVIEWのアプローチ
ProjectVIEWは、生産・製作の計画と管理を、資材、調達、倉庫業務、労務、機械、プロジェクト予算、コスト管理と同じエコシステムに取り込みます。
このプラットフォームは、生産を無関係なバックオフィス業務として扱うのではなく、プロジェクト型の建設、生産、製作、および関連業務のために特に設計されています。
メリット
生産とプロジェクト実行が共通のプロジェクト中心のデータモデルで運用され、製作実績と商業上の業績との間の可視性が向上します。
教訓
個別受注設計生産（ETO）やプロジェクト型製造では、経営陣に製造の視点かプロジェクトの視点かのどちらかを選ばせるべきではありません。両方が必要です。
これらの業界に共通するもの
用語は業界によって異なります。
建設請負者はプロジェクトと現場について語ります。造船所は船舶とヤードについて語ります。鉱業会社は保有機器と生産に大きく注力します。鋼構造物ファブリケーターは作業指示と製作を管理します。
しかし、これらの違いの根底には同じ経営課題があります。
物理的な実行を、時間、リソース、コスト、商業的価値とどのように継続的に結び付けるのか？
これらの業界全体で、繰り返されるパターンは明らかです。
建設・インフラ
課題：入札、工程計画、現場業務、財務データが分断される。
ProjectVIEWのアプローチ：プロジェクトのライフサイクル全体でBoQ ↔ WBS ↔ Cost Codesを結び付ける。
メリット：コストと出来高の実績対予算を継続的に可視化。
EPC請負者
課題：調達がプロジェクトの需要、予算、工程から切り離される。
ProjectVIEWのアプローチ：プロジェクトの要件を、調達、サプライヤー、在庫、予算、納期要件と結び付ける。
メリット：調達がプロジェクトのコスト管理と実行管理の不可欠な一部となる。
造船・修繕船
課題：造船所の業務、生産、協力会社、資材、商務上の変更が断片化する。
ProjectVIEWのアプローチ：船舶プロジェクト、生産、作業指示、調達、協力会社、コスト管理を統合する。
メリット：造船所からオフィスまでのプロジェクトの可視化を継続的に実現。
海洋・オフショア
課題：遠隔地の業務情報が経営陣に届くのが遅すぎる。
ProjectVIEWのアプローチ：現場からオフィスへのデータ収集、ワークフロー、一元化されたプロジェクト情報により、分散した業務を結び付ける。
メリット：より迅速な状況把握と業務管理。
鉱業・採石
課題：資産記録だけでは、機器の実績や稼働率は分からない。
ProjectVIEWのアプローチ：機械の稼働率、配置、稼働可能性、保守、コストを結び付ける。
メリット：機器稼働率と運用コスト管理の向上。
プロジェクト型製造
課題：生産とプロジェクト管理が別々の環境で運用される。
ProjectVIEWのアプローチ：生産、製作、資材、リソース、工程、プロジェクトコストを結び付ける。
メリット：プロジェクトチームと生産チームが共通のプロジェクト中心のデータモデルで業務を行う。
汎用ERPは悪いERPではありません
この区別は重要です。
SAP、Oracle、Microsoft Dynamics、その他の主要な基幹系ERPプラットフォームは、強力なシステムです。
問題は、汎用ERPが不十分であることではありません。
問題は、大規模な設定、カスタマイズ、連携、補完アプリケーションなしに、汎用的な企業データモデルが高度に専門化されたプロジェクト型事業の業務DNAを理解することを期待することにあります。
ProjectVIEWはその反対側から出発します。
プロジェクトから出発するのです。
そのエコシステムは、積算・入札、予算・コスト管理、協力会社、調達・購買、資材・在庫、機械・保守、人事・給与、会計・財務、買掛金、売掛金、分析、ワークフロー、プロジェクト・現場アプリケーションをカバーします。
また、ProjectVIEWを選ぶことは、必ずしも既存の全社ERPを置き換えることを意味しません。
ProjectVIEWはAPIを通じたサードパーティシステムとの連携をサポートし、主要な基幹系プラットフォームと共存するよう設計されています。たとえばProjectVIEWとOracleの連携では、調達、発注書、受入、請求書、在庫取引、プロジェクト関連データを両環境間でやり取りできます。
組織によっては、ProjectVIEWを中核ERPとして運用できます。
また別の組織では、全社ERPを補完するプロジェクト業務、建設管理、コスト管理のレイヤーとなり得ます。
そこで、次のような単純な問いよりも有益な問いが生まれます。
「ProjectVIEWか、SAP/Oracleか？」
より良い問いはこうです。
「どのシステムがどの役割を担うべきか？」
25年以上を経て得た最も重要なERPの教訓
プロジェクト型組織は、リソースを物理的な出来高へ、そして物理的な出来高を商業的価値へと継続的に変換しています。
したがって、そのERPは次の関係全体を理解していなければなりません。
スコープ → 時間 → リソース → コスト → 出来高 → 収益
これがProjectVIEW ERPの根底にある原則です。
業務プロセスは、切り離された取引として扱われるのではありません。プロジェクトの商務上のスコープ、実行工程、コスト構造に照らして評価することができます。
これにより、次の項目を現実と継続的に照合する仕組みが生まれます。
何が見積もられたか。何が計画されたか。何が実行されているか。それにいくらかかっているか。
そしてこれこそが、事業を記録するERPと、事業を管理するためのERPとの最終的な違いです。
建設、EPC、インフラ、造船、海洋・オフショア、鉱業、採石、プロジェクト型製造の企業にとって、その違いは重要です。
なぜなら、プロジェクト型産業では、収益性はプロジェクトの終わりに決まるのではないからです。
収益性は、実行中に下される何千もの判断によって獲得され、あるいは失われるのです。
関連記事： 造船向けERPソフトウェア · 海洋・オフショア建設ERP
