Column

コラム

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

2022/03/03

【16】企業をまたがるプロジェクト決裁の仕組み作り ~プロジェクトワークフロー~

プロジェクトではオーナー、コントラクター、ベンダーなど様々な企業とドキュメントなどのやりとりやコミュニケーションを行う。特に近年では複数社でプロジェクトを契約する JV(ジョイントベンチャー)やコンソーシアムなどのケースが増えてきており、プロジェクト関係者は多数の企業をまたがってプロジェクトを進めていくことが多くなっている。

column_it16_01.jpg

このようなプロジェクトでは、企業間でいろいろな決裁処理が発生する。しかし、これらの決裁処理はあまりシステム化されていないケースが多いようだ。

社内による照査・承認などの社内決裁については、ワークフローシステムを構築し、システムによる決裁を行っている企業があると思うが、企業間をまたがるプロジェクトの決裁では自社で使用しているワークフローシステムを活用するのが難しく、またプロジェクト期間中だけ必要となるためプロジェクトワークフローシステムを検討するプロジェクトが少ないようだ。

column_it16_02.jpg

しかし、ビル建設内装のデザインなど実際に他社のプロジェクト関係者と合意を取りながら進めるケースは多数発生する。

これらの合意をメールでやりとりした場合、誰で決裁が止まっているのか、決裁がいつになったら終わるのかを追跡していくのは大変な作業になる。

下図はプロジェクトワークフローの例である。

社内承認(1次決裁)後にコンサルタント会社へ決裁依頼(2次決裁)が届き、承認後にオーナーへ決裁依頼(3次決裁)が届く仕組みとなっている。
それぞれの決裁を決裁ステップと呼んでおり、各決裁ステップに決裁期限を設けることにより、いつまでに決裁を完了させる必要があるかを明確にしている。

このように決裁ステップと決裁期限を明確にして管理することにより、数あるプロジェクト関係者間の決裁をスムーズに行おうという考え方になる。

column_it16_03.jpg

ただし、この考え方に対しシステムを活用せずメールなどの履歴で管理すると非常に時間と労力がかかる。また離れた拠点間での決裁ルートが発生するため、手軽にアクセスし管理ができる仕組みが必要となる。

column_it16_04.jpg

最近はこのようなケースで、プロジェクトワークフロー機能を持ったクラウドのドキュメント共有システムが活用されることが多くなってきている。

では、プロジェクトの決裁でシステムを活用する例を説明していこう。今回はプロジェクトワークフロー機能を持つドキュメント共有システム Oracle Aconexを使って紹介する。

下図はAconexのワークフロー設定画面である。Aconexの場合ワークフローの設定はマウスで手軽にできるので、専門的なスキルを持っていなくても以下の手順で設定できる。

①決裁ステップの追加と名前の登録(決裁者の数分を追加する)

②各決裁の期限を設定

③ステップ完了ルール(1ステップに複数承認者がいる場合)などの設定

column_it16_05.jpg

column_it16_06.jpg

この設定例では、

column_it16_07.jpg

2日間以内に「Architect Review(社内決裁を想定)」に決裁をしてもらい、
承認後5日間以内に「Consultant Review(社外決裁を想定)」に決裁をしてもらい、
承認後2日間以内に「Owner Review(社外決裁を想定)」に決裁をしてもらう内容になっている。

またステップ内に分岐がある場合は、分岐全員の決裁を完了したら次のステップに進む設定にしている。

設定が完了したら作成したワークフローで(ドキュメントなどの)決裁処理を始める。
下図はワークフロー設定後にドキュメントの決裁を回してみた結果である。
「Architect Review(社内決裁を想定)」は完了になっており、現在「Consultant Review(社外決裁を想定)」 中(期限:2018年8月17日)となっている。
これにより、ドキュメントの決裁が現在どこでされているかがわかり、決裁依頼は決裁者にメールで通知される。
また、それぞれの決裁者は別画面で決裁依頼一覧(未決裁の確認など)も確認できるようになっている。

column_it16_08.jpg

これらの決裁はクラウド上で行われるため、プロジェクト関係者が複数の国にわたっていても、インターネットでプロジェクトワークフローにアクセスできるようになっている。

column_it16_09.jpg

以上のようにプロジェクトワークフローのシステムを上手に活用すると、プロジェクトで発生する決裁状況の追跡や決裁依頼の確認に大きな効果が得られる。

また、このようなワークフロー機能を有したドキュメント共有システムは、他にもプロジェクト関係者でドキュメント共有をする機能やコレポン機能なども必要に応じて持たせることができるようになっており、プロジェクト用のドキュメント管理・共有にとても適している。

さて、今回「企業をまたがるプロジェクト決裁の仕組み作り」というテーマで企業をまたがったプロジェクトの決裁ワークフローの仕組みについて述べてきた。
通信の発展により増えていくグローバルプロジェクト、プロジェクトの関係者は国を越え、企業を越え、複雑なコミュニケーションルートをいかに管理するかが重要となっている。
みなさんもシステムを活用したプロジェクトワークフローの仕組みを作って効率良くプロジェクトの決裁をしてみてはいかがであろうか。

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

関連リンク

Aconex

Aconexは、世界で最も広く使われているプロジェクトコラボレーション・プラットフォームです。 複数の企業や組織を跨るドキュメント管理・プロセス管理・情報フローのコラボレーション実現のため、リアルタイムのプロジェクト・マネジメント・ソリューションを提供しています。
「Aconex」詳細はこちら

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

2022/02/24

【15】工程管理ツールは企業で使うと効果的(3)

【第13回】【第14回】と2回に渡り「工程管理ツールは企業で使うと効果的」をテーマに、企業全体で活用することを想定した工程管理ツールの特徴として「グローバルコードなどの定義の標準化設定」「スケジュールシミュレーション」などを説明してきた。
今回はこのテーマの3回目として「一括変換を活用したスケジュールの見直し」について話をしたいと思う。

プロジェクトスケジュールを管理する場合、年単位にわたる大規模プロジェクトはもちろん、組立製造のような中小プロジェクトが多数ある場合でも総アクティビティ(タスク)数は数千や数万以上になるようなケースもある。
このような場合にとても苦労するのが、スケジュールの見直しや修正である。

例えば、契約締結遅れなど何かしらの理由によりプロジェクト開始が予定より遅くなるにも関わらず、工期を変えられない状態になってしまった場合にスケジュールをどう調整するか。いろいろなケースを想定してスケジュールを修正したいが、数千・数万のアクティビティを1アクティビティずつ見直して修正するのは至難のわざである。

このようなとき、全体の工期を数%短縮してみたら、マンパワーを増やしてみたらスケジュールは納期内に納まるか、影響はどうかなど検証してみたくはないだろうか。

下図は説明用にプロジェクト工期を500日間にしたサンプルである。
プロジェクト開始が100日遅くなり、かつ納期が変わらないという条件になってしまった場合、100日間短縮したスケジュールを作成する必要がでてくる。下図のサンプルは5アクティビティしかないが、実際に数千以上のアクティビティがあった場合は、1アクティビティずつ調整したらとてつもない時間を要することになる。

このような場合、工程管理ツールでは「一括変換」というものがある。
上図で工期を100日短縮するためには、ひとつの例として500日×0.8=400日つまり現工期を全体的に20%短縮(0.8倍)すれば、下図のように400日で完成させるスケジュールができる。
工程管理ツールの「一括変換」を活用すると、条件式を記入することにより「すべてのアクティビティ」に対し「アクティビティ期間を0.8倍」するという計算をさせることが可能だ。管理するアクティビティ数が総合で数千や数万になる場合は、一度に条件式に従い一括変換されるため、スケジュールを作成する際にはとても効果的である。

また、一括変換は計算結果を確定する前にどのアクティビティ期間が何日から
何日へ変更されたか確認できるレポートが表示されるため、レポートを確認してから確定するか変換前に戻すかを決めることができる。
【第14回】で説明したシミュレーションをあわせて活用すれば、結果が想定外の場合は削除するだけで良いので、さらに確実に活用できる。

では、実際の工程管理ツールの画面例を紹介したいと思う。
今回も企業で活用できる工程管理ツールとして Oracle Primavera P6 の例で説明する。
Oracle Primavera P6 ではグローバル・チェンジという「一括変換」を持っており、下図はグローバル・チェンジの設定画面である。

設定画面は3つに分かれており、① が対象とするアクティビティの絞り込み条件、② が変換する項目とその条件(数式など)、③ が ① で対象外となったアクティビティの変換項目とその条件である(① は記入がなければ全アクティビティ対象、③ は記入がなければ変更なし)。

※いわゆる① if~、② then~、③ else~ の条件である。

上図では、① マイルストン以外(タスク)のアクティビティに対して、② アクティビティ当初期間(計画期間)を現在設定の当初期間×0.8倍にする、③ マイルストンは変更なしと設定している。
設定が完了したあと画面上の変更ボタンをクリックすると一括変換の結果が表示される。

下図はグローバル・チェンジ(一括変換)の結果レポートである。アクティビティIDと変換項目(フィールド)、既存値(変換前の値)、新規値(変換後の値)が表示されている。
たとえば、EC1000アクティビティは期間が41日から33日(少数第一位四捨五入)に変換されているのがわかる。
このレポートを確認しデータに反映させる場合は「変更の確定」ボタンを、変換前に戻す場合は「変更の取り消し」ボタンをクリックする。

「変更の確定」ボタンをクリックした場合は、スケジュール画面に反映される。
下図はスケジュール期間変更前と変更後である。すべてのアクティビティの当初期間が20% 短縮されているのがわかる。

グローバル・チェンジの使い方に慣れてくると、いろいろな一括変換を考えるようになる。
下図では 1.期間10% 短縮 のグローバル・チェンジと 2.工数10% アップ のグローバル・チェンジを設定している。
この設定の組み合わせは次のようなケースを想定している。

1.プロジェクトが予定より遅れており、キャッチアップのためのスケジュール見直しをするため、まだ完了していない(未開始と進行中)10日以上期間が残っているアクティビティに対し、期間を10% 短縮する。
2.期間を短縮するための策として対象リソースの工数を10% アップとする。

では 1.と 2.それぞれの設定の中身について説明していこう。

まず 1.期間10% 短縮 の設定は下図のとおりとなっている。
① の条件が「完了していない(未開始と進行中)、かつ残期間が10日以上のアクティビティ」、② の条件が「対象アクティビティの残期間を現在の0.9倍(10% 短縮)」、③ の条件なしとしている。
この設定により、プロジェクトのまだ完了していない部分のインパクトが高い(10日以上)のアクティビティ期間を10% 短縮することになる。

次に 2.工数10% アップ の設定は下図のとおりとなっている。
① の条件が「Laborer-Constructionリソース」、② の条件として「対象リソースの残工数を現在の1.1倍(10% アップ)」、③ の条件なしとしている。 この設定により、これから投入される Laborer-Constructionリソースの工数は10% アップすることになる。

これら 1.期間10% 短縮 と 2.工数10% アップ のグローバル・チェンジを組み合わせることにより、遅れているプロジェクトの Laborer工数を+10% かけて全体期間を10% 短縮した見直しスケジュールが完成する(もちろん詳細な調整などは必要)。
これはマンパワーをかけてキャッチアップするクラッシングの考え方を工程管理ツールで実現したものである。

ここまで、工程管理ツールの一括変換を活用して、スケジュール遅れをキャッチアップする例を紹介してきたが、これに【第13回】の定義の標準化設定や【第14回】のスケジュールのシミュレーションをあわせることで、さらに効果的に活用できる。

例えば、下図のようにグローバル・チェンジ(一括変換)のパターンを企業ナレッジとして蓄積し、全ユーザーへ標準提供することで定義の標準化が実現する。
スケジュール担当者は企業ノウハウとして提供されたグローバル・チェンジと、スケジュールのシミュレーションにより複数の工期短縮パターンを比較しながらスケジュールを作成することができるのである。

さて、今回「工程管理ツールは企業で使うと効果的(3)」というテーマで、企業全体で活用する工程管理ツールの「一括変換を活用したスケジュールの見直し」として工期短縮の例を紹介してきた。
工程管理ツールを始めとしたプロジェクト管理システムへの期待は、企業型への対応、JV(ジョイントベンチャー)など複数社の共同プロジェクトへの対応など時代と共に大きく変化している。

ただし、これらには企業としてのプロジェクト管理の考え方が必要なことを忘れてはならない。考え方とシステム(もちろん人材育成も)が組み合わさることにより、企業としてのプロジェクト管理の仕組みができあがる。

企業としてのプロジェクト管理仕組みをしっかり構築することにより強い企業が生まれるであろう。

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

関連リンク

Primavera ファミリー概要

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

Primavera P6 EPPM

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

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

2022/02/24

【14】工程管理ツールは企業で使うと効果的(2)

前回、工程管理ツールは企業で使うと効果的(1) として、企業全体で活用することを想定した工程管理ツールのコンセプトや特徴について明記した。
今回も引き続き、コンセプトや特徴を説明していきたいと思う。

前回は「企業の役割別に集計やセキュリティ管理をするための特徴」「企業で統一して管理をするための特徴」の2つの特徴をあげて説明したので、今回は企業全体で工程管理ツールを使う時の「スケジュール作成のための特徴」として例をあげていきたい。

プロジェクトのスケジュールを作成する時、何回も作り変えたり作り直したりすることが多いと思う。また、大規模プロジェクトでは各関係者に作成してもらい、それを確認し修正版を再び受け取るなど、スケジュール作成は1回ですぐに完成とはいかないのではないだろうか。

これは工程管理ツールを使っても同じで、会社のサーバーへアップすると他プロジェクトの工数への影響があったり、各関係者からの計画を統合したりすると即座に全体への影響が出てしまうため、未確定版スケジュールをいくつも別プロジェクトやファイルとして作成するような運用でカバーするケースが多くなる。

実は企業全体で活用することを想定した工程管理ツールでは、他プロジェクトへの影響が無いようなシミュレーション用プロジェクトという考え方を持っている。
下図はマスタースケジュールに対し、ABC 3カ所の部隊やベンダーから詳細スケジュールを集めたものである。

詳細Bのスケジュールを見ると、マスタースケジュールのマイルストン日付を越えている状態になっており、

このままスケジュール計算をするとマスタースケジュールへの影響が出るため、事前に何回かシミュレーションを行い確定スケジュールを作成した時点で全体に反映したくなる。
こうしたシミュレーションを実現できるのが工程管理ツールが持っているプロジェクトのミラー化というものである。

下図はプロジェクトをシミュレーション用にミラー化したイメージである。
プロジェクトをミラー化するとシミュレーション用プロジェクトが別途作成される。このシミュレーション用プロジェクトは、全体工数やコストへの集計対象にならない他のプロジェクトにも全く影響が出ないものなので自由に編集・更新ができる。
ミラーは複数作成できるため、いくつかのスケジュールパターンを作成し、納得のいくスケジュールを最終的に反映させる使い方が多いようだ。もちろん必要なくなったミラープロジェクトは削除すれば良いだけである。

では、実際の工程管理ツールの画面例を紹介したいと思う。
今回も企業で活用できる工程管理ツールとして Oracle Primavera P6 の例で説明する。
下図はプロジェクトをミラー化する画面である。
XYZプロジェクトのマスタースケジュールのミラーを作成しようとしている。

「ミラーを作成」をクリックするとマスタースケジュールの下に、マスタースケジュール Reflection というミラーができあがる。これをシミュレーションパターンの数だけ作成していく。シミュレーションはそれぞれのスケジュールでも、パターンごとにまとめたスケジュールでも確認・編集ができるようになっている。

また、ミラーのスケジュールには上図のように「?」マークがついており、これらはシミュレーション用で工数やコストなどが全体(他のプロジェクトなど)に反映されないようになっている。
これにより他に登録されているプロジェクトへの影響もなく、シミュレーションを元に採用したいスケジュール案を計画できるのである。

もちろん「?」マークがついているミラーのスケジュールでも、下図のようにガントチャートが表示され、通常のスケジュール同様のイメージで同様の操作ができるようになっている。

次に編集・更新したミラーのスケジュールを反映させてみたいと思う。
下図は編集・修正したミラーを統合する画面である。対象のスケジュールを選択し「ミラーをソース・プロジェクトに統合」をクリックすると統合画面に移動する。

統合画面では、元となるスケジュール(ソース・プロジェクト)との差異が表示され、それぞれの項目を統合して良いかが確認できる。また、部分的に統合したい場合も対象部分だけチェックを入れれば、部分的に元スケジュールへ更新がかかるようになっている。
下図の例では、元となるスケジュールに更新(差異)があったアクティビティが更新項目・内容と共に確認でき、必要な更新部分をチェックで選択するようになっている。

このようにミラー作成、修正・更新、元スケジュールへの統合を行うことにより、スケジュール更新をいくつかのパターンでシミュレーションしながら、スケジュールを計画できるようになる。

さて、今回「工程管理ツールは企業で使うと効果的(2)」というテーマで、企業全体で工程管理ツールを使う時の「スケジュール作成のための特徴」の例としてスケジュールのシミュレーションについて説明してきた。
近年、企業としてのプロジェクト管理の仕組み作りを検討・導入する企業が増えてきている今、プロジェクト情報のサマリー集計やプロジェクト間の要員調整などに正確な情報集計が求められることになる。
工程管理ツールも企業全体で使用できるように進化してきている。ぜひ企業で活用してみてはいかがであろうか。

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

関連リンク

Primavera ファミリー概要

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

Primavera P6 EPPM

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

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

2022/02/24

【13】工程管理ツールは企業で使うと効果的(1)

ITの活用が当たり前になってきている現代、プロジェクトではITを活用したさまざまな管理ツールが使われるようになっている。プロジェクトの工程(スケジュール)管理にも、いくつものITツールが販売されており、活用されている。 しかし、工程管理ツールにはプロジェクトのみに使うツール以外に、企業全体で使うことを想定しているものがあることはご存じだろうか。

これは企業としてプロジェクト管理方法をどう考えるか、企業内やプロジェクト関係者間でどのように情報を可視化していくかなど属人的なプロジェクト管理から脱却し、管理手法やツール(システム)を統一する動きが出ているからである。

では、企業全体で活用することを想定した工程管理ツールとはどのようなコンセプトで作られているのか?
ここでは「企業の役割別に集計やセキュリティ管理をするための特徴」「企業で統一して管理をするための特徴」の2つの特徴で説明したいと思う。

最初に「企業の役割別に集計やセキュリティ管理をするための特徴」について説明する。
下図は企業で使うことを想定している工程管理ツールのプロジェクト管理構造である。

まず、プロジェクトの上に階層があることに注目してほしい。企業でプロジェクト管理の仕組みを考える場合、事業ドメイン別に(事業ドメイン=組織の場合もあり)情報を収集する必要も出てくる。
このためプロジェクトの上位に事業ドメイン階層が作られており、関係プロジェクトの情報をサマリーレベルで集計できるようになっている。

もちろん集計値を確認する範囲や権限など、どの部署の誰にどのような役割で管理権限を与えるかはとても重要なものとなってくる。

下図は工程管理ツールが持つ EPS・プロジェクト・WBS・アクティビティに対しアクセス管理や各種コードなど、どのような属性項目が関連するかの相関図である。
この相関図の赤点線枠が管理権限に関する部分となり、OBS(Organization Breakdown Structure)で主管組織と役割を定義し、組織別・役割別に EPS・プロジェクト・WBS まで管理範囲が設定できるようになっている。また、役割別に編集や閲覧などの権限を持たせる設定もある。
これらを活用することにより、企業内それぞれの役割別の視点でプロジェクト・プログラム・ポートフォリオ管理を実現することができるようになる。

では例をあげて説明しよう。例えばアクティビティコードに関しては定義が以下のとおり3つの単位に分かれている。

[グローバル(企業)単位]
全ユーザーが共通で使用可能なコードであり、事前にツールに登録しておけば各ユーザーは企業標準コードとしてすぐに活用できる。

[EPS(事業)単位]
対象事業に関わるユーザーが使用可能なコードであり、事前にツールに登録しておけば対象事業のユーザーは事業標準コードとしてすぐに活用できる。

[プロジェクト単位]
プロジェクトで独自に設定するコードであり、グローバル単位や EPS 単位に用意されていないプロジェクト独自のコードを定義したい場合に活用する。

以上のようにグローバルや EPS 単位にアクティビティコードを持たせることにより、企業標準のアクティビティコードを活用するようになり、企業で統一した視点で工程管理をすることが可能となるのである。

今まで企業で活用するための工程管理ツールの管理構造や特徴について説明してきた。
ここからは、実際の工程管理ツールの画面例を紹介したいと思う。
今回は企業で活用できる工程管理ツールとして Oracle Primavera P6 の例で説明する。

下図は「企業の役割別に集計やセキュリティ管理をするための特徴」で説明した管理構造の EPS とプロジェクトを登録した例である。
ここでは、EPS を全社 - 事業 - 事業拠点(海外or国内)- プログラムで階層化し、その下にプロジェクトが登録されている。

※EPS にプロジェクト名が入っている部分もあるが、大規模プロジェクトをサブプロジェクトに分け管理することを想定し、EPS にプロジェクト名を入れ複数のサブプロジェクト管理をするケースもある。

これらを登録することにより、プロジェクトだけでなく事業単位、事業拠点単位、プログラム単位でも進捗・工数・コスト状況を分析できるようになり、組織視点で事業の意思決定材料を集めることができるようになる。

下図は実際にプロジェクトの進捗・工数・コスト管理状況が各 EPS にボトムアップ集計されている分析画面である。
赤枠部分の「石油化学プラント事業」を見ると、配下のプロジェクト情報が集計され、事業当初計画の予算(BAC)
約172億円に対し、完成時予想コスト(EAC)が約176億円となっている。
また、SPI が0.91(<1)であることからこの事業は予定より若干進みが遅いこともわかる。
このように工程管理ツールから事業状況までもが分析できるのである。

次に「企業で統一して管理をするための特徴」の1つであるアクティビティコードの定義画面を紹介したいと思う。

下図は Oracle Primavera P6 のアクティビティコード定義画面である。赤枠内を見るとグローバル・EPS・プロジェクトと3つ選択できるようになっており、それぞれグローバル(企業単位)の標準アクティビティコード、EPS(事業単位)の標準アクティビティコード、プロジェクト独自のアクティビティコードが登録できる(それぞれに登録できるコード数は無制限)。
これらをうまく活用することにより、企業で統一してプロジェクト管理を行う仕組みの1つが実現できるようになるのである。

ここまで、工程管理ツールの具体的なイメージを紹介してきたが、企業全体で工程管理ツールを活用するためには、企業として管理構造・体系をどうするかなどを決めていく必要があることを忘れてはならない。

自社内で管理構造・体系を検討するのも良いが、ツールの構造に詳しい人間も必要となるため、各社のワークショップサービスを活用するケースも多いようだ。

弊社でも Oracle Primavera P6 といったツールの構造を説明しながら、お客様と管理構造・体系を決めていくワークショップサービス(EPM ソリューションサービス)を提供している。

さて今回、「工程管理ツールは企業で使うと効果的(1)」という題で企業全体で活用することを想定した工程管理ツールの特徴を説明してきた。
属人的なプロジェクト管理から脱却し、企業としてのプロジェクト管理の仕組み作りを検討・実施する企業が増えている今、工程管理ツールも時代の背景に合わせて進化している。みなさんも企業全体での工程管理ツールを活用を検討してみてはいかがであろうか。

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

関連リンク

Primavera ファミリー概要

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

Primavera P6 EPPM

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

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

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

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

2022/02/18

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

前回、製造業におけるプロジェクト管理の仕組み作りとして個別受注生産について述べたが、今回は量産の話をしたいと思う。

量産というとプロジェクトという言葉から遠い感じがするが、近年では鉄道車両や航空機など中型(車などより大きく、船などより小さい)の生産にプロジェクト管理の要素を取り入れる傾向が出てきている。

それは鉄道車両や航空機など中型の生産は組立工程がそれなりに長いため、見込生産から計画生産に変更するところが増えてきているからだ。

たしかに計画生産にすると、仕掛の削減や全体のリードタイム短縮が期待できる。しかし、計画が正しくないと必要部品未入荷により組立作業員の待ちが続いたり、組立時の要員不足で作業の進みが悪くなったりする。

このようなことから、大日程・中日程に関して製造型番をプロジェクトとして捉え、全型番の工程とリソースを踏まえて計画・調整していくプログラム(プロジェクト)管理の考え方が取り入れられてきている。

では、どのように実現性のある最適な大日程・中日程を計画していくか述べていきたいと思う。

下図は大日程と中日程において工程計画で主に考慮しなくてはいけない項目をあげている。

大日程計画ではリソースキャパシティを考慮して実現性のある工程計画をする。
中日程ではリソースの制約の他に、組立設備の制約が入ってくる。組立作業は同じ作業を複数の製造番号で順に行っていくため、場所が空いていないと次の番号の組立を始めることができない。よって設備を考慮した工程計画・計画更新を以下に早く正しくできるかが組立中日程の工程計画のポイントになってくる。

次に組立中日程の組立設備の制約とリソース制約について図で説明していきたいと思う。

下図は組立中日程の例である。型A001を製造番号ごとに組立対象となる設備番号ごとに示している。下には組立員種類の負荷状況とキャパシティを示している。工程は同じ設備が同時期に重ならないよう、また組立員の状況を確認しながら計画や更新をする必要がある。

例えば、製造番号30815 の Z001 の組立日程が変更もしくは遅れた場合、下図のとおり 30816 は Z001 の組立ができなくなる。そのため 30816 と 30817 の工程をすぐに変更しなくてはいけない。また工程を変更することによりリソース(組立要員)のローディングも変わるので、要員調整などのため一緒に確認する必要も出てくる。

これらの考え方はシステムを活用しないと相当な手間がかかる。
ここからはプロジェクト管理システム(工程管理)を使った例を紹介したいと思う。

今回はプロジェクト工程管理システムの Oracle Primavera P6 の例で紹介する。
下図は製造番号30015工程 の Z001 の終了日が変更(遅く)なった例である。変更後の状況を確認後、スケジュールボタンを押すとすべての製造番号に対し設備を考慮して工程が自動調整される。あわせて工程更新後の要員ローディングも確認できる(ローディング負荷による工程調整もできる)。
このようにプロジェクト管理システムを使うことで即座に設備とリソースに配慮した工程作成が可能になる。

ここまで組立中日程の組立設備の制約とリソース制約を考慮した工程作成について話をしてきた。大日程もリソース制約も中日程のリソース制約同様にシステムで工程作成できる。これにより組立中日程までの工程計画・更新の仕組みができあがる。

ここからは、部品と組立中日程の日程調整について説明していく。

組立中日程がきちんと計画できても、各設備で組み立てるための部品が完了していないと組立が始められなくなってしまう。よって、部品中日程と組立中日程の日程のずれを確認できる仕組みを作り、日程調整する。

下図は組立中日程の作業開始に対し、部品がいつ完了予定かを表現している。Z002 の組立開始よりも2日後に部品が揃うことになり、調整が必要となることがわかる。
このように、どの組立作業に部品完了予定とのずれが生じているかをシステムを使ってすぐに確認する必要がある。
そのためには、部品中日程のシステムと組立中日程のシステムをつなぎ、いつでもそれぞれの日程を確認できるシステム構築を行う。

では、システムの例を紹介したいと思う。
下図は部品中日程でよく適用される MRP システムとプロジェクト工程管理システム Oracle Primavera P6 をつないだ例である。組立中日程側から部品完了予定が分かるようになっており、組立開始と部品完了予定までにどのくらいのずれがあるかが分かるようになっている。これによりすぐに調整に入ることができ、部品工程・組立工程・設備・要員すべてが加味された実現性のある中日程計画がいつでも可能となる。

さて、中型製造の計画生産におけるプロジェクト管理を取り入れた大・中日程の仕組み作りについて紹介してきた。
実際にはこの他にも下図のように小日程システム(MES や生産スケジューラーなど)との連携や BOM、手配システムとの連携、経営/組織/現場それぞれにおける BI を活用した KPI 分析なども仕組み作りの中には含まれる。

さらに、現在では全工場のマスタープランを1つにして、製造実現性と最適化を最大限考えた「プロジェクト・マニュファクチャリング」という考えが普及し始めている。

以上、今回は製造業におけるプロジェクト管理の仕組み作り(2)として、中型製造の計画生産におけるプロジェクト管理を取り入れた大・中日程の仕組み作りについて紹介してきた。最後に明記したプロジェクト・マニュファクチャリングも含め、世界的に製造業の工程計画・リソース計画を連携し統合していく動きが広まってきている。

企業としてのプロジェクト管理の仕組み作り同様に、製造業においても企業として情報の可視化や統合、リソース全体最適化が注目されている。
みなさんも製造業における企業としてのプロジェクト管理の仕組み作りを検討してみてはいかがであろうか。

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

関連リンク

Primavera ファミリー概要

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

Primavera P6 EPPM

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

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