Oracle Primavera Unifierとは? — 月曜の朝、設計変更1件から始まる話

月曜9:00、現場。 設計変更が1件下りる。鉄骨の数量が変わった。原価はどれだけ増え、工程にどう響き、誰が承認するのか。この1件が五つの部署を通る。

よくある光景はこうだ。現場がExcelで影響金額をまとめ、メールで本社へ上げ、電話で確認する。三日経っても「今は誰の番か」が見えない。変更は積み上がるのに原価シートは月末にしか合わない。事故が起きてから精算する構造だ。

Oracle Primavera Unifierはこの光景を変える。一行で言えば — 資本プロジェクトの原価・契約・変更・プロセスを一か所で、進行中に統制させる。何を束ねるかを見る前に、なぜこの統制が必要かから押さえよう。

なぜ「プロジェクト・コントロール」か — 資本プロジェクトが漏れる地点

建設・プラント・インフラのような資本プロジェクト(capital project)は規模が大きく、契約と変更が頻繁で、多数の主体が同時に動く。だから原価と工程が漏れやすい。特定企業の問題ではなく、産業全体で繰り返し観測されてきた構造的パターンだ。

産業研究はこのパターンを一貫して報告する。オックスフォードのベント・フリュビヤ(Bent Flyvbjerg)は大型プロジェクトの「予算超過、工期遅延、何度も(over budget, over time, over and over)」を「メガプロジェクトの鉄則(iron law)」と呼んだ。マッキンゼー・グローバル研究所(MGI)のReinventing Construction(2017)も同じ方向を指す — 大型建設プロジェクトは工程が平均20%ほど長くかかり、予算は最大80%まで超過する傾向があるという分析だ。(産業研究の推定値で、プロジェクト類型・地域により差が大きい。DTソリューションの実測値ではない。)

原因は単一ではないが、よく指摘される共通項がある。情報が分散していることだ。原価はExcelに、工程は工程表に、契約はキャビネットに、承認はメールボックスにある。変更1件がこれら全てに同時に触れるのに、どこにも集約されないため、損失は「進行中」ではなく「事故の後」にしか見えない。プロジェクト・コントロール(原価・工程・変更・契約を一つの体系で統制する発想)は、まさにこの漏れの地点を狙う。Unifierが立つのがここだ。

では、Unifierが具体的に何を束ねるか見よう。

変更1件がシステムを通る道

さきほどの鉄骨変更に戻ろう。Unifierではこの1件が「変更ビジネスプロセス(BP)」1枚として始まる。フォームを開いて変更内容を書くと、連結された原価コードから影響金額が自動計算され、定められた決裁ラインに沿って電子的に流れる。

違いは結果ではなく「時点」に出る。同じ変更1件でも、ツールによってこう分かれる。

それで、Unifierが扱うもの — モジュール別に

変更1件を追えばUnifierの領域が自然に見えてくる。一行要約ではなく、モジュール別に何をどうするか覗いてみよう。前提は一つ。これらの領域は別々に動くモジュールではなく、一つのデータモデルの上に載っている。

① 原価管理 — Cost Sheet・キャッシュフロー・EVM

Unifier原価管理の中心にはCost Sheet(原価シート)がある。行は原価分類体系(原価コード/CBS)、列は予算(Budget)・約定(Commitment)・実績(Actuals)・予測(Forecast)などの原価項目だ。発注・契約・変更・出来高などすべての取引が定められた原価コードに入り、このシートのセルを自動で埋める。原価シートは人が月末に手で合わせる表ではなく、取引が積み上がるたびに生きて動く台帳だ。

ここに二つが加わる。キャッシュフロー(Cash Flow)は予算・約定・実績を工程曲線に配分し、期間別の資金需要と回収を予測する。出来高(EVM)は計画価値(PV)・出来高(EV)・実コスト(AC)から工程成果指数(SPI)と原価成果指数(CPI)を算出し、「このまま行けば最後にいくらになるか(EAC)」を進行中に見通させる。損失を最後ではなく途中で見せる仕掛けだ。

② 契約・約定管理

発注(Prime Contract)と下請(Subcontract)、それに紐づく約定(Commitment)を電子的に管理する。契約金額・項目はそのまま原価シートの約定列へ流れ、出来高(Progress Billing)と支払(Payment)が実績として累積する。契約変更は変更BPを通じて契約残高と約定を更新する。「この契約にいくら残っているか、次の出来高はいつ・いくらか」が一か所で答えになる。

③ 変更管理 — Change Order

設計・数量・契約変更(Change Order)を標準手順で統制する。先の鉄骨変更のように、変更1件はフォーム1枚で始まり、影響金額の自動算定 → 決裁 → 原価反映の流れに乗る。核心は、すべての変更が原価に即連結され、全履歴が追跡される点だ。「この変更が予算をどれだけ食ったか、誰がいつ承認したか」が紛争なく残る。

④ プロセス自動化 — uDesigner

上のすべての流れを支えるエンジンがuDesignerだ。組織ごとに異なるフォーム・決裁ライン・承認ルールをコードなし(ノーコード)で設計させる。詳しくは下で扱う。

⑤ 文書管理

図面・提出物(Submittal)・契約文書をバージョン・権限とともに中央で管理する。ビジネスプロセス(変更・出来高・検討)に文書を添付して一緒に流せるため、「どの決定がどの図面の上で出たか」が途切れない。大規模な文書協業は姉妹ソリューションAconexがより深く担い、Unifierは原価・プロセスの文脈で必要な文書を束ねる。

⑥ 資本計画・ポートフォリオ

個別プロジェクトを超え、発注者が多数プロジェクトの資本計画・優先順位・予算配分を一つのポートフォリオで管理する。個別プロジェクトの原価・工程が上に集計されポートフォリオダッシュボードに上がり、「どの事業に資本をどれだけ投じるか」をデータで決める。

⑦ 資産・施設管理

プロジェクトが終わっても終わりではない。竣工した施設・設備は運用・保守へ移る。Unifierは資産・施設管理(Facilities & Asset Management)まで延び、資産登録・点検・保守要請・空間管理を同じプラットフォームで扱う。建設(CapEx)から運用(OpEx)まで、資産の全ライフサイクルを一つのデータ上でつなぐ。

これらモジュールの力は連結から生まれる。変更が契約に触れ、契約が原価を動かし、原価がキャッシュフローとダッシュボードに表れる — その連結が途切れない。

uDesignerをもう一層 — ノーコードで働き方を設計する

Unifierの真の差別点を一つ挙げるならuDesignerだ。多くのパッケージシステムは「決まった画面と手順に組織を合わせろ」と求める。Unifierは逆に、組織の働き方をシステムの中に描き込ませる。

その単位がビジネスプロセス(BP)だ。BP一つは業務様式+その様式が流れる手順だ。uDesignerではコーディングなしで次を設計する。

• フォーム(Form) — どのフィールドを受けるか(テキスト・金額・日付・ドロップダウン・添付)、何を必須にするか、レイアウトをどう置くか。
• ワークフロー(Workflow) — 要請 → 検討 → 承認 → 反映へ続く段階と分岐、各段階の担当・権限・期限。
• 原価連結 — このBPが原価シートのどの列(予算・約定・実績・変更)を動かすかのマッピング。
• 業務ルール — 金額帯別の決裁ライン分岐、自動計算式、状態遷移条件など。

効果は双方向だ。組織ごとに異なる決裁ラインと様式をパッケージに合わせて曲げる必要なくそのまま実装することも、逆に標準プロセスを新たに移植することもできる。人が覚えて回していた手順がシステム上で自動的に流れる。uDesignerがUnifierを「原価台帳」ではなく「プロジェクトの運用基盤」にする地点がここだ。

P6と何が違うか

同じPrimaveraだが役割が違う。P6は「いつ」(工程・スケジュール)を、Unifierは「いくらで・どの手順で」(原価・契約・プロセス)を担う。代替ではなく二つの軸だ。

二つを連携すればP6の進捗がUnifierの出来高・出来高価値(EV)へ流れ込む。工程遅延(SPI)と予算超過(CPI)を別々に見るのではなく一つのモデルで見る。大型EPCが損失を最後にしか発見できなかった宿痾が、この統合により早期警報へ変わり得る — 進捗がそのまま原価に換算されて見えるからだ。ただしその効果は、データが時宜に入力されてこそ生まれる。

統合PMISという絵 — P6・Aconex・Unifier

Unifierは単独でも使えるが、真価は同じPrimaveraエコシステムの中で束ねられたときに表れる。三つの軸に分かれる。

• Primavera P6 — 工程。工程・資源・クリティカルパス(CPM)で「いつ終わるか」を押さえる。
• Oracle Aconex — 文書・協業。図面・提出物・書信・検討を発注者・EPC・協力会社が一か所でやり取りし、誰が何をいつ見たかを追跡する。
• Primavera Unifier — 原価・契約・プロセス。「いくらで、どの手順で」を統制し、上の二つから入る工程・文書を原価の文脈で編む。

三つの軸が束ねられて初めて工程 × 費用 × 文書が一つの統合PMISになる。工程が遅れれば原価が揺れるのが見え、その決定の根拠文書がすぐ付いて回る。分散した三つのシステムを使うのと、連結された一つの体系を使うことの差がここで分かれる。

どう導入するか — 方法論と考慮事項

ツールを入れただけで自然に良くなることはない。Unifier導入の成否は製品よりデータとプロセスの設計で分かれる。実務で押さえる段階はおおむねこうだ。

原価コード体系(CBS)の設計

すべての原価フローが入る原価分類体系をまず立てる。細かく刻みすぎると入力負担が、粗すぎると分析ができない。WBS(工程)・契約構造との整合もこの段階で取っておくとP6連携が滑らかだ。

標準プロセス(BP)の定立

変更・出来高・購買要請・検討など核心業務を標準BPとして定義する。現行の決裁ラインをそのまま移すか、この機会に標準へ整理するかを成熟度に合わせて決め、uDesignerで実装する。

データ移行

進行中のプロジェクトなら既存の予算・契約・実績を移行(migration)する必要がある。どの時点を基準線(baseline)とし、過去履歴をどこまで移すか範囲を決めるのが肝だ。

段階的ロールアウト

全社・全モジュールを一度に点けるより、パイロット・核心モジュールから検証後に拡大するほうが安全だ。原価・変更管理のように効果の大きい領域を先に定着させ、ポートフォリオ・資産へ広げる。

変更管理

最も見落とされる段階だ。Excel・メールに慣れた現場をシステム上で働かせるには教育・マニュアル・初期運用支援が要る。システムではなく人が変わってこそ効果が出る。

きちんと定着したときに変わることは明確だ。分散した原価・契約・承認が単一の真実の源(single source of truth)に集まり、決裁が電子化・標準化され、変更と原価が月末ではなくリアルタイムで見える。すべての処理に監査証跡(audit trail)が残り、「誰がいつ何を承認したか」が紛争なく残る。クラウド・オンプレミスの両方に対応し、導入形態も選べる。