カテゴリー
成功するプロジェクト・失敗するプロジェクト

成功する人財配置

最近 LinkedIn 経由で中途採用のオファーが増えてきました。全世界におけるITプロジェクトの成功率は3割と言われています。今回はプロジェクトの成功率を高める人財配置(採用)について記そうと思います。

20年以上 SAP® の導入現場を見ていると、プロジェクトが始まって1ヶ月も経過しないうちに「このプロジェクトは上手く進められそうだ!」とか「あっ、このプロジェクトは失敗するな。。」と勘が働き、そしてその通りの結果を迎える事が多くなりました。

開始直後からボトルネックになる人が見えてしまうのです。

成功率が高まるケース

これまで見てきた中で、最も成功確率の高いプロジェクトは、プロジェクト責任者やリーダーに、ある共通点がありました。

  • やらされてる感がない。
  • 火中の栗を拾う覚悟で、業務の見直しと説得に没頭する。
  • プロジェクトの成功が会社の成功、そして自身の成功だと強い信念を持っている。

こういった方がプロジェクト責任者やリーダーとして存在していた場合は、グッと成功率が高まります。

また、自社の社員でもベンダー側の人間でも、自らの信念とプロジェクトの方針に従って評価できる方ですので、メンバー間の不満も少なく、非常に良い職場環境を育みます。

プロジェクト内部での意見交換も増え、ときには思いもよらない解決策が見つかるなど、良いループに入る事でプロジェクトを成功に導きます。

高確率で失敗するケース

名プレーヤーが名監督・名コーチになるとは限りません。優秀なプレーヤー(開発者)であった方を、プロジェクトマネージャーとして育てたい一心でプロジェクト責任者、またはリーダーとして配置している場合は、プロジェクトが暗転する確率が高まります。

技術が主軸で、業務要件を整理し、相手の心情にも配慮しながらプロジェクトを進められる方も稀にいらっしゃいますが、本当にごく少数です。見つけた場合は大事なご縁ですので、大切にして下さい。

テクニカルな事が得意(好き)な方の大きな特徴として挙げられるのは、以下の2点です。

  • 自分の技術(知識)と、その存在価値が一番大事。
  • プロジェクトの成功には、あまり興味がない。

まず、自分の技術(知識)が採用される事、これが最も重要だと考えています。こういった方がプロジェクト責任者やリーダーとなってしまった場合、時間がいくらあっても足らなくなる傾向があります。その理由は以下の2点に大切な時間を浪費してしまうからです。

  • マッチポンプで自己満足。自分が最適解を持っていても敢えて言わず、メンバーの提案でやらせてみる。(もちろん失敗する方向に罠を仕掛けているので、必ず失敗させます。)失敗が露見したところで、自身の技術(知識)を見せつけてリカバリーし、自尊心を満たします。しかし、その間、プロジェクトの進捗は停滞しています。
  • 脅威となる存在の排除。自分の存在価値を危うくする存在(知識も経験も相手の方が上)が現れると、体調が悪くなり休みがちになります。また、プロジェクトそっちのけで、その脅威となるメンバーの排除に全身全霊を捧げます。パワハラはもちろん、他のメンバーを巻き込んで無視させたり、不具合をでっち上げる等、ありとあらゆる手段で排斥に没頭するため、プロジェクトの進捗は当然滞ります。

こんな時間の無駄使いをするわけですから、フェーズ事のスケジュールもまともに出てきません。一番酷い例だと、フェーズが始まって3週間もスケジュールが無いケースがありました。

自尊心を持つのは大事な事ですが、行き過ぎた自己愛はプロジェクトのブレーキでしかありません。

内製化を目的とした採用の優先順位

社内にプロジェクトを任せられる人財が居れは最高です。該当する方が見つからなかった場合は、当然ながらそのポジションを担う方の採用が最優先となります。

候補者のバックグラウンドがとても重要となりますので、上記にあるような傾向が見られないか、よく話しを聞いて観察する事が重要です。

内製化を目的とした採用基準の一助となれば幸いです。

カテゴリー
成功するプロジェクト・失敗するプロジェクト

ベンダーのミスリード

残念ながら、全てのベンダーが「正しい情報をユーザーに伝えている」訳ではない事を、改めて記しておきます。

ネット上で見かける SAP S/4HANA® 移行サービスでも、担当者の誤解なのか、意図的にミスリードを誘っているのか不明ですが、ユーザー企業の知識不足を狙った感のある記述があったので、これを例に挙げて解説と補足説明を残しておきます。

(ミスリードを誘う記載例1)修正するAdd-On量で単純移行か再構築かを提案します。

(解説1)「少し言葉が足りないだけ」なのかもしれませんが、ユーザー企業側から見れば、判断基準は以下の2点に絞られるはずです。

  • 「保守期限が迫っているので、とにかく現状の業務を変えずに、最低限のコストで乗り換えたい」→ 単純移行
  • 「DXを見据えて業務を見直す(見直せる従業員が存在する)ので、これまで投資してきたAdd-Onも捨てて、一から業務とシステムを見直したい」→ 再構築

(ミスリードを誘う記載例2)Add-Onはバージョンアップの弊害になる場合があるため、なるべく標準機能の利用をお勧めします。

(解説2)SAP®は2通りの拡張方法を提示しています。一つ目は従来のAdd-On開発等でお馴染みの「In-App 拡張」です。二つ目は、SAP®以外のクラウドサービスやシステムとの連携機能や、不足する機能をSAP® Cloud Platformで開発する「Side-by-Side 拡張」です。SAP®のメッセージを纏めると以下の2点に集約されます。

  • 従来のAdd-On(In-App 拡張)はECCのバージョンアップ時、検証コスト増となる可能性があるので、影響を見極めて、必要であれば Side-by-Side 拡張で移管して下さい。
  • 新たにAdd-Onする場合は Side-by-Side 拡張で実装して下さい。ECCのバージョンアップによる影響はありません。(標準機能の利用を強く勧めている訳ではない)

(ミスリードを誘う記載例3)SAP S/4HANA® はクラウド時代の設計で、SAP®のクラウド製品との連携が容易です。

(解説3)❝ SAP S/4HANA® はインメモリデータベースであるHANAの能力を最大限に発揮できるような設計になっている ❞ が正しい伝達の仕方でしょうか。SAP®のクラウド製品との連携が容易である事に間違いはありませんが、他社のクラウドサービスとの連携アダプタも、世界中のパートナーが開発し販売していますので、❝ 他のクラウドサービス連携も容易です ❞ が正しい情報です。

いかがでしょうか。ベンダーからの提案が「ベンダー都合の提案」なのか、「ユーザー企業の目線に立った提案」なのか、こうやって見ると、とても分かりやすい例だと思います。

ベンダー選定の一助となれば幸いです。

カテゴリー
成功するプロジェクト・失敗するプロジェクト

導入時の失敗要因

2020年6月でビッグドライブ株式会社は、創業から10期目を迎える事ができました。私は1996年からSAP®のAdd-On開発者としてキャリアをスタートさせ、今年で25年目を迎えました。

これから将来を担う技術者のためにも、そしてSAP S/4HANA®を導入して運用していくユーザーのためにも、これまでERPの導入現場で何が起こってきたのか、時代背景を踏まえて記そうかと思います。

1990年代後半。ホストコンピューターからのダウンサイジングニーズ、そして2000年問題の対応手段としてSAP® R/3® は飛ぶように売れました。当時はBPR(ビジネス プロセス リエンジニアリング)という言葉も流行り、「R/3® に業務を合わせて下さい!極力 Add-Onを減らしましょう!」を合言葉に導入プロジェクトが進められました。しかし、導入する側もプロフェッショナルは少ない訳です。

SAP® R/3® に精通していない人達が導入するわけですから、あちらこちらで「これがSAP®の標準ですから。Add-Onしましょう!」となってしまいました。

標準プログラムやパラメータ設定、Exitでどうにかなる範囲でも、Add-On開発が増えれば増えるほど、システム導入会社の儲けは大きくなるため、「標準機能では実現できないと説明してAdd-Onにしちゃえ!」というベンダーもいました。

そうして「SAP® vs ユーザー企業」という一番望ましくない対立構図が、皮肉にも「SAP®のパートナー企業」の手によって作り上げられていったのです。

プロジェクトメンバーに導入企業の業務担当者を据えた事も、Add-Onが増えた材料の一つでした。何故なら業務を担当している方は「今の業務をこなす」のが仕事であり、「新しい業務を作りだすのは自分の仕事では無い」と感じている方が多いからです。

業務改善を考え、責任を負う覚悟のある各業務のリーダークラス、SAP® R/3®の機能を熟知しシステム稼働後の運用まで考えていたベンダーが揃った「幸運なるプロジェクト」だけが成功を収めていました。下記表のNo.1は大成功と言ってもいいでしょう。No.2は保守メンバーの熟練度が上がり、稼働後にシステムの改善余地があるので、小成功といったところでしょうか。No.3はベンダー側(システム稼働後に残る保守メンバー含む)が疲弊している場合が多いので、運用フェーズでの改善提案は望みにくいケースです。No.4にいたっては、残念ながら既存システムを使い続けていた方が良かったレベルです。

No.ユーザー側ベンダー側結果
1リーダークラス機能熟知成功
2リーダークラス機能知識に乏しい要求された機能をAdd-Onや手作業で逃げる。
3担当者レベル機能熟知現状維持を求められ、ベンダーの提案が通らない。
4担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因