エンタープライズ ソフトウェアの選択における問題点: ホワイト ペーパー

このホワイト ペーパーは、「最前線の現場から」コレクションの一部です。 エンタープライズ システムの実装を導入し、成功まで発展させるために必要な方法について説明します。

このホワイト ペーパーの Word 版をダウンロードするには、「エンタープライズ ソフトウェアの選択に関する課題」を参照してください。

その他のホワイト ペーパーについては、「最前線の現場から」のホワイト ペーパーを参照してください。

エンタープライズ ソフトウェアの選択に関する課題

次のようなことは常に起こっています。 ある顧客から、数日以内または 1 週間以内に回答するようにという指示が記載された "見積依頼書" (RFP) が送られ、購入対象に検討しているエンタープライズ システムを記載して返送します。 RFP はほとんど同じ内容です。 通常、簡単な概要、返信を検討する上で必要な対応についての指示 (必要な書式、返信時期など) が記載されています。そして、必要な機能の長い記入欄と、回答を記入する記述式の質問がいくつか続きます。

RFP の課題は、RFP がエンタープライズ ソフトウェアの選択に最適ではなく、RFP プロセスに従っても、組織にとって最適な決定が保証されないことです。 RFP は、最適な価格で最適な商品を入手する方法として、購入側コミュニティが設計したものであり、その方法としては今でも役に立っています。 商品が同等な場合、意思決定プロセスでは、最適な価格を中心にして、考慮する必要があるその他の 1 つまたは 2 つの可変要素 (発送日など) と共に考えることができます。 ソリューション案が、全般的なカテゴリは同じでも、(エンタープライズ ソフトウェアの場合と同様に) すべてが同じではない場合、購入者が考慮する必要がある可変要素の数は多数になるので、RFP プロセスは選択の付加価値になりません。 多くの会社は、どのようにエンタープライズ ソフトウェアを選んでいるのでしょうか。まずはエンタープライズ ソフトウェアのベンダーまたはソリューション プロバイダーで常に発生しているプロセスに注目してみましょう。 当社が提供しているソフトウェアなので、エンタープライズ プロジェクト管理ソフトウェアまたはエンタープライズ タイムシート ソフトウェアについて説明します。ただし、実質的にはどのエンタープライズ システムの選択でもパラダイムは同じです。

多くの会社は、どのようにエンタープライズ ソフトウェアを選んでいるのでしょうか。

まずはエンタープライズ ソフトウェアのベンダーまたはソリューション プロバイダーで常に発生しているプロセスに注目してみましょう。 当社が提供しているソフトウェアなので、エンタープライズ プロジェクト管理ソフトウェアまたはエンタープライズ タイムシート ソフトウェアについて説明します。ただし、実質的にはどのエンタープライズ システムの選択でもパラダイムは同じです。

ほとんどの組織で、エンタープライズ ソフトウェアを探すきっかけは、何らかの問題です。 おそらく、現場担当者が問題を見つけます。 そしておそらく、上層部経営陣の誰かが問題を特定します。 ただし、その後に重要なことは、上層部経営陣の誰かから支持を得ることです。 企業全体に影響を及ぼすシステムを経営陣以外が選ぶことは、かなり進歩的な組織であっても現実的ではありません。 そのため、上層部経営陣が「我が社にはこのようなエンタープライズ システムが必要だ」と決定します。

一般的なエンタープライズ ソフトウェアの選択プロセスは次のとおりです。

  1. 経営陣が新しいエンタープライズ システムが必要と言う

  2. プロジェクト マネージャーが選択される

  3. 関係するすべての部門からリクエストを求める

  4. すべてのリクエストを 1 つの大きなスプレッドシートにまとめる

  5. 要件のリストを多数のベンダーに送る

  6. 多数の回答を得る

  7. リストの項目数を少なくする

  8. デモンストレーションを見る

  9. 交渉する

  10. 経営陣の同意を得る

  11. 別のことについて経営陣に決定してもらう

選択作業のプロジェクト マネージャーはボランティアです。 プロジェクト マネージャーは、誰もがすることを実行します。つまり、インターネットにアクセスし、検索エンジンを使って "EPM ソフトウェア" (または何かエンタープライズ システムに必要なもの) を検索します。 すぐに 50 万件もの検索結果が返されます。 おそらく、熱心なプロジェクト マネージャーであれば、最初の数十件を閲覧して、どのような種類のシステムがあるかを把握してから、次に進むでしょう。 当然ながら、50 万件もの検索結果を閲覧して、最後の 1 件が組織にとって最適かどうかを確認する時間がある人などいません。

不屈のプロジェクト マネージャーは、新しいエンタープライズ システムの実装で影響を受ける人の中から選択委員会を集めることにします。 委員会のメンバーには、最初のフェーズで組織のニーズを特定した現場担当者が含まれる場合があります。 また、それ以外のメンバーが含まれる場合もあります。 この選択委員会には、選択されるシステムの種類への関心が異なる、さまざまなメンバーが参加する可能性があります。

この不運なプロジェクト マネージャーは、委員会の各メンバーに、新しいエンタープライズ システムに必要なものについて、それぞれが代表するグループで投票を行うように求めます。 各委員会の代表者はどうするでしょうか。 まず、全員が同じ労力を掛けることはないでしょうが、この宿題について、代表者はスタッフに重要と思われる機能のリストを提出するように依頼します。 そして、スタッフもインターネットを検索し、いくつかのベンダーの Web サイトを閲覧します。 ベンダーのサイトには、新しいシステムで実現できる可能性があるリクエストの種類について新しいアイデアが示されているので、サイトに掲載されているカタログの機能をコピーして貼り付けることもあります。

委員会が再び招集され、各委員会メンバーの長いスプレッドシートが他のメンバーのものと結合され、1 つの巨大なスプレッドシートが作成されます。 要件が記載された巨大なスプレッドシートはカテゴリに分けられますが、問題があります。 まず何よりも、幅広い観点から機能のリクエストが出されたので、委員会のニーズの多様性がさらに明白になりました。 委員会のメンバーは、部門が異なるだけでなく、国や地域も異なる可能性があります。 ほとんどの場合、同じリスト内で、リクエスト間の競合があります (たとえば、ごく簡単で多数のプロンプトを表示しないシステムのリクエストと、各ユーザー向けに多数のオプションがあって柔軟性が高いシステムのリクエストなどです)。

最終的に、ベンダーに見せる統合スプレッドシートが完成します。 数百もの機能のリクエストがあり、ベンダーはそれぞれについて "可能"、"不可能"、"ある程度の労力で可能" と回答することが求められます。 その機能が "必須"、"重要"、"あれば便利" のいずれかについて示す加重システムも利用する場合があります。

機能選択スプレッドシートの一部

これで RFP の準備がほぼ整いました。 いくつかの記述式質問があります。通常は、選択の技術アーキテクチャについての質問です。これらの要件について投票した人数にもよりますが、アーキテクチャのリクエストも同様に競合する可能性があります (たとえば、システムですべてのデータを SQL Server データベースで一元的に保存する必要があるというリクエストと、すべてのデータをユーザーのコンピューターにローカル保存できるようにする必要があるというリクエストです)。

実際のところ、ここまではうまく行っていると思いませんか。 結果として、必要なすべての機能を提供できることを示す大量の回答がベンダーから戻ってきます。 実際のところ、ここまではうまく行っていると思いませんか。 結果として、必要なすべての機能を提供できることを示す大量の回答がベンダーから戻ってきます。

ただし、実際には、ここまでに説明してきた内容には根本的な問題があります。エンタープライズ システムではない商品に RFP プロセスを利用するときには発生しない問題です。 つまり、エンタープライズ システムは何かに対する解決策のはずです が、 問題についてはまだ何も話していません。 この状況はよくあることなので、テクノロジ業界が通常のこととして受け入れ、受け入れ可能としてきました。

機能しないエンタープライズ ソフトウェアを選ぶ理由

購入者は、何十年にもわたってこの方法を使ってきて、疑問に思う人はいません。ただし、エンタープライズ ソフトウェア ビジネスの人間であれば、エンタープライズ ソフトウェアを選ぶ従来の RFP 方法には根本的な問題があることをわかっています。

まず何よりも、膨大な量の機能リストがあるだけでは、必ずしもビジネスの問題の解決に近づいたとは言えません。 実際、解決しようとしている特定のビジネスの問題が明確にすらなっていない場合、事態はより複雑になり、最終的には改善されるどころか悪化する可能性があります。 RFP プロセスは、商品を購入するために設計されました。 靴、芋、砂糖のような同種の製品を入手する場合、この方法で製品を購入すると、候補の供給元の中から、最も低いコストの入札者で最適な製品を選択できる可能性があります。 似た商品の場合、RFP に対する回答で候補の供給元を簡単に比較できます。 (エンタープライズ ソフトウェアと同様に) 各製品の選択肢が多様で無限にある場合、RFP に対する回答も無限になり、プロセスの結果はほとんど価値がなくなります。

エンタープライズ システムの選択に RFP 方法を使うと、RFP はほぼ同じ結果になります。 これは、すべての RFP が同じ刺激に反応して作成されているためです。 プロジェクト マネージャーは、"このエンタープライズ システムに必要なものは何か" のリストを要請し、その要請に対してほとんどの中間管理者は機能リストを提出するだけです。 結果として、RFP に対する回答は同じような結果になります。 つまり、システムの一部として、またはある程度の労力でシステムの一部として利用できる全機能のチェックリストです。

選択チームによくあることは、RFP に対する多数の回答を受け取り、何百ページもの回答を苦労して読み、読み終わっても、開始時よりも解決に少しも近づいていないと感じる状況です。 購入者にとって、公正な見積依頼書を作成し、回答を評価しようと多大な努力を払って、その労力が無価値だったとわかるのは非常にいらだたしいことです。

何よりも悪いことに、経験豊富なエンタープライズ営業担当者は、プロセスがいらいらするような結果になると分かっていて、RFP が作成されることになると聞いた時点から仕事中だということです。 営業担当者は RFP の回答を処理しません。 彼らには関係ないことだからです。 代わりに、管理構造で 2 つか 3 つ上位の管理者に働きかけ、RFP が開始される原動力を探します。 何らかのビジネス課題を明確に表現し、そして、結局は購入者や他の中間管理スタッフが RFP を作成してベンダーに提出するような方向にかじを切った上級エグゼクティブを探すのです。

購入プロセス内でほとんど明らかになっていないビジネスの問題について明確な答えがないまま、RFP の回答が完了したときには、エンタープライズ営業担当者は行動に移る準備が整っているので、上級エグゼクティブにプロセスを迂回させ、そのエグゼクティブと上位のエンタープライズ営業担当者との個人的な関係に基づいてシステムを選択させます。

このような状況にはうんざりだと考えているのであれば、それは間違いです。 実際のところ、RFP プロセスを使用して購入するよりも、エグゼクティブ レベルの個人的な関係でソフトウェアを選ぶ方が良い結果になることがあります。

概念実証またはパイロットを利用する場合

エンタープライズ ソフトウェアの購入に従来の購入プロセスを適用するのは問題があるとわかっています。 このような場合、エンタープライズ プロジェクト管理システムなど、エンタープライズ ソフトウェアを選ぶにはどうすればよいでしょうか。 人気のある方法は、概念実証またはパイロット フェーズの方法です。

多くの場合、これら 2 つの用語は 同意語として使われるので、まず概念実証またはパイロットの展開について説明しましょう。

概念実証    概念実証では、見込み顧客の組織は限定された方法でエンタープライズ ソフトウェアを展開し、技術的な課題を解決できることを証明します。このとき、ソリューションがその課題を克服する能力について、いくつか疑問が生じます。 たとえば、データのボリュームなどです。 「現在の各プロジェクトに含まれる多数のタスクをこの製品で処理できるかどうか心配です。 ソフトウェアを持ってきて、それぞれ 500 件のタスクがあるサンプル プロジェクトを 2 つか 3 つ使って、ソフトウェアにどのように読み込まれるか、また、そのようなボリュームでもソフトウェアの基本機能が動作するかを見せていただけないでしょうか」

パイロット フェーズ    パイロット フェーズは、限られた範囲でエンタープライズ ソフトウェアをインストールすることです。 パイロット展開は、ユーザーの一部を対象にする場合があります。たとえば、1,000 人中 10 人が 4 週間、ソフトウェアをフルに使います。 また、機能のサブセクションや、データ ボリュームの一部を対象にする場合があります。たとえば、500 プロジェクト中の 10 プロジェクトのみを読み込むなどです。

概念実証またはパイロット フェーズの使用方法    よく発生する問題は、パイロット フェーズまたは概念実証の適用方法です。 見込み顧客の組織が概念実証の提案について問い合わせてきて、証明する必要がある技術的なニーズも特定できる場合は非常にまれです。 私たちは、「証明したいことは何ですか。また証明したことをどのように測定できますか」と尋ねます。

よくあるのは、中間管理者の誰かが、エンタープライズ ソフトウェアの 1 つを指定し、組織内の仕事が簡易化されることを希望している場合です。 上層部経営陣はまったくかかわらず、中間管理スタッフですら、克服しようとしているビジネスの課題が明確にわかっていません。 中間管理者の望みは、ソリューションが社内にあるだけで、次に経営陣の誰かが廊下を通りかかったときに、ソリューションが運用されていることを "偶然に" 見かけて、すぐに社内への展開に賛同することです。 映画「フィールド オブ ドリームズ」のフレーズを借りると、「それを作れば、彼らは来る」です。

効果がないパイロット フェーズの選択

これが成功するのはまれです。 エンタープライズ ソフトウェアの問題は、展開が成功するには、上層部経営陣が関与する必要があるという点です。 このエンタープライズ システムのレポートと分析の "顧客" になるのは、上層部経営陣です。 ある範囲のスタッフに、エンタープライズ ソフトウェアの設計と構成を行い、トレーニングを受けるために必要な時間を許可するために、個人的に投資する必要があるのは、上層部経営陣です。 エンタープライズ システムの展開に含まれるビジネス プロセスを承認し、再設計さえも支援する必要があるのも、上層部経営陣です。 上層部経営陣が賛同するだけでなく、暗黙的な支持と直接の支援も与えないと、概念実証は役に立ちません。

これはパイロット フェーズの場合にも当てはまります。 エンタープライズ ソフトウェアによるビジネスの問題の解決に会社の最上層部が取り組んでいなければ、パイロット フェーズを導入しても効果はありません。

効果があるパイロット フェーズの選択

展開のパイロット フェーズに存在する意味がないという訳ではありません。 パイロット フェーズは、展開の成功のために重大なフェーズです。 それは、購入の決定が完了し、エンタープライズ システムの設計が完成した直後です。 パイロット フェーズは、エンタープライズ システム設計をテストし、全般的な展開について微調整するために適したフェーズになります。

ソフトウェアが機能しているところを見たいという希望を受けてパイロット フェーズを実行すると、経営陣の選択につながります。 パイロットが効果的でなければ、選択プロセスが先に進まなくなります。

組織のエンタープライズ ソフトウェアの選択方法

エンタープライズ システムは中規模から大規模の組織が日常的に購入しています。RFP は最も効果的な方法ではないかもしれませんが、非常に効果的なエンタープライズ ソフトウェアの選択方法はいくつかあります。 独自の効果的なエンタープライズ選択プロセスを作成する場合、いくつかのヒントがあります。

  • 問題を明確にする    何よりも重要なのは、問題を明確にすることです。 つまり、上層部経営陣が関与する必要があり、明確にする問題とは、取引条件で明確にする必要があるビジネスの問題です。 お勧めの質問は、「ビジネス上の決定事項のうち、現在は不可能なもの、大きな困難はあっても可能なものはありますか。また、その中で、このエンタープライズ システム ソリューションを展開することで簡単になるものはありますか」です。

    このエンタープライズ システムを使って解決したいビジネスの課題が、数多くある場合もあります。

  • ベンダーがソリューションを作成するときにある程度の自由度を与える    ビジネスの問題が明確になったら、ベンダー候補に連絡し、プロセスを支援した上層部経営陣とのアクセスについて隠しごとがないようにします。 プロセスの最初から経営陣が参加していれば、ベンダーと上層部経営陣との "秘密" のミーティングは不可能になります。 ベンダーが問題を理解するようにして、問題に回答する上である程度の自由度を与えます。 ビジネスの課題が自分に与える影響を説明するときに、自分の組織について、認識していたよりも多くのことがわかる可能性があります。また、ベンダー候補にソリューションを詳しく説明しようとしなければ、問題に対してより広い範囲のソリューション案が提示されるでしょう。

    ソリューション プロバイダー候補と話すときは、そのプロバイダーがテクノロジとビジネス プロセスの課題の両方について説明する必要がある、という点を確実に理解してもらいます。 組織のプロセスに何も影響がないエンタープライズ システム ソリューションは存在しません。 プロセスが受ける影響について、ソリューション プロバイダーが役に立たない場合、あなたがソリューションの一部しか見ていないことを示します。

  • 何人かの人と会う    何社かのソリューション プロバイダー候補と具体的な話に進んだら、相手の既存の顧客について話を聞きます。 できれば、既存の顧客の何社かについて、自分が訪問してもよいかを確認します。 多くの場合、優れたソリューション プロバイダーであれば、展開が成功し、見込み顧客と会う時間を作る余裕がある顧客がいます。

    RFP の回答を読んだり、ベンダーの営業担当者のデモンストレーションを見たりするよりも、ソリューション案を経験した顧客と何時間か会う方が、より多くの情報が得られます。 見込み顧客の照会先と現地訪問をベンダーに依頼する場合、会うのに最適な会社は、自社とまったく同じ会社と思われるかもしれませんが、 それが常に正しいとは限りません。

多くの場合、他の業種の会社と会う際に自社に関連する会社や、自社と少し似ている会社と会うことは非常に価値があります。 また、自社よりも規模が大きい組織や小さい組織から多くを学ぶこともあります。 組織が使っているバージョン、規模の大きさ、自社と同じ業種かどうかよりも、組織がそのソリューションについて持っている経験の量を重視してください。

既存の顧客を訪問する幸運に恵まれた場合、その顧客はベンダーではないことを忘れないでください。 敬意を払い、礼儀正しく、感謝の念を示すようにします。 また、ささやかな贈り物を持参します。多くの場合、会社のロゴが入った販売促進品などが喜ばれます。 組織に訪問する場合、または電話で照会について話す場合は、次のような質問を聞くことをお勧めします。

  1. 他のソリューションではなく、このソリューションを選ぶときに、どのようなプロセスを使いましたか。

  2. このソリューションは ビジネス プロセスにどのような影響を与えましたか。

  3. 展開の最も困難な側面は何でしたか。

  4. これまでの投資に対する見返りとして、最も価値のあることは何ですか。

  5. 今後、ソリューションはどのように発展する予定ですか。

ただし、良い答えのみを期待しないでください。

照会先をまったく示すことができないベンダーは、多数の満足している顧客がいるベンダーよりも、やや疑わしいと考える必要があります。

最後に、選択が完了したら、複数のフェーズで展開します。 複数のフェーズでの展開方法とビッグバン モードの展開方法については、このコラムの別の記事を 参照してください。 複数のフェーズで展開することで、エンタープライズ システムの展開に関係するリスクが軽減され、システムの発展に会わせて展開プロセスを微調整することができます。

エンタープライズ システムの展開は動的なプロセスであることを忘れないでください。 1 回の決定で、毎月毎月、永遠に幸せな結果が出ることはありません。 最も成功したエンタープライズの展開の場合、主要な担当者が関与する選択から始まります。その担当者は、経営陣の最も上層から、最も戦略的な現場まで展開プロセスに参加します。そして何フェーズもかけてシステムの発展を継続します。

効果的なエンタープライズ システムの選択は、プロセスの最初のフェーズに過ぎません。

著者について

Chris Vandersluis 氏は、Microsoft 認定パートナーであり、モントリオール (カナダ) に拠点を置く HMS Software の社長兼創業者です。 マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。 PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。 氏は、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 ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×