お売りしているのは穴であり、ドリルではありません。We're selling holes, not drills!

興味深い表現が最近登場しました。I came across an interesting expression recently. ソフトウェアの営業担当者は、自分のクライアントにソリューション全体を納入することについて話していました。A software salesperson was talking about delivering the entire solution to his client. 「ドリルを販売していません。"We don't sell drills. 「いいね!」というように、穴を販売しています。We sell holes," he said. これは大きな比喩です。It's a great analogy. 多くの人 (私が含まれていた) は、power tools 部門のハードウェアストアおよびウィンドウ shopped に移動し、この強力なパワーツールを購入する根拠となると考えられる可能性があるプロジェクトを調べています。Many people (me included) have gone to the hardware store and window shopped in the power tools department while wondering what project I could possibly think of which would justify buying this great power tool. しかし、このロジックを適用することによって、企業のソフトウェアシステムの場合と同じように、自分の世界では非常にわかりやすくなります。But applying this logic makes as much sense in the do-it-yourself world as it does in enterprise software systems.

問題が発生していない場合は、ソリューションは必要ありません。If you don't have a problem, you don't need a solution.

何らかの問題を解決する必要がある場合を除いて、特定のドリルを探すべきではありません。これは、何らかの問題を解決しない限り、エンタープライズソフトウェアを検索することはありません。Just as no one should go looking for a drill unless the problem they'd like to solve is to make a hole, no one should go looking for enterprise software unless it solves some problem. エンタープライズソフトウェアの展開で問題が発生した場合は、次のことを確認することで、購入しているものが必要なソリューションを提供できるようになります。Now if you've got a problem that deploying enterprise software will fix, the next thing to ensure is that what you are buying will deliver the solution you need. 多くの場合、ソフトウェアを購入するだけではありません。That's often a lot more than just buying the software.

エンタープライズシステムの展開は複雑な課題なので、成果が労力を費やす価値があります。Deploying an enterprise system is a complex challenge so the payoff has to be worth the effort. 世界規模のグローバルプロジェクトチームでは、最も一般的な作業の1つとして、企業のシステム展開の大きな労力を分割することが挙げられます。In today's world of global project teams, one of the most common things to do is to divide the tremendous effort of an enterprise system deployment. これにより、プロジェクトの側面において高度なトレーニングを受けている teams を使用してスケールのメリットを得ることができますが、非常にリスクの高い方法でプロジェクトの overlooking 側面のリスクも保持します。While this can give us economies of scale in using teams which are highly trained in their aspect of the project, it also holds the risk of overlooking aspects of the project in highly risky ways. このリスクは、さまざまなチームが物理的に離れ、組織的に切断されていることが複雑になります。This risk is compounded the more physically and organizationally disconnected the different teams are.

エンタープライズシステムプロジェクトの最も一般的な要素を見てみましょう。Let's take a look at the most common elements of an enterprise systems project.

エンタープライズとはWhat's an enterprise?

最初に、企業は何を意味していますか?First of all, what do I mean by enterprise? ほぼすべてのユーザーに対して機能する必要がある定義を取得します。I'll take a definition that should work for almost everyone. このコンテキストの "Enterprise" は、組織全体の機能に影響を与えるプロジェクトを意味します。"Enterprise," in this context, means any project which will impact how the entire organization functions. このことは、どの組織でも当てはまります。I'll say this is true for any organization. エンタープライズ実装として認定される実装は、ユーザー数がどれだけに影響するかについてだけではありません。Implementations that qualify as enterprise implementations aren't just about how many users but how much impact they have. そのため、ベンダー A からベンダー B にウイルススキャンソフトウェアを更新すると、おそらく修飾されない可能性があります。So, updating our virus scanning software from vendor A to vendor B probably wouldn't qualify. 少数のユーザーに対して、デスクトップ上のプロジェクトスケジュールソフトウェアを実装しても、資格がない可能性があります。The implementation of project scheduling software on the desktop for a handful of users likely wouldn't qualify. プロジェクト管理を一元化し、集中管理型エンタープライズプロジェクト管理システムを使用すると、通常はそれが適用されます。Centralizing our project management and using a centralized enterprise project management system probably would qualify.

エンタープライズプロジェクトの場合は、エンタープライズシステムの展開で最も一般的な要素は何でしょうか。Okay, so if that's an enterprise project, what are the most common elements of a deployment of an enterprise system? 当社のオフィスでは、最も一般的に使用されているのは、独自の TimeControl、エンタープライズプロジェクト管理システム (Microsoft Project Server など) などのエンタープライズタイムシートシステムですが、これらの要素はエンタープライズシステムのほぼすべての実装に共通しています。In our offices the most common experience is deploying enterprise timesheet systems, such as our own TimeControl, or enterprise project management systems, like Microsoft Project Server, but these elements will be common to almost any enterprise system implementation.

ビット数とバイト数Bits and bytes

最初に、ソフトウェアの最も基本的な構成要素である技術アーキテクチャに取り組むことができます。First let's tackle the most fundamental building blocks of software: the technical architecture. 次に示すように、オンプレミスの展開またはクラウド内のサブスクリプションを使用した決定に基づいて、考えを分割する必要があります。These days we have to divide our thinking based on our decision to go with an on-premises deployment or an in-the-cloud subscription. 他の日にどの条件にも当てはまるものを選択することをお勧めしますが、各カテゴリで考慮する必要のある事柄についていくつかの基礎を紹介します。I'll leave the wonders of choosing which of these is best under which conditions for another day, but here are some of the basics of what we'll have to think of in each category.

オンプレミスインストールを使用している場合は、使用するハードウェアを考慮する必要があります。If we're going with an on-premises installation, we have to think about what hardware we'll use. メモリと Cpu のハードウェア要件は何ですか。What are the hardware requirements for memory and CPUs? 物理サーバーと仮想サーバーのどちらを使用するか。Will we use physical servers or virtual servers? 専用サーバーを使用するのか、それとも共有するのか。Will we use dedicated servers or shared? 必要となるサーバーの種類What kinds of servers might be required? アプリケーションサーバー、セキュリティサーバー、web サーバーサーバーが必要ですか。Will we need application servers, security servers, web server servers? 負荷分散、障害復旧、およびバックアップについてWhat about load balancing, disaster recovery, and backups? コールドまたはウォームバックアップサーバーが必要ですか。Will we need cold or warm backup servers? ふう!Whew! しかし、まだ完了していません。But we're not done! データベースについてWhat about the database? 必要な要件は何か。What are the requirements there? 既存のセキュリティ、アプリケーション、およびデータベースのアーキテクチャのサポートについてHow about support for our existing security, application, and database architectures? ブラウザー、ブラウザーのバージョン、およびモバイルデバイスのサポートについてWhat about support for browsers, browser versions, and mobile devices? すべての質問に回答したら、インストール、テスト、運用環境の問題を処理し、システムの正常性と監視をシステムが稼働していることを確認する必要があります。Once we've got all those questions answered, we have to handle the issues of installation, test, and production environments, and then system health and monitoring once the system is up and running.

クラウド内のサブスクリプション実装を使用している場合でも、さまざまな質問があるかもしれませんが、答えられる質問があります。If we're going with an in-the-cloud subscription implementation, we still have questions to answer though they may be very different questions. どのオンラインサービスを使用しますか?Which online service do we use? 専用インストールまたはマルチテナントサービスを使用していますか。Do we go with a dedicated installation or a multi-tenant service? セキュリティについてWhat about security? 独自の認証と統合できますか。Can we integrate with our own authentication? サブスクリプションサービスでの障害復旧の処理方法を教えてください。How do we handle disaster recovery with the subscription service? データが物理的に配置されている場所Where is the data physically located? これは法律上の問題があるかどうか。Does this present legal issues for us? 内部ブラウザーとモバイルデバイスのサポートについてHow about support for our internal browsers and mobile devices? 機能を統合するために、どのようにデータを取得し、内部データベースまたは他の外部 SaaS (ソフトウェアをサービスとして使用する) サービスと接続することができますか。How will we get our data out and how can we connect with out internal databases or other external SaaS (Software as a Service) services to integrate functionality?

Breath がまだ完了していますか?Out of breath yet? エンタープライズシステムについて説明している場合は、これらの質問やその他の事項がアジェンダにあります。When we're talking about an enterprise system, these questions and more are on the agenda. この部分を高度なトレーニングを受けた技術チームに移行すると、プロジェクト全体の範囲と考え始められます。これは、現在のところ、これが必要な穴の構築だけではなく、ドリルの構造になっているためです。If we shift this part of our project off to our highly trained technical team, they might start to think of this as the scope of the entire project, when this is just the construction of our drill, not yet the making of the hole we need.

構成するConfigure me!

システムを稼働させるだけでなく、そのシステム内の機能を特定の問題に適用することもあります。Aside from just getting our system working, there is also applying the functionality within that system to our specific problems. Project server の展開を確認しました。これは、クライアントが Project Server を起動して実行し、ワークフローを作成するための資金が割り当てられていないことを認識しているか、プロジェクトのポートフォリオの優先度を設定する方法、または1つのレポートを作成する方法を学習しています。I've seen Project Server deployments where the client gets Project Server up and running and then realizes they have not allocated any funding for creating workflows, learning how to prioritize their portfolio of projects, or learning how to make a single report. 大学でのシステムの分析101の場合と同様に、通常は、実際のビジネス上の問題が発生しているビジネス担当者に対して、必要な "出力" を求めるように、ホワイトボードの右端にある実装の一部を開始します。Just like Systems Analysis 101 back in college, we typically start this part of the implementation at the far right side of a white board as we ask the business people who have the actual business problem what "outputs" they'll need. この記事は他の writings でも使用しています。ここでは belabor されませんが、出力は最終的にはビジネス上の決定になります。I've spoken of this before in other writings so I won't belabor it here, but the outputs should ultimately be business decisions. これらの決定を行うために、レポート、分析、そして最終的には、データ入力が必要になります。To make those decisions, what reports, analysis, and, ultimately, data inputs do I need? 画面の右側から左へと、データ要素、分析計算、エクスポート、およびシステムで構成する必要があるレポートに必要なすべての文書パーツの一覧が表示されていますが、ここでは、これらの要素の一覧を示します。We work our way from the right side of the screen to the left and we end up with a list of all the building blocks we'll need in the form of data elements, analytical calculations, and exports and reports that will need to be configured in the system. この構成手順は、その複雑さに応じて数週間から数か月かかることがあります。This configuration exercise can take weeks or months depending on its complexity.

多くの場合、プロジェクトのこの側面に必要となるリソースの種類は、ビジネスアナリストとシステムエキスパートの組み合わせであり、これらの人々は展開されているシステムの機能について高度なスキルを持つことがありますが、技術的なアーキテクチャのスキルではありません。Often the types of resources we'll need for this aspect of the project are a combination of business analyst and system expert, and it's common that while these people may be highly skilled in the functionality of the system being deployed, they are not as skilled in the technical architecture. これにより、システムの2つの重要な要素に対して、teams を切断することが非常によくあります。That makes having disconnected teams for two critical elements of the system quite common. これらの2つのグループの通信が少ないほど、後で問題に直面する可能性が高くなります。The less these two groups communicate, the more likely it is that we'll face challenges later.

プロセスIt's a process

組織のプロセスに影響を与えることなく、新しいエンタープライズシステムを展開することはできません。It is impossible to deploy a new enterprise system and not affect the organization's processes. 1つの集中エンタープライズシステムを放棄して、その競合企業に移行する場合でも、プロセスは変わります。Even if you are abandoning one centralized enterprise system and moving to its competitor, processes will change. 実際には、プロセスを変更したくない場合は、解決が必要な問題が発生していない可能性がありますが、その問題は依然として別の課題です。In fact, if you don't want your processes to change, then it is entirely possible that you don't have a problem that needs solving, and herein lies yet another challenge. ユーザーの毎日のルーチンが変更されると、混乱が生じます。When a person's daily routine changes, it causes upset. 時間があることを意味していません。I don't mean some of the time. 筆者の環境では、この変更時に感情が見られることはありません。In my experience, upset at this time of change is a given. これは 、プロセスの変更によって処理が改善された場合でも当てはまります。This is true even when the process change will result in a better process! そのため、影響を受けるユーザーがどのように変更され、どのように動作するかについて考慮することが重要です。So thinking about how the processes will change and working with those who will be affected is critical to the success of the project. しかし、この変更のプロセスを設計することが非常に重要な専門家は、おそらくその変更による影響を受ける人と同じであると考えられます。このため、これは実装の難しさになる可能性があります。However, the very experts who are critical to designing this change in process are probably the same people who will be affected by that change, so this can be a challenging aspect of the implementation. 通常、熟練した経験のあるファシリテータは、新しいシステムの実装で可能になるプロセスの変更をガイドするために、社内の専門家と連携します。Usually, a skilled and experienced facilitator will work with the internal experts in guiding the change in process that has become possible with the implementation of the new system. この記事では、このような課題については常に説明します。In our line of work, we see this challenge all the time. 「プロジェクト管理者は、まずタイムシートの承認を行う必要があります」という新しい TimeControl クライアントから通知されます。"But the project managers have to do the timesheet approvals first," a new TimeControl client tells us. 「これはプロセスです」"That's our process." マトリックス承認を使用することにより、プロジェクトマネージャーは、より大きな、より効果的なプロセスの一環として、タイムシートの承認を行うことができるようになります。pushback.When we explain that matrix approvals can allow project managers to do their timesheet approvals as part of a larger, more effective process, we get upset; pushback. この時点で、最も経験のあるスタッフの1人が、影響を受けているユーザーと協力し、プロセスがどのように変化するかについて重要な部分であることがわかります。At this point, we have one of our most experienced staff work with the people affected to ensure that their concerns are taken care of, and that they are an integral part of how the process will change.

そのため、このようなチームを計画していない 場合は、 インストールと構成に関するすべての作業が展開されることはないと考えられます。So the process people are probably not the configuration people or the technical people, yet if we don't have this team planned for, all our hard work on the installation and configuration is probably not going to be deployed. このチームは、コミュニケーションに含まれている計画と、他の2つのチームによって行われた決定に含める必要があります。This team too must be part of our planning, included in communications and decisions made by the other two teams.


「トレーニングを必要としますか?」"So, will we need training?" 残念ながら、最後によく寄せられる質問です。is unfortunately a question that is often asked last. プロジェクトのその部分には多くの実践的なディスカッションが必要になるため、このプロセスの変更に関する一部のトレーニングが行われることがありますが、実際のユーザーガイドは、新しいシステムが段階的にどのように動作するかについてはどのようなものですか?Some training may come through the process changes as that part of the project requires a lot of hands-on discussion, but what about the actual user guide of how the new system will work in more of a step-by-step fashion? 現時点では、トレーニングはソフトウェア展開の重要な要素だと考えられており、クライアントには総予算の20% を含める必要があります。At one time, training was considered to be a critical element of software deployments and clients expected to put aside about 20% of the total budget on it. しかし、ソフトウェアのコストとインストールの速度が変更されたため、徐々に20% が減少し、コストが少なくなりました。But, with the changes in software costs and speed of installation, gradually that 20% became less and less money. システムのユーザー1人あたりの1月あたり $20 を支払っている場合は、トレーニングのためにユーザーごとに $4 をかけておく必要がありますか?If we're paying $20 per month per user for a system, should I put aside $4 per user for training? これ以上のことは約束できません。I can't promise it won't go too far. トレーニングには多数のオンラインサブスクリプションオプションがありますが、設計した正確なソリューションを考慮することはできません。There are many online subscription options for training, but none of that will take into account the exact solution you've designed.

トレーナーは、プロジェクトの構成またはプロセスパーツから提供されるかもしれませんが、実際に実装を行うユーザーではなく、専門家である人がいる場合があります。Trainers may come from the outside or may come from the configuration or process parts of the project, but they are often people who are specialists rather than the people who actually did the implementation work. そのため、このチームのために資金を予約していても (お客にお望みなら)、その人々が実際にどのような方法で作業しているかを把握しておく必要があります。So even if you've put funding aside for this team (and I hope you have), you still need to make sure that these people know what the system they're training people in is actually designed to do. Microsoft Project Server のトレーナーが表示されていて、ユーザーに対してエンタープライズフィールドを構成する方法と、ポートフォリオ分析でビジネスドライバーをセットアップする方法について説明してきました。エンタープライズフィールドはすべて設定されており、初期ロールアウトでポートフォリオ分析を使用しないため、ユーザーは空の stare を指定する必要があります。この特定の展開で解決すべき問題があるかどうかについては、トレーナーにお問い合わせください。I've seen trainers arrive for Microsoft Project Server and had them start explaining to users how to configure enterprise fields and set up business drivers in portfolio analysis, only to have the users give a blank stare because their enterprise fields were already all set up and they're not going to be using portfolio analysis in their initial roll out. Do your trainers even know the problem this particular deployment is supposed to solve? 必要があります。They should. プロジェクトの開始時にトレーニングについて考えることにより、成功する可能性が最大になります。Thinking about training at the start of the project gives it the greatest chance of success. 技術的、構成、プロセスの各チームは、最終的に提供されるトレーニングについて、それぞれのセクションを通じて重要なデータをあらゆる方法で確保できます。The technical, configuration, and process teams can be putting critical data aside all through their sections for the training that will ultimately be delivered. これは、早い段階でトレーニングチームが関与することを意味します。That means involving the training team early.

ロールアウト/承認/カルチャの変更Roll-out/acceptance/culture change

これらのチームを開始し、それらのすべての機能を利用してコミュニケーションしていくことができるようになるように、リソースを事前に検討し、リソースを残しておくと、新しいシステムのロールアウトは、それ以外の場合よりもずっとスムーズになる可能性がありますが、カルチャの変更に対する抵抗を過小評価しません。If you were forward thinking and put aside the resources to initiate these teams and have had all of them working and communicating together through the project, then the roll-out of your new system is likely to go much smoother than it might otherwise, but don't underestimate the resistance to culture change. 適切なタイミングで使用できるキー evangelists が重要な場合があります。Having key evangelists available at the right time can be critical. また、これらのチームメンバーはすべて、次のプロジェクトに移行していく予定ですか。Also, will all these team members be packing up and moving on to their next project? このようなユーザーには、プロジェクトがロールアウトされるまでに多くのシステム知識を包み込まれることになります。昨年初頭のクライアントの1人に特に感銘を行いました。There will be a lot of system knowledge wrapped up in these people by the time the project rolls out. I was particularly impressed with one of our clients early last year. It 部門は、大規模な金融組織です。It was the IT department a large financial organization. プロジェクトの早い段階でソフトウェアを評価している主要な技術ユーザーに対して、「プロジェクトをラップした後に管理者になるのは誰ですか」という懸念の1つです。One of the concerns we surfaced to the key technical user who was evaluating the software early in the project was "who will be the administrator once you wrap the project up?" 「彼は言います。"I will," he said. 自分の単語に対しては true でした。He was true to his word. 彼のスキルと知識は、複数の月の展開によって発展してきましたが、成功を収めることができました。His skills and knowledge evolved through the multi-month deployment, which was a great success, and he remains the key administrator still.

ラッピングWrapping up

チームがより大きな目標の一部としてコミュニケーションして作業していることを確認する方法について、他にもいくつかの点を考慮する必要があります。There are a hundred other things to think about in how to make sure your teams are communicating and working as part of a larger goal, and we've talked about only a few. さらに、次のエンタープライズシステムの展開については、既にお待ちしております。Hopefully it is making you think already about your next enterprise system deployment. 「ドキュメントについて」"What about documentation?" 考えているかもしれません。you might be thinking. 「テクニカルサポートについて」"What about technical support?"

このことを覚えておくことが重要です。エンタープライズシステムの展開を計画している場合は、インストール作業だけでなく、完成したソリューションの配信を含めるために、パースペクティブを拡張する必要があります。The key thing to remember is this: When you are planning an enterprise system deployment, you have to expand your perspective to include not just the installation effort, but also the delivery of the completed solution. 穴が正しいサイズ、右の深さ、右の角度だけになるように表示します。Make sure the hole appears just where it should in just the right size, right depth, and right angle.

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