お売りしているのは穴であり、ドリルではありません。

  • [アーティクル]

最近面白い表情に出会いました。 あるソフトウェア営業担当者は、ソリューション全体をクライアントに提供する方法について話していました。 「ドリルは販売していません。 私たちは穴を売っています」と、彼は言いました。 それは素晴らしいたとえです。 多くの人々(私が含んでいた)は、ハードウェアストアに行き、窓は、私がこの素晴らしいパワーツールを購入することを正当化するかもしれないと考えることができるプロジェクトを疑問に思いながら、パワーツール部門で買い物をしました。 しかし、このロジックを適用することは、エンタープライズ ソフトウェア システムと同じくらい理にかなっています。

問題がない場合は、解決策は必要ありません。

解決したい問題が穴を開ける場合を除き、誰もドリルを探しに行くべきではありませんが、何らかの問題を解決しない限り、誰もエンタープライズ ソフトウェアを探しに行くべきではありません。 エンタープライズ ソフトウェアの展開が修正するという問題が発生した場合、次に確認する必要があるのは、購入しているものが必要なソリューションを提供することです。 多くの場合、ソフトウェアを購入するだけではありません。

エンタープライズ システムのデプロイは複雑な課題であるため、支払いは労力を費やす価値がある必要があります。 現在のグローバル プロジェクト チームの世界では、最も一般的な作業の 1 つは、エンタープライズ システムの展開の膨大な労力を分割することです。 これにより、プロジェクトの側面で高度にトレーニングされたチームを使用する規模のメリットを得ることができますが、非常にリスクの高い方法でプロジェクトの側面を見落とすリスクも保持されます。 このリスクは、さまざまなチームが物理的および組織的に切断されるほど複合化されます。

エンタープライズ システム プロジェクトの最も一般的な要素を見てみましょう。

企業とは

まず第一に、私は企業で何を意味しますか? 私は、ほぼすべての人のために動作する必要がある定義を取ります。 このコンテキストの "エンタープライズ" は、組織全体の機能に影響を与えるプロジェクトを意味します。 これはどの組織にも当てはまると言います。 エンタープライズ実装として適格な実装は、ユーザーの数だけでなく、影響を与える程度です。 そのため、ベンダー A からベンダー B にウイルス スキャン ソフトウェアを更新することは、おそらく適格ではないでしょう。 一部のユーザー向けのデスクトップ上のプロジェクト スケジューリング ソフトウェアの実装は、適格ではない可能性があります。 プロジェクト管理を一元化し、一元化されたエンタープライズ プロジェクト管理システムを使用することは、おそらく適格です。

さて、それがエンタープライズ プロジェクトの場合、エンタープライズ システムの展開の最も一般的な要素は何ですか? オフィスで最も一般的なエクスペリエンスは、独自の TimeControl などのエンタープライズ タイムシート システムや、Microsoft Project Server などのエンタープライズ プロジェクト管理システムを展開することですが、これらの要素は、ほぼすべてのエンタープライズ システムの実装に共通します。

ビットとバイト

まず、ソフトウェアの最も基本的な構成要素である技術アーキテクチャに取り組みましょう。 最近では、オンプレミスのデプロイまたはクラウド内サブスクリプションを使用する決定に基づいて、考えを分ける必要があります。 私は、これらのうちのどれが別の日の条件の下で最適であるかを選択する不思議を残しますが、ここでは各カテゴリで考えなければならないものの基本をいくつか紹介します。

オンプレミスのインストールを行う場合は、使用するハードウェアについて考える必要があります。 メモリと CPU のハードウェア要件は何ですか? 物理サーバーまたは仮想サーバーを使用しますか? 専用サーバーを使用するか、共有しますか? どのような種類のサーバーが必要な場合がありますか? アプリケーション サーバー、セキュリティ サーバー、Web サーバー サーバーが必要ですか? 負荷分散、ディザスター リカバリー、バックアップはどうですか? コールド バックアップ サーバーまたはウォーム バックアップ サーバーが必要ですか? ふう！ しかし、私たちは終わっていない! データベースはどうですか? 要件は何ですか? 既存のセキュリティ、アプリケーション、およびデータベース アーキテクチャのサポートはどうですか? ブラウザー、ブラウザーバージョン、モバイル デバイスのサポートはどうですか? これらのすべての質問に回答したら、インストール、テスト、運用環境の問題を処理し、システムが起動して実行されたらシステムの正常性と監視を行う必要があります。

クラウド内サブスクリプションの実装を行う場合は、質問は非常に異なる場合がありますが、回答する必要があります。 どのオンライン サービスを使用しますか? 専用のインストールまたはマルチテナント サービスを使用しますか? セキュリティはどうですか? 独自の認証と統合できますか? サブスクリプション サービスでディザスター リカバリーを処理する方法 データは物理的にどこにありますか? これは私たちのために法的な問題を提示していますか? 内部ブラウザーとモバイル デバイスのサポートはどうですか? データを取得する方法と、内部データベースやその他の外部 SaaS (サービスとしてのソフトウェア) サービスと接続して機能を統合する方法

息切れしましたか? エンタープライズ システムについて説明すると、これらの質問などが議題になります。 プロジェクトのこの部分を高度なトレーニングを受けた技術チームにシフトすると、これはプロジェクト全体のスコープとして考え始めるかもしれません。これはドリルの建設に過ぎず、まだ必要な穴の作成ではありません。

自分を構成します。

システムを動作させるだけでなく、そのシステム内の機能を特定の問題に適用することもできます。 私は、クライアントが Project Server を起動して実行する Project Server の展開を見てきました。その後、ワークフローの作成、プロジェクトのポートフォリオの優先順位付け方法の学習、または単一のレポートの作成方法を学習するための資金が割り当てていないことを認識しています。 大学に戻ったシステム分析 101 と同様に、実際のビジネス上の問題を抱えているビジネスユーザーに、必要な "出力" を尋ねるように、通常はホワイト ボードの右端で実装のこの部分を開始します。 私は他の書き込みでこれについて話したので、ここで説明することはありませんが、出力は最終的にはビジネス上の決定である必要があります。 これらの決定を行うには、どのようなレポート、分析、最終的にはデータ入力が必要ですか? 画面の右側から左側に向かい、システムで構成する必要があるデータ要素、分析計算、エクスポートとレポートの形式で必要なすべての構成要素の一覧が表示されます。 この構成演習は、複雑さに応じて数週間または数か月かかることがあります。

多くの場合、このプロジェクトのこの側面に必要なリソースの種類は、ビジネス アナリストとシステムエキスパートの組み合わせです。一般的に、これらのユーザーはデプロイされるシステムの機能に高度なスキルを持っているかもしれませんが、技術的なアーキテクチャに関するスキルは高くありません。 これにより、システムの 2 つの重要な要素の切断されたチームが非常に一般的になります。 これら 2 つのグループの通信が少ないほど、後で課題に直面する可能性が高くなります。

これはプロセスです

新しいエンタープライズ システムを展開することは不可能であり、組織のプロセスには影響しません。 一元化されたエンタープライズ システムを破棄し、競合他社に移行する場合でも、プロセスは変更されます。 実際、プロセスを変更したくない場合は、解決が必要な問題を抱えておらず、ここにはまだ別の課題がある可能性があります。 人の毎日のルーチンが変わると、その人は不調を引き起こします。 私は時間の一部を意味するものではありません。 私の経験では、この変更時の不調は与えられました。 これは、 プロセスの変更によってプロセスが改善される場合でも 当てはまります。そのため、プロセスがどのように変わるかを考え、影響を受けるユーザーと連携することは、プロジェクトの成功にとって重要です。 ただし、プロセスでこの変更を設計する上で重要な専門家は、おそらくその変更の影響を受けるのと同じ人物であるため、実装の困難な側面になる可能性があります。 通常、熟練した経験豊富なファシリテーターは、内部の専門家と協力して、新しいシステムの実装で可能になったプロセスの変更を導きます。 私たちの作業ラインでは、この課題は常に見えます。 「しかし、プロジェクト マネージャーは最初にタイムシートの承認を行う必要があります」と、新しい TimeControl クライアントから通知されます。 「それが私たちのプロセスです。マトリックスの承認により、プロジェクト マネージャーがより大きく、より効果的なプロセスの一部としてタイムシートの承認を行うことができると説明すると、私たちは怒ります。プッシュ。 この時点で、最も経験豊富なスタッフの 1 人が影響を受ける人々と協力して、問題が発生し、プロセスがどのように変化するかの不可欠な部分であることを確認します。

そのため、プロセスの担当者はおそらく構成担当者 でも 技術担当者でもないと思われますが、このチームを計画していない場合は、インストールと構成に関するすべてのハード ワークはおそらくデプロイされません。 このチームも、他の 2 つのチームによるコミュニケーションと意思決定に含まれる、計画の一部である必要があります。

トレーニング

「だから、トレーニングが必要ですか?」という質問は残念ながら最後によく寄せられる質問です。 プロジェクトのその部分では多くの実践的な議論が必要なため、プロセスの変更を通じてトレーニングが行われる場合もありますが、新しいシステムがどのように機能するかの実際のユーザー ガイドはどうでしょうか。 一度に、トレーニングはソフトウェア展開の重要な要素と見なされ、クライアントは予算全体の約 20% を確保することが期待されていました。 しかし、ソフトウェアのコストとインストールの速度の変化に伴い、徐々に20%が少なくなり、お金が減りました。 システムに対してユーザーごとに月額 20 ドルを支払っている場合は、トレーニングのためにユーザー 1 人あたり 4 ドルを確保する必要がありますか? 私はそれがあまりにも遠くに行かないと約束することはできません。 トレーニングには多くのオンライン サブスクリプション オプションがありますが、設計した正確なソリューションは考慮されません。

トレーナーは、外部から来るか、プロジェクトの構成またはプロセス部分から来る場合がありますが、実装作業を実際に行った人ではなく、スペシャリストである人であることが多いです。 そのため、このチームの資金を確保したとしても(そして、私はあなたが持っていることを願っています)、これらの人々が人々をトレーニングしているシステムが実際に何をするように設計されているかを知っている必要があります。 私は、トレーナーが Microsoft Project Server に到着し、エンタープライズ フィールドを構成し、ポートフォリオ分析でビジネス ドライバーを設定する方法をユーザーに説明し始めたのを見てきました。これは、エンタープライズ フィールドがすべて既に設定されており、最初のロールアウトでポートフォリオ分析を使用する予定がないため、ユーザーに空の凝視を与えるだけです。トレーナーは、この特定のデプロイが解決すべき問題を知っていますか? 彼らはする必要があります。 プロジェクトの開始時にトレーニングを考えると、成功の可能性が最も高まります。 技術チーム、構成チーム、およびプロセス チームは、最終的に提供されるトレーニングのために、重要なデータをセクション全体を通して脇に置くことができます。 つまり、トレーニング チームが早く関与することを意味します。

ロールアウト/同意/カルチャの変更

これらのチームを開始するためのリソースを先送りして脇に置き、すべてのチームがプロジェクトを通じて連携してコミュニケーションを取っている場合、新しいシステムのロールアウトは、それ以外の場合よりもはるかにスムーズに進む可能性がありますが、文化の変化に対する抵抗を過小評価しないでください。 適切なタイミングで主要なエバンジェリストを利用できることは非常に重要です。 また、これらのチーム メンバーは全員、次のプロジェクトに進む予定ですか? プロジェクトがロールアウトされる頃には、これらの人々に多くのシステム知識が巻き込まれるでしょう。昨年の初めに私たちのクライアントの一人に特に感銘を受けました。 IT 部門は大規模な財務組織でした。 プロジェクトの早い段階でソフトウェアを評価していた主要な技術ユーザーに対する懸念の 1 つは、「プロジェクトをラップしたら管理者になる人」でした。「私は行きます」と、彼が言いました。 彼は自分の言葉に忠実でした。 彼のスキルと知識は、多か月間のデプロイを通じて進化し、大成功を収め、引き続き重要な管理者です。

折り返し

チームがコミュニケーションを取り、より大きな目標の一部として働いていることを確認する方法については、他にも 100 個の点について考慮する必要があります。これについては、いくつかお話ししました。 うまくいけば、それはあなたの次のエンタープライズシステムの展開についてすでに考えさせている。 「ドキュメントはどうですか?」と考えているかもしれません。 「テクニカル サポートはどうですか?

重要な点は、エンタープライズ システムの展開を計画する場合は、インストール作業だけでなく、完成したソリューションの提供も含むように視野を広げる必要があります。 穴が適切なサイズ、右の深さ、直角の場所に表示されていることを確認します。

筆者について

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