次の方法で共有


PSA バージョン 2.x または 1.x からバージョン 3.x へのアップグレードに関する考慮事項

重要

Dynamics 365 Project Service Automation は Dynamics 365 Project Operations に進化しました。 詳細は、Project Service Automation の移行を参照してください。

適用対象: Project Service アプリ バージョン 2.x および 1.x

Project Service Automation および Field Service

Dynamics 365 Project Service Automation と Dynamics 365 Field Service のどちらも、リソース スケジュールには Universal Resourcing Scheduling(URS)ソリューションを使用します。 インスタンスに Project Service Automation および Field Service がある場合、両方のソリューションを最新バージョンに更新する必要があります。 Project Service Automation の場合は、バージョン 3.x です。 Field Service の場合、バージョン 8.x です。 Project Service Automation または Field Serviceをアップグレードすると、最新バージョンの URS がインストールされます。 同じインスタンス内の Project Service Automation ソリューションと Field Service ソリューションの両方が最新バージョンにアップグレードされていない場合、動作に一貫性がない可能性があります。

リソース割り当て

Project Service Automation の バージョン 2 およびバージョン 1 では、タスクの割り当ては子のタスク (または行タスクとも呼ばれます) として タスク エンティティ に保存され、リソースの割り当て エンティティと間接的に連動していました。 行タスクは、作業分解構造 (WBS) の割り当てのポップアップ ウィンドウに表示されます。

Project Service Automation バージョン2 と バージョン1 における WBS 上の行タスク。

Project Service Automation のバージョン 3 では、予約可能なリソースをタスクに割り当てる際に基礎となるスキーマが変更されています。 行タスクは非推奨となり、タスク エンティティ のタスクと リソースの割り当て エンティティのチーム メンバーとの間で 1 : 1 で直接関連付けられます。 プロジェクト チーム メンバーに対する割り当てタスクは、現在、リソース割り当てエンティティに直接保存されるようになりました。

これらの変更は既存のプロジェクトのアップグレードの際に影響を与えます。既存のプロジェクトは、プロジェクト チームに、名前付き予約可能リソースおよび汎用リソースを含みます。 この記事では、バージョン 3 にアップグレードする場合、プロジェクトとして考慮する必要のある事柄について説明します。

名前付きリソースに割り当てられたタスク

基礎となるタスク エンティティ、バージョン 2 およびバージョン 1 のタスクを使用することによって、チーム メンバーは既定の定義済みロールではないロールを構築できました。 たとえば、既定でプログラム管理者のロールに割り当てられていた石田 美月を、開発者ロールを使用するタスクに割り当てることができました。 バージョン 3 では、チーム メンバーという名前のロールは常に規定であり、石田 美月が割り当てられているどのタスクでも、美月の既定ロールを使用します。

バージョン 1 およびバージョン 2 で既定のロールではないタスクにリソースを割り当てていいた場合、アップグレードすると、名前付きリソースはバージョン 2 のロール割り当てに関わらずすべてのタスク割り当ての既定ロールに割り当てられます。 この割当により、バージョン 2 またはバージョン 1 からバージョン 3 まで、計算された見積に違いが生じますが、これは、見積がリソース ロールに基づいて計算されたものであり、行タスクの割り当てに基づいていないためです。 たとえば、バージョン 2 では、2 つのタスクが藤戸 茜に割り当てられていました。 タスク 1 の場合、行タスクのロールは開発者であり、タスク 2 の場合、プログラム管理者です。 藤戸 茜には、プログラム管理者としての既定ロールもあります。

1 つのリソースに割り当てられた複数のロール。

開発者およびプログラム管理者ロールが異なるため、コストと営業見積りは次のようになります。

リソース ロールのコスト見積り。

リソース ロールの営業見積り。

バージョン 3 にアップグレードすると、行タスクは、予約可能なリソース チーム メンバーのタスクでリソース割り当てに置き換えられます。 割り当てでは、予約可能リソースに対する既定ロールが使用されます。 次のグラフィックで、藤戸 茜はプログラム管理者のロールを持っていますが、このリソースです。

リソース割り当て。

見積がリソースに対して既定のロールを持っているため、営業およびコスト見積りは変わる場合があります。 次のグラフィックでは、ロールが予約可能リソースの既定ロールから取得されるようになったため、開発者 ロールは表示されません。

既定のロールのコスト見積り。既定の役割の営業見積もり。

アップグレード完了後は、チーム メンバー ロールを既定の割り当てのでないものに編集できます。 ただし、チーム メンバーのロールを変更すると、割り当てられたタスクすべてが変更されます。理由は、チーム メンバーがバージョン 3 で複数のロールを割り当てることができないためです。

リソース ロールの更新。

これは、リソースの組織単位を既定から別の組織単位に変更する際に名前付きリソースに割り当てた行タスクにも該当します。 バージョン 3 のアップグレードの完了後、割り当てには、行タスクに設定済みのものではなく、リソース既定の組織単位が使用されます。

汎用リソースに割り当てられたタスク

バージョン 2 およびバージョン 1 では、タスクにロールや組織単位を設定して、チームの生成 機能を使用して、タスクに設定されている属性を持つ汎用リソースを生成できます。 バージョン 3では、ロールや組織単位に汎用チーム メンバーを作成し、チーム メンバーにタスクを割り当てます。

バージョン 2 およびバージョン 1 では、汎用リソースを含むプロジェクトは二つに別れた状態か、またはタスクレベルで両者が融合した状態になっている可能性があります。 たとえば、次のシナリオを使用できます。

  • ロールや組織単位を含むタスクは設定したが、関連リソースの割り当てを生成していなかった。
  • チームの生成 機能を使用して汎用リソースを作成して、割り当て済みの汎用チーム メンバーのリソースを含むタスク。

アップグレードを開始する前には、汎用リソースに割り当てられたタスクを含んでいる各プロジェクトか、または含んでいるがまだそこで実行するチーム プロセスを含まない各プロジェクトごとに、チームを再生成することをお勧めします。

チームの生成 を使用して生成された汎用チーム メンバーに割り当てられたタスクの場合、アップグレードでは汎用リソースがチームに置かれ、また割り当てがその汎用チーム メンバーに置かれます。 アップグレード後に汎用チーム メンバーに関するリソース要件を生成することをお勧めします。ただし、それはリソース要求を予約するか送信する前にしてください。 これにより、プロジェクトの契約組織ユニットとは異なる汎用チーム メンバーの組織ユニットの割り当てを保持できます。

たとえば、「プロジェクト Z」 プロジェクトでは、契約組織単位は、「Contoso US」 となります。 プロジェクト プランの実装段階内のテスト タスクでは、技術コンサルタントにロールが割り当てられていました。割り当てられた組織単位は、Contoso India です。

実装段階の組織割り当て。

実装段階の後、統合テスト タスクは、ロールの技術コンサルタントに割り当てられますが、組織は、「Contoso US」 に設定されます。

統合テスト タスク組織の割り当て。

プロジェクトのチームが生成されると、2 名の汎用チーム メンバーが、タスクで異なる組織単位に対して作成されます。 技術コンサルタント 1 は、Contoso India に割り当てられます。また、技術コンサルタント 2 は、Contoso US を有します。

汎用チーム メンバーの生成。

Note

Project Service Automation のバージョン 2 と バージョン 1 では、チーム メンバーが組織単位を保持しておらず、組織単位は行タスクで保持されています。

Project Service Automation バージョン 2 と バージョン 1 の行タスク。

見積もりビューの組織単位を表示できます。

組織単位の予測。

アップグレードが完了したら、汎用チーム メンバーに対応する行タスクの組織単位は汎用チーム メンバーに追加され、その行タスクは削除されます。 これにより、アップグレードの前に、汎用リソースを含む各プロジェクト チームを生成または再生成することをお勧めします。

契約プロジェクトの組織単位と異なる組織単位、およびまだ生成されていないチームにロールを割り当てるタスクの場合は、アップグレードによってロールに対する汎用チーム メンバーを作成できますが、チーム メンバーの組織単位の場合はプロジェクトの契約単位を使用します。 「プロジェクト Z」 の例を再び見てみると、これは契約組織単位 「Contoso US」、および実装段階のプロジェクト プランのテスト タスクは、Contoso India に割り当てられている組織単位を使用する技術コンサルタントにロールが割り当てられています。 実装段階後に完了した統合テスト タスクは、ロールの技術コンサルタントに割り当てられます。 組織単位は 「Contoso US」 で、チームは生成されていません。 アップグレードによって、1 つの汎用チーム メンバーが作成され、3 つのすべてのタスクに対して割り当て時間を持つ技術コンサルタント、およびプロジェクトの契約組織単位である Contoso US の組織単位が生成されます。

生成されていないチーム メンバーについて、異なるリソース組織単位の既定を変更する理由は、汎用リソースを含む各プロジェクトで、アップグレード前にチームを生成または再生成し、組織単位割り当てが失われないようにするためで、Microsoft がお勧めしています。