エンタープライズ ソフトウェアの選択に関する課題
この記事は、"From the Trenches" コレクションの一部です。 エンタープライズ システムの実装が成功するために適応および進化する必要がある方法について説明します。
この記事のWordバージョンをダウンロードするには、「Enterprise Software の選択に関する課題」を参照してください。
その他の記事については、「 溝から」ホワイト ペーパーを参照してください。
エンタープライズ ソフトウェアの選択に関する課題
この辺りは常に起こります。 クライアントは、数日または週に応答を完了し、エンタープライズ システムに購入を検討してもらうための指示を含む "提案要求" (RFP) をオフィスに送信します。 RFP は、ほとんどすべて同じように見える。 通常、簡単な概要や、返信を考慮するために必要な操作の手順 (書式設定方法や返送するタイミングなど) があります。その後、必要な機能の長いグリッドと、回答を書くためにいくつかの追加のエッセイの質問があります。
RFP の課題は、エンタープライズ ソフトウェアの選択に最適ではなかった点です。また、RFP プロセスに従うと、organizationに最適な決定が保証されるわけではありません。 RFP は、最高の価格で最高の商品を取得する方法として購入コミュニティによって設計され、彼らはまだその素晴らしい仕事をしています。 オファリングが同等の場合、意思決定プロセスは、競合する追加の変数 (出荷日など) を 1 つまたは 2 つのみで最適な価格に集中できます。 可能なソリューションが同じ一般的なカテゴリにあり、まったく同等ではない場合 (エンタープライズ ソフトウェアの場合と同様)、購入者が考慮する必要がある変数の数は膨大であり、RFP プロセスは選択に価値を追加しません。 ほとんどの企業がエンタープライズ ソフトウェアを選択する方法 エンタープライズ ソフトウェアのベンダーまたはソリューション プロバイダーで常に発生するプロセスを見てみましょう。 私はエンタープライズプロジェクト管理ソフトウェアまたはエンタープライズタイムシートソフトウェアについて私の会社が提供しているものと話しますが、パラダイムは実質的にエンタープライズシステムの選択と同じです。
ほとんどの企業がエンタープライズ ソフトウェアを選択する方法
まず、エンタープライズ ソフトウェアのベンダーまたはソリューション プロバイダーで常に発生するプロセスを見てみましょう。 私はエンタープライズプロジェクト管理ソフトウェアまたはエンタープライズタイムシートソフトウェアについて私の会社が提供しているものと話しますが、パラダイムは実質的にエンタープライズシステムの選択と同じです。
ほとんどの組織では、エンタープライズ ソフトウェアを探すきっかけは、何らかの問題から生じます。 おそらく、問題は現場担当者によって表面化している可能性があります。 おそらく、問題は上級管理職の誰かによって特定されます。 ただし、イニシアチブは上級管理職の誰かからサポートを受ける必要があります。 企業全体に影響を与えるシステムの草の根の選択は、最も進歩的な組織でもファンタジーです。 そこで、上級マネージャーは「この種のエンタープライズ システムが必要です」と判断します。
一般的なエンタープライズ ソフトウェアの選択プロセスは次のようになります。
経営陣は、新しいエンタープライズ システムが必要だと言います
プロジェクト マネージャーが選択されている
関係するすべての部門から要求を求める
すべての要求を 1 つの大きなスプレッドシートにマージする
要件グリッドを多数のベンダーに送信する
多数の応答を取得する
短いリスト
デモを見る
交渉
管理の受け入れを取得する
経営陣に他の決定をしてもらう
選択作業のプロジェクト マネージャーがボランティアで行われます。 彼または彼女は、インターネットに移動し、検索エンジンを読み込み、"EPM Software" (または任意のエンタープライズ システムが必要です) を入力します。 直ちに 50 万件のヒットが返されます。 おそらく勤勉なプロジェクトマネージャーは、先に進む前に利用可能なシステムの種類を学ぶために最初の12人ほどをサーフィンします。 明らかに、誰も50万以上のヒットをサーフィンして、おそらく最後の1つがorganizationにとって理想的なシステムであるかどうかを確認する時間がありません。
プロジェクトマネージャーは、この新しいエンタープライズシステムの実装の影響を受ける人々の中から選択委員会を組み立てるようになりました。 委員会の中には、最初にorganizationの必要性を特定したフィールド担当者の中からのものがあるかもしれません。 他のユーザーは、そうでない場合があります。 この選定委員会には、どのような制度を選ぶのか、多様な関心を持つ人が混在している可能性があります。
ハプレス プロジェクト マネージャーは、委員会の各メンバーに対して、新しいエンタープライズ システムで必要なものについて代表グループを投票するよう求めるようになりました。 各委員会の代表者はどのようにこれを行いますか? まず第一に、誰もが同じ努力をするのではなく、宿題を行う人のために、スタッフに重要な機能のリストを提出するよう依頼します。 その後、彼らもインターネットにヒットし、いくつかのベンダーのWebサイトを閲覧します。 各サイトでは、新しいシステムでどのような種類の要求を行うことができるかについての新しいアイデアが得られるので、これらのサイトのパンフレットに表示される機能をコピーして貼り付けることができます。
これで委員会が再構成され、各委員会メンバーの長いスプレッドシートが他のメンバーとマージされ、1 つの大規模なスプレッドシートになります。 要件のメガ スプレッドシートは分類されますが、課題があります。 委員会の多様なニーズの第一に、機能が幅広い観点から要求されるにつれて、より明確になりました。 異なる部署の委員がいますが、国や地域や部門も異なる場合があります。 ほぼ常に、同じリスト内の別の要求と競合する要求があります (たとえば、システムは非常に簡単で、多くのプロンプトが表示されず、システムはユーザーごとに多数のオプションを使用して非常に柔軟である必要があります)。
最後に、ベンダーに表示される複合スプレッドシートは完了です。 これには何百もの機能要求があり、ベンダーごとに"はい"、"いいえ"、または "はい" と言う必要があります。 重み付けシステムは、この機能が "Must-have"、"Important-to-have"、または "Nice-to-have" のいずれであるかを示すためにアタッチされる場合もあります。
RFP は、ほぼ準備が整いました。 通常、選択の技術的なアーキテクチャに関するいくつかのエッセイの質問があります。また、これらの要件についてポーリングされたユーザーの数によっては、アーキテクチャの要求が等しく競合する可能性があります (たとえば、システムは、すべてのデータをSQL Serverデータベース ¬に一元的に格納する必要があります。システムでは、ユーザーのコンピューターにローカルにデータを保存できるようにする必要があります)。
実は、今のところはかなり良い音だと思いませんか? 結局のところ、必要なすべての機能を誰が提供できるかを示すベンダーの回答を取り戻す予定です。 実は、今のところはかなり良い音だと思いませんか? 結局のところ、必要なすべての機能を誰が提供できるかを示すベンダーの回答を取り戻す予定です。
しかし、私がこれまでに説明したことには、実際には根本的な問題があります。エンタープライズ システムではなく、コモディティに RFP プロセスを使用しているときに発生しない問題です。 エンタープライズ システムは何かのソリューションです。 しかし、私たちは今のところ問題について何も言っていません。 これは、テクノロジ業界が通常どおりに受け入れ、受け入れられるようになったような一般的な状況です。
このようにエンタープライズ ソフトウェアを選択しても機能しない理由
購入者は何十年もこの方法を使用してきましたが、誰も質問しませんが、エンタープライズソフトウェアビジネスの人々は、エンタープライズソフトウェアを選択する従来のRFP方法に根本的な問題があることを知っています。
まず第一に、機能の非常に長いリストがあるからといって、ビジネス上の問題の解決に近づいているとは限りません。 実際、解決しようとしている特定のビジネス上の問題を明確にしていない場合は、物事をより複雑にし、最終的には悪化させる可能性があります。 RFP プロセスは、コモディティを購入するように設計されています。 靴やジャガイモや砂糖のような均質な製品を持っている場合、この方法でこれらのアイテムを購入すると、低コストの入札者と可能なサプライヤーの中から最良の選択につながる可能性があります。 同様の商品に対する RFP への応答により、可能なサプライヤーの比較が非常に簡単になります。 ミックス内の各製品の変数が (エンタープライズ ソフトウェアと同様に) 無限である場合、RFP への応答にも無限の数の変数があり、プロセスでは価値がほとんどない結果が生成されます。
エンタープライズ システムを選択する RFP メソッドを使用すると、ほとんどの RFP は同じように見えるようになります。 これは、それらがすべて同じ刺激に応答して作成されるためです。 プロジェクト マネージャーは、"このエンタープライズ システムで必要なもの" の一覧を要求し、ほとんどの中間マネージャーがその要求に応答する必要がある唯一のボキャブラリは、機能の一覧です。 そのため、RFP への応答はすべて同じになります。 これらは、システムの一部として、またはシステムの一部として使用できるすべての機能のチェックリストです。
選択チームにとって最も一般的なのは、RFP に対して多数の応答を受け取り、何百ページものページを通過し、完了すると、開始時よりもソリューションに近いとは感じられません。 これは、提案のための公正な要求であるべきものを作成し、その答えを評価する際に膨大な労力をかけた購入者にとって非常にイライラします。
このすべてよりも悪いことに、経験豊富な企業の営業担当者は、プロセスがイライラする結果を生み出し、RFP が作成されると聞いた時点から作業を行っていることを知っています。 RFP 応答では動作しません。 これは関係ありません。 代わりに、RFP を開始した元の原動力を探して、管理構造の 2 つまたは 3 つのレベルで作業しています。 彼らは、ビジネス上の課題を明確にし、購入者や他の中間管理スタッフが最終的にRFPを作成してベンダーに送信できるように車輪を動かしている上級エグゼクティブを探します。
RFP の応答が、購入プロセス内で明確に説明されることがほとんどないビジネス上の問題に対する明確な回答が得られなければ、企業の営業担当者は、上級幹部がプロセスを完全にバイパスし、上級エンタープライズ営業担当者との個人的な関係に基づいてシステムを選択する準備が整います。
あなたがこれがジェイドに聞こえると思うなら、あなたは間違っています。 実際には、RFPプロセスを通じて購入するよりも、エグゼクティブレベルで個人的な関係を通じてソフトウェアを選択するためのより良いケースを作ることができます。
しかし、概念実証やパイロットはどうでしょうか?
そのため、エンタープライズ ソフトウェアの購入に適用すると、従来の購入プロセスに欠陥が生じることがわかっています。 その場合、エンタープライズ プロジェクト管理システムなどのエンタープライズ ソフトウェアをどのように選択すればよいでしょうか。 一般的な方法は、概念実証またはパイロット フェーズ メソッドを使用することです。
これら 2 つの用語は、多くの場合、同義語として使用されるため、概念実証またはパイロット展開とは何かについて説明することから始めましょう。
概念実証。 概念実証では、将来のorganizationは、その課題を克服するソリューションの能力に関して何らかの疑問がある技術的な課題を達成できることを証明するために、限られた方法でエンタープライズ ソフトウェアを展開します。 たとえば、データ ボリュームの場合があります。 「私たちは、製品がプロジェクトごとに持っているほど多くのタスクを処理できないかもしれないことを懸念しています。 このソフトウェアを使用して、それぞれ 500 個のタスクを含む 2 つまたは 3 つのサンプル プロジェクトを作成し、これらのサンプル プロジェクトをソフトウェアに読み込む方法と、ソフトウェアがこのボリュームで基本的な機能を引き続き実行できることを示してください。
パイロット フェーズ。 パイロット フェーズは、エンタープライズ ソフトウェアのインストールですが、スコープは限られています。 パイロットデプロイは、ユーザーのサブセットに対する場合があります。たとえば、1000 人のうち 10 人だけが 4 週間ソフトウェアを完全に使用します。 または、機能のサブセクションまたはデータ量のサブセットの場合もあります。たとえば、500 プロジェクトのうち 10 個のみが読み込まれます。
概念実証またはパイロット フェーズはどのように使用されますか? よく発生する問題は、パイロット フェーズまたは概念実証の適用方法です。 将来のorganizationから概念実証の提案を求められ、実証が必要な技術的概念を特定できる場合は、非常にまれです。 「何を証明したいと考えていて、それを証明したことをどのように測定できるか」と私たちは尋ねます。
最も一般的なのは、中間管理職の誰かが、organizationでの生活を容易にすることを望むエンタープライズ ソフトウェアの一部を特定したことです。 経営陣は全く関与せず、中間管理職は、彼らが克服しようとしているビジネス上の課題を明確にさえしていません。 ソリューションが建物の中にだけあれば、次に経営陣の誰かが廊下をさまようとしたら、ソリューションが運用中であることを「誤って」見て、すぐに企業の展開に祝福を与えるだろうという彼らの希望です。 映画「夢のフィールド」のフレーズを借りるために、「私たちがそれを構築すれば、彼らは来ます」。
ほとんど成功しません。 エンタープライズ ソフトウェアの問題は、展開を成功させるために上級管理職が関与する必要があるということです。 このエンタープライズ システムからのレポートと分析の "クライアント" になるのは、上級管理職です。 さまざまなスタッフがエンタープライズ ソフトウェアで設計、構成、トレーニングを受けるために必要な時間を提供するために、個人で投資する必要がある上級管理職です。 エンタープライズ システム展開の一部であるビジネス プロセスを受け入れるか、または再設計する必要がある上級管理職です。 経営陣が祝福だけでなく、暗黙の支援や直接的な支援を与えなければ、概念実証は役に立たなくなります。
これは、パイロット フェーズにも当てはまります。 企業がエンタープライズ ソフトウェアを使用してビジネス上の問題を解決するために最高レベルからコミットしていない場合、パイロット フェーズの導入は生産的ではありません。
これは、デプロイのパイロット フェーズに場所がないというわけではありません。 デプロイが成功すると、重要な場所が提供されます。 その場所は、購入決定が完了し、エンタープライズ システムの設計が終了した直後です。 現在、パイロット フェーズは、エンタープライズ システム設計をテストし、一般的な展開のために微調整するのに最適な場所です。
運用中のソフトウェアを見て管理が選択されることを期待してパイロット フェーズが行われると、効果のないパイロットが得られ、選択プロセスではこれ以上進めなくなります。
組織はどのようにエンタープライズ ソフトウェアを選択する必要がありますか?
エンタープライズ システムは、毎日、中規模から大規模の組織によって購入され、RFP メソッドが最も効果的ではない場合がありますが、非常に効果的なエンタープライズ ソフトウェアを選択するいくつかの方法があります。 独自の効果的なエンタープライズ選択プロセスを作成するためのヒントをいくつか次に示します。
問題を明確にする。 まず第一に、問題を明確にします。 これは、上級管理職が関与する必要があり、明確にする問題はビジネス上の問題であるため、ビジネス用語で明確にする必要があることを意味します。 質問すべき良い質問の 1 つは、「今は何のビジネス上の決定を下すことができず、このエンタープライズ システム ソリューションの展開を容易にすることができる、非常に困難でしか行えないか」です。
このエンタープライズ システムを使用して解決したい一連のビジネス上の課題がある場合があります。
ベンダーにソリューションを作成するための緯度を与えます。 ビジネス上の問題や問題が明確になったら、可能なベンダーに問い合わせ、プロセスを支援した上級管理職へのアクセスが透過的であることを確認します。 経営陣が最初からプロセスの一部である場合、上級管理職との「秘密」ベンダー会議は不可能になります。 ベンダーに問題を理解させ、それに答えるのに緯度を与えます。 organizationの詳細については、これらのビジネス上の課題が実際よりも自分にどのような影響を与えるのかを説明する際に、潜在的なベンダーに解決策を説明しようとしない場合に、問題に対するより広範な解決策が確実に表示される可能性があります。
可能なソリューション プロバイダーと話すときは、テクノロジとビジネス プロセスの両方の課題に対応する必要があることを理解しておいてください。 organizationのプロセスに何らかの影響を与えなかったエンタープライズ システム ソリューションは一度もありません。 ソリューション プロバイダーがプロセスの影響を支援できない場合は、ソリューションの一部のみを確認します。
何人かの人に会いに行く。 いくつかの可能なソリューション プロバイダーにアクセスしたら、既存のクライアントの一部と話をするように依頼してください。 さらに、ベンダーが既存のクライアントの一部にアクセスできるかどうかを確認してください。 優れたソリューション プロバイダーには、多くの場合、独自のデプロイで成功を収め、見込み顧客に会うのに十分な寛大なクライアントがいます。
可能なソリューションの経験豊富なクライアントを使用して、数時間から、RFP の応答を読んだり、ベンダーの販売デモを見て学んだりするよりも多くのことを学ぶことができます。 ベンダーにクライアント参照やサイト訪問の可能性を尋ねると、理想的な会社は自分の会社とまったく同じだと思うかもしれません。 必ずしもそうであるとは限りません。
多くの場合、関連する、または多少似ている他の業界の企業に会うことが非常に重要です。 また、自分より大きくて小さい組織から多くの情報を得ることもできます。 どのバージョンを使用しているか、正確なサイズであるか、または実際の業界にあるのかではなく、organizationがソリューションに対してどれだけの経験を持っているかに重点を置きます。
幸運にも既存のクライアントにアクセスできる場合は、ベンダーではないことに注意してください。 敬意と礼儀正しく、感謝してください。 小さな贈り物を持って来て、おそらく会社のロゴのプロモーション資料は、多くの場合、よく高く評価されています。 organizationを使用している間、または電話で参照と話している間に、次のような質問が考えられます。
このソリューションを他のユーザーよりも選択するために使用したプロセスは何ですか?
このソリューションがビジネス プロセスにどのような影響を与えましたか?
デプロイの最も困難な側面は何でしたか?
これまでで最も価値のある投資収益率は何でしたか?
ソリューションがここからどのように進化しているのを見ることができますか?
幸せな答えだけを期待しないでください。
参照を完全に提供できないベンダーは、満足しているクライアントの数を持つベンダーよりも少し疑わしい必要があります。
最後に、選択したら、段階的にデプロイします。 この列の他の記事では、段階的なビッグ バン モードでのデプロイ方法について説明します。 これにより、エンタープライズ システムの展開に伴うリスクが軽減され、システムの進化に伴うデプロイ プロセスの微調整に役立ちます。
エンタープライズ システムの展開は動的プロセスであることを忘れないでください。 幸せな結果が月の後に永遠に到着する1回限りの決定ではありません。 最も成功したエンタープライズ展開は、管理の最も上級者から現場で最も戦術的な展開プロセスの一部となる主要な担当者を含む選択から始まり、フェーズ後に段階的にシステムの進化を続けます。
効果的なエンタープライズ システムの選択は、プロセスの最初のフェーズにすぎません。
著者について
Chris Vandersluis は、カナダに拠点を置く MICROSOFT 認定パートナーであるモントリオールの社長兼創設者です。 彼はマギル大学で経済学の学位を取得し、プロジェクト制御システムの自動化に30年以上の経験を持っています。 彼は、プロジェクト管理研究所 (PMI) の長年のメンバーであり、Microsoft Project Users Group (MPUG) のモントリオール、トロント、ケベックの各章の設立を支援しました。 クリスが執筆した出版物には、Fortune、Heavy Construction News、Computing Canada Magazine、PMI の PMNetwork が含まれており、彼は Project Times の定期的なコラムニストです。 彼はマギル大学で高度なプロジェクト管理を教え、多くの場合、北米と世界中のプロジェクト管理協会の機能で話します。 HMS Software は、TimeControl プロジェクト指向のタイムキーピング システムの発行元であり、1995 年から Microsoft Project Solution Partner です。
Chris Vandersluis には、次の電子メールで連絡できます。 chris.vandersluis@hms.ca
Chris Vandersluis の EPM 関連の記事をさらに読む場合は、HMS の EPM ガイダンス サイト (https://www.epmguidance.com/?page_id=39) を参照してください。