Співробітники компанії «Техопедія», 8 листопада 2017 року
Винос: Ведучий Ерік Кавана обговорює зрілість даних та організаційну зрілість з Джен Андервуд з Impact Analytix та Рона Хуйзенга з IDERA.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, панове. Привіт і ще раз ласкаво просимо. Середа о 4 годині східної, а це означає, що пора гарячих технологій. Так, справді. Мене звуть Ерік Кавана; Я буду вашим господарем нашого шоу сьогодні, яке дійсно визначено, призначене для визначення певних технологій у певних станах перебування у світі управління даними. І наша сьогоднішня тема - «Досягнення зрілості даних: Закон про організаційне збалансування». Отож, місце про ваше справді є, і мене зачепило на Twitter, @eric_kavanagh. Я завжди ретвітую, якщо ви згадуєте про мене, і я спробую також відслідкувати. Це хороше місце, щоб поїхати, щоб отримати інформацію про те, що відбувається у світі. Я люблю цей формат. Короткі символи, 140 символів - або більше в ці дні. Тож не соромтеся надіслати мені твіт, і я пітиму назад.
Цей рік гарячий, звичайно. Ми говоримо все про зрілість даних сьогодні, і ось лінійка, з вашою справді на самому верху. У нас сьогодні є новий аналітик; Я дуже рада, що Джен Андервуд із Impact Analytix. Вона є досить знавцем бізнес-аналітики та аналітики та візуалізації даних та всіх цих чудових тем. І звичайно зрілість даних. І наш добрий приятель Рон Хуйзенга дзвонить з IDERA. Тож спочатку ми почуємо від Джен, а потім від Рона. І тоді ми проведемо хороший круглий стіл.
Коли я натискаю цей наступний слайд сюди, я просто скажу пару швидких слів. Зрілість управління даними вже певний час є предметом. Очевидно, що в історії вам доведеться дійти до певного моменту, перш ніж починати думати про зрілість, і багато життєвих циклів зрілості було розроблено - або цикли - намагаючись зрозуміти, де ви знаходитесь в кривій. Ви на ранній стадії? Ти підліток? Ви зрілі? Etcetera.
І я думаю, що багато організацій або в підлітковому віці, або в кінці підлітків або на початку двадцятих років з точки зору зрілості. І це не говорить про те, що нічого не відштовхує. Просто ми все ще в перші дні вміємо управляти даними як стратегічний актив. І все швидко змінювалося. Особливо в останні п'ять-сім років, коли ми переходили від невеликих даних до великих даних, і вони намагаються узгодити ці досить розрізнені світи та нові технології зі старими технологіями. Тож спадщина там, вона є скрізь.
Один з жартів, які я чув багато років тому, - це те, що спадщина - це система, яка виробляється. Щойно система переходить у виробництво, технічно це є спадщиною. І певним чином це правда. Але суть полягає в тому, що у нас є всі ці системи, які існують довгий час, і ми повинні знайти спосіб зрозуміти, де ми перебуваємо у власній кривій зрілості, щоб мати можливість максимально оптимізувати та оптимізувати значення даних як актив . І звичайно, є деякі питання дотримання вимог, деякі норми, про які ми повинні турбуватися, залежно від того, в якій галузі ми перебуваємо. І тоді, звичайно, ми також повинні турбуватися про злому. Раніше ми говорили про управління даними та про те, як це насправді є частиною безпеки та просто розуміння ролей та обов'язків використання даних та переконання, що ми отримаємо найкраще значення від них.
І тому з цим я збираюся вручити ключі Джен Андервуд, і вона може розказати нам свою перспективу щодо зрілості даних. Джен, забирай це.
Джен Андервуд: Дякую, Еріку, і дякую, що запросили мене. Тому сьогодні я розкрию кілька різних тем, а потім я познайомлю Рона з IDERA, і він збирається глибше заглибитися в деякі інші сфери цієї конкретної теми. Я скажу, що це найважливіша роль у цифровій ері чи цифровій трансформації, яку ми зараз перебуваємо, і, як сказав Ерік, це епоха, що розвивається. Деякі цікаві статистичні дані від Ради EDM, був огляд звітності про галузь управління даними. Це майже два роки, але це все ще досить актуально і розкриє деякі, знаєте, фактоїди як такі, що є підлітком у цьому просторі. Я трохи розкажу про зрілість даних та стовпи управління, як такі.
Щодо цієї теми цифрової епохи чи цифрової трансформації, яку ви чуєте всюди, це справді відбувається саме зараз. Один з цікавих фактів, який я збирав, коли я слідкував за галуззю щодня, - це точка, яку зробив Gartner у першій десятці стратегічних тенденцій технологій. І вони сказали до 2020 року - тому ми лише кілька років від цього - інформація буде використана для винахідництва, оцифрування та автоматизації або усунення 80 відсотків процесів, які ми мали на десятиліття раніше.
І я бачив це деякий час, я думаю, що тут ви бачите різні типи людей, які говорять, знаєте, "Дані - це нова олія", і такі речі. Мені подобається говорити, що зараз дані є цифровим золотом. І якщо ви думаєте про програмні програми та залучення до програмного забезпечення, я в минулому був світовим менеджером продуктів для Microsoft, і навіть про зміни в моїй кар'єрі з, знаєте, ми дійсно зосередилися б на програмному забезпеченні, тепер ми орієнтовані на користувачів і збирання даних та роздуми про монетизацію даних.
Ми вступаємо в цю епоху, коли дані є цифровим золотом, і ви починаєте бачити, що з появою того, що називається головним службовцем даних, і це, у них, ви знаєте, дві основні місії - і, звичайно, кілька інших - переконатися, що дані є безпечними та безпечними, а також знайти способи максимального значення значень даних внутрішньо - і навіть зовні - як цей цифровий актив. Тож такі речі, які, можливо, не були або не здавались важливими для вашої організації в минулому, дані, нарешті, отримують місце за столом на рівні С разом із CDO, і вони будуть сприйматися набагато серйозніше вперед.
Якщо ви думаєте про управління даними та зрілість, у мене на цьому конкретному слайді є дві різні теми, перша - це, знаєте, саме управління даними. Йдеться більше про бізнес-функції, які розробляють та створюють потоки даних та даних, деякі політики та практики, що існують. І тоді, коли ви думаєте про зрілість управління даними, саме ця здатність організації точно визначати, легко інтегрувати, знаєте, використовувати ті дані, які вони знову мають, для внутрішніх чи зовнішніх цілей, таких як монетизація даних. І одна з найважливіших тем - і це було смішно, на початку моєї кар'єри, і я фактично використовував деякі інструменти та проекти архітектури IDERA - це була ціла концепція метаданих, і ми продовжували думати про метадані, а потім про неї не говорили про довго, довго. Я нарешті бачу метадані знову прохолодними. Дійсно дуже важливо взаємодіяти з різними групами, розуміючи, де ваші дані, які дані. Особливо в таких речах, як озеро даних. Це нарешті, нарешті, стає цікавим.
Тепер я пообіцяв, що маю тут декілька статистичних даних із звіту про галузеві показники. Цей був з 2015 року для Ради EDM. Йдеться про модернізацію якості даних та управління, і в цьому конкретному є кілька цікавих фактоїдів. Тож тут більше 33 відсотків організацій мають активну, формальну програму управління даними на якомусь рівні організації - лише 33. Тож це дуже цікаво саме по собі. З тих 50 відсотків, які насправді формалізували, ми хочемо керувати даними, ми розуміємо, що це дійсно важливий актив у нашій організації, як і люди, які мають людські ресурси. Лише 50 відсотків з них мали програми, старші одного року. Отож, це знову-таки нова сфера, що насправді цікаво тим, що ми стаємо все більш важливими, особливо з такими речами, як деякі норми галузі.
Тож багато разів - і це було цікаво, коли я працював у технічних продажах та ролях впродовж моєї кар’єри - це насправді не було: «О, ми можемо заощадити гроші, які мотивують організацію» - це зазвичай страх. Це більше: "О, боже, ми повинні переконатися, що ми охоплені. Ми не хочемо втрачати роботу. "І, звичайно, такі речі, як злом і ризик передачі даних та витік даних, є справді цікавими орієнтирними дослідженнями щодо цього. Verizon робить один щороку, і це, мабуть, одне з моїх улюблених, щоб переглянути. Те, що ви майже завжди бачите, - це ненавмисне, це не обов'язково, знаєте, навмисне неправильне використання даних або неправильне управління даними, що призводить до витоку. І часто - у них немає такої статистики для конкретного сеансу - але це захоплююче, що ці випадкові витоки неправильного управління дозволами та ін. Ви знаєте, щоб трохи полегшити справи, ці витоки йдуть в кредит. І, як правило, людям, які є сторонніми або зовнішніми для вашої організації, і це не те, чого ви хочете.
Отже, це такі речі, коли ви думаєте про те, щоб мати програму безпеки та управління даними. Ви знаєте, не лише погані рішення та заощадження грошей, а й переконання, що, знаєте, ви безпечні, дотримуєтесь законодавства про конфіденційність та безпеку. Ви можете монетизувати дані в цю цифрову епоху, і, звичайно, знаєте, ви хочете робити ефективні дії і використовувати повторно дані, мати блаженну копію і є - я ненавиджу, коли люди кажуть, і я в аналітиці, і я Я давно працював в аналітиці, одна версія правди. Звичайно, зазвичай, існує кілька версій істини, просто з різних точок зору. Але по суті, ви хочете, щоб дані були надійними, на яких ви ґрунтуєте рішення.
Один з найбільших драйверів, який я бачу - і це добре, добре, що знову стає круто - це вся концепція GDPR Європейського Союзу. І дозвольте мені трохи поговорити про це. Тож якщо ви не знаєте GDPR, ви будете чути багато про це цього року. Це нове законодавство, яке діє в травні. Він буде застосований у травні 2018 року, і за нього є великі штрафи за неправильне управління інформацією. Ви, можливо, чули про це, про що говорили в інших формах - можливо, не використовуючи термін GDPR - ви, можливо, чули чи бачили це написане як право бути забутим, це означає, що ви можете зв’язатися і попросити продавців видалити ваші дані. Знову ж таки, минулі архітектори даних не видаляли б дані. Ми змінили б його, зробимо його неактивним у сценаріях зберігання даних. Ми ніколи не видаляли наші дані. У нас не було процесів для цього. Отже, ви знаєте, це стосується всіх аспектів вашої організації та різних способів та процесів, які ви, можливо, ніколи не розглядали під час створення програми чи сховища даних. Тож якщо ви бачите, що про ГДП слід думати, досить скоро вам знадобиться юридична основа для виправдання збору та обробки персональних даних.
Тож це здебільшого на особистому рівні, тому згоду потрібно вільно давати: конкретну, поінформовану, однозначну. І це вплине на багато областей штучного інтелекту та науки про дані - саме цією сферою я займаюсь в ці дні, це наслідки науки про дані та просто впевненість у тому, що є якась прозорість у самих моделях - а також у багатьох інших сферах вашого самообслуговування BI, ваш сховище даних, ваше основне управління даними, навіть ваш клієнт 360 проектів, для персоналізації та навіть ваш бізнес-додатків. Тож це щось, що торкнеться кожної частини вашого органу. І на відміну від законів про конфіденційність в інших юрисдикціях, GDPR застосовуватиметься до будь-якої організації, розташованої всередині або поза межами Європейського Союзу. І штрафи за дотримання, знову ж таки, значні. Це ваша організація може бути оштрафована до чотирьох відсотків від вашої валової валової продукції на рік - я вважаю, що це називається оборотом - доходом як таковим.
Сподіваюся, я маю вашу увагу, і це те, про що ви повинні звертати увагу. Якщо ваша компанія вже дотримується деяких із цих практик та галузевих стандартів з PCI, можливо, це ISO - я не впевнений, чи збираюся я сказати це правильно - 27001. Якщо ви вже робите деякі з них, це не повинно ' не бути занадто непосильним, але це, безумовно, слід знати. Тому, готуючись до цього, є декілька напрямків, особливо в управлінні даними, і однією з перших речей є створення каталогу та класифікація ваших даних - знати, де розміщуються ваші дані. І у світі, гібридному світі, де дані живуть скрізь: Це в хмарі; це в цих додатках; це в силі збуту; саме в якійсь іншій випадковій програмі маркетинг також використовується, знаєте, ваші клієнтські системи чи ваші інвентарні системи - усі ці типи місць. Знайте, де ваші дані, і що найпростіше зробити - і це було дійсно цікавою сферою управління даними, чи це поняття цих каталогів даних, які мають інтелект, навіть класифікація машинного навчання є деякою інформацією.
І знову метадані - я згадав, що метадані знову стають крутими, тому по-справжньому замислюйтесь над метаданими, а не замислюйтесь над цією важливою темою, коли ви починаєте розробляти озера даних та подібні речі, і звичайно керуючи ними та контролюючи їх. Тож моніторинг набуде набагато важливішого значення, коли вам доведеться повернутися назад, і хтось із GDPR, наприклад, може попросити вас довести, куди поділися ці дані, хто їх має, хто мав доступ до них та ін. Тому що вам насправді доведеться показувати владі ті речі.
Щоб допомогти вам у зрілості управління даними, насправді існує декілька шкіл думок, і я вважаю, що я не на 100 відсотків впевнений - я думаю, що в колоді Рона я побачив, що він охоплює декілька таких, так що я Я сьогодні поговорю про це від CMMI. І цей, цей доступний для людей; Він охоплює шість різних категорій управління даними, 25 областей обробки, 414 тверджень про практику та 596 різних робочих продуктів. Отже, коли ви думаєте навіть про всі речі, якими ви займаєтесь, як, наприклад, керуєте та архітуєте дані, 596 функціональних робочих продуктів, ви не усвідомлювали, скільки зробили, правда? Або те, що ти насправді не робиш. Коли я дивлюсь на таке число, це одна з речей, яка насправді залишається в моїй свідомості. Тож у цьому, і що мені подобається у цьому конкретному, є його архітектура та технологія, нейтральна. Отже, це означає, що якщо у вас є, і більшість великих організацій, з якими я консультувався або працював і впроваджувався впродовж багатьох років, знаєте, у них є всілякі різні технології. Отже, ви хочете перекласти, що означає DMM, на платформи та технології, які ви використовуєте у вашому конкретному середовищі. Це також незалежно від галузі, тому воно не обов'язково стосується, наприклад, охорони здоров'я. Охорона здоров'я має певне - чи це БАД чи різні типи класифікацій, вам потрібно перекласти або переглянути різні типи речей, коли ви збираєте свою програму чи плануєте покращити рівень зрілості управління даними у вашій організації.
Що це, якщо це не деякі з цих речей? По суті, це визначення того, що робити, але не конкретно вам сказати, як це зробити. Більшу частину своєї кар’єри, будучи особистості типу А, мені сподобалось, коли люди давали мені мету, і я міг зрозуміти, як дійти до цієї мети, і не було, скажімо, мікроменеджменту свого часу, як доїхати. Ось як зрілість управління даними, і ці процеси з CMMI, це дає вам цілі і дає вам можливість вимірювати себе в деяких з цих різних областей. І вони дадуть вам рівень. Існують різні способи, як можна оцінювати і вимірювати себе, будь то рівень першого аж до п’ятого рівня, тобто ви його оптимізували і у вас є дійсно сильна програма.
І щоб просто дати вам відчуття того, що це насправді означає, у мене тут невеликий огляд того, що це може означати. Отже, тут, коли ви думаєте про те, щоб мати життєвий цикл процесора зрілості управління даними, у нього є підтримка процесів, всього - від вимог, управління ризиками, вам доведеться підтримувати там процеси, до управління даними, і я добрий обстеження цього, але по суті, управління даними - це ціла програма сама по собі. Маючи бізнес-словник, ми назавжди говорили про бізнес-словники та архітектори даних - це має бути щось у вашій організації. Деякі з цих типів технологій каталогів там виготовляють, розробляючи бізнес-словник із краудсорсингом інформації та взяттям та іншим, і, знаєте, розміщенням посилань у документах на різні точки зору тих самих даних, поля даних або версія даних, оскільки вони змінюються протягом життєвого циклу значення.
Це типи речей, які стали набагато кращими з мого початку кар’єри. Раніше нам доводилося розробляти системи, вирощені в домашніх умовах, щоб робити ці речі. Таким чином, ми дивимось на всю і велику картину, це стратегія, а потім всі різні частини тут, від управління до якості в управлінні. І одне, що стосується якості даних, це цікаво, оскільки галузь стає все більш автоматизованою, і ми знову маємо ці цифрові процеси з автоматизованим прийняттям рішень. Я багато працюю в просторі науки, де ми використовуємо деякі з цих інструментів для автоматизації рішень та оновлення прогнозних моделей на ходу. Дуже багато цих інструментів і алгоритмів вимагають і припускають, що дані хороші. Для отримання правильного автоматизованого рішення потрібні дані, щоб вони були дійсними. Отже, замислюючись про те, ви знаєте, можливо, якість даних, як правило, одна з тих речей, які люди відсувають і не сприймають це дуже серйозно. Але як тільки ви почнете автоматизувати прийняття рішень в моделях прогнозного моделювання та машинного навчання, якість даних стає дійсно важливою.
Кілька способів оцінити свій прогрес тут - і я дозволю Рону поговорити з цим, у нього теж прекрасний слайд про це на своєму сеансі - я просто збираюся дати тобі швидкий пік підкрадання, знаєте, ці різні рівні в цьому. По суті це самооцінка, правда? Таким чином, ви подивитесь на управління вашими даними та те, що, на вашу думку, взагалі маєте щось на місці. І не соромтеся, якщо цього не зробите. Як я вже говорив, лише 33 відсотки організацій насправді навіть почали робити такі речі. Незважаючи на те, що ви знаєте, що ці програми були, як мінімум, - я працював у цій галузі понад 20 років, і, звичайно, роблю такі речі років тому, ми, можливо, не просто так називали це. У CMMI вони мають вправу, яку ви можете самостійно оцінити, і ви зможете пройти певний вид і створити свій власний - у цьому випадку такий тип радіолокаційної діаграми - оцінив усі ці різні кути чи речі. І кожна організація, як я робила різні, ви знаєте, коли я раджу консультації та реалізацію цих проектів, ви знаєте, кожна організація унікальна. Вони будуть сферами, які будуть для них справді, дуже важливими. Можливо, ви знаєте, це управління процесами, або це управління якістю, або це ризики - залежить, що це таке, але ви захочете подивитися та створити орієнтир чи базовий рівень, а потім також подумати, що визначає його успіх.
З цього приводу, коли ви замислюєтесь про те, щоб виміряти та керувати такими речами, вам потрібно буде спочатку заручитися деяким виконавчим спонсорством для такої програми. Це те, що буде нефункціональним у всій організації, тому навіть якщо Сьюзі Q та Джон Сміт, вони вирішують: "Так, давайте це зробимо. Нам потрібно це зробити", вони не можуть зробити це в силосі в їх організації, або навіть якщо це ІТ. Вам справді потрібно мати цей закуп від бізнесу та експертів, що займаються даними. Їм потрібно мати певний час. Вони не хочуть, щоб це було лише зайвим завданням. Якщо ви коли-небудь працювали над цим - я думаю, я раніше виконував кілька основних завдань щодо управління даними, проектами та якістю даних - і зазвичай, ви знаєте, ви переходите до бізнесу, і вони: "О, управління даними". Це не так щось вони схвильовані. І вони начебто: "О, ні. Нам потрібно встигнути для цього ", і вони. Тож вам захочеться мати певний час. Вам потрібно буде це благословення зверху. Ви хочете, щоб він був крос-функціональним.
Знову ж таки, це щось, що дійсно торкається багатьох областей організації. І з GDPR, це має зробити це трохи простіше, оскільки, знову ж таки, закони GDPR і де ці персональні дані використовуються для ваших клієнтів і використовуються у всій вашій організації, це має бути трохи легше, якщо ви застосовуєте їх, якщо у вас є дотримуватися GDPR. Отримати тут язик. Це вам повинно бути простіше зробити. Ви захочете покласти деяку відповідальність, а потім подивіться, знаєте, ви збираєтеся їх налаштувати. Таким чином, ви завжди дивитесь на такі типи керівних принципів, які ці організації надають, і зазвичай вони є такими: вони є рекомендаціями для вас, і ви збираєтесь впровадити свою культуру у своїй організації.
Робота в управлінні була дійсно важливою, одна з речей, що деякі продукти, які я розробив, коли я працював у всьому світі по управлінню продуктами в Microsoft, - це самообслуговування BI і дозволяє бізнес-користувачеві та користувачеві, що не має технічних даних, грати з даними та створювати власні звіти, і ІТ багато разів відштовхується. Тож я витратив багато часу на це управління та переконався, що продукти матимуть правильні функції та аудит та ведення журналів, і, знаєте, це робиться так, щоб вони самі не збивали базу даних. Але є рамки, які, знаєте, працювали протягом багатьох років над цією темою цих типів речей, що реально схоже на управління даними. Ви хочете мати таку основу, яка була створена з виконавчим спонсорством для цього, і ви хочете, щоб ця прихильність між бізнесом та ІТ.
Отже, ми знову говорили про розподіл бюджету / часу та розробку нових процесів. Це станеться зміною на культурному рівні, коли ви робите деякі з цих речей, знаєте, починаєте переглядати дані. Але ви знаєте, це дуже важливо з стратегічної точки зору. І, щоб дати вам відчуття, ось приклад, і я очистив це від одного зі своїх старих проектів років тому про такі речі. І знову ж таки, це, мабуть, більше з точки зору загального управління, але, безумовно, може бути використане для таких типів проектів із управлінням та розвитком ваших процесів управління даними та управління ними. У вас є експерт з питань ділових питань, у нас тут є керівники даних, фахівці з інформаційних питань, знаєте, для різних напрямків бізнесу. Багато компаній, які мають більше розмірів, матимуть вашу корпоративну дошку стандартів та ваші підприємства архітектори та архітектори даних та модельєри. Тож будуть різні фахівці з предметів різних рівнів. І знову: багато цього - я ненавиджу, щоб це було прикладом - вони будуть підлаштовані під вашу організацію та вашу культуру.
Одна з речей, коли ви працюєте з цими проектами, знову ж таки, це багато разів, мабуть, не самий захоплюючий проект в організаціях, не такий наглядний, як хочуть люди. Це смішно, це одна з тих речей, яка приходить в консалтингову фірму або навіть у вашій ІТ-групі або у вашій БІ-центрі передового досвіду або входить ваш аналітичний центр досконалості, і ми будемо працювати над даними якості та зрілості управління даними, вони можуть не бути надзвичайно раді цього зробити. Але ви повинні знайти способи мотивувати їх і включити їх у свої виміри. Отже, коли ви думаєте про те, що це буде, одна справа зробити цю вправу один раз, і ви залучите людей на борт. І ви дізнаєтесь, що їм сподобався каталог даних або вони люблять деякі з цих речей, тому що це полегшує їхнє життя, і вони можуть знайти, що дані означають або зрозуміти, і вони можуть додати до них свою перспективу. І річ, каталоги даних - це, мабуть, один із найбільших проектів, який допомагає людям по-справжньому закохатись у це.
Тож наступне - тримати їх займатися. Як ти когось займаєш, що, можливо, їм це не байдуже? Це визначити деякі показники і включити їх, їх вимірювання в, а потім забезпечити деяке навчання, коли є порушення і деяке усвідомлення того, що: "Ей, ми робили дійсно добре деякий час, а потім не так добре". - це типи речей, над якими слід думати, щоб продовжувати це. І тоді, коли ви думаєте про підрахунок балів, і це приклад CMMI, це те, як вони його оцінюють. Знову ви матимете власні інформаційні панелі, власні KPI, знаєте, різні способи вимірювання людей в організації. Але у вас будуть різні способи зарахувати та виміряти власний успіх. Мій ключовий момент, що вам слід відмовитися від цього, або гачок, щоб забрати це, - це переконатися, що у вас є спосіб виміряти успіх, і ви можете також відзначати свої успіхи.
Тож я маю на увазі те, що ти там зачепився за цю захоплюючу тему, і я переїду до Рона, який перекопає трохи глибше.
Рон Хуйзенга: Добре дякую, Джен. І дякую всім за приєднання до нас сьогодні. Зараз я візьму кілька аспектів того, про що Джен говорила, і трохи глибше пітиму на певні ділянки. Але те, що я також збираюся зробити, - це подати короткий підсумок того, як ви можете хоча б мати своєрідну самооцінку деяких із цих сфер. Тому що, як ви бачили з моделями CMMI та подібними речами, ви можете дуже швидко заглибитись із великою кількістю різних показників. Тож, до чого ми дійсно хочемо дістатись, це щось таке, щоб ви могли добре відчути, де ваша організація знаходиться на досить високому рівні, а потім почати вивчати інші. Тож з цим я поговорю про ефективність організації. І я буду базувати це на CMMI та деяких інших стандартах або тілях знань, які випливають із цього протягом багатьох років. А потім я поговорю про деякі показники зрілості для зрілості даних та зрілості процесу, оскільки, як ми проходимо це, ви побачите, що вони йдуть рука об руку. І підтримуючи перспективи, Джен розповіла про управління в одній області. І я теж трохи поговорю про архітектуру підприємства. А потім ми підведемо його підсумок і перейдемо до самого круглого столу.
Якщо ми подивимось на це, існує багато стандартів та норм, які, звичайно, є сукупними знаннями, які були опубліковані протягом багатьох років. Багато з них насправді виникли на основі можливості зрілості. І ось звідки походила CMMI, про яку говорила Джен. Сама модель CMM була насправді в 1998 році. Її насправді розпочав джентльмен на ім'я Уотс Хамфрі, коли він був в компанії IBM. Він мав 27-річну кар'єру в IBM. Але його реальна активна розробка саме цієї моделі почалася, коли він був у Карнегі Меллон, і це було замовлено Міністерством оборони США. Для цього було використано багато інших стандартів. І те, що дуже добре знати про галузь, коли ми говоримо про це в деяких інших стандартах, це коли ми дивимось на терміни цього, це також на тлі речей, які ми бачили в промисловості взагалі. Це було тоді, коли рух якості по-справжньому почав займатися, особливо у виробництві, і перекинувся на інші сфери. Де ми розглядали шляхи вдосконалення виробничих процесів, роблячи такі речі, як загальне управління якістю, своєчасне виготовлення та інші речі. І багато філософій, які вийшли з цього, увійшли до всього якісного складу роботи.
І це справді своєрідне місце для стрибків, з якого почалося багато цього. Він розпочався в загальній галузі та пробився в ІТ, дані та процеси та інформаційні системи. Інші стандарти, які ми бачимо, тісніше пов'язані або більш конкретні для деяких речей, про які ми говоримо, - це, звичайно, модель зрілості даних, про яку Джен розповідала трохи. Також існує група зрілості бізнес-процесів від групи управління об'єктами. І ряд інших стандартів, які, можливо, ви бачили, що ваша організація може боротися або використовуватись для різних областей бізнесу, зокрема ІТ-систем, таких як COBIT, що є цілями управління інформацією та технологіями, ITIL, що, як правило, інфраструктура - зосереджена, з якою багато з вас, можливо, мали справу. Знову тотальне управління якістю. І особливо, коли ви потрапляєте в такі речі, як метрика та все інше, можливо, ви бачили, що такі речі, як контроль статистичного процесу, також вступають у гру. І, звичайно, деякі ті знання, якими ми маємо справу, - це інформація чи ІТ-фахівці. Орган управління даними знаннями.
Є, рівнозначне тому, тіло знань з бізнес-аналізу. І управління знаннями проекту. У вас може бути кілька або більше цих ігор, які одночасно використовуються різними зацікавленими сторонами у вашій організації. Але давайте щось фільтруємо через BOK, і повернемося назад і скажемо, що таке зрілість? І ми перераховуємо визначення зрілого, тому що, коли ви запитуєте, що таке зрілість, коли ви шукаєте його в словнику, воно фактично говорить "ви зрілі". Отже, використовуючи слово "зрілий", це насправді означає досягти просунутого стадія розвитку - звичайно, дуже родова. Але те, на що ми дійсно дивимось тут, - це просування того, що ми робимо, до вищого та більш високого рівня досягнень, коли ми проходимо. І коли ви дивитесь на багато стандартів, як ви бачите, зокрема, CMMI та модель зрілості можливостей насправді базують речі на п'ятибальній шкалі, тож це дає нам можливість поступово дивитись і говорити, як саме ми насправді еволюціонуємо за цією шкалою в тому, як ми ростемо?
Якщо ми дивимось на зрілість, то, з точки зору досягнення організаційної зрілості у речах, які нас цікавлять, нам потрібно бути в рівновазі. Вам потрібно досягти зрілості даних, і ми поговоримо про деякі критерії, які ви повинні там виконати, але вам потрібно домогтися зрілості процесу одночасно. Вони дві сторони однієї монети, і вони повинні йти рука об руку. Ви не можете перейти, скажімо, від нуля до п'яти за шкалою зрілості даних, не збільшуючи зрілість процесу, і те саме стосується зрілості процесу. Вони обоє об’єднані разом, і вони тягнуть один одного за їзду, оскільки ви насправді еволюціонуєте через різні етапи. І я розповім про це трохи більше у майбутньому слайді тут. Інші речі, які ми маємо усвідомити, - це досягнення як зрілості даних, так і процесів, є основними для архітектури підприємства та є основними для деяких речей, про які Джен говорила. Ми дозволяємо їм досягти зрілості в деяких із цих речей, які ми намагаємось зробити.
Тепер на слайд, про який Джен сказала, що я збираюся поговорити трохи детальніше. Я взяв лише декілька категорій і, використовуючи тут шкалу CMM, і в мене є власний, я фактично додаю нуль у переліку шкали, тому що можуть бути певні випадки, коли ви насправді не зробили будь-яка тяга взагалі в цих випадках. Отже, це лише способи розпізнавання, що відбулося. Отже, якщо ми розглянемо зокрема управління даними, ви можете почати з нуля, оскільки у вас немає жодних програм управління даними. І коли ви починаєте дозрівати в різних областях, як тільки ви починаєте впроваджувати його на проектному рівні, потім на програмному рівні, через підрозділи і в кінцевому підсумку в цілому на підприємстві, ось так, з точки зору управління, ви насправді дорослішаєте і росте як організація, як ви це робите.
Інші аспекти цього, такі як головне управління даними, ви можете починати з нуля без формальних класифікацій даних. Потім ви дістаєтесь, ви переростаєте до точки, коли визнаєте, що маєте головні дані, і починаєте класифікувати, але це не інтегровано. Потім ви починаєте працювати над інтегрованими та спільними сховищами. Потім, потрапляючи в стандартизоване середовище, саме тоді ви шукаєте послуги з управління даними. І як ви просунетесь далі, ви збираєтесь створити головних управителів даних і, врешті-решт, раду з питань керування даними, яка справді весь час серйозно ставиться до цього. Коли ви дивитесь на своє технічне середовище та додатки та бази даних, які ви маєте з точки зору інтеграції даних, знову ж таки, у незрілому середовищі, у вас буде ряд спеціальних, точкових інтерфейсів та такого типу річ. І коли ви росте, ви почнете впроваджувати деякі загальні інструменти та стандарти. Тоді ви почнете переглядати загальні інтеграційні платформи, коли це зробите. І коли ви станете стандартизованими, ви будете працювати над стандартизованим проміжним програмним забезпеченням та можливими простими речами, такими як службові автобуси, канонічна модель, класифікуйте всі ваші дані у вашій організації, а також прив'язуючи до таких речей, як правила ведення бізнесу у вашому сховищі та подібного роду речі. А потім піти ще далі там, де ви цілком вписуєтесь в організаційну культуру. І звичайно, якість є першорядною. Поки Джен говорила, багато рішень та багато інструментів, які є там, припускають, що у вас є високоякісні дані, з якими ви працюєте. Таким чином, якість даних - це основна основа досягнення зрілості даних.
Знову ж таки, коли ви дивитесь на дані, у вас може бути багато силосів та розпорошених даних у незрілих середовищах. У вас можуть бути невідповідності, які прийняті. І тоді ви починаєте працювати над цим, розпізнаючи непослідовне і потім починаєте дивитися на планування. Якщо ви дивитесь на керовані середовища тут, то тут дуже важливим є очищення даних при споживанні для того, щоб використовувати ці дані при прийнятті рішень. Тож, про що ми говоримо насправді, - це очищення даних, де ми збираємося завантажити їх у сховища даних та інші засоби підтримки прийняття рішень. І це аналогічно тому, що ми звикли бачити в галузі виробництва даних, де люди будують продукцію, вони пробиваються вниз по конвеєрній лінії, і в кінці цього ви оглянете продукт і перейдете: "О, У нас тут є дефекти ". Знову ж таки, одне, що ви ніколи не можете зробити, - це ніколи не вдається покращити якість товару, перевіривши його в кінці. Ви можете бачити проблеми з цим, а потім можете вживати заходів для вдосконалення наступних та інших, які виходять за лінію після неї, але ви ніколи не збираєтесь її вдосконалювати, перевіряючи її наприкінці. Так ось, коли ви рухаєтеся вперед, особливо в даних, ви більше рухаєтесь з огляду та очищення з точки зору споживання в місці споживання, де ви починаєте намагатися будувати це в джерелі, прямо звідки ви ловите дані, процеси, які діють на ці дані, гарантуючи, що ці дані точні та придатні для споживання в кожному процесі протягом усього шляху. По мірі подальшого розвитку ви починаєте розробляти та отримувати якісні показники KPI і дійсно починаєте розробляти той підхід щодо запобігання якості даних у процесі руху вперед.
Що стосується поведінки організації або того, що ви бачите, це, якщо ви не вважаєте, що у вас є проблеми або не знаєте, ви можете бути, якщо у вашій організації є фаза відмови, це говорить про те, що ви перебуваєте в нульовий рівень або потенційно переходить у один. Якщо навколо ваших даних багато хаосу і намагаються вирішити ці невідповідності, ви, мабуть, на рівні першого. Якщо ви все ще перебуваєте в реактивному режимі, ви переходите до керованого, але не збираєтесь отримувати стандартизацію, поки у вас фактично не буде стабільне середовище даних, що охоплює як управління, якість, головне управління даними та дані інтеграції, щоб назвати лише декілька моментів. І знову, як тільки ви пройдете це, саме тоді ви почнете вступати в дійсно проактивні стилі управління. Якщо ви перейдете до тієї частини, де ви маєте дуже передбачувану поведінку, а також аналітики для її резервування та KPI, щоб створити резервну копію у вашій організації, коли ми подивимось на це і накладемо пару речей, є деякі інші речі, які ми можемо дізнатися про організації та де вони знаходяться. Давайте розглянемо основний ІТ-фокус в організації. Якщо ваша основна увага в сфері ІТ все ще залишається на технології та інфраструктурі, ви, мабуть, вниз до менш зрілого кінця шкали. Але коли ви дійсно зосереджуєтесь на інформаційному та інформаційному сприянні стратегічному розвитку бізнесу, то ви наближаєтесь до зрілого кінця шкали. Крім того, коли ви дивитесь на це з точки зору даних, якщо ви знаходитесь в низькому кінці, у вас є високий ризик передачі даних, і якщо ви на високому рівні, ви знизили ризик, пов'язаний з даними. І зворотний бік цього - це цінність організації. Нижча зрілість даних означає, що ви, мабуть, маєте досить низький рівень формування цінності, особливо з точки зору даних, які є у вашій організації. І коли ви рухаєтесь вгору за шкалою, ви отримуєте велику цінність.
Давайте розглянемо це з точки зору самого моделювання даних. Іноді моделювання даних перетворюється на пасинка. І моделювання даних є основним для досягнення зрілості даних. Тому я просто хочу поговорити про декілька ознак розповіді про те, як моделювання даних пов'язане з цим. Якщо він просто використовується для документації або простого, фізичного створення баз даних для невеликих додатків і подібного типу, ви, мабуть, знизилися на рівні першого з точки зору зрілості даних. Коли ви починаєте сприймати та розпізнавати різні типи моделей, включаючи концептуальні, логічну модель та фізичне моделювання, де це також, ви знаєте, в основному ви рухаєте дизайн. Ви дійсно використовуєте це як точку зору дизайну, тоді ви на рівні першого.
Коли ви почнете розглядати це з більш корпоративного рівня, включаючи створення корпоративних чи канонічних моделей, введення понять та прив'язку до декількох моделей, лінійку даних та побудову метаданих управління прямо у ваші моделі, ви починаєте переходити до третій рівень, а потім переходити до метаданих з повним управлінням, інтеграції бізнес-словника та іншого. Переглядаючи життєвий цикл і цінність даних, це коли ви дійсно доходите до четвертого рівня. І знову ж таки, повністю інтегроване моделювання за допомогою словників бізнесу, метаданих, вміння керувати такими, як аналітика для самообслуговування, саме тоді ви досягли досить зрілого стану.
Як частина цього питання, я хочу розповісти про життєвий цикл даних дуже коротко. І причину, про яку я хочу поговорити, це життєвий цикл даних, на жаль, часто ігнорується. Що ж стосується, він дійсно описував, як створюється, читається, оновлюється чи видаляється елемент даних та процеси, які діють на нього у всій організації. Тож ті з нас, хто вже давно працює у цій галузі, називають це CRUD, оскільки це створювати, читати, оновлювати та видаляти. Але ми повинні розуміти це на фундаментальному рівні, коли ми маємо справу з даними в нашій організації. Багато факторів вступає в гру. Які правила ведення бізнесу діють на ньому? Які бізнес-процеси споживають, виробляють або змінюють дані? Які програми, які реально реалізують ці бізнес-процеси, дозволяють вам це робити? Все, що грає з точки зору життєвого циклу даних.
І знову, Джен нагадала на це раніше - не обов'язково може бути одне джерело істини. І може бути кілька способів створення певного елемента даних. І вам, можливо, доведеться зайти, різні речі надходять через декілька систем або кілька входів, які вам доведеться узгодити і вирішити, щоб придумати те, що є правильним джерелом даних для конкретного рішення в той момент часу. В організації може бути кілька варіантів даних для різних цілей. Щоб досягти цього, вам потрібно вміти моделювати бізнес-процес, рядок даних якого включає потоки даних, інтеграцію і включає такі речі, як ETL, тому витягуйте, перетворюйте та завантажуйте для вашого сховища даних, марта даних та області постановки даних і звичайно, посилання на дані з боку великих даних також вступають у гру. Коли ви витягуєте цю інформацію з озера даних, вам потрібно знати, як ви її споживаєте та як ви її використовуєте. Що стосується самого життєвого циклу, це насправді, як ми створюємо або збираємо нові дані, як ми їх класифікуємо - адже ви повинні класифікувати їх, щоб зрозуміти та ефективно працювати з нею - як ви їх зберігаєте, як ви Ви використовуєте його, як ви модифікуєте його до тих бізнес-процесів, де він ділиться в організації - і дуже важливо: збереження та архівування. Як довго ви зберігаєте дані? Коли ви архівуєте його? Коли ви остаточно знищуєте ці дані? Усі ці речі необхідно враховувати у вашому життєвому циклі даних, і ви повинні робити все це для досягнення високого рівня зрілості даних у вашій організації.
Тепер я знову сказав, що вони схожі на близнюків, де вам потрібно поговорити про зрілість процесу в поєднанні зі зрілістю даних - вони йдуть рука об руку. Знову ж таки, у мене тут є кілька різних речей і - не хвилюйтесь, я не збираюсь читати все це, а просто такий собі контрольний список, щоб - знову ж таки, ви можете почати самостійно оцінювати, де знаходиться ваша організація з точки зору зрілості процесу. Давайте ще раз розглянемо речі з початкового права через оптимізовані сторінки. Знову ж таки, ми використовуємо ту саму п'ятибальну шкалу, яка була похідна від моделі зрілості можливостей. Якщо ви дивитесь на такі речі, як фокус, якщо ви знижуєтесь на нижчому рівні або початковому рівні зрілості процесу, ви можете виявити у вашій організації, що люди справді покладаються на свої власні методи для виконання своєї роботи. І ви можете побачити деяку героїку та подібний тип речей, щоб мати змогу виконати справи. Потім ви починаєте доходити до того, що ви ставитеся до цього більш активно, коли ваше керівництво бере на себе відповідальність за робочі підрозділи та результати роботи. Потім ви починаєте розвивати стандартні інтегровані процеси. Потім стабільність процесу та повторне використання. Тоді ви починаєте бачити більше культури наставництва та статистичного управління для обчислення показників та KPI щодо цих процесів і, нарешті, до повного рівня оптимізації.
Якщо ви подивитесь на управління роботою, ви можете піти на шлях, ви перейдете з тієї області, де у вас є непослідовний рівень управління роботою, до більш керованої, де ви збалансуєте принаймні на більш високому рівні свої зобов’язання щодо ресурсів. Потім до точки, де у вас є більш пристосована або гнучка організація, щоб ви могли стандартизувати свої процеси, але пристосувати їх до найкращого використання в різних обставинах вашої організації. І коли ви переходите до передових, саме тут розширення можливостей є дуже важливим, і це означає, що всі інтуїтивно розуміють, що відбувається, і персонал має дані про процес, щоб вони могли оцінити та керувати своєю роботою.
Знову повертаючись до виробничої аналогії - коли ми побачили, що, коли ми починаємо модернізувати наші конвеєрні лінії та все подібне у промисловості, ми заговорили про загальну якість та розширення можливостей працівників навіть на конвеєрі, де, якби хтось бачив Щось не так на будь-якому конкретному етапі виробництва, люди отримали повноваження, що вони можуть натиснути на велику червону кнопку та закрити всю конвеєрну лінію, поки проблеми не будуть вирішені, перш ніж все піде далі. І саме такий тип менталітету та культура, яку ми шукаємо навколо даних у своїх процесах, щоб переконатися, що ми насправді оптимізуємо наші дані та наші процеси в нашій організації.
Інші показники вашої культури - чи ваша культура застоюється з точки зору не визначених підстав для реальної прихильності до вдосконалення ваших бізнес-процесів? Чи є делегування відповідальності, яке ми бачимо далі за масштабами? І як ви рухаєтеся далі, у вас все ще можуть бути силоси, але, коли ви починаєте рухатися вгору з точки зору культури та речей, які ви робите у своєму бізнес-процесі, ви також руйнуєте ці різні бізнес-силоси та використовуєте процесів у вашій організації. Дуже важливо, що, переходячи до етапу події, це те, що ви насправді ґрунтуєтеся на цьому, а не відчуваєте, як ви відчуваєте, ви фактично збираєте якісні показники, і у вас є показники, щоб передбачити ваші можливості в діяльності вашого бізнесу. операцій, і це надзвичайно важливо.
Що стосується архітектури, давайте поговоримо про це, тому що багато з нас тут в ІТ або завжди дивляться на ІТ. Знову ж такі речі, які ми бачили в даних. Ми маємо відчайдушні ІТ-системи, якщо ви насправді на початкових етапах зрілості процесу. Як тільки ви почнете керувати своїми процесами, ви побачите, що деякі сервіси створюються там, де ви реально застосовуєте більше підходу, заснованого на послугах. Тоді, якщо ви станете стандартизованими, ви побачите більше прийняття повного сервісу щодо даних і служб та службових процесів, і такого типу речей, аж до того, де ви отримаєте повний сервіс або нову архітектуру. І тоді в кінцевому рахунку до повного управління процесом підприємства, яке використовує ваші дані.
Знову ж, ті самі типи ваг, коли ми дивимось на це. Що стосується продуктивності, то при низькому рівні зрілості процесу ви побачите низький рівень продуктивності та високу зрілість процесу, ви побачите набагато більшу продуктивність. І якість також поєднується з цим. Так само, як і з даними - якщо ви низький рівень зрілості, ви побачите високий рівень ризику, а також високий рівень відходів. Але чим вище рівень зрілості, ти знижуватимешся та знижуєш ризик та значно знижуєш відходи. Щодо деяких речей, які ви можете бачити як певні симптоми або показники в організації, якщо основна філософія базується на скороченні витрат, ви, ймовірно, знижуєтесь на низькому рівні зрілості процесу. Тоді ви будете закінчувати освіту і рухатися до більш глибокого вивчення ефективності у своїй організації, і тоді, як ви досягнете дуже зрілого рівня, ви знову зосереджуєтесь на генерації вартості.
З точки зору організаційного управління, якщо панує хаос, це, як правило, симптом організацій з низьким рівнем зрілості. Але ви починаєте зосереджуватися на тому, що я називаю більше менталітетом менеджменту, де - і може бути якесь управління указом або накладення речей - де ви насправді тоді, коли ви переходите до більш зрілих рівнів, ваше управління перекладається на більше керівництва. Іншими словами, філософія вдосконалення вбудована в культуру і від генерального директора вниз, вони пропагують всю цю філософію вдосконалення процесів і постійного, постійного вдосконалення вашої організації в цілому.
Що стосується моделі процесу - і я досить швидко перегляну ці речі тут - ще раз розглянемо моделі процесів, як вони вписуються в саму зрілість процесу. Знову ж таки, дуже схоже на те, що ми бачили в зрілості даних, де на низьких рівнях або на рівні першого ви можете просто документувати процеси або поточний процес стану, але ви насправді не використовуєте це з точки зору просування речей вперед. Коли ви почнете дозрівати, ви збираєтесь використовувати моделювання бізнес-процесів для того, щоб активізувати фактичне управління бізнес-процесами в організації, а потім ще більше розвиватися там, де ви його використовуєте, і постійно оновлювати ці моделі, щоб керувати вдосконаленням процесів туди, де ви в кінцевому підсумку. приступайте до оформлення дизайну. І тоді, коли ви досягнете повної зрілості, або, знаєте, те, що ти зазвичай бачиш у худорлявих організаціях, які прийняли програми вищої якості, такі як Sigma, це знову-таки ти маєш менталітет постійного вдосконалення, і це вкорінено правильно в моделюванні вашої організації. Точно так само, як ми використовуємо інженерні креслення для створення виробів, будь то літаки чи будівлі та хмарочоси, і такий тип речей, ми покладаємося на наші моделі, щоб насправді рухати наш бізнес вперед, тому що це елемент дизайну, який насправді рухає наші організаційні елементи вперед .
Тепер, знову ж таки, я не збираюся детально переглядати це та кожне кожне слово. Що я зробив, це те, що я взяв ці два простіших слайди сітки, і я вибрав ряд слів, які були використані в деяких з цих інших дескрипторів як для зрілості даних, так і для зрілості процесу. Отже, коли ви дивитесь на це після факту, ви можете почати думати про деякі слова, які, як ви бачите, виходять у власних внутрішніх культурах з точки зору речей, про які говорять. І це допоможе вам почати класифікувати, де ми, як загальна організація, починаємо підходити до цієї шкали зрілості загалом. Тож якщо ви бачите такі речі, як невідповідність чи застій, або неефективність, які виникають досить часто або хаос, ти зазвичай опинишся в нижньому кінці шкали. Коли ви починаєте думати про такі речі, як постійне вдосконалення, стратегічне вирівнювання, профілактичний підхід до дефектів та якості та такого типу речей, повна інтеграція, і ви говорите про кращі практики в конкурентній перевазі, саме тоді ви збираєтеся побачити себе вгору на оптимізаторі, вищий кінець шкали.
Знову ж таки, на що я хочу зазначити, що коли ви починаєте дивитися на управління даними, зокрема, коли ви дивитесь внизу шкали, знаходиться на початкових етапах, управління даними може бути запроваджено лише на окремих рівнях проекту. Потрібно розвиватися до того моменту, коли управління даними та певна мета - від управління даними проектів і розвиваються через управління програмними та дивізіональними даними, де знову це підприємство і вбудоване в організацію в цілому.
Я говорив про те, що це насправді близнюки, які працюють разом з точки зору зрілості даних та зрілості процесу. Досягаючи цієї зрілості, обидві сторони шкали - це подорож, і ви не можете стрибати кроками. Якщо у вас нуль, вам доведеться еволюціонувати через етапи один, два, три, чотири і в кінцевому підсумку дістатися до п'яти. І в світі дуже мало організацій, насправді в п'ятірку. Тож багато організацій були б більш ніж задоволені, опинившись у точці, де вони знаходяться в трійці, а потім зможуть використовувати це як плацдарм, який рухається вперед. І знову ж таки, ви не можете піти, ви не можете бути чотирьома з моменту зрілості даних та одного з зрілості процесу. Це просто не працює, оскільки вони настільки взаємопов'язані, що вам потрібно зрозуміти і добре обробляти свої дані та процеси в поєднанні один з одним.
Хороша аналогія, щоб подумати про це так, як ви хочете на шляху до організованої зрілості, припустимо, що ваша команда складається з двох людей: Один - зрілість процесу, а другий - зрілість даних. Ви біжите перешкоду з перешкодами, і ви зв’язані короткою мотузкою. І щоб дійти до кінця цього курсу, це означає, що ви обоє повинні пройти не тільки всі перешкоди, але вам доведеться пройти всі перешкоди майже одночасно або дуже близько один до одного, щоб бути здатний рухатися далі і дістатися до наступної перешкоди. Це дійсно хороший спосіб подумати про збалансування зрілості процесу та зрілості даних. Тобто іншими словами, ви можете бути дещо орієнтованими на процес і можете бути дещо орієнтованими на дані, але це буде провідним показником, і не може бути великого розриву, щоб насправді вивести вас через рівні.
І тоді, коли ми знову дивимось на це з управління даними, одна з речей, яку я хотів зазначити, якщо ви цього не знали, - це те, що DAMA фактично випустила орган управління знаннями томом два на початку цього року та про речі, які поміняв там власне колесо DAMA. І я насправді представляв це трохи інакше, де управління даними знаходиться в центрі, а десять різних категорій навколо різного колеса. Тут дуже важливо бачити моделювання даних, і дизайн насправді має власні ділянки на колесі - раніше він був наче поєднаний з іншими. Одне з важливих моментів тут - моделювання даних, зокрема, є основним для всіх цих інших аспектів, тому що, чи ми робимо моделювання даних наших баз даних, або метаданих, з якими ми маємо справу, моделювання даних має роль грати у всіх цих інших творах, про які ми говоримо. І моделювання процесів також має важливу роль у багатьох цих речах, тому що, крім розуміння самих даних, ми повинні розуміти, як вони використовуються, і саме так моделювання процесів насправді допомагає нам це робити.
Тепер трохи змінимо передачу і поговоримо про архітектуру підприємства. І моделі мають вирішальне значення для архітектури підприємства. І я грунтуюся на цьому на прикладі, і це Закман, який я показую тут дуже швидко. І коли ви дивитесь на це, ви бачите тут кілька речей. Ви бачите, що, як, де, хто, коли і чому є своєрідною шкалою вгорі. А потім ви проходите більш детальні рівні розробки, якщо ви будете, з точки зору типів моделювання чи типів речей, які ви розробляєте з точки зору архітектури підприємства, від дуже високого контекстуального рівня аж до детального рівня, включаючи фізичну реалізацію. Якщо ви подивитесь на перші стовпці, то, що дуже важить даних, і дані, що стосуються. Як керується дуже процесом. І якщо ви подивитесь на інші аспекти, ви будете використовувати комбінацію моделювання процесів і даних з точки зору залучення решти інформації. Ви будете мати дані про всі ці різні речі, і ваші моделі процесів також збиратимуться пов'язати, як, де це відбувається, відповідальність. А також з точки зору моделювання процесів, які ми добре виконуємо в наших інструментах, ви можете почати пов'язувати це з цілями, стосунками та правилами бізнесу, які також визначають різні речі, які ви робите.
З точки зору загальної точки зору Захмана, один із хороших способів подумати над цим - це те, що ти керуєш моделлю, і ти насправді переживаєш різні рівні. Отже, ви починаєте з високого рівня та контекстуального. Тоді ви розвиваєтеся до бізнес-моделей, вниз до системних моделей, потім технологічних моделей, а потім і дуже детальне представлення технічних моделей. І знову ж таки, дані являють собою що, процес - це як, і це дійсно поєднання взаємодіючих даних та процесів, які керують усіма іншими характеристиками тут.
Виходячи з цього, не випадково те, як ми бачимо ідею архітектури підприємства, базується дещо інакше, ніж деякі інші. Досить часто ви чуєте про чотири стовпи архітектури підприємства: архітектуру даних, придбання, бізнес та технічну архітектуру. Ми дивимось на це трохи інакше, ніж на це. Ми розглядаємо архітектуру даних як основну основу, яка керує всією архітектурою підприємства з двох причин. Один, ось з чого і почався. Навіть такі речі, як рамки Захмана, виросли в основному з архітектури даних, а потім перетворилися і на інші аспекти архітектури. І два, тому що принциповий зв'язок між процесом і даними. Ось чому ми бачимо бізнес-архітектуру як центральний стовп архітектури підприємства. І тоді, звичайно, це компліментує архітектура додатків та технічна архітектура, які є абсолютно необхідними умовами, щоб ми могли реалізувати справжні можливості підприємства. Тепер, коли ми розглядаємо це з точки зору ER Studio Enterprise Team Edition, нашої інтегрованої платформи моделювання, ось як це входить у гру. І це контекстна діаграма на високому рівні деяких моделювань, які ми робимо, та деяких основ, що стоять за ним. І це насправді втілено, це фактично зафіксовано в діаграмі процесу. Отже, коли ми дивимося на наш фрагмент архітектури даних, а також на нашу ділову архітектуру внизу, ми пропонуємо інструменти на основі ролей.
А коли ви дивитесь на наш інструмент бізнес-архітектора внизу в лівому нижньому куті, то тут зазвичай працюють бізнес-аналітики та бізнес-архітектори. І вони, як правило, зосереджуються на деяких бізнес-процесах і починають виганяти їх. Але вони також зосереджені на тому, що. Тоді ми починаємо робити якесь концептуальне моделювання даних та подібні речі. Ми можемо використовувати ці компоненти концептуального моделювання в нашому інструменті моделювання даних та в архітекторі даних, де вони детальніше розроблені в логічних моделях даних і, звичайно, фізичних моделях, щоб ми могли генерувати фізичні бази даних. І ми можемо також відштовхуватися, щоб концептуальні моделі були модернізовані і в просторі бізнес-архітектури. Тут дуже важливою є підтримка різних типів моделювання. Отже, знову ж таки, BI є дуже важливим, і озера даних та подібні речі, тому ми фактично також робимо деяке моделювання, а також як частина цього, ми робимо моделювання ліній даних. Таким чином, не тільки ETL з точки зору того, як ви здійснюєте відображення зі своїх фізичних моделей у ваші розмірні моделі для сховищ даних або навіть приведення речей із ваших озер даних і бачачи, як вони відображають, ми можемо зв'язати всі ці речі разом. Як і переадресація зворотної інженерії з інших платформ моделювання, з великих платформ даних.
А потім також такі речі, як інструменти ETL, тому ми можемо насправді почати отримувати діаграми рядків даних прямо із специфікацій ETL, які у вас можуть бути у вашому власному середовищі. Також дуже важливо знати, що нам довелося вийти за рамки реляційного моделювання. У нас є певні платформи на зразок Hive і особливо MongoDB, ми зараз починаємо говорити про магазини документів, де у нас є такі поняття, як вбудовані об'єкти та масиви. Ми фактично розширили позначення, щоб також вмістити ці типи моделей, тому що це нереляційна концепція. Все, що ми створили в інструменті архітектора даних з точки зору артефактів даних, будь то логічні об'єкти або фізичні таблиці та їх атрибути, може бути також повернуто в моделювання бізнес-обробки. Отож, коли ви розробляєте моделі бізнес-процесів з високого рівня та переходите на нижчий рівень, ви можете фактично зв’язати фактичні елементи даних. Отже, ви можете діяти, ми можемо вказати матриці CRUD того, що відбувається насправді. Отже, це дає вам той життєвий цикл даних, про який я говорив зі створенням, читанням, оновленням та видаленням на рівні процесу. І ми там робимо повне моделювання процесів BPM з власним набором накладок, тож ви можете почати пов'язувати бізнес-стратегії, бізнес-цілі. Крім того, ми також можемо приєднатись до програм, які реалізують ці бізнес-процеси, і все це з точки зору моделей.
Інші речі є надзвичайно важливими і в наших моделях даних. Характеристики управління даними або характеристики якості даних засвоюються та управління. Ви можете визначити та створити там свої власні метадані для характеристик, які ви хочете відстежувати, а це означає, що тепер ви використовуєте свою модель як креслення для керування цим через всю вашу організацію, у ваші сховища метаданих та все інше. І звичайно, одне з обмежень моделювання, багато років тому, коли багато з нас починали в галузі робити це, - це ми виробляємо ці моделі. Що б ми зробили? Ми б їх роздрукували, поставили б на стіну, можливо, щоб члени команди могли поділитися та подібними речами. Справжня цінність цього полягає в можливості ділитися і співпрацювати в наших організаціях. Тому ми маємо підхід, орієнтований на сховища, для того, де ми перевіряємо та перевіряємо наші моделі та робочі місця. І ми ділимось ними з нашими учасниками організації, незалежно від того, чи є вони іншими технічними зацікавленими сторонами, діловими користувачами тощо. А також пов'язати це з нашою платформою для співпраці під назвою Team Server.
Тож ми поговорили про більш ранні бізнес-словники та терміни, про важливість цього та розробки цього словника для бізнесу. Це все було в Team Server, де користувачі, бізнес-користувачі можуть співпрацювати на цих умовах. Вони помітні, їх можна використовувати в архітекторі даних, наприклад, поблизу моделей даних, і, звичайно, багато цих словників бізнесу часто походять з деяких словників даних, які ми створили в наших моделях даних. Ми можемо підштовхнути це до того ж - також із інструментів архітектури даних вихідною точкою є бізнес-словник, де їх можна вдосконалити далі, а також все із управлінням змін навколо нього.
Це було багато Підводячи підсумок, кілька речей, про які ми говорили - це спробувати справжню організаційну зрілість, вам потрібен збалансований підхід, який складається із зрілості даних та зрілості процесу. Неможливо досягти одного без іншого. Знову ж таки, фундаментальне, вам потрібно мати і те, і на це потрібно покладатися, зокрема, моделювання даних та моделювання процесів як для архітектури підприємства, так і для управління даними та управління процесами, а також у ваших організаціях. Корпоративна архітектура насправді пов'язує її разом з точки зору розгляду цих різних аспектів та перспектив. Для цього вам потрібна міцна основа архітектури даних, і вам потрібно інтеграційне моделювання процесів, щоб забезпечити цей бізнес-контекст і дозволити вам рухати свій бізнес-процес і споживання ваших даних вперед. Знову важливіше, ніж будь-коли раніше. Я можу сказати: те, що старе, знову нове. Таким чином, моделювання даних, моделювання процесів, рядки, метадані та словники є основними для досягнення цього, а ER / Studio Enterprise Team Edition - це спільна платформа, яка поєднує все це разом.
І з цим ми можемо перейти до питань.
Ерік Кавана: Добре.
Рон Хуйзенга: Ми підемо до тебе, Ерік.
Ерік Кавана: Рон, я маю накинути тобі капелюх на всі зусилля, які ти докладеш до документування цих різних процесів та рамок. Це багато матеріалу, який ви там отримали. Я здогадуюсь, що у мене головне питання, хто має наглядати за цими матеріалами в організації, тому що ви торкаєтеся так багато різних речей. Ви розбираєте процеси, це буде головний операційний директор чи людина з операцій. Життєвий цикл даних, ви думаєте, можливо, це буде головним службовцем даних. Ви торкаєтеся так багато різних частин і стільки різних компонентів для бізнесу. Як ви знаходите потрібну людину чи групу людей, і це керівний комітет? Що це? Що ви можете сказати нам про те, хто повинен це робити в організації?
Рон Хуйзенга: Знаєте, це цікаве питання. Ми можемо реально провести день, обговорюючи достоїнства різних різних підходів. Але щось, що я точно бачив, ви знаєте, як я консультувався до того, як я вступив у роль управління продуктом, - це коли я дивився на організацію, то це було частиною проблеми - отримання права власності та отримання людиною права на право власності на це. І коли ми дивимось на такі дисципліни, як наше моделювання даних і навіть моделювання бізнес-процесів, або навіть у перші дні, діаграми потоку даних та подібні речі, такі види виросли з ІТ. Але, коли ми рухалися вперед, і я думаю, що зараз ми все більше і більше усвідомлюємо, що це справді має керуватися бізнесом. Тому ви дуже хочете, щоб право власності на це було в бізнесі.
І я збираюся образити деяких ІТ-людей тут, але я твердо вірю, що причиною того, що ми бачили еволюцію ролі головного службовця з питань даних, є роль CIO, у більшості організацій цього не вдалося. І це тому, що багато CIO технічно сфокусовані, а не на даних та процесах. Тому я думаю, що вам це справді потрібно, вам, мабуть, знадобиться якийсь керівний комітет у більших організаціях. Але цим справді потрібно володіти бізнесом. Я б висловив аргумент, що ваш бізнес, ваше моделювання процесів, ваше моделювання даних мають належати до бізнесу, оскільки це дає вам можливість гарантувати, що ІТ, який є зберігачем даних, і реалізує ці процеси завдяки тому, що вони Ви створюєте, у вас є цей молоток, щоб переконатися, що це відбувається, якщо він фактично належить бізнесу.
Ерік Кавана: Так, я думаю, я погодився би з цим. Але Джен, що ти думаєш про це?
Джен Андервуд: Тож це дійсно цікаво. Це те, на що я натякав, коли говорив, що турбота про людей та їх інтерактивність - це, мабуть, одна з ключових речей. Якось я написав білу книгу про те, що це управління БІ для самообслуговування дуже схоже на це. Справа в тому, щоб знайти це, знайти спосіб мотивувати людей, сторонню цінність бізнесу, змусити їх дбати про це. І тоді, коли вони бачать, або знаходять, чи це каталогізація даних, чи будь-який кут. Можливо, це зменшити витрати на відвантаження, поставити те, за що хтось несе відповідальність в організації, саме так можна доглядати. І так, бізнес абсолютно. Експерти з питань ділової тематики збираються зробити або порушити.
Ерік Кавана: Це важко. Я думаю, ви завжди хочете мати цей консорціум зацікавлених сторін з усієї організації. Звичайно, не хочеться паралічу аналізу. Ви не хочете бюрократії заради бюрократії. Те, що ви хочете, - це організація має план дій і документувати ці речі. Ви знаєте, я думаю, коли ти починаєш говорити про моделювання бізнес-процесів, це було спекотно 25 років тому, але це було в основному відірваним від реального бізнесу. Я думаю, що принаймні в деяких галузях ви можете витягнути багато цього процесу з фактичного програмного забезпечення, яке керує речами. Але я думаю, в ці дні ми повинні знайти спосіб збалансувати ці два світи, правда, Рон? Ви хочете мати сучасні та сучасні моделі процесів, які відображають те, що відбувається насправді. Тож ви не хочете, щоб це було просто окремою вправою, де вона є, вона десь сидить на полиці. Але це, це стає трохи складним, правда? Тому що не всі операційні системи узгоджуються з таким видом виконуваного коду. Але що ти думаєш?
Рон Хуйзенга: Абсолютно. І це цікаво, бо я дивлюся на те, що я дивлюся, коли люди, знаєте, ми стали миттєвим суспільством задоволення. Люди думають: "О, ми просто вийдемо, придбаємо кілька інструментів і зробимо це для нас". Начебто, ви не збираєтеся купувати зрілість процесу. Ви не збираєтеся купувати дані про термін погашення. Це важка робота. Ви повинні засунути рукави, і ви повинні зробити це. І механізм, щоб це відбулося, - це моделювання. Це занадто складно, щоб не мати візуального уявлення не лише про поточний стан, над яким ви працюєте, а й вміти розробляти, як ви збираєтеся покращити ці різні бізнес-процеси. Вам потрібна ця візуальна рамка, щоб можна було зрозуміти, який вплив ці зміни чинять.
Ерік Кавана: Це справді - я просто твіт; Я це твітую зараз - "Ви не збираєтесь купувати термін погашення, ви не збираєтесь купувати термін зрілості". Я можу просто повністю погодитися з обома цими речами. І Джен, я б запросив тебе за твоїми думками. І я перекину ще одне запитання. Один із присутніх запитує: що мається на увазі під керованим процесом підприємством або зрілістю процесу? Джен, ти можеш з цим поговорити?
Джен Андервуд: Насправді я можу трохи краще сказати попереднє питання. Коли я замислююсь, правду кажучи, це перша, знаєте, покупка інструментів. Це був такий чудовий, чудовий коментар, тому що це так правда. Але що я скажу - це набагато краще. Тому я переглядаю безліч рішень і бачу різні пробіли і тестую їх. Що стає краще - це виявити дані, позначити теги і принаймні дати вам масовий старт, а також зробити це, коли я кажу менш болісно, це майже весело. Тож уявіть, що каталог даних або проект MDM є цікавим. Так, і у вас є люди в організації, яка використовує ці дані, чи то звітність, чи інші види речей, і я думаю, що хтось, навіть за лінійкою, сказав, тож отримуйте людей, які піклуються про їхній індивідуальний план розвитку. Так, навіть підняти його на ще один рівень. Це приймає ці речі і каже, що зараз ми знизили неправильно поставок на 30 відсотків, і саме на це зекономили гроші. Це просто краще керувати нашими даними. Це такі типи речей, і ви вкладаєте гроші навколо цього, і ви робите це весело. Або ви робите це цікавим і актуальним для того, що вони роблять. Це якась магія, я думаю, цього не вистачає в багатьох цих заходах, що люди намагаються це зробити в організації, і це затримується.
Ерік Кавана: Так, це хороший момент. І, Рон, повернувшись до Вашого коментаря кілька моментів тому навколо важливості створення візуальної рамки, я думаю, що це абсолютно вірно, тому що багато разів, якщо люди щось не бачать, насправді важко обернути голову навколо того, що це значить, і звичайно, коли ви починаєте говорити про складні процеси з взаємозалежностями і контрольними точками, і про всі ці речі, вам доведеться це десь в якийсь момент відобразити, і в ідеалі ви це робите з програмним забезпеченням, яке має вбудований у нього функціональний каталог, для Наприклад, які перетворення відбулися за допомогою різних ліній від цієї точки до цієї точки. Або те, що є в цьому контрольному пункті. І я якось посилаюсь на свою історію управління ризиками там, де контрольною точкою є будь-яка точка в процесі чи будь-яка опція, або окремий або програмний додаток, де ви можете щось змінити, правда? Саме так вони називають контрольний пункт. І, на мій погляд, це дійсно цінно, що ви отримуєте цю візуальну рамку. Тому що ви можете побачити і види прогулянки, і це просто потребує часу. Людському мозку потрібен час, щоб керувати цим матеріалом і реально зрозуміти його, а тому оптимізувати його, правда?
Рон Хуйзенга: Абсолютно. І для того, щоб використати іншу аналогію, яку, на мою думку, ставить у перспективу: я трохи авіаційний гай, тому, я б сказав, якщо ви намагаєтесь це думати паралельно, подумайте про створення 747 - або Airbus 380, тому я не вибираю одного постачальника над іншим - подумайте, як важко було б це зробити на основі документів, складених лише з тексту, а не креслення та 3-D малюнки CAD та все, як це насправді зібрано разом.
Ерік Кавана: Так, це було б грубо. І Джен має теж говорити.
Рон Хуйзенга: Бізнес той самий, правда?
Ерік Кавана: Так, ні, це правильно. Джен має розмовляти з однією з ваших гарячих областей, яку ви хочете вивчати, а це візуалізація. Ви повинні вміти щось візуалізувати, щоб повністю зрозуміти це, мені здається.
Джен Андервуд: Дуже багато людей, так. І навіть просто візуалізація говорить, що говорити, тисячі слів чи щось подібне. Коли вони це бачать, вони можуть у це повірити. І вони це отримують.
Ерік Кавана: Я згоден. І я люблю, Рон, як ти все це зблизив. Я думаю, що я просто запитую себе ще раз: вам потрібен чемпіон всередині організації, і хто буде там, щоб служити зв’язком для різних груп. Дані стюардів - це те, про що ми часто говоримо - я думаю, що це дуже важлива роль, і я вважаю, що це роль, яка за останні три-чотири роки отримала набагато більше уваги, оскільки ми якось цінували цінність даних управління, правда? Цей керівник даних - це той, хто може спілкуватися з бізнесом, але також розуміти системи, розуміти життєвий цикл даних, всю цю картину. І я здогадуюсь, що ця людина може і повинна бути, мабуть, під керівництвом генерального директора, правда?
Рон Хуйзенга: Так, і вам знадобиться багатофункціональна команда, правда? Тож вам знадобляться люди, які складають команду, яка займається тим чи іншим завданням з різних областей, що представляють технічну сторону, та, знаєте, різні сфери бізнесу. І, знаєте, залежно від типу організації, якщо у вас є офіс з управління проектами і багато ініціатив, які ви робите, керує керівництвом управління, ви хочете переконатися, що у вас є ПМО залучення, а також просто для збереження всіх видів у гармонії та синхронізації того, як вони працюють над речами.
Ерік Кавана: Так, і ви знаєте, останнє, я викладу останній слайд, рамки управління. У нас був учасник запитання, чи не вистачає даних із цього слайда? Це чи мають на увазі дані слайда чи що ви думаєте щодо коментаря про відсутність даних із слайда?
Джен Андервуд: Ні, і це лише загальна структура управління. По суті, це відбувається з простору BI для самообслуговування, тому дані мають на увазі багато цього. Це було просто з моєї точки зору та моєї точки зору, і не настільки зосереджене на стороні даних, що склало це разом. Але дані, безумовно, були б, коли ви думаєте про всі ці фрагменти, були б дані. Будь це фундамент для даних, підзвітність за допомогою даних протягом усього процесу та в усьому рамках.
Ерік Кавана: Так, ні це не має повного сенсу. І я здогадуюсь, я накину тобі ще одне останнє запитання, коли ми закінчимось тут, Рон. Якщо я подумаю про те, скільки більше інформації та скільки більше даних ми використовуємо в ці дні та про те, наскільки розвинені організації, яке значення мають екосистеми в наші дні між партнерами каналу та як ми можемо обмінюватися інформацією в цих партнерствах та в небагато швидкого посилання blockchain на це - не робити речі надто складними. Суть полягає в тому, що ми перебуваємо у світі, де все більше керуються даними, як з точки зору бізнесу, так і з нашого повсякденного життя. І для мене це просто збільшить ставку ще більше за те, що організації дійсно серйозно подивляться на те, що ви тут пропонуєте, яка їхня зрілість, де вони стоять і наскільки далеко вони знаходяться з точки зору кривої та насправді бути чесним із самим собою з цього приводу, правда? Тому що, якщо ти не знаєш краще, ти не можеш робити краще, і якщо ти не задумуєшся над речами, ти не будеш краще знати, правда?
Рон Хуйзенга: Саме так. І я здогадуюсь, фразу, яку я б застосував, є те, що ти, мабуть, не такий хороший, як ти думаєш. Це може здатися суворим, але люди можуть бути досить оптимістичними щодо цього, але якщо ви по-справжньому уважно подивитесь на це і по-справжньому хорошу критичну самооцінку, я думаю, будь-яка організація знайде, знаєте, значні прогалини, які вони потрібно звернутися.
Ерік Кавана: Я повинен погодитися. І один з наших колег там прокоментував важливість метаданих, даних про дані. У цьому немає жодних сумнівів. Метадані - це клей, який поєднує всі ці системи разом, і ми все ще ніколи навіть не повністю зламали цей код і з поважної причини, відверто кажучи, тому, що метадані змінюються. Він відрізняється від системи до системи. Знаєте, чим більше ви намагаєтесь нормалізувати свої дані, тим менш точними я вважаю, що це стає.
Тож ми зараз у цьому дивному світі, і, мабуть, я думаю, я ще одне питання до тебе, Джен, бо ти кілька разів згадував каталоги даних. Я дуже люблю цей новий рух технології каталогів даних, який автоматично сканує ваші інформаційні системи, визначає назви стовпців метаданих тощо тощо та допомагає вам поступово формувати стратегічний вигляд ваших даних та ваших метаданих у ваших системах. Тому що для мене, щоб зробити це вручну, це просто, є занадто багато. І ти ніколи не збираєшся дістатися до вершини цього пагорба, перш ніж на тебе зійде лавина, і, знаєш, ти або нормалізувався до точки сірого тесту, або ти не нормалізувався там, де ти насправді робиш Я не знаю, що відбувається. Для мене, використовуючи машини, машинне навчання, про яке ми продовжуємо говорити, це стане ключовим у майбутньому, щоб допомогти нам хоча б отримати мотузку навколо достатньо даних, щоб добре зрозуміти, що там, правда, Джен ?
Джен Андервуд: Так, я. Я люблю ці технології. Вони дуже-дуже круті. І тоді ви подумаєте про це, це дає вам той масовий біговий старт. І тоді ви можете переповнити ресурси. Ви маєте своїх управителів даних, знаєте, випереджаючи, чи додають вони власну документацію, чи це перспектива там, ось ці зміни. Ви знаєте, говорячи, що це сертифіковані джерела даних, які слід використовувати для звітності. Люди можуть шукати та знаходити потрібні дані. Це дійсно, дійсно досить приємно. А також допомагає: коли я замислююсь про бізнес і про те, як криптичне управління даними підприємств було, коли я займався справами DBA - ми використовували розширені властивості та SQL Server та сканували за допомогою таких інструментів, як IDERA, правда? Спробуйте створити каталог даних. Але у версії DBA або архітекторів даних, ви знаєте, якою б не була ця цінність чи той стовпець чи поле, воно, напевно, не відповідало тому, що було бізнесом. Тож тепер, маючи бізнес, можна легко по-справжньому, увійти, знайти та керувати, і все має бути орієнтоване на цілі, це дійсно, я б хотів, щоб ми мали це давно, відверто кажучи. Тож стає набагато краще.
Ерік Кавана: Це смішно. У нас є ще один остаточний коментар учасника аудиторії, кажучи, що, можливо, blockchain буде найціннішим для того, щоб поставити штамп автентифікації на метадані. Це хороший момент, і, знаєте, blockchain насправді дивовижна технологія. Я свого роду розглядаю це як свого роду згуртований фундамент для з'єднання багатьох точок між системами та програмами тощо. І, знаєте, ми перебуваємо на ранніх стадіях розвитку blockchain, але тепер ми бачимо, що це відкручується, звичайно, з цього моменту спочатку, де він вийшов на перший план, і тепер у вас IBM дуже наполегливо працює на блокчейн-технології. SAP придбав все це. І це дійсно так, це дає можливість більш глибокої основи та рамки для з'єднання всіх цих систем та всіх цих точок.
Отже, люди, горіли добре протягом години. Дякуємо, що залишаєтесь разом з нами сьогодні, але ми завжди любимо відповісти на ваші запитання та дійти до всіх коментарів. Ми архівуємо всі ці веб-трансляції для подальшого перегляду, тому перейдіть онлайн на веб-сайт insideanalysis.com, де ви можете знайти посилання на це. Це повинно бути протягом декількох годин, як правило, після події. І ми наздоженемо вас наступного разу. На наступному тижні у нас є ще пара подій - багато чого відбувається. Але це попрощається, люди. Дякую за ваш час. Піклуватися. Бай-бай.
