Column

コラム

プロジェクトマネジメント

2022/02/18

【11】製造業におけるプロジェクト管理の仕組み作り(1)

今回は製造業のプロジェクト管理について話をしたいと思う。

製造業では余剰在庫をできるだけ減らすため、受注してから設計を始める個別受注生産に事業を変更して行う企業がよくある。
たしかに個別受注生産であれば余剰在庫を減らすことは考えられるが、設計・調達・組立まで一気通貫で工程管理、リソース管理をしていかないと、納期遅延やリソース不足、コスト増加を引き起こす。
つまり、生産管理以外にプロジェクト管理の考え方が必要になってくる。

では、個別受注生産におけるプロジェクト管理について述べていきたいと思う。

海外企業との競争など製造業も納期要望の短期化が進んでいるなか、多数の短納期案件を受注する製造業が増えている。経営陣や組織マネージャ、営業は、現案件がいつ完了して次の案件を始められるのか、人の都合はつくのかを、常に設計部門長・調達部門長・組立部門長に状況を確認し、お客様と話を行っていく。しかし、案件が増えてくると全案件の状況を把握することが困難になってくる。

このようななか、企業の全案件状況を確認していくため PMO(プロジェクト・マネジメント・オフィス)を一つの組織として設置する企業も出ている。
PMO は企業のプロジェクト管理を横断的に支援する立場として、各案件の進捗状況やリソース状況(もちろんその他もあるが)をモニタリングし、経営陣や組織マネージャへの報告、また対応が必要なプロジェクトに必要な支援を行っていく。
これにより企業として全案件の状況を分かるようにする考えであるが、PMO が全案件をモニタリングするための全社で統一した仕組みとシステムが必要だ。

上図は全社で統一した仕組みとシステムがない状態で起こるケースである。上図では、設計部門で個別に対象製番(案件)の管理をしており、調達部門や組立部門にはいつ図面があがってくるかがよく分からない。また調達部門や組立部門もそれぞれのシステムで個別に管理しており、設計部門からするといつまでにどの図面を作れば良いかが分かりづらい。さらに PMO は定期会議報告で受けた情報しかなく、最新の製番進捗状況が把握できない状態が起きている。

このような状態の時、企業は以下が可能となるシステムを検討することが多い。

  • ・設計、調達、組立の進捗状況を一気通貫で確認できる(大日程、中日程レベル)
  • ・必要スキルのリソース負荷状況を確認し要員調整が行える
  • ・全製番をまとめて管理することができる
  • ・全社が同一の仕組みで使える(海外拠点がある場合は多言語対応)

上図は全社で統一したシステムを考えたケースの例である。
この例では、BOM 構成を利用して大日程、中日程の構成を作り、小日程(生産スケジューラなど)と統合させて設計、調達、組立を一気通貫で確認できるようにした仕組みである。
製番の下を設計、調達、組立のフェーズにし、その下を BOM 構成にして遅れをトレースする考え方だ。これにより PMO はいつでもどの製番の、どのフェーズで、どの部品が遅れているのかをトレースできるようになる。

では、システム作りの例をあげていこう。今回は Oracle Primavera P6 と BOM システム、生産スケジューラの連携をベースにしたシステムの例である。
下図は Oracle Primavera P6 に全製番を登録し、WBS を BOM 構成として BOM システムから取り込み、アクティビティ(作業レベルのタスク)を生産スケジュールの小日程の日付から取り込んでいる。またアクティビティにはどのフェーズの作業か属性をつけておく。

これらの取り込みにより小日程から中日程(BOM 構成)、大日程(フェーズ)、製番へと工程計画・進捗、リソース工数の予実が集計される。これで PMO は全製番の進捗状況とリソース状況がわかるようになり、設計、調達、組立では一気通貫の管理が実現され、図面はいつ出来あがるか、いつまでに作れば良いかがそれぞれ分かるようになる。
もちろん、システムを使う前に、事業戦略案件、案件規模、案件難易度など常にモニタリングが必要な製番の洗い出しや、アラートの対象となる遅延日数、リソース投入可能数、超過工数の設定などをあらかじめ決めておく必要がある。

では、PMO がこのシステムでどのように全製番の状況をチェックするか記述していこう。
下図は製番一覧である。ここでは計画より10日以上遅れている製番に対しマークをつけ、対象製番だけを絞りこんで確認している。下図では 5 製番が10日以上遅れている状態であり、PMO は毎日遅れている製番だけを確認できるようになっている。
ただし前述したように、遅れ以外にも戦略的に優先して確認したい製番や規模や予算など企業にインパクトが大きいものは、システムで確認できるようにしておく。
今回は遅れ製番に焦点をおいて、どのようにトレースしていくかを明記したいと思う。

上図により遅れ製番が確認できたので、次にこれらの製番のどのフェーズが遅れているかを見ていく。

下図は 5 製番をフェーズ別に切り替えた画面である。たとえば製番P00400では、調達と組立に遅れが生じていることが分かる。

さらに、P00400の調達について部品構成を表示すると部品P-1、P-2、P-2-1に遅れが生じており、P-1とP-2-1については終了列に納品フラグの A(Actual)が無いことから、手配したが、未納ということが分かる。

また組立の遅れに対してリソース負荷状況を確認してみると、組立上級スキル(リーダーレベル)の負荷が高くなっており、調整が必要な状態になっていることも確認できる。

これで、PMO は全製番に対する進捗状況とリソース状況の確認や問題の抽出が
できるようになり必要な対策をどこに打てば良いかが明確になる。

今までは PMO の視点から話をしてきた。しかし、全社的に統一したシステムを使うとなると現業側からも見たい情報が見られるようにしたいものだ。今回はその一例をあげたいと思う。例えば、調達や組立では部品の入荷状況を一目で確認したいものである。調達と組立用の画面レイアウトを切り替えると、部品の発注数、入荷数、入荷率が各日程とともに分かるようになっている。これにより各部品の入荷状況がいつでも分かる。

また設計では、設計メンバーの稼働状況が気になる。設計メンバーの稼働状況画面に切り替えると、どのメンバーがどの製番でどのくらい稼働予定かが分かる。これによりリソース調整が可能となる。

以上のように PMO だけではなく、現業側の欲しい情報も用意することにより企業全体のシステムや仕組みの導入、運用がスムーズにできるようになる。

今回は製造業のプロジェクト管理をテーマに個別受注生産の全案件の工程、リソース管理の仕組み作りを説明してきた。

今回のように単体のプロジェクトではなく、複数プロジェクトをまとめて管理することを「プログラム管理」、経営戦略などによる優先度や規模、難易度などを入れて全プロジェクトを分析することを「プロジェクト・ポートフォリオ管理」という。

短納期で多数案件を管理する今回のような製造業では、全案件をモニタリングする組織やシステムを検討する企業が増えてきている。プログラム管理、プロジェクト・ポートフォリオ管理の考え方やシステムをいかに取り入れ、見える化できる仕組みを作っていくかが今後の鍵になっていくだろう。

この記事へのお問い合わせ 

関連リンク

Primavera ファミリー概要

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera ファミリー概要」詳細はこちら

Primavera P6 EPPM

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera P6 EPPM」詳細はこちら

カテゴリ:プロジェクトマネジメント

2022/02/18

【10】IaaS、PaaS、SaaS でもない第四の次世代クラウド(プロジェクト用)

みなさんはプロジェクト用アプリケーションにクラウドを活用しているだろうか。
クラウドというと IaaS(Infrastructure as a Service)[イァース]、PaaS(Platform as a Service)[パース]、SaaS(Software as a Service)[サース]の3つの考え方が定番となっている。この3つの定義について調べてみると、IaaSはハードウエアまで、PaaS は OS や実行環境を伴うプラットフォームまで、SaaSはアプリケーションまでとよく書かれている。
しかし、SaaS はアプリケーションベンダーがその会社のアプリケーションのみ提供しているものであり、実際には PaaSのプラットフォームに自社でアプリケーションのインストールや設定を行うか、メインベンダーのアプリケーションに絞って SaaS にするかのどちらかになり、複数ベンダーのアプリケーションが自由に選べるわけではない。

例えば、あるユーザーがプロジェクトでCADアプリケーションと工程管理アプリケーションを使う必要が出たとき、CADベンダーと SaaS 契約したうえで、更に工程管理アプリケーションのベンダーと SaaS 契約する必要がある。
また、ユーザーはバージョンの指定が困難であったり、それぞれのアプリケーションベンダーへテクニカルな問い合わせや教育依頼をしなくてはいけないなどの課題が出てしまう。

そこで今回話題にあげたいのが、PaaS でも SaaS でもない必要なアプリケーション層までを提供する次世代クラウドである。
ソフトウエア(アプリケーション)とプラットフォーム両方を提供するということで、ここではあえて SPaaS(Software and Platform as a Service)[エスパース]と呼びたいと思う。
SPaaS はプラットフォームに加え、アプリケーション層を提供する。つまり必要なアプリケーションと数量を伝えるだけで、必要なアプリケーションが必要な数量だけ、いつでもどこでもブラウザから利用できるようになる。
これによりインストールなどの設定作業や認証化、ユーザー設定などが一切不要になる。

上図は SPaaS サービスのイメージであるが、プラットフォーム上にアプリケーション層があり、そのなかに必要なアプリケーションが必要な数量用意される。
サービス利用者はサービス提供ベンダーへ使いたいアプリケーション名、数量、ユーザー情報を伝える(ここでは、ユーザー1がアプリケーションAとB、ユーザー2がアプリケーションBとCとD)。するとユーザー1のブラウザからアプリケーションAとBが、ユーザー2のブラウザからBとCとDが使えるようになる。
ユーザーはいつでもどこでも必要なアプリケーションが利用できるようになるのだ。もちろんプラットフォームに自社システムを乗せることも、システム間連携開発を行うことも可能だ。

SPaaS サービスのメリットは運用が開始されてからさらに発揮される。
下図は一般的にアプリケーションの導入と運用に必要な業務である。
環境構築とシステム運用保守(ユーザー管理や障害対応など)、教育、ユーザーサポート(ヘルプデスク)などアプリケーション導入後はやるべきことが山のようにある。

しかし SPaaS サービスは、使用するすべてのアプリケーションに対してこれらを1つのユーザー専用ポータルから提供しているのだ。
もちろん、管理者専用ポータルではシステム管理者が気になるアプリケーションライセンス使用状況(ライセンスが足りているか、多過ぎないかなど)や利用場所履歴(なりすまし対応など)をいつでも確認できるようになっている。

もう1つ運用時に大きな問題になるのが、アプリケーションのバージョンアップである。アプリケーションベンダーが提供する SaaS はアプリケーションのバージョンアップがあった場合、プロジェクトの途中であっても強制的にバージョンアップされてしまう。この場合、プロジェクトのレポーティング(発注者側にする報告)やシステムパフォーマンス、連携しているシステムへの影響が懸念される。このような懸念に対し SaaS ではなくオンプレミスや IaaS、PaaS にしてアプリケーション製品管理は自社でという結論になる企業も多いようだ。

実は SPaaS サービスは、このようなケースにもっとも強い。
1つのアプリケーションに対し、複数のバージョンを持ち、ユーザーごとにバージョンを変えることが可能だ。
よってプロジェクトの途中で強制的にバージョンアップされることもなく、自社で対応する必要もないのである。
まさに IaaS でもない、PaaS でもない SaaS でもない SPaaS は第四の次世代クラウドの考え方である。

では SPaaS サービスの例を紹介したいと思う。
今回は弊社のプロジェクト用 SPaaS サービス「PROJECT CLOUD™」の例で紹介する。

下図はブラウザからユーザが PROJECT CLOUD™ にログインして工程管理アプリケーション Oracle Primavera P6 とコスト管理アプリケーション ARES PRISM を使用している例である。弊社への手続きはアプリケーション名と使用したいバージョンを申請するだけである(注:ライセンス自体は取り扱っていないアプリケーションもあるので要確認)。

アプリケーションにもよるが、申請後一週間もあれば各ユーザーのブラウザから申請したアプリケーションの(指定したバージョンの)アイコンが画面左に表示される。アイコンをクリックするとアプリケーションが立ち上がり、すぐに使用できる。

PROJECT CLOUD™ はプロジェクトで使用する以下の5カテゴリに対するアプリケーションを、200種類以上用意している。

 ● アセット管理&トラッキング
 ● CAD/BIM
 ● コスト管理/見積
 ● GEO 地理空間情報
 ● プロジェクト管理/契約管理

例えば、有名なアプリケーションとして AutoCAD、ARES PRISM、Oracle Primavera、Microsoft 関連のアプリケーションを PROJECT CLOUD™ に申し込んだ場合、一週間程度で各ユーザーのブラウザにアイコンが表示され使用できるようになる。

また、上図のとおりサポートページも用意されており、申し込んだすべてのアプリケーションに対してサポートが受けられるようになっている。問い合わせ先が一元化されているので、ユーザーはアプリケーションごとに違うベンダーへ問い合わせする必要がなくなる。
企業によっては、社内システムサポート部門を用意しているところもあるが、プロジェクトに特化した専門スキルが必要なアプリケーションのサポートは難しいため、これらのサポートが1ヶ所から提供されることは、とても効果的である。

さらに、PROJECT CLOUD™ ではユーザーは画面でトレーニングをしながらアプリケーションの操作を覚えることができる(動画コンテンツ作成は別サービス)。
下図は、工程管理のアプリケーション Oracle Primavera P6 の操作トレーニング動画を使用している例である。
ユーザーは Oracle Primavera P6 を使って工程作成する手順、進捗更新する手順などがわかるようになっている。

ここまでは、ユーザー側のイメージで紹介してきたが SPaaS サービスである PROJECT CLOUD™ はシステム管理者にもメリットがある。
下図はシステム管理者専用ページである。使用されているアプリケーションの使用状況を表示している。これにより、ライセンスが不足していないか、また過剰にライセンス契約していないかを確認でき、ライセンス違反対策や適正ライセンス数の検討ができるようになる。

また、下図は利用場所履歴となっており、なりすまし対策等どこでアプリケーションが利用されているかが確認できるようになっている。

そのほか、アプリケーション別利用者状況やストレージ、サポート・ステータス(重要度別平均解決時間など)などシステム管理者が確認したいレポートが揃っている。

このように SPaaS サービスである PROJECT CLOUD™ は、いつでもどこでも必要なプロジェクト用アプリケーションが使用でき、システム管理者も管理用ポータル画面でいつでも必要な情報が揃い、アプリケーションの導入・管理時間や労力を大幅に縮小することができるサービスとなっている。

以上、今回は日々進化する通信環境において、新しいかたちのシステム提供(プロジェクト用)について話をしてきた。
企業では下図のように社内標準システムだけでなく、プロジェクトや業務でよく使用されるアプリケーションも企業としてまとめて運用・管理したいという動きがでてきている。併せて検討されるのが必要なときに必要な分の環境利用料だけ発生するクラウド環境の活用である。
今回紹介した IaaS、PaaS、SaaS でもない第四の次世代クラウドはそんな時代の流れにあったニーズにより考えられたものである。

企業として本当に必要なシステム環境が何か、いつでもどこでも利用できる状態にするにはどうしたらよいか。
進化する通信環境をうまく活用しシステム構築・運用・管理をしていくことが、経営やプロジェクトの意思決定を迅速化し、企業の力をあげていくに違いない。

この記事へのお問い合わせ 

関連リンク

PROJECT CLOUD™

PROJECT CLOUD™はプロジェクト管理業務を支援する『グローバル・パッケージシステム』をクラウド化し、「環境構築」「教育」「ユーザーサポート」「システム運用保守」をワンストップで提供するサービスです。
「PROJECT CLOUD™」詳細はこちら

Primavera P6 EPPM

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera P6 EPPM」詳細はこちら

ARES PRISM

ARES PRISMは、世界で250社5,000以上のユーザーに活用されている、次世代型プロジェクトコストマネジメント統合製品です。
Cost Managementを中核に捉え、Estimating、Engineering、Procurement、Contracts、Constructionの各システムを必要に応じて組み合わせることでプロジェクトのコスト管理/パフォーマンス管理に最適化できる製品となっています。
「ARES PRISM」詳細はこちら

カテゴリ:プロジェクトマネジメント

2022/02/10

【9】企業としてのプロジェクト管理の仕組み作り(7) ~リソース稼働管理編~

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

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

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

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

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

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

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

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

① リソース情報の登録
  ここではリソースの属性、分類情報を登録する。
  リソース情報の属性や分類として、以下のような項目が想定される。
  <属性項目>
  リソースID(社員番号など)、リソース名、1日の投入制限量、役割など
  <分類項目>
  部署、雇用カテゴリなど

② 要員計画の確認
  ここでは、中期経営計画、期首計画の要員計画を確認する。
  中期経営計画、期首計画の要員計画にて要員のキャパシティが決められるため、企業リソース最適化の制約
  条件となる。

③ プロジェクト要求確認
  ここでは、プロジェクトからのリソース要求を確認する。
  プロジェクトからのリソース要求はリソース最適化の調整対象となる。

④ 要員稼働計画の確認
  ここでは、要員稼働計画を確認する。
  要員稼働計画はリソース最適化のベースとなる。

⑤ 分析、調整
  ここでは、① ~ ④ の登録/確認情報とプロジェクト・ポートフォリオにて分析したプロジェクト優先度を
  もとに分析、調整を行う。

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

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

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

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

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

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

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

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

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

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

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

この記事へのお問い合わせ 

関連リンク

Primavera P6 EPPM

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera P6 EPPM」詳細はこちら

カテゴリ:プロジェクトマネジメント

2022/02/10

【8】企業としてのプロジェクト管理の仕組み作り(6) ~プロジェクトKPI分析~

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

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

そこでいま注目を集めているのが、企業としてプロジェクト分析方法を考えて行く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分析を検討してみてはいかがであろうか。

この記事へのお問い合わせ 

関連リンク

プロジェクトマネジメント
ソリューション

組織レベルでプロジェクトマネジメントに取り組む「EPM(エンタープライズ・プロジェクトマネジメント)」の考えをベースに、 企業収益のさらなる向上を目指すお客様を支援するソリューションをご用意しております。
「プロジェクトマネジメントソリューション詳細はこちら

カテゴリ:プロジェクトマネジメント

2022/02/10

【7】企業としてのプロジェクト管理の仕組み作り(5) ~工程管理編~

最近よくプロジェクトを有する大手企業が米国プロジェクトマネジメント協会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®資格が企業に注目されているのであろう。

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

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

この記事へのお問い合わせ 

関連リンク

Primavera ファミリー概要

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera ファミリー概要」詳細はこちら

Primavera P6 EPPM

世界164ヶ国、75,000社以上で導入されているプロジェクトマネジメント・システムです。 建設・エンジニアリング・設備保全・製品開発・研究開発・通信・システム開発などの業界から、 その実力が高く評価されています。
「Primavera P6 EPPM」詳細はこちら

カテゴリ:プロジェクトマネジメント