Techopediaスタッフ、2017年11月8日
まとめ：ホストのEric KavanaghがImpact AnalytixのJen UnderwoodとIDERAのRon Huizengaとデータの成熟度と組織の成熟度について議論します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：わかった、紳士la女。 こんにちは、おかえりなさい。 水曜日の東部標準時4時です。つまり、Hot Technologiesの時間です。 はい、確かに。 私の名前はエリック・カバナです。 私は今日のショーのホストになります。実際に定義され、データ管理の世界にいる特定の状態の特定の種類のテクノロジーを定義するように設計されています。 そして、今日のトピックは「データの成熟度の達成：組織のバランスをとる法」です。ですから、あなたのものについて本当にスポットがあります。Twitterで@eric_kavanaghを見つけてください。 あなたが私に言及した場合、私はいつもリツイートし、私も同様にフォローしようとします。 これは、世界で何が起こっているかについての情報を入手するのに適した場所です。 私はそのフォーマットが大好きです。 短い文字、140文字–最近ではそれ以上。 自由にツイートを送ってください。フォローします。
今年はもちろん暑いです。 今日はデータの成熟度についてすべて話しているので、ここにラインナップがあります。 今日、新しいアナリストがいます。 Impact AnalytixのJen Underwoodをお迎えできることを非常に楽しみにしています。 彼女は、ビジネスインテリジェンスと分析、データの視覚化、およびこれらすべてのすばらしいトピックの専門家です。 そしてもちろん、データの成熟度。 そして、私たちの良き相棒であるロン・フイゼンガがIDERAから電話をかけています。 最初にジェン、そしてロンから話を聞きます。 そして、素敵な円卓会議があります。
この次のスライドをここまで押し上げて、簡単な言葉をいくつかお話しします。 現在、データ管理の成熟度が課題となっています。 明らかに、成熟について考える前に特定のポイントに到達する必要があり、カーブのどこにいるかを理解しようとして、多くの成熟ライフサイクル（またはサイクル）が開発されました。 あなたは初期段階ですか？ あなたはティーンエイジャーですか？ 大人ですか？ 等。
そして、多くの組織は、成熟の観点から、10代または10代後半または20代前半のいずれかであると思います。 そして、それは落胆するようなことではありません。 ただ、データを戦略的資産として管理できるようになった初期の段階では、私たちはまだそういう人たちです。 そして、物事は急速に変化しています。 特に過去5〜7年で、小さなデータからビッグデータに移行し、これらのかなり異なる世界と新しいテクノロジーを古いテクノロジーと調和させようとしています。 レガシーはそこにあり、どこにでもあります。
私が数年前に聞いたジョークの1つは、レガシーが実稼働中のシステムであるということです。 システムが実稼働に入る瞬間、技術的にはレガシーです。 そして、それは真実です。 しかし、一番下の行は、私たちが長い時間をかけてきたこれらすべてのシステムを持っていることであり、資産としてのデータの価値を最大化および最適化できるように、私たち自身の成熟曲線のどこにいるかを理解する方法を見つけなければなりません。 そしてもちろん、コンプライアンスの問題や、私たちがどの業界にいるかによって心配する必要のある規制があります。そしてもちろん、ハッキングについても心配する必要があります。 過去に、データガバナンスと、それが実際にセキュリティの一部であり、データを使用し、それから最高の価値を確実に得る役割と責任を理解する方法について話してきました。
それで、キーをJen Underwoodに引き渡します。彼女はデータの成熟度についての彼女の見解を伝えることができます。 ジェン、それを奪う。
ジェンアンダーウッド：ありがとう、エリック、そして私を招待してくれてありがとう。 そこで、今日はいくつかの異なるトピックを取り上げ、次にIDERAでRonを紹介します。彼はこの特定のトピックの他のいくつかの領域についてさらに掘り下げていきます。 エリックが言ったように、それはデジタル時代やデジタル変革において今重要な役割を果たしており、進化している時代です。 EDM評議会からのいくつかの楽しい統計、データ管理業界のベンチマークレポートがありました。 それはほぼ2年前ですが、それでもかなり関連性があり、この空間でティーンエイジャーであることに関する事実上の事実を明らかにします。 データの成熟度とガバナンスの柱自体について少しお話しします。
あなたがどこでも聞いているデジタル時代またはデジタル変換のこのテーマで、これはまさに今起こっています。 毎日業界をフォローしているうちに収集した興味深い事実の1つは、ガートナーがトップ10の戦略的技術トレンドで指摘したことです。 そして、彼らは2020年までに言っていました-それから私たちはほんの数年しか離れていません-情報は、10年前から持っているプロセスの80％を再発明、デジタル化、自動化、または排除するために使用されます
そして、私はしばらくこれを見てきました。ここでは、さまざまなタイプの人々が「データは新しいオイルだ」と言っているのを見ていると思います。 現在、データはデジタルゴールドであると言っています。 ソフトウェアアプリケーションとソフトウェアの関与について考えると、私は過去にマイクロソフトの世界的なプロダクトマネージャーであり、私のキャリアの変化でさえ、ソフトウェアに焦点を当てることになりました。データを収集し、データの収益化について考えます。
データがデジタルゴールドであるこの時代に入り、最高データ責任者と呼ばれるものが出現し、彼らが知っているように、2つの主要な任務と、確かに他のいくつかの任務があることに気付き始めています。データが安全で安全であることを確認し、そのデジタル資産として内部的、さらには外部的にもデータの価値を最大化する方法を見つけます。 そのため、過去には組織にとって重要ではなかった、または重要であると思われていたこれらの種類のデータは、最終的にCDOでCレベルの表に位置付けられ、さらに真剣に進められます。
データ管理と成熟度について考えると、このスライドには2つの異なるテーマがあります。最初のテーマは、データ管理そのものです。 それは、データとデータフロー、いくつかのポリシーとそのプラクティスを開発および作成するビジネス機能に関するものです。 そして、データ管理の成熟度を考えると、組織が持っているデータを正確に定義し、簡単に統合して、データ収益化などの内部または外部の目的に再び活用することができます。 そして、大きなテーマの1つであり、私のキャリアの早い段階でおもしろく、IDERAのツールとデータアーキテクチャプロジェクトのいくつかを実際に活用しました。これはメタデータのこの概念全体であり、メタデータについて考え続けました。ずっと長い間 メタデータが再びクールになりました。 さまざまなグループとやり取りし、データがどこにあるのか、データが何であるのかを理解する上で非常に重要です。 特にデータレイクのようなもので。 ついに面白くなってきました。
さて、ここで業界ベンチマークレポートからいくつかの統計情報を入手すると約束しました。 これはEDM評議会の2015年からのものです。 それは、データの品質とガバナンスを近代化することであり、この特定のものにはいくつかの面白い事実があります。 そのため、ここでは、組織の33％以上が組織のあるレベルでアクティブで正式なデータ管理プログラムを持っています。たった33個です。それ自体が非常に興味深いものです。 正式に定式化された50パーセントのうち、データを管理したいと考えています。これは、人が人を持っているのと同じように、これが組織にとって本当に重要な資産であることに気付きます。 1年以上前のプログラムを使用していたのはそのうちの50％のみでした。 繰り返しますが、これは新興分野であり、特に業界規制のいくつかが出てくるなど、ますます重要になっている点で非常に興味深いものです。
その点で、何度も-そして、私のキャリアを通じて技術的な販売と役割に携わっていたことは興味深いです-「ああ、私たちは組織を動機付けるお金を節約できます」-それは通常恐怖です。 それは、「ああ、まあ、私たちはカバーされていることを確認する必要があります。 ハッキングやデータリスク、データの漏洩など、確かに、これに関する非常に興味深いベンチマーク研究があります。 Verizonは毎年1つを実行しますが、おそらくレビューするのが私のお気に入りの1つです。 あなたがほとんどいつも見ているのは不注意であり、必ずしもデータの意図的な誤用またはデータの誤管理が漏れにつながるわけではありません。 そして、多くの場合、彼らはこの特定のセッションに関するこれらの統計情報を持っていませんが、許可やその他の誤った管理のこれらの偶然のリークが魅力的です。 物事を少し簡単にするために、これらのリークは貸し出されます。 そして、通常、あなたの組織の副業的または外部的な人々に、それはあなたが望むものではありません。
したがって、これらは、データ管理のセキュリティとガバナンスのプログラムを持つことを考えるときの種類です。 悪い決断やお金の節約だけでなく、安全であり、プライバシーとセキュリティの法律を遵守していることを確認します。 このデジタル時代のデータを収益化することができます。もちろん、物事を効率的に行い、データを再利用し、祝福されたコピーを持ち、持っていることを望みます。 「分析の分野で長い間、真実の1つのバージョンでした。 異なる視点から見た場合、通常、真実の通常複数のバージョンがあります。 しかし、本質的には、意思決定の基にしているデータの信頼性を高めたいと考えています。
私が目にしている最大の要因の1つは、欧州連合のGDPRの概念全体です。 それについて少し話させてください。 GDPRがわからない場合は、来年、GDPRについて多くのことを聞くことになります。 5月に実施されるのは新しい法律です。 2018年5月に施行される予定で、情報の誤管理に対して大きな罰則が科せられます。 これについては、GDPRという用語を使用せずに他の形式で話されたことを聞いたことがあるかもしれませんが、これは忘れられる権利として書かれていることを聞いたり見たりした可能性があります。 繰り返しますが、過去のデータアーキテクトは、データを削除しませんでした。 変更し、データウェアハウスのシナリオでは非アクティブにします。 データを実際に削除したことはありません。 そのためのプロセスはありませんでした。 したがって、組織のあらゆる側面、およびアプリケーションやデータウェアハウスを構築する際に考慮したことのないさまざまな方法やプロセスに影響を与えるものです。 したがって、GDPRについて考えていることを見ると、すぐに個人データの収集と処理を正当化する法的根拠が必要になります。
そのため、これは主に個人レベルで行われるため、同意を自由に与える必要があります。具体的で、情報に基づいており、明確です。 そして、人工知能とデータサイエンスの多くの分野に影響を与えます。最近取り上げるのは、データサイエンスへの影響であり、モデル自体に透明性があることを確認することです。 BI、データウェアハウス、マスターデータ管理、さらには顧客360プロジェクト、パーソナライゼーション、さらには基幹業務アプリケーションまで。 したがって、これは組織のあらゆる部分に影響を与えるものです。 また、他の法域のプライバシー法とは異なり、GDPRは欧州連合の内外にあるすべての組織に適用されます。 また、コンプライアンスの罰金も重要です。 それはあなたの組織があなたの総年間総収入の4％まで罰金を科せられることができるということです。
うまくいけば、私はあなたの注意を払っており、これらはあなたが注意を払うべきものです。 あなたの会社がすでにこれらのプラクティスと業界標準のいくつかをPCIで守っていれば、それはISOかもしれません。私がこれを正しく言うのかどうかはわかりません-27001。あまりにも圧倒的すぎるが、それは確かに注意することです。 そのため、特にデータ管理にはいくつかの領域があります。最初に行うことの1つは、カタログを作成してデータを分類することです（データの場所を知ること）。 そして、データが至る所に存在する世界、ハイブリッドの世界では、データはクラウドにあります。 これらのアプリにあります。 それは営業部隊にあります。 マーケティングが使用している他のランダムプログラムでも、顧客システムや在庫システムなど、これらすべての場所が使用されています。 データがどこにあり、最も簡単なことを知ってください。これは、データ管理の非常に楽しい分野でした。これらのデータカタログの概念は、インテリジェンスを持ち、機械学習の分類も情報の一部です。
繰り返しますが、メタデータ–メタデータは再びクールになりました。したがって、メタデータについて真剣に考え、データレイクやそれらの種類のものの設計を開始し、もちろんこれらを管理および監視する際に、その重要なトピックについて説明しません。 そのため、たとえば、GDPRの誰かが戻って行かなければならない場合、監視はより重要になり、そのデータがどこに行ったのか、誰が持っているのか、誰がアクセスしたのかなどを証明するように求められることがあります。 あなたは実際に当局にこれらの種類のものを示さなければならないからです。
データ管理の成熟度を支援するために、実際にはいくつかの流派があり、私は-私は100％確実ではありません-ロンのデッキで彼がこれらのいくつかをカバーすることを見たと思います。今日お話しするのはCMMIからです。 そして、これは人々に利用可能です。 データ管理の6つの異なるカテゴリ、25のプロセス領域、414の実践ステートメント、および596の異なる作業成果物をカバーしています。 だから、データや596の機能的な作業成果物を管理および設計しているなど、自分がしていることすべてを考えても、あなたは自分がどれだけのことをしたのか分からなかったでしょう？ またはあなたが本当にしていないこと。 私がそのような数字を見るとき、それは本当に私の心にとどまるものの一つです。 この点で、そしてこの特定の点で私が気に入っているのは、アーキテクチャとテクノロジーが中立であることです。 つまり、もしあなたが持っているなら、そして私が長年にわたって相談したり、働いたり実装したりした大規模な組織のほとんどは、あらゆる種類の異なるテクノロジーを持っているということです。 そのため、DMMの意味を、特定の環境内で使用しているプラットフォームとテクノロジに変換する必要があります。 また、業界に依存しないため、たとえば医療に必ずしも固有のものではありません。 医療には確かなものがあります。BAAであろうと、さまざまな種類の分類であろうと、プログラムや組織内のデータ管理の成熟度を向上させる計画をまとめる際には、さまざまな種類のものを翻訳または検討する必要があります。
それらの一部ではない場合、これは何ですか？ 本質的には、何を定義することですが、その方法を具体的に説明するものではありません。 私のキャリアの中で最もタイプAの性格だったので、人々が私に目標を与えてくれたときが好きで、その目標に到達する方法を理解することができました。たとえば、私の時間、そこに到達する方法を細かく管理していませんでした。 これが、データ管理の成熟度、およびCMMIを使用したこれらのプロセスであり、目標を与え、これらの異なる領域のいくつかで自分自身を測定する方法を与えています。 そして、彼らはあなたにレベルを与えます。 レベル1からレベル5まで、自分でスコアを付けて測定するさまざまな方法があります。つまり、最適化され、本当に強力なプログラムが用意されているということです。
そして、それが本当に何を意味するのかをお伝えするために、ここでそれが何を意味するのかについて少し概説します。 したがって、ここでは、データ管理の成熟度プロセッサのライフサイクルを考えると、要件、リスク管理、プロセスをサポートする必要がある、データガバナンスに至るまで、サポートプロセスがすべて整っています。それについては大したことではありませんが、基本的にデータガバナンスはそれ自体がプログラム全体です。 ビジネス用語集を作成して、ビジネス用語集とデータアーキテクトについて永遠に話しました。これは、組織内にあるものでなければなりません。 これらのカタログタイプのテクノロジーのいくつかは、情報のクラウドソーシングとビジネスグロッサリーの作成、作成、およびその他、そして同じデータの異なる視点、データのフィールドへのドキュメントへのリンクの挿入を行っています、または値のライフサイクルを通じて変化するデータのバージョン。
これらは、私がキャリアを始めてからずっと良くなったタイプのものです。 この種のことを行うには、過去に自社開発のシステムを開発する必要がありました。 ですから、全体像と全体像を見ています。それは戦略であり、経営陣からガバナンスの質に至るまでのさまざまな要素です。 また、データ品質に関する1つのことは、業界がより自動化され、自動化された意思決定を行うこれらのデジタルプロセスがあるため、興味深いことです。 これらのツールのいくつかが意思決定を自動化し、オンザフライで予測モデルを更新するデータサイエンスの分野で多くの仕事をしています。 これらのツールとアルゴリズムの多くは、データが適切であることを前提としています。 適切な自動決定を行うには、データが有効である必要があります。 考えてみると、データ品質は、通常、人々がちょっとしたことはさておき、あまり真剣に考えていないことの1つです。 しかし、予測モデリングと機械学習のモデルで意思決定の自動化を開始すると、データ品質が非常に重要になります。
ここでの進捗状況を測定するいくつかの方法は、次のとおりです。ロンにこれについて話させてください。彼はセッションでこれについても素敵なスライドを用意しています。これでこれらの異なるレベル。 基本的には自己評価ですよね？ そのため、データガバナンスと、何が整っていると思うかを調べます。 そして、もしあなたが恥ずかしがらないでください。 私が言ったように、実際にこれらのタイプのことを始めた組織は33％しかありません。 少なくとも、これらのタイプのプログラムはすでに行われていますが、私は20年以上にわたって業界に携わっており、確かに数年前にこれらのタイプのことをやっていたので、これを単に呼んだわけではありません。 CMMI、彼らはあなたが自己評価できるエクササイズを持っており、あなたは自分自身を調べて、あなた自身のもの（この場合この種のレーダーチャート）を作成し、これらすべての異なる角度や物事を評価できます。 そして、私が行ったように、各組織は、これらのプロジェクトのコンサルティングと実装を行っていたとき、各組織が一意であることを知っています。 それらは彼らにとって本当に重要な領域になるでしょう。 たぶん、それはプロセス管理、品質管理、またはリスクです。それが何であるかによって異なりますが、ベンチマークまたはベースラインを見て作成し、その成功を定義するものについても考えてください。
その上、これらの種類の物事を測定し、管理することを考えている場合、まずこのようなプログラムのエグゼクティブスポンサーシップを確保する必要があります。 これは組織全体で機能横断的になるため、スージーQとジョンスミスが「うん、これをやろう。これをやる必要がある」と判断しても、サイロでそれを行うことはできません。彼らの組織、またはそれがITであっても。 ビジネスとデータの主題の専門家からの賛同が本当に必要です。 彼らには時間が必要です。 彼らはそれを単なる追加のタスクにしたくないのです。 あなたがこれまでに働いたことがあるなら-私はいくつかのマスターデータ管理タスク、以前のプロジェクト、およびデータ品質をやったと思います-そして、通常、あなたはビジネスに着きます、そして、彼らは「ああ、データスチュワードシップ」。彼らが興奮している何か。 そして、彼らは「ああ、いや。 これには時間が必要です」と彼らはしています。 ですから、ある程度の時間を費やす必要があります。 あなたは上からその祝福を得る必要があります。 あなたはそれがクロス機能であることを望むでしょう。
繰り返しますが、これは組織の多くの領域に本当に影響を与えるものです。 そして、GDPRを使用すると、GDPRの法律およびその個人データが顧客に使用され、組織全体で使用される場所であるため、それを少し簡単にする必要があります。 GDPRに準拠します。 ここで縛られます。 それはあなたにとってより簡単なはずです。 何らかの責任を割り当ててから、これらをカスタマイズすることを検討してください。 そのため、これらの組織が提供するこれらの種類のガイダンスを常に確認しますが、それは通常それらのガイダンスです。これらはあなたのためのガイドラインであり、組織の文化に合わせて実装します。
ガバナンスで働いたことは本当に重要でした。マイクロソフトで世界規模の製品管理を行っていたときに開発した製品の一部は、セルフサービスBIであり、ビジネスユーザーと非技術データユーザーがデータを操作して独自のレポートを作成すると、多くの場合、ITが押し返します。 だから私はこのガバナンスに多くの時間を費やし、製品が適切な機能と監査とロギングを備えていることを確認し、データベース自体をダウンさせないようにしました。 しかし、これらのタイプのこの特定のトピックに長年取り組んでいるフレームワークがあります。これは、データ管理にも実際に似ています。 このためのエグゼクティブスポンサーシップで確立された基盤が必要になります。また、ビジネスとITの間のコミットメントが必要になります。
繰り返しになりますが、予算/時間の割り当てと新しいプロセスの開発について話しました。 これらのことのいくつかを行うと、文化レベルの変化になるでしょう。ご存知のとおり、データを見始めます。 しかし、戦略的な観点からも非常に重要です。 そして、あなたに感触を与えるために、ここに例があります、そして、私は数年前にこれらのタイプのものに関する私の古いプロジェクトの1つからそれをきれいにしました。 繰り返しますが、これはおそらく一般的なガバナンスの観点からのものですが、データ管理プロセスを管理および進化させ、それらを管理することで、これらのタイプのプロジェクトに確実に再利用できます。 あなたにはビジネスの主題の専門家がいます。ここにはデータスチュワードがいます。ITの主題の専門家は、さまざまな事業分野に対応しています。 大規模な企業の多くは、エンタープライズ標準ボードとエンタープライズアーキテクト、データアーキテクト、モデラーをそこに配置します。 したがって、さまざまなレベルのさまざまな主題の専門家がいます。 繰り返しになりますが、これらの多くは、例として挙げたくありませんが、組織や文化に合わせてカスタマイズされます。
これらのプロジェクトで作業しているときの1つは、多くの場合、おそらく組織で最もエキサイティングなプロジェクトではなく、人々が望むほど視覚的ではないことです。 おもしろいことです。コンサルティング会社が入ってきたとき、あるいは自分のITグループに入ってきたとき、またはBIのエクセレンスグループが入ったとき、またはアナリティクスセンターオブエクセレンスが出てきて、データに取り組むとき品質とデータ管理の成熟度、彼らはそれを行うことに信じられないほど興奮していないかもしれません。 しかし、それらを動かす方法を見つけて、測定値に含める必要があります。 ですから、これから何をするのかを考えるとき、このエクササイズを一度行うだけで、人々を乗せることができます。 そして、あなたは彼らがデータカタログを愛している、または彼らが人生を楽にし、データが意味するものを見つけたり理解したりできるので、これらのもののいくつかを愛していることを見つけ、彼らはそれに対して独自の視点を加えることができます。 そして、データカタログは、おそらく人々がこれに本当に夢中になるのを助ける最大のプロジェクトの1つです。
それで、次は、彼らを引き付けることです。 多分これを気にしない人をどのように関与させるのですか？ いくつかの測定基準を定義し、それを含め、その測定を行い、違反がある場合に学習し、「しばらくの間本当に良いことをしていたが、しばらくしてあまり良くなかった」という認識を与えます。それを続けようと考えているもののタイプです。 そして、スコアリングについて考えてみると、これはCMMIの例であり、これが彼らのスコアリング方法です。 繰り返しますが、独自のダッシュボード、独自のKPI、組織内の人々のさまざまな測定方法があります。 しかし、あなたはあなた自身の成功を採点し、測定するさまざまな方法があります。 あなたがこれから取り去るべき、またはこれから取り去るためのフックの重要なポイントは、あなたが成功を測定する方法を持っていることを確認し、あなたもあなたの成功を祝うことができることです。
それで、あなたがこのエキサイティングなトピックに夢中になってくれたことに感謝します、そして私はロンに引き渡すつもりです、それはもう少し深く掘り下げるつもりです。
Ron Huizenga：ありがとう、ジェン。 本日はご参加いただきありがとうございます。 次に、ジェンが話したことのいくつかの側面を取り上げ、特定の領域についてもう少し詳しく説明します。 しかし、私もやろうとしていることは、少なくともこれらの領域のいくつかについて、ある種の高レベルの自己評価をどのように行うことができるかについての要約を提供することです。 というのは、CMMIモデルとそのタイプで見たように、多くの異なるインジケーターを使用して非常に迅速に深く進むことができるからです。 ですから、私たちが本当に達成したいのは、組織がかなり高いレベルにあることをよく理解してから、他の組織へのドリルを開始できるようにすることです。 それで、組織の有効性についてお話します。 そして、私はそれをCMMIと、長年にわたってそこから生まれてきた他の標準や知識体系に基づいて考えていきます。 次に、データの成熟度とプロセスの成熟度の成熟度インジケータのいくつかについて説明します。これを見ていくと、それらが密接に関連していることがわかります。 そして、サポートの観点から、ジェンはある分野のガバナンスについて話しました。 また、エンタープライズアーキテクチャについても少しお話しします。 そして、それを要約して、円卓会議に行きます。
これを見ると、長年にわたって公開されている多くの標準とBOKがあります。もちろん、これらは知識の本体です。 これらの多くは本当に成熟度モデルの能力から生まれました。 そして、これがジェンが話していたCMMIの由来です。 CMMモデル自体は、実際には1998年にありました。実際には、IBMにいたときにWatts Humphreyという名前の紳士によって開始されました。 IBMで27年のキャリアを積んでいます。 しかし、その特定のモデルの実際の積極的な開発は、彼がカーネギーメロンにいたときに始まり、米国国防総省から委託されました。 これを導き出すために、他の多くの標準が使用されています。 そして、他の標準のいくつかでこれについて話すときに業界について知っておくと良いことは、このタイミングを見ると、業界で一般的に見られていたものの背景にも反することです。 これは、特に製造業において、品質の動きが実際に定着し始めた時期であり、それが他の分野にスピンオフしました。 製造プロセスを改善する方法を検討しており、総合的な品質管理、ジャストインタイム製造などのことを行っていました。 そして、そこから生まれた哲学の多くは、仕事の質全体にもたらされました。
そして、それは本当にこれらのことの多くが始まったジャンプスポットのようなものです。 一般産業で始まり、IT、データ、プロセス、情報システムにも進出しました。 私たちが見ている他の基準は、私たちが話していることのいくつかにより密接に関連するか、より具体的であると言うのはもちろん、データ成熟度モデルであり、ジェンは少し話しました。 Object Management Groupによるビジネスプロセスの成熟度モデルもあります。 また、組織がビジネスのさまざまな分野、特に情報や技術の制御目標であるCOBIT、一般にインフラストラクチャであるITILなどのIT主導型に取り組んでいる、または利用している可能性のある多くの標準-多くの人が対処したかもしれないことに焦点を当てています。 再び、総合的な品質管理。 そして、特にメトリックスやその他すべてのことを始めたとき、統計的なプロセス制御のようなものが同様に作用するのを見たかもしれません。 そしてもちろん、私たちが扱う知識の一部は情報またはITの専門家です。 によるデータ管理知識体系。
それと同等のビジネス分析知識体系もあります。 そして、プロジェクト管理の知識体系。 組織内のさまざまな利害関係者が同時に使用しているこれらのものがいくつかある場合があります。 しかし、BOKを除外して、成熟度とは何かを振り返ってみましょう。 成熟度の定義をリストします。成熟度とは、辞書で調べると「成熟している」と表示されるためです。したがって、「成熟」という言葉を使用すると、開発の段階–もちろん、非常に一般的です。 しかし、ここで私たちが本当に見ているのは、私たちがやっていることを、より高いレベルの達成に向けて前進させることです。 そして、あなたが見るように、あなたが見るように、多くの標準を見るとき、特にCMMIと能力成熟度モデルは実際に5ポイントスケールに物事に基づいているので、どのように見えるかを段階的に見ることができます実際にこの規模に沿って成長している方法で進化していますか？
ただし、関心のあることで組織の成熟度を達成するという観点から、成熟度を検討するときは、バランスを取る必要があります。 データの成熟度を達成する必要があり、そこで行う必要がある基準のいくつかについて説明しますが、同時にプロセスの成熟度を達成する必要があります。 彼らは同じコインの両面であり、手をつないで行かなければなりません。 プロセスの成熟度を上げることなく、データの成熟度スケールで0から5に移行することはできません。プロセスの成熟度についても同様です。 あなたは実際にさまざまなステージを進化しているので、両方が一緒に結合されており、彼らは乗り心地のために互いに引き合います。 このことについては、今後のスライドでもう少し詳しく説明します。 私たちが理解しなければならない他のことは、データとプロセスの両方の成熟度を達成することは、エンタープライズアーキテクチャの基本であり、ジェンも話していたガバナンスの一部の基本でもあります。 私たちは、私たちがやろうとしているこれらのことのいくつかの成熟を達成することによってそれらを可能にします。
さて、ジェンが私がもう少し詳しく話そうとしていると言ったスライドの上に。 いくつかのカテゴリを取り上げましたが、ここでCMMスケールを使用し、実際に独自のスケールを使用して、実際に作成していない特定のインスタンスが存在する可能性があるため、スケールの上にゼロを追加しますこれらの例では、すべてのトラクション。 したがって、これらは発生した認識の単なる方法です。 したがって、特にデータガバナンスを見ると、データガバナンスプログラムが設定されていないため、ゼロから始めることができます。 そして、さまざまな分野で成熟し始めて、プロジェクトレベルで導入し始め、次にプログラムレベルで、部門を経て最終的に全社規模で導入し始めると、ガバナンスの観点からは、実際に成熟し、成長していますこれを行う組織。
マスタデータ管理など、その他の面では、正式な案件データの分類なしでゼロから始めることができます。 次に、マスターデータがあり、分類し始めているが、統合されていないことを認識するまで成長します。 次に、統合リポジトリおよび共有リポジトリに向けて作業を開始します。 次に、標準化された環境に入ると、データ管理サービスの提供を検討しています。 そして、さらに上に進むにつれて、マスターデータスチュワードを設立し、最終的には常にこれを真剣に検討するデータスチュワードシップ評議会を設立します。 データ統合の観点から、技術環境、アプリケーション、データベースを見ると、やはり未熟な環境で、多くのアドホックなポイントツーポイントインターフェイスとそのタイプがあります。事。 そして、成長するにつれて、いくつかの一般的なツールと標準の導入を開始します。 その後、一般的な統合プラットフォームを検討していきます。 標準化されると、標準化されたミドルウェアや、エンタープライズサービスバス、標準モデルなどの簡単なものに取り組み、組織内のすべてのデータを分類し、リポジトリ内のビジネスルールなどに結び付けます。ものの。 そして、さらに組織文化に完全に組み込まれた場所に進みます。 そしてもちろん、品質が最重要です。 Jenが語ったように、多くの決定とそこにある多くのツールは、あなたが作業している高品質のデータがあると仮定しています。 したがって、データ品質は、データの成熟度を達成するための基本的な基盤です。
繰り返しになりますが、データを見ると、未熟な環境に多くのサイロや散在するデータがある可能性があります。 受け入れられる不整合がある場合があります。 そして、あなたはその作業を開始し、矛盾を認識し、計画を検討し始めます。 ここで管理された環境を見ると、ここで非常に重要なのは、意思決定でデータを使用するために、消費時にデータをクレンジングすることです。 そこで私たちが本当に話しているのは、データクレンジングです。そこでデータをデータウェアハウスやその他の意思決定支援ツールにロードします。 そして、これは、人々が製品を製造し、組み立てラインを下って、最後に製品を検査し、「ああ、繰り返しますが、決してできないことの1つは、最後に検査して製品の品質を向上させることはできないということです。 あなたはそれに関する問題を見ることができます、そして、あなたは次のものとその後に続く他のものを改善するための手段を講じることができます、しかし、あなたは最後にそれを点検することによってそれを決して改善するつもりはありません。 これは、特にデータの場合に進むにつれて、消費元の場所で検査とクレンジングの観点からより多くの場所に移動する場所であり、それをソースでキャッチしようとするところから構築しますデータ、そのデータに作用するプロセス。データが正確であり、すべてのプロセスで消費に適していることを確認します。 さらに進化するにつれて、品質のKPIの開発と取得を開始し、前進するにつれてデータ品質に対するその防止アプローチの開発を実際に開始します。
組織の行動や見ているものに関して、問題があると思わない場合や気付いていない場合は、組織に拒否フェーズがある場合は、あなたがダウンしていることを教えてくれるかもしれませんレベル0または1に移行する可能性があります。 データの周囲に多くの混乱があり、これらの矛盾を解決しようとしている場合、おそらくレベル1にいるでしょう。 まだリアクティブモードにある場合、マネージドに移行しますが、ガバナンス、品質、マスターデータ管理、およびデータの両方を取り入れた非常に安定したデータ環境が実際に確立されるまで、標準化されません。統合、いくつかのポイントを挙げます。 繰り返しになりますが、それを乗り越えてからは、本当に積極的な管理スタイルを開始します。 組織で非常に予測的な動作があり、それをバックアップする分析とバックアップするKPIがある部分に到達した場合、これを見て、いくつかのことを重ね合わせると、他にもいくつかのことができます組織とその場所を参照してください。 組織におけるITの主な焦点を見てみましょう。 ITの主な焦点がまだテクノロジーとインフラストラクチャにある場合、おそらくスケールのより成熟していない終わりに向かっているでしょう。 しかし、本当に情報に焦点を合わせており、情報を活用した戦略的なビジネスの実現を目指している場合、スケールの成熟した終わりに近づいています。 また、データの観点から見ると、ローエンドの場合はデータリスクが高く、ハイエンドの場合はデータに関連するリスクが低くなります。 そしてその裏側は、組織の価値創造です。 データの成熟度が低いということは、特に組織内にあるデータに関しては、おそらくかなり低いレベルの価値生成があることを意味します。 そして、スケールを上げると、高い価値が生まれます。
これをデータモデリング自体の観点から見てみましょう。 データモデリングが赤毛の継子になっていることもあります。 また、データモデリングは、データの成熟度を達成するための基本です。 ですから、データモデリングがこれにどのように結び付いているかを示すいくつかの兆候についてお話ししたいと思います。 ドキュメントや、小さなアプリの単純な物理データベース生成などに使用されているだけであれば、データの成熟度に関してはレベル1に落ちているでしょう。 概念、論理モデル、物理モデリングなど、さまざまなタイプのモデルを受け入れ、認識し始めると、基本的に設計を進めていることになります。 あなたは本当に設計の観点からそれを使用しています、そしてあなたはレベル1にいます。
エンタープライズモデルまたは標準モデルの構築、複数のモデルへの概念の導入、データ系統、モデルへのガバナンスメタデータの直接的な構築など、よりエンタープライズレベルから検討を開始すると、レベル3、さらに完全なガバナンスのメタデータ、ビジネス用語集の統合などに進みます。 ライフサイクルとデータのバリューチェーンを見ると、本当にレベル4に達します。 繰り返しになりますが、ビジネス用語集、メタデータと完全に統合されたモデリングは、セルフサービス分析のようなものを駆動することができますが、それは本当にかなり成熟した状態を達成したときです。
その一部として、データライフサイクルについて非常に簡単に説明したいと思います。 そして、それについてお話したい理由は、残念ながらデータのライフサイクルであり、ほとんどの場合無視されます。 そして、それが何であるかは、データ要素がどのように作成、読み取り、更新、または削除されるか、および組織全体でそれに作用するプロセスを実際に説明しました。 そのため、業界に長い間携わってきた私たちは、これをCRUDと呼んでいます。なぜなら、それは作成、読み取り、更新、削除だからです。 しかし、組織内のデータを扱う場合、基本レベルでこれを理解する必要があります。 多くの要因が影響します。 それに作用するビジネスルールは何ですか？ データを消費、生成、または変更するビジネスプロセスは何ですか？ それを可能にするためにそれらのビジネスプロセスを実際に実装するアプリケーションは何ですか？ データライフサイクルの観点から見れば、これらすべてが有効です。
繰り返しになりますが、ジェンは以前にこれをほのめかしました-必ずしも真実の1つのソースがあるとは限りません。 また、特定のデータ要素を作成する方法は複数ある場合があります。 そして実際には、複数のシステムまたは複数のインテークを介してさまざまなものが入り、その時点での特定の意思決定のために適切なデータソースが何であるかを突き止めて解決する必要があります。 組織内のさまざまな目的のために、データの複数のバリアントが存在する場合があります。 これを実現するには、ビジネスプロセス、データフローを含むデータリネージ、統合、ETLなどを含むデータリネージをモデル化できる必要があります。そのため、データウェアハウス、データマート、ステージングエリアの抽出、変換、ロードを行います。もちろん、ビッグデータ側のデータリンクも同様に機能します。 この情報をデータレイクから引き出す際には、その情報の使用方法と使用方法を知る必要があります。 ライフサイクル自体に関して言えば、それは本当に新しいデータをどのように作成または収集するか、どのように分類するかです。それを効果的に理解して使用するには分類する必要があるからです。 「それを使用している、それらをビジネスプロセスにどのように修正しているのか、組織内で共有されている場所、そして非常に重要なのは、保持とアーカイブ」です。 データをどのくらい保持しますか？ いつアーカイブしますか？ 最終的にそのデータを破壊するのはいつですか？ これらのすべてをデータライフサイクルで考慮する必要があり、組織で高度なデータ成熟度を達成するには、これらすべてを実行する必要があります。
反対に、データの成熟度と併せてプロセスの成熟度について話す必要がある双子のようなものだと言いました。 繰り返しますが、ここにはいくつかの異なるものがあります。これらすべてを読むことはありませんが、チェックリストのようなものですので、心配しないでください。ここでも、組織の観点から自己評価を開始できます。プロセスの成熟度。 最適化されたページを最初から右に見ていきましょう。 繰り返しますが、能力成熟度モデルから導出されたものと同じ5ポイントスケールを使用しています。 フォーカスのようなものを見ると、プロセスの成熟度が低いレベルまたは初期レベルにある場合、作業を達成するために人々が独自の方法に本当に依存していることがわかります。 そして、あなたはいくつかの英雄と物事を成し遂げることができるそのようなものを見るかもしれません。 それから、あなたはそれについてもっと積極的になり、経営陣が作業単位とパフォーマンスに責任を負うようになるまでになります。 次に、標準の統合プロセスの進化を開始します。 次に、プロセスの安定性と再利用。 次に、これらのプロセスに関するメトリックスとKPIを計算し、最終的に完全なレベルの最適化を行うために、メンタリングと統計管理の文化の多くを見始めます。
作業管理を見るとき、あなたは行くかもしれません、あなたは一貫性のない作業管理のレベルからより管理された領域に行きます。そこでは、少なくともより高いレベルでリソースへのコミットメントのバランスを取ります。 その後、より適応性のある組織またはアジャイルな組織を作成して、プロセスを標準化しながら、組織のさまざまな状況で最適に使用できるように調整します。 そして、高度になると、エンパワーメントが非常に重要になります。それは、誰もが何が起こっているかを直観的に理解し、スタッフがプロセスデータを持っているため、自分の作業を評価および管理できることを意味します。
繰り返しますが、製造の類推に戻ります。それを見て、産業の組立ラインなどを近代化し始めたとき、組立ラインでも作業者の総合的な品質とエンパワーメントについて話し始めました。生産の特定の段階で何かがおかしいと、人々は大きな赤いボタンを押して、問題がさらに解決するまで問題が解決するまで組立ライン全体をシャットダウンできるようになりました。 そして、組織内のデータとプロセスを実際に最適化していることを確認するために、プロセスのデータの周りを探しているのは、そのタイプのメンタリティと文化です。
あなたの文化のその他の指標–あなたの文化は、ビジネスプロセスの改善における真のコミットメントの特定可能な基盤がないという点で停滞していますか？ 責任の委任はありますか？ そして、さらに進んでいくと、まだサイロが残っているかもしれませんが、ビジネスプロセスで行っている文化や物事の観点から上に向かって動き始めると、それらの異なるビジネスサイロを壊して活用することにもなります組織全体のプロセス。 イベントステージに到達するとき、あなたが本当にベースにしているのは、直感ではなく、実際に品質指標を収集していること、そしてビジネスのパフォーマンスにおける能力を予測するための指標があることは非常に重要です操作、そしてそれは非常に重要です。
アーキテクチャに関しては、ここで私たちの多くがITに携わっているか、常にITを検討しているため、それについて話しましょう。 繰り返しますが、データで見たものと同じタイプのものです。 プロセスの成熟の初期段階で本当にダウンしている場合、私たちは絶望的なITシステムを持っています。 プロセスの管理を開始すると、サービスベースのアプローチを実際に採用している場所にいくつかのサービスが設定されているのがわかります。 次に、標準化された場合、データやサービス、プロセスサービス、およびその種類の点で、フルサービスや新しいアーキテクチャに到達するまで、より多くのフルサービスを採用することになります。 そして最終的には、データを活用している完全なプロセス駆動型企業になります。
繰り返しますが、これを見ると同じ種類のスケールです。 生産性の観点から見ると、プロセスの成熟度が低いと、生産性が低くなり、プロセスの成熟度が高くなり、生産性が大幅に向上します。 品質もそれと連動します。 データと同じ-成熟度が低い場合は、リスクが高くなり、無駄も多くなります。 しかし、成熟度レベルが高いほど、それを低くし、リスクを減らし、無駄を大幅に削減します。 組織の一種の兆候または指標として見られる可能性のあるものに関して、主な哲学がコスト削減に基づいている場合、おそらくプロセスの成熟度が低いレベルに落ちています。 その後、卒業し、組織の効率をより詳しく調べる方向に進み、非常に成熟したレベルに達すると、再び価値の生成に焦点を合わせます。
組織管理の観点から見ると、カオスが支配している場合、それは通常、プロセス成熟度の低い組織の症状です。 しかし、あなたは私が管理精神と呼んでいるものに焦点を当て始めます-そして、法令による何らかの管理、または物事を課すことがあります-あなたが本当にそうなのか、あなたがより成熟したレベルに到達すると、あなたの管理はより多くのリーダーシップ。 言い換えれば、改善の哲学は文化に組み込まれ、CEOからは、プロセス全体を改善し、組織全体で継続的かつ継続的に改善するという哲学全体を推進しています。
プロセスモデルの観点から（そして、これらのことをここでかなり迅速に説明します）、プロセスモデルがプロセスの成熟度そのものに結びついているのを見てみましょう。 繰り返しますが、データの成熟度で見たものと非常に似ています。低レベルまたはレベル1では、単にプロセスまたは現在の状態プロセスを文書化しているだけかもしれませんが、物事を推進するという点では実際には使用していません。 成熟し始めたら、ビジネスプロセスモデリングを使用して組織内の実際のビジネスプロセス管理を促進し、それを使用している場所でさらに進化し、それらのモデルを継続的に更新して、プロセスの改善を最終的にどこまで進めるかプロセス設計を開始します。 そして、完全に成熟したとき、またはシグマなどの高品質プログラムを採用した組織やリーンで通常見られるものを知ったとき、ここでも継続的な改善の精神があり、それがモデル化に深く染み込んでいますあなたの組織。 飛行機やビル、超高層ビルなど、エンジニアリングの設計図を使用して製品を構築するように、実際にビジネスを推進するのはモデルに依存しています。それが実際に組織要素を推進する設計要素だからです。 。
繰り返しになりますが、ここではこれとすべての単語について詳しく説明しません。 私がしたことは、これらの2つのより単純なグリッドスライドを取得し、データの成熟度とプロセスの成熟度の両方の他の記述子のいくつかで使用された多くの単語を選択したことです。 ですから、事実の後にこれを見るとき、あなたが言われていることに関してあなた自身の内部文化で出てくると思う言葉のいくつかについて考え始めることができます。 そしてそれは、全体的な組織として、全体としてこの成熟度スケールに適合する場所を分類し始めるのに役立ちます。 そのため、一貫性のなさや停滞、または非効率性が頻繁に発生したり、混乱が生じたりする場合は、通常、スケールの下限になります。 継続的な改善、戦略的調整、欠陥と品質への予防的アプローチ、その種のこと、完全な統合などのことを考え始めると、競争上の優位性のベストプラクティスについて話しているとき、それはあなた自身を見ることになるオプティマイザーで、スケールの上限に達します。
繰り返しますが、データガバナンスの検討を開始するとき、特にスケールの下部を検討するときは初期段階であり、データガバナンスは個々のプロジェクトレベルでのみ導入される可能性があります。 データガバナンスと特定の目標がプロジェクトデータガバナンスからのものであり、プログラムと部門のデータガバナンスを通じて進化したポイントに進化する必要があります。この場合も、企業全体であり、組織全体に組み込まれています。
私は、これらが実際にデータの成熟度とプロセスの成熟度の点で連携する双子であるという事実について話しました。 その成熟を達成する上で、スケールのどちらの側も旅であり、ステップをジャンプすることはできません。 ゼロになっている場合、ステージ1、2、3、4を経て最終的に5に到達する必要があります。 そして、世界で実際に5である組織はほとんどありません。 そのため、多くの組織は、3になった時点で満足し、それを今後の踏み台として使用できるようになります。 繰り返しになりますが、データの成熟度から4つ、プロセスの成熟度から1つになることはできません。 それらが互いに絡み合っているため、うまく機能しません。相互に連携してデータとプロセスを理解し、適切に処理する必要があります。
組織化された成熟に向けての旅で、これをそのまま考えるのに良い例えとして、チームが2人で構成されていると仮定しましょう。1人はプロセスの成熟、もう1人はデータの成熟です。 あなたは障害物コースを走っていて、短いロープで結ばれています。 そして、そのコースの終わりに到達するには、両方の障害物を通過する必要があることを意味しますが、すべての障害物を通過する必要がありますが、ほぼ同時にまたは非常に近くにすべての障害物を通過する必要があります次の障害物に進むことができます。 これは、プロセスの成熟度とデータの成熟度のバランスを考えるのに非常に良い方法です。 つまり、プロセス中心になり、データ中心になりますが、先行指標になり、実際にレベルを上げるのに大きなギャップはありません。
そして、データガバナンスからもう一度見ると、あなたが気付いていなかった場合に指摘したいことの1つは、DAMAが実際に今年の初めに知識管理第2巻のData Management Bodyをリリースしたことです。変更された実際のDAMAホイールがあります。 そして実際には、データガバナンスが中心であり、異なるホイールを取り巻く10の異なるカテゴリで、少し異なった表現をしました。 ここで確認することが非常に重要なのは、データモデリングとデザインが実際にホイール上に独自の領域を持つようになったことです。以前は、他の領域とブレンドされていました。 ここで非常に基本的なポイントの1つは、特にデータモデリングがこれらすべての他の側面の基本であるということです。データベースのデータモデリングを行っているか、メタデータを扱っているかにかかわらず、データモデリングは私たちが話している他のすべての作品でプレイしてください。 また、プロセスモデリングは、これらの多くの役割を果たすことができます。データそのものを理解することに加えて、データの使用方法を理解する必要があるからです。
それでは、ギアを少し変えて、エンタープライズアーキテクチャについて話しましょう。 また、モデルはエンタープライズアーキテクチャにとっても重要です。 そして、私はこれを例に基づいており、これは私がここで非常に迅速に示しているZachmanフレームワークです。 これを見ると、ここにいくつかのことがわかります。 何が、どのように、どこで、誰が、いつ、なぜ、スケールの種類が上部に表示されます。 そして、エンタープライズアーキテクチャの観点から非常に高いコンテキストレベルから詳細レベルまで精緻化するモデリングのタイプや物事の観点から、さらに詳細なレベルの精緻化を行います。物理的な実装を含む。 最初の列を見ると、非常にデータ集約的であり、データが含まれています。 方法は非常にプロセス駆動型です。 そして、他の側面を見ると、プロセスとデータモデリングの組み合わせを使用して、残りの情報を促進することになります。 これらすべての異なるものに関するデータを取得することになり、プロセスモデルは、物事が発生する場所や責任など、物事を結び付けることにもなります。 また、ツールで行っているプロセスモデリングの観点から、これを目標や関係、ビジネスルールに結び付けて、これらのさまざまなことを推進しています。
Zachmanフレームワークの全体的な観点から、これについても考える良い方法の1つは、モデル主導型であり、実際にさまざまなレベルを経験しているということです。 したがって、高レベルのスコープとコンテキストから始めています。 その後、ビジネスモデル、システムモデル、テクノロジーモデル、そしてテクニカルモデルの非常に詳細な表現へと進化しています。 繰り返しますが、データは何を表し、プロセスは方法であり、実際にデータとプロセスの相互作用の組み合わせであり、ここで他のすべての特性を駆動します。
それに基づいて、エンタープライズアーキテクチャのアイデアの見方が、他の人とは少し異なることに基づいていることは偶然ではありません。 エンタープライズアーキテクチャの4つの柱は、データ、買収、ビジネス、技術の各アーキテクチャであることをよく耳にします。 それとは少し違った見方をします。 データアーキテクチャは、2つの理由でエンタープライズアーキテクチャ全体を推進する基本的な基盤と考えています。 1つは、それが始まった場所です。 Zachmanフレームワークのようなものでさえ、主にデータアーキテクチャから生まれ、その後、アーキテクチャの他の側面も取り入れるようになりました。 そして2つ目は、プロセスとデータの基本的な結びつきだからです。 そのため、ビジネスアーキテクチャをエンタープライズアーキテクチャの中心的な柱と考えています。 そしてもちろん、それはアプリケーションアーキテクチャと技術アーキテクチャによって補完されます。アプリケーションアーキテクチャと技術アーキテクチャは、私たちが真のエンタープライズイネーブルメントを推進できるようにするために必要不可欠です。 今、統合モデリングプラットフォームであるER Studio Enterprise Team Editionの観点からそれを見ると、このようになります。 そして、これは私たちが行っているモデリングの一部とその背後にある基礎の一部の高レベルのコンテキスト図です。 そして、これは実際に駆動され、これは実際にプロセス図で図式化されます。 そのため、特にデータアーキテクチャの部分と、下のビジネスアーキテクチャを見ると、ロールベースのツールを提供しています。
そして、左下隅にあるビジネスアーキテクトツールを見ると、通常はビジネスアナリストやビジネスアーキテクトが働いています。 そして、彼らは通常、いくつかのビジネスプロセスに焦点を合わせ、それらを追い出し始めています。 しかし、彼らは何にも焦点を合わせています。 そこで、概念的なデータモデリングとそのようなことを始めます。 これらの概念モデリングコンポーネントを活用して、データモデリングツールとデータアーキテクトに持ち込み、そこで論理データモデル、そしてもちろん最終的に物理モデルにさらに精緻化して、物理データベースを生成できます。 また、ビジネスアーキテクチャ分野でも概念モデルがアップグレードされるように、プッシュバックすることができます。 ここで非常に重要なことは、さまざまなタイプのモデリングをサポートすることです。 繰り返しになりますが、BIは非常に重要であり、データレイクやこれらの種類のものであるため、実際にはいくつかのモデリングも行います。その一部として、データ系統モデリングも行います。 したがって、データウェアハウスの物理モデルから次元モデルへのマッピング方法や、データレイクからのデータの取り込みとそれらのマッピング方法の確認という点で、ETLだけでなく、それらすべてを結び付けることができます。 ビッグデータプラットフォームからの他のモデリングプラットフォームからのリバースエンジニアリングと同様に。
また、ETLツールなどもあります。実際に、独自の環境にある可能性のあるETL仕様から直接データ系統図を導き出すことができます。 また、リレーショナルモデリングを超えて拡張する必要があることを知ることも非常に重要です。 Hiveのような特定のプラットフォーム、特にMongoDBがありますが、埋め込みオブジェクトや配列などの概念があるドキュメントストアについて話し始めています。 これらのタイプのモデルも非リレーショナルコンセプトであるため、実際に表記を拡張して、これらのタイプのモデルにも対応できるようにしました。 データアーティファクトに関してデータアーキテクトツールで作成したものは、それが論理エンティティであろうと物理テーブルであろうとその属性であろうと、ビジネス処理モデリングにもプッシュバックできます。 そのため、ビジネスプロセスモデルを高レベルから詳細に作成し、低レベルに移行するときに、実際のデータ要素を実際にリンクできます。 それで、あなたは行動することができます、私たちは実際に起こっていることのCRUDマトリックスを指定することができます。 したがって、プロセスレベルでの作成、読み取り、更新、および削除について説明したデータライフサイクルが得られます。 また、独自のオーバーレイセットを使用して完全なBPMプロセスモデリングを行っているため、ビジネス戦略、ビジネス目標に結び付けることができます。 また、モデル駆動型の観点から、これらのビジネスプロセスを実装しているアプリケーションを結び付けることもできます。
他の非常に重要なことは、データモデルにもあります。 マスターされたデータガバナンス特性またはデータ品質特性と管理。 追跡したい特性に合わせて独自のメタデータを定義および構築できます。つまり、モデルを青写真として使用して、組織全体でメタデータリポジトリなどにそれを導くことができます。 そしてもちろん、何年も前に私たちの多くがこれを行う業界で始めたモデリングの限界の1つは、これらのモデルを作成することです。 私たちは何をしますか？ 私たちはそれらをプリントアウトし、壁に置いて、おそらくチームメンバーが共有できるようにし、そのようなことをしました。 これの真の価値は、組織内で共有およびコラボレーションできることです。 そのため、モデルとワークスペースをチェックインおよびチェックアウトする場所について、リポジトリ駆動型のアプローチを採用しています。 そして、他の技術的な利害関係者、ビジネスユーザー、およびそのタイプのものであろうと、組織である構成員とそれらを共有します。 また、それをTeam Serverと呼ばれるコラボレーションプラットフォームに結び付けます。
そこで、私たちは以前のビジネス用語集と用語とその重要性について話し、ビジネスのためにその語彙を開発しました。 それはすべてTeam Serverで行われ、ユーザー、ビジネスユーザーはこれらの条件で共同作業できます。 たとえば、データアーキテクトで使用でき、データモデルの近くで使用できます。もちろん、これらのビジネス用語集の多くは、データモデルで作成したデータディクショナリに由来することがよくあります。 また、データアーキテクトツールの出発点は、ビジネス用語集です。ビジネス用語集では、それらをさらに洗練させることができます。
それはたくさんでした。 要約すると、私たちが話したいくつかのことは、真の組織の成熟度を試すことです。データの成熟度とプロセスの成熟度で構成されるバランスの取れたアプローチが必要です。 あなたは他なしで一方を達成することはできません。 繰り返しになりますが、基本的には、組織のエンタープライズアーキテクチャとデータガバナンスおよびプロセスガバナンスの両方について、特にデータモデリングとプロセスモデリングの両方を使用し、これらに依存する必要があります。 エンタープライズアーキテクチャは、これらのさまざまなファセットとパースペクティブを見るという点で、実際にそれを結び付けます。 そのためには強固なデータアーキテクチャの基盤が必要であり、そのビジネスコンテキストを提供し、ビジネスプロセスとデータ消費を前進させるためには、統合プロセスモデリングが必要です。 繰り返しますが、これまで以上に重要です。 私は言うことができます、古いものは再び新しいです。 そのため、データモデリング、プロセスモデリング、系統、メタデータ、および用語集は、これを実現するための基本であり、ER / Studio Enterprise Team Editionは、これらすべてを統合するコラボレーションプラットフォームです。
そして、それで質問に移ることができます。
エリック・カバナ：わかった。
ロン・フイゼンガ：エリック、あなたに行きます。
Eric Kavanagh：ロン、これらのさまざまなプロセスとフレームワークの文書化に費やしたすべての努力に対して、私はあなたに私の帽子を傾けなければなりません。 それはあなたがそこに持っている多くの資料です。 私が抱える大きな疑問は、あなたが非常に多くの異なることに触れるので、誰が組織内でこのようなものを監督すべきかということだと思います。 プロセスを把握すると、最高執行責任者または運用担当者になります。 データライフサイクルは、おそらくそれが最高データ責任者になると思います。 あなたは非常に多くの異なる部品と非常に多くの異なるコンポーネントにビジネスに触れています。 どのようにして適切な人または人のグループを見つけるのですか？それは運営委員会ですか？ それは何ですか？ 組織内で誰がこれを行うべきかについて教えてください。
Ron Huizenga：ご存知のように、それは興味深い質問です。 実際には、そこでさまざまなアプローチのメリットを議論するのに1日費やすことができます。 しかし、私が間違いなく見たのは、製品管理の役割に入る前に相談していたとき、組織を見たとき、それが所有権を取得し、人々に所有権を取得させることの問題の一部でした。 そして、データモデリングやビジネスプロセスモデリングなどの分野、または初期の頃はデータフローダイアグラムやこれらの種類の分野を見ると、その種はITから生まれました。 しかし、私たちが前進してきた今、私たちはこれが本当にビジネス主導でなければならないことをますます認識していると思います。 ですから、あなたは本当にこれの所有権をビジネスに持ちたいのです。
ここでIT担当者を怒らせますが、チーフデータオフィサーの役割の進化を目の当たりにしたのは、ほとんどの組織でCIOの役割が失敗しているからです。 そしてそれは、多くのCIOがデータとプロセスに焦点を当てるのではなく、技術的に焦点を合わせているためです。 だから私はあなたが本当にそれを持っている必要があると思う、あなたはおそらく大規模な組織で運営委員会のいくつかのタイプが必要になるだろう。 しかし、これは本当にビジネスが所有する必要があります。 ビジネス、プロセスモデリング、データモデリングはすべてビジネスに属している必要があると主張します。これにより、データの管理者であるITが、そのプロセスを通じてそれらのプロセスを実装できるようになります。 「作成している、あなたはそれが実際にビジネスによって所有されている場合それが起こっていることを確認するためにそのハンマーを持っています
エリック・カバナ：ええ、私はそれに同意すると思います。 しかし、ジェン、あなたはそれについてどう思いますか？
ジェン・アンダーウッド：それは本当に面白いです。 それは、人々を気遣わせ、インタラクティブにさせることがおそらく重要なことの1つだと言ったときにほのめかしたことです。 ある時点で、私はこれに非常によく似たセルフサービスBIガバナンスについてのホワイトペーパーを書きました。 それを手に入れること、それがビジネス価値の側面である人々をやる気にさせる方法を見つけて、彼らにそれを気にかけるようにすることです。 そして、それがデータのカタログであろうと、それがどんな角度であろうと、彼らが見たり、見つけたりするとき。 たぶんそれは、輸送コストを削減し、誰かが組織に責任を負わせる何かを置くことです。それはあなたがそれを気にする方法です。 そして、はい、ビジネスは絶対に。 ビジネスの主題の専門家は、それを作ったり壊したりします。
エリック・カバナ：それは難しい。 組織全体からのこの利害関係者のコンソーシアムを常に持ちたいと思います。 もちろん、分析の麻痺は望ましくありません。 官僚主義のために官僚主義を望まない。 組織がアクションプランを作成し、これらのことを文書化することが望まれます。 ご存知のとおり、ビジネスプロセスモデリングの話を始めたとき、25年前は暑かったのですが、実際のビジネスからはほとんど切り離されていたと思います。 少なくとも一部の業界では、物事を実行する実際のソフトウェアからそのプロセスの多くを引き出すことができると思います。 しかし、私は、これらの2つの世界のバランスをとる方法を見つける必要があると思います、そうですね、ロン？ 最新かつ最新で、実際に起きていることを反映したプロセスモデルが必要です。 ですから、それがどこか別の棚に置かれているだけの別のエクササイズにしたくないのです。 しかし、それはちょっと難しいですよね？ すべての運用システムがそのような実行可能コードに対応しているわけではないためです。 しかし、あなたはどう思いますか？
Ron Huizenga：もちろんです 。 興味深いのは、私が見ていることの1つは、人々が、すぐに満足できる社会になったときです。 「ああ、私たちは外出していくつかのツールを購入し、私たちのためにこの作品を作ります」と考えます。まるで、プロセスの成熟度を購入するつもりはないようです。 データの成熟度を購入するつもりはありません。 それは大変な仕事だ。 あなたは袖をまくり上げなければならず、それを実現しなければなりません。 そして、それを実現するメカニズムはモデリングです。 複雑すぎて、作業中の現在の状態だけでなく、それらのさまざまなビジネスプロセスを改善する方法を設計できるようになります。 これらの変更がどのような影響を与えるかを理解できるようにするには、そのビジュアルフレームワークが必要です。
Eric Kavanagh：それは本当に-私はただツイートしています。 私は今これをツイートしています-「プロセスの成熟度を購入するつもりはありません。データの成熟度を購入するつもりはありません。」これらの両方に完全に同意することができます。 そしてジェン、私はあなたの考えのためにあなたを連れてきます。 そして、その上に別の質問を投げます。 出席者の一人が尋ねています：プロセス駆動型の企業またはプロセスの成熟度とは何を意味するのでしょうか？ ジェン、あなたはそれについて話すことができますか？
ジェン・アンダーウッド：実際、前の質問に少し上手く話すことができます。 考えてみると、本当のことを言うと、それはツールを購入する最初の1つです。 それは本当に真実だからです。 しかし、私が言うことは、かなり良いです。 だから私は多くのソリューションをレビューし、さまざまなスペースを見つけてテストします。 良くなっているのは、データを発見し、タグ付けし、少なくとも大規模なランニングスタートを行い、これを行うことです。痛みが少ないと言えば、それはほとんど楽しいことです。 したがって、データカタログまたはMDMプロジェクトが楽しいと想像してください。 それは、あなたがこのデータを使用している組織の人々であり、それが報告であろうと他の種類のものであろうと、ライン上の誰かが言っていたと思います。 ええ、さらに1レベル上げます。 これらのことを考えており、誤って配送された貨物を30％削減し、これが節約された金額です。 データを適切に管理しているだけです。 それはそのような種類のものであり、あなたはそれにお金をかけ、それを楽しくします。 または、あなたがそれを興味深く、彼らがしていることに関連するようにします。 それは一種の魔法であり、人々が組織でこれを行おうとするこれらのエンゲージメントの多くに欠けていると思います。
エリック・カバナ：ええ、それは良い点です。 ロン、先ほどのビジュアルフレームワークの重要性についてのコメントに戻りますが、多くの場合、人々が何かを見ることができない場合、それを頭で包むのは本当に難しいからです。確かに、相互依存性と制御ポイントなどの複雑なプロセスについて話し始めるときは、ある時点でどこかにマップする必要があります。理想的には、カタログ化するための機能が組み込まれたソフトウェアでマッピングする必要があります。たとえば、このポイントからそのポイントまでの異なるラインを使用して発生した変換。 または、このコントロールポイントで利用可能なもの。 そして、私はリスク管理の私の歴史を参照しています。コントロールポイントとは、プロセスの任意のポイント、オプション、または実際に何かを実際に変更できる個人またはソフトウェアアプリケーションです。 それが彼らがコントロールポイントと呼ぶものです。 そして、私にとって、あなたがその視覚的なフレームワークを手に入れることは本当に貴重です。 それはあなたが見ることができて、ちょっと歩き回ることができるからです。 そのようなものを管理し、それを本当に理解し、それを最適化するには、人間の脳の時間がかかりますか？
Ron Huizenga：もちろんです 。 そして、私はそれを遠近法に入れていると思う別の類推を使用します：私は少し航空ナッツですので、これを並行して考えようとしているなら、747を構築することを考えてください–またはAirbus380。したがって、私は他のベンダーよりもベンダーを選びません。設計図や3-D CAD図面ではなく、テキストのみで構成されるドキュメントに基づいてそれを行うのがどれほど難しいかを考えます。それは実際に一緒に組み立てられます。
エリック・カバナ：ええ、それは大雑把でしょう。 そしてジェンも話さなければなりません。
Ron Huizenga：ビジネスは同じですよね？
エリック・カバナ：ええ、そうではありません。 ジェンは、あなたが勉強したいあなたのホットなエリアの1つである視覚化と話す必要があります。 それを完全に理解するためには、何かを視覚化できる必要があります。
ジェンアンダーウッド：多くの人間がそうしています。 そして、視覚化だけでも、何と言っているのか、何千もの単語などが話します。 彼らはそれを見るとき、彼らはそれを信じることができます。 そして彼らはそれを得る。
エリック・カバナ：同意します。 ロン、あなたがこれをすべてまとめたような方法が大好きです。 組織内にチャンピオンが必要であり、誰がそこにいて、さまざまなグループへの連絡役を務める必要があると思います。 データスチュワードはよく話します。これは非常に重要な役割であり、データの価値を高く評価してきたこの3、4年でさらに注目されている役割だと思いますガバナンスですね そのデータスチュワードは、ビジネスと話をするだけでなく、システムを理解し、データのライフサイクル、全体像を理解できる人です。 そして、その人はCEOの支配下にある可能性があり、おそらくそうであると思いますか？
Ron Huizenga：ええ、多機能のチームが必要になりますよね？ そのため、それを行うチームを構成する人々、または技術的な側面を表すさまざまな分野、つまり、さまざまなビジネス分野の人々が必要になります。 また、組織のタイプによっては、プロジェクト管理オフィスがあり、多くのイニシアチブがPMOによって推進されている場合は、PMOがあることを確認する必要があります。参加するだけでなく、すべての人が調和を保ち、物事に取り組んでいる方法を同期させることができます。
エリック・カバナフ：そうですね、最後にもう1つ、この最後のスライド、ガバナンスフレームワークを紹介します。 そのスライドからデータが欠落していませんか？ それは、スライドにデータが含まれているのか、それともスライドからデータが欠落しているというコメントについてどう思われているのですか？
Jen Underwood：いいえ、これは単なる一般的なガバナンスフレームワークです。 基本的に、これはセルフサービスBIスペースからのものであるため、データの多くはこれに含まれています。 これは私の視点と視点から来たものであり、これをまとめる際にデータ側に焦点を合わせたものではありませんでした。 しかし、データは確かにあります。これらすべての要素について考えると、データがあります。 データの基盤であるかどうか、プロセス全体およびフレームワーク全体でデータを使用する説明責任。
エリック・カバナ：ええ、それは完全に理にかなっています。 ここで最後の質問を1つだけお送りします。Ronです。 最近使用している情報の量とデータの量、組織がどれだけ離れているかを考えると、昨今のチャネルパートナー間のエコシステムの重要性と、これらのパートナーシップ間で情報を共有する方法これに対するブロックチェーンの簡単なクイックリファレンス-複雑になりすぎないようにします。 結論としては、ビジネスの観点と日常生活の両方から、データ駆動型の接続された世界にいるということです。 そして私にとって、それは組織があなたがここで提案していること、つまり成熟度、彼らがどこにいるのか、そしてどの程度彼らがカーブに沿ってどの程度進んでいるのかを真剣に見るようにするための利害関係をさらに高めることになりますそれについて本当に自分自身に正直になりますよね？ Because if you don't know better, you can't do better, and if you don't reflect on things, you're not going to know better, right?
Ron Huizenga: Exactly. And I guess a phrase that I would use is, you're probably not as good as you think you are. That may sound kind of harsh, but people can be quite optimistic about this, but if you take a really hard look at it and a really good, critical self-assessment, I think any organization will find, you know, significant gaps that they need to address.
Eric Kavanagh: I have to agree. And one of our colleagues out there commented on the importance of metadata, the data about data. There's no doubt about that. Metadata is the glue that that holds all these systems together and we've still never even really fully cracked that code and for good reason, frankly, because metadata changes. It's different from system to system. You know, the more you try to normalize your data, the less accurate I think it becomes.
So we're kind of in this weird world right now and maybe I guess I'll extend for one more question to you, Jen, because you mentioned data catalogs a couple times. I really love this new movement of data catalog technology that automatically scans your information systems, ascertains metadata column names, so on and so forth, and helps you to incrementally build up the strategic view of your data and your metadata in your systems. Because to me, to manually do that stuff, it's just, there's just too much. And you're never going to get to the top of that hill before the avalanche comes down on you and, you know, you either have normalized to the point of play-dough gray or you haven't normalized enough to where you really don't know what's going on. To me, using the machines, the machine learning that we keep talking about, that's going to be the key in the future to help us at least get a rope around enough of the data to have a good understanding of what's out there, right Jen?
Jen Underwood: Yeah, I do. I love these technologies. They're very, very cool. And then you think about it, it gives you that massive running start. And then you can crowdsource. You have your data stewards, you know, pulling ahead, whether they're adding their own documentation or this is the perspective out there, these are the changes. You know, saying these are the certified data sources to use for reporting. People can search and find the right data. It's really, really quite nice. And also helps to – when I think about business and how cryptic enterprise data management was when I was when I was doing DBA stuff – we used extended properties and SQL Server and scan with tools like IDERA's, right? To try to create a data catalog. But in DBA or data architects' version of, you know, whatever that value was or that column or field was, it certainly probably didn't match what the business was. So now having the business be able to really easily, you know, go in and find and manage and have everything be goal-based, it's really, I wish we would've had this a long time ago, quite frankly. So it's getting a lot better.
エリック・カバナ：それは面白いです。 We've got another final comment from an audience member, saying perhaps blockchain will be the most valuable to put a stamp of authentication to metadata. That's a good point and, you know, blockchain really is amazing technology. I kind of view it as a sort of cohesive foundation for connecting a lot of the dots between systems and applications and so forth. And, you know, we're in the early stages of blockchain development, but we now see that it is spun off, of course, from this point originally where it came to the fore, and now you've got IBM working very hard on blockchain technologies. SAP has bought into all that. And really it's, it presents an opportunity for a deeper foundation and framework to connect all these systems and all these dots.
So, folks, have burned well over an hour. Thanks for staying along with us today, but we always like to answer your questions and get to all the commentary. We do archive all these webcasts for later viewing, so hop online to insideanalysis.com, where you can find the link to that. It should be up within a few hours, typically after the event. And we'll catch up to you next time. We got a couple more events coming up next week – lots of stuff going on. But that will bid you farewell, folks. Thanks for your time. 気を付けて。 さようなら。
