EPC、PPP、BOT、一括請負、数量精算方式の大型プロジェクトを手がける国内・多国籍コントラクターのための、エンドツーエンドの評価フレームワークです。
概要
建設ERPは、多数のモジュールを一つの画面にまとめているだけでエンドツーエンドになるわけではありません。
エンドツーエンドと言えるのは、承認された一つのプロジェクト事象が、再入力・再解釈・手作業による照合なしに、入札から貸借対照表まで、モデルから現場まで、そして現場から経営会議までつながる場合だけです。
グローバルなコントラクターにとって、評価の対象は会計やプロジェクト管理だけではありません。コスト、工期、品質、リソース、商務管理、現場施工、財務、給与計算、多国間の事業運営まで含める必要があります。
なぜグローバルなコントラクターには異なるERP評価が必要なのでしょうか？
国内外の大手コントラクターは、政府、公的機関、大規模発注者向けに、インフラ、ユーティリティ、エネルギー、建築、産業施設、環境工事、MEP（設備）プロジェクトを受注・遂行しています。
こうした企業は子会社、支店、ジョイントベンチャー、特別目的会社（SPV）を通じて事業を行うことがあります。そのポートフォリオには、複数の国、通貨、言語にまたがるEPC、PPP、BOT、一括請負、単価契約が含まれることがあります。
したがって、会計ソフトウェア、文書管理、あるいは現場アプリケーションの寄せ集め以上のものが必要です。必要なのは建設ERPソフトウェアです。
公共部門や国際融資によるプロジェクトでは、追跡可能な調達、管理された承認、測定可能なパフォーマンス、信頼できる記録も求められます。世界銀行の現行の調達枠組みは、費用対効果、誠実性、目的適合性のあるプロセス、効率性、透明性、公正性を重視しています。これらの規則は世界銀行が融資するプロジェクトに特有のものですが、複雑なB2G環境で期待されるガバナンス水準をよく示しています。
PPPおよびBOTプロジェクトでは、長期にわたる契約、資金調達、ステークホルダー、環境、引渡し、サービス性能に関する義務が加わります。
建設ERPを真にエンドツーエンドにするものは何でしょうか？
3つの連続性を実証する必要があります。
1. プロセスの連続性
あるプロセスで検証された出力が、次のプロセスの管理された入力にならなければなりません。
積算 → 承認済み予算 → 工程 → 調達 → 倉庫または製作 → 現場施工 → 実績コスト → 予測 → 会計
Excelに出力して手作業で再入力すれば、この連鎖は途切れます。
2. プロジェクト軸の連続性
すべての業務取引は、次の要素との関係を保持する必要があります。
- 商業的スコープと数量
- 工程上の作業
- 全社のコスト分類
- リソース
- 品質および検収の記録
- 契約上の権利
- プロジェクトと法人
- 会計上・財務上の処理
3. グローバル運営の連続性
プラットフォームは、次の要件をサポートする必要があります。
- 会社、支店、ジョイントベンチャー
- 言語と現地の文字
- 通貨と為替レートのルール
- 計量単位と換算
- 給与計算の要件
- 会計および税務のルール
- 承認権限
- 稼働カレンダーとタイムゾーン
「多言語対応」は、各国の法定要件へのローカライズと同じではありません。
どのプロジェクト軸を結び付けておく必要があるのでしょうか？
本格的な建設ERPは、同じプロジェクトについて相互に関連する4つの見方を維持すべきです。
BoQ：何を、どのようなリソースベースのコストで引き渡すのか？
数量明細書（BoQ）、またはそれに相当する出来高明細表、入札項目、作業パッケージ構造は、商業的かつ測定可能なスコープを表します。
そこには数量、資材、労務、機械、協力会社、間接リソース、生産性の前提、リスク、一般管理費、利益が含まれるべきです。
予算積算・入札モジュール [DANAOS LINK → https://danaos-projects.com/projectview-erp/budget-estimation-bidding/]
は、したがってCost Recipes、Productivity Templates、過去単価、サプライヤーへの引合い、入札バージョン、承認済みプロジェクトベースラインへの移行について評価すべきです。
GAOのコスト積算ガイドは、信頼できる積算を、技術的スコープ、WBS、前提条件、有効なデータ、リスク分析、文書化、実績コストに基づく更新と結び付けています。
WBS：作業をどのように、いつ実施するのか？
作業分解構成（WBS）と工程表は、作業、依存関係、所要期間、制約、リソース、マイルストーン、フロート、クリティカルパスを定義します。
GAOの工程評価ガイドは、信頼できる工程表が、パフォーマンス測定、変更分析、遅延によるコストへの影響評価を支えると説明しています。
コストコード：コストはどこで、なぜ消費されているのか？
コストコードまたは管理勘定は、コントラクター社内のコスト管理構造を提供します。
経営陣はコストコードを使って、プロジェクト、子会社、ジョイントベンチャー間で同等のリソースや作業を比較し、それらをプロジェクトおよび全社の財務報告に対応付けられる必要があります。
ProjectVIEW コスト管理モジュール は、BoQ、WBS、コストコードの関連付けに加え、現場取引、クレーム、変更、アーンドバリュー、P6／MS Projectとの連携を公開資料で説明しています。
QHSE：報告された作業を承認済みの進捗として計上すべきか？
承認された検査、試験結果、材料証明書、または検収記録がない作業について、施工済み数量を自動的に出来高として計上すべきではありません。
品質・安全衛生・環境（QHSE）の記録は、検査、不適合、是正処置、事故、許可を、該当するBoQ項目、WBS作業、場所、協力会社、モデル要素と関連付けることで、プロジェクトの実態を検証すべきです。
BoQは「何を、どれだけ」を説明します。WBSは「どのように、いつ」を説明します。コストコードは「どこでコストが消費されるか」を説明します。QHSEは「その作業を承認すべきか」を検証します。
ERPはどの業務プロセスをカバーすべきでしょうか？
グローバルなコントラクターは、次の相互に連携したプロセスの実証を求めるべきです。
1. 積算、予算編成、入札
BoQの取り込み、リソースベースの積算、Cost Recipes、Productivity Templates、最新価格、過去コスト、リスク、一般管理費、利益、バージョン、シナリオ、入札からベースラインへの連続性。
2. 計画、工程管理、BIM
概略計画、マスター工程、WBS、クリティカルパス、リソース所要量、進捗、Oracle Primavera P6またはMicrosoft Projectとの管理された双方向連携。
BIMの評価では、ERPがIFCモデルを表示できるかどうかだけでなく、オブジェクト識別子、数量、BoQとの関係、WBS作業、進捗、検査状況、改訂管理を検証すべきです。
3. 調達、倉庫、資材
システムは次の流れを結び付けるべきです。
予算または工程上の需要 → 現場資材請求 → 在庫確認 → 購買依頼 → 見積依頼（RFQ） → 評価 → 発注書 → 納品 → 検査 → 受入 → 消費 → 請求書
4. 生産とプロジェクト製作
EPC、MEP、産業系のコントラクターにとって、ERPは生産用BoQ、作業指示、製作工程、労務、機械、資材、協力会社、品質記録、実際の生産コスト、据付場所への納入を管理すべきです。
5. 現場業務
現場環境では次の情報を取得すべきです。
- 物理的な進捗
- 労務生産性
- 機械の稼働率と遊休時間
- 現場資材請求
- 資材の消費
- 協力会社の作業
- 作業日報
- 検査とQHSE記録
- 変更と指示
- 写真と裏付け資料
これらのデータは、コスト管理、予測、給与計算、下請出来高査定、会計へと流れる必要があります。
6. 協力会社と変更管理
ERPは、発注先選定、契約スコープ、単価、進捗、保留金、控除、元請支給材、出来高査定、請求書、変更、最終的な支払見込額を結び付けるべきです。
7. 機械、建設機械、工具
評価では、稼働可能性、リソース平準化、予約、配置、稼働時間と遊休時間、時間当たりコスト、燃料、オペレーター、予防保全、事後保全、予備部品、保険、検査を対象とすべきです。
8. 会計、財務、アーンドバリュー
プラットフォームは、プロジェクト業務を総勘定元帳、買掛金、売掛金、資金管理、キャッシュフロー、資産、発注残、未払計上、ジョイントベンチャー、連結、現地の法定報告と結び付けるべきです。
アーンドバリューは、「予算対請求書」レポートの名前を変えたものではありません。承認済みのスコープ、工程、予算、物理的進捗、実績コストの間の管理された関係です。
9. HRMSと現地の給与計算
ERPは、採用、従業員記録、スキル、プロジェクトへの配属、動員、勤怠、給与計算、人件費、キャンプ、休暇、時間外労働、退職時の処理、国ごとの労働要件を管理すべきです。
10. 全社管理
プラットフォームは、複数会社・複数プロジェクトの構造、ダッシュボード、ワークフロー、承認限度額、ユーザー、ロール、グループ、設定可能なメニュー、文書のバージョン管理、多通貨運用、複数の計量単位を提供すべきです。
11. APIとグループレベルの統合
大手建設グループでは、持株会社レベルでSAPやOracleを維持しながら、子会社、プロジェクト、現場では建設業に特化した業務プラットフォームを使用する場合があります。
評価では、各レコードをどのシステムが所有するか、コストコードをどう対応付けるか、データがどの方向に流れるか、連携が失敗した場合に何が起きるか、照合の責任者は誰かを定義する必要があります。
競合するシステムはどのように分類すべきでしょうか？
ベンダー名の順位付けから始めないでください。まず、評価対象がどのカテゴリーのシステムなのかを特定してください。
建設業特化型ERPまたはエンタープライズプラットフォーム
これらのベンダーは、自社のプラットフォームを建設ERP、または統合された建設エンタープライズ環境として公に位置付けています。
グローバルERPと大型プロジェクト向けエコシステム
これらは企業全体にわたる幅広い機能を提供できますが、その範囲は複数のモジュール、製品、連携、パートナーソリューションにまたがる場合があります。
プロジェクト管理・現場・業務プラットフォーム
これらのプラットフォームは建設の重要なプロセスをカバーしていますが、より広範なERP、会計、人事、給与計算環境との連携を前提とすることを公に説明しています。
積算・数量拾い出しの専門プラットフォーム
これらは積算と数量拾い出しの専門システムです。コントラクターの業務ERPとの、入札からベースラインへの統合を実証する必要があります。
この分類は品質の順位付けではありません。専門システムはその目的において非常に優れている場合があります。問題は、アーキテクチャ全体が一つの管理されたプロジェクトの実態を保てるかどうかです。
最終候補のすべてのベンダーは何を実証すべきでしょうか？
すべてのベンダーに同じシナリオを求めてください。
- 発注者のBoQを取り込み、Cost Recipesを適用し、リソースに価格を設定し、落札した積算を承認済みベースラインに変換する。
- 一つのスコープ項目を複数のWBS作業とコストコードに対応付ける。
- 工程とBIMの情報を双方向でやり取りし、やり取りが失敗した場合に何が起きるかを示す。
- 現場資材請求を、在庫、RFQ、発注、納品、検査、消費、請求書まで処理する。
- 製作を記録し、最終的な据付と結び付ける。
- 現場から物理的進捗、労務、機械、資材、QHSEの証跡を取得する。
- 協力会社の出来高を査定し、保留金を処理し、遊休時間を記録し、変更を申請する。
- 現地言語・現地通貨のプロジェクトをグループ報告に連結する。
事前録画のプレゼンテーションでは不十分です。ベンダーは代表的な顧客データを使い、完全な監査証跡を示すべきです。
ProjectVIEW ERPはこのフレームワークにどう適合するのでしょうか？
ProjectVIEW ERPは、建設業に特化した業務プラットフォームとして設計されています。現在の公開資料では、積算、予算編成、調達、資材、生産、協力会社、機械、HRMS、給与計算、会計、コスト管理の各モジュールが統合されていると説明しています。
その中核となるプロジェクト管理ロジックはBoQ、WBS、コストコードを結び付けるもので、公開されているコスト管理の資料では、Oracle Primavera P6およびMicrosoft Projectとの双方向連携について説明しています。
こうした位置付けがあっても、ProjectVIEWが実証を免除されるわけではありません。
導入を検討する企業は、次の点を確認すべきです。
- 有効化される具体的なモジュール
- 標準機能とカスタマイズの区別
- 必要なすべての言語
- 必要なすべての財務・給与計算のローカライズ
- 各方向でやり取りされるBIMオブジェクトと属性
- 想定されるプロジェクト数・取引量でのパフォーマンス
- セキュリティとサービスレベル
- データ移行
- 現行のAI機能とロードマップ上のAI機能の区別
同じ評価基準をすべてのシステムに適用すべきです。このフレームワークを公表している組織が推奨するシステムも例外ではありません。
建設ERPの最終テスト
決定的な問いは、次のようなものではありません。
「このプラットフォームには調達、BIM、コスト管理、ダッシュボードがあるか？」
問うべきは次の点です。
承認された一つの業務事象が、再入力・再解釈・手作業による照合なしに、入札から貸借対照表まで、モデルから現場まで、現場から経営会議までつながるか？
答えが「いいえ」であれば、そのプラットフォームは真のエンドツーエンドではありません。
