みなさんはプロジェクトのリソース計画・管理をどのようにしているだろうか。

昔は比較的規模が大きいプロジェクトが多かったため、プロジェクトで納期内かつ予算内に完了させるためのリソースを計画・管理が考えられていたように思う。

しかし、グローバル化や通信の発展にあわせ、各企業間での競争が激しくなりプロジェクトが低利益化、短納期化し、個別プロジェクトで十分な利益の確保が以前より難しくなるにつれて、企業としてリソース計画・稼働管理をどのようにするべきかが考えられるようになってきた。

下図は経営理念から考えるポートフォリオマネジメントのピラミッドに企業のリソースを当てる図となっている。
かつては各プロジェクト内でリソース管理が行われ、管理方法はプロジェクトに託されることが多かったが、最近では短納期の複数プロジェクトを抱える企業が増え、プロジェクトをまたいで、リソースを効率的に活用しようとする動きに変わってきた。

例えば、企業内に全社のプロジェクトを支援しモニタリングする立場のPMO（プロジェクトマネジメントオフィス）などを設置し、全社要員の稼働を可視化して非稼働要員を利用することにより、外注費を削減したり受注活動に割り当てて受注増を狙うなど、限られたリソースを最大限活用するための検討や調整を行っている企業も多くなっている。

まさに、プロジェクトのリソース管理から企業リソース最適化へ注目度が変化してきているのである。

では、企業リソース（要員）最適化のプロセスについて紹介していこう。
下図は企業リソース最適化のプロセスを示している。

各プロセスの詳細は次の通りとなる。

下図は、企業リソースの最適化の分析・調整を絵にしたものであり、① ～ ④ の情報のほかに企業のプロジェクト・ポートフォリオ分析による経営判断を含めたKPIをもとにしたプロジェクト優先度結果の情報を加え分析・調整により企業リソースが最適化されていく。

ここまでリソース稼働管理をテーマに企業リソースの最適化について述べてきたが、この仕組みを実現するにはシステムの活用が不可欠である。

ではここからシステムを活用した、企業リソースを最適化するリソース稼働管理について説明していきたいと思う。今回はプロジェクト・ポートフォリオマネジメント機能を持つ Oracle Primavera P6 を活用した例を紹介する。

まずは ① リソース情報の登録 と ② 要員計画の確認 であるが、下図のとおり要員情報、スキル（または役割）情報、年間の要員投入計画（月別など）を社内システムなどから Oracle Primavera P6 へ取り込む（システム間の連携開発は必要）ことで実現する。

次に ③ プロジェクト要求確認 であるが、ここではプロジェクトから必要要員を要求するところから説明したいと思う。
下図はプロジェクトのスケジュール計画者が必要要員と工数を割当てている。

各プロジェクトからのリソース要求を企業全体で確認すると下図のようになる。
下図は現在遂行中または計画しているプロジェクトと各要求されている役割の工数山積みを示している。下図の例では、Civil/Structural Crews の役割ができる要員をどのプロジェクトでいつ求められているかが分かるようになっている。
6つのプロジェクトが遂行中もしくは計画の状態にあり、キャパシティ（企業の要員投入計画値）を超えているのが分かる。
この場合、対象時期に増員を予定してキャパシティをあげて調整するか、プロジェクトの開始時期等の調整をすることが考えられる。

ここでは、プロジェクトの開始時期等の調整をする例をあげてみたいと思う。
⑤ 分析、調整<.b> であるので、もちろんプロジェクト優先度（規模、企業戦略など）は考慮すべきであるが、今回はシステムを使った調整例とする。
下図は、今後始める想定である計画中のプロジェクトの日程を調整してみた例である。
Oracle Primavera P6 のようなプロジェクト・ポートフォリオマネジメント機能を持ったシステムを使うと、この時期にプロジェクトが開始したら対象となる企業リソースは足りるのか、もしこのプロジェクトが開始しなかったら対象となる企業リソースの負荷はどうなるのかがシミュレーションできるようになっている。

もちろん、このようなシステムには全体的にキャパシティをもとにした企業リソースの最適化だけをするのではなく、リソース要求表（どの役割がどのプロジェクトでどのくらい要求されているか）やリソース稼働表（どの要員がどのプロジェクトにどのくらい入る予定か）の確認することも出来るので、これらを使って分析・調整することも可能だ。

さらに、スケジュール計画者が要員要求をしたあと、対象時期の稼働と役割（スキル）をもとに割当できるリソースのリスト確認と割当をすることもできる。
これによりスケジュール計画者が分析・調整をすることで企業リソースを最大限活用できるようになる。
ただし、これを行う上では企業としての割当ルールなどが必要であり、また実際には割当前に関係者との調整などが必要となってくる場合もある。

このように、プロジェクト・ポートフォリオマネジメントのシステムを活用することにより、企業リソースを最適化するプロセスが回せるようになる。 これにより企業としてのリソース稼働管理の仕組みができあがり、リソースが不足する状態や待ちになる状態が軽減され、効率的な企業としてのリソース稼働管理が実現するのである。</p/>

さて今回は企業としてのプロジェクト管理の仕組み作りとしてリソース稼働管理の話をしてきた。
グローバル化などにより世界の各企業との競争が行われるなか、企業の限りある資源をいかに効率よく活用するかが利益を確保していける1つの重要な要素となっている。
みなさんも仕組みとシステムを駆使して企業の限りある資源を有効に使ってみてはいかがであろうか。

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

プロジェクト責任者や現場責任者は、工程進捗・リソース負荷状況・コスト状況・生産性などを現状分析し対策を講じるために、手間と時間をかけて多種多様なレポートを受け取って情報を収集し、自分なりの整理と分析を行っている。

このような作業が、責任者の負担やレポートを作成する側の負担となっている。また情報の分析方法が責任者に依存してしまうため、企業としてもプロジェクト管理の属人化を招いている。

そこでいま注目を集めているのが、企業としてプロジェクト分析方法を考えて行くBI（ビジネス・インテリジェンス）を活用したプロジェクトKPI分析（キー・パフォーマンス・インデックス分析）である。
KPIやBIという言葉を聞くと、経営向けのイメージが強いと思われる。

しかし、最近ではプロジェクトで行われる業務の状況分析や製造現場の状況分析用にKPIを決め、BIで追跡を行いさまざまな分析・評価を行うことがトレンドになっている。

では、BIを活用したプロジェクトKPI分析の仕組み作りについて述べて行こう。

下図はプロジェクト関連と生産関連（製造業など内作が入る場合）の確認/評価/分析したい情報をまとめ、KPI分析を行う仕組みの例である。
プロジェクト管理システムの情報、設計/調達/工事に関連するシステムの情報、基幹システムからの情報、生産関連システムからの情報を集め、統合BIシステムでさまざまなKPI分析を行っている。
この例では組織側はプロジェクトサマリー分析などサマリー情報を、プロジェクト側では図書ステータスの分析や設計/調達/工事ステータス分析を、生産側ではジョブ進捗状況や工数などの分析を確認できるようになっている。またBIにより問題部分の追跡ができるようになっており、複数レポートで確認する必要がなくなっている。

では実際の統合BIシステムによるKPI分析の例を紹介していきたいと思う。
まずはプロジェクト情報分析として、以下4つの例を紹介する。

 ① プロジェクトサマリー分析
 ② 図書提出状況分析
 ③ 調達ステータス分析
 ④ 工事進捗分析

下図は「① プロジェクトサマリーKPI分析」の例である。

ここではプロジェクト全体の進捗状況、工数の予実、各WBSの状況が一目で分かる。
さらにSPI（スケジュール・パフォーマンス・インデックス）とCPI（コスト・パフォーマンス・インデックス）の低いところが色分けで分かるようになっており、ドリルダウンして追跡することにより、問題の詳細へたどりつけるようになっている。

① プロジェクトサマリー分析

下図は「② 図書提出状況分析」の例である。

ここでは各図書の提出状況として、図書分類ごとにステータスとして未提出数、未承認（提出し承認待ちになっているもの）、要再提出（コメントによる再提出が必要なもの）、承認済、それぞれ数が分かるようになっている。
これを見ると「設計図書」は14件中 9件が未完了（未承認、要再提出）であり、未承認の5件が提出済で承認待ちという状態になっているのが分かる。
さらに「計装チーム」に焦点を絞り、未承認2件をクリックすると追跡が行われ、対象となっている図書のドキュメントナンバーや名前、いつ提出したかが確認できる。

② 図書提出状況分析

下図は「③ 調達ステータス分析」の例である。

ここでは各調達品に対してRequisition（手配依頼）からDeliver on Site（現地到着）までのステータス状況を表現している。縦軸が機器/材料名、横軸がステータスイベントになっており、各機器／材料の手配状況はどうなのか、配送状況はどうなのか一目で確認できるようになっている。また予定より遅れている部分も色違いで警告される。
これによりスケジュールへの影響確認や調整への判断が迅速に行われるようになる。

③ 調達ステータス分析

下図は「④ 工事進捗分析」の例である。

ここでは工事全体をプログレスアカウントIDで明細をルールIDで表現しており、各工事（プログレスアカウントID）進捗率と工事明細（ルールID）のルールオブクレジット進捗率が分かるようになっている。下図の例では工事 PEVC-C06 をクリックし、PEVC-C06 工事明細を表示させることにより、工事明細（ルールID）V0021 と V0022 のルールオブクレジット進捗率の合計により、工事進捗率が30%になっていることが分かる。

④ 工事進捗分析

ここまで、プロジェクト情報分析の例をあげてきた。
次に生産関連システム情報分析として以下3つの例を紹介する。

 a. ジョブ消化-バーンダウン分析
 b. バッファ分析
 c. ジョブステータス分析

下図は「a. ジョブ消化-バーンダウン分析」の例である。

ここではジョブ消化計画と完了ジョブ、追加ジョブと総ジョブ状況を表現している。
赤の折れ線グラフが計画のタスク消化予定、赤の棒グラフが追加ジョブ数、青の折れ線グラフが総ジョブ数、水色の点が最新のジョブ消化予定数を表現している。
これによると追加ジョブにより総ジョブ数が増加し、予定消化スケジュールに対し、キャッチアップとしてジョブ消化スケジュールが見直されているのが分かる。
またここでは表現していないが、工数情報も取ると工数消化のバーンダウンに切り替えることも可能で、ジョブ消化状況とそれにかかる工数状況が一目で確認できる。

a. ジョブ消化-バーンダウン分析

下図は「b. バッファ分析」の例である。

ここではFOB（Free On Board）までのバッファ日数の変動が分かるようにしている。
棒グラフでバッファの日数を表し、棒グラフの頂点を線で結ぶことにより、バッファがマイナスになっていないか一目で確認できるようになっている。
これを見るとスケジュール途中でマイナスのバッファが出ており、対象時期に対するスケジュールの調整（もしくはリソースの調整）が必要となっていることが分かる。

b. バッファ分析

下図は「c. ジョブステータス分析」の例である。

ここではジョブの完了状況や予定に対する遅れを分かるようにしている。
折れ線グラフでジョブの完成予定を棒グラフでジョブの完了実績を表現している。
これを見ると初期段階で予定以上のジョブ数が完了し、途中からジョブの消化が少なくなっている。
一見前倒しているイメージに見えるが、初期のジョブ完了数が予定の倍になっていることから、追跡して倍になっている完了ジョブの確認をしていくと予定にないジョブが行われているケースもある。BIを使用しているので、追跡することで細部まで確認できるようになっている。

c. ジョブステータス分析

以上、本コラムでは企業としてのプロジェクト管理の仕組み作りのBIを活用したプロジェクトKPI分析について述べてきた。

いくつかのプロジェクトKPI分析の例をあげたが、企業やプロジェクトにより分析したいKPIは異なってくる。よってKPIを何にするか、どの情報を集めるべきか、つねに確認できる仕組みを作れるかが重要になってくる。
弊社のEPMソリューションサービスー統合BIシステム構築では、ワークショップで確認したいKPIとその必要情報がどこにあるかなどを確認していき、情報を一元化する仕組みとシステムを構築している。

企業としてKPIを決め、情報収集と可視化をする仕組みを作ることにより、企業としてのプロジェクトKPI分析の仕組みができあがるのである。

プロジェクトKPI分析は、いままで企業として仕組み作りを検討されることは少なく、プロジェクト担当者が手間と時間をかけて必要情報を必死に集め、Excel に詳しい人間に協力を得ながら独自に確認、分析を行っているケースが多かったと思う。

企業としてのプロジェクト管理の仕組みを検討・構築する企業が増えている中、その一環としてBIを活用したプロジェクトKPI分析も取り入れる企業がでてきている。

次世代の企業としてのプロジェクト管理の仕組み作りとして、みなさんもBIを活用したプロジェクトKPI分析を検討してみてはいかがであろうか。

最近よくプロジェクトを有する大手企業が米国プロジェクトマネジメント協会PMI®（Project Management Institute）のPMP®（Project Management Professional）取得社員を増やす目標を掲げているのを新聞で見たり、耳にしたりする。
PMI®ではPMの知識体系をガイドにしたPMBOK®ガイドを作成しており、このガイドや各参考書などを勉強してPMP®資格の試験の臨む人が多い。

今回はPMP®試験のベースともなるPMBOK®ガイドの「プロジェクト・タイム・マネジメント」の範囲に入る工程管理について述べていきたいと思う。

工程管理という言葉は、プロジェクト管理にはもちろん、そのほかのケースでも使用されていて、その考え方は業種やプロジェクトにより捉え方がまったく違うものになる。
たとえば、プラント建設などのエンジニアリング業や建設業では、マスタースケジュール・詳細スケジュールなどがイメージされるが、組立製造業では、大日程・中日程・小日程で管理され、工程管理手法や考え方も変わってくる。

今回はプラント建設、ビル建設など大規模プロジェクトの工程管理について説明したいと思う。たとえば海外の大規模プロジェクトの場合、発注者側からCPM（クリティカルパス計算）手法を使って、クリティカルパススケジュールを作成することが求められる。CPMはPMBOK®ガイドでも紹介されており、ネットワーク手法とも呼ばれスケジュールの作業レベルをアクティビティ（またはタスク）と呼び、アクティビティの順序設定を行うことによりスケジュールを作成する。

下図はCPMで計算を行う例である。

 ① 各アクティビティを定義し期間の設定する
 ② アクティビティの順序設定を行う
 ③ 順序に従ってアクティビティを移動する

以上によりスケジュールが作成され、アクティビティの最早開始、最早終了、最遅開始、最遅終了とフロート（余裕期間）が求められる。
たとえば [2F建設準備 20日] のアクティビティについては、[1F建設 30日] が完了するまでに完了させればよいことになるので、30日-20日=10日のフロート（余裕期間）があることになる。あわせて前からの計算で最早開始・最早終了、後ろからの計算で最遅開始、最遅終了の日程がわかるようになる。

また上図の赤字部分は、余裕期間がなく、最早と最遅日付が同じになっている。
このアクティビティをクリティカルアクティビティ、その流れをクリティカルパスと呼び、この手順でクリティカルパスを算出する方法をCPM（クリティカルパス計算）という。

海外のプラント建設やビル建設などでは、発注者側からの仕様書にCPMでクリティカルパスを明確にしたスケジュールを提出するよう求められるケースが多い。
初めて海外の建設プロジェクトに関わる方は、CPMではなく独自にスケジュールを引いて、ここがクリティカルであると表現してしまい、発注者側からきちんとCPMでクリティカルを計算するよう再提出を求められるケースが多いようである。

さて、ここまでCPMによるスケジュール作成を説明してきたが、スケジュール作成時に重要なのがリソース計画である。リソースのピークだけが高い状態であると、そこに一時的にリソースを多数投入することになるため、人の短期導入によるコスト高や作業に慣れないまま離れてしまうという生産性低下が発生する。

下図は各アクティビティに作業者というリソースを割り当て10日単位で負荷状況を表現したものになる。これをリソースの山積みという。

上図の例で確認すると山積みを行った結果、4/1～4/10にリソースのピークができており、制限も超えているため、スケジュールの見直しが必要となる。

下図では、準備②アクティビティのフロートを使い4/21～4/30へ移動させている。これによりリソース負荷のピークが崩されて制限値内に収まり、後続アクティビティの開始もそのままで安定的なリソース投入となるスケジュール計画ができている。このフロートを使った方法をリソースの山崩し（もしくは平準化・円滑化）という。
このあたりについてはPMBOK®ガイドの「資源最適化技法」で紹介している。

以上のように大規模プロジェクトの場合は、CPMや山積み、山崩しを行ってスケジュールを作成するが、これらを手動で行うのは非常に手間がかかるため、システムを使うケースが多い。

では、いままでの話をシステムを使うとどうなるか説明したいと思う。
今回はさまざまなスケジューリングに強いOracle Primavera P6を使った例をあげたいと思う。下図はOracle Primavera P6でスケジュール作成した例である。

 ① 各アクティビティを定義し期間を設定する
 ② 画面上でアクティビティ間の順序をつける
 ③ 計算ボタンを押す（順序に合わせアクティビティが移動される）

以上3つのステップで、各アクティビティの「最早開始/終了」「最遅開始/終了」「フロート」が計算され、クリティカルパスは赤で表現される。
ここまでがCPMによるスケジュール作成。このあとリソースの山積みと山崩し（平準化・円滑化）を行う。

 ④ 各アクティビティにリソース量を入力し、山積みを表示する
 ⑤ 山崩しボタンで山崩しを実行する

下図のように、このようなシステムを使うとスケジュール作成はスムーズにできるようになる。またこのようなシステムでは次にクリティカルになりそうな複数フロートパスの算出シミュレーションや山崩しの優先度など多数の機能が含まれている。

ここまで、工程計画について話をしてきた。
このあとは進捗管理と予実の話になるが、これはコラム第4回の設計進捗管理編、第5回の調達ステータス管理編、第6回の工事進捗管理編 に記載した方法で下図のとおり設計/調達/工事の進捗と生産性を測定していく仕組みを活用する。

工程管理側は上図の仕組みから収集した進捗と生産性の情報を把握・分析し、アクティビティ残期間（もしくは完了予定）を修正し、再度システムでCPM計算と山崩しを行いスケジュールを更新する。しかし、単純にマイルストンや納期を遅らせるわけにはいかない。
PMBOK®ガイドでは「スケジュール短縮」でクラッシングとファスト・トラッキングという2つの手法を紹介している。クラッシングとはリソースを増やすことによりアクティビティ残期間を縮める方法、ファスト・トラッキングとはアクティビティ順序設定を変えて並行作業させる方法である。下図はファスト・トラッキングの例である。

以上のように、工程管理ではスケジュール作成でCPM、リソース山積み・山崩しを使用し、スケジュールのコントロールでは、進捗と生産性の確認後ファスト・トラッキングやクラッシング手法を用いてスケジュールの見直しを行っていく。

今回は工程管理の手法を中心に説明したが、これはあくまでもプロジェクトでどのようにスケジューリングしていくかの話になる。
実際に企業として取り組むべきことは、プロジェクトに関わる人たちの工程管理用語や考え方の教育、システム作りによる情報共有化を行い企業としてのプロジェクト管理力を向上することである。このようなことからも国際標準的なPMの考え方としてPMI®のPMBOK®ガイドやPMP®資格が企業に注目されているのであろう。

最後に海外の大規模プロジェクト以外の工程管理にも少し触れておきたいと思う。
例えば、組立製造の量産では設備という制約が入るため、設備が重ならないスケジュールを作成しなくてはならないため、下図のようなスケジュール作成になってくる。

この他にも企業として全体プロジェクトの工程管理をしていくケース、人のスキル（専門リーダー）が中心となるプロジェクトの工程管理など、業種やプロジェクト規模、役割、管理内容により工程管理はさまざまである。
企業として業種や有するプロジェクトを考慮し、全体を見据えて工程管理の仕組みを作っていくことも必要で、これらの仕組み作りにより企業の競争力強化が実現するであろう。

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

企業としてのプロジェクト管理の仕組み作りとして、これまで3回にわたり、プロジェクト管理会計、設計進捗管理、
調達ステータス管理について記載してきた。
そこで今回は工事進捗管理について述べていきたいと思う。

工事の場合、まず現場状態が進み具合を左右すると言える。たとえば、現場の天候による影響や、現地の地盤状態や地形の影響などは、工事を進める上では避けて通れない問題であり、スケジュール遅れや工事数量の増加などをもたらす。

企業としては、これらをリスクと捉え、コンティンジェンシーを含めたリスク対策をとる。ただし、実際に発生したときは、スケジュール遅延の説明根拠や工事数量増加による変更承認をうけるための交渉が行われるため、現場の状況を迅速に把握し、それらの情報をしっかり管理・共有できる状態にしなければならない。

しかし、このような工事状況や進捗管理をExcelなどで個別に管理してしまうケースが多い。これでは、管理ファイルの紛失が起きたり、進捗管理が属人的になったり、情報の共有ができなかったりと、悪いケースでは工事状況を説明できずに承認を得られず泣き寝入りをすることになってしまう。

このように進捗と変更が大きくコストに影響する工事進捗管理を、企業としてどのような仕組み作りをしていけば良いだろうか？

まずは企業として考える工事進捗の計算例から明記していこう。

下図は工事進捗管理の例である。 ここでは、工事進捗を管理する単位としてプログレス（工事進捗）アカウントを用いている。このプログレスアカウントには、ルールという工事明細が管理される。
このルール（工事明細）別に「計画数量」と「重み」、「計画完了日」を設定する。そして、工事が進んだら「実績数量」を入れて「ルール・オブ・クレジット進捗率（出来高計上ルールによる工事進捗率）」を計算させる。

下図の例では、

・V0021は1.0㎥の計画数量に対し、実績数量1.0㎥以上で実績完了日もあることから作業進捗100%完了しているため、重みを考慮してルール・オブ・クレジット進捗率を計算すると以下のとおりとなる。

 計画数量1.0㎥×作業進捗1（100%）×重み0.2（20%）＝ルール・オブ・クレジット進捗率20%

・V0022は1.0㎥の計画数量に対し、実績数量0.5㎥で作業進捗50%となり、重みを考慮してルール・オブ・クレジット進捗率を計算すると、以下のとおりとなる。

 計画数量1.0㎥×作業進捗0.5（50%）×重み0.2（20%）＝ルール・オブ・クレジット進捗率10%
よって、PEVC11-06の工事進捗率は30% となる。

上記のように企業としての進捗計算の考え方を統一して管理することにより、属人的な進捗管理から企業として統一された管理方法に変わっていく。

次に工事数量が変更になったケースについて明記する。

今回は、現場で作業を行ってみると地形や地盤の影響などで、計画の数量より実際の作業する数量が多かったというケースの例を考える。

下図V0021は、計画数量が1.0㎥に対して実績数量が1.2㎥となり数量進捗は120となっている。つまり0.2㎥分追加で作業したことになる。
このように、数量が変更された情報をきちんと管理することにより契約相手との交渉材料にする。

このような重要な情報は、迅速に状況を把握・共有し、漏れのないよう管理し、前述の進捗計算と併せ、しっかり管理できるシステム作りが必要である。

最近では、工事進捗の算出・管理を行い、関係者に情報を共有しながら、迅速に現場の状況が把握できる工事進捗管理のシステムを活用する企業が多くなってきている。

では、システムイメージを含めた具体的な例をあげていこう。 今回はARES PRISMの現場管理システムを使った例をあげたいと思う。
下図は工事進捗を管理する単位としてプログレス（工事進捗）アカウントに対し、工事明細ごとに数量で進捗を測定し、工事進捗率を計算させている例である。
画面左上のプログレス（工事進捗）アカウントPEVC11-C06に対し、画面下にその工事明細となる各ルールが管理されている。

ルール（工事明細）ごとに「計画数量」「重み（加重）」「計画終了日」を入れる、工事が進んだら「実績数量（数量完了済）」をそれぞれ入れて行く。実績数量が入ると「数量進捗率」と「ルール・オブ・クレジット進捗率（出来高計上ルールによる工事進捗率） 」が計算される。そして、各ルールのルール・オブ・クレジット進捗率が加算され、PEVC11-C06の工事進捗率が算出される。

また上図のV0021では、計画数量1㎥に対し実際の作業が1.2㎥、この作業増が影響して計画終了日よりも実績終了日が10日間遅れている。このようなシステムを使うと、交渉の材料となる重要な情報が漏れずに保管され共有される。

ここまで、工事進捗の算出・管理や数量の変更についてシステムイメージを述べてきた。しかし、工事の場合もうひとつ重要なことがある。
それは現場作業の状況が、いかに迅速にかつ正確に収集できるかである。

今回紹介しているARES PRISM現場管理用のシステムでは、前述した工事進捗管理と併せて現場報告用に特化したシステムを持つ。

上図のように現場からタブレットなどで担当作業の実績を入力するとルール（工事明細）の実績として反映される仕組みになっている。これにより現場の進み具合がすぐに把握できるようになり、工事進捗が即時に計算される。
これらにより、現場作業の状況が即座に反映され、工事進捗率がいつでも確認できる仕組みができあがる。

また下図の通り、ARES PRISMでは前回、前々回 とコラムで記載してきた設計進捗管理と調達ステータス管理同様に現場管理システムもコスト管理システムとリンクする。そのため、現場管理システムで算出した進捗率は、プロジェクトとしてのコントロールアカウントの進捗率へ反映されプロジェクトの進捗率や完成予測コストを計算する。
これにより、プロジェクトの工事の現場状況報告から工事進捗率、工事のコスト関連までが企業としてわかる仕組みができあがる。

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

このように工事の現場状況と工事進捗率を常に共有化し、工事進捗状況や現場の変更状況などをプロジェクト管理システムに取り込むシステム作りをすることにより、企業としての工事進捗率をいつでも確認できる仕組み、また工事進捗率を考慮したプロジェクト管理会計の仕組みができあがる。

さて、4回にわたり企業としてのプロジェクト管理の仕組み作りとして、プロジェクト管理会計（コスト管理）、設計進捗管理、調達ステータス管理、工事進捗管理について記載してきた。

これらはまだ各プロジェクトでばらばらに管理されることも多いと思う。ただこのような企業としての取り組みを導入、もしくは導入に向けての準備をしているところは、非常に多くなってきているのも事実だ。

ここ数年は、弊社が受ける問い合わせもプロジェクト管理システム（またはプロジェクト管理製品）単体の問い合わせではなく、プロジェクト管理とERPなど基幹システムの連携やドキュメント管理と進捗管理の組み合わせ、プロジェクトスケジュールと調達ステータス管理の組み合わせ、企業全体のプロジェクト管理関連すべての組み合わせなど、企業システムとしての仕組みとシステムの提案依頼が多くなってきている。

みなさんも次世代プロジェクト管理の仕組みとして、企業としてのプロジェクト管理の仕組みを検討してみてはいかがであろうか。

※本文中の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のリストを持って調達部隊に確認しに行き、タイミング悪く古い情報を得てしまうようなことはなくなるに違いない。