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

Дефекты данных

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

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

Очистка данных в системе-источнике

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

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

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

«Хозяева» данных из сферы бизнеса

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

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

ФЕДЕРАЛИЗОВАННЫЙ ПОДХОД

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

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

Дата добавления: 2015-04-29