機械翻訳について
  1. Oracle Content Managementでのアセットの管理
  2. 概要
  3. デジタル・アセット管理環境の設定

3 デジタル・アセット管理環境の設定

Oracle Content Managementは、イメージやビデオからドキュメント、構造化テキスト、3Dや拡張現実アプリケーションのコンテンツなどの新しい形式など、あらゆるタイプのデジタル・アセットを管理するための次世代コンテンツ・ハブです。

この項では、Oracle Content Managementをデジタル・アセット管理(DAM)ハブとしてプロビジョニングおよび構成するために必要な主なアクティビティに関するガイダンスを示します。 リファレンス実装計画は2週間のスプリントに分割されます。 スプリントの期間と数は、それぞれ固有の要件に応じて異なる場合があります。

ステージ1 - 検出および要件の定義

最初のフェーズでは、後続のフェーズで実装する詳細の定義に重点を置きます。 このフェーズが終了するまでに、コンテンツ・モデル、移行計画、セキュリティ・ロールおよび責任など、初期運用開始のための強固な要件セットが必要です。

要件の定義

Oracle Content Managementには、汎用DAMデプロイメントを構成するためのサンプル・アプリケーションが用意されています。 ただし、実際のプロジェクトでは、ビジネス要件に合わせてOracle Content Management設定をカスタマイズする必要があります。

既存のソリューションから移行する場合は、Oracle Content Managementから予想されるメタデータ、カテゴリおよび統合の種類をすでに定義している可能性があります。 ただし、この場合でも、ソリューションに移行するときに、この構成の一部を変更する必要がある可能性があります。

ディスカバリ・セッションの数は、必要なカスタマイズの量と、関連するユーザーのチームの数によって異なります。 特に、DAMシステムで管理する必要があるアセットおよびメタデータのタイプに関して、ほとんどの主要な要件を早期に確認することをお薦めします。

次の要件に対処する必要があります:

  • 「アセット・タイプ」-Oracle Content Managementには、いくつかのシード済アセット・タイプ(イメージ、ビデオ、ファイル)が付属しています。 通常、これらを拡張して独自のアセット・タイプを作成します。 たとえば、1つ以上の製品に関連するメタデータを含む「製品イメージ」タイプを作成できます。 Oracle Content Managementには任意の数のアセット・タイプを作成できますが、通常、顧客は6から8のアセット・タイプでほとんどのデジタル・アセットを管理できます。

    各タイプのメタデータ・フィールドを定義する場合は、各フィールドの形式、フィールドが必須かどうか、およびユーザーがフィールドをどのように入力するかについての詳細を取得する必要があります。 たとえば、外部カタログで製品SKUを参照するフィールドの場合、カタログに対して動的参照を実行する必要がある場合があります。

  • 「タクソノミ」-Oracle Content Managementでは、任意の数のタクソノミおよびカテゴリでアセットを分類できます。 これらのカテゴリは、事業部門、チーム、キャンペーン、オーディエンス・セグメントなどを表すことができます。 通常、コンテンツを整理するために、リポジトリには少なくとも1つのタクソノミがあります。 新しいタクソノミを作成し、タクソノミの構造をいつでも変更できますが、移行されたコンテンツを整理し、アップロードされたコンテンツを分類する習慣をユーザーに理解するために、最低限のカテゴリ・セットを設定しておくと便利です。
  • 「翻訳ルール」-Oracle Content Managementでは、デジタル・アセットを複数の言語に翻訳できます。 多くの場合、これはアセットのメタデータ(イメージ・キャプションなど)の翻訳に制限されます。 ただし、言語ごとに異なるバージョンのアセットを管理することもできます。 これは、埋込みテキストを使用してビデオやイメージ・バナーを管理する場合によく使用されます。 どの言語や翻訳パターン(ある場合)をサポートする必要があるかを理解することが重要です。
  • 「公開チャネル」-Oracle Content Managementは、ユーザーがコンテンツを1つ以上のチャネルに直接プッシュできるように設計されています。 通常、ブランド・ポータル用のチャネル(複数のブランド・ポータルがある場合は複数のチャネル)、マーケティング自動化ツール用のチャネル(Eloqua、Responsysなど)、ソーシャル公開用のチャネル、webサイトやモバイル・アプリケーション用の1つ以上のチャネルがあります。

    各チャネルについて、そのチャネルでコンテンツがどのように使用されるかについての期待を理解する必要があります。 たとえば、Oracle Content ManagementをEloquaおよびResponsysと統合すると、マーケティング担当者は、ランディング・ページおよびEメールで使用するイメージをリポジトリから検索および選択できます。 必要に応じて、いつでもチャネルを追加できます。

  • 「承認ワークフロー」-Oracle Content Managementには、リポジトリ内のすべてのコンテンツを1人のユーザーが承認する基本的な承認ワークフローが付属しています。 Oracle Integrationより複雑な承認や電子メール通知が必要な場合は、プロセスを統合できます。 プロセスには、3つの事前定義済ワークフロー(1ステップ、2ステップおよび3ステップ)が含まれます。 これらのワークフローを検証して、目的に十分なかどうか、または追加のワークフローが必要かどうかを理解する必要があります。 新しいワークフローを作成し、既存のワークフローをいつでも変更できます。
  • 「アクセス・コントロール・ルール」-Oracle Content Managementを使用すると、管理者はリポジトリのコンテンツにアクセスして変更できるユーザーをすばやく定義できます。 リポジトリに対してより詳細なロールを定義することもでき、特定のアセット・タイプまたは特定のカテゴリのコンテンツのみへのアクセスを制限できます。 アクセス制御ルールは、必要に応じていつでも変更できます。
  • 「ブランド・ポータル」-Oracle Content Managementには、完全なOracle Content Managementユーザー・インタフェースへのアクセスが望ましくない場合、事前構成されたブランド・ポータル・アプリケーションが付属しています。 ブランド・ポータルを使用すると、ユーザーはタクソノミを検索してナビゲートし、目的のアセットを検索できます。 その後、アセットをリンクまたはダウンロードして外部で使用できます。 通常は、ブランド・ポータルのロゴと色を調整し、ホーム・ページをカスタマイズします。 それぞれ独自のブランディングを持つ複数のブランド・ポータルを作成することもできます。 必要に応じて、より高度なカスタマイズも可能です。
  • 「レガシー・コンテンツ移行」-レガシー・コンテンツの移行がプロジェクトの一部である場合、基本的な要件も検出セッションの一部として対処する必要があります。 新しいプラットフォームで使用可能にする必要がある既存のメタデータの種類を理解することが重要です。 多くのレガシー・プラットフォームでは、分類ではなくフォルダごとにコンテンツを編成します。 フォルダ構造を移行する必要があるかどうかを決定し、移行する場合は、タクソノミまたはメタデータ・フィールドのどちらで表されるかを決定する必要があります。

検出セッションの実行時に、Oracle Content Managementでリポジトリを直接作成し、各セッション中または各セッション後に構成を変更することを検討できます。 これにより、ユーザーは自分のディシジョンがユーザー・インタフェースにどのように反映されるかを確認できます。

利害関係者契約の取得

主要な要件を定義したら、それらの要件を利害関係者と検証することが重要です。 後で変更を行うことは可能ですが、特に使用状況が進むにつれて、システムを設定する前にコンテンツ・モデルおよびアーキテクチャを変更することは容易です。

ステージ2 - 設定と構成

2番目のフェーズでは、Oracle Content Managementインスタンスの起動および実行に重点を置きます。 通常、このステージは複数のスプリントを取らない必要があります。

アカウントのプロビジョニングおよびインスタンスの作成

アカウントのプロビジョニングは主に自動化されたタスクであり、Oracle Cloudテナントをアクティブ化する必要があります。 内部Oracleプロセスによっては、1日または2日かかる場合があります。

このアクティブ化プロセスが完了したら、数分でOracle Cloud Infrastructureコンソールから「Oracle Content Managementの1つ以上のインスタンスの作成」を実行できます。 このフェーズでは、Oracle Content Managementの単一インスタンスを作成することをお薦めします。 このインスタンスは本番インスタンスとして構成する必要があるため、これを反映する名前を割り当てる必要があります。 インスタンスの名前は一度作成すると変更できません。 ただし、エンド・ユーザーがアクセスできるようにカスタムDNS名を割り当てて変更できます。

後のスプリントでは、テストまたは開発のために非本番インスタンスを作成できます。 たとえば、カスタム・ポータル開発をテストしたり、他のアプリケーションとの統合をテストする必要がある場合があります。

プラットフォームへのアクセスの構成

ユーザーおよびグループは、Oracle Cloudテナンシの一部として作成されたOracle Identity and Access Management (IAM)コンソールから作成および管理できます。

Oracle Content Managementインスタンスを作成すると、複数の「事前定義済アプリケーション・ロール」がIAMに作成され、そのインスタンスに関連付けられました。 これらのアプリケーション・ロールは、Oracle Content Managementの特定の機能に対するアクセス権を定義します。 IAMコンソールから、「ユーザーおよびグループの作成」を行い、これらの各ロールに割り当てることができます。

Oracle IAMは、一部またはすべてのユーザーの認証をActive Directoryなどの外部ディレクトリに対してフェデレートするように構成することもできます。

このスプリントでは、IAMで必要なユーザーおよびロールを直接構成することをお薦めします。 フェデレーテッド認証およびSSOの構成は、後で行うか、セキュリティ・チームによってパラレルに行うことができます。

ステージ3 - 設計と構築

検出フェーズの最後に、特定の要件に応じてOracle Content Managementの構成を開始するために必要な情報のほとんどが必要です。 この第3フェーズでは、検出セッションで識別されるコア構成の実装に焦点を当てます。 フェーズが終了するまでに、完全に構成されたDAMリポジトリと、要件に基づく重要なカスタマイズが必要です。

一般に、このステージは1つまたは2つのスプリントのみを使用します。

メイン・リポジトリの構成

Oracle Content Managementは、任意の数のリポジトリの作成と構成をサポートします。 ただし、通常、デジタル・アセットの管理の大部分が一元化されているメイン・リポジトリがあります。 このフェーズでは、このリポジトリの構成に重点を置きます。

Oracle Content Managementで「空のリポジトリの作成」から開始できます。 他のアーティファクト(アセット・タイプなど)を作成するときに、ユーザーがリポジトリ内から参照できるように、このリポジトリ定義を編集する必要があります。 次のアーティファクトを作成する必要があります:

  • 「アセット・タイプ」-検出セッションで識別した様々なアセット・タイプを作成します。 メタデータの要件がない場合は、デフォルトのアセット・タイプを使用できます: イメージ、ビデオおよびファイル。
  • 「公開チャネル」および「ローカリゼーション・ポリシー」-コンテンツがリポジトリから消費される様々な方法を表す1つ以上の公開チャネルを作成します。 1つ以上のOracle Marketingツール(Eloqua、Responsysなど)と統合する場合、「Oracle Marketing」のような名前を持つ単一のチャネルを作成できます。 ブランド・ポータルのチャネルを作成する必要はありません。 これは、必要に応じて後で作成されます。

    公開チャネルごとに、そのチャネルでサポートされている言語とポリシーを定義する必要があります。 必要に応じてコンテンツを公開するチャネルごとに異なるローカリゼーション・ポリシーを作成することも、すべてのチャネルで共有する単一のローカリゼーション・ポリシーを作成することもできます。

  • 「タクソノミ」-検出セッションで識別したカテゴリに基づいて、1つ以上のタクソノミを作成します。 ブランド・ポータルを作成してレガシー・リポジトリからコンテンツを移行するときに、後で追加のタクソノミを追加できます。
  • 「翻訳コネクタ」-自動翻訳が必要な場合は、Lingotek用に事前構成された翻訳コネクタをアクティブ化するか、独自の翻訳コネクタを追加することを検討してください。 Lingotekを含むほとんどの自動翻訳サービスには、追加コストがかかります。
  • 「コンテンツ・コネクタ」-Oracle Content Managementには、Google Drive、OneDriveなどの一般的なクラウド・サービスからコンテンツを取り込むための組込みのコネクタがいくつか用意されています。 これらのいずれかがプロジェクトで重要な場合は、ドキュメントに従って構成します。

異なるアーティファクトを作成したら、必ずリポジトリに追加する必要があります。

ディスカバリ・セッションから適切なレベルの詳細がある場合、これらのアーティファクトを使用して新しいリポジトリを構成することは迅速かつ簡単です。 通常、作業自体は数時間で実行できます。 ただし、コンテンツ・モデルに変更をいくつか繰り返したり、他の変更を識別してソリューションの有用性を確保することは珍しくありません。

承認ワークフローの設定(必要な場合)

アセットは、「すぐに使える基本的な承認/却下ワークフロー」を使用して確認できます。構成されている場合は、「Oracle Integrationからのワークフロー」を利用できます。 リポジトリごとに異なるレビューまたはワークフロー・オプションを設定できます。

より高度なロールベースのワークフロー承認が必要な場合は、Oracle CloudテナントにOracle Integrationプロセスのインスタンスを作成する必要があります。 このサービスには、追加の月次コストがかかります。

Oracle Integrationインスタンスが稼働したら、documentationをたどってOracle Content Managementに接続し、サンプル承認ワークフローをデプロイする必要があります。 ワークフローをデプロイした後、Oracle Content Managementユーザー・インタフェースからワークフロー・ロールをOracle Content Managementユーザーにマップできます。

事前構成されたワークフローを変更する必要がない場合、この設定は数時間で実行できます。

ブランド・ポータルの作成

Oracle Content Managementには、コンソールへの直接アクセスを必要としないエンド・ユーザーをサポートするために、必要に応じてカスタマイズできる「ブランド・ポータル」サンプルが含まれています。 ブランド・ポータルのインストールには数分かかります。 新しいアセット・タイプ、新しいタクソノミおよび新しい公開チャネルがリポジトリに作成されます。

ブランド・ポータルが作成されたら、次のような簡単な変更を加えます:

  • ロゴを会社のロゴに変更します。
  • 会社のブランディングに合わせて色スキームを変更します。
  • ホーム・ページを更新して主要なアセットを表示するか、ポータルの使用方法に関する説明を共有してください。
  • 言語の要件に合わせてローカリゼーション・ポリシーを調整します。
  • 必要に応じて、ユーザーがブランド・ポータル内のアセットのライブラリをナビゲートできるタクソノミおよびフィルタを変更することもできます。

ブランド・ポータルでユーザーがコンテンツを使用できるようにするには、それらのアセットをブランド・ポータル・チャネルに公開するだけで済みます。

サンプル・ブランド・ポータルを大幅に変更する必要がない場合、ポータルの設定には数時間から数日かかることがあります。

ステージ4 - コンテンツの移行

「レガシー・リポジトリからのコンテンツの移行」がプロジェクトの一部である場合、この作業は、特に稼働前に移行を実行する必要がある場合に、できるだけ早く開始する必要があります。 技術的には、レガシー・コンテンツを移行する前にプラットフォームの使用を開始できます。 移行が進行すると、Oracle Content Managementに表示されるとおりに、コンテンツに自動的にアクセスできます。

通常、この第4ステージは最長です。 移行するデータが少ない場合は、いくつかの短いスプリントが必要になることがあります。また、移行して新しいコンテンツ・モデルにマップする必要があるアセットが多数ある場合は、いくつかのスプリントが必要になることがあります。

ステージ5 - その他のカスタマイズ

第3フェーズの終了までに、DAMソリューションが機能します。 これには、中央リポジトリ、ブランド・ポータルおよびオプションのワークフローが含まれます。 必要なものが単純なイメージおよびビデオ管理で、場合によってはOracle Marketingツールと統合されている場合、追加の要件がない可能性があり、稼働できます。 それ以外の場合は、いくつかの高度なカスタマイズまたは構成が必要になることがあります。

カスタムDNS構成リクエストの開始(必要な場合)

デフォルトでは、パブリック・チャネルに公開されたコンテンツは埋込みCDNサービスによって自動的にキャッシュされ、顧客固有のDNS名が次の形式で利用されます:

https://<<CustomerInstanceName>>-<<CustomerTenantName>>.ocecdn.oraclecloud.com

オプションで、「埋込みCDNの構成」サービスを使用して、カスタムDNSホスト名に対してキャッシュできます。 そのためには、Oracle Supportを使用してサービス・リクエスト(SR)を開く必要があります。 このプロセスの完了には最大2週間かかる可能性があるため、可能なかぎり早くプロセスを開始して、プロジェクトの稼働開始に影響を与えないようにしてください。

Oracle Marketingツールに接続(必要な場合)

Oracle Content ManagementをEloqua、ResponsysまたはMaxymiserの中央アセット・ハブとして使用する場合は、すばやく「これらの統合の構成」できます。 各ツールとの統合は多少異なります。 場合によっては、自分で構成することもできます。 その他の場合は、SRを開く必要があります。 いずれの場合も、統合にはリポジトリの詳細が必要であり、公開されたアセットにアクセスするための特定のパブリック・チャネルを作成する必要があります。

最大で1日ですべてのサービスへの接続を設定できる必要があります。