一つのアセット、多くのステークホルダー：ProjectVIEW ERPがオーナー、コントラクター、コンサルタント、銀行、保険会社をつなぐ方法

大規模な物理的アセットが、単一の組織によって設計、資金調達、建設、組立、保険付保、引き渡しのすべてを行われることはほとんどありません。

 

データセンターには、オーナー／デベロッパー ProjectVIEW オーナー／デベロッパー、ゼネラルコントラクター ProjectVIEW ゼネラルコントラクター、エンジニアリング・コンサルタント ProjectVIEW コンサルタント、建築家、設計者、専門サブコントラクター、機器メーカー、サプライヤー、銀行、保険会社、コミッショニング専門家、そして最終的にはオペレーターが関与することがあります。

 

鉱山、オフショア施設、船舶、産業プラント、製作構造物も、同じ基本的な論理に従います。

 

物理的なアセットは一つ。しかし、その周囲には組織のエコシステム全体が存在します。

 

これが、Build World（建設・ものづくりの世界）におけるデジタル化の最も重要な課題の一つを生み出しています。

 

 

ここで、ProjectVIEW ERP は、従来の建設管理アプリケーションや汎用的な企業向けERPとは異なるものとして理解されるべきです。

 

ProjectVIEWは、アセットの物理的な創出を中心とした企業の業務基盤を構築し、プロジェクトのスコープ、工期、原価、リソース、調達、契約、生産、財務取引をつなぎながら、各ステークホルダーが自らの責任に関連する情報にアクセスできるようにします。

 

目的は、銀行、保険会社、建築家、独立エンジニアにコントラクターのERPを操作させることではありません。

 

目的はそれよりもはるかに重要です。

 

 

---

 

真のデジタル課題：誰もが同じアセットの異なるバージョンを見ている

 

大規模プロジェクトは、すでに拡張された企業体として運営されています。

 

FIDIC FIDIC建設契約 が発行する国際建設契約は、発注者／クライアント、コントラクター、エンジニアの間の関係を正式に定めています。FIDICはまた、フィージビリティ調査、詳細設計、施工監理、プロジェクトマネジメントなどの業務を対象としたクライアント／コンサルタント標準業務委託契約 FIDIC White Book も発行しています。

 

デジタル設計のエコシステムも同じ現実を認識しています。buildingSMART International と openBIM buildingSMART openBIM は、オーナー、設計者、エンジニア、コントラクター、オペレーター、その他のステークホルダー間の相互運用可能な情報交換に重点を置いています。そのアセットオーナー向けガイダンス アセットオーナー向けopenBIM は、アセットのライフサイクル全体にわたるプロジェクトのステークホルダー、パートナー、サプライヤー間のコミュニケーションを特に重視しています。

 

金融機関は、もう一つの情報レイヤーを生み出します。赤道原則（Equator Principles） 赤道原則のプロジェクトファイナンス・フレームワーク は、プロジェクトファイナンスおよび関連する金融商品に関わる金融機関によって、リスク管理のフレームワークとして使用されています。

 

エンジニアリング・リスクは、さらに別のレイヤーをもたらします。国際工事保険協会（International Association of Engineering Insurers）— IMIA IMIA は、工事保険業界を代表し、エンジニアリング・リスクに関する技術的知見とベストプラクティスを推進しています。

 

したがって、実際のプロジェクト・エコシステムは、次のようなものではなく、

 

オーナー → コントラクター

 

むしろ次のようなものです。

 

オーナー／デベロッパー ↔ 設計者 ↔ コンサルタント ↔ コントラクター ↔ サブコントラクター ↔ サプライヤー ↔ ファブリケーター ↔ 銀行 ↔ 保険会社 ↔ 認証機関 ↔ 規制当局 ↔ オペレーター

 

しかし、これらの当事者は、異なるシステム、契約、データセット、報告サイクルで業務を行っていることが少なくありません。

 

その結果として生じるのは、多くの場合、データの不足ではありません。

 

つながった業務上の真実の不足です。

 

ProjectVIEWは何をつなぐのか？

 

ProjectVIEW ERP の中核では、プロジェクトの物理的なスコープと実行を、三つの基本的な次元を中心に構造化できます。

 

数量明細書（Bill of Quantities）— BoQ

 

何を建設、設置、製作、掘削、または納入する必要があるのか？

 

作業分解構成（Work Breakdown Structure）— WBS

 

作業はいつ、どのような実行順序で行うべきか？

 

コストコード

 

その作業を実行するために、どのようなリソースと支出が消費されるのか？

 

ProjectVIEWは、これらの構造を予算見積、原価管理、調達、サブコントラクター管理、資材・生産、機械設備、人事・労働生産性、買掛金、売掛金、財務管理などの企業プロセスと結び付けます。DANAOSは、このBoQ–WBS–コストコードの関係を、自社の業務モデルの基盤となるプロジェクト・カーネルと位置付けています。

 

つまり、物理的なアセットの変更を、その業務上の影響まで追跡できるということです。

 

設計変更は、次のような流れになり得ます。

 

図面変更 → 数量変更 → BoQ変更 → WBSへの影響 → 調達要件 → サブコントラクターへの影響 → リソース要件 → 原価への影響 → 顧客への変更（バリエーション） → キャッシュフローへの影響

 

これは、単に最新の図面改訂版を配布するよりもはるかに強力です。

 

社内のペルソナと社外のステークホルダーは同じではない

 

この区別は非常に重要です。

 

企業内では、ProjectVIEWは次のような業務ペルソナをサポートします。

 

コストコントローラー ProjectVIEW コストコントローラー、プロジェクトマネージャー ProjectVIEW プロジェクトマネージャー、積算担当者、クオンティティサーベイヤー、工程計画担当者、契約マネージャー、調達担当者、サブコントラクター管理者、建設マネージャー、資材管理者、倉庫管理者、生産・製作マネージャー、機械設備マネージャー、人事・労働生産性チーム、財務担当者、文書管理者、品質マネージャー、HSEマネージャー、ITチーム、デジタルトランスフォーメーション・マネージャー、そして経営層です。

 

これらはエンタープライズ・ユーザーです。

 

しかし、その周囲には社外のステークホルダーが存在します。

 

オーナー、デベロッパー、エンジニアリング・コンサルタント、建築家、設計者、銀行、保険会社、サプライヤー、サブコントラクター、検査機関、船級協会、規制当局、オペレーター。

 

これらのステークホルダーは、ERP全体へのアクセスを必要としない場合があります。

 

代わりに必要なのは、自らの責任に関連する情報とワークフローへの管理されたアクセスです。

 

これは重要なアーキテクチャ上の違いです。

 

---

 

1. 建設・インフラ

 

病院、空港、鉄道、橋梁、住宅開発、産業施設、データセンターを考えてみましょう。

 

主なステークホルダーには次のものが含まれます。

 

• オーナー／デベロッパー ProjectVIEW オーナー／デベロッパー
• ゼネラルコントラクター／EPCコントラクター ProjectVIEW ゼネラルコントラクター
• エンジニアリング・コンサルタント／独立エンジニア／PMC ProjectVIEW コンサルタント
• 建築家／設計者／BIMチーム — buildingSMART International buildingSMART openBIM が推進するオープンなデジタル建設エコシステムの中で位置付けられています
• 銀行／プロジェクトファイナンス機関 — 赤道原則 赤道原則 などのプロジェクトファイナンスのリスクフレームワークを用いています
• 工事保険会社／再保険会社 — IMIA 国際工事保険協会 が代表しています
• サブコントラクター
• サプライヤー
• ファブリケーター
• 規制当局
• コミッショニング専門家
• 将来のオペレーター

 

このステークホルダー構造は、FIDICやbuildingSMARTが推進する、より広範な契約モデルおよびオープンデータモデルと整合しています。

 

例：データセンターにおける設計変更

 

機械設備コンサルタントが冷却設計を改訂したとします。

 

文書管理システムは、改訂された図面を配布することができます。

 

しかし、実際のビジネス上の影響には、次のようなものが含まれる可能性があります。

 

• 追加の機器
• 数量の改訂
• 調達パッケージの変更
• 専門サブコントラクター契約の変更
• 追加の労務
• 据付順序の改訂
• 追加の試験
• コミッショニング日程の変更
• 完成までのコスト（cost-to-complete）の改訂
• 契約上の変更（バリエーション）
• キャッシュフロー要件の変化

 

設計者にとっては、技術的な変更として始まりました。

 

コントラクターにとっては、実行と原価に関わる事象となりました。

 

オーナーにとっては、資本コストと引き渡しの問題となりました。

 

コンサルタントにとっては、監理と認証の問題となりました。

 

銀行にとっては、プロジェクトのモニタリングや融資実行のエビデンスに影響する可能性があります。

 

保険会社にとっては、プロジェクトのエンジニアリング・リスク・プロファイルが変わる可能性があります。

 

ProjectVIEWは、各部門が同じ事象をそれぞれ孤立して解釈するのではなく、これらの影響を共通の業務フレームワークに結び付けることができます。

 

ProjectVIEWのコンサルタント向けERPモデル 建設コンサルタント向けProjectVIEW は、すでに現場のリアルタイムな可視性、施工文書、設計承認、QC/QA情報、変更管理を、コンサルタントによる監理の重要な要素として位置付けています。

 

---

 

2. 海洋・オフショア建設

 

海洋・オフショアプロジェクトは、さらに分散しています。

 

物理的なアセットは、オフショアプラットフォーム、海底システム、防波堤、港湾、桟橋、パイプライン、海上ターミナル、沿岸インフラプロジェクトなどです。

 

国際海洋コントラクター協会（International Marine Contractors Association）— IMCA IMCAの会員エコシステム は、このエコシステムがいかに広範であるかを示しています。その会員区分には、海洋コントラクター、船主・船舶運航者、オフショアエネルギー企業・デベロッパー、サプライヤー、メーカー、コンサルタント、人材供給会社、研修機関が含まれます。

 

ProjectVIEWのステークホルダー・モデルには次のものが含まれます。

 

• E&Pオーナー／エネルギー企業 ProjectVIEW E&Pオーナー
• 海洋／オフショア・コントラクター ProjectVIEW 海洋コントラクター

 

さらに、次のステークホルダーも関与します。

 

• EPCコントラクター
• エンジニアリング・コンサルタント
• 船主／船舶運航者
• 海底工事コントラクター
• 製作ヤード
• 浚渫コントラクター
• 機器サプライヤー
• 港湾当局
• 銀行
• 工事保険会社・海上保険会社
• サーベイヤー（検査人）
• 政府当局

 

例：オフショア据付の変更

 

オフショア据付キャンペーンの最中に、海底の状況によってエンジニアリング上の変更を余儀なくされたと想像してください。

 

その影響は次のようになる可能性があります。

 

エンジニアリング変更 → 作業パッケージの改訂 → 追加の船舶稼働日数 → 専門クルー → 機器の動員 → 調達 → 工程への影響 → 追加コスト → 顧客への変更（バリエーション）

 

エンジニアリング・コンサルタントには、技術的なトレーサビリティが必要です。

 

コントラクターには、リソースと原価の管理が必要です。

 

E&Pオーナーには、影響と承認に関する可視性が必要です。

 

船舶運航者には、更新された要件が必要です。

 

営業マネージャーには、契約上の影響の把握が必要です。

 

経営陣は、プロジェクトが引き続き収益性を維持しているかを知る必要があります。

 

 

この区別が重要です。

 

---

 

3. 鉱業・採石

 

鉱山は、単なる建設プロジェクトではありません。

 

鉱山には、同時に次のものが含まれることがあります。

 

• 土工事
• 道路
• 処理プラント
• 破砕機
• コンベヤー
• 作業場
• 水インフラ
• 電力インフラ
• 重機の車両群
• 保守作業
• コントラクター
• 長期的な生産資産

 

Global Mining Guidelines Group — GMG Global Mining Guidelines Group は、鉱山オペレーター、OEM、テクノロジープロバイダー、サプライヤー、コンサルタント、研究機関、その他のステークホルダーが参加する鉱業コミュニティについて説明しており、そのガバナンスは業界全体のマルチステークホルダー協働を明確に支援しています。

 

ProjectVIEWにとって、中核となるステークホルダー区分には次のものが含まれます。

 

• 鉱山／採石場オーナー ProjectVIEW 鉱山・採石場オーナー
• 鉱業コントラクター ProjectVIEW 鉱業コントラクター

 

その周囲には次のステークホルダーが存在します。

 

• EPCMコンサルタント
• 鉱山技術者
• 地質学者
• 掘削・発破コントラクター
• 重機OEM
• 処理プラント・コントラクター
• インフラ・コントラクター
• サプライヤー
• 銀行・投資家
• 工事保険会社
• 環境コンサルタント
• 規制当局
• ESG・保証（アシュアランス）チーム

 

例：処理プラントの拡張

 

主要な破砕機の納入が遅れたとします。

 

これは単なる調達の問題ではありません。

 

影響は次のように波及する可能性があります。

 

サプライヤーの遅延 → 据付順序 → WBS → 機械設備 → 労務 → サブコントラクター → コミッショニング → 生産準備 → キャッシュフロー → プロジェクト予測

従来の購買システムは、遅延している発注書を特定できるかもしれません。

 

工程管理システムは、遅延している作業を表示できるかもしれません。

 

建設プラットフォームは、現場の問題を明らかにできるかもしれません。

 

 

ProjectVIEW 鉱山・採石場オーナー・モデル 鉱山オーナー向けプロジェクト管理ERP は、プロジェクト管理とオーナーの可視性に特化しており、鉱業コントラクター・モデル 鉱業コントラクター向けERP はコントラクターによる実行に対応しています。

 

---

 

4. 造船・船舶修繕

 

造船は、ステークホルダーの複雑さを示す最も顕著な例の一つと言えるでしょう。

 

建造中の船舶は、次の関係者が関与するエコシステムの中心に位置しています。

 

• 船主／発注者 ProjectVIEW 船主
• 造船会社／造船所 ProjectVIEW 造船・船舶修繕会社
• 造船技師・海洋技術者 — 国際的には SNAME Society of Naval Architects and Marine Engineers が代表しています
• 船級協会 — IACS International Association of Classification Societies を通じて代表されています
• 海上保険会社・再保険会社 — IUMI International Union of Marine Insurance が代表しています
• 船舶金融銀行
• 機器メーカー
• 専門サブコントラクター
• 旗国当局
• 技術管理会社
• 将来のオペレーター
• 傭船者（該当する場合）

 

これは契約面にも反映されています。BIMCO NEWBUILDCON BIMCO NEWBUILDCON は、船主と造船会社の利益のバランスを取るよう設計された国際標準の造船契約です。

 

IACSはまた、船級協会が船舶の設計、建造、就航後の検査を対象とする技術要件を策定し、その遵守を検証していることを説明しており、船級を船舶の建造、保険、金融、運航上の地位に直接結び付けています。

 

例：船級に起因する設計変更

 

船級協会が機関配置の変更を要求したとします。

 

これにより、次のような流れが生じる可能性があります。

 

設計改訂 → 資材変更 → 調達 → 製作 → 艤装 → 再検査 → WBS変更 → 労務への影響 → 原価への影響 → 船主承認 → 契約変更

 

造船技師にとっては、これはエンジニアリングの問題です。

 

船級協会にとっては、コンプライアンスの問題です。

 

造船所にとっては、生産の問題です。

 

船主にとっては、コストと引き渡しの問題です。

 

融資者にとっては、マイルストーンのモニタリングに影響する可能性があります。

 

保険会社にとっては、リスク情報に影響する可能性があります。

 

 

これは、独立した文書リポジトリというよりも、物理的な船舶を中心とした業務環境にはるかに近いものです。

 

---

 

5. プロジェクト型製造・製作

 

建設は現場から始まるわけではありません。

 

大規模なアセットは、ますますプロジェクト固有の製作に依存するようになっています。

 

• 構造用鋼材
• モジュール建築
• MEPアセンブリ
• プロセススキッド
• 配管スプール
• プレキャスト部材
• オフショアモジュール
• 海洋製作物
• 個別受注設計（Engineer-to-Order）機器

 

ProjectVIEW プロジェクト型製造ERP プロジェクト型製造ERP は、製作・製造活動を、それらが生産される対象プロジェクトに結び付けるよう設計されています。

 

ステークホルダーのエコシステムには、次のものが含まれる可能性があります。

 

• オーナー
• EPCコントラクター
• ゼネラルコントラクター
• ファブリケーター／メーカー
• 構造エンジニア
• ディテーラー（詳細図作成者）
• 資材サプライヤー
• QA/QCチーム
• 独立検査員
• 物流プロバイダー
• 銀行／貿易金融プロバイダー
• 保険会社

 

例：構造用鋼材の改訂

 

エンジニアが構造部材を変更した場合、その影響は次のように波及する可能性があります。

 

設計 → 数量 → BOM → 資材要件 → 購買 → 切断 → 製作 → 溶接 → 検査 → 物流 → 現場建方 → 原価

 

重要な問題は、各システムがプロセスの自らの担当部分を管理できるかどうかではありません。

 

ほとんどのシステムはそれが可能です。

 

重要な問題は次の点です。

 

企業は、変更による業務上・商業上の影響を、物理的なアセットから原価と財務の現実まで一貫して追跡できるでしょうか？

 

ここで、エンタープライズ統合が決定的に重要になります。

 

しかし、他の建設プラットフォームもすでにステークホルダーをつないでいるのでは？

 

はい。

 

そして、この点を正確に述べることが重要です。

 

差別化のポイントは、他のシステムでは協働できないということではありません。

 

それらのシステムも協働は可能です。

 

より有益な区別は、それぞれの重心がどこにあるかです。

 

Autodesk Construction Cloud / Autodesk Docs

 

Autodesk Docs Autodesk Docs は、文書とデータの管理に重点を置いたクラウドベースの共通データ環境です。Autodeskは、そのユーザーとして建築家、設計者、エンジニア、コントラクター、サブコントラクター、BIM/VDCマネージャー、プロジェクトマネージャー、オーナー、ファブリケーターを挙げています。

 

Autodeskはまた、コントラクター、オーナー、サプライヤー、建築家、コンサルタントの間での、管理された原価管理の協働もサポートしています。

 

したがって、その重心は次の領域と強く結び付いています。

 

設計 + モデル + 文書 + 現場情報 + 建設における協働

 

それには価値があります。

 

しかし、それは給与計算、調達、買掛金、売掛金、機械設備、企業在庫、企業会計にわたる企業の取引基盤全体を運用することと同じではありません。

 

Procore

 

Procore Financial Management Procore Construction Financial Management は、現場情報をプロジェクト予算、予測、請求、建設の財務プロセスと結び付けます。

 

Procoreはまた、会計システムやERPシステムとの統合を明確に推進しており、そのエコシステムには500を超える統合が含まれているとしています。

 

このアーキテクチャは、その違いを明確に示しています。

 

建設／プロジェクト・プラットフォーム ↔ ERP／会計システム

 

Procoreは、オーナー側の原価管理とポートフォリオの可視性も拡充しています。

 

したがって、ステークホルダー間の協働を幅広く促進していますが、そのアーキテクチャは一般的に、別個の企業会計またはERPのレイヤーと併存しています。

 

Oracle Aconex

 

Oracle Aconex は、組織横断的なプロジェクト情報と協働のレイヤーで主に機能しています。

 

Oracle自身のSmart Construction Platformのドキュメントには、Aconex と Primavera Unifier の間の明示的な同期が示されています。Oracle Smart Construction Platformの統合

 

これは非常に重要です。なぜなら、大規模な統合型建設テクノロジー・エコシステムの中でさえ、プロジェクトの協働とプロジェクト管理が別々のアーキテクチャ・レイヤーとして存在し得ることを示しているからです。

 

Oracle Primavera Unifier

 

Oracle Primavera Unifier Oracle Smart Construction Platformの統合 は、資本プロジェクトの管理、業務プロセス、財務ワークフローに対応しています。

 

Oracleは、UnifierとOracle Fusion Cloud ERP Procurement and Financialsをつなぐ統合レシピを提供しています。

 

これもまた、重要なアーキテクチャの例です。

 

資本プロジェクト管理 ↔ エンタープライズERP

 

Autodesk Digital Project Delivery

 

Autodeskは、Digital Project Delivery Autodesk Digital Project Delivery を、オーナー、建築家、コントラクター、エンジニア、専門工事業者などのステークホルダーのために分野横断的なデータをつなぐ、クラウドベースの共有アプローチとして説明しています。

 

これも、問題の重要な一部に対応するものです。

 

情報の相互運用性とプロジェクトの協働です。

 

ProjectVIEWは、別の次元に対応します。

 

そのプロジェクトの現実を、アセットを創出するために資金、労働力、機器、資材、契約上のコミットメントを実際に消費している企業と、どのように同期させるのか？

 

---

 

戦略的な違い：協働か、業務オーケストレーションか

 

これがProjectVIEWの主要な論点です。

 

• 共通データ環境は、どの図面が最新かを全員に伝えることができます。
• BIMプラットフォームは、アセットをデジタルで表現することができます。
• 工程計画システムは、作業をいつ行うべきかを全員に伝えることができます。
• 建設管理プラットフォームは、RFI、課題、現場プロセスを調整することができます。
• 汎用ERPは、購買、給与、請求書、会計仕訳を記録することができます。

 

これらのシステムはすべて価値を生み出します。

 

しかし、物理的なアセットにとって、これらのプロセスは別々に起こるものではありません。

 

何かが物理的に変化すると、複数の次元が同時に変化します。

 

したがって、ProjectVIEWの提案は次のとおりです。

 

企業ファーストのアーキテクチャ。

 

ERPは、個々のプロジェクト内だけでなく、企業全体にわたって機能します。

 

プロジェクト中心のビジネスロジック。

 

企業の取引は、それを生み出したプロジェクト構造に継続的に関連付けられます。

 

アセットを中心とした業務上の現実。

 

BoQ、WBS、リソース、文書、原価、物理的な進捗が、実際に建設されているものを中心につながります。

 

ステークホルダーごとの可視性。

 

各ステークホルダーは、ERP全体を操作することなく、自らの責任に適した情報、承認、エビデンスを受け取ることができます。

 

 

各ステークホルダーは何を得られるのか？

 

オーナー／デベロッパー

 

プロジェクトの進捗、コミットメント、原価、変更、コントラクターのパフォーマンス、商業上のエクスポージャーに関する可視性。

 

コントラクター／EPC

 

原価、調達、サブコントラクター、資材、機械設備、労務、契約、生産、財務にわたる統合的な実行。

 

エンジニアリング・コンサルタント／PMC

 

進捗レビュー、設計調整、認証、文書化、変更管理のための、より構造化されたエビデンス。

 

設計者／建築家／造船技師

 

設計変更と、その後の実行への影響との、より強固なつながり。

 

銀行／融資者／テクニカルアドバイザー

 

プロジェクトの進捗、原価の推移、マイルストーン、モニタリングを裏付けるエビデンスへの管理されたアクセス。

 

ProjectVIEWは、銀行の融資プラットフォームやリスク管理プラットフォームを置き換えるものではありません。

 

工事保険会社または海上保険会社

 

変更、進捗、物理的な実行、文書化に関する構造化されたプロジェクトのエビデンス。

 

ProjectVIEWは、引受、エンジニアリング調査、保険金請求管理のシステムを置き換えるものではありません。

 

サブコントラクター

 

構造化された作業パッケージ、出来高測定、認証、変更（バリエーション）、支払ワークフロー。

 

サプライヤー

 

調達要件、納入状況、資材のトレーサビリティ、契約情報。

 

監査人

 

業務上の事象をその財務的な影響に結び付ける、より強固な取引・承認の証跡。

 

経営層

 

プロジェクトの物理的な実行が、企業の収益性とリスクにどのような影響を与えているかを示す統合的なビュー。

 

---

 

一つのアセット。多くのステークホルダー。統制された一つの業務上の現実。

 

建設テクノロジーの未来は、すべてのステークホルダーに専門アプリケーションを手放すことを求めるべきではありません。

 

• 建築家は、引き続きプロフェッショナルな設計システムで設計を行うべきです。
• エンジニアは、引き続きエンジニアリングを行うべきです。
• 工程計画担当者は、引き続き計画を立てるべきです。
• 銀行は、引き続き銀行プラットフォームを運用するべきです。
• 保険会社は、引き続き引受システムや保険金請求システムを使用するべきです。
• 船級協会は、引き続き自らの技術・認証環境を運用するべきです。

 

目指すべきは、業務の統制を失うことのない相互運用性です。

 

それこそが、ProjectVIEW ERPにとっての機会です。

 

誰もがERPの中で作業する必要があるわけではありません。

 

しかし、アセットに関わるすべての人は、受け取る情報が構造化され、管理され、継続的に更新される業務システムから発信されたものであるとき、恩恵を受けます。

 

• コントラクターにとって、ProjectVIEWは企業の業務基盤となり得ます。
• オーナーにとっては、透明性をもたらします。
• コンサルタントにとっては、エビデンスを。
• 設計者にとっては、変更と実行のつながりを。
• 銀行にとっては、より確かなプロジェクト・モニタリング情報を。
• 保険会社にとっては、より構造化された業務上のエビデンスを。

 

経営陣にとっては、さらに根本的なものを生み出します。

 

 

それがProjectVIEWのビジョンの基盤です。

 

 

• 一つの物理的なアセット。
• 多くの企業。
• 多くの専門分野。
• 多くの契約。
• 多くの専門アプリケーション。

 

統制された一つの業務上の現実。

 

---

 

よくある質問

 

建設ERPにおけるステークホルダー協働とは何ですか？

 

建設ERPにおけるステークホルダー協働とは、基盤となる業務データおよび財務データをエンタープライズ・システムで管理したまま、オーナー、コントラクター、コンサルタント、設計者、サブコントラクター、サプライヤー、その他の権限を持つ当事者が、関連するプロジェクト情報にアクセスし、やり取りできるようにすることです。

 

ProjectVIEWは、ステークホルダーの情報をBoQ、WBS、原価、調達、リソース、契約、実際の企業取引に結び付けることで、この概念を拡張しています。

 

ProjectVIEW ERPは、コントラクターとプロジェクトオーナーの両方が使用できますか？

 

はい。

 

ProjectVIEWには、ゼネラルコントラクター ProjectVIEW ゼネラルコントラクター と オーナー／デベロッパー ProjectVIEW オーナー／デベロッパー 向けの専用モデルがあります。

 

コントラクターはProjectVIEWを業務用ERPとして使用し、オーナーは適切なプロジェクト管理情報、進捗、商業面の可視性を受け取ることができます。

 

エンジニアリング・コンサルタントはProjectVIEW ERPを使用できますか？

はい。

 

ProjectVIEW コンサルタント・ソリューション 建設コンサルタント向けProjectVIEW は、独立した監理、施工の進捗、文書化、変更管理、ステークホルダー協働を中心に設計されています。

 

銀行や融資者はProjectVIEWの情報を利用できますか？

 

はい。プロジェクトのオーナーまたはコントラクターが、該当するアクセスまたはレポーティングを承認した場合に利用できます。

 

銀行とそのテクニカルアドバイザーは、融資対象プロジェクトをモニタリングする際に、進捗、原価、契約、変更、プロジェクトのマイルストーンに関するエビデンスを必要とすることがあります。

 

ProjectVIEWは、その基礎となるエビデンスの作成と構造化を支援できます。

 

銀行の与信、融資、金融リスクのシステムを置き換えるものではありません。

 

---

 

保険会社はProjectVIEW ERPからどのような恩恵を受けられますか？

 

工事保険会社や海上保険会社は、アセット、エンジニアリング変更、施工の進捗、リスクに関する信頼できる情報に依存しています。

 

ProjectVIEWは、プロジェクトの実行、文書、変更、承認に関する、より構造化されたエビデンスの証跡を作成できます。

 

引受、エンジニアリング検査、保険金請求管理のプラットフォームを置き換えるものではありません。

 

業界の参考団体としては、IMIA 国際工事保険協会 や IUMI International Union of Marine Insurance があります。

 

ProjectVIEWはBIMソフトウェアを置き換えるものですか？

 

いいえ。

 

BIMおよびエンジニアリング設計アプリケーションは、専門的な設計とモデリングの機能を担います。

 

ProjectVIEWの役割は、設計関連の情報と変更を、数量、WBSアクティビティ、調達、生産、リソース、原価などの企業プロセスと結び付けることです。

 

openBIM buildingSMART openBIM のようなオープンな相互運用性のアプローチは、このアーキテクチャにとって引き続き非常に重要です。

 

ProjectVIEWは共通データ環境を置き換えるものですか？

 

ProjectVIEWには、文書の管理された配布やバージョン管理を含む、文書管理および共通データ環境の機能が含まれています。

 

ただし、組織はテクノロジー・アーキテクチャに応じて、ProjectVIEWを専門のCDE、BIM、エンジニアリング・アプリケーションと統合することもできます。

 

ProjectVIEWはProcoreとどう違うのですか？

 

Procore Procore Financial Management は、建設管理、プロジェクトの実行、建設の財務ワークフローを中心に強く位置付けられており、会計システムやERPシステムとの統合をサポートしています。

 

ProjectVIEWはエンタープライズERPそのものとして位置付けられており、プロジェクトの実行を、全社的な調達、リソース、サブコントラクター、資材、機械設備、給与、財務取引と結び付けます。

 

ProjectVIEWはAutodesk Construction Cloudとどう違うのですか？

 

Autodesk Docs / Autodesk Construction Cloud Autodesk Docs は、設計から施工までの情報、文書、モデル、協働、現場／プロジェクトのワークフローに強く焦点を当てています。

 

ProjectVIEWは、その物理的／プロジェクトの現実を、企業の取引および原価管理の基盤と結び付けることに焦点を当てています。

 

したがって、この二つのテクノロジー区分は、相互に排他的なものではなく、補完的なものとなり得ます。

 

ProjectVIEWはOracle AconexやPrimavera Unifierとどう違うのですか？

 

Aconex は主に組織横断的なプロジェクト情報と協働に焦点を当てており、Primavera Unifier は資本プロジェクトおよびプロジェクト管理のプロセスを提供します。

 

Oracle自身が、Aconex、Unifier、Oracle Fusion ERPの間の統合を提供しています。Oracle Smart Construction Platformの統合

 

ProjectVIEWの提案は、プロジェクト中心のビジネスロジックと企業の取引を、Build Worldのための単一の専門ERP環境に統合することです。

 

ProjectVIEWのステークホルダー・モデルはどの業界で活用できますか？

 

ProjectVIEWは、次の分野にわたってそのビジネスロジックを適用しています。

 

建設・インフラ

 

海洋・オフショア建設 ProjectVIEW 海洋コントラクター

 

鉱業・採石 ProjectVIEW 鉱山オーナー

 

造船・船舶修繕 ProjectVIEW 造船ERP

 

プロジェクト型製造 ProjectVIEW プロジェクト型製造ERP

 

物理的なアセットは、建物から鉱山、オフショア施設、船舶、製作構造物へと変わります。

 

しかし、その根底にあるマネジメント上の課題は、驚くほど似通っています。

 

スコープ + 工期 + 原価 + リソース + 契約 + ステークホルダー + 実際の実行。

 

ProjectVIEW ERPの主な目的は何ですか？

 

ProjectVIEW ERPは、複雑なプロジェクトの物理的、業務的、商業的、財務的な現実を継続的につなぐことができる、構造化されたエンタープライズ環境を構築するよう設計されています。

 

簡単に言えば、次のとおりです。

 

私たちは何を建設しているのか？いつ建設すべきか？いくらかかるべきか？実際に何が起きているのか？実際にいくらかかったのか？誰がそれを知る必要があるのか？

 

これらの問いをつなぐことこそが、効果的なプロジェクト管理、そして意義あるステークホルダー協働の基盤です。