PDM誌上セミナー - 第三回:PDMの導入と現実


 PDMが日本で語られておよそ7年、多くの企業が導入を図り、およそ数年、本番に移行した企業も多く見うける。一方、PDMソフトウエアが社内で遊んでいる企業、投資をしてしまったものの本番に移行出来ない企業も見うけられる。今回はこの問題に触れてみたい。

 筆者がある企業のPDM勉強会に招かれた際の出来事である。そこで例によって、一般的なPDMの効果なりの話しを行なった訳だが、その後の当のPDM担当部長の弁はこうであった。『試験的に設計現場にPDMの効果評価のために導入を図った。しかし、誰も使おうとしない』。PDM担当側のよかれとして開発したシステムである。ところが現場ではそのシステムをさわったものの依然として使わない。何が原因なのだろうか?PDM担当者は『PDM』そのものに疑問を感じているのである。

動かないPDMシステム

 『PDM製品』はある程度の規模の企業ではすでに多く『購入』されていることと思う。その動機は、PDMの現場への具体的適用、PDMテクノロジーないし製品の実装テスト、技術者への教育など、様々であろう。結果は様々なメディア、各社のベンダーや弊社のPDMセミナー(1997年より毎年12月に開催)に報告されているように本番稼動に至っている。それらを成功事例として捉えるならば、弊社セミナーに於けるユーザー発表には以下の様な導入の際のコメントをあげている点:

  • PDMを推進する側は現場を理解している
  • PDM開発側とエンドユーザーのチームワーク
  • 設計のデータは後工程でも有効利用
  • 今までの手作業をきっぱりと止める勇気
  • 現場の人のため、そのためには泥臭さはまぬがれない
  • 全社を巻き込む、トップダウンで推進
  • PDMはあくまでツール
  • 自分達の必要なことが出来るツールの選択
  • カスタマイズの少ないシステム
  • 作り込みはしない。パッケージの実現可能な機能や不可能機能の認識
  • パッケージの位置付け・効果を明確に定める
  • パッケージに合わせる
  • 業務改革を定着させるための段取りや教育を徹底

 などなどキリがない。これらはPDM導入者の生の声である。

 一方、良い話ばかりではない。筆者らが現場で目にしたケースや、相談として持ち込まれたり、耳にする、『動かないシステム』もあるのである。それらの良くあるケースは下記のようなものがある:

  • 開発したものの現場が使わない。現場に余計な作業が増える。
  • プロト作成に終わってしまう。本番に移行しないのは何故必要か解らない(特に効果)
  • 本番使用でなかなか立ち上がらない。原因はPDMソフトウエアのバグの問題、パフォーマンスが悪いなど
  • 開発に金がかかりすぎる。カスタマイズが思った以上に多い。
  • PDMそのものに価値を見い出せない。今のレガシー(メインフレームベース)でも仕事は出きる
  • 実装したいPDM機能は自社でも開発可能。

 などなどである。おそらくそれらの企業は、業務分析に専門コンサルタントを入れたり、社内各部門との調整やミーティングに多くの時間を費やしたことと想像する。人件費などHidden Cost(見えないコスト)も含めて、おそらくPDM検討・評価とプロト作成に関する初期導入の部分の投資額でも数千万、ある種の企業では億に相当する金額と考える。それだけの努力にも関わらず、結果が出ないのは何故だろうか?これらは前回の『ニーズの明確化と投資効果の検証』に解説のように『裏書き』のないまま、プロジェクトが進行しているのである。『裏書き』はだれが作るのであろうか?それはPDMベンダーでもない、システムシステムインテグレータでもない。皆さん自身が責任を持ち、リスクを負うものなのである。また、技術的興味で評価をしてないだろうか?PDMはビジネス・ニーズとリンクして評価しなければ結果を得ることが出来ない。

ビジネス・アプレイザル

 そこで『動かないシステム』に陥らないための方法としての弊社が薦めるPDMビジネス・アプレイザルプログラムを紹介する。このプログラムはエンドユーザーのPDM担当者自ら、ビジネス・ニーズを明確にし、トップの管理者にPDM投資の確信を持たせ、現場においてPDMの利益や効果(すなわちアプレイザル)を得るための知識や実行の目標を持たせようとするものである。次の様なステップで構成される:

  1. PDMの教育とビジネス・ニーズの定義:社内のユーザーに受け入れのための興味を向上させることを推進させる。誰が使用するのか、どこで、何時、何の為に?ビジネス上のニーズの理由は?そしてその定義を行なう。
  2. 主要な利益や効果は何なのか?:どんな利益や効果を得たいのか?それらを明確化し、十分に理解し、その大きさを確認する。そして数(的)を絞る。
  3. 範囲とシステム&サプライヤの確認:2. から得られたもので最も重要な利益・効果に見合うシステムやサプライヤの検討を行なう。ツールは目的があって、開発され、成長している。また、サプライヤ(システムインテグレータ含む)も同様である。すなわち万能はないのである。
  4. 導入への戦略計画:そして重要である効果や利益を達成するための導入計画やシステム構成を組立てる。導入フェーズをマッピングし、それぞれのフェーズの範囲を定義する。それにはデータの確認が流れ、プロセスのチェック、初期システムのコスト計画(表1:PDMに関わる費用を参照)などが入る。
  5. コストと利益・効果の分析:これは提案するシステムの初期コストとその後に掛かるコストのついての投資効果を数値(金や項目)で正当化する。リーズナブルでアクセプト出来るものであること。これらには導入展開に於けるメトリクス(表2:メトリクス(評価基準)例を参照)を定めておくことが必要である。
  6. リポーティング:これは慎重に準備をすることはもちろんであり、事前に関係者の理解(所謂、根回し)を得て置くことは必要である。また、先延ばしをすることの損失も入れて置くことは重要なことである。

 以上のようなプロセスでPDM導入の目的、そして得るべき効果や利益を明確にして置き、コミットメントをしなかればならない。コミットメントとはリスクを負うものであるが、一方、それは目標を明確にしてあるので、それに見合わない場合、すなわち、メトリクスが達成出来ない場合、改修が出来ることである。所謂、早期発見、早期治療が可能なのである。結果的に『動かないPDMシステム』になることを未然に防ぐものとなる。

 上記の上手くいったケースは平たい話と受け止めるかも知れないが、それは現実であり、『動かないPDMシステム』の例にある点とは対照的なことを述べていることをよく理解いただきたい。また、導入の正攻法としては『PDMビジネス・アプレイザルプログラム』を考慮して置くことを進める。少なくとも、初期投資のリスクの多くが低減出来る筈である。

 『動かないPDMシステム』のケースで究極且つ最悪のケースは担当者が『ツールの責任にする』にすることである。これは最も簡単で古典的な責任逃れの方法である。問題はそこではなく、導入プロセスや担当者そのものにあるのである。最後に御参考のために表3の新技術導入などの戦略プロジェクトの問題の参照いただきたい。PDM固有の問題でないことは明らかであり、このような過去も経験を活かしたビジネス・アプレイザルプログラムでもある。

参考1:PDMに関わる費用(表1)

  • ソフトウエアの費用(データベース、保守も含む)
  • ハードウエア費用(サーバー、ネットワークも含む)
  • システムの選定、正当化、導入計画
  • トレーニング
  • 導入、デーたやプロセスのモデリングなど
  • 既存(レガシー)製品情報の取り込み
  • システム管理
  • システム・ベンチマーク

参考2:メトリクス(評価基準)例(表2)

  • 変更サイクルの期間や長さ
  • 変更の変更
  • 製造工程に回った後の変更回数
  • エラーに伴う変更回数
  • 変更に伴うコスト
  • データのアクセスの時間
  • 生産までのサイクルタイム
  • 新製品のタイム・ツー・マーケット
  • プロトタイプの作成時間
  • 部品点数
  • 標準部品や特殊部品の数
  • BOMの種類、数
  • 治具や工具の組立の越す値
  • スクラップ、在庫や再作業の率
  • 等など他

  (これらの重要度は各社により異なる)

参考3:戦略プロジェクトの問題(導入時発生しえる問題)(表3)

  • 71% => 導入が計画より時間がかかる
  • 69% => 予測しえない問題の発生
  • 62% => 導入のコーディネーションが効果的でない
  • 60% => 不慮のことに惑わされる/振り回される
  • 59% => 導入チームの知識不足
  • 58% => ユーザーへのトレーニングの不適切/不十分
  • 56% => プロジュクトに降り掛かる問題への対処が出来ない
  • 55% => 管理者のリーダーシップ/方向性の欠如
  • 52% => 主要な導入タスクの詳細さの欠如
  • 52% => プロジェクトのモニターシステムの不適切

  (ソース:Larry D. Alexander, 1985)

(江澤 智、2013.5.10 改)


本件についてのご意見はこちらからお送り下さい。

Your local time is  where you live.

© 1995-2015 MetaLinc K.K.