Asisからどのようなアプローチで標準化を考えるか

データ連携HUBや大規模データレイクなどを用いて、複数の組織あるいは事業を跨いでデータ統合基盤を構築するケースが増えてきました。

取り扱う製品やサービスごとに分かれた事業別システムや拠点別のシステムなど広い範囲のデータが取り込み対象になります。それぞれのシステムで生成されるデータは、同じように見えても意味や形式が微妙に異なることが多いです。個々に設計されたデータを１つに統合していくにはデータの標準化がポイントとなります。

今回のブログでは、既存の基幹系システムを大きく変更せずデータ統合基盤を介することにより既存システムのばらつきを吸収するケースを前提に、どのような点に留意してAsisを分析し、標準化を考えていくかご紹介します。

仮の標準を作ることからスタートする

～代表システムを下敷きに、基準となる仮の標準を作る～

現行に引きずられることなく、トップダウンで業界のベストプラクティスやパッケージ仕様を適用するのも選択肢のひとつです。ただ、そのようなスキルを持ったエキスパートがいない、または現行とのギャップが大きく整合を取るのに苦労する、というのが多くの会社での実情です。そのため、既存システムを参考にしながらボトムアップで進めるアプローチが堅実です。しかし、既存システムで管理しているデータすべてを隈なく分析しようとすると、現状把握だけで膨大な時間が掛かります。そこで、標準化の基準にできそうな代表システムを選定し、これを仮の標準として補強していくアプローチが現実的と考えます。現行をベースとするため、ゼロから始めるより早く拠り所となる姿を構築でき、ほかとのギャップや課題点も見つけやすくなります。代表システムは、主要な業務のカバー率が高い、あるいは業務の特殊性が低いなど、事業を横断して共通化できる可能性が高いものを選ぶのがよいでしょう。

仮の標準を作るには、まず代表システムの予備調査を行います。初めから詳細な分析をするのではなく、代表システムでどのようなデータを管理しているか、粗い分析を行って骨格レベルのデータ構造を描きます。その上で、基準となる代表システムに片寄せしていけば良いもの、代表システムでは標準を賄えないため一から考えるべきものなど、業務領域やエンティティごとに標準化の方向性を決めていきます。片寄せ出来る業務領域やエンティティは代表システムを分析すれば十分であり、一から考えなくてはならない業務領域は他のシステムを含めて再度分析します。

このように、標準化の方向性を仮の標準を作る際に具体化することで、どのシステムを対象に分析するか、どれくらいのエンティティを詳細に分析しなくてはならないか、という分析全体の規模感も把握できます。また、代表システムはあくまで仮の標準を決めるものであり、代表システムが標準に相応しくない場合があるという点に留意する必要があります。

データ構造に着目して分析する

～組織や事業縦割りの既存システムそれぞれのデータ構造を分析する～

標準化にあたり、システムごとに管理しているデータの単位や粒度、種類などの違いが問題となります。例えば、一括りに受注伝票と言っても、その構造は、一品一葉か、商品ごとに複数の明細行があるのか、または販売単価は商品の単位で管理しているのか、商品別取引先別に決めているのか、など違いがあります。まず、システムごとに管理するデータ構造のばらつきを見極めます。その上で、標準のデータ構造にまとめるか、または無理に標準化させず個別のデータ構造を残すか、方針を検討します。これにより、標準化の対象となるデータ項目の絞り込みもできます。こういった標準化の方針は、詳細なデータ項目の分析に取り掛かる前に、システム全体を俯瞰してデータ構造を理解して決めておくことが重要なポイントです。データ構造に着目するため、詳細に属性項目を記述する必要はありませんが、骨格レベルで主要なエンティティと属性、エンティティ間の関連を洗い出します。また、データ構造を分析する際には、データの粒度を正しく理解するために、必ずシステムの画面や帳票を利用するようにします。

物理データベースの定義書上では、テーブルの主キー項目がナチュラルキーで設計されていなかったり、1つのエンティティがいくつかのテーブルに分割されていたりします。そのため、そのデータが業務上どのような単位で取り扱われているかが見えないからです。