coffee brake
20～30年周期の重要な選定の前に
PLM/PDM/BOMなどの重要なITインフラ基盤再整備は20～30年間隔で発生すると言われています。選定を任された方は非常に大きな責任と同時に機会（チャンス）も手に入れたことになります。
大きな責任
PLMを根付かせ多くの効果を期待する一方で、失敗は許されない風潮があります。またその期間は長期に渡る為 大きな負担を感じることになります。
チャンス
多くの選任者が「大変な責任を負わされ、早く選定を終わらせたい」との感情を持っています。しかし、これは大きなチャンスです。自社の根幹を左右するPLMの選定に携わり、長期に渡ってそれらの舵取りなどにも寄与することができます。会社はあなたに多くの評価を惜しまないでしょう。
選定者は大きな問題を抱えます
社内業務を熟知しているが文書化されていない
担当者は 社内のルールや部門間の暗黙知など、他社では想像もつかないほどの複雑なルールを熟知しています。製造業のシステムは、PLMという概念や言葉が生まれる前から様々な仕組みやルールが存在し、それらを改善し、今に至っていることでしょう。この複雑なルールを熟知しているスーパーエンジニアはお客様の社内にしか存在致しません。しかし、それらのほとんど文書化されておらず、仕様に対する要求元も定かではありません。
製品知識、業界動向を熟知していない
PLMは概念的な要素が強く、利用されるお客様ごとに正解は異なります。製造業を取り巻く動向やIT、インフラ、クラウドなどにも精通し自社システムも十分熟知することは限りなく困難な目標です。また日本のIT管理者は、多くの業務を掛け持つ多能工エンジニアとしての傾向が強くPLMだけの知識を追求できる環境にありません。この環境で大きな選定を任されることは 不安でしかありません。
しかし、あなたの会社の課題は、他社の課題とは違います
社内ルールに精通していても そのルールが他社と比べて効率的なのか？自社のルールよりも他社事例に興味を抱き、自社仕組み/ルールを極端に否定的に捉えがちになることは理解できます。結果として「多くのパッケージ製品を選定対象」として「正解」をパッケージ内に求めてしまいます。パッケージ内の機能は、他社も利用しているのでデファクトであるという誤った価値観は自社PLM選定時には必要ないにもかかわらずです。
Point
5つのポイントだけ抑えて適正なPLMを選ぶ
PLMの選定に十分な時間が割けない場合でも、5つのポイントを抑えることで 最適な結果を導くことが出来ます
限られた時間内でやらなければならないことは「多くの選定候補をみる」ことではありません。
多くの製品候補の提示を受けた後、思うことはたった1つです。
「どれも同じに見える。判断できない。後は好き嫌いだけ」
こうなると、各製品の機能や価格を「○と×」という一律の評価軸で表し、判断を役員に委ねてしまう他ありません。1度決まった選定は覆ることはなく、その「なんとなく決まった」PLMは大変長い年月使われることになります。お客様にとって「正解」ではなかったとしてもです。
そうならないために まず、やらなければならないことは 「1.自社で求めている機能を洗い出す」です。遠回りに見えますが、最短で最も正確な答えがでます。とにかく、製品やサービスを見ないことが重要です。
1.自社で求めている必要機能を洗い出す（～3ヶ月）
現在利用しているシステムの機能を細かく洗い出します。また、システム化されていないルール（業務）や機能改善などの要望も細かく洗い出します。 できれば、その機能がどうして必要なのか？（要望）も書き出せるとベストです。この時に「必要」「要望」「強い要望」などのランク分けが必要ですが この時点ではステークホルダー（利害関係）は無視してかまいません。多少の予算を使って「コンサルタント」を参画させRFPを作成をすることは重要です。このRFP作成にかかるコストは、必ず回収できます。（RFIやRFPを作成せずに、PLM導入を進めることは 期間/費用/精度を大幅に下落させることになります）
2.必要機能とパッケージ標準機能の比較をする（～2ヶ月）
ようやくSIerやPLMベンダーの出番です。あらゆる手段を使ってコンタクトを取り情報を集めましょう。またその際には社内の購買部門や営業部門といった「社外との接点が多い部門」に相談することを心がけましょう。評判の良いSIerや取引実績のあるパートナーを紹介してくれる可能性があります。
事前に検討した「1.自社で求めている必要機能を洗い出す」をRFIとして活用することで、ベンダー/SIerとの接点が濃くなり、的を射た回答を得られます。概要の説明を受け、好感を持てた場合にRFPの提出となります。
SIerやPLMベンダーへの質問として、必要機能で洗い出した項目に対して「標準機能対応」「環境編集定義対応」「カスタマイズ対応」「開発対応」などの回答を得ます。
3.標準機能で実現不能な機能はカスタマイズで対応するか検討する（～2ヶ月）
パッケージ製品をカスタマイズ/開発することは、大きな痛みを伴います。要は、パッケージベンダーの開発方向性とは異なる機能やルールを無理に対応することになり、1箇所でも修正すると その影響は複数箇所に及びます。また、製品のバージョンアップが行われた場合、カスタマイズ部分はどこまで保証されるのか誰も解りません
パッケージ製品を選定する場合の大前提は「業務をパッケージに合わせる」です。このことで大きな恩恵を受けることが出来ることを十分に理解しましょう。パッケージ製品には環境変数によって機能や見せ方を変える機能を備えた製品が存在します。これらを活用して、カスタマイズは「しない」方向で考えることが重要です。繰り返しなどの面倒な作業で効率が落ちる場合は、それらの機能のみを外部プログラムなどで対応することを考えましょう。この場合、パッケージ製品から指定のデータをアウトプット/インプットする仕組みを開発し、複雑な処理は外部プロブラムで行い、パッケージに無理をさせず、開発費を下げ品質を確保することが出来ます。
4.サポート期間を確認する
パッケージ製品の開発保守は多くの工数と費用を消費します。メーカーは常に新しい機能やプラットフォームへの対応を期待され、それらに対応していく必要があります。既存製品を使い続けたいというユーザーと、新しい製品を開発し、新規顧客を獲得したいというメーカーの間には埋まらない溝があることを意識しましょう。サポート期間の終了は、すなわち 既存システムからの切替を強制されることになります。今までの機能で十分だと思っていても、メーカー保守サポート期間が切れてしまえば 利用し続けることは出来ません。サポート期間やサポート期間後の対応などは選定時の重要な項目です。
対応コスト：
サポート終了タイミングで新しいバージョンに乗り換えるコストは想像を超えることもあり、予め過去実績を確認しておく必要があります。
5.５年総額が予算内で収まるか確認する
カットオーバーまでの費用の他、5年間の維持（ライセンスの追加などの計画も含む）費用総額を細かく計算しましょう。パッケージ製品にはクライアントライセンスが必要で、利用者数に応じて毎年費用を計上する必要があります。PLMは全社展開が肝となりますが、使えば使うだけ費用が上がってしまうことは「広げる力」とは逆の「使わせたくない力」が働きます。多くの投資をしたPLMが、あまり使われていない原因の多くは 展開時の維持費用です。 クライアントライセンスが必要なく、サーバー側の費用のみであれば カットオーバーまでの費用は割高になりますが、展開後は 思う存分全社展開することが出来るはずです。 5年間の総額と国内外含めた展開計画を照らし合わせてみましょう
The last stronghold
PLMconsoleは最後の砦
- パッケージ製品の機能/ルールよりも自社ルールを優先したい
- 今後の展開においてクライアント数が増えることが予想される。トータル費用が安価になる方法としてサーバーライセンス方式を重要視したい。