適切に構築されたデータ アーキテクチャのメリットは、運用プロセスだけにとどまりません。 そのメリットは、戦略的な運用効率、より深いビジネス洞察、隣接するビジネスチャンスに到達する能力にまで及び、すべてがより機敏な方法で実行されます。
前回の記事では、架空の食品注文および配達サービスを紹介し、顧客の注文プロセス、ピックアップおよび食品配達のワークフロー、支払い処理など、いくつかの重要な日常業務ワークフローを紹介しました。 ワークフローへの主要なデータ入力に関する意図的なデータ戦略が、より堅牢で俊敏かつスケーラブルなビジネス プロセスにどのようにつながるかを検討しました。
この記事では、日常的な運用効率を超えて、事前に考えられたデータ アーキテクチャ設計の長期的かつ戦略的なメリットについて説明したいと思います。 当初のシナリオを 6 か月早送りすると、applicationが成功したと仮定すると、ビジネス リーダーはいくつかの新しい機会を特定したことになります。 彼らは現在、基盤となるシステムが特定の機会や関連する課題にどれだけ迅速かつ容易に調整し適応できるかを技術者に尋ねています。
リストされている 4 つの課題の例は、次の 2 つの大きなカテゴリに分類できます。
1つ目は、重要な日常的な(「戦術的な」)ビジネス プロセスを調整し、効率を向上させることです。
2 つ目は、企業の顧客を通じて直接的または間接的に企業に長期的な(「戦略的」)価値を生み出す新しい洞察を生み出すことです。
最初の 2 つの新たな課題 (テリトリーの拡大と関連するコンプライアンス要件) は、戦術的なビジネス プロセスに関連するものであり、本質的にはより運用的なものです。 最後の 2 つの課題は、本質的にはより戦略的なものです。
まず、戦術的および運用上の懸念について見てみましょう。
地理的に他の都市に拡大すると、いくつかの異なる問題が発生する可能性があります。 配送ワークフローの潜在的な問題の 1 つは、番地の曖昧さの解消に問題がある可能性があることです。つまり、同じ住所 (例: 「100 Main St.」) が複数の都市に存在する可能性があります。 もう一つの考えられる問題は、異なる都市がタイムゾーンにまたがっている可能性があることです。これを考慮しなかった場合、午後 6 時の集荷になります。 MDT では、近隣の PDT 都市への配達が 1 時間遅れる場合があります (午後 6 時 30 分)。 PDT)。 前回の記事で説明したデータ アーキテクチャには、データ要素の「正規化された」(グローバルに一意の) 表現という概念が組み込まれており、両方の潜在的な問題に対処しているため、applicationはこれらの追加要件に暗黙的に対応できます。
2 番目の戦術的な懸念は、カリフォルニア州の追加データ ガバナンス要件への準拠です。 カリフォルニア州消費者プライバシー法 (CCPA) に関する一連の懸念事項は、それだけで一連の記事に相当しますが、その 1 つの側面は、顧客のすべてのデータを収集できること、および収集された日時とデータ ソースを注釈として収集できることです。 前述したように、主要なデータ取り込みパイプラインでタイムスタンプなどのメタデータ注釈を追加できるデータ アーキテクチャ フレームワークを構築することで、追加のデータ ガバナンス要件を簡単に、最小限の労力で満たすことができます。
企業の日常的な戦術的なワークフローとプロセスの改善によって生み出されるビジネス価値に加えて、もう 1 つの利点 (おそらくより重要な利点) は、既存の競争の場を傾けると同時に、参加できる新しい競争の場を切り開くことができるという戦略的価値です。
戦略的メリットの 1 つは、主要な運用ワークフローの青写真を変更することで「状況を好転させる」ことができることです。 これは、単に最適化するだけでなく、再考することにもつながります。 堅牢で将来を見据えたデータ アーキテクチャにより、動的な価格設定を使用して、需要の変動によって生じる配送時間の遅延という前述の課題に対処するために必要な主要な機能 (集約とデータ分析) を俊敏かつ効率的に活用できるようになります。
具体的には、データ アーキテクチャが事前に考慮されているため、次のようになります。
その結果、注文と配送という 2 つの異なるワークフローからのデータを相関させ、分類し、集計することができます。 さらに、柔軟なメタデータ アーキテクチャを活用して、照合されたデータに分析用の豊富なコンテキスト情報を注釈として追加することもできます。 全体的な配達待ち時間、つまり注文を受けてから料理が配達されるまでの時間を考慮してください。 遅延は、注文ワークフローと配送ワークフローを相関させることによって計算できます。 さらに、2 つのワークフローにわたる地理位置情報データの表現でも一貫した構文とセマンティクスが使用されるため、配信待ち時間の計算と相関関係を郵便番号などの場所ごとに分離できます。 したがって、データ戦略を事前に検討することで、郵便番号ごとの粒度で全体的な配送遅延のデータセットをより簡単に作成できます。 最後に、柔軟なメタデータ アプローチを活用することで、交通状況や降水量の合計などの追加のコンテキスト情報を時間ごとの統計に注釈として付けることができます。
この時点で、分析パイプラインに取り込む豊富な情報が得られ、予測 AI 手法を使用して全体的な配送時間の増加と相関するパターンを認識し、将来的にそのような状況を予測することさえできるようになります。
このストーリーの最後のステップとして、企業が配送ワークフローを需要と供給の問題として再考し、価格設定を使用して需要と供給を一致させている様子を想像することができます。 具体的な例としては、配達ドライバーの報酬を、固定スケジュールに基づいて、またはリアルタイムの状況に基づいて動的に、時間と場所に応じて調整できるようにすることが挙げられます。 これは、データを活用して実用的な手順 (価格調整) を実行し、ビジネス上の懸念 (全体的な配信遅延の管理) に対処し、クローズド ループ フィードバック (観測された遅延に応じた動的な価格調整) を使用してワークフローを「適応型」にすることで、データ サイクルの「ループを閉じる」ものです。
データから得られる別の種類の価値は、データを使用して「新しい競技場を開拓」し、顧客への直接的な利益を通じて収益化できるビジネス価値を生み出すことです。 6 か月後のシナリオでは、サプライヤー側のパートナーであるレストランに価値を提供するという例が挙げられます。 アプリケーションの顧客に洞察を提供するというビジネスニーズに対する解決策は、アプリケーションの運用ワークフローによって収集されたデータを再び活用することです。今回は、顧客とパートナー向けのビジネス洞察を抽出するための原材料として活用します。 これらのビジネス洞察はさまざまな形をとることができます。例をいくつか挙げます。
こうしたビジネス インサイトの発見は、大規模なデータ ストアの存在だけでなく、一貫したメタデータ語彙を使用して収集されたデータに構造化された方法で注釈を付けるデータ戦略によっても可能になります。
特定のビジネス洞察ストーリーに焦点を当てて、メニュー価格設定の洞察がどのように決定されるかを検討します。 原材料、つまり発注ワークフローから運用的に収集されたデータから始めると、メタデータ注釈付きデータ戦略の価値がすぐに明らかになります。 具体的には、特定のレストランの商品の価格が記録されるだけでなく、関連するメタデータも保存されます。 食品の追加の説明属性、たとえば、分量、食品の「種類」(「ソフトドリンク」や「ハンバーガー」など)、特別な「追加機能」(「サイドディッシュ付き」や「辛い」など)などを検討します。 データ アーキテクチャが、一貫したメタデータ タグ語彙 (「ポーション オンス」、「食品クラス」、「拡張機能」など) と正規化されたメタデータ値のセットを使用して、食品項目データをこれらの属性のメタデータで装飾すると、レストラン間で食品項目情報を比較できるようになります。 たとえば、コード データベースからわかっていることが、「Burger Basement」にはMan Cave Burgerがあり、「Heart Attack Grill」にはDouble Bypass Burgerがあるということだけであれば、意味のある比較を行う根拠はありません。 ただし、メタデータ注釈語彙を追加すると、比較と分析を実行できます。システムは、2 つのアイテムが両方とも「ハンバーガー」という「食品クラス」に属しているため、比較可能であると理解します。 さらに、分析では他のメタデータ フィールドを使用して、部分サイズを正規化することもできます (つまり、「Man Cave」は 8 オンス、「Double Bypass」は 12 オンスなど)。 最後に、「チーズを含む」などの「強化」値の標準スペースを使用して、二次的な類似点や相違点に基づいて追加の調整を行うこともできます。 ここでも、データ アーキテクチャ (今回はメタデータ戦略) に事前に配慮することで、既存のワークフローから排出されるデータを活用するだけで、新しいビジネス チャンスを迅速に実現できるようになりました。
ほとんどのビジネス リーダーは、成功は重要な運用ワークフローの計画と、それらのワークフローの実行の可視性にかかっていることを痛感しています。 優れたビジネス リーダーは、こうした洞察を迅速かつ効率的に生成し、その洞察に基づいて社内外に向けて行動を起こす能力が、継続的な成功の鍵であることを理解しています。
技術者として、私たちは、継続的な運用効率の改善とビジネスの俊敏性というビジネス目標を実現するソリューションを構築するよう求められています。 残念なことに、エンジニアはソリューションのデータ処理ソフトウェア要素に重点を置きすぎて、データ アーキテクチャ自体に十分注意を払っていないことがよくあります。 その結果、社内ワークフローの改善や新しい派生的な顧客向けサービスの展開に多大な労力と展開時間の遅延が生じることがよくあります。 この記事が示すように、データ アーキテクチャ (データ語彙、表現、メタデータ戦略) に事前に注意を払うことは、俊敏で堅牢なデータ駆動型ビジネスの技術的基盤となります。