hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

2.4 Проведение первичной оценки качества данных

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

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

Определение целей, стимулов и направлений работы.

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

Выявление областей применения и основных потребителей данных.

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

Проверка данных на соответствие действующим и предлагаемым правилам.

Документирование уровней несоответствия и типов проблем.

Повторный углубленный анализ на основе первичных заключений с целью:

количественной оценки выявленных проблем;

приоритизации проблем по степени негативного влияния на бизнес;

проработки гипотез относительно корневых причин проблем с данными.

596	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Согласование приоритетов с руководством, экспертами и потребителями данных.

Планирование первоочередных мер на основе полученных заключений.

Устранение выявленных проблем, в идеале вместе с корневыми причинами.

Меры по совершенствованию процессов с целью профилактики рецидивов.

Механизмы текущего контроля и учета.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

2.5 Выявление и приоритизация потенциальных улучшений

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

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

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

2.6 Определение целей повышения качества данных

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

Качество данных

597

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

Например, целью ставится повышение показателя числа профилей клиентов с полными дан ными с 90% до 95% за счет совершенствования процессов и внесения изменений в конфигураци онные настройки системы. Понятно, что для подтверждения улучшения ситуации требуется все го лишь сравнение исходных показателей полноты данных с текущими. А вот для доказательства реальной ценности наличия полных данных о клиентах полезна статистика иного рода: снижение числа жалоб/претензий, ускорение обработки заявок и т. п. Регистрируйте подобные показате ли — и проще будет объяснить ценность усилий, направленных на повышение качества данных. Никому в руководстве нет дела до полноты и точности заполнения полей, если нет понимания, что неполнота и неточность приносят убытки. Иными словами, инвестиции в качество данных должны окупаться. Поэтому при выявлении проблем первым делом озаботьтесь обоснованием окупаемости затрат на их устранение с учетом следующих факторов:

критичность (значимость, приоритетность) данных, затрагиваемых проблемой;

объемы (доля) проблемных данных;

период датирования (период) проблемных данных;

число и тип бизнес-процессов, использующих проблемные данные;

число клиентов, поставщиков, сотрудников и т. п., затрагиваемых проблемой;

риски, проистекающие из проблемы;

затраты на устранение корневых причин;

затраты на потенциальные временные решения.

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

598	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

2.7 Разработка и внедрение операционных процедур обеспечения качества данных

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

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

2.7.1 Управление правилами качества данных

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

четко определять качественные характеристики данных;

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

формулировать требования к качеству данных поставщиков и третьих сторон;

обосновывать измеримые показатели качества данных в системах мониторинга и отчетности.

Строго говоря, правила и стандарты качества данных — это критически важная категория ме таданных. Следовательно, для эффективного управления стандартами и правилами необходимо обеспечивать соблюдение, по сути, тех же требований, которые предъявляются к управлению метаданными (см. главу 12). Сами же правила должны соответствовать следующим требованиям.

Согласованное документирование. Определите и утвердите стандарты и шаблоны докумен тации правил, чтобы все они были представлены в одном и том же формате и не допускали смысловых разночтений.

Определение в терминах измерений качества данных. Измерения качества (см. раздел 1.3.3) помогают людям понимать, что именно оценивается. Согласованное использование измере ний способствует эффективной оценке и решению возникших проблем.

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

Качество данных

599

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

указанием на их роль в обеспечении успешной работы организации. Показатели, не связан

ные с бизнес-процессами, не стоят того, чтобы их оценивать.

Подтверждение результатами анализа данных. Аналитики качества данных не должны определять правила на основе догадок. Все правила подлежат предварительному тестирова нию на реальных данных. Во многих случаях правила помогают выявлять проблемы с данны ми. Но бывает и так, что анализ результатов тестирования правил показывает непригодность или неполноту самих правил.

Подтверждение экспертами в предметных областях. Цель правил — описать, как долж ны выглядеть данные. Зачастую, не зная деталей реализации рабочих процессов изнутри организации или подразделения, судить о корректности применения правил к предмету, описываемому данными, и, как следствие, к самим данным весьма затруднительно, и лучше проконсультироваться с экспертами в предметных областях, которые либо подтвердят годность правил, либо разъяснят аналитикам истинный смысл полученных ими результатов.

Доступность всем потребителям данных. Все потребители данных должны иметь доступ ко всем задокументированным правилам, применимым к этим данным. Это нужно и для луч шего понимания данных пользователями, и для обеспечения полноты их применения, и для выявления возможных противоречий или неполноты самих правил. Кроме того, у потреби телей данных должна иметься возможность получать разъяснения точного смысла и порядка применения правил и оставлять отзывы и предложения.

2.7.2 Измерение и мониторинг показателей качества данных

Операционные процедуры управления качеством данных основаны на возможности измерения и мониторинга текущих показателей качества. Организация измерения и мониторинга нужна по двум одинаково важным причинам:

необходимость информирования потребителей данных об уровне их качества;

необходимость управления информационными рисками, обусловленными изменениями в бизнес-процессах и технологических процессах.

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

600	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

автоматически.

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

ректных данных, например:

ПригодныеДанные (r) =	(ПровереноЗаписей (r) – ОтбракованоЗаписей (r))
		× 100%
	ПровереноЗаписей (r)

ОтбракованоЗаписей (r)

НепригодныеДанные (r) = × 100% , ПровереноЗаписей (r)

где r — правило проверки. Например, если по результатам проверки 10 000 записей на предмет соблюдения бизнес-правила r выявлено 560 записей, не соответствующих r, то в рассматривае мом примере мы получим результаты: ПригодныеДанные (r) = 9440/10 000 = 94,4%, Непригодные Данные (r) = 560/10 000 = 5,6%.

Табличное представление определений и результатов измерений показателей качества дан ных, подобное приведенному в примере (см. табл. 30), помогает встраивать различные метрики и индикаторы качества в отчеты, получать сводные показатели и пояснять важные для пони мания моменты. Отчет может носить более формализованный характер, если адресован про ектам, отвечающим за устранение выявленных проблем. Отфильтрованные отчеты могут быть полезны распорядителям данных или бизнес-аналитикам, выявляющим тенденции и факторы влияния. Таблица 30 содержит примеры правил, сконструированных подобным образом. Там, где это применимо и уместно, результаты могут приводиться в двух выражениях — позитив ном (% данных, соответствующих правилам и ожиданиям) и негативном (% данных, не соот ветствующих правилам).

Качество данных

601

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Таблица 30. Примеры метрик качества данных

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

	Измерение	Замеры	Метрики	Индикатор статуса
	и бизнес-правило
	Полнота	Доля записей	Результат деления числа записей	Неприемлемо:
	Бизнес-правило	с заполненными	с заполненными обязательными полями	соблюдение < 80%
	1: заполнение	обязательными полями от	на общее число записей в таблице или базе	несоблюдение > 20%
	обязательных полей	общего числа записей	данных, умноженный на 100 для перевода
			в процентное выражение
	Пример 1:	Заполнено: 700 000	Соблюдение (%):	Результат в примере:
	заполнение поля Индекс	Не заполнено: 300 000	700 000/1 000 000 × 100% = 70%	неприемлемо
	в таблице почтовых	Итого: 1 000 000	Несоблюдение (%):
	адресов		300 000/1 000 000 × 100% = 30%
	Уникальность	Доля записей в таблице,	Результат деления числа записей с дубликатами,	Неприемлемо: > 0%
	Бизнес-правило 2:	у которых выявлен хотя бы	умноженный на 100 для перевода в процентное
	каждый экземпляр	один дубликат	выражение
	объекта должен быть
	представлен в таблице
	единственной записью
	Пример 2:	Записей с дубликатами:	10 000/1 000 000 × 100 = 1,0% почтовых	Результат в примере:
	в справочном списке	10 000	индексов представлены в двух и более строках	неприемлемо
	Почтовые индексы	Всего записей: 1 000 000
	каждый индекс должен
	быть представлен одной
	и только одной записью
	Актуальность	Доля транзакций,	Число не завершенных в срок транзакций,	Неприемлемо:
	Бизнес-правило 3:	не отражаемых как	отнесенное к числу попыток завершения	соблюдение < 99%
	записи должны	завершенные из-за	транзакций, умноженное на 100 для перевода	несоблюдение > 1%
	обновляться	невозможности получить	в процентное выражение
	в установленные сроки	обновленные данные от
		службы синхронизации
	Пример 3:	Незавершенных	Соблюдено:	Результат в примере:
	запись о завершении	транзакций: 2000	(1 000 000 – 2000) / 1 000 000 × 100 = 99,8%	приемлемо
	биржевой транзакции	Попыток завершения	записей о завершении транзакций поступило
	должна поступать не	транзакций: 1 000 000	в срок
	позднее 5 минут после		Не соблюдено:
	транзакции		2000/1 000 000 × 100 = 0,20% записей
			о завершении транзакций поступило в срок
	Допустимость	Доля записей, где правило	Отношение числа записей, где правило	Неприемлемо:
	Бизнес-правило 4: если	соблюдено	соблюдено к общему числу записей со	< 100%
	значение в поле X =		значением X = V1, умноженное на 100 для
	V1, значение в поле Y		перевода в процентное выражение
	должно = V1’

602	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

	Измерение	Замеры	Метрики	Индикатор статуса
	и бизнес-правило
	Пример 4:	Число записей с кодами	Соблюдено:	Результат в примере:
	счета выставляются при	статусов отгружено = да	999 000/1 000 000 × 100 = 99,9%	неприемлемо
	отгрузке товара	И счет = да: 999 000	Не соблюдено:
		Число записей с кодами	(1 000 000 – 999 000)/1 000 000 × 100 = 0,10%
		статусов отгружено = да	записей содержат только отметку об отгрузке
		ИЛИ счет = да: 1 000 000	товара или выставлении счета, что является
			нарушением правила

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

Обеспечивайте непрерывный мониторинг всех потоков данных посредством включения в них промежуточных процессов оперативного контроля и измерения параметров качества. Автоматизи рованный мониторинг соответствия данных правилам качества можно проводить как в процессе потоковой передачи (обработка в потоке), так и с помощью пакетной обработки данных. Измере ния могут вестись на трех уровнях детализации данных: значений элементов или полей; экземпля ров сущностей или табличных записей; наборов данных. Таблица 31 описывает основные методы сбора информации о результатах измерения характеристик данных. Обработка в потоке обычно используется для проверки качества при создании данных или при их перемещении от одной фазы обработки к другой, а пакетная — для проверки массивов данных, накопленных в файлах или таб лицах баз данных, перед их интеграцией в хранилище. Для массивов данных методы обработки в потоке, как правило, не подходят, поскольку из-за необходимости проверки соблюдения правил, касающихся статистических параметров, требуется обработка сразу всего массива.

Таблица 31. Методы мониторинга качества данных

Уровень детализации	Обработка в потоке	Пакетная обработка
Элемент/Поле	Проверка ввода/изменений в приложениях	Прямые запросы
	Службы валидации значений данных	Средства профилирования и/или анализа данных
	Специальные программируемые приложения
Экземпляр/	Проверка ввода/изменений в приложениях	Прямые запросы
Запись	Службы валидации записей данных	Средства профилирования и/или анализа данных
	Специальные программируемые приложения
Набор/Массив	Средства проверки при передаче данных из процесса	Прямые запросы
	в процесс (между стадиями обработки)	Средства профилирования и/или анализа данных

Качество данных

603

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

2.7.3 Разработка операционных процедур выявления и устранения проблемных вопросов

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

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

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

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

оценивает, не было ли возникновение проблем с качеством данных обусловлено вмешатель ством сторонних факторов — например, сбоев в работе смежных систем или процессов;

определяет, не является ли проблема прямым следствием получения некондиционных дан ных из внешних источников.

ВАЖНО: к выявлению и анализу корневых причин должны привлекаться эксперты в пред метных областях как из технических, так и из бизнес-подразделений. Команда качества данных должна координировать совместную работу, но конечный успех зависит от сла женности взаимодействия между всеми функциональными подразделениями.

Формулировка перечня возможных корректирующих мероприятий: в зависимости от ре

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

устранение нетехнических корневых причин (слабостей в подготовке и руководстве, не четкого распределения обязанностей и полномочий и т. п.);

изменение ИТ-систем с целью устранения корневых причин технического характера;

доработку средств и механизмов контроля во избежание рецидивов;

введение дополнительных проверок и средств мониторинга;

прямую корректировку ошибочных данных;

604	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

сравнительная оценка альтернативных вариантов по критериям эффективности и/или по лезности затрат;

выбор, доработка и рекомендация оптимального варианта;

выработка и предоставление плана реализации решения;

реализация принятого решения, включая внедрение необходимых доработок.

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

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

Данные отслеживания инцидентов полезны и для потребителей информации. Располагая ис правленными данными и зная о внесении исправлений, можно принимать ответственные реше ния без опасения, — напротив, с осознанием того, что ошибки устранены, а данные исправлены, и с полным пониманием того, как именно всё это было сделано. Одно это служит веской причи ной для документирования методов изменения правил учета данных и обоснований изменений. Такая документация должна быть доступна не только потребителям данных, но и разработчи кам программного обеспечения, чтобы у них была возможность учитывать полученные уроки при разработке кодов будущих продуктов. Тем, кто реализует изменения, их необходимость бы вает очевидной, но историю изменений вести нужно всё равно, хотя бы ради того, чтобы она не изгладилась из памяти и оставалась доступной будущим поколениям потребителей данных. Отслеживание инцидентов с качеством данных требует от сотрудников навыков классифика ции, регистрации и мониторинга; при необходимости можно предусмотреть дополнительную

Качество данных

605

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

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

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

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

2.7.4 Определение соглашений об уровне обслуживания в области качества данных

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

606	Г Л А В А 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

элементы данных, подпадающие под действие соглашения;

последствия ошибок и сбоев в данных для бизнеса;

измерения качества, соответствующие каждому элементу данных;

ожидаемые показатели качества каждого элемента по установленным для него параметрам в каждом приложении или системе в цепи прохождения данных по бизнес-процессам;

методы измерения ожидаемых показателей;

пороги допустимых отклонений по каждому измеримому показателю;

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

временные графики и крайние сроки устранения или исправления проблем;

стратегия передачи решений проблем на высший уровень руководства;

премирование/штрафы.

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

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

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

Качество данных

607