| 1． |
最初にエンジニアリング専業3社の業績推移の解説 |
| |
・ |
売上は1兆円超から4000億と波が大きい |
| |
・ |
一方利益は、伸びている
業務改革が進んでいることが伺え、体質強化されている
|
| 2． |
プラントプロジェクトのライフサイクルについて |
| |
・ |
顧客のプロジェクトライフサイクルとエンジニアリング会社のプロジェクトライフサイクルは自ずと異なる
顧客は、構想段階から始まるが、受託側は、見積作業はプロジェクトライフサイクルに含めず、受注後の設計業務からプロジェクトライフサイクルとなる
|
| 3． |
RFPについて
顧客から受注側に対し、RFPが提示され、受注側の見積作業が始まる |
| |
・ |
RFPが作られ受注側に提示され始めたころ初期は、RFPといっても5CM程度の厚さであった。最近では、同程度のプロジェクトのRFPがファイルで10冊はある
|
| 4． |
見積書について
見積書は、受注側にとって、発注側へ実現すること、遂行することをコミットするものである。一方、できないこと、やらないことを示すものでもある、出来るだけ詳細に記述した方が、プロジェクトの実行段階で有利になることが多い。あいまいな記述は、圧倒的に、受注側に不利な決着となる
|
| 5． |
SUMMIT Meetingの開催
社長クラス(発注側、受注側)が参加するSUMMIT Meetingは、最初から設置しておくべきである。
何か問題が起きてからでは、トラブルの責任となる側は開催したくないに決まっている
自分の上司も、わざわざ謝る会議は出たくない
平時でもエスカレーションする場は持っておく
|
| 6． |
調達コストを下げるための有利購買の推奨 |
| |
・ |
有利購買をするためには、まとめて発注することになる、これは一部見切り発車となることが多い |
| |
・ |
発注側のわがままで仕様が何度も変わることが多い、有利購買のため、如何に仕様を確定させるかが重要なミッションとなる
|
| 7． |
WBSの作成 |
| |
・ |
実績あるWBSの蓄積は、その会社の貴重な財産である |
| |
・ |
プロジェクトのタスクをWBSとして展開するが、WBSを作成、展開する前にプロジェクトリーダーはプロジェクト(仕事)の範囲を把握することが重要である |
| |
・ |
WBSは、不透明な段階で無理に深くすることはせず、明らかになった段階で順次深くすればよい |
| |
・ |
アクティビティの数は、200億円規模のプロジェクトで1000位が目安である
→ITプロジェクトの規模とは、桁が違うか
|
| 8． |
プロジェクトの大きさ
プロジェクトリーダーが、メンバーの名前を覚えられる規模(例100人程度)ならコントロール可能である
|
| 9． |
プロジェクト進捗の見える化 |
| |
・ |
一般的にITプロジェクトは進捗が見え難い |
| |
・ |
エンジニアリング業務の「見える化」は、3D-CADの普及で進んだ
物量の「見える化」、進捗の「見える化」、完成度の「見える化」]
→自動設計、BOM、自動積算、工事工数積算、EPM |
| |
・ |
見える化は、PDCAを可能とする
|
| 10． |
超上流工程の推進 |
| |
・ |
顧客はITベンダーに超上流工程を任せたいと考えている |
| |
・ |
一方、ITベンダー側には、顧客の業務が分かる人材が居ない |
