申し訳ございません。検索条件に一致するものが見つかりませんでした。

お探しのものを見つけるために、以下の項目を試してみてください。

  • キーワード検索のスペルを確認してください。
  • 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。
  • 新しい検索を開始してください。
Country

Oracle SaaSの移行
ISV向けプレイブック

過去数年間、当社は60を超えるSaaSベースのアプリケーションをOracle Cloud Infrastructureに移行しました。これらのアプリケーションは、8つの業種のコアエンタープライズ機能と、世界中の199,000を超える顧客をサポートします。

このプレイブックでは、主要な課題、学んだ教訓、ベストプラクティス、およびクラウドへの移行の過程で当社が経験したメリットを共有します。当社のクラウド移行の洞察を活用してください。

入念によく計画され、慎重に実行されたクラウド移行は、大きなメリットにつながる可能性があります。次に当社の移行のハイライトを示します。

 
データセンターの統合
80から11
 
設備投資の削減
80%
 
インフラストラクチャ・コストの削減
64%
 
ソフトウェアへの支出
42%
 
ソフトウェアベンダーの削減
28から10
 
プロビジョニング時間の短縮
98%

エグゼクティブ・サマリー

独自のデータセンターとホスト環境を運用している場合、クラウドへの移行は大きな変化です。クラウドはインフラストラクチャ・サービスの復元力、規模、範囲を強化しますが、この過程を完了するには、テクノロジー、組織構造、およびビジネス慣行を再検討して適応する必要があります。これは、長期的な製品ロードマップから計画されたテクノロジーへの投資まで、さまざまな変数に影響を与えます。

この移行を行う際には、固有の課題に対処し、基本的な質問に答え、広範囲にわたるオポチュニティを捉える必要があります。クラウドへの道は明確に整えられていません。1だけつのアプローチ、アーキテクチャ、または一連のサービスがすべてのクラウド・アプリケーションに役立つことはありません。

独立系ソフトウェアベンダー(ISV)向けの、このサービスとしてのソフトウェア(SaaS)移行プレイブックは、60を超えるSaaSベースのアプリケーションをOracle Cloud Infrastructure(OCI)に移行する際に蓄積した学習に基づいています。これらのアプリケーションは、8つの業種のコアエンタープライズ機能と、世界中の199,000を超える顧客をサポートします。チームがナビゲートした課題と当社が実装したソリューションの多くは、クラウドモデルに移行するときに目にする可能性のあるものと同じです。このプレイブックは、移行のすべての段階で当社の経験を抽出し、お客様の過程を支援するための強力な洞察と観察を提供します。また、当社のOracle@Oracle Webサイトにアクセスして、クラウド移行の過程について説明し、その途中で学んだベストプラクティス、課題、教訓を共有する12以上のホワイトペーパーとブログを参照できます。

当社は、ISV、または、社内外向けのSaaSベースのアプリケーションを提供している企業は、クラウドに移行することで、同様のメリットを体験できると信じています。

第1章:変革の推進力

クラウドに向けた取り組みの紹介

アプリケーションの移行を含むクラウド移行プロセスは複雑になります。しかし、この複雑さの中には、クラウドへの過程で明確に定義された目標がいくつかあります。そのような目標の1つには、対象アプリケーションをどれほど"クラウド対応"にするか、ということがあります。希望する時間枠でクラウドに移行するために、アプリケーションをどの程度クラウド対応にする必要があるでしょうか?このホワイトペーパーでは、これらの目標のいくつかを概説し、当社の移行の過程に基づいて学んだベストプラクティスと教訓に焦点を当てます。成功の秘訣は、移行目標を事前に明確に定義して、目標を達成する方法について最適な決定を下せるようにすることです。可能性のある道筋はたくさんあることがわかるようになります。移行の過程で、開発者、配信チーム、および役員は、どのように進めるかについて評価し、多くの選択を行うことが必要になります。

ビジネス目標を達成するために必要な決定の枠組みを決めるために、次の技術的およびビジネス上の推進要因に焦点を当てることをお勧めします。

スケーラビリティ

クラウドサービスは、管理されたインフラストラクチャで可能な計算能力はるかに超える大規模な計算能力を提供し、ビジネスが市場オポチュニティを満たすために成長できるようにします。クラウドベースのサービスとしてのインフラストラクチャ(IaaS)とサービスとしてのプラットフォーム(PaaS)により、ISVは最新のコンポーネントを利用したスケーラブルなアーキテクチャの構築に集中できます。移行でさらに得られるメリットは、内部開発チームがIT運用の管理とスケーリングから解放され、パフォーマンスの調整と最適化に集中できるようになることです。

モダナイゼーション

ツールセット、サービス、およびアーキテクチャを最新化すると、コンポーネント間の統合が容易になり、アプリケーションがクラウドで利用可能なツールとテクノロジーの完全な価値を実現できるようになります。このようなツールは、インフラストラクチャのアップグレードから自動導入パイプライン、アプリケーションのパフォーマンスを向上させる統合された機械学習モデルまで多岐にわたります。市場で急速かつ一貫した変化が起きている場合、変化に付いて行くためにアプリケーションは動的でなければならないため、モダナイゼーションが最も重要です。場合によっては、最新のテクノロジースタックを活用して、サービスを完全に書き直し、ブランドを変更して、低コストまたはより合理化されたサービスオプションを提供できます。このような変化は、老朽化した製品を更新し、ライセンス製品が標準となっている、確立された市場を混乱させる可能性があります。また、新しいアプローチで製品をオーバーホールし、ブランド認知度と顧客のロイヤルティを維持しながらサービスを改善できる場合もあります。これは、必ずしも製品スイートを完全に変更する必要があるということではありません。

クラウドへの移行は、幅広いモダナイゼーション推進のきっかけになります。クラウドは、以前には組織で利用できなかったサービス、テクノロジー、専門知識へのアクセスをお客様とお客様のチームに提供するため、新しい目標を達成し、新しい機能を提供することが可能になります。チームは、個別の顧客との特定の導入にリンクされたカスタムコードではなく、一般的に適用可能な新しい製品機能に焦点を当てられるようになります。サービスのプロビジョニング、製品の更新、カスタマーサポートがすべてこれまでになく迅速に行われるため、新しい機能の開発にリソースを再集中させることができます。このように、クラウド移行は、製品のアップグレードの実行から顧客サービスの品質に至るまで、あらゆるものを変革する、幅広いモダナイゼーション活動の準備を整えます。


「Gen2クラウドへの移行により、Oracleは堅牢なDevSecOpsモデルを介してサービスを確実に提供できるようになり、お客様のビジネス変革をサポートできるようになりました。現在、ソフトウェアを毎日リリースしており、プロビジョニング時間を98%以上短縮しています」— Oracle Global Business Units、シニアプリンシパル製品戦略マネージャー、Karthic Murali

oracle@oracle


標準化

IaaSとPaaSでの標準化により、オーバーヘッドを削減し、チームをより柔軟で代替可能にすることができます。組織が成長するにつれて、チームはさまざまな成熟度レベルのツールを採用します。これらのツールセットをクラウドサービス内で統合すると、IT管理のこの層に関連する複雑さの多くが抽象化されます。これにより、ポートフォリオ全体でマッピングできるタスクの標準的な運用方法の開発と使用が可能になります。また、標準化により、日常業務がより簡単で予測可能になり、基本的なタスクの労働力の需要が減少します。以前は、アプリケーション間で、互換性がない場合もある、さまざまなプロセスをナビゲートすることに縛られていたリソースは、次世代製品や顧客向けのサービスの開発など、より重要な問題に集中するために解放されます。

特に、標準化により、セキュリティ、リスク、コンプライアンス、およびチームが既存および新製品に簡単に適用できるその他の運用アクティビティに関するグローバルポリシーとプラクティスを簡単に適用できるようになります。実際、資格を取得したコンプライアンス認定など、IaaSプラットフォームの固有の機能の多くは、アプリケーションに継承できます。

収益の最適化

収益の最適化は、主に2つの方法で実現できます。1つ目の、最も明白なものは、コスト削減です。IaaSを利用してデータセンターを排除すると、財務モデルがCapExからOpExに移行するだけでなく、通常、有意義なTCOの節約にもつながります。クラウドに移行されるアプリケーションのポートフォリオ全体で使用されるテクノロジースタックを合理化することによって達成されるコスト削減は、それほど明白ではないかもしれません。一般的なツールセットでは、制度的な知識が生まれ、標準化されていないツールのアドホック・トレーニングに関連する費用が排除されます。これらの方針に沿って、インフラストラクチャをコードとして扱う一般的なツールセットでは、最終的に時間と人件費を節約する自動化が実現できます。最後に、セキュリティなど、ポートフォリオ全体に適用される基本的な領域を専門とするチームにより、個々の製品チーム内に専門家を生み出す必要がなくなります。

第二に、アプリケーションがクラウド対応またはクラウドネイティブになると、通常、製品開発のタイムラインが短縮されるため、クラウドへの移行は、市場投入までの時間を短縮し、最終的に収益を最適化できます。より早く市場に参入することは、より迅速に収益を実現できることを意味します。アプリケーションがクラウド対応になると、世界中のどこにでも数分で導入できます。

上記の原則を組み合わせると、製品とサービスのアーキテクチャが標準化され、導入の速度と品質が向上するはずです。スケールは、繰り返されるパターンの設計の結果として生じ、収益の最適化、価値実現までの時間の短縮、および結果として得られる、顧客向けのサービスの品質と整合性の向上にリソースを再集中させる機能に貢献します。


WorkForce Softwareは、ワークフォース管理ソリューションをOracle Cloud Infrastructureに移行し、パフォーマンスの30%向上を実現します。

労働力"財務パフォーマンスにより、最初から設備投資を30〜35%節約できました。また、OCIから得られる優れたパフォーマンスにより、スイートで提供するROIはますます向上しています。"—WorkForce Software、最高経営責任者、Mike Morini氏

続きを読む


クラウドでの価値に通じる道

クラウド・コンピューティングには、ベア・メタル・インスタンスへのアクセスから統合されたコンテナ化された環境、完全に機能するサービススタックに至るまで、一連のIaaSおよびPaaSリソースと複数のソフトウェア導入モデルを含めることができます。最も基本的なレベルでは、クラウド・コンピューティングとは、物理インフラストラクチャ・コンポーネントをコアIaaSリソースに置き換えることを指します。

ほとんどのエンタープライズ・アプリケーションは、もともとクラウド用に構築されていません。多くのアプリケーションでは、クラウドパターンへの変換または準拠には時間がかかり、かつ困難です。プラットフォームの再構築は、時間と労力の両方の観点からコストがかかる可能性があるため、クラウドネイティブのプリンシパルを最初から設計する方が簡単な場合があるのは、驚くようなことではありません。この点を考慮に入れると、企業は通常、クラウドの移行を検討する際に3つの主要なシナリオのいずれかに直面します。

  • レガシー・データセンターの終了:データセンターの運営には費用がかかります。建物、人、電力、冷却、メンテナンス、およびアップグレードは、日常の責務のごく一部です。多くの企業は、オフプレミスに移動するための候補となるアプリケーション・ポートフォリオを評価することにより、データセンターへの依存を軽減または排除するために積極的に取り組んでいます。優先事項は、資本支出を削減または排除するために、同じ場所に配置された、マネージド・ホスティングまたはオンプレミスのデータセンターからアプリケーションを移動することです。多くの場合、リフトアンドシフト戦略が利用され、アプリケーションはそのままベアメタルサーバーまたはクラウド内の仮想マシンに移行されます。
  • テクノロジースタックの進化:この場合、企業は追加の投資を必要としても、時間とともにより多くの価値をもたらすことも期待されるアプリケーションに段階的な変更を加え始めます。この例としては、アプリケーション自体に大きな変更を加えることなく、オンプレミス・バージョンのOracle DatabaseをクラウドベースのOracle Autonomous Databaseに置き換えることが挙げられます。これは、移行と改善の戦略と呼ばれることもあります。
  • クラウドネイティブでのオールイン:アプリケーションをボトムアップでクラウド対応に再構築する利点は、上記のシナリオの1つを実装しながら、成熟度の低いアプリケーションをそのまま維持するコストを上回る可能性があります。クラウドネイティブなアプリケーションは、本質的に高度に分散されており、多くの場合、12要素の原則を利用して構築されているため、基盤となるアーキテクチャから独立するように設計されています。つまり、アプリケーションは、その下にあるインフラストラクチャが壊れた場合でも継続して動作します。簡単に言えば、クラウドへの移行は、基盤となるインフラストラクチャと緊密に結合されたアプリケーションを移行するよりも確かに簡単であるため、このパスが対象アプリケーションにとって意味があるかどうかを評価する価値があります。
クラウド・ネイティブ・パターンeBook
Oracleがクラウドネイティブをどのように定義しているか、クラウド・ネイティブ・アプリの起源、およびそれを構築する際に従うべきベストプラクティスについては、このeBookをお読みください。

これらのシナリオを想定するもう1つの方法は、エンタープライズ・アプリケーションをOracle Cloud Infrastructureに移行しながら、クラウド・ネイティブ・アーキテクチャに近づけるために実行できるさまざまなアクションを調べることです。下の図1を参照してください。


図1:クラウド移行の変化と投資レベル

図1の左側は、変化の量が最も少なく、価値を実現するまでの時間が最も短く、初期投資が最も少ないことを表しています。変化、投資、時間のレベルは、右に移動するにつれて全体的に増加しますが、実現される価値も大きくなります。このモデルは、移行フェーズで行うことを検討する投資の種類を予測する方法の枠組みを作るのに役立ちます。アプリケーションは無数の方法で構築されているため、シナリオは必ずしも個別のものとは限らず、多少重複ことに注意してください。

上記のシナリオは、既存の成熟度レベルとクラウド移行の目標を評価するための重要な参照ポイントになります。現在の状態と目標の状態の間のギャップから、クラウド移行に必要な技術的およびプロセスの変更の範囲の大まかな見積もりが得られます。完璧な世界では、クラウド移行により、すべてのアプリケーションがクラウドネイティブの提供モデルに移行するはずです。しかし、リソースと時間の制約があるため、1回のプロセスでポートフォリオ全体をクラウドネイティブ・モデルに移行できる組織はほとんどありません。単純なプラットフォームの再構築作業でさえ、リソースを大量に消費し、レガシー機能を複製するためだけに多額の投資が必要になる可能性があります。

したがって、クラウド移行は、最適なクラウド成熟度レベル(アプリケーションが上記のクラウドでホストされたクラウドネイティブの連続体にある場合)と、製品とそれに関連するビジネスプロセスを再構築するために必要なエンジニアリング投資との間のトレードオフを判断する問題です。この段階での重要なステップは、このギャップを埋めるために必要な開発投資の概算の見積もりを含め、各アプリケーションの現在および目標の成熟度レベルを特定することです。

移行中に成熟度レベルが変化するアプリケーションは、運用パターンと期待も変更する必要があります。成熟度レベルの変化は、サービスをサポートするチーム、プロセス、およびポリシーに影響します。

 

第2章:準備と投資目的

クラウドの技術的準備状況の評価

対象アプリケーション、または複数のSaaSベースのアプリケーションを提供する企業のアプリケーション・ポートフォリオ全体の技術的理解は、移行の要件と依存関係を理解するために不可欠です。この段階では、アプリケーションに必要な機能と、その機能がアプリケーションの依存関係にどのように関連しているかを特定することに主な重点を置く必要があります。これにより、移行アクティビティの相対的なタイミングが促進され、主な焦点領域を特定するのに役立ちます。アセスメントは、3つの重要なディメンションに対処する必要があります。

  1. インフラストラクチャの要件:クラウドは、基盤となるハードウェアまたはオペレーティング環境からソフトウェアを切り離します。成熟度の高いアプリケーションは、基本的に環境から独立しており、クラウドで簡単に拡張できる、CPUやKubernetesクラスターなど、一般的なインフラストラクチャ・リソースのみに依存しています。成熟度の低いアプリケーションは、管理されたインフラストラクチャやその他の専用システムなど、提供されている特定の機器、コンポーネント、または環境に依存します。アプリケーションがクラウド内のインフラストラクチャ・コンポーネントや構成に強く依存する範囲を最初に文書化し、最終的には排除する必要があります。基盤となるインフラストラクチャに関連付けられている、または結合されている(ユーザーまたはユーザーの顧客が作成した)カスタマイズが見つかるのは珍しいことではありません。
  2. サービス・コンポーネント:クラウドは、アプリケーションとは独立して運用および提供されるスタンドアロン・サービスとして、サポート機能を提供します。成熟度の高いアプリケーションは、スタック全体の依存関係を最小限に抑えた個別のコンポーネントを中心に設計されているため、対象を絞った変更とアップグレードが可能になり、稼働時間を最大化できます。成熟度の低いアプリケーションは、大きく緊密に結合されたコンポーネントで設計されており、これらのコンポーネントは相互依存性が高く、単一のエンティティとして管理する必要があります。これらのサービス関係は、アプリケーションごとに文書化する必要があります。
  3. Operational Readiness:クラウドは、技術アーキテクチャだけでなく、作業プロセス、スキルセット、利用可能なツール、および運用モデルを変更します。成熟度の高いアプリケーションは、すでにクラウド・アプリケーションのように動作しており、クラウドで適切に機能するプロセス、標準、およびツールセットを使用します。成熟度の低いアプリケーションでは、重要なサポートサービスがクラウドにないことが見つかったり、サポートするチームのスキルセットがクラウド作業に不適切だったり、クラウドへの移行によって中断されるプロセスを使用したりしています。

これらの要因に関してアプリケーションの成熟度を評価することから移行を開始すると、適切に計画を立てることができ、遅延を引き起こし、コストを増加させ、目標を達成できない原因となるダウンストリームの予期しない事態を回避できます。現在の本番環境、サポートサービスのスイート、および対象となるクラウド環境はプロセスを通じて進化し続けるため、移行の複雑さを控えめに言うことは困難です。サービスとアプリケーション間のつながりを明らかにすることで、事前のインテリジェントな計画が可能になるだけでなく、移行中に必然的に発生する変更にその計画が柔軟に対応できるようになります。効果的に文書化された場合、この評価により、移行プロセスの明確なやることリストが作成されます。これにより、予測される移行スケジュールが、絶えず変化するロードマップと一致し続けるようになります。


Zoomは、Oracle Cloud Infrastructureで数百万の同時会議を迅速にスケール調整し、アクティブ化します。

ズーム"当社では、最近、ビジネスでこれまで見られた中で最も大幅な成長を経験し、サービス能力の大幅な増加が必要となっています。複数のプラットフォームを調査したところ、容量を迅速に拡張し、新しいユーザーのニーズを満たには、Oracle Cloud Infrastructureが役立ちました。"— Zoom、CEO、Eric S. Yuan氏

続きを読む


財務目標

他のITイニシアティブと同様に、特に、対象アプリケーションがオンプレミス・ホスティング・モデル用に構築されている場合、クラウド移行にはその価値を最大限に引き出すための一連の投資が必要です。クラウドに移行する価値があると見なされるアプリケーションは、時間の経過とともに最終的にクラウドネイティブになるか、廃止されます。ただし、最初の目標は、通常、アプリケーションをクラウドリリース状態にすることです。

アプリケーションを現在の状態からクラウドリリース状態に移行するために必要なのは、一連の決定と初期投資の産物です。アプリケーションを単純にベアメタルサーバーにリフトアンドシフトすることを計画していますか(この場合、投資の大部分はクラウド・インフラストラクチャになります)、あるいは移行前にアプリをクラウド対応にする計画がありますか(この場合、一部アプリケーション・スタックの一部をクラウドベースのモデルに移行(たとえば、データベースをオンプレミスからDBaaSまたはOracle Autonomous Databaseに移行)するには、投資が必要になります)?顧客固有の機能を有効にするためにハードコードされたカスタマイズを作成している場合、プラットフォーム・コンポーネントがカプセル化され、製品化された機能としてAPIを介して提供されるモデル用にリファクタリングする必要があります。クラウドで高度に分散されたアプリケーションを拡張するには、ハードウェアまたはプラットフォームの依存関係を解除する必要があります。これらの投資を理解することは、クラウドへの移行に関連する財務目標を計画および達成するための重要な要素です。

初期投資には、先ほど説明したクラウド移行の段階に関連して必要な製品変更を行うために必要な開発時間と労力が含まれます。ただし、追加の費用も把握しておく必要があります。移行中に組織で発生する可能性のあるさまざまな費用には、次のものが含まれます。

  • 開発投資:データベース移行やアプリケーションのプロビジョニングなどのアクティビティをサポートする自動化など、製品を再構築したり、移行作業用のアクセラレータを作成したりするために必要な開発作業
  • 移行の実行:新しい資産のプロビジョニング、既存の環境とデータの移行、およびレガシー在庫の廃止に必要な作業
  • インフラストラクチャの取り込み:IaaSランプを通じて発生したサブスクリプション料金は、定常状態に移行しますが、移行期間による新たな増加になります。
  • 取り残されたインフラストラクチャ:移行作業によって発生し、排除または償却できるようになるまで残る、データセンターと設備投資の減価償却費
  • 労働力の移行:既存のチームのトレーニング、教育、再構築に関連する費用、または必要なクラウドスキルセットを備えた新しいリソースの取得に関連する費用
  • お客様の移行:新しい開発、インセンティブ、契約項目の再交渉、顧客の減少など、新しいモデルではサポートできない環境機能またはサービス条件の変更に関連するコスト

多かれ少なかれ、これらのコストはそれぞれ、IaaSへの移行に必要な要素です。それぞれが異なる方法でコストプロファイルに影響を与えます。たとえば、開発投資と移行実行費用は、この作業に関連するリソースが固定されている場合でも、1回限りのバケットに含まれる可能性があります。新しいインフラストラクチャの採用により、取り残されたインフラストラクチャの費用がなくなるまで、一定期間は費用の純増加になります。トレーニングや移行のインセンティブなど、一部の従業員および顧客の移行費用は、1回限りの費用になります。労働力の拡大や顧客契約の変更などのその他の事項は、新たな継続的費用になる可能性があります。

これらのダイナミクスが時間の経過とともにどのように展開するかを理解することは、組織がクラウド移行の準備を進め、期待を設定するために不可欠です。組織がクラウドの目覚ましいメリットに熱心ではあっても、移行リスクを明確に理解していない場合、特に移行を取り入れるとき、重複するインフラストラクチャ、事前の移行コストなどで、初期段階の費用の増加に驚かされます。適切な期待を設定し、段階的な進捗状況の発生に合わせて可視性を維持することは、組織が移行を進める際の整合性と統制を維持するために不可欠な要素です。

クラウド移行インベントリ

クラウドへの移行には、クラウド移行インベントリが不可欠です。クラウド移行インベントリとは何でしょうか?簡単に言えば、フリート内のすべての資産と、各資産を説明する、関連した重要なデータ要素のリストです。これは、移行の対象となるアプリケーションとそのすべての依存関係です。そのデータをキャプチャするために使用される媒体は無関係であり、データは企業内の複数の部門にまたがることが多いため、いくつかのツールを利用することは珍しくありません。必要な情報は通常、さまざまな生産、販売、運用データベースに分散しています。たとえば、構成管理データベースは、物理サーバーやラックの場所に至るまで、技術的な依存関係や資産の場所を詳細に追跡する場合があります。ただし、移行について顧客に通知する時期と方法を決定するために重要なビジネスおよび顧客についての考慮事項は含まれません。その情報は、多くの場合、運用およびサポートの関係者向けに設計されたリポジトリに含まれています。さらに、買収、特別なユースケース、および製品のサイロにより、複数のリポジトリ間で情報がさらに断片化されている可能性があります。

移行インベントリの主な目的は、クラウドへの移行を管理するために必要な要素を一元的に表示することです。例:資産とは何ですか。資産はどこにありますか。どの製品をサポートしていますか。どのような機能がありますか。どの顧客をサポートしていますか。

最初から、ブループリントは生きたドキュメントであることを認識することが重要です。時間の経過とともに進化するため、特に、複数のアプリケーションまたは複数のバージョンのアプリケーションを使用している企業の場合は、柔軟性が必要です。新しい問題が表面化し、新しいニーズが発見されると、インベントリは進化します。基盤となるクラウド・インフラストラクチャでさえ、移行の過程で変更され、インベントリがさらに進化する可能性があります。移行インベントリは、可能な限り多くの利用可能なデータをキャプチャして、初期計画を開始できるようにし、その後、移行によって新しい要件が明らかになったときに、何層もの詳細を追加します。

移行インベントリの管理は、それ自体が機能横断的なプロジェクトであり、詳細なデータの必要性と収集作業のバランスをとる必要があります。また、詳細な技術仕様、アーキテクチャ的アプローチ、顧客要件、データ転送経路など、タイミングと速度に影響を与える依存関係、制約、およびリソースを識別する要素も含まれています。情報が少なすぎるとインベントリは役に立ちません。多すぎると、維持するのが負担になり、すぐに古くなって使用されなくなる可能性があります。

クラウド移行の開始点として、次の移行インベントリ・フレームワークをお勧めします。

移行インベントリから運用インベントリへ

移行インベントリに焦点を当てている中で、クラウド移行には最終的に2つの課題があります。最も直接的には、移行アクティビティを計画、優先順位付け、追跡する必要が生じます。ただし、移行自体により、日常の運用の追跡に必要なデータが強制的に変更されます。たとえば、物理サーバーとラックに関する移行後の構成の詳細は無関係になり、個々のインスタンスに関する情報でさえ、重要性が低くなります。同時に、特に組織がセルフサービスモデルを採用すると、全体的な使用状況やデータ出力などのメトリクスが重要になる可能性があります。

これらの新しいクラウド中心のデータスキーマとプロセスへの移行は、移行インベントリの作成により開始する必要があります。インベントリの作成とアプリケーションの移行という2つの課題は別々のプロジェクトですが、個別に追求するべきではありません。移行作業が主要な作業であり、組織が資産の詳細な統合ビューを作成したのはこれが初めてである可能性もあります。これは、移行後の新しいインベントリビューのテンプレートを形成すべき変革の瞬間です。上で説明したように、移行インベントリは柔軟で適応性がある必要があります。適切に管理すれば、移行インベントリは貴重な移行後インベントリ管理ツールに進化します。

第3章:クラウドに向けた取り組みを始める

クラウドへの道を先導する

SaaSアプリケーションをホストするためのインフラストラクチャの設計

SaaSベースのアプリケーションを提供するISVとして、サービスをホストし、顧客を分離して管理するための、安全でスケーラブルなエンタープライズ・グレードのインフラストラクチャが必要です。以下の図3に示されている参照アーキテクチャは、ベストプラクティスを組み込んだ検証済みのフレームワークを提供し、Oracle Cloud InfrastructureでSaaSアプリケーションをホストできるようにします。

この参照アーキテクチャでは、複数の分離されたアプリケーション・インスタンスを導入および管理します。各導入は特定のテナント向けであり、これらの個々のテナント・アプリケーション・インスタンスは共通の管理層を介して管理されます。

単一のコードベースからすべてのテナント・アプリケーション・インスタンスを構築するか、アプリケーションのカスタマイズされたバージョンを各テナントに提供するかを選択できます。このパターンは、アプリケーション環境を完全に分離する必要があるSaaSの顧客に最適です。

図3:OCI上のSaaSアプリケーションのベスト・プラクティス・参照アーキテクチャ

上記の参照アーキテクチャの詳細については、Oracle Architecture Centerを参照してください。さらに、4つのテナントのアーキテクチャの展開を支援するTerraformベースのツールとステップバイステップガイドを作成しました。最後に、常にOracle Cloud Infrastructureのベスト・プラクティス・ガイドに従うことをお勧めします。このガイドでは、次の4つの一般的なビジネス目標にわたるガイダンスが得られます。セキュリティとコンプライアンス、信頼性と回復力、パフォーマンスとコストの最適化、および運用効率。

アーキテクチャの変更に加えて、サービススタックがクラウドでどのように変化するかを考える必要があります。オンプレミス・アーキテクチャ用に開発されたレガシー環境に導入された監視、ネットワーク管理、またはセキュリティに使用されるコアツールセットは、クラウド向けに進化します。クラウドへの移行では、これらのツールが対応する範囲を拡大するオポチュニティが得られます。クラウドベースのツールは、主にエンドポイントを監視する代わりに、スタック全体を監視します。クラウド・サービス・プロバイダーは、コア機能に加えてクラウドまたはハイブリッドベースの監視ツールを提供する場合があります。Oracle Cloud Infrastructureの場合、ネイティブの監視、タグ付け、および監査機能の組み合わせにより、サービススタック全体を監視し、多くの場合、指定された基準外で見つかった異常を自動的に修正する機能が利用できます。現在オンプレミスでサードパーティの監視ツールを使用している場合、そのベンダーはハイブリッドまたはクラウドベースのツールも提供している可能性があります。


Cisco TetrationはコアアプリケーションをOracle Cloud Infrastructureに移行し、60倍のパフォーマンス向上を実現します。

Cisco Tetration"オラクルとのパートナーシップは素晴らしいものでした。これが、Cisco Tetrationによるこの大きな変化が起きている理由です。"—Cisco Tetration、創設者、Navindra Yadav


パイロットプログラムを立ち上げる

他のエンジニアリング作業と同様に、小さなパイロットプログラムまたはプロトタイプから始めることで、パイロットチームと組織は、何ができるか、どのように進めればよいかについての感覚が得られるため、成功の確率が大きくなります。パイロットおよび概念実証プログラムでは、組織全体の全面的な変更に伴う時間と財政的圧力なしに、課題を特定してトラブルシューティングできます。ゆっくりと進み、新しい運用環境に精通することで、パイロットプログラムは変化の速さを管理するのに役立ちます。

パイロットは、開発者と運用スタッフのコアグループがターゲットのクラウド環境を探索し、アーキテクチャ、サービス、運用モデルを学ぶためのオポチュニティです。このチームは、実践的な知識、便利なツール、ベスト・プラクティス、および自信、専門知識、経験の種となるものを作ります。チームがこの知識を構築すると同時に、クラウドベースの環境でチーム間のコラボレーションを行うための道のルールを整備しています。クラウド移行では、アプリケーション・チームが、直接のリソースマネージャーから他のチームが提供するサービスの利用者に進化する必要があります。パイロットにより、アプリケーション・チームは、サービスの境界がどのように変化するかを理解し、使用するサービスを提供する運用チームとの関係を構築して、これらの運用チームとのニーズを提唱する方法を学ぶことができます。

パイロットには次の利点があります。

  • テクノロジーの移植性に関する仮定を検証する(または疑う)コンテキスト。特に、テクノロジーが常に同じ環境で実行されている場合に有効です。これは、チームが移行の準備ができているかどうかを理解し、移行するために何を変更する必要があるかを特定するのに役立ちます。
  • ターゲット環境でサービスと統合するためのアプリケーション/データベースの準備状況を確認するオポチュニティ。これにより、チームは、どのような変更が必要か、いつアプリケーション環境とターゲットサービス環境の両方で移行を実行する準備ができたかを知ることができます。
  • ターゲット環境向けに構築し、新しいサービスや新しい環境に移行する際に、ポートフォリオの残りの部分の出発点になる、足場を作成できます。これにより、チームはポートフォリオの戦略的目標を得ます。

Manhattan Associatesは、サプライ・チェーン・ソリューションをOracle Cloud Infrastructureに移行し、以前のクラウド・ソリューションに比べてコストを50%節約します。

Manhattan Associates"アプリ層とデータベース層の両方でのOracle Cloudの多様性と柔軟性により、インフラストラクチャの観点での以前のクラウド・ソリューションから約50%の節約が実現しました。"— Manhattan Associates、上級副社長、Jeff Demenkow氏


パイロットプログラムの管理

パイロットは、技術スタッフと運用スタッフ、および経営陣と管理チームにとって、学習体験です。経営陣と管理チームは、パイロットチームと継続的にコミュニケーションを取り、組織的な障害を取り除き、組織がパイロット・プロジェクトから得られる学習(つまり、何がうまくいったか、何が失敗したか、ベスト・プラクティス、学んだ教訓、標準パターンまたは識別されたアンチパターン)を最大化できるようにする必要があります。この貴重な情報を収集して組織の他のメンバーと共有することで、理想的には、後続のクラウドプロジェクトをより効果的かつ効率的にすることができます。パイロットは、計画の作成に使用された仮定を管理してテストし、不確実な領域を明らかにします。これらの前提条件は組織ごとに異なりますが、パイロットは移行においていくつかの重要な課題に直面します。

  • トレーニング:パイロットは既存のスキルをテストし、組織が技術的な移行作業にどの程度備えているかを明らかにします。経営陣は、パイロットを使用して、技術的な習熟度を評価し、学習するのに最も重要なツールと機能を理解して、これらの重要な領域でスキルを迅速に構築(または採用)する方法を計画する必要があります。
  • コラボレーション:パイロットは、開発、運用、サポートの各チームがどのように異なる方法で連携するかを明らかにします。管理者は、パイロット中にこれらのチームが、新しい要件を公開し、この新しい環境での運用方法についての理解を深めて、実際に協力していることを確認する必要があります。
  • 変化への欲求:パイロットは、より広範な移行に影響を与える文化的障壁を見つけるチャンスです。パイロットで問題を抱えているグループは、規模が大きくなっても同じ反応を示します。パイロットは、経営陣が問題を特定して、トレーニングを導入し、特定の組織の現実に対応するように計画を調整するチャンスです。

スムーズな移行の鍵は、強固な基盤を構築することです。移行の最初のフェーズでは、移行が進むにつれて徐々に拡大する、サービスとプラットフォームのコアセットの開発を推進します。最終的に、これらのコア機能は、移行ポートフォリオ全体をサポートするように拡張する必要があります。結果として、最初のクラウドリリースが成功するだけでなく、次のすべてのリリースとアップグレードのための助走路を作成することが重要です。

第4章:クラウドベースの組織の成果

組織の変化への適応

SaaSアプリケーションをホストするためのインフラストラクチャの設計

組織の提供モデルと顧客関係の変更には、新しいスキル、知識、ビジネスプロセス、および考え方が必要になる場合があります。これらの変更は、組織全体に大きな影響を与える可能性があり、そのため、文化の変更は、クラウド移行の最も難しい側面であるとよく言われます。

これらの変更の範囲だけで、クラウドへの移行には大規模な再編成が必要であり、クラウドの経験と専門知識を備えた従業員の入れ替えが必要であるという印象を与える可能性があります。クラウドスキルセットに焦点を当てた社内機能の専門分野の変更と新規採用はクラウド移行の主要なコンポーネントですが、これまでの成功の鍵となっていた確立されたプロセス、ダイナミクス、および貢献者を失うことは許されません。組織の変化の速度と進行中のビジネスおよび顧客体験への潜在的な混乱とのバランスをとることは不可欠です。このバランスを維持するには、既存の従業員が新しいオペレーティング・モデルに移行できるようにするキャリア開発機能の構造の変更を再調整する必要があります。

長年続いているソフトウェアビジネスをクラウド配信モデルに移行するには、多くの主要なビジネス領域にわたって、前提条件、技術的ノウハウ、および標準的な運用プロセスを大幅に変更する必要があります。必要な変更の量を考えると気が遠くなるかもしれませんが、当社の経験は、クラウドの専門家の完全なオーバーホールを試みるよりも、既存のチームを維持して投資する方が一般的に優れていることを示唆しています。同様の移行を計画している組織は、当社のGBU組織が変更ニーズの分散型のボトムアップ評価からどのように始まったかを確認する必要があります。そこでは、各チームがそれぞれの移行インベントリとサービス・スタック・ロードマップを作成し、それぞれの管理領域内で必要な手順を特定できるようにしました。このアプローチにより、チームは、必要な可能性のあることについての概要的な仮定を回避しながら、プログラムを具体的な変更要因に合わせることができました。


8x8は、Oracle Cloud Infrastructureに移行することで、つながった世界を維持し、コストを80%削減し、サービスを向上させます。

8x8"ビデオ会議が急速に今日の新しい世界を結合する手段になるにつれて、ユーザー数が急増しました。その急激な成長をサポートするために、いくつかのプラットフォームを検討し、強力なセキュリティ、卓越した価格パフォーマンス、およびこの新しいユーザーの急増に対応する世界レベルのサポートのために、OracleのGen 2 Cloudインフラストラクチャを選択しました。"— 8x8、CEO、Vik Verma氏

ビデオを見る


ビジネスへの影響

クラウドへの移行が成功すると、組織全体の変更が可能になり、組織全体の変更によって可能性が与えられます。基本的にホストされているポートフォリオまたはオンプレミスのポートフォリオからクラウドベースのビジネスに移行するには、組織が顧客と関わる方法を根本的に変える必要があります。ただし、確立されたビジネス慣行と前提条件がどの程度変化するかは、クラウド移行で行われる製品変更の範囲によって大きく左右されます。

変化の少ないシナリオでも、IaaSへの移行はビジネスプロセスの変化を促進します。当社のGBUは、このコンテキストにおける変化の2つの重要なオポチュニティを特定しました。

  1. CapExを多用する物理インフラストラクチャ管理を、短期的な変動と長期的な期待を構成するOpEx指向の予測モデルに置き換えます
  2. 従来の責任から解放されたセキュリティおよびコンプライアンス・チームを進化させ、サービス・コンポーネントの提供に集中させます

アプリケーションの技術的変更とともに、これらの変更に対処する組織は、クラウド移行の潜在能力を最大限に発揮できる可能性があります。

顧客の連携

「シュリンクラップされた」製品、またはホストされている製品の提供から実際のクラウドサービスへの移行は、貴社と貴社の顧客が一緒に取り組む過程です。実際、クラウドを以前のすべてのホスティング・モダリティから差別化するのは、サービスとしてのモデルへのこの変更です。クラウドサービスへのすべての変更は、スケーラビリティから稼働時間、回復力まで、顧客のエクスペリエンスに影響を与えます。場合によっては、顧客が新しい提供モデルへの変更を依頼もしくは要求する可能性があります。また、特長、機能、およびコストに対する期待が、クラウドベースの配信を通じてのみサポートできる方法で進化している場合もあります。

クラウド戦略に顧客を巻き込み始めるときは、ロードマップへの期待と慣れ親しんだものから離れることへの抵抗の両方の視点に備える必要があります。これらの視点に対応するには、技術的な詳細に迷ったり、危険信号を上げたりすることなく、取り組みの方向性を示す明確で計算されたコミュニケーションが必要です。これは、組織内の顧客対応チームを関与させ、進行中の取り組み、ビジネスによって行われている投資、および製品と提供に期待される結果を確実に理解させるための重要な瞬間です。その際、顧客対応チームは、この変更をサービスに対する顧客の信頼を強化する言葉に変換するために、参加する必要があります。

クラウドサービスを利用する顧客にとって、シナリオはもう少し複雑になる可能性があります。クラウドサービスを必要とする顧客セグメントがあります。SaaSが効率と敏捷性の観点から提供するメリットを理解している人たちです。ただし、クラウドまたはSaaSのオプションが重要視されるようになったため、顧客はクラウド自体の価値ではなく、ベンダーのサービスを区別する機能とサービスレベル契約について教育を受ける必要があります。

ただし、すべての顧客がクラウドサービスに熱心であるわけではありません。特に、ホステッド・サービス・モデルまたは管理サービスモデルを使用している既存の顧客は、特注のサービス・コンポーネントまたは非標準環境を使用していて、クラウド配信と矛盾するモデルにアクセスしている場合、現状に満足している可能性があります。クラウドサービスへの移行のメリットを理解している顧客でさえ、提供条件の変更や環境の移行に必要なサービスの中断に不快感を覚える場合があります。

顧客を安心させるには、マーケティング、販売、サポート、および顧客事例の各チーム間の調整と一貫したコミュニケーションが必要です。理想的な世界では、顧客は自分のワークロードが移行されたことにまったく気付かないでしょう。ある日、パフォーマンスの改善に気づきますが、起こった変化には気付きません。現実には、サービスをクラウドに移行するには、アップグレードとダウンタイムの期間が必要になることが多く、場合によっては、サービス条件や利用可能な機能の変更が必要になります。全体的な移行タイムラインへの整合性を維持しながら、これらのイベントを通じて顧客を導くことは大変なことであり、変更のメリットを理解する以上のことが求められます。発生する変更への同意と、顧客のビジネスに影響を与える可能性のある移行手順の調整が必要です。


CMICは、建設エンタープライズ・ソフトウェアをOracle Cloud Infrastructureに移行し、10倍高速な導入を実現しています。

CMIC"他のクラウドプロバイダーに対するOCIのコスト上の利点に加えて、俊敏性が向上しています。OCIにより、新しいレベルの技術的柔軟性が得られました。利用可能な最高の建設ERPソフトウェアの提供に引き続き集中できるように、Oracle Container ServicesやOracle Autonomous Databaseなどのテクノロジーを使用して将来に進んでいます。"— CMIC、ITおよびクラウド・インフラストラクチャ担当ディレクター、Vince Di Piazza氏

ビデオを見る


顧客がクラウドの移行に伴うメリットと変更を支持したら、組織が直面する最後のステップは、実際に顧客のワークロードを新しい環境に移動することです。これは、新しい環境の移行と検証テストに最適な時間を決定するという課題になります。ダウンタイムの期間に直面することを受け入れる顧客でも、そのダウンタイムがいつ発生するかについて依然として強い意見を持っていることがよくあります。

顧客の好みはあなたにとって重要ですが、他の多くの懸念とのバランスを取る必要があります。移行の計画には、製品またはサービスの技術的属性、すべての顧客の好みの調整、内部リソースの制限、既存のレガシー・データセンターの統合/削除や非推奨の製品ラインの終了などのビジネス目標など、多数の要因のトレードオフが関係しています。これらの相反する優先順位のバランスをとるために、市場の期待を表す上で重要な声になる顧客対応チームを移行計画活動に含めます。

組織は、投資と移行の期間、およびクラウド提供モデルの継続的な技術的およびビジネスプロセスの変更の両方に備える必要があるのと同様に、移行に関する顧客との関わり方、および製品と顧客の関係における新しい状態の両方に備える必要があります。

当社のGBUは、まず移行が技術的、運用的、および提供コミットメントの観点から顧客にどのように影響するかを確認し、特別な注意、関与、および商取引関係の変更の可能性を必要とするものを分離することによって、これらのニーズに応えました。顧客対応チームの準備に向けた取り組みは、製品、運用、戦略、および特定の製品および顧客の変更に対処しながら、一般的なクラウドリテラシーを提供する、その他のチーム間のコラボレーションを含め、同様の視点で構築されます。

この取り組みは、単に顧客対応チームが顧客と関わりを持つ準備をすることだけではありませんでした。コアで部門を超えたリーダーシップを結集して顧客エンゲージメントを調整することで、主に技術的に主導されていたプログラムを、ソリューションのコアバリューの再検討、製品の差別化要因の再明確化、市場内でその価値を維持し、成長させる最善の方法の計画に関する幅広いイニシアティブに拡大する貴重な機会も生まれました。

第5章:上位5位の課題

事前の準備

SaaSアプリケーションをホストするためのインフラストラクチャの設計

このプレイブック全体を通して、数千のインスタンスでホストされている60を超えるGBUアプリケーションの移行を通じて学んだ教訓に基づいて、ベスト・プラクティスのガイダンスを提供しました。以下に、アプリケーションをクラウドに移行するすべての組織に適用できると考えられる、当社がその過程で直面した上位5つの課題を要約します。

  1. 移行前の開発努力の決定
    クラウドリリース用に確立されたアプリケーションを準備するには、特に製品をクラウドネイティブ状態にするために、多額の投資が必要になる場合があります。クラウド・ネイティブ・アプリケーションの原則への投資は、最終状態を満たすために多くの時間と開発リソースを消費する一方で、クラウドから得ることができる最高の利益をもたらします。製品をクラウドに対応させるのに時間がかかるほど、クラウドに移行することによる固有の段階的なメリットを得るのが遅れ、一般的にレガシー環境に関連するリスクにさらされる可能性が長くなります。同時に、ライフサイクル・フェーズと顧客の姿勢によっては、すべての製品から同じようにメリットが得られるわけではありません。移行を成功させるには、移行前に行う開発作業の量を完全に理解して文書化することが重要です。

    クラウドの成熟度とライフサイクル・フェーズのすべてのレベルの製品を含め、GBUのアプリケーション群は多様です。すべてのアプリケーションをクラウドに移行する必要がありましたが、クラウドリリース前にどれほどの製品変更を行う必要があるかについて苦労していました。正しいバランスを見つけるには、組織が各製品のライフサイクル・ステージ、成長の可能性、および製品をクラウドに移行するために必要な労力を評価する必要がありました。これらの組み合わされた評価に基づいて、GBUは各製品に与えられる優先順位と費用のレベルを決定しました。
  2. 開発の配分の決定
    クラウド投資の準備と市場の需要に応じて新しい特長と機能の開発に割くエンジニアリングの労力の量を決めることは、GBUにとってバランスをとるのが困難な問題でした。

    GBUは、クラウド移行の優先順位に関する調整を欠いていませんでしたが、製品チームは、顧客エクスペリエンスとパフォーマンスを向上させるものの、顧客が要求する機能の代替品とならないクラウド機能にどれだけの労力を割くべきかを理解するのに苦労していました。クラウド開発には、新機能に対する顧客の要求に対応する組織の能力を逸らす可能性のある、基盤となる運用機能への投資が必要です。これらのトレードオフにより、クラウドの準備と製品強化イニシアティブの間で時間をどのように配分するかを見極めることが困難になります。

    この課題に対応するために、GBUは、第1章で説明したクラウド成熟度フレームワークに依存して、各パスに必要な相対的な開発投資についての洞察を得ました。次に、潜在的なクラウド移行段階ごとのROIを調査し、その結果と、新機能の開発から期待される潜在的な収益への貢献度を比較検討しました。これにより、目標のビジネス成果の可視性を維持しながら、作業の正しい配分を決定するために使用できる共通の評価フレームワークが得られました。
    Altairは、Oracle Cloud Infrastructureでの高パフォーマンス・コンピューティングを選択し、価格パフォーマンスを20%向上させています。

    Altair"世の中のすべてのクラウドベンダーを調べたところ、OracleはHPCに非常に重点を置いていることがわかりました。それらのベアメタルサービスは、業界初であると私は信じていますが、高速で低遅延のネットワークを備えており、これは当社にとって非常に重要です。"—Altair、戦略的関係担当上級副社長、Piush Patel氏


  3. フリートを理解する
    会社のアプリケーションが単一であろうと大規模なポートフォリオであろうと、クラウド移行中に追跡およびインベントリする必要のある多くの要因があります。どのような変更を加える必要があるかを完全に把握するには、既存のアプリケーション・リポジトリ全体の現在のインベントリと、クラウドでの利用が計画されているものを完全に理解する必要があります。移行するアプリケーションが多数ある場合は、既存のインベントリが存在しないか、特定のアプリケーションの状態に関するトライバルな知識に依存している可能性があります。単一の、顧客向けアプリケーションを所有している企業でも、クラウドへの移行時にどの側面を変更する必要があるかを判断するために、アプリケーション・スタック全体のインベントリを作成する必要があります。クラウドではどの要件が変更され、設計がどのように見える必要があるかを理解することは、移行に必要な作業を文書化するための重要な側面です。

    インスタンスの特性(バージョン、ハードウェア/プラットフォームの依存関係、カスタマイズ、顧客アクセスモデルなど)に応じて、各アプリケーション・インスタンスに関してさまざまな種類と量の作業が必要になります。さらに、アプリケーション・データは複数の記録システムに分散している場合があります。

    Oracle GBUは、80のデータセンターと12,000を超えるアプリケーション・インスタンスにまたがるフリートを備えた30件を超える買収を統合したものです。これらのインスタンスに関連する重要なデータは非常に細かく断片化されており、コンポーネント製品チーム全体で一貫した方法で管理されているとは限りません。この情報がなければ、移行作業を効果的に組織し計画することができませんでした。何を移行する必要があるかを明確に理解するために、GBUは専用のデータ収集と統合の取り組みを開始する必要がありました。

    "OCIに移行することで、Oracle GBUチームは設備投資を80%削減し、インフラストラクチャのコストを64%削減することができました。"— GBU Cloud Architecture
    Oracle@Oracle、上級副社長、Mike Prindle


  4. 移行作業の優先順位付けと整理
    実際にワークロードを移行するには、既存のVMのイメージのコピーから、新しいインスタンスのインストールやデータの複製まで、さまざまな経路をたどることができますが、そのすべては完了するために、ある程度の技術投資または労働力のコミットメントが必要です。組織内のフリートでの各製品環境で乗ずると、移行に伴う労働の量とさまざまな種類は、容易に圧倒的なものになります。完了するために利用できるリソースは有限であり、多くの場合、日常業務の管理も担当しています。
    OceanXは、ビジネス・インテリジェンス・システムをAmazon Web Services(AWS)からOracle Cloud Infrastructureに移行して、パフォーマンスが3倍向上しています。

    OceanX"データ・プラットフォームを拡張して、低コストで高性能を提供する必要がありました。AWSからOracleへのデータ・プラットフォームの移行は、OceanXで最も成功した移行の1つであり、大幅なパフォーマンスの向上と大幅なコスト削減が相まって、プログラム全体が大きな成果を上げました。これにより、最終的には、より多くの情報に基づいた意思決定を、より迅速に行えるプラットフォームをクライアントに提供できるようになっています。"—OceanX、データおよび分析担当上級副社長、Vijay Manickam氏


    GBUクラウド移行には、3,000を超える個別の移行プロジェクトが必要でした。これらのプロジェクトは元々、顧客の好み(つまり、統合された顧客フィードバックに基づく移行時間枠の優先)または特定の環境の移行準備に基づいて優先順位が付けられていました。最終的に、このアプローチは、移行の過程でビジネス上のメリットを増やすのに役立ちませんでした。共通の優先順位付けまたは調整フレームワークがなかったため、GBUでの移行活動の量には一貫性がありませんでした。これにより、リソースの競合が多い期間とリソースの可用性がむだになる期間が交互に発生し、移行作業を完了する責任のあるチームに負担をかけました。

    これらの課題を解決するために、GBUは、移行専用の中央プログラム管理オフィスと、ターゲットビジネスの結果に対する移行の優先順位付けと移行の機会の特定を担当するエグゼクティブ監督委員会の両方を作成しました。
  5. 組織的変更の管理
    クラウド移行に伴う変化には、知識、スキルセット、プロセスの新しい領域に加えて、他の領域の文化的変化が関係しました。これらの人材に関する課題の管理は、クラウド移行の技術的コンポーネントよりも難しい場合があります。これに対処するために、Oracle GBUは、トレーニングに重点を置くことにより、既存のチームがクラウドチームに進化するのを支援しました。新しい人材をいつ導入するかということに対して、その他の方法で組織を進化させるメカニズムをいつ見つけるかという問題を管理するために、GBUは、主要な機能領域と製品グループに対して労働力評価を実施し、各ユースケースに照らして適切な改善イニシアティブをマッピングする必要がありました。移動する複数のアプリケーションが会社にある場合、セキュリティや一般的なIaaSなど、すべての製品にまたがる基本的なクラウド知識をどこで作成できるかを検討してください。

第6章:結果と開始

結果を受け入れる

このハンドブックは、60を超えるSaaSベースのアプリケーションをOracle Cloud Infrastructureに移行する際にOracle GBUチームが蓄積した学習に基づいています。これらのアプリケーションは、8つの業種のコアエンタープライズ機能と、世界中の199,000を超える顧客をサポートします。入念で計画的かつ適切に実行された移行は、大きなメリットをもたらしました。

  • 80のデータセンターを11に統合
  • 設備投資を80%削減
  • インフラストラクチャ・コストを64%削減
  • ソフトウェアベンダーを28から10に削減
  • ソフトウェアの費用を42%削減
  • ソフトウェアの毎日のリリースに移行
  • プロビジョニング時間を98%以上短縮
  • 計画的ダウンタイムを98%以上減少

このISVプレイブックは、GBUチームによって達成された学習に基づいていますが、その努力は、Oracle Cloud Infrastructureへの数ある大規模な移行の1つにすぎませんでした。すべてのSaaSアプリケーションの収益と顧客数を考慮すると、Oracleは世界最大のISVの1つと見なすことができ、移行プロセスを理解しています。当社は、実際にOracle Fusion Cloud ERP、Oracle Fusion Cloud EPM、Oracle Fusion Cloud HCM、Oracle Advertising and CX、Oracle Fusion Cloud SCMを含む製品ポートフォリオ全体をOracle Cloud Infrastructureに移行しました。これらの移行は、Oracle@Oracleと呼ばれる変革イニシアティブの一部です。これは、数十のデータセンターにまたがる数万のアプリケーションを含む多年にわたるプロジェクトでした。

これらの努力の結果として見られたいくつかの利点を次に示します。

  • インフラストラクチャ – アプリケーション・ポートフォリオ全体で99.99%の可用性を実現し、30%のコスト削減と2–10倍のパフォーマンス向上を実現
  • 財務 – 10日以内に決算を終了して収益を報告する機能を獲得
  • 人事 – タレントレビューのサイクル時間を70%短縮
  • サプライ・チェーン – サプライ・チェーンの計画サイクルを1週間から48時間に短縮—71%の改善
  • CX – キャンペーンのリードタイムを4週間から5日に短縮—82%の改善
  • サステナビリティ – 19年度にOracleで収集した、使われなくなった機器の99.4%を再利用またはリサイクル

Oracleとのパートナーシップ

当社は、ISVが対応可能な市場を拡大すると同時に、売り上げ収益の成長の可能性を高める支援をしています。詳細については、oraclecloud-isv_ww@oracle.comに電子メールを送信してください。

ISVがOracle Cloudを選択する理由の詳細については、次のリソースを検討してください。


Körberは、倉庫管理システムをOracle Cloud Infrastructureに統合し、40%高速に稼働しています。

Korber"さまざまな決定ポイントを評価したとき、OCIは、Go-To-Market戦略の観点から、当社が試みていたことに対して非常に戦略的でした。"— Körberö、北米セールスおよびアライアンス担当上級副社長、Rick Schrader氏

ビデオを見る