※本文中のARES PRISMはブランド名を「Contruent Enterprise」に変更いたしました

プロジェクトから調達へ機器の手配依頼（REQ-Requisition）をしたのに、予定日になっても機器が現地に届いていない？ そもそも手配されているのか？

みなさんはプロジェクトで機器の手配ステータスが分からずに、こんな心配をしたことがないだろうか。 プロジェクトとしては、「いつ設置や工事ができるのか」手配の状況はかなり気になるところである。

本コラムでは、このような課題にどう対応するか、企業としての調達ステータス管理の仕組み作りについて話をしたいと思う。

調達のステータス管理は、以下の3つがある。

 ① 注文書（PO）を発行するまでのステータス管理
 ② 注文書（PO）を発行した後の出荷のステータス管理
 ③ 注文書（PO）を発行した後の支払のステータス管理

プロジェクトでは、これらのステータスを常に把握することが難しく、実態としては担当者が調達部隊へExcelのリストを持ちながら、手配状況をつど確認するケースが多い。

では、これら3つのステータス管理に対してどのような仕組み作りをしていくのが良いか、まずは調達業務の流れを元に考えていこう。
下図は注文書発行までと注文書発行後の調達業務について流れを表したものである。

注文書発行までの業務では、設計側からREQ（手配依頼）が出されると、調達では依頼内容を確認し、RFQ（見積依頼）と入札（BID）が行われ、ベンダー決定後に注文書（PO）を発行する。そして、ここまでの注文書ステータスを管理する。
注文書発行の後は出荷（Shipment）業務と請求・支払（Invoice）業務に分かれる。
出荷業務では、Line Item（購入品アイテム）ごとに出荷ステータスを管理し、請求・支払業務では支払ステータスを管理する。

上図のように調達業務の中では、ステータスとともにコストの計上が発生する。

注文書発行により確定コストが計上し、支払により実績コストが計上される。この確定コストがコスト管理のポイントの１つとなっている。

プロジェクトの期間が長く、また手配する機器や材料の金額が大きいプロジェクトでは、支払業務が完了するまでコスト計上がされないと、コスト実績値が後になってから一気に上がることになり、スケジュール／リソースの調整が迅速にできなくなる。

よって、このようなプロジェクトでは支払金額が確定する注文書発行タイミングで確定コストを計上するのである。もちろん、支払業務完了時の金額は実績コストとして計上する。

以上のように注文書発行前、発行後における3つのステータス管理をプロジェクトと調達の双方が、常に確認できるよう可視化し、確定コスト（Commitment）と実績コスト（Actual）をコスト管理へ計上できる仕組みやシステムを作ることにより、「いつ設置や工事が行えるか」「実際にプロジェクトでかかっている調達コストはいくらか」が分かるようになる。

では、システムイメージを含めた具体的な例をあげていこう。 今回はARES PRISMの調達管理システムを使った例をあげたいと思う。

まずは注文書発行までの注文書ステータス管理から説明しよう。
下図はARES PRISM調達管理システムで注文書ID:PEVP11-PO-000001に対し、ステータスがどこまで進んでいるかを確認している例になる。

あらかじめ企業としての注文書ステータス測定用にイベントを用意しておき、いつでも注文書の状況が分かるようになっている。この例では、入札が完了して2/28に注文書（PO）完了予定であることが分かる。
もちろん、このようなシステムでは、REQ（手配依頼書）作成・確認、対象ベンダー選定など業務面の機能も備えている。

次に注文書発行後の出荷ステータス管理を説明しよう。 下図はARES PRISM調達管理システムで出荷ID:PEVP11-PO-000005-S01に対し、ステータスがどこまで進んでいるかを確認している例になる。

あらかじめ企業としての出荷ステータス測定用にイベントを用意しておき、いつでも出荷の状況が分かるようになっている。この例では、手配した機器や材料が輸送中で6/6に現地に到着する予定であることが分かる。
これにより手配を依頼した機器や材料の調達状況が分かり、「いつ設置や工事が行えるか」が計画できるようになるのである。同様に支払ステータス管理や請求・支払業務もできるようになっている。

さて、ここまで調達に関わるステータス管理の話をしてきた。 ここからは注文書発行や支払の完了時に計上される調達コストとプロジェクトコスト関連を説明していこう。

以前のコラムでも記載したが、ARES PRISMのコスト管理システムでは
コントロールアカウント（プロジェクトのコスト管理単位）で
予算（Budget）、変更予算（Change）、実績（Actual）、
確定（Commitment）、完成時予測（EAC）を管理する。
管理項目にある通り、ポイントの１つである確定（Commitment）も管理対象である。

たとえば、プロジェクト期間が長く、また手配する機器の金額が大きい場合、その金額はプロジェクトのコスト管理に大きな影響を与える。
そのためプロジェクトでは、支払完了ではなく金額が確定する発注段階でコスト計上したくなる。
ARES PRISMでは、注文書が発行され確定（Commitment）項目にコストが計上され、支払が完了すると実績（Actual）項目にコスト計上される。

また、ARES PRISMでは調達管理システムでとコスト管理システムがリンクしているため、注文確定時の発注金額と支払完了時の支払金額が、それぞれプロジェクトのコスト管理単位であるコントロールアカウントに対する確定（Commitment）と実績（Actual）に計上される。
これにより常に「プロジェクトで現在発注した額はいくらか、支払まで完了した額はいくらか」が分かるようになるのである。

以上、本コラムでは調達ステータス管理の仕組み作りについて述べてきた。

このように調達ステータスを共有化し、また発注・支払コストをプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての調達ステータスをいつでも確認できる仕組み、また調達ステータスを考慮したプロジェクト管理会計の仕組みができあがる。

これによりプロジェクトマネージャ、プロジェクト関係者、組織長などのマネジメントはいつでもプロジェクトステータスとコスト状況を分析し、常に必要な対策を取れるようになるのである。

近年の通信やシステムの驚異的な進化により、調達業務のグローバル化や調達業務の効率化を考える企業が増えてきている。
企業として調達ステータスを可視化できる状態にし、遠隔地からでもプロジェクト担当者が確認できる仕組みができあがると、信憑性が高く迅速が対応が取れるようになる。

そうすれば、Excelのリストを持って調達部隊に確認しに行き、タイミング悪く古い情報を得てしまうようなことはなくなるに違いない。

※本文中のARES PRISMはブランド名を「Contruent Enterprise」に変更いたしました

みなさんは、設計業務の進捗管理をどのように計っているだろうか。

進捗基準を明確にせず、属人的で根拠がわからないまま90%完了したと連絡を受けてないだろうか。
よくある話であるが、90%終わっているはずなのに数週間経っても完了報告がなく、本当に終わるのかと心配になったことはないだろうか。

今回は、属人的にならない設計進捗管理の仕組みについて話をしていきたいと思う。

設計業務と言えば設計図書などのドキュメント作成が中心であるが、最近ではドキュメントの進捗基準にいくつかのパターンを用意し、ドキュメントのステータスを管理する企業が増えてきている。
ただし、ドキュメント管理のステータスをもとに、設計業務全体の進捗がわかるような仕組みを整えているところは少ないのではないだろうか。

では、どのような仕組みで設計図書（ドキュメント）の進捗と設計業務を管理していくか。
各社いろいろと設計業務の進捗管理単位はあると思うが、今回は設計進捗の管理単位を考えるエンジニアリングアカウントを使った管理例を紹介しよう。

設計図書の数が多い場合、設計図書１枚ずつを設計業務の進捗管理単位とすることは難しい。エンジニアリングアカウントは複数の設計図書をまとめた成果物の単位で管理する考え方である。
下図は一例であるがエンジニアリングアカウント（設計成果物ベースの管理単位）の進捗が算出される流れを明記している。

 ① エンジニアリングアカウントを定義する（対象設計図書など）
 ② 設計図書の進捗マイルストンを定義する
 ③ 設計図書提出に合わせて進捗計算する

下図の例では設計図書Aを5/11提出により、設計図書Aの進捗が50%となり、見積時間（重み）により成果物の進捗であるエンジニアリングアカウントは15%となる。
プロジェクトの各エンジニアリングアカウントを集約するとプロジェクトの設計進捗が計算される。
この仕組みをシステム構築し自動化することにより、企業としてプロジェクトの設計進捗を即時に捉えることが可能になる。

では、システムイメージを含めた具体的な例をあげていこう。
今回はARES PRISMの設計管理システムと、コレポン管理Aconexを使った例をあげたいと思う。

下図はAconexで [PEVE3#-PFD-000001] を含む設計図書を送付状を付けて送付し、提出日を設計図書の進捗マイルストンに反映させた例である。
これにより [PEVE3#-PFD-000001] の進捗率が50%となる。同じエンジニアリングアカウントに属する設計図書の進捗率もあわせエンジニアリングアカウントの進捗率が算出される。

それぞれのエンジニアリングアカウントで進捗率が算出されたら、関係するコントロールアカウントに反映されコントロールアカウントごとの進捗率が算出される。
つまり、それぞれの設計業務の進捗が、プロジェクト業務の進捗に反映されるのである。

そして、下図のようにコントロールアカウントの進捗率が見えると、「どこまでの進捗で、コストがいくらかかっているか」が分かるようになる。また、進捗率を踏まえた完成時予測も算出されるため、コントロールアカウントの進捗率、予算、実績、完成時予測がすべて自動で見えるようになる。
この仕組みをシステム構築し自動化することにより、企業としてプロジェクトの設計進捗をベースとしたコスト予測を即時に捉えることが可能になるのである。

もう一つ具体的な例として、前回のプロジェクト管理会計編でも登場したARES PRISMのコスト管理システムを使った例をあげたいと思う。 さきほどARES PRISM設計管理システムで算出した進捗率は、コスト管理システムに画面を切り替えると、コントロールアカウントの進捗率へ反映され表示されている状態になる。また、コントロールアカウントの進捗率をもとに完成予測が計算される。
（計算方法については、CPIを反映／SPIとCPIを反映など選択可、またこれらを参考値として直接入力する方法もある）

これらにより、統一した基準で設計進捗は管理されるようになり、どこまで進んでいくらかかっている（また、いくらかかりそう）が分かるようになる。
さらに、システムのレポート出力により、進捗率カーブやコストカーブも確認できるようになるのである。

エンジニアリング・進捗レポート例

エンジニアリング・コストレポート例

以上、本コラムでは設計進捗管理の仕組み作りについて述べてきた。

このように企業として進捗基準を統一し、設計進捗をプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての設計進捗だけでなく、進捗を考慮したプロジェクト管理会計の仕組みができあがる。
これによりプロジェクトマネージャ、プロジェクト関係者、組織長などのマネジメントは　いつでも統一した基準で設計進捗を確認でき、プロジェクトの進み具合とコストを分析し、常に必要な対策をとれるようになるのである。

通信のめざましい発達により、いつどこでも必要な情報が取得できる現在、情報がいかに正しく伝わっているかが　ポイントとなっている。
プロジェクトにおける設計進捗を基準なく管理してしまうと、同じような設計図書で同じ進み具合であっても人によっては、90%であったり、30%であったりする。そうならないためにも、企業で進捗基準を作りシステム化する必要があるだろう。

90%から何週間も進まないような、属人的な報告はなくしたいものである。