エンタープライズ ソフトウェアの選択に関する課題The challenges of selecting enterprise software

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. エンタープライズシステムの実装が、成功するために適応および進化できるようにする必要があることを説明します。It describes how enterprise system implementations need to able to adapt and evolve to be successful.

この記事の Word バージョンをダウンロードする方法については、「 エンタープライズソフトウェアの選択に関する課題」を参照してください。To download the Word version of this article, see The Challenges of Selecting Enterprise Software.

その他の記事については、 ホワイトペーパー「Trenches」を参照してください。To see more articles, see "From the Trenches" white papers.

エンタープライズソフトウェアを選択する際の課題The Challenges of Selecting Enterprise Software

これは、常にこの時点で発生します。It happens around here all the time. クライアントは、「提案の依頼」 (RFP) を office に送信して、数日または数週間で応答を完了して、その後にエンタープライズシステムの購入を検討するために送り返します。A client sends a "Request for Proposal" (RFP) to the office with instructions to complete a response in a few days or week and send it back to have our enterprise system considered for purchase. ほとんどの場合、Rfp は同じように見えます。RFPs pretty much all look the same. 通常、応答を考慮するために必要な作業についての説明があります。これには、書式設定の必要性や、返信のタイミングなどが含まれます。次に、必要な機能の長いグリッドと、いくつかの essay 質問を追加して回答を作成します。There's usually a brief overview, instructions on what you need to do to have your response be considered, including how it needs to be formatted and when to send it back, etc. Then there's a long grid of features that are required and a number of additional essay questions to write answers to.

Rfp に関しては、エンタープライズソフトウェアの選択には理想的ではありませんでした。また、RFP プロセスが実行されたときの ensues によって、組織にとって最適な意思決定が保証されていない場合もあります。The challenge with RFPs is that they weren't ideally suited for selecting enterprise software, and what ensues when an RFP process is followed doesn't guarantee the best decisions for the organization. Rfp は、最高の価格で最高の商品を取得し、それを引き続き実行する方法として、購入コミュニティによって設計されています。RFPs were designed by the purchasing community as a way to get the best commodity at the best price and they still do a great job of that. これらのオファーリングが同等である場合、意思決定プロセスは、1つまたは2つの追加の変数 (出荷日など) にのみ対応できる最良の価格に焦点を当てることができます。When the offerings are comparable, then the decision-making process can focus on the best price with only one or two additional variables (such as shipping dates) to contend with. 可能なソリューションが同じ一般的なカテゴリにあり、同等ではない (エンタープライズソフトウェアの場合と同様) 場合、purchasers で考慮する必要のある変数の数は非常に大きく、RFP プロセスは選択範囲の値を追加しません。When the possible solutions are in the same general category but not at all comparable (as is the case with enterprise software), then the number of variables that must be considered by purchasers is huge and the RFP process doesn't add value to the selection. ほとんどの企業がエンタープライズソフトウェアを選択する方法エンタープライズソフトウェアのすべてのベンダーまたはソリューションプロバイダーで常に発生するプロセスを見てみましょう。How most companies select enterprise software Let's start by looking at the process that happens all the time in any vendor or solutions provider of enterprise software. エンタープライズプロジェクト管理ソフトウェアまたはエンタープライズタイムシートソフトウェアについては、お客様の企業が提供するものと同じですが、実質的にすべてのエンタープライズシステムの選択について同じパラダイムがあります。I'll be talking about enterprise project management software or enterprise timesheet software as that's what my firm provides, but the paradigm is the same for virtually any enterprise system selection.

ほとんどの企業がエンタープライズソフトウェアを選択する方法How most companies select enterprise software

最初に、エンタープライズソフトウェアのベンダーまたはソリューションプロバイダーのすべての時間に発生するプロセスを見てみましょう。Let's start by looking at the process that happens all the time in any vendor or solutions provider of enterprise software. エンタープライズプロジェクト管理ソフトウェアまたはエンタープライズタイムシートソフトウェアについては、お客様の企業が提供するものと同じですが、実質的にすべてのエンタープライズシステムの選択について同じパラダイムがあります。I'll be talking about enterprise project management software or enterprise timesheet software as that's what my firm provides, but the paradigm is the same for virtually any enterprise system selection.

ほとんどの組織では、エンタープライズソフトウェアを検索する impetus に問題があります。In most organizations, the impetus to look for enterprise software comes from some problem. この問題は、フィールド担当者によって表面化した可能性があります。Perhaps the problem is surfaced by the field personnel. この問題は、上級管理者によって特定された可能性があります。Perhaps the problem is identified by someone in senior management. しかし、イニシアチブでは上級管理職のユーザーからサポートを受ける必要があります。However it happens, the initiative has to get support from someone in senior management. Grassroots エンタープライズ全体に影響を与えるシステムの選択は、fantasy の中でも、多くのプログレッシブ組織で行われます。Grassroots selection of a system that will affect the entire enterprise is a fantasy in even the most progressive organizations. シニアマネージャーは、"この種のエンタープライズシステムを必要とします" と判断します。So a senior manager decides, "we need this kind of enterprise system."

一般的なエンタープライズソフトウェア選択プロセスは、次のようになります。The typical enterprise software selection process goes like this:

  1. 管理には、新しいエンタープライズシステムが必要であるという通知があります。Management says we need a new enterprise system

  2. 選択されたプロジェクトマネージャーProject manager is selected

  3. 関係するすべての部門からの要求を要請するSolicit requests from all departments involved

  4. すべての要求を1つの大きなスプレッドシートに結合するMerge all requests into one large spreadsheet

  5. 多くのベンダーに要件グリッドを送信するSend the requirements grid to lots of vendors

  6. 多くの応答を取得するGet lots of responses

  7. 短いリストShort list

  8. 観デモンストレーションWatch demonstrations

  9. 取り決めNegotiate

  10. 管理の受け入れの取得Get management acceptance

  11. 他のものについて管理を決定するHave management decide on something else

選択作業のプロジェクトマネージャーは volunteered です。A project manager for the selection effort is volunteered. すべての操作を行いますが、インターネットにアクセスして、検索エンジンと種類「EPM Software」 (または、どのエンタープライズシステムが必要か) を読み込みます。He or she does what we all do —go to the Internet, load up a search engine and type in "EPM Software" (or whatever enterprise system is desired). すぐに、半数万個のヒットが返されます。Immediately a half-million hits are returned. おそらく、入念なプロジェクトマネージャーが最初に必要とするシステムの種類については、「」を参照してください。Perhaps the diligent project manager surfs the first dozen or so to learn what kind of systems might be available before moving on. すぐには、半数万以上のヒットを見て、組織にとって最適なシステムであるかどうかを確認することはできません。Clearly no one has the time to surf through a half-million or more hits to see if perhaps the very last one is the ideal system for the organization.

Undaunted、プロジェクトマネージャーは現在、この新しいエンタープライズシステムの実装によって影響を受けるユーザーの選択委員会を組み立てます。Undaunted, the project manager now assembles a selection committee from among those who will be affected by the implementation of this new enterprise system. 委員会のメンバーの中には、組織での必要性を最初に特定した現場担当者がいる場合があります。Some of those on the committee may be from among field personnel who identified the need in the organization in the first place. それ以外の場合もあります。Others may not. この選択委員会では、選択されるシステムの種類にさまざまな関心があるユーザーが混在している可能性があります。There may be a mix of people on this selection committee who have diverse interests in what kind of system will be selected.

Hapless プロジェクトマネージャーは、新しいエンタープライズシステムで必要なことを確認するために、委員会の各メンバーを solicits して、それぞれの担当者グループをポーリングするようになりました。The hapless project manager now solicits each member of the committee to poll their representative group for what they require in the new enterprise system. 各委員会の担当者はどのようにしますか?How does each committee representative do this? 最初にすべてのユーザーが同じ作業をするわけではありませんが、自分の宿題をする場合は、重要な機能の一覧を提出するようにスタッフに依頼します。Well, first of all, not everyone puts in the same effort but for those who do their homework, they ask their staff to submit a list of features that they would find important. また、インターネットを検索して、いくつかのベンダー Web サイトを閲覧することもできます。Then they, too, hit the Internet and surf some vendor Web sites. これらのサイトのパンフレットに表示される機能は、サイトごとに、新しいシステムに対して作成できる要求の種類に関する新しいアイデアが提供されるため、コピーして貼り付けることができます。They can copy and paste from features they see in the brochures of these sites as each site gives them new ideas of what kinds of requests they might be able to make of a new system.

これで、委員会が再構築され、各分科会メンバーの長いスプレッドシートが他の1つの巨大なスプレッドシートにマージされます。Now the committee is reassembled and the long spreadsheet of each committee member is merged with the others into one massive spreadsheet. 要件のメガスプレッドシートは分類されていますが、課題があります。The mega-spreadsheet of requirements is categorized, but there are challenges. 最初に、さまざまな視点から機能が要求されるので、委員会のさまざまなニーズがより明確になります。First of all the diverse needs of the committee now become more apparent as features are requested from a wide range of perspectives. さまざまな部署に分科会メンバーが存在する場合もありますが、国や部署が異なる場合もあります。There may be committee members in different departments but also in different countries or even different divisions. ほぼすべての要求が同じリスト内の別の要求と競合している (たとえば、システムが非常に簡単で、多くの音声ガイダンスを必要とせず、システムがユーザーごとに大量のオプションを使用する必要がある場合など)。There is almost always a request which is at conflict with another request in the same list (e.g., the system should be very easy and not have many prompts and the system should be very flexible with a large number of options for each user).

最後に、ベンダーによって表示される結合スプレッドシートは完成です。Finally the combined spreadsheet that the vendors will see is complete. 何百もの機能の要求があり、ベンダーは "はい"、"いいえ"、または "はい" を言うことが期待されます。It has hundreds of feature requests and for each one the vendor will be expected to say "Yes", "No" or "Yes with some effort". また、この機能が "必要なもの" かどうか、"重要な場合" または "いいね!" であるかどうかを指定する重み付けシステムを添付することもできます。A weighting system may also be attached to say whether this feature is a "Must-have", an "Important-to-have" or a "Nice-to-have".

フィーチャー選択スプレッドシートのスニペット

RFP は、ほぼ準備完了です。The RFP is almost ready to go. Essay に関するいくつかの質問があります。通常は、選択された技術アーキテクチャについて説明し、これらの要件についてポーリングしたユーザーの数によっては、アーキテクチャ要求の競合が発生することがあります (たとえば、システムが SQL Server データベース¬に保存されているすべてのデータを保持し、システムでユーザーのThere will be a few essay questions, usually about the technical architecture of the selection and, depending on how many people were polled about these requirements, the architecture requests can be equally conflicted (e.g. The system must have all data stored centrally in the SQL Server database ¬and¬ the system must allow any data to be stored locally on the user's computer).

実際には、これまでにずっとすばらしいことになります。Actually, it's sounding pretty good so far, don't you think? 結局のところ、必要なすべての機能を提供できるユーザーを示す一連のベンダー応答を取得する予定です。After all, we're going to get back a bunch of vendor responses that show who can deliver all the features that we'll need. 実際には、これまでにずっとすばらしいことになります。Actually, it's sounding pretty good so far, don't you think? 結局のところ、必要なすべての機能を提供できるユーザーを示す一連のベンダー応答を取得する予定です。After all, we're going to get back a bunch of vendor responses that show who can deliver all the features that we'll need.

しかし、これまでに説明したように、企業システムではなく商品に対して RFP プロセスを使用しているときには発生しない問題があります。But there's actually a fundamental problem with what I've described thus far: A problem that doesn't occur when we're using the RFP process for a commodity rather than an enterprise system. これは、エンタープライズシステムは何らかの解決策です。It's this: An enterprise system is a solution to something. しかし、この問題については現時点では何も言われていません。But we've said nothing so far about the problem. これは、テクノロジ業界が通常どおりに受け入れられるようになる一般的な出来事です。This is such a common occurrence that the technology industry has come to accept it as normal and acceptable.

方法が機能しないエンタープライズソフトウェアを選択する理由Why selecting enterprise software that way doesn't work

Purchasers は、数十年にわたりこの方法を使用していますが、お客に質問することはありませんが、エンタープライズソフトウェア会社のユーザーは、エンタープライズソフトウェアを選択する従来の RFP の方法に関する基本的な問題があることを認識しています。Purchasers have been using this method for decades and no one questions it, but people in the enterprise software business know there is a fundamental problem with the classic RFP method of selecting enterprise software.

最初に、非常に長い機能の一覧があるため、ビジネス上の問題を解決することがこれまでにないことを意味するわけではありません。First of all, just because you have an enormously long list of features, it does not necessarily mean that you are any closer to solving a business problem. 実際には、解決しようとしている特定のビジネス上の問題を明確にしていない場合は、より複雑で、最終的にはさらに悪いものになる可能性が高くなります。In fact, if you haven't even articulated what specific business problems you are trying to solve, then you are likely to make things more complex and ultimately worse, not better. RFP プロセスは、commodities を購入するように設計されています。The RFP process was designed to purchase commodities. 靴、potatoes、または砂糖などの同種の製品を購入した場合、このようにこれらの項目を購入すると、最低価格の入札者と、考えられるサプライヤーからの選択が最適になります。When we've got homogeneous products like shoes or potatoes or sugar, then purchasing these items in this way can result in the lowest-cost bidder and the best selection from among the possible suppliers. 同様の商品の RFP に対する応答により、可能な業者の比較が非常に簡単になります。The responses to an RFP for a similar commodity makes comparing possible suppliers very easy. 混合の各製品の変数が無限である場合 (エンタープライズソフトウェアの場合)、RFP に対する応答には無限の変数があるので、プロセスによって結果が得られる結果はほとんどないことになります。When the variables for each product in the mix are infinite (as they are with enterprise software) then the responses to the RFP have an infinite number of variables also and the process yields results that have little value.

エンタープライズシステムを選択する RFP メソッドを使用すると、ほとんどの場合、Rfp は同じように表示されます。When we use the RFP method of selecting enterprise systems, the RFPs mostly all look the same. これは、すべてが同じ刺激への応答として作成されるためです。This is because they are all created in response to the same stimulus. プロジェクトマネージャーは、「このエンタープライズシステムで必要なこと」のリストと、最も大規模なマネージャーが要求に応答する必要がある唯一の語彙を、機能のリストとして要求します。The project manager requests a list of 'what you will need in this enterprise system' and the only vocabulary most middle managers have to respond to that request is a list of features. そのため、Rfp への返信はすべて同じように表示されます。Consequently, the responses to RFPs all look the same. これらは、システムの一部として、または何らかの労力でシステムの一部として使用可能なすべての機能のチェックリストです。They're a checklist of all the features available either as part of the system or as part of the system with some effort.

選択チームにとって最も一般的なものは、自分の Rfp に対して多数の応答を受信することで、何百ものページを処理し、完成したときに、開始したときよりもソリューションに近いと思われないようにすることです。What is most common for selection teams is that they will receive a number of responses to their RFPs, they'll wade through the hundreds of pages and, when they're finished, they won't feel any closer to a solution than when they started. これは、提案の公正な要求になるものを作成すること、および naught のために演習が行われたことを確認するために、その答えを評価するのに膨大な労力を purchasers ために非常に苦労しています。This is terribly frustrating for purchasers who put in enormous effort in creating what should be a fair request for proposal and in evaluating the answers only to find that the exercise was for naught.

このようなことは、経験のある企業の営業担当者は、不満のある結果を得て、RFP が作成された瞬間から機能するということです。Worse than all of this is that experienced enterprise salespeople know the process will yield frustrating results and are at work from the moment they hear there will be an RFP created. これらのユーザーは、RFP 応答の処理を行っていません。They're not working on the RFP response. これは関係ありません。That's not relevant. その代わりに、管理構造で2つまたは3つのレベルで作業し、RFP を開始した元の impetus を探します。Instead, they are working two or three levels higher in the management structure, looking for the original impetus that got the RFP started. ビジネス上の課題があるシニアエグゼクティブを探し、purchasers やその他の中央管理スタッフが最終的に RFP を作成してベンダーに送信するように、モーションの車輪を設定します。They look for the senior executive who articulated some business challenge and set the wheels in motion so that purchasers and other middle-management staff would ultimately create the RFP and send it out to vendors.

RFP の応答が、購入プロセスでほとんど行われていないビジネス上の問題に対して明確な回答を行わない場合、エンタープライズの営業担当者はアクションに移行する準備ができ、シニアエグゼクティブがプロセスを完全にバイパスして、シニアエンタープライズの営業担当者との独自の関係に基づいてシステムを選択します。When the RFP responses end up without a clear answer to the business problems that are almost never articulated within the purchasing process, the enterprise salesperson is ready to leap into action, having a senior executive bypass the process altogether and select a system based on their own personal relationship with the senior enterprise salesperson.

このサウンドを使用していない場合は、正しく動作していません。If you think this sounds jaded, you're wrong. 実際には、RFP プロセスでの購入と比較して、経営陣レベルで個人の関係によってソフトウェアを選択することをお勧めします。In fact, you can make a better case for having software selected through personal relationships at the executive level than you can for buying through the RFP process.

しかし、概念実証やパイロットについてはどうでしょうか。But what about a Proof of Concept or Pilot?

そのため、エンタープライズソフトウェアの購入に適用すると、従来の購入プロセスに不備があることがわかっています。So, we know the classic purchasing process is flawed when we apply it to the purchase of enterprise software. その場合は、エンタープライズプロジェクト管理システムなどのエンタープライズソフトウェアをどのように選択する必要がありますか。If that's the case, how should we choose enterprise software such as an enterprise project management system? 一般的な方法は、概念実証またはパイロットフェーズの方法を使用することです。A popular method is to use the Proof of Concept or Pilot Phase method.

これらの2つの用語はよく synonymously を使用しているため、まず、概念実証やパイロット展開について説明します。These two terms are often used synonymously, so let's start off by talking about what is a Proof of Concept or a Pilot deployment.

概念実証Proof of Concept. 概念実証では、ソリューションがそのような課題を解決できるという技術的な問題が発生していることを証明するために、組織はエンタープライズソフトウェアを限定的な方法で展開します。In a Proof of Concept, the prospective organization deploys the enterprise software in a limited fashion in order to prove that it can accomplish a technical challenge where there is some question as to the solution's ability to overcome that challenge. 例として、データボリュームが考えられます。An example might be for data volume. 「製品は、プロジェクトごとの多くのタスクを処理できない可能性があることを懸念しています。"We're concerned that the product might not be able to handle as many tasks as we have per project. このソフトウェアには、2つまたは3つのプロジェクトのうち、それぞれ500のタスクが含まれています。これらをソフトウェアに組み込む方法を示しています。また、ソフトウェアがこのボリュームでこのボリュームを使用して基本的な機能を実行することもできます。We'd like you to come with the software, take two or three example projects with 500 tasks each and show us how these can be loaded into to the software and that the software can still perform its basic functions with this volume in it."

パイロットフェーズPilot Phase. パイロットフェーズは、エンタープライズソフトウェアをインストールしたものですが、範囲が制限されています。A Pilot Phase is an installation of the enterprise software but with a limited scope. パイロット展開は、ユーザーのサブセットに対して行われる場合があります。たとえば、10分の1人1000のユーザーのみが、4週間の期間、ソフトウェアを完全に使用します。A pilot deployment might be for a subset of users; for example only 10 out of 1000 people will use the software fully for a four-week period. または、機能のサブセクションやデータの一部を対象とする場合もあります。たとえば、10個の500プロジェクトのみがロードされます。Or, it might be for a subsection of the functionality or a subset of the volume of data; for example only 10 out of 500 projects will be loaded.

概念実証またはパイロットフェーズをどのように使用しますか?How is the Proof of Concept or Pilot Phase used? 多くの場合、パイロットフェーズまたは概念実証の適用方法に関する問題が発生します。The problem that is often encountered is how the Pilot Phase or Proof of Concept is applied. 考えられる組織が、概念提案の証明を求めていて、どのような技術的概念を実証する必要があるかを判断することは、非常にまれです。It is quite rare when a prospective organization calls and asks us for a Proof of Concept proposal and can also identify what technical concept needs to be proven. 「期待していることは何か、実証されたことをどのように測定できるか」というものです。"What are you hoping to prove and how will we be able to measure that we've proven it?" 求められます。we ask.

最も一般的なのは、中央管理者が組織の生活を容易にすることを望んでいるエンタープライズソフトウェアを特定したことです。What is most common is that someone in middle management has identified a piece of enterprise software that they hope will make their lives easier in their organization. 上級管理者は関係のあるものではありません。また、中央の管理スタッフは、克服しようとしているビジネス上の課題さえも理解していません。Senior management is not at all involved, and the middle management staff have not even articulated what business challenges they are trying to overcome. ソリューションが建物だけに配置されていた場合は、次に管理者が corridor を下に移動したときに、誤ってソリューションが表示され、エンタープライズ展開にすぐに blessing を与えることができるようになります。It is their hope that if the solution was just in the building, that the next time someone from management would wander down the corridor, they would 'accidentally' see the solution in operation and would instantly give their blessing to an enterprise deployment. 夢の映画のフィールドから語句を借りるには、「作成した場合は、それを取得する」というようにします。To borrow a phrase from the movie Field of Dreams, "If we build it, they will come."

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

成功することはほとんどありません。It is rarely successful. エンタープライズソフトウェアに関する問題は、展開を成功させるために上級管理者の関与が必要になることです。The problem with enterprise software is that we need senior management's involvement to make the deployment a success. これは、このエンタープライズシステムからのレポートと分析の「クライアント」である上級管理者です。It is senior management who will be the 'clients' of the reports and analysis from this enterprise system. 上級管理者は、企業のソフトウェアで設計、構成、およびトレーニングを行うために必要な時間を、ある範囲のスタッフに許可するために、個人に投資する必要があります。It is senior management who will need to invest personally to allow a range of staff the time required to design, configure and be trained in the enterprise software. これは上級管理者であり、企業のシステム展開の一部であるビジネスプロセスの再設計に役立てる必要があります。It is senior management who will have to accept or even help redesign the business processes that are part of any enterprise system deployment. 上級管理者が blessing だけでなく、暗黙のサポートや直接支援を提供していない場合は、概念実証は役立ちません。Without senior management giving not just their blessing but also their implicit support and direct assistance, no proof of concept will help.

これはパイロットフェーズにも当てはまります。This is true also for a pilot phase. 企業がエンタープライズソフトウェアを使用してビジネス上の問題を解決するために最上位レベルからコミットされていない場合、パイロットフェーズの導入は生産性の高いものではありません。If the company has not committed from the highest level to solving some business problem through the use of enterprise software, then the introduction of a pilot phase is not productive.

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

これは、展開のパイロットフェーズが配置されていないということではありません。This is not to say that pilot phases of a deployment have no place. これらのユーザーは、正常な展開で重要なスポットを受けます。They do carry a critical spot in a successful deployment. これは、購入の決定が完了し、企業システムの設計が完了した直後になります。That place is immediately after the purchase decision is complete and the design of the enterprise system has been concluded. パイロットフェーズでは、エンタープライズシステム設計をテストし、一般的な展開のために微調整するための優れた場所を作成しました。Now a pilot phase makes a great place to test out our enterprise system design and fine tune it for general deployment.

パイロットフェーズを期待して実行することによって、ソフトウェアの動作が管理されることを期待している場合は、無効なパイロットが行われ、選択プロセスがこれ以上行われません。When a pilot phase is done in the hope that seeing the software in action will result in management selecting it, then we have an ineffective Pilot and will get no further ahead in the selection process.

組織がエンタープライズソフトウェアを選択する方法How should organizations select enterprise software?

エンタープライズシステムは、中部から大規模の組織で毎日購入されており、RFP の方法が最も効果的ではない場合でも、非常に効果的なエンタープライズソフトウェアを選択する方法がいくつかあります。Enterprise systems are purchased by middle- to large-sized organizations every day and, while the RFP method may not be the most effective, there are several methods of selecting enterprise software that are very effective. ここでは、効果的なエンタープライズ選択プロセスを作成するためのヒントをいくつか紹介します。Here are a few tips for creating your own effective enterprise selection process.

  • 問題を明確にします。Articulate the Problem. 最初に、問題を明確にします。First and foremost, articulate the problem. これは、上級管理が関係していて、ビジネス上の問題によってビジネス上の問題が発生する可能性があることを意味します。This means that senior management must be involved and the problem to articulate is a business problem so it should be articulated in business terms. 質問が1つよくあることは、「どのようなビジネス上の意思決定でも可能ではないか、または大きな問題が生じた場合にのみ、このエンタープライズシステムソリューションの展開によって eased する可能性があるか」ということです。One good question to ask is, "What business decision can we not make now or can we make only with great difficulty, the making of which could be eased with the deployment of this enterprise system solution?"

    このエンタープライズシステムを使用して解決する必要がある一連のビジネス上の問題が存在する可能性があります。There may be a series of business challenges that you wish to solve with the use of this enterprise system.

  • ベンダーに、ソリューションを作成するための latitude を提供します。Give vendors some latitude to create the solution. ビジネス上の問題や問題が発生したことがある場合は、ベンダーに連絡して、プロセスを支援した上級管理者へのアクセスが透過的であることを確認してください。Once the business problem or problems have been articulated, contact possible vendors and make sure the access to the senior management who assisted in the process is transparent. 管理が開始時からのプロセスの一部である場合は、上級管理職との "シークレット" ベンダーミーティングは不可能になります。"Secret" vendor meetings with senior management become impossible when management is part of the process from the beginning. ベンダーに問題を認識させ、その答えに latitude を与えることができます。Let the vendors understand the problem and give them some latitude in answering it. 潜在的なベンダーに対してソリューションを説明しようとしない場合は、これらのビジネスの課題が実現するにつれて、お客様の問題にどのように影響するかを説明します。You may find out more about your organization in explaining how these business challenges affect you than you realize and you will certainly see a much wider range of possible solutions to your problem when you don't try to describe the solution to the potential vendors.

    考えられるソリューションプロバイダーについて話し合う場合は、テクノロジとビジネスプロセスの両方の課題について話し合う必要があることを必ず理解しておいてください。When you talk to possible solution providers, make sure they understand that they must speak to both the technology and the business process challenge. 組織のプロセスに影響を与えないエンタープライズシステムソリューションは存在しませんでした。There has never been an enterprise system solution that didn't have some impact on the organization's process. ソリューションプロバイダーがプロセスにどのような影響を与えるかがわからない場合は、ソリューションの一部のみを見ることになります。If the solution provider can't help with how the process will be affected, then you're only looking at part of the solution.

  • いくつかのユーザーに会うGo meet some people. 考えられるいくつかのソリューションプロバイダーに移動したら、既存のクライアントの一部について話し合うように依頼します。When you get down to a couple of possible solution providers, ask to talk to some of their existing clients. さらに、ベンダーが既存のクライアントの一部にアクセスできるかどうかを確認してください。Even better, see if the vendor will let you go visit some of their existing clients. 適切なソリューションプロバイダーでは、多くの場合、独自の展開で成功しているクライアントがあります。また、予想されるクライアントを満たすのに十分な時間を確保できます。Good solution providers often have clients who have had success in their own deployments and who are generous enough to make time to meet prospective clients.

    提案されているソリューションの経験豊富なクライアントでは、多くの場合、RFP の回答を読んだり、ベンダーのセールスデモンストレーションを参照したりすることによって得られたものよりも多くの時間を使用できます。You'll learn more from a couple of hours with an experienced client of the possible solution than you would have ever learned from reading RFP responses or looking at vendor sales demonstrations. クライアント参照やサイトの訪問に関してベンダーに質問すると、会議の理想的な企業が自分のものと同じになると考えられるかもしれません。When you ask the vendor for possible client references and site visits, you might think the ideal company to meet would be one exactly like yours. これは必ずしもそうではありません。That's not always the case.

多くの場合、他の業界に関連する、または少し似ている企業を満足させることは非常に重要です。It's often extremely valuable to meet companies in other industries that are related or somewhat similar to yours. また、より大規模な組織や、それよりも小さい組織の場合もあります。You might also learn lots from organizations who are bigger or smaller than you are. どの程度の経験を使用しているか、または正確なサイズであるか、または正確な業種であるかによって、組織がどの程度の経験を使用していたかについて、より多くのことを強調します。Place more emphasis on how much experience the organization has had with the solution rather than what version they're using or whether they're of the exact size or in the exact industry you're in.

既存のクライアントにアクセスするのに十分な運がある場合は、ベンダーではないことに注意してください。If you are lucky enough to visit an existing client, remember that it's not the vendor. Respectful および courteous と thankful。Be respectful and courteous and thankful. 小規模なプレゼント (たとえば、会社のロゴの販促材料) を提供することはよくあります。Bringing a small gift, perhaps of company logo promotional material is often well appreciated. 組織を使用しているとき、または電話での参照に向かっている間に、次のような質問があります。While you're with the organization or while talking to references on the phone, some possible questions might include:

  1. 他のユーザーとの間でこのソリューションを選択するためにどのようなプロセスを使用しましたか?What process did you use to select this solution over others?

  2. このソリューションによってビジネスプロセスがどのような影響を受けるか。What impact has this solution had on your business processes?

  3. 展開の最も困難な側面は何ですか。What was the most challenging aspect of the deployment?

  4. これまでに最も重要な投資収益率What was the most valuable return on investment thus far?

  5. ここから、ソリューションをどのように表示しますか?How do you see the solution evolving from here?

満足のいくだけではありません。Don't expect only happy answers.

参照を完全に提供できないベンダーは、多くのユーザーが満足しているクライアントよりもやや疑わしいことがあります。A vendor who is completely unable to provide references has to be somewhat more suspect than one who has a number of satisfied clients.

最後に、選択した時点で、フェーズごとにを展開します。Finally, when you've made your selection, deploy in phases. このコラムの他の記事については、段階的なモードでの展開方法を参照してください。You can find other articles in this column on how to deploy in a phased vs. big-bang mode. これにより、企業システムの展開に伴うリスクが軽減され、システムの進化に伴って展開プロセスを微調整することができます。This will mitigate the risks involved in any enterprise system deployment and help fine-tune the deployment process as the system evolves.

エンタープライズシステムの展開は、すべて動的なプロセスであることに注意してください。Remember that any enterprise system deployment is a dynamic process. これは、月に1回の検索結果があるかどうかについては、1回限りの判断ではありません。It's not a one-time decision with happy results arriving month after month forevermore. 最も成功するエンタープライズ展開は、最も熟練した管理の展開プロセスの一部となる主要な担当者を対象とした選択から始まり、フェーズ後フェーズでのシステムの進化を続けます。The most successful enterprise deployments start with a selection that involves the key personnel who will be a part of the deployment process from the most senior in management to the most tactical in the field and continue through the evolution of the system in phase after phase.

効果的なエンタープライズシステムの選択は、プロセスの最初のフェーズにすぎません。An effective enterprise system selection is only the first phase of the process.

著者についてAbout the Author

Chris Vandersluis 氏は、Microsoft 認定パートナーである、カナダベースの HMS ソフトウェアである Montreal、創設者の社長およびです。Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. McGill 大学と30年以上のプロジェクト管理システムの自動化において、経済の学位が得られています。He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. プロジェクト管理協会 (PMI) の長期のメンバーであり、Microsoft Project ユーザーグループ (MPUG) の Montreal、トロント、およびケベックの章を見つけました。He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Chris が執筆した刊行物には、フォーチュン、ヘビー建設ニュース、コンピューティングカナダ雑誌、PMI の PMNetwork などが含まれており、彼はプロジェクトの時間の正規の columnist です。Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. McGill 大学の高度なプロジェクト管理を指導しており、北アメリカと世界各地のプロジェクト管理関連機能で講演していることがよくあります。He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software は、TimeControl のプロジェクト指向の timekeeping システムの発行者であり、1995以降の Microsoft Project Solution Partner になっています。HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis 氏は、次の場所に電子メールで連絡することができます。 chris.vandersluis@hms.caChris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

Chris Vandersluis 氏がより多くの EPM 関連記事を読む場合は、「HMS の EPM ガイダンスサイト (」を参照してください https://www.epmguidance.com/?page_id=39) 。If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (https://www.epmguidance.com/?page_id=39).