Почему Е в аббревиатуре ЕХД — это про бизнес-процессы

Хранилище данных без Е

Сегодня в любой компании, относящийся к большому и среднему бизнесу, наличие хранилища данных является де-факто корпоративным стандартом. Неважно, в какой индустрии работает компания, без анализа имеющихся данных о клиентах, поставщиках, финансах, невозможно удерживать конкурентное преимущество. С развитием автоматизации и оптимизации на каждом уровне производства товара или услуги, в организации используется все больше и больше ИТ систем, создающих данные — производственные, бухгалтерские, системы планирования, управления персоналом, и другие.

Как же выстроить процесс создания хранилища данных наиболее эффективно с точки зрения глобальной оптимизации ресурсов предприятия, новых и текущих потребностей бизнеса, и почему ведение метаданных — это важно.

Задачи по использованию накопленных данных наиболее часто используются для следующих классов задач:

• регуляторная отчетность
• финансовый учет
• планирование и контроль
• бюджетирование
• анализ клиентской базы
• риск-менеджмент

Часто для самых насущных целей достаточно использования одного источника — например, если мы говорим о предоставлении регулятору некоторой детализации из определенной системы, или выслать клиенту всю историю его заказов, используя CRM. Даже при смене информационных систем обычно нет сложностей при получении отчетности.

Способы и виды хранилищ данных

Однако, когда размер организации становится достаточно большим, или же требуется повысить конкурентное преимущество, то уже недостаточно только создать продукт и вывести его на рынок. Современные тенденции — во всестороннем изучении потребителя для повышения его лояльности. Необходимо анализировать бизнес с разных углов и научиться более точно оценивать затраты. Типовые задачи из разряда must have следующие:

• как аллоцировать расходы по бизнес-добывающим подразделениям
• Как прогнозировать спрос в зависимости от внутренних или внешних факторов
• Как управлять риском в финансовых и страховых организациях
• Как повысить средний чек клиента (таргетинг)

В каждом из вышеприведенных примеров требуется использование более одного источника данных. Кроме того, важно, чтобы методы сопоставления данных между источниками были едины. Иначе неизбежно возникнет ситуация, когда в организации, скажем, директор по стратегии и директор по продажам будут приносить генеральному директору одну и ту же информацию, но с разными цифрами. А потом месяц выясняют, кто же был «правее», используя чуть ли не половину имеющегося в их распоряжении персонала.

Самым примитивным способом организации хранилища данных является так называемое «озеро данных» (или data lake), когда мы просто берем и сваливаем в кучу данные из разных источников. В этом случае мы имеем единую техническую платформу для работы с данными и изолируем сложные аналитические запросы от первичных задач информационных систем. Такое хранилище данных может быть вполне себе и нереляционным. Однако в этом случае можно забыть о сложном анализе, и оперировать лишь простыми запросами. Кроме того, люди, работающие с данными, должны быть хорошо осведомлены не только о бизнес-области, но и о моделях данных исходных систем.

Далее по уровню организации хранилища данных следует хранилище, по т.н. классификации Кимбелла (Kimpball). Измерения из разных систем унифицируются, и таким образом, получается что-то вроде сети с двумя типами таблиц — фактов и измерений. Это первичное обогащение справочников, когда мы, используя какой-то общий натуральный ключ в одних и тех же таблицах разных источников, например, ИНН в справочнике организаций, получаем единый справочник.

Следующим по сложности и надежности является хранилище данных с единой моделью данных, отражающей наиболее важные объекты, описывающие деятельность организации. Надежность заключается в том, что данные, будучи представлены в форме, близкой к третьей нормальной, при правильно составленной модели, являются универсальным средством описания жизнедеятельности всего бизнеса, и таким образом, модель данных может быть легко приспособлена не только для аналитической и регуляторной отчетности, но и для работы некоторых систем предприятия.

Е — Единое

Говоря о тезисе данной статьи, я перечислю основные проблемы, с которыми сталкиваются лица, ответственные за построение хранилищ данных:

"Конь в вакууме". Хранилище построено, но им никто не пользуется.

"Черный ящик". Хранилище построено, но что в нем есть и как оно работает непонятно. Из-за этого возникают постоянные ошибки, а если еще и уволилась часть команды разработчиков, то как результат, скатываемся в пункт a.

"Калькулятор". Хранилище построено, но оно удовлетворяет только примитивные запросы, бизнес меняется гораздо быстрее, чем реализация требований, новые запросы бизнеса в ней не учтены. К тому же некоторые данные могут быть устаревшими или обновляться достаточно редко.

"Хрустальная ваза". Для хранилища необходимо много ручного контроля, проверок и неавтоматизированных управляющих воздействий, если один из участников поддержки не на работе, есть большой риск получить невалидные данные или не получить их вообще.

Разберем все четыре случая более подробно

«Конь в вакууме». Если вы получили этот результат, то это произошло по одной из двух причин:

1. Менее вероятно. Вами не были собраны требования от бизнес-подразделений (или, что — то же самое, они были плохо проработаны). Такая, казалось бы, абсурдная ситуация возникает, если идея создания хранилища идет не от бизнеса, а от ИТ подразделения, у которого просто есть «лишний» бюджет, а хранилище — задумывалось потому, что оно есть у всех. Заказчиков вроде как потом найдем (еще лучше вариант «сами прибегут с протянутыми руками») — если все туда уложим. Лица, ответственные за выделение бюджета, считают это чем-то необходимым, в книжках читали, слыхали, ну вроде это как модернизация, и согласно кивают.
2. Более вероятно. Определены заказчики хранилища данных, допустим, это департамент по продажам, и тут приходит светлая идея: «а давайте сделаем еще небольшое усилие дельта, загоним в него финансы, кадры и еще чуть-чуть и хранилищем будет пользоваться все предприятие». Хранилище построено, но им пользуется только департамент продаж, хотя там все красиво, и молочные береги — бери не хочу, но нет, времени на кисельные берега у коллег нет, им нужно скорее в шахту, с утра до ночи долбить кусочек данных. Ведь это кусочек, добытый потом и кровью (читай: потраченным рабочим временем).

В обоих случаях отсутствует элемент взятия ответственности на топ-менеджера и спускании ее вниз по иерархии. Это как с корпоративной культурой. Если у ген. директора предприятия 2 зама, то заставить пользоваться хранилищем на уровне предприятия может только сам ген. дир, или же хранилище строится для части предприятия — той, которую курирует руководитель наивысшей должности, осознающий необходимость внедрения ЕХД.

Для исключения таких ситуаций необходимо следующее:

1. Определить формально спонсора проекта хранилища данных — кто будет отвечать за результат и финансово, и духовно
2. Утвердить скоуп проекта, возможно, этапность, обозначить приблизительные сроки
3. Согласовать со всеми подразделениями — желательно, с построением бизнес-процессов as is и to be

Только после этого можно приступать к реализации проекта — сбору требований, проектирования архитектуры и т.д.

"Черный ящик". Итак, вы утверждаете, что построили хранилище, что все требования учтены, однако, никто не понимает, как им пользоваться, к тому же если ушел один из ключевых разработчиков, понять, что и как было сделано, становится практически нереально.

В этом случае, очевидно, не был поставлен процесс документирования разработки. Принцип «сначала документирование», потом разработка должен быть возведен если не в Абсолют, то в достаточно жесткий контроль. И не только со стороны команды, ответственной за разработку хранилища данных. В идеале необходимо, чтобы к процессу непрерывной и актуальной документации были подключены дополнительно разработчики отчетности (аналитической, регуляторной), владельцы внутренних информационных систем компании, и, конечно, сами потребители.

Кроме того, процесс документации должен удовлетворять следующим принципам:

• Актуальность — текущее состояние программного кода полностью определено составом документации
• Версионность — возможность анализировать документацию прошлых релизов и планировать модификации на будущие релизы
• Разделяемость — над документом могут работать одновременно несколько человек
• Применимость. Тут говорится о том, что для каждого вида документации хранилища важно подобрать такую структуру, которая будет лучше всего восприниматься целевыми пользователями: так, структуру таблиц лучше описывать в табличной форме, бизнес-процессы в виде нотаций, взаимодействие между информационными системами в виде диаграммы, бизнес-словарь в виде вики-системы, и т.д.

Сейчас появляются программные продукты, которые серьезно позволяют упростить жизнь, т.е. связать проектирование и разработку, но пока цельного решения для хранилищ данных еще нет, это:

• ER-диаграммы
• BPMN-продукты
• ETL-решения

Без актуальной документации сложность разработки новых требований будет увеличиваться, а при грамотной — сокращаться.

"Калькулятор". Если считать, что мы не получили «коня в вакууме», тогда эта ситуация о том, когда требования вроде бы выполнены, но выполнены они формально. Вы хотели посчитать остатки по дням — пожалуйста. Хотите получить их в разрезе по регионам контрагентов — такого в требованиях не было, вам нужно сделать выгрузку в excel, далее берете из системы X выгрузку по контрагентам с выбором поля Y, и затем ВПР-ите.

Сложившаяся ситуация свидетельствует об отсутствии опыта у команды, без архитектурного взгляда на последующее развитие хранилища, без, даже примитивной, модели данных. Обычно такие хранилища становятся временными, или о них быстро забывают. По-хорошему, хранилище должно обладать силой снежного кома, катящегося с горы. Сначала, когда ком еще небольшой, а впереди рыхлый снег, вам самим с трудом нужно будет его собирать и толкать. В какой-то момент времени слава о вашем продукте будет распространяться, и пользователи будут смотреть в хранилище все чаще.

Итак, чтобы хранилище не оказалось калькулятором, необходимо обеспечить:

1. квалифицированные кадры — архитекторы, аналитики, разработчики EtL и SQL
2. Устав проекта, в котором будут обозначены цели хранилища не только на ближайший бюджетный период, но и на последующие годы
3. Количественные и качественные критерии хранилища данных. Если не хватает своих кадров, рекомендуется привлечь консультантов
4. Четко представлять себе, что поможет оптимизировать хранилище данных в дальнейшем — расходы на персонал, ПО, увеличить скорость разработки отчетов и т.д.

"Хрустальная ваза". Хранилище построено, оно вроде бы справляется со своими задачами, но для его поддержки нужна масса усилий: ведение каких-то ручных справочников, постоянная перезагрузка некоторых источников, сбои в загрузке, дублирующиеся данные, и т.д.

Такая ситуация может происходить по следующим причинам:

1. О ней уже было сказано выше — недостаток квалифицированных кадров;
2. Безархитекутрная концепция — когда разные части хранилища делаются разными людьми или командами без общей утвержденной концепциии, в результате имеем множественные способы извлечения, трансформации и загрузки данных;
3. Очень частая ситуация — «аутсорсим разработку», поддержка своя, при этом приемка работ сделана плохо
4. На каком-то этапе развития хранилища «бюджет кончился». И далее хранилище дорабатывает (поддерживает) не та команда, которая создавала, а те, кому нужны данные

Для предотвращения данных ситуаций, рекомендуются следующие действия:

1. Сказанное в пунктах выше — квалифицированные кадры, устав проекта, долгосрочный план и бюджет, заинтересованное лицо из топ-менеджера.
2. Не аутсорс руководит процессом, а внутренний сотрудник (главный аналитик или архитектор) руководит аутсорсом.
3. Любые сбойные ситуации должны выноситься на собрания на рассмотрения архитектору хранилища. Если архитекторов несколько, то на архитектурный комитет.
4. Желательно ввести метрику качества хранилища данных, можно использовать эту метрику для привязки к KPI команды.

Как видно, во всех перечисленных случаях, несмотря на то, что создание хранилища данных — это проектная деятельность, сами процессы по созданию должны быть регламентированы для создания качественного результата.

Переход от хранилища данных к единому

Как уже было сказано выше, успех проекта по созданию хранилища данных, определяется достаточно многими входными данными (бюджет, спонсор, команда, цели, заказчики). Однако мы практически не касались бизнес-процессов, которые направлены на развитие и поддержание самого ХД. Ниже я попробую сформулировать основные бизнес-процессы, которые и призваны сделать процессы работы с данными на предприятии действительно едиными:

1. Процессы поддержания технической и пользовательской документации в актуальном состоянии
2. Процессы ведения в актуальном состоянии бизнес-словаря (глоссария) данных
3. Процессы контроля качества данных
4. Процессы сбора и управления требованиями к ХД и системе отчетности
5. Процессы управления инфраструктурой хранения и обработки данных
6. Процессы оптимизации хранения и сбора данных

В современной парадигме данная совокупность бизнес-процессов составляет основу концепции Data Governance.

Очень часто при попытке внедрить эти процессы силами команды по созданию ХД и отчетности будет предпринято активное сопротивление, или же игнорирование процессов. Оно и понятно, ведь в локальном смысле это удлинение разработки.

Поэтому полезным будет предпринять следующие действия:

• Введение горизонтальной структуры ответственности (каждый участник может отвечать за небольшую область)
• Изображение в графическом виде всех возможных workflow для всех сотрудников (формализация процесса)
• Внедрение в систему KPI процент и качество выполнения ответственности

Несмотря на то, что в локальном смысле процесс перехода кажется значительно «обюрократизированным» и тяжеловесным, в глобальном смысле это дает существенные плюсы и экономию времени. Так как основные потери времени — при изобретении с нуля уже существующих решений ввиду невозможности или отсутствия желания разобраться в существующем механизме.

Немного о целевом архитектурном решении

Несмотря на то, что архитектура ЕХД тянет на отдельную большую статью, или даже книгу, обозначу также основные технические требования к зрелому хранилищу данных:

1. Парадигма data lake не заменяет корпоративных хранилищ данных, а сосуществует с ним вместе
2. ЕХД должно иметь различные интерфейсы предоставления данных: средства bi, возможность выполнения ad-hoc sql запросов, стандартное предоставление данных в форматах json, xml и т.д.
3. Должна быть реализована ролевая модель доступа к данным
4. Скорость отклика при обращении к данным: 90% типовых запросов — менее 1 секунды, 99% запросов — менее 10 секунд. Должен быть достаточно хороший запас по ресурсам
5. Наличие единого и связного центрального слоя ХД (предпочтительно — Inmon методология)

Как итог, хранилище данных нарекается единым не по наличию источников, а по наличию потребителей данных. А это гораздо сложнее, чем написать универсальный ETL и подогнать петабайты памяти.

Автор: RussianKeeper

Источник