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

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. 簡単に理解できるビジネス分析方法を適用して、ソフトウェア purchasers がソフトウェアベンダーとの対話をより効果的にする方法について説明します。It describes how prospective software purchasers can make interactions with software vendors more effective by applying easily understood business analysis methods. このホワイト ペーパーを利用すれば、ソフトウェア ソリューションでどんな問題に取り組むべきかを効果的に判断することでソフトウェア評価基準が作成しやすくなります。It walks you through an exercise that can help create software evaluation criteria by effectively determining what problems need to be addressed by the software solution.

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

ソリューションの購入者になるBeing a Solutions Buyer

多くの場合、ソフトウェアの購入は、機能の一覧、広告キャンペーン、または友人の推奨事項に基づいて行われます。All too often, a software purchase is based on a list of features, an advertising campaign, or a friend's recommendation. この記事では、簡単に理解できるビジネス分析方法を適用して、ソフトウェア purchasers がソフトウェアベンダーとの対話をより効果的にする方法について説明します。This article describes how prospective software purchasers can make interactions with software vendors more effective by applying easily understood business analysis methods.

のように使用されているのではありません。It's sure not like it used to be. エンタープライズ設定でのソフトウェアの使用は、インストールとも呼ばれません。Getting software working in an enterprise setting isn't even referred to as installation any more. 今日では、新しいパッケージを起動して実行するために必要なものについて、実装または展開という用語が適しています。Nowadays, the terms implementation or deployment better describe what is needed to get a new package up and running.

ソリューションとして販売しているものについて、ソフトウェアベンダーの話が多いほど、不思議なことはありません。More and more software vendors are speaking about what they sell as solutions, and it's no wonder. Microsoft Project Server または Microsoft CRM などのエンタープライズシステムの展開について考えている場合は、まず、関係するテクノロジのさまざまな層について検討する必要があります。また、それに到達する前に、ビジネス全体への影響について検討する必要があります。When we think about deploying an enterprise system like Microsoft Project Server or Microsoft CRM, we have to first think about the different layers of technology that will be involved, and—before we even get to that—we have to think about the impact on our overall business.

セールスするソリューションについては、もちろんソリューション sales をご用意しています。With solutions to sell comes, of course, solutions sales. これをすべて実行した場合は、大規模な組織を対象とする地球上のほとんどすべてのハイテク組織が、ソリューション sales deliverer として自身を再作成していることになることがわかります。If you've followed this at all, you know that almost every high tech organization on the planet that targets mid to large organizations is working to re-create itself as a solutions sales deliverer. マイクロソフトは、これらの組織の中でも確実にご活用ください。Microsoft is certainly among these organizations. Microsoft は過去数年間にわたり、フィールド販売および実装の取り組みの指針となるソリューションを確立してきました。Microsoft has worked extensively over the last few years to establish solutions selling as a guiding principle in its field sales and implementation forces.

ソリューション担当者とは何ですか。So what is a solutions salesperson? その場合でも、営業担当者のことです。It's true they're still a salesperson. ただし、ソリューションの営業担当者は、ソフトウェアのボックスを移動するだけではなく、クライアントの状況を改善するための方法を構築することを目的としています。However, solutions salespeople aim not just to move a box of software, but to build something that helps the client improve their situation.

これまでに大きな効果があります。Nirvana のすべての営業担当者が、生活をさらに充実させることに注目しています。Sounds great so far; a Nirvana of salespeople all looking to improve your lot in life. しかし、これには課題がありますが、その課題に対処することは、考えられるクライアントとして参加することができます。But this does come with a challenge, and addressing that challenge is something in which you—the prospective client—can participate.

問題の焦点Focusing on the problem

ほとんどのソリューション営業担当者が市場に到着したときに直面する課題は、ソリューションがどのようなものになるかについての事前の構想です。The challenge that most solutions salespeople face when they arrive to the market is our preconception about what a solution should look like. ソフトウェアの機能を重視するために、ソフトウェアの営業担当者と話をしているときに、「お客様のソフトウェアでこれを行うことはできますか」ということになります。We're so used to focusing on functions and features of software, when we speak to a software salesperson the conversation almost inevitably leads directly to, "Can your software do this? ソフトウェアでは、これを実行できますか。Can your software do that?" 経験豊富なソフトウェア営業担当者 (ソリューション販売の分野に移行される) は、多くのお客様にとって最も基本的な質問にお答えすることを忘れてきた機能や機能を販売するために使用されます。「問題点」Experienced software salespeople—and those are the types who are moved into solutions selling positions—are so used to selling functions and features that they often forget to ask the most basic question of all: "What is the problem?"

今のところ、これはばかげたことになりますが、ソフトウェア販売員との最後のいくつかの会話についてよく考えた場合は、この質問が表示されるまでに驚かれるかもしれません。Now this may sound silly, but if you think about your last few conversations with software salespeople, you might be surprised at how rarely this question comes up. Microsoft とそのパートナーのようなベンダーは、毎年、提案について多くの要求を受け取ります。Vendors like Microsoft and its partners receive many Requests for Proposals each year. 数百のユーザーが何年も見てきましたが、ほとんど常に表示されているものは、ベンダーが入力することが期待される関数の長いグリッドです。I've seen hundreds of them over the years, and one thing that is almost always present is a long grid of functions that the vendor is expected to fill in. 多くの場合、この大きなスプレッドシートはクライアントへの返信の中核となります。This large spreadsheet often is the core of the reply to the client.

めったに存在しないものは、これらの各機能によって対処されるビジネスニーズの説明です。What is rarely present is a description of the business needs that will be addressed by each of these functions. これは、以前の製品から学んだ機能で、または、この新しい製品に関する関心事項に焦点を当てるために実際の統制に重点を置くことができるようになりました。It's so easy to get caught up in a feature we're familiar with from a previous product or that we've seen promoted somewhere that it takes real discipline to focus on what got us interested in this new product in first place. これは特に、どの種類のソリューションを検索するかについて多くの入力があるエンタープライズ設定では、特に役立ちます。This can be especially so in an enterprise setting where there is a lot of input into what type of solution is being sought. ユーザーに対して、特定のビジネスニーズについて説明するのではなく、新しいソフトウェアシステムに含まれるすべての機能を一覧表示するように求める要求を送信する方がはるかに簡単です。It's much easier to send out a request asking for people to list all the functions that they'd like in a new software system than it is to talk about their particular business needs.

何らかの問題が見つからないと考えられる場合は、それだけではありません。If you're starting to think that perhaps you've been missing something obvious, you're not alone. この条件は、ビジネスアナリストと呼ばれるコンサルタントの新しいカテゴリが sprung 発生した時点で、ソフトウェア業界で普及しています。This condition is so prevalent in the software industry at the moment that a new category of consultant called Business Analyst has sprung up. これらのユーザーは、ビジネスニーズからソフトウェア機能への接続を確立するためのトレーニングを受けています。These people are trained to make the connection from business need to software functionality. ここでは、ビジネスアナリストがエンタープライズレベルソフトウェアの評価で基本概念を適用する方法について、いくつかの時間をかけて説明します。Let's take a few minutes to see how you can apply the basic concepts—in the way that a Business Analyst would apply them—in your evaluations of enterprise level software.

ビジネスニーズを特定するIdentifying the business need

最初に考えておく必要があるのは、最初に新しいソフトウェアシステムを検索するためにビジネスに必要なものです。The first thing to think about is what business need brought you to look for a new software system in the first place. 多くの場合、自社の組織はエンタープライズプロジェクト管理ソフトウェアの実装について企業を模索しています。Our own organization often consults companies on implementing enterprise project management software. コンサルタントとして組織に到着したときに、ソフトウェアを購入するかどうかについて話し始める前に、組織がどのようにプロジェクト管理を実行しているかを確認してみます。When I arrive in an organization as a consultant, long before we talk about whether to buy software, I ask how the organization is doing project management right now.

お客様が回答を完了したら、常にこの質問にお答えください。 "Is このメソッドは使用できますか?"When they finish their answer, I always ask this follow-up question: "Is that method working for you?" 意外にも、クライアントは多くの場合に応答します。Surprisingly, the client often answers that it is. ここでは、実装の会話を停止する必要があります。For me the implementation conversation has to stop there. 「問題がない場合は、「ソリューションを策定する方法はありません」という説明があります。"If there's no problem," I explain, "there's no way for me to craft a solution!" 多くの場合、この応答によってユーザーが一時停止します。Often this answer makes people pause. 「なぜ呼び出したのでしょうか?」"Why were we called in?" 質問します。I'll ask. この答えはさまざまに異なる可能性があります。また、調整が必要な場合があるため、会話が5分未満であることを認識しているということを認識しているユーザーにとっては珍しいことはありません。The answers can vary widely, and it's not uncommon for people to look around the room realizing that there are several agendas under way which must be reconciled—and our conversation is less than five minutes old!

そのため、"ビジネスニーズは何か" という質問をします。So, asking "What is our business need?" を開始するのに最適な場所です。is a great place to start. この質問には、ほとんどの場合、最初に構想を開始することになる目標があります。There is almost always an overall goal which answers this question—a goal that jump-started the initiative in the first place.

ビジョンの演習の実施Conducting a vision exercise

次に、ソフトウェア機能の観点から、この意味を少し深く理解する必要があります。Next you'll need to look a little deeper into what this means in terms of software functionality. Microsoft Project Server などのエンタープライズプロジェクト管理ソフトウェアを組織に実装するときは、常に、重要な担当者 (ソフトウェアを評価している人と上級管理者など) に関係するビジョンの実践を開始します。When we implement enterprise project management software like Microsoft Project Server into an organization, we always start with a vision exercise which involves the key personnel—those who are evaluating the software—and the senior management—those who are sponsoring the exercise. この演習の目的は、ビジネス目標を技術的な機能に結び付けることなので、技術担当者にとってこの練習をするだけでは不十分です。It's not enough to do this exercise with just technical personnel, because the objective of this exercise is to connect business goals to technical functions.

これを行うための効果的な方法は、大規模なホワイトボードを使用して主要な担当者を会議室に配置することです。Here's an effective way to do this: Put the key personnel into a room with a big whiteboard. ホワイトボードを4つの列に分割します。最初に、右端の列に見出しがあります。Divide the whiteboard into 4 columns: Start with a heading in only the far right column. 「ビジネスの意思決定」という呼び出し。Call it "Business Decision."

ビジネス上の意思決定列を含む4つの列があるホワイトボード

右の列には、検討している新しいシステムを使用して、ビジネス上の意思決定をリストすることをお勧めします。In the right column you are going to list business decisions you hope to make by using the new system you are considering. クライアントを使用してこれを行う場合、まず、多くの機能を一覧表示することになり、重要な答えがビジネス上の決定であることを事前に主張する必要があります。When we do this with a client, the first thing people want to do is to list a lot of features, so you'll have to insist that the answers which are important are business decisions. たとえば、"すべてのリソースとそのワークロードの一覧が必要です" という参加者がすぐに言うことがあります。For example, a participant may immediately say, "I need a list of all resources and their workload." もちろん、当然ですが、そのリストでビジネス上の意思決定を行う必要があるかどうかを確認する必要があります。That may be true, of course, but what you need to find out is what business decision they will make with that list.

ビジネス上の決定の例としては、次のようなものがあります。Some examples of business decisions might be:

  • 特定の部門での雇用または発生Hiring or firing in a particular department

  • プロジェクトの進行またはゴーゴーを決定するMaking a go or no-go decision on a project

ビジネス上の意思決定列を含むホワイトボードとビジネス上の意思決定のリスト

ビジネス上の意思決定の適切なリストを取得したら、一時停止します。Once you've got a decent list of business decisions, pause. ここでは、ビジネス意思決定リストを確認し、優先度の高い決定を特定するための最適なタイミングを示します。Now is a good time to review the business decision list and identify the top priority decisions. この質問を聞くことができます。このようなビジネス上の決定の1つに対してのみ回答を得ることができる場合は、組織にとって最大の価値を提供しますか。You might want to ask yourselves this question: If you could only get answers for one of these business decisions, which would deliver the most value to the organization? 上位3つの決定を選択することは、プロセスのこの時点で常に最も簡単です。Picking the top three decisions is always easiest at this point in the process.

これまでの経験があれば、エンタープライズプロジェクト管理ソフトウェアを模索する多くの組織が既に完了しています。If you have gotten this far, you've already accomplished more than most organizations that seek out enterprise project management software. システムベンダーにとって最も重要なビジネス上の意思決定の優先順位付きリストを提供できることは、プロセス全体にとって大きな一歩前進になります。Being able to provide a prioritized list of the most significant business decisions to systems vendors is a huge step forward for the entire process. システムベンダーに対して必要となるビジネス上の意思決定を伝えることができる場合は、簡単な機能について説明するだけでなく、組織の効率を高める方法について話しやすくすることができます。When you can tell system vendors what business decisions you need to make, they are empowered to move beyond talking about simple functionality to talking about how to make the organization more effective.

次に、それぞれの判断を調べて、"ビジネス上の意思決定を行うために、どのようなレポートが必要ですか?" と尋ねます。Next, look at each decision and ask, "In order to make that business decision, what report would you require?" 1つ以上のレポートを参照した後、ほぼすべての決定が行われます。Virtually every decision is made after looking at one or more reports. 3列目に "Report" というラベルを付けます。Label the 3rd column "Report." 上位3つの決定のそれぞれについて、その列に、対応する意思決定に必要なレポートを一覧表示します。For each of the top three decisions, list in that column the reports required for the corresponding decision.

たとえば、特定の部門に対して担当者を雇用するか、または解雇するかを決定する場合は、リソース容量計画データを示した部門別のレポートが必要です。For example, we might say that to determine whether to hire or fire personnel for a particular department, we need a report by department showing the resource capacity planning data. これには、予想されるワークロードのフォワード予測、予想されるリソースの可用性、およびスケジュールが含まれます。This includes a forward forecast of expected workload, expected resource availability, and schedule. 中規模企業の場合は、キャッシュフローが懸念になることもあります。If you are a mid-sized business, the cash flow might also be a concern. たとえば、追加の担当者を必要としても、雇用する現金を見つけることができない場合があります。You might, for example, have a need for additional personnel but not be able to find the cash to hire them. キャッシュフローレポートには、残高がある見積もり incomes および outflows が含まれています。The cash flow report would include estimated incomes and outflows of money with a running balance.

レポートとビジネスの意思決定列を含むホワイトボード

優先度として識別された各決定に対して [レポート] 列に入力すると、必要なものは既にクリアされ始めています。If we fill in the Report column for each of the decisions we've identified as our priorities, the shape of what we'll require is already starting to become clear. 完了すると、予想されるシステムから必要な物理的出力の一覧が得られます。Once you're done, you've got a list of physical output that you require from your prospective system.

ここで再び一時停止して、組織で既に使用されていると識別された種類のレポートがあるかどうかを確認します。Pause again here to find out if there are already reports of the type you've identified already in use in the organization. このようなレポートが存在することがありますが、多くの形式では、データが不完全であったり、データの生成に多大な手間がかかったりする可能性があります。Chances are that such reports exist, but in numerous formats and possibly with either incomplete data or with excessive effort required to generate them. 組織で作業したレポートの形式が見つかった場合は、それらをシステム要件の一覧に追加できます。If you find formats of reports that have worked in the organization, you can add these to your list of systems requirements. これで、システムベンダーにより多くの情報を提供できるようになりました。Now you can provide even more information to the system vendors.

キーレポートが識別されたので、これらのレポートを生成するために必要なシステムの要素に移動できます。With the key reports now identified, we can move to the elements of a system required to generate those reports. グラフの2番目の列に見出し "Analysis" を追加します。Add the heading "Analysis" to the 2nd column of the chart. レポートごとに、レポートの生成に必要な分析またはアルゴリズムを特定します。For each report, identify the analyses or algorithms that are required to generate the report. たとえば、リソース容量計画レポートの場合、プロジェクト管理システムからのクリティカルパスのスケジュールとリソースの平準化が必要になることがあります。For example, for a resource capacity planning report, we might require a critical path schedule from the project management system and a resource leveling analysis.

分析、レポート、およびビジネスの意思決定列を含むホワイトボード

これらの分析は、多くの場合、ベンダーによって販売されており、それぞれに含まれる多数の機能に基づいています。These analyses will often be marketed by vendors on the basis of the myriad of features that each includes. (ただし、機能ごとのセールスは生きています)。判断できるようにする必要があるのは、必要なレポートを提供する最小限の機能であり、これにより、特定したビジネス上の意思決定を行うことができます。(Yes, feature-by-feature selling is still alive and well!) What you need to be able to determine is the minimal functionality that will deliver the reports you require with which you can then make or improve the business decision that you have identified. 基本的な機能は、実際のビジネス要件を満たすために必要な機能に驚かれることがあります。You may be surprised at how basic is the functionality that you require in order to fulfill your actual business requirements. 一部のレポートでは、分析または計算は一切必要ありません。レポートは、新しいシステムのデータから直接生成できる単純な集約のみを必要とします。For some reports, no analysis or calculations will be required at all; the reports need only to be simple aggregates that can be generated right out of the new system's data.

最後に、グラフの最初の列について説明します。Finally, we come to the first column in our chart. 必要な分析を特定したら、分析にフィードするために必要なデータの要素を判断するために移動できます。Once you've identified the analyses required, you can move to determining what elements of data are required to feed the analyses.

見出し "Input" をグラフの最初の列に追加します。Add the heading "Input" to the 1st column of your chart.

使用している例では、部署の作業の各プロジェクト implicated について、タスクの完全な一覧を必要とする場合があります。In the example we've been using, we might require a complete list of tasks for each project implicated in the department's work. このことは、組織内のすべてのプロジェクトに当てはまります。This might very well be every project in the organization. また、各リソースの利用可能時間の完全なプロファイルと共に、タスクがスケジュール分析で移動するときに、リソースの平準化分析でワークロードが移動するように、各タスクで定義されたワークロードも必要になります。We'll also need a complete profile of the availability of each resource along with the workload defined on each task such that when the task moves in the schedule analysis, the workload moves in the resource leveling analysis. また、特定の部門で雇用を決定するか、または特定の部門で開始するかを確認してください。Also, remember how we started with the decision of hiring or firing in a particular department? また、部門別にリソースを特定できる必要があります。We'll also need to be able to identify the resources by department.

入力、分析、レポート、およびビジネスの意思決定列を含むホワイトボード

新しいエンタープライズシステムで必要となるすべてのことを識別するまで、右の出力から左の入力に移動できます。We can move like this from the outputs on the right to the inputs on the left until we have identified everything we'll need in our new enterprise system.

リスクの評価Assessing risks

この手順が完了すると、各入力に戻り、データのこれらの要素がどのように使用できるかを決定することをお勧めします。Once this exercise is complete, it's worthwhile to go back to each of the inputs and determine how available these elements of data are. よくあるように、これらのアイテムの一部が存在しないことがわかります。You might find—as we often do—that some of these items don't even exist. たとえば、一部の組織では、リソースの利用可能時間の完全な一覧を管理していません。For example, some organizations don't maintain a complete list of resource availability. また、プロジェクトによって生成されたリソースの負荷を示すリソースがロードされていない場合もあります。You might also find that not every project has a resource-loaded schedule showing the resource load generated by that project. 多くの組織では、特定の種類のプロジェクトは、あらゆる種類のシステムに配置されるわけではありません。In many organizations, certain types of projects aren't put into a system of any kind. 緊急作業、テクニカルサポートの作業、または通常のメンテナンス作業は、いくつかの一般的な例です。Emergency work, technical support work, or regular maintenance work are some common examples.

ビジネス価値を実現するために必要な基本データにアクセスできない場合は、システムのその要素を高リスクとして調べる必要があります。If you don't have access to the fundamental data you'll require to deliver the business value, you've got to look at that element of the system as high-risk. たとえば、組織のプロジェクトの80% に対してリソースが読み込まれたスケジュールを特定することができた場合、スタッフを増員または減らすためにビジネス上の意思決定を改善しなければならないと予想されると考えられるでしょうか。For example, if we find that we can identify resource-loaded schedules for 80% of the organization's projects, can we reasonably expect to improve our business decision to increase or decrease staff? その答えは、"いいえ" と考えられます。The answer is likely, "No." それはなぜでしょうか。Why? システムにないプロジェクトの20% が特定の部門の作業負荷の80% を表す場合があります。Because perhaps the 20% of projects that are not in the system might represent 80% of the work load for a particular department. すべてのデータがない場合は、最終レポートが正確かどうかを知ることはできません。If you don't have all the data, you'll never know whether the final report is accurate.

この種の問題を回避する方法はありますが、もちろんあります。There are ways around these kinds of problems, of course. 1つの方法は、データ要素にアクセスできない組織のこれらの要素のすべてのビジネスプロセスを分離することです。One method is to isolate all the business processes of those aspects of the organization where you can't get access to the data elements. システムに含まれていない可能性のある部門では、それらのリソースが表示されないことがあります。A division whose projects might not be in the system wouldn't have their resources listed either. この操作は、すべてのケースで行うことはできません。このような場合は、アイテムごとに項目を確認して、ビジネスプロセスやビジネス上の決定がどの程度のリスクで実装されているかを把握する必要があります。This can't be done so simply in every case; you'll have to look item-by-item to figure out how much risk those business process and business decisions are to your implementation. この時点では、改善する必要がある最終的なビジネス上の決定に優先順位を再設定することは珍しいことではありません。It's not uncommon at this point in the process to re-prioritize the final business decisions you hope to improve. 非常に重要な意思決定があるかもしれませんが、非常に高いリスクになるため、展開の初期段階ではそのようになる価値はありません。You might have a decision that is very desirable but turns out to be very high risk and therefore not worth pursuing in the early phases of your deployment.

完了した内容を文書化するDocumenting what you've done

この種の会議を実施する場合は、スクライブを割り当てます。ジョブには、プロセス全体にわたるメモやコメントの記録が行われます。When you conduct this kind of meeting, assign a scribe—someone whose job it will be to record notes and comments throughout the process. 特定のビジネス上の意思決定が高または低い優先度としてランク付けされた理由、または、「何が危険だと考えられているのか」では、を参照しても問題がないことがすぐにわかりません。The reasons why a particular business decision was ranked as a high or low priority or why something was considered high risk will be quickly forgotten if you don't have good notes to refer back to.

以下を記録することが非常に重要です。It is very important to record:

  • ホワイトボードに記入したことWhat you have written on the whiteboard

  • プロセスに参加したユーザーWho participated in the process

  • 最終的なビジネスの意思決定を行う担当者Who owns each final business decision

この時点で圧倒されている場合は、心配しないでください。If you're feeling overwhelmed at this point, don't fear. この演習全体は、大規模な組織であっても、非常に短時間で実現できます。This entire exercise can be accomplished very quickly, even in the largest organizations. 1日または2つのプロセス全体を完了できることは珍しいことではありません。It is not uncommon to be able to complete the entire process in a day or perhaps two. 成功するには、適切なレベルの管理をルームに移行することが重要です。The key to being successful is getting the right level of management into the room. さらに、この種類の会議は、常に実行されているのではなく、事前に破棄されていない組織の外部からのユーザーにとって最適です。Moreover, this type of meeting is best facilitated by someone from outside the organization who is not predisposed to do things the way they have always been done.

ナレッジはパワーKnowledge is power

エンタープライズプロジェクト管理システム (実際にはあらゆる種類のエンタープライズシステム) を確認している場合は、この手順を完了すると、ソフトウェアシステムベンダーと対話する場合に非常に多くの電力が得られます。If you're looking at enterprise project management systems—indeed, at enterprise systems of any kind—completing this exercise gives you a tremendous amount of power when you interact with software systems vendors. 重要なシステムの要素と、それ以外の要素を、すぐに見分けることができます。You can immediately distinguish between those elements of a system that are important to you and those that are not. ソフトウェアベンダーには、必要なレポートと決定事項の一覧を記載してください。Software vendors can be provided with the list of reports and decisions that you want to make.

ベンダーから返される応答には驚かされるかもしれません。You might be surprised at some of the responses that come back to you from the vendors. 機能上の機能を使用する以外の方法で応答するように解放されます。つまり、ラウンドの要件に square 関数を組み込むことができます。より良いベンダーは、システムを活用して、お客様のビジネス上の課題にどのように対応できるかを示すことができます。Freed up to respond in a way other than on a feature-by-feature basis—that is, trying to fit a square function into a round requirement—the better vendors will be able to show you how you can answer your business challenges by using their systems to their best advantage.

この演習を実施する最大の利点は次のとおりです。準備が整った評価基準を作成しました。Here is the biggest benefit of conducting this exercise: You have created ready-made evaluation criteria. 概念実証フェーズでは、ビジネス上の意思決定を改善するために必要な情報をシステムが提供するかどうかについて、すぐに確認できます。Now, during the proof-of-concept phase, you can immediately focus on whether the system delivers the information you need to improve the business decisions you must make.

著者について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).