Microsoft Fabric 導入ロードマップ: 変更管理

  • [アーティクル]

Note

この記事は、"Microsoft Fabric 導入ロードマップ" シリーズ記事の一部です。 シリーズの概要については、「Microsoft Fabric 導入ロードマップ」を参照してください。

データとビジネス インテリジェンス (BI) 導入の改善に向けて取り組む場合は、効果的な 変更管理 を計画する必要があります。 データと BI のコンテキストで言う変更管理には、組織内のユーザーに与える変更の影響に対処する手順が含まれます。 こうした手順により、ソリューションまたはプロセスの変更による中断と生産性の損失から保護します。

Note

Power BI に移行するときは特に効果的な変更管理が重要です。

効果的な変更管理により、次の理由で導入と生産性が向上します。

  • コンテンツ作成者とコンシューマーがより効果的かつ短時間で分析を使用できるようになります。
  • データ、分析ツール、ソリューションの重複を抑えます。
  • 共有リソース (Fabric の容量など) と組織のコンプライアンス (データのセキュリティやプライバシーなど) に影響する、リスクを引き起こす行為の可能性を減らします。
  • 計画を妨げ、ユーザーの導入を妨げる変更に対する抵抗を軽減します。
  • 中断、ストレス、競合の可能性を減らすことで、変更の影響を軽減し、ユーザーの幸福度を高めます。

効果的な変更管理は、すべてのレベルで導入を成功させるために不可欠です。 変更管理を成功させるには、以下のセクションで説明する主要なアクションとアクティビティを検討してください。

重要

変更管理は、多くの組織で成功を妨げる根本的な障害になっています。 効果的な変更管理を行うには、ツールやプロセスではなく、ユーザーが重要であることを理解する必要があります。

変更管理を成功させるには、共感とコミュニケーションが必要です。 変更を強制しないこと、また変更に対する抵抗を無視しないことを心がけてください。組織の分断が広がり、有効性がさらに阻害される可能性があります。

ヒント

可能な限り、変更を "改善" と表現して促進することをお勧めします。脅威と感じる度合いがかなり和らぎます。 多くの人にとって、"変更" は労力、集中力、時間の面でコストがかかることを意味します。 また、"改善" とは、何かをより良くすることなので、利点を意味します。

管理する変更の種類

データと BI ソリューションを実装する場合は、さまざまな種類の変更を管理する必要があります。 また、実装の規模と範囲に応じて、変更のさまざまな側面に対処する必要があります。

Fabric の導入を計画する場合は、次の種類の変更を管理することを検討してください。

プロセスレベルの変更

プロセスレベルの変更とは、より広範なユーザー コミュニティまたは組織全体に影響を与える変更です。 通常、このような変更には大きな影響を伴うので、管理にかかる労力も多大になります。 具体的には、この変更管理作業として、詳しい計画とアクティビティが含まれます。

次にプロセスレベルの変更の例をいくつか示します。

  • 所有権に対する集中型から分散型へのアプローチの変更 (コンテンツの所有権と管理の変更)。
  • 企業から部門へ、またはチームから個人へのコンテンツ配信の変更 (コンテンツ配信範囲の変更)。
  • 中央チーム構造の変更 (センター オブ エクセレンスの形成など)。
  • ガバナンス ポリシーの変更。
  • 他の分析製品から Fabric への移行。この移行に伴って、次のような変更があります。
    • セマンティック モデルとレポートの分離と、分析に対するモデルベースのアプローチ。
    • エクスポートや静的レポートから対話型分析レポートへの移行。これにはフィルター処理やクロスフィルター処理が使われることがあります。
    • PowerPoint ファイルまたはフラット ファイルとしてレポートを配布する方法から、Fabric ポータルからレポートに直接アクセスする方法への移行。
    • テーブル、改ページ対応レポート、スプレッドシートの情報から、対話型の視覚化とグラフへの移行。
    • オンプレミスまたはサービスとしてのプラットフォーム (PaaS) プラットフォームからサービスとしてのソフトウェア (SaaS) ツールへの変更。

Note

通常、エクスポートベースのプロセスまたは Excel レポートを放棄することは、大きな課題になります。 なぜなら、通常、このような方法は組織に深く根付いており、ユーザーの自律性とデータ スキルに結び付けられているからです。

ソリューションレベルの変更

ソリューションレベルの変更は、1 つのソリューションまたは一連のソリューションに影響する変更です。 このような変更の場合、影響はそれらのソリューションのユーザー コミュニティとその依存プロセスに限定されます。 通常、ソリューションレベルの変更による影響は小さくなりますが、より頻繁に発生する傾向もあります。

Note

この記事のコンテキストで言う "ソリューション" は、ユーザーの特定のビジネス ニーズに対処するために構築されるものです。 ソリューションは、データ パイプライン、レイクハウス、セマンティック モデル、レポートなど、さまざまな形式を取ることができます。 この記事で説明する変更管理の考慮事項は、レポート プロジェクトだけでなく、あらゆる種類のソリューションに当てはまります。

次にソリューションレベルの変更の例をいくつか示します。

  • KPI またはメジャーの計算ロジックの変更。
  • ビジネス属性のマスター データまたは階層をマップ、グループ化、または記述する方法の変更。
  • データの鮮度、詳細さ、形式、または複雑さの変更。
  • 予測分析、規範的分析、一般的な統計などの高度な分析の概念の導入 (ユーザー コミュニティがこのような概念にまだ慣れていない場合)。
  • 次のようなデータの表示方法の変更:
    • 視覚化のスタイル、色、その他の書式設定の選択肢。
    • 視覚化の種類。
    • データのグループ化または集計の方法 (平均値、中央値、幾何平均値など、中心傾向のさまざまなメジャーからの変更など)。
  • コンテンツ コンシューマーがデータを使う方法の変更 (個人使用シナリオで情報をエクスポートするのではなく共有セマンティック モデルに接続するなど)。

変更管理計画とアクティビティを準備する方法は、変更の種類によって異なります。 変更を適切かつ持続的に管理するには、段階的な変更を実装することをお勧めします。

変更に段階的に対処する

変更管理は重要な取り組みになる可能性があります。 段階的アプローチを導入すると、持続可能な方法で変更を進めることができます。 段階的アプローチを導入するには、最も優先順位の高い変更を特定し、それを管理しやすいパーツに分割し、反復フェーズとアクション プランを使って各パーツを実装します。

次の手順は、変更に段階的に対処する方法をまとめたものです。

  1. 変更内容を定義する: 変更を説明する際に、その前と後の状態を概要で示します。 変更、削除、または導入するプロセスや状況の具体的な部分を明確にします。 なぜこの変更が必要なのか、いつ行うべきかについて根拠を示します。
  2. 変更の影響について説明する: これらの変更ごとに、ビジネスへの影響を見積もります。 その変更の影響を受けるプロセス、チーム、または個人と、その対象にとってどの程度の中断が生じるかを特定します。 また、他の依存するソリューションやプロセスに対してその変更が及ぼすダウンストリームの影響も考慮します。 ダウンストリームの影響により、他の変更が生じる可能性があります。 さらに、状況が変更される前に、変更されなかった期間がどのくらい続いたかを考慮します。 時間の経過と共に優先順位や依存関係が生じるので、長期にわたるプロセスに対する変更は影響が大きくなる傾向があります。
  3. 優先順位を特定する: 潜在的な影響が最も大きい変更に焦点を当てます。 変更ごとに、変更の詳細な説明と、ユーザーに与える影響についてまとめます。
  4. 変更を段階的に実装する方法を計画する: 影響の大きい変更を複数の段階またはパーツに分割できるかどうかを特定します。 各パーツについて、影響を抑えるために複数のフェーズで段階的に実装する方法を説明します。 制約または依存関係があるかどうかを判断します (変更を実行できるタイミングやユーザーなど)。
  5. フェーズごとにアクション プランを作成する: 変更の各フェーズを実装およびサポートするために実行するアクションを計画します。 また、影響の大きいフェーズでの中断を軽減する方法を計画します。 アクション プランには、可能な限りロールバック プランを含めてください。

ヒント

四半期ごとの戦術計画の一環として、これらの段階的変更の各フェーズをどのように実装するかについて繰り返し計画します。

Power BI の導入に対する変更の影響を軽減する計画を立てる場合は、以下のセクションで説明するアクティビティを検討します。

変更を効果的に伝える

ユーザー コミュニティに対して、計画されている変更を明確かつ簡潔に説明するようにします。 重要な伝達内容は、エグゼクティブ スポンサー、または関連する権限を持つ他のリーダーから発信するようにします。 次の詳細を必ず伝えてください。

  • 変更内容: 現在と変更後の状況。
  • 変更する理由: 対象ユーザーにとっての変更の利点と価値。
  • 変更するタイミング: 変更が有効になるタイミングの予測。
  • その他のコンテキスト: ユーザーが詳細情報を確認できる場所。
  • 連絡先情報: フィードバック、質問、懸念事項を伝える連絡先。

集中型ポータルでコミュニケーションの履歴を保持することを検討します。 こうすることで、変更のコミュニケーション、タイミング、詳細を後で簡単に見つけることができます。

重要

ユーザーが準備できるように余裕を持って事前通知をした上で、変更を伝えるようにします。 考えられる変更の影響が大きいほど、早く伝える必要があります。 予期しない状況によって事前通知できない場合は、伝達の際に必ず理由を説明してください。

トレーニングとサポートを計画する

ツール、プロセス、ソリューションを変更するには、通常、それらを効果的に使うためのトレーニングが必要です。 また、質問に対処したり、サポート リクエストに対応したりするために、追加のサポートが必要になる場合があります。

トレーニングとサポートを計画するために実行できるいくつかのアクションを次に示します。

  • 集中型ポータルを使ってトレーニングとサポートを一元管理します。 ポータルは、ディスカッションの整理、フィードバックの収集、トピック別のトレーニング資料またはドキュメントの配布に役立ちます。
  • コミュニティ内の自立型サポートを奨励するインセンティブを検討します。
  • 質問に答え、指導する定期的な業務時間をスケジュールします。
  • ユーザーが新しいプロセスを練習できるように、エンドツーエンドのシナリオを作成し、実演します。
  • 影響の大きい変更については、その変更による中断を防ぐために必要な労力とアクションを現実的に評価するトレーニングとサポートの計画を作成します。

Note

これらのトレーニングやサポートは、変更の規模と範囲によって異なります。 影響が大きく、大規模な変更 (データと BI に対するエンタープライズからマネージド セルフサービス アプローチへの移行など) の場合は、おそらく、複数の計画期間にまたがる反復的な複数フェーズの計画を立てる必要があります。 この場合は、成功の実現に必要な労力とリソースを慎重に検討します。

経営幹部を関与させる

効果的な変更管理には、経営幹部のサポートが不可欠です。 経営幹部が変更をサポートすると、組織の他の部分にとっての戦略的な重要性や利点を示すことになります。 このようなトップダウンの承認と強化は、影響が大きく、中断の可能性が高い、大規模な変更の場合に特に重要です。 このようなシナリオでは、エグゼクティブ スポンサーが変更を承認し、強化するように、積極的に関与させます。

注意事項

変更に対する経営幹部からの抵抗は、多くの場合、ビジネスと BI の戦略の間でより強力なビジネス アライメントが必要であるという警告の兆候です。 このシナリオでは、経営幹部向けに特別なアライメント セッションと変更管理アクションを検討します。

関係者への参加要請

変更を効果的に管理するには、変更の影響を受ける関係者を関与させることで、ボトムアップ アプローチを取ることもできます。 変更に対処するアクション プランを作成するときには、主要な関係者を特定し、焦点を絞った限定的なセッションに参加してもらいます。 このようにすると、業務が変更の影響を受けるユーザーに対する変更の影響を理解できます。 ユーザーの懸念事項や、この変更による影響を軽減するためのアイデアをメモします。 変更が他のユーザーやプロセスに及ぼす予期しない影響がないか、必ず特定します。

変更に対する抵抗に対処する

変更に対する抵抗に対処することは重要です。なぜなら、導入と生産性に多大な悪影響を及ぼす可能性があるからです。 変更に対する抵抗に対処する場合は、次のアクションとアクティビティを検討します。

  • エグゼクティブ スポンサーを関与させる: 変更管理をサポートし、論争を解決するには、エグゼクティブ スポンサーの権限、信頼性、影響力が不可欠です。
  • ブロックの問題を特定する: 変更によってユーザーの作業方法が中断される場合、この変更により、ユーザーは日常のアクティビティでタスクを効果的に完了できなくなる可能性があります。 このようなブロックの問題については、変更を考慮するときに、可能な回避策を特定します。
  • 意見ではなくデータと事実に焦点を当てる: ユーザーは変更前の状況に慣れているので、変更に対する抵抗は意見や好みに起因する場合があります。 ユーザーがこのような意見や好みを持っている理由を理解してください。 新しいツールやプロセスの学習に時間と労力をかけたくないという、利便性の問題である可能性があります。
  • 要件ではなくビジネス上の質問とプロセスに焦点を当てる: 多くの場合、変更によって、問題に対処してタスクを完了する新しいプロセスが導入されます。 新しいプロセスは、変更に対する抵抗につながる可能性があります。なぜなら、人は、新しい点は何か、理由か何かを完全に理解することではなく、何がなくなるかを重視するものだからです。

さらに、"推進者" と "批判者" を関与させることで、変更に対する抵抗に大きな影響を与えることができます。

推進者を特定して関与させる

推進者とは、ユーザー コミュニティでツール、ソリューション、またはイニシアティブを支持する声を上げる、信頼できる個人のことです。 推進者は導入に良い影響を与える可能性があります。なぜなら、同僚がその影響を受け、変更を理解して受け入れる可能性があるからです。

変更を効果的に管理するには、プロセスの早い段階で推進者を特定し、関与させる必要があります。 関与させ、変更について知らせることで、その支援をより効果的に活用し、拡大することができます。

ヒント

特定した推進者は、チャンピオン ネットワークの最適な候補者になる可能性もあります。

批判者を特定して関与させる

批判者は推進者の反対です。 ユーザー コミュニティでツール、ソリューション、またはイニシアティブに反対する声を上げる、信頼できる個人のことです。 批判者は導入に大きな悪影響を及ぼす可能性があります。なぜなら、変更が有益ではないと同僚を説得する可能性があるからです。 さらに、批判者は、廃止対象となっている代替品やソリューションを擁護する可能性があり、古いツール、ソリューション、またはプロセスの使用停止が難しくなります。

変更を効果的に管理するには、プロセスの早い段階で批判者を特定し、関与させる必要があります。 そうすることで、潜在的な悪影響を軽減できます。 さらに、その懸念事項に対処すると、このような批判者が推進者に変わり、導入の取り組みを支援するようになる可能性があります。

ヒント

よく批判者になるのは、変更または置き換えが予定されているソリューションのコンテンツ所有者です。 変更は、このようなコンテンツ所有者を脅かす可能性があります。自分たちのソリューションが引き続き使われることを期待して、変更に抵抗する動機があります。 この場合は、このようなコンテンツ所有者を早期に特定し、変更に関与させます。 このような個人に実装の当事者意識を持たせると、変更を受け入れ、さらには支持するようになる可能性があります。

確認事項

以下のような質問を使って、変更管理を評価します。

  • 組織内に変更管理を担当する役割またはチームはありますか? その場合、データと BI のイニシアティブにどのように関与していますか?
  • 変更は、組織内のユーザーの間で戦略的成功を達成するための障害と見なされていますか? 変更管理の重要性は組織内で確認されていますか?
  • データと BI ソリューションとプロセスの重要な推進者はユーザー コミュニティにいますか? 逆に、重要な批判者はいますか?
  • 新しいデータ ツールとソリューションを立ち上げるために、どのようなコミュニケーションとトレーニング作業が行われていますか? 期間はどのくらいですか?
  • ユーザー コミュニティの変更はどのように対処されますか (たとえば、新入社員や昇格した個人)。 このような新しい個人を既存のソリューション、プロセス、ポリシーに導入するオンボーディング アクティビティは何ですか?
  • Excel レポートを作成するユーザーは、BI ツールを使ってレポートを自動作成するイニシアティブに脅威や不満を感じていますか?
  • ユーザーは、自分が使っているツールや自分が作成して所有しているソリューションと、自分の ID をどの程度関連付けていますか?
  • 既存のソリューションへの変更はどのように計画され、管理されていますか? 変更は、確認できるロードマップを使って計画されていますか、それとも事後対応ですか? ユーザーは、今後の変更について十分な通知を受け取っていますか?
  • 変更によって既存のプロセスとツールが中断する頻度はどのくらいですか?
  • 新しいシステムを使用できるようになったとき、レガシ システムまたはソリューションの使用停止にはどれくらいの時間がかかりますか? 既存のソリューションに変更を実装するには、どのくらいの時間がかかりますか?
  • "処理する必要がある情報量に圧倒されている" という意見に、ユーザーはどの程度同意しますか? "変更が多すぎるし、速すぎる" という感想に、ユーザーはどの程度同意しますか?

成熟度レベル

変更管理の評価では、組織がどの程度効果的に変更を実現し、変更に対応できるかを評価します。

次の成熟度レベルは、データと BI のイニシアティブに関連する変更管理の現状を評価するのに役立ちます。

Level 変更管理の状態
100: 初期 • 通常、変更は事後対応的であり、伝達は不十分です。

• 変更の目的または利点は十分に理解されておらず、変更に対する抵抗によって対立や混乱が起きています。

• データ イニシアティブの変更管理を担当する明確なチームまたは役割はありません。
200: 反復可能 • 経営幹部と意思決定者は、データと BI プロジェクトとイニシアティブにおける変更管理の必要性を認識しています。

• 変更を計画または伝達するためにある程度の取り組みは行われていますが、一貫性がなく、多くの場合、事後対応的です。 変更に対する抵抗はまだ一般的にあります。 多くの場合、変更によって既存のプロセスとツールは中断されます。
300: 定義済み • 正式な変更管理計画または役割があります。 これらの計画にはコミュニケーション戦術とトレーニングが含まれていますが、一貫して、または確実に実行されているわけではありません。 変更によって既存のプロセスとツールが中断することがあります。

• 成功した変更管理は、組織の境界を越える主要な個人によって支持されています。
400: 可能 • 共感と効果的なコミュニケーションは、変更管理戦略に不可欠です。

• 変更管理の取り組みは特定の役割またはチームによって所有されており、効果的なコミュニケーションにより、変更の目的と利点が明確に理解されています。 変更によって既存のプロセスとツールが中断されることはほとんどありません。
500: 効率的 • 変更は組織の不可欠な部分です。 組織内のユーザーは変更の必然性を理解しており、それを中断ではなく勢いの源として捉えています。 変更によって既存のプロセスやツールが不必要に中断されることはほとんどありません。

• 体系的なプロセスによって、プロセスではなく、ユーザーの課題としての変更に対処します。

関連するコンテンツ

Microsoft Fabric 導入ロードマップ シリーズの次の記事では、最後に、役立つ場合がある導入関連のリソースについて説明します。