- 26 октября 2012 г.
ETL и обеспечение качества данных
В статье обсуждается, на каком этапе ETL-процесса следует выполнять
исправление данных.
Вездесущий разрыв, обычно, между предоставленными IT-отделом проверенными данными и проектами по трансформации процессов, которые, как правило, инициируют бизнес-руководители компаний – это симптом распространения разрозненных источников данных среди их ключевых потребителей из ИТ- и бизнес-отделов. В случае использования недостоверных данных бизнес-процессы могут «пойти вразнос», а инициативы по повышению качества данных не принесут пользы, если данные не используются в наиболее критичных для организации решениях и бизнес-процессах. Опрос, проведённый в ноябре 2011 года компанией Forester Consulting, показал, что 38% опрошенных считают качество данных своей организации «узким местом», и только менее половины (48%) вполне им удовлетворены.
Низкое качество данных – это «узкое место» совершенствования бизнес-процессов
В ходе опроса была поставлена цель определить, как организации используют решения для обеспечения качества данных для улучшения собственных бизнес-процессов и результатов деятельности. Исследование показало, что вопросы качества данных, а также инвестиции в программы по его улучшению – это задачи высочайшей важности. Так, 85% респондентов указали, что это - важная часть их бизнеса в целом. Подобная реакция свидетельствует, что мероприятия по повышению качества данных, наконец, эволюционировали до уровня стратегических инициатив, обладающих наивысшим приоритетом и уровнем финансирования.
Итак, одна из сложнейших задач, стоящих перед компаниями – это расставить приоритеты для применения средств и ресурсов, направленных на улучшение качества данных.
Среди вопросов исследования было определение основных процессов и функций, наиболее «страдающих» от низкого качества данных. 55% опрошенных сообщили, что повысить эффективность операционных процессов, охватывающих несколько функциональных подразделений, невозможно без улучшения качества данных. На втором месте находятся процессы, связанные с обслуживанием клиентов и финансами (45% респондентов), а на третьем - с CRM (40% респондентов). Интересно, что маркетинговые процессы в наименьшей степени зависят от всех прочих – так утверждают 30% опрошенных. Фактически, прямой маркетинг - это один из самых популярных и традиционных «адресатов» программ по улучшению качества данных. Маркетологи многие годы делали серьёзные вложения, очищая, выверяя и обогащая клиентские данные с целью снижения маркетинговых затрат и формирования «единого клиента» для проведения фокусных кампаний и промо-акций.
Поскольку перечисленные в исследовании функциональные процессы не являются взаимоисключающими, вполне вероятно, что некоторые респонденты ассоциировали свои стратегические маркетинговые мероприятия с «CRM» и процессами обслуживания клиентов, используя «маркетинговую» обратную связь, чтобы сфокусироваться на прямом маркетинге и прочих тактических усилиях.
Эта относительно низкая позиция маркетинговых процессов также может быть признаком того, что финансовый риск кампании, основанной на некачественных данных, потенциально ценных для неё, намного меньше по сравнению с прочими сбоями, в результате которых финансовые, нормативные и пользовательские вопросы могут серьёзно повлиять на бизнес в целом.
Респондентов опросили, какие методы были использованы для решения проблем качества данных в рамках конкретных ключевых процессов. Ответы показали, что организации прибегали к различным подходам в зависимости от конкретной ситуации. Например, для улучшения качества данных, используемых в реализации финансовой функции, в компаниях в первую очередь вводятся программы управления корпоративными данными для определения стандартов, правил и политик качества (так заявили 53% опрошенных). Второе место - занимает согласование бизнес-процессов и проектов по управлению данными (43% опрошенных), третье – внедрение инструментов очистки и проверки, у также управления НСИ (32% опрошенных).
Качество данных и ETL-процессы
Касательно практических аспектов, следует заметить, что время от времени при выполнении ETL-процессов на первый план выходят проблемы с качеством данных. Зачастую выбор стоит между исправлением некорректных данных в источнике или в ходе выполнения ETL-процесса. По мнению Саймона Макалистера (Simon McAlister), эксперта построения хранилищ данных, первый подход является «золотым стандартом», так как позволяет не только исправлять данные сами по себе, но и воздействовать на причины возникновения проблем, будь то процесс, стандарты или технические ошибки. К решению проблем в источнике данных стоит стремиться по следующим причинам.
Проблемы остаются решёнными
Устранение ошибок в данных в источнике предотвращает повторное возникновение похожей или смежной неисправности. Одноразовое исправление в хранилище данных не гарантирует того, что неверные данные не будут перезагружены или повторно внесены в будущем. Достаточно исправить проблему исходных данных, и она останется решённой.
Проблемы решаются для всей организации
Если проблема исправлена в источнике данных, она решена не только для хранилища, она устранена для исходной системы и всех пользователей данных. Никогда не стоит недооценивать негативный эффект, оказываемый проблемными данными. Если представить себе паутину с большим количеством связанных нитей, которые исходят из центра - это будет хорошей иллюстрацией того, как проблемы качества данных проходят сквозь всю организацию. Повышение качества данных непосредственно в источнике обеспечит преимущество последовательного и правильного представления данных.
Как правило, это дешевле
Иногда, кажется, что проще исправить ошибку в хранилище, но первое впечатление обманчиво. Стоит иметь в виду следующее выражение: «Если хочется быстрого, пусть и некачественного решения, можно гарантировать низкое качество, причём не быстро». Одним из примеров скрытых трат является согласование источника данных и целевой архитектуры.
Реальность такова, что иногда необходимо прибегать к исправлениям в хранилище данных. Исходная причина может быть связана с внешними системами, контролировать которые сложно. Может потребоваться достаточно много времени, чтобы согласовать эти исправления. Существует несколько шагов, позволяющих обеспечить их максимальную эффективность:
Эскалация проблемы
Следует убедиться, что к проблеме привлечено внимание, и другие пользователи оповещены об её возникновении. Ответственные за причину, должны быть осведомлены – это, по крайней мере, позволит не увеличить степень ее влияния. Иногда простого привлечения внимания достаточно, чтобы запустить процесс решения проблемы.
Локализация исправления
Необходимо минимизировать лавинный эффект ошибки. Когда основная проблема решена, довольно просто удалить временное решение.
Отслеживание проблемы
Процесс устранения первопричины требует постоянного контроля. Не стоит сбрасывать проблему со счетов, только потому, что на данный момент симптомы исчезли.
Противоположной точки зрения по вопросу, где следует производить повышение качества данных, придерживается Вивек Прадхан (Vivek Pradhan), ведущий консультант в области построения систем бизнес-анализу и хранилищ данных. По его оценке, причины возникновения проблем качества данных в источниках следует искать в соответствующих бизнес-процессах – так считает. Эти процессы, как правило, построены «вокруг» этих данных. Внесение изменений в операционные системы с целью исправления данных в источнике может оказаться очень «болезненным».
В качестве решения Вивек Прадхан рекомендует подход, предполагающий, что хранилища данных можно использовать для улучшения качества данных, извлечённых из источников. В случае применения модели данных, независящей от источника данных и обслуживаемых им бизнес-процессов (типичный подход Инмона), очистка, стандартизация и исправление данных в обязательном порядке возлагается на хранилища данных.
Публикации
- Современные тенденции в области согласования качества данных и бизнес-процессов (Trends In Data Quality And Business Process Alignment). Ноябрь 2011 г.
- Саймон МакАлистер. Качество данных – к золотым стандартам (Simon McAlister, Data Quality – Go for Gold). Июль 2012 г.
Автор: По материалам зарубежных сайтов