ソリューションの購入者であること

この記事は、"From the Trenches" コレクションの一部です。 これは、将来のソフトウェア購入者が、簡単に理解できるビジネス分析方法を適用することで、ソフトウェア ベンダーとの対話をより効果的にする方法について説明します。 このホワイト ペーパーを利用すれば、ソフトウェア ソリューションでどんな問題に取り組むべきかを効果的に判断することでソフトウェア評価基準が作成しやすくなります。

その他の記事については、「 溝から」ホワイト ペーパーを参照してください。

ソリューション購入者であること

多くの場合、ソフトウェアの購入は、機能の一覧、広告キャンペーン、または友人の推奨事項に基づいています。 この記事では、将来のソフトウェア購入者が、簡単に理解できるビジネス分析方法を適用することで、ソフトウェア ベンダーとの対話をより効果的にする方法について説明します。

以前とは違います。 エンタープライズ設定でソフトウェアを動作させる方法は、インストールと呼ばれることさえありません。 今日では、実装またはデプロイという用語は、新しいパッケージを起動して実行するために必要なものをより適切に説明しています。

ソフトウェア ベンダーがソリューションとして販売するものについて話す人が増えていますが、不思議ではありません。 Microsoft Project Server や Microsoft CRM などのエンタープライズ システムの展開を考えるときは、まず、関連するテクノロジのさまざまなレイヤーについて考え、それに到達する前に、ビジネス全体への影響について考える必要があります。

もちろん、販売するソリューションにはソリューションの販売が含まれます。 これに全く従っているなら、中規模から大規模な組織を対象とする地球上のほぼすべてのハイテク組織が、ソリューション販売配信者としての再構築に取り組んでいることを知っています。 Microsoft は確かにこれらの組織の一つです。 Microsoft は、この数年間、フィールドセールスと実装力の指針として販売するソリューションを確立するために広範に取り組んできました。

では、ソリューションの営業担当者とは 彼らはまだ営業担当者であることは事実です。 しかし、ソリューション営業担当者は、ソフトウェアのボックスを移動するだけでなく、クライアントが状況を改善するのに役立つ何かを構築することを目的としています。

今のところ素晴らしいですね。あなたの人生の多くを改善するために探している営業担当者のニルヴァーナ。 しかし、これには課題が伴い、その課題に対処することは、見込み顧客であるユーザーが参加できるものです。

問題に焦点を当てる

ほとんどのソリューション営業担当者が市場に参入したときに直面する課題は、ソリューションの外観に関する私たちの先入観です。 私たちはソフトウェアの機能と機能に焦点を当てることに慣れているので、ソフトウェアセールスマンと話すとき、会話はほとんど必然的に直接導きます。"あなたのソフトウェアはこれを行うことができますか? あなたのソフトウェアは、それを行うことができます?"経験豊富なソフトウェア営業担当者は、ポジションを販売するソリューションに移行されるタイプであり、機能や機能の販売に使用されるため、最も基本的な質問を忘れることがよくあります。"問題は何ですか?

今、これは愚かに聞こえるかもしれませんが、ソフトウェア営業担当者との最後のいくつかの会話について考えると、この質問が出ることはめったにないことに驚くかもしれません。 Microsoft やそのパートナーなどのベンダーは、毎年多くの提案依頼を受け取ります。 私は長年にわたって何百もの関数を見てきましたが、ほとんど常に存在することは、ベンダーが記入することが期待される機能の長いグリッドです。 この大きなスプレッドシートは、多くの場合、クライアントへの応答の中核となります。

ほとんど存在しないのは、これらの各機能によって対処されるビジネス ニーズの説明です。 以前の製品で使い慣れた機能に巻き込まれるのはとても簡単で、どこかで昇格しているのを見たので、この新製品に興味を持たれたことに焦点を当てるには本当の規範が必要です。 これは特に、どのような種類のソリューションが求められているかについて多くの入力があるエンタープライズ設定で発生する可能性があります。 特定のビジネス ニーズについて話すよりも、新しいソフトウェア システムで必要なすべての機能を一覧表示するように求める要求を送信する方がはるかに簡単です。

おそらくあなたは明らかな何かを欠いていると思い始めている場合, あなたは一人ではありません. この状態は、現時点ではソフトウェア業界で非常に普及しているため、Business Analyst という新しいコンサルタント カテゴリが立ち上がっています。 これらのユーザーは、ビジネスニーズからソフトウェア機能への接続を確立するためのトレーニングを受けています。 ビジネス アナリストがそれらを適用する方法で、エンタープライズ レベルのソフトウェアの評価に基本的な概念を適用する方法を数分で確認しましょう。

ビジネス ニーズの特定

最初に考えるべきことは、最初に新しいソフトウェア システムを探すために必要なビジネスです。 私たち自身の組織は、多くの場合、エンタープライズ プロジェクト管理ソフトウェアの実装について企業に相談します。 私がコンサルタントとして組織に到着したとき、ソフトウェアを購入するかどうかについて話すずっと前に、私は組織が今どのようにプロジェクト管理を行っているかを尋ねます。

彼らが彼らの答えを終えたら、私はいつもこのフォローアップの質問をします:"その方法はあなたのために働いていますか?驚くべきことに、クライアントは多くの場合、それがであると答えます。 私にとって実装の会話はそこで停止する必要があります。 「問題がなければ、ソリューションを作成する方法はありません」と説明します。多くの場合、この回答はユーザーを一時停止させます。 「なぜ私たちは呼び出されたのですか?」と聞いていきます。 答えは大きく異なる場合があり、調整する必要があるいくつかの議題があることに気付いて部屋の周りを見回す人は珍しくありません。そして、私たちの会話は5分未満です!

だから、「私たちのビジネスニーズは何ですか?」と尋ねるのは、始めるのに最適な場所です。 ほとんどの場合、この質問に答える全体的な目標があります。これは、最初にイニシアチブを開始した目標です。

ビジョン演習の実施

次に、ソフトウェア機能の観点から、これが何を意味するのかについてもう少し詳しく見る必要があります。 Microsoft Project Server のようなエンタープライズ プロジェクト管理ソフトウェアを組織に実装する場合は、常にビジョン 演習から始めます。これには、ソフトウェアを評価する主要な担当者と、上級管理職が関与するビジョン 演習が含まれます。 この演習の目的は、ビジネス目標を技術的な機能に接続するため、技術担当者だけでこの演習を実行するだけでは十分ではありません。

これを行う効果的な方法は次のとおりです。重要な担当者を大きなホワイトボード付きの部屋に入れます。 ホワイトボードを 4 列に分割する: 右端の列の見出しから始めます。 "ビジネスの決定" と呼びます。

適切な列では、検討している新しいシステムを使用して、ビジネス上の意思決定を一覧表示します。 これをクライアントと一緒に行う場合、まず多くの機能を一覧表示する必要があります。そのため、重要な回答はビジネス上の意思決定であると主張する必要があります。 たとえば、参加者はすぐに「すべてのリソースとそのワークロードのリストが必要です」と言うことができます。もちろん、それは当てはまるかもしれませんが、見つける必要があるのは、そのリストで彼らが行うビジネス上の決定です。

ビジネス上の意思決定の例を次に示します。

• 特定の部署での雇用または解雇

• プロジェクトに対する外出先または外出先での意思決定

ビジネス上の決定事項の適切な一覧が得られたら、一時停止します。 今は、ビジネス意思決定リストを確認し、最優先事項の決定を特定する良い時期です。 このようなビジネス上の決定の 1 つについての回答しか得られなかった場合、組織に最も価値を提供するものはどれでしょうか。 この時点で、上位 3 つの決定を選択するのが常に最も簡単です。

ここまで進んでいけば、エンタープライズ プロジェクト管理ソフトウェアを探すほとんどの組織以上の成果が既に達成されています。 システム ベンダーに最も重要なビジネス上の意思決定の優先順位付けされたリストを提供できることは、プロセス全体にとって大きな前進です。 どのようなビジネス上の決定を行う必要があるかをシステム ベンダーに伝える場合、シンプルな機能について話すだけでなく、組織の効果を高める方法についても説明する権限が与えられます。

次に、各決定を見て、「そのビジネス上の決定を行うには、どのようなレポートが必要ですか?」と尋ねます。実質的にすべての決定は、1 つ以上のレポートを見た後に行われます。 3 番目の列に "レポート" というラベルを付けます。上位 3 つの決定ごとに、対応する決定に必要なレポートをその列に一覧表示します。

たとえば、特定の部署の担当者を雇用するか、消防するかを決定するには、リソース容量計画データを示す部署別のレポートが必要であるとします。 これには、予想されるワークロード、予想されるリソースの可用性、スケジュールの前方予測が含まれます。 中規模のビジネスの場合は、キャッシュ フローも懸念される可能性があります。 たとえば、追加の担当者が必要ですが、現金を見つけることができない場合があります。 キャッシュ フロー レポートには、見積もられた収入と、実行中の残高を持つ資金の流出が含まれます。

優先順位として特定した各決定の [レポート] 列に入力すると、必要なものの形が既に明確になり始めています。 完了すると、見込みシステムから必要な物理出力の一覧が表示されます。

ここでもう一度一時停止して、組織内で既に使用されていることを確認した種類のレポートが既に存在するかどうかを確認します。 このようなレポートが存在する可能性はありますが、多くの形式で、不完全なデータまたは生成に過度の労力が必要な場合があります。 組織内で機能しているレポートの形式が見つかる場合は、システム要件の一覧に追加できます。 これで、システム ベンダーにさらに多くの情報を提供できます。

主要なレポートが特定されたので、これらのレポートを生成するために必要なシステムの要素に移動できます。 グラフの 2 番目の列に見出し "Analysis" を追加します。 レポートごとに、レポートの生成に必要な分析またはアルゴリズムを特定します。 たとえば、リソース容量計画レポートの場合、プロジェクト管理システムからのクリティカル パス スケジュールとリソース 平準化分析が必要になる場合があります。

これらの分析は、多くの場合、ベンダーが、それぞれが含む無数の機能に基づいて販売されます。 (はい、機能ごとの販売はまだ健在です!決定するために必要なのは、必要なレポートを提供する最小限の機能です。これにより、特定したビジネス上の決定を行ったり改善したりできます。 実際のビジネス要件を満たすために必要な機能がいかに基本的であるかに驚くかもしれません。 一部のレポートでは、分析や計算はまったく必要ありません。レポートは、新しいシステムのデータから直接生成できる単純な集計である必要があります。

最後に、グラフの最初の列に進みます。 必要な分析を特定したら、分析にフィードするために必要なデータの要素を決定します。

グラフの 1 列目に見出し "Input" を追加します。

使用している例では、部署の作業に含まれる各プロジェクトのタスクの完全な一覧が必要になる場合があります。 これは、組織内のすべてのプロジェクトである可能性があります。 また、各リソースの可用性と、各タスクで定義されているワークロードの完全なプロファイルも必要です。これにより、スケジュール分析でタスクが移動すると、リソース 平準化分析でワークロードが移動します。 また、特定の部署で採用または解雇の決定を開始した方法を思い出してください。 また、部門別にリソースを識別できる必要もあります。

このように、右側の出力から左側の入力に移行し、新しいエンタープライズ システムで必要なものをすべて特定できます。

リスクの評価

この演習が完了したら、各入力に戻り、データのこれらの要素の利用方法を決定する価値があります。 多くの場合、これらの項目の一部が存在しない場合があります。 たとえば、一部の組織では、リソースの可用性の完全な一覧が保持されていません。 また、すべてのプロジェクトに、そのプロジェクトによって生成されたリソースの負荷を示すリソース読み込みスケジュールが設定されているわけではありません。 多くの組織では、特定の種類のプロジェクトがいかなる種類のシステムにも組み込まれません。 緊急作業、テクニカル サポート作業、または定期的なメンテナンス作業が一般的な例です。

ビジネス価値を提供するために必要な基本的なデータにアクセスできない場合は、システムのその要素を高リスクと見なす必要があります。 たとえば、組織のプロジェクトの 80% のリソース読み込みスケジュールを特定できる場合、スタッフの増減に関するビジネス上の決定を改善することが合理的に期待できますか。 答えは、"いいえ" である可能性があります。なぜでしょうか。 システムにないプロジェクトの 20% が、特定の部門の作業負荷の 80% を表している可能性があるためです。 すべてのデータがない場合、最終的なレポートが正確かどうかはわかりません。

もちろん、このような問題の周りには方法があります。 1 つの方法は、データ要素にアクセスできない組織のこれらの側面のすべてのビジネス プロセスを分離することです。 プロジェクトがシステムに存在しない可能性がある部門には、リソースも一覧表示されません。 これは、すべてのケースで簡単に行うことはできません。これらのビジネス プロセスとビジネス上の意思決定が実装に及ぶリスクを把握するには、項目ごとに確認する必要があります。 この時点で、改善したい最終的なビジネス上の決定に優先順位を付け直すのは珍しいことではありません。 非常に望ましいが、リスクが非常に高いため、デプロイの初期段階では追求する価値がない決定を下す可能性があります。

完了したことを文書化する

この種の会議を行う場合は、筆記者を割り当てます。その仕事は、プロセス全体を通してメモやコメントを記録することです。 特定のビジネス上の決定が優先度が高い、または低い優先順位としてランク付けされた理由、または高リスクと見なされた理由は、参照すべき良いメモがない場合は、すぐに忘れ去られる可能性があります。

記録することが非常に重要です。

• ホワイトボードに書かれた内容

• プロセスに参加したユーザー

• 各最終的なビジネス上の決定を所有するユーザー

この時点で圧倒されている場合は、恐れる必要はありません。 この演習全体は、大規模な組織でも、非常に迅速に実行できます。 1 日または 2 日でプロセス全体を完了できることは珍しくありません。 成功するための鍵は、適切なレベルの管理を部屋に入れることです。 さらに、この種の会議は、組織外の誰かが、常に行われているように何かをする素因のない人によって最も容易になります。

知識は力

エンタープライズ プロジェクト管理システム (実際には、あらゆる種類のエンタープライズ システム) を見ている場合、この演習を完了すると、ソフトウェア システム ベンダーと対話するときに非常に大きな力が得られるのです。 重要なシステムの要素とそうでない要素をすぐに区別できます。 ソフトウェア ベンダーは、行うレポートと決定の一覧を提供できます。

ベンダーから返される応答の一部に驚くかもしれません。 機能ごとに対応する以外の方法 (つまり、四角形の関数をラウンド要件に合わせようとする) 以外の方法で対応できるように解放されたベンダーは、システムを最大限に活用することで、ビジネス上の課題にどのように対応できるかを示すことができます。

この演習を実施する最大の利点は次のとおりです。既製の評価基準を作成しました。 これで、概念実証フェーズでは、ビジネス上の意思決定を改善するために必要な情報がシステムによって提供されるかどうかにすぐに焦点を当てることができます。

著者について

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) を参照してください。