多くの場合、顧客は組織構造内でクラウド導入のアンチパターンを経験します。 多くの要因によって、次の問題が発生する可能性があります。
- ツールセット
- パートナー
- エンジニア
- IT 部門の位置がずれている
クラウド導入の成功シナリオでこれらの要因の役割を理解することが重要です。
アンチパターン: IT をコスト センターとして扱う
多くの企業では、IT 部門をコスト センターとして扱っています。 このアプローチは、IT が会社に価値を追加しないという認識につながる可能性があります。 従業員が IT をイネーブラーではなくプロバイダーとして見ると、意欲を失うことがあります。 また、会社が適切な人材を引き付けるのも難しいです。 動機が減り、ライフサイクル時間が長くなります。 IT の作業品質が低下し、サイロと封土が形成される可能性があります。
例: IT をコスト センターとして扱う
ある企業は、最高財務責任者 (CFO) を担当するコスト センターとして IT 部門を管理しています。 管理委員会は、IT を会社の最大のコスト 要因の 1 つである低速のサービス プロバイダーと認識しています。 管理委員会は、モビリティ ビジネス ユニットが、IT 部門が注文した資産の大部分を消費していることを認識していません。 IT 部門は、すべての部署が使用するデータセンターを購入しますが、モビリティ ビジネス ユニットはこの特大の資産を取得します。 ボードでは、IT がイネーブラーまたはパートナーとして表示されません。
推奨される結果: IT をイネーブラーとして表示する
IT 部門をコスト センターとして管理する代わりに、次のいずれかの方法を検討してください。
- チャージバック: 事業単位は、予算内の運用経費などの IT コストを扱います。
- ショーバックまたは認識バック: IT はエージェントとして機能します。 ビジネスに提出されるレポートでは、ITは関連する事業部に直接コストを割り当てます。
クラウドをツールとして使用して、コストとビジネスの透明性を高めます。 たとえば、コストの透明性を高めるために、Cost Management 規範 を実装します。 その後、さまざまな事業単位のコストについてさらに理解できるようになります。 IT 部門は、それらのユニットのイネーブラーとして表示されます。
透明性を向上させるには、クラウドへの移行時に可視性、アカウンタビリティ、最適化に重点を置きます。 詳細については、「コスト重視の組織を構築する」を参照してください。
アンチパターン: ビジネスを伴わずに新しいテクノロジに投資する
多くの場合、IT 部門は、堅牢なプラットフォームとツールセットの構築と展開に重要な人的リソースと財務リソースを投資します。 しかし、IT 部門が設計および開発フェーズでビジネス ユニットとそのニーズを考慮できない場合があります。 この省略により、ビジネス ユニットとの関連性が最小限の新しいプラットフォームにつながります。 その後、従業員は新しいテクノロジを受け入れることをためらっています。 導入が不十分または遅れると、問題が生じる可能性があります。 また、ビジネス ユニットがそのプラットフォームを使用していない場合にも、IT 内でフラストレーションが発生します。
例: 部署を含めずにプラットフォームを設定する
データ分析会社の IT 部門は、ビジネス ユニットを含めずに Azure プラットフォームを設定およびカスタマイズします。 プラットフォームを使用している間、ビジネス ユニットの開発者は次の手順を実行します。
- デプロイに必要なアクセス許可がないことに気付きます。
- 制限された数のサービスのみを使用できます。
- 承認サイクルが長くなるサポート チケットを発行します。
- 新しいプラットフォームを疑い始めます。
最終的に、一部の開発者は、IT の規則や規制の手間を省くために、自分で Azure サブスクリプションを購入します。 シャドウ IT が表示されます。 会社はシャドウ IT をほとんど制御していないため、高いセキュリティ リスクが発生します。
優先される結果: 意思決定にビジネス ユニットを関与させる
エンタープライズ対応のクラウド プラットフォームをデプロイするときは、IT サイロ 作成しないでください。 設計および開発プロセスで、ビジネス ユニットの開発者と技術意思決定者 (TVM) を関与させます。 プラットフォームの導入を改善するには、ビジネス ユニットの入力に耳を傾けます。
導入速度を向上させ、開発者向けに調整される Azure のベスト プラクティスと設計原則については、「クラウド導入フレームワークのエンタープライズ規模のランディング ゾーンの開始」 を参照してください。 コンプライアンスと柔軟性のバランスを取る。 たとえば、開発環境のアジャイルを維持しながら、ガバナンスとセキュリティ ポリシーを満たす方法を見つけます。
アンチパターン: コア ビジネス機能をアウトソーシングする
コンサルティング パートナーとマネージド サービス プロバイダー (MSP) は、クラウド体験において重要な役割を果たすことができます。 しかし、企業は、パートナーと MSP の仕事がビジネスで最も価値を提供しないように注意する必要があります。 MSP やクラウド コンサルタントに責任を委託する企業は、これらのプロバイダーに依存しないようにする必要があります。
例: クラウドの導入と移行をアウトソーシングする
ある研究所には、タイム クリティカルなクラウド移行プロジェクトがあります。 クラウド導入の取り組みを短縮するために、MSP を採用して Azure 基盤を構築し、移行を実装します。 クラウド導入フェーズについて学習し、スキルを構築する代わりに、研究所は、すべての Azure 責任を MSP に引き継ぐ選択をします。 研究所にはクラウドや Azure の知識がないため、MSP はすべての決定を主導し、研究所は MSP に依存します。
推奨される結果: 重要な設計領域を会社の責任にする
優れたコスト削減戦略として、アウトソーシングに留意してください。 ただし、次の重要な設計領域を含む場合は、社内で意思決定を行います。
- 統治
- リスク
- コンプライアンス
- 同一性
セキュリティ資産にとって重要なこれらの領域や他の領域について、社内で責任を負います。 外部パートナーを使用して導入作業を高速化します。 ただし、プロバイダーに依存しないように、すべてを外部委託しないでください。
アンチパターン: クラウド エンジニアを開発するのではなく、技術的な意思決定者を雇う
企業は、適切な人材を見つけることを重視しています。 その結果、最初のクラウド導入フェーズで、多くの場合、TDMS を採用または構築します。 成功したクラウド体験は、TVM に依存します。 しかし、さらに重要なのは、クラウド導入には、実践的な考え方と深い技術的スキルを持つエンジニアが必要です。
例: TDMs のみを雇用する
ある研究所では、クラウド体験をリードするために複数の TDM を採用しています。 最初の高度な概念フェーズが終了すると、実装フェーズが開始されます。 その後、この研究所は、クラウド デプロイの動作がオンプレミスのデプロイとは異なっていることを認識します。 適切に コードとしてのインフラストラクチャ (IaC) の概念とポリシー駆動型ガバナンス を実装するには、追加のクラウドエンジニアリング作業が必要です。
推奨される結果: 実装フェーズにクラウド エンジニアを使用する
クラウド自動化とランディング ゾーンの概念を適切に実装するためには、エンジニアが不可欠であることを忘れないでください。 サービス モデルを採用すると、責任とタスクが大きく変わる可能性があります。 クラウド プロバイダーに責任を移すことで、運用環境にすばやく移行できます。 また、意思決定には TVM を使用できますが、エンジニアリングに関する深い知識を必要とするタスクには、対応するクラウド エンジニアを使用します。 次に、クラウドが提供する利点を実現します。