SAP Analytics Cloud（SAC）概要：ストーリーとダッシュボードを実務で使う基本

SAP Analytics Cloud（SAC）は、業務データを取り込み、分析・可視化・共有するクラウド型の分析基盤です。SAP S/4HANAやSAP BW、外部データなどを対象に、グラフ、表、フィルター、計画関連の画面を組み合わせて利用できます。導入時は機能の多さよりも、誰がどのデータを見て、どの判断に使うかを先に整理すると設計が安定します。

この記事では、SACを使い始める現場で確認しやすいように、主要オブジェクトの関係、ストーリーとダッシュボードの使い分け、データ接続、権限、更新エラーの切り分けをまとめます。SAPの分析・レポーティング全体の位置付けは、SAP分析・レポーティング概要も併せて確認できます。

01SACの基本構成

SACの利用環境では、データソース、モデル、ストーリー、公開・共有の権限が連携します。データソースはSAPシステムやファイルなどの取得元、モデルは分析に使う項目やディメンションの定義、ストーリーは利用者が見る分析画面です。

典型的な流れは、次のようになります。

1. 分析対象と利用者を決める
2. データソースと接続方式を選ぶ
3. 日付、組織、製品、金額などの分析軸を整理する
4. モデルまたは接続先の項目を確認する
5. ストーリーにチャートやテーブルを配置する
6. 権限を設定して利用者に共有する
7. 数値、更新時刻、表示範囲を確認して運用に移す

この順序にすると、画面を作った後で項目不足や権限不足が判明する事態を減らせます。特に、売上や在庫などの重要指標は、集計単位、通貨、期間、除外条件をあらかじめ定義してください。

02ストーリーとダッシュボードの使い分け

SACのストーリーは、チャート、テーブル、フィルター、テキストなどを組み合わせて分析画面を作るための中心的なオブジェクトです。利用者が期間や組織を切り替えながら、原因を掘り下げる用途に向いています。

ダッシュボードという言葉は、複数の重要指標を一画面にまとめた閲覧用の画面を指す場面で使われます。実務では、経営会議向けのKPI一覧、部門管理者向けの例外一覧、担当者向けの詳細分析など、利用者の判断単位に合わせて画面を分けると運用しやすくなります。

1画面に情報を詰め込むと、読み手が重要な変化を見つけにくくなります。最初の画面には判断に必要な指標を置き、詳細はページやフィルターで分ける設計が効果的です。

03データ接続を設計する

データ接続では、データの保存場所、更新頻度、リアルタイム性、ネットワーク経路、認証方法を確認します。業務システムのデータを直接参照する構成と、データを複製・取り込みして分析する構成では、更新の考え方と障害時の確認箇所が異なります。

設計時は、次の項目を一覧化してください。

• 接続先のシステムと担当者
• 利用するデータセットまたはモデル
• データ取得の方式と更新スケジュール
• 日付・時刻・通貨・タイムゾーンの扱い
• 参照できる組織や会社コードなどの範囲
• 接続用ユーザーと認証情報の管理方法
• 障害時に再実行する担当者と連絡先

ファイル取り込みを使う場合は、列名、データ型、必須項目、重複行、空白値を受け入れるかを固定します。手作業でファイルを差し替える運用では、ファイル名、保存場所、承認者、取り込み後の件数確認も手順に含めます。

SAP ERP側のレポートや抽出処理とSACを組み合わせる場合は、元システムで作成するデータとSAC側で作成する表示ロジックを分けて管理します。SAP Queryの運用を確認する場合は、SAP Query（SQVI／SQ01）の基本が参考になります。

04権限と共有を確認する

SACの権限は、ログインできること、コンテンツを開けること、データを参照できること、編集や共有ができることを分けて確認します。ストーリーの閲覧権限があっても、基になるデータへのアクセス範囲が不足していれば、値が表示されない場合があります。

権限設計では、職務ではなく利用目的を基準にロールを分けます。たとえば、経営層は承認済みKPIの閲覧、部門管理者は担当組織の分析、コンテンツ管理者はストーリーの更新というように、操作とデータ範囲を定義します。

確認項目は次のとおりです。

• ユーザーが適切なロールまたはチームに所属しているか
• フォルダーやストーリーを開く権限があるか
• モデルや接続先を参照する権限があるか
• 行または組織単位のデータ制限が適用されているか
• 共有後に別ユーザーで実際の表示を確認したか
• 編集者と閲覧者を分離しているか

権限変更は、管理者ユーザーだけでなく、一般利用者のテストアカウントでも確認します。レポート全体の権限設計は、レポート権限の基本も参照してください。

05ストーリーを作成する実務手順

最初に、利用者が画面を開いて最初に答えたい質問を一つ決めます。たとえば「今月の売上は目標を達成しているか」「在庫金額が増えた拠点はどこか」のように、判断につながる問いへ変換します。

次に、KPI、比較対象、明細の順で画面を構成します。KPIには現在値と単位を示し、比較対象には前年、計画、前月などの基準を置きます。明細では、差異が大きい順や対応期限が近い順など、利用者が次の操作を選びやすい並びを設定します。

チャートを選ぶときは、表示したい関係に合わせます。時系列の変化には折れ線、構成比には積み上げ棒、カテゴリ間の比較には棒グラフ、詳細確認にはテーブルが適しています。色は意味を固定し、警告、達成、未処理などの状態を一貫して表現します。

完成後は、作成者の画面だけで判断せず、利用者の業務シナリオで確認します。期間を切り替え、フィルターを解除し、データが空になる条件を試し、表示された数字を元システムの確認値と照合します。

06更新失敗を切り分ける

データ更新が失敗した場合は、まず失敗した対象、開始時刻、終了時刻、エラー内容、最後に成功した時刻を記録します。再実行を繰り返す前に、接続先、認証情報、対象データ、スケジュールの状態を順番に確認してください。

接続または認証を確認する

接続テストの結果、認証エラーが出る場合は、接続用ユーザーの有効性、パスワードや証明書の状態、接続先の到達性を確認します。担当者の退職やパスワード更新をきっかけに、共有接続の認証情報が無効になることがあります。

データ定義を確認する

列の追加・削除、データ型の変更、日付形式の変更、必須値の欠落は、取り込みやチャート表示に影響します。元データの件数と主要な集計値を、更新前後で比較します。空のグラフが表示される場合は、フィルター期間、組織範囲、権限によるデータ制限を確認します。

更新スケジュールを確認する

スケジュールが無効化されていないか、実行時刻が業務データの確定前になっていないかを確認します。更新成功後も画面の値が古い場合は、利用中のモデル、ストーリー、接続先が想定した対象と一致しているかを確認します。一般的なレポート障害の調査手順は、レポートトラブルシューティングに整理しています。

07運用で残す記録

運用開始後は、ストーリーごとに所有者、利用目的、データソース、更新頻度、最終確認日、利用者、障害時の連絡先を記録します。重要なKPIについては、定義、計算方法、基準日、単位、データ確定時刻も残してください。

変更管理では、画面レイアウト、計算式、フィルター、接続設定、権限を分けて記録します。変更前のスクリーンショットや確認値を保管しておくと、数値差異が発生したときに原因を追跡しやすくなります。

月次または四半期ごとに、利用されていないストーリー、重複したKPI、失敗が続く更新、過剰な共有範囲を見直します。利用実績と問い合わせ内容をもとに、画面を統合または廃止すると、利用者が正しいレポートを選びやすくなります。

08導入時の確認チェックリスト

• 分析の目的と利用者が定義されている
• KPIの計算方法、単位、基準期間が合意されている
• データソースと更新方式が決まっている
• 接続用ユーザーと認証情報の管理者が明確になっている
• ストーリーの閲覧者、編集者、共有者が分かれている
• 組織や担当範囲に応じたデータ制限を確認している
• テストデータと元システムの集計値を照合している
• 更新失敗時の記録項目と連絡先が決まっている
• 所有者、最終確認日、変更履歴を管理している

SACを安定して運用するには、見栄えのよい画面を作ることより、指標の定義、データ更新、権限、障害対応を一つの運用にまとめることが重要です。最初は対象業務と利用者を絞り、確認可能なKPIから始めると、段階的に分析範囲を広げられます。