- PVSM.RU - https://www.pvsm.ru -
Сегодня в любой компании, относящийся к большому и среднему бизнесу, наличие хранилища данных является де-факто корпоративным стандартом. Неважно, в какой индустрии работает компания, без анализа имеющихся данных о клиентах, поставщиках, финансах, невозможно удерживать конкурентное преимущество. С развитием автоматизации и оптимизации на каждом уровне производства товара или услуги, в организации используется все больше и больше ИТ систем, создающих данные — производственные, бухгалтерские, системы планирования, управления персоналом, и другие.
Как же выстроить процесс создания хранилища данных наиболее эффективно с точки зрения глобальной оптимизации ресурсов предприятия, новых и текущих потребностей бизнеса, и почему ведение метаданных — это важно.
Задачи по использованию накопленных данных наиболее часто используются для следующих классов задач:
Часто для самых насущных целей достаточно использования одного источника — например, если мы говорим о предоставлении регулятору некоторой детализации из определенной системы, или выслать клиенту всю историю его заказов, используя CRM. Даже при смене информационных систем обычно нет сложностей при получении отчетности.
Однако, когда размер организации становится достаточно большим, или же требуется повысить конкурентное преимущество, то уже недостаточно только создать продукт и вывести его на рынок. Современные тенденции — во всестороннем изучении потребителя для повышения его лояльности. Необходимо анализировать бизнес с разных углов и научиться более точно оценивать затраты. Типовые задачи из разряда must have следующие:
В каждом из вышеприведенных примеров требуется использование более одного источника данных. Кроме того, важно, чтобы методы сопоставления данных между источниками были едины. Иначе неизбежно возникнет ситуация, когда в организации, скажем, директор по стратегии и директор по продажам будут приносить генеральному директору одну и ту же информацию, но с разными цифрами. А потом месяц выясняют, кто же был «правее», используя чуть ли не половину имеющегося в их распоряжении персонала.
Самым примитивным способом организации хранилища данных является так называемое «озеро данных» (или data lake), когда мы просто берем и сваливаем в кучу данные из разных источников. В этом случае мы имеем единую техническую платформу для работы с данными и изолируем сложные аналитические запросы от первичных задач информационных систем. Такое хранилище данных может быть вполне себе и нереляционным. Однако в этом случае можно забыть о сложном анализе, и оперировать лишь простыми запросами. Кроме того, люди, работающие с данными, должны быть хорошо осведомлены не только о бизнес-области, но и о моделях данных исходных систем.
Далее по уровню организации хранилища данных следует хранилище, по т.н. классификации Кимбелла (Kimpball). Измерения из разных систем унифицируются, и таким образом, получается что-то вроде сети с двумя типами таблиц — фактов и измерений. Это первичное обогащение справочников, когда мы, используя какой-то общий натуральный ключ в одних и тех же таблицах разных источников, например, ИНН в справочнике организаций, получаем единый справочник.
Следующим по сложности и надежности является хранилище данных с единой моделью данных, отражающей наиболее важные объекты, описывающие деятельность организации. Надежность заключается в том, что данные, будучи представлены в форме, близкой к третьей нормальной, при правильно составленной модели, являются универсальным средством описания жизнедеятельности всего бизнеса, и таким образом, модель данных может быть легко приспособлена не только для аналитической и регуляторной отчетности, но и для работы некоторых систем предприятия.
Говоря о тезисе данной статьи, я перечислю основные проблемы, с которыми сталкиваются лица, ответственные за построение хранилищ данных:
"Конь в вакууме". Хранилище построено, но им никто не пользуется.
"Черный ящик". Хранилище построено, но что в нем есть и как оно работает непонятно. Из-за этого возникают постоянные ошибки, а если еще и уволилась часть команды разработчиков, то как результат, скатываемся в пункт a.
"Калькулятор". Хранилище построено, но оно удовлетворяет только примитивные запросы, бизнес меняется гораздо быстрее, чем реализация требований, новые запросы бизнеса в ней не учтены. К тому же некоторые данные могут быть устаревшими или обновляться достаточно редко.
"Хрустальная ваза". Для хранилища необходимо много ручного контроля, проверок и неавтоматизированных управляющих воздействий, если один из участников поддержки не на работе, есть большой риск получить невалидные данные или не получить их вообще.
Разберем все четыре случая более подробно
«Конь в вакууме». Если вы получили этот результат, то это произошло по одной из двух причин:
В обоих случаях отсутствует элемент взятия ответственности на топ-менеджера и спускании ее вниз по иерархии. Это как с корпоративной культурой. Если у ген. директора предприятия 2 зама, то заставить пользоваться хранилищем на уровне предприятия может только сам ген. дир, или же хранилище строится для части предприятия — той, которую курирует руководитель наивысшей должности, осознающий необходимость внедрения ЕХД.
Для исключения таких ситуаций необходимо следующее:
Только после этого можно приступать к реализации проекта — сбору требований, проектирования архитектуры и т.д.
"Черный ящик". Итак, вы утверждаете, что построили хранилище, что все требования учтены, однако, никто не понимает, как им пользоваться, к тому же если ушел один из ключевых разработчиков, понять, что и как было сделано, становится практически нереально.
В этом случае, очевидно, не был поставлен процесс документирования разработки. Принцип «сначала документирование», потом разработка должен быть возведен если не в Абсолют, то в достаточно жесткий контроль. И не только со стороны команды, ответственной за разработку хранилища данных. В идеале необходимо, чтобы к процессу непрерывной и актуальной документации были подключены дополнительно разработчики отчетности (аналитической, регуляторной), владельцы внутренних информационных систем компании, и, конечно, сами потребители.
Кроме того, процесс документации должен удовлетворять следующим принципам:
Сейчас появляются программные продукты, которые серьезно позволяют упростить жизнь, т.е. связать проектирование и разработку, но пока цельного решения для хранилищ данных еще нет, это:
Без актуальной документации сложность разработки новых требований будет увеличиваться, а при грамотной — сокращаться.
"Калькулятор". Если считать, что мы не получили «коня в вакууме», тогда эта ситуация о том, когда требования вроде бы выполнены, но выполнены они формально. Вы хотели посчитать остатки по дням — пожалуйста. Хотите получить их в разрезе по регионам контрагентов — такого в требованиях не было, вам нужно сделать выгрузку в excel, далее берете из системы X выгрузку по контрагентам с выбором поля Y, и затем ВПР-ите.
Сложившаяся ситуация свидетельствует об отсутствии опыта у команды, без архитектурного взгляда на последующее развитие хранилища, без, даже примитивной, модели данных. Обычно такие хранилища становятся временными, или о них быстро забывают. По-хорошему, хранилище должно обладать силой снежного кома, катящегося с горы. Сначала, когда ком еще небольшой, а впереди рыхлый снег, вам самим с трудом нужно будет его собирать и толкать. В какой-то момент времени слава о вашем продукте будет распространяться, и пользователи будут смотреть в хранилище все чаще.
Итак, чтобы хранилище не оказалось калькулятором, необходимо обеспечить:
"Хрустальная ваза". Хранилище построено, оно вроде бы справляется со своими задачами, но для его поддержки нужна масса усилий: ведение каких-то ручных справочников, постоянная перезагрузка некоторых источников, сбои в загрузке, дублирующиеся данные, и т.д.
Такая ситуация может происходить по следующим причинам:
Для предотвращения данных ситуаций, рекомендуются следующие действия:
Как видно, во всех перечисленных случаях, несмотря на то, что создание хранилища данных — это проектная деятельность, сами процессы по созданию должны быть регламентированы для создания качественного результата.
Как уже было сказано выше, успех проекта по созданию хранилища данных, определяется достаточно многими входными данными (бюджет, спонсор, команда, цели, заказчики). Однако мы практически не касались бизнес-процессов, которые направлены на развитие и поддержание самого ХД. Ниже я попробую сформулировать основные бизнес-процессы, которые и призваны сделать процессы работы с данными на предприятии действительно едиными:
В современной парадигме данная совокупность бизнес-процессов составляет основу концепции Data Governance.
Очень часто при попытке внедрить эти процессы силами команды по созданию ХД и отчетности будет предпринято активное сопротивление, или же игнорирование процессов. Оно и понятно, ведь в локальном смысле это удлинение разработки.
Поэтому полезным будет предпринять следующие действия:
Несмотря на то, что в локальном смысле процесс перехода кажется значительно «обюрократизированным» и тяжеловесным, в глобальном смысле это дает существенные плюсы и экономию времени. Так как основные потери времени — при изобретении с нуля уже существующих решений ввиду невозможности или отсутствия желания разобраться в существующем механизме.
Несмотря на то, что архитектура ЕХД тянет на отдельную большую статью, или даже книгу, обозначу также основные технические требования к зрелому хранилищу данных:
Как итог, хранилище данных нарекается единым не по наличию источников, а по наличию потребителей данных. А это гораздо сложнее, чем написать универсальный ETL и подогнать петабайты памяти.
Автор: RussianKeeper
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/metadanny-e/287285
Ссылки в тексте:
[1] Источник: https://habr.com/post/418361/?utm_campaign=418361
Нажмите здесь для печати.