Про гармонизацию, оказывается, много говаривали классики. «Когда в товарищах согласья нет, на лад их дело не пойдёт», — заявлял один. «Согласие есть продукт непротивления сторон», — вторил ему другой. Однако они говорили про человеческое согласие, оно же «гармонизация отношений». А вот про гармонизацию данных почему-то не писали. Поэтому придётся нам.

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

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

Классика жанра

Гармонизация данных действительно чаще всего упоминается в примере, в котором есть две компании и они сливаются. В этом примере фирмы оказываются в ситуации, когда у них на руках несколько ERP-систем и много баз данных, часто используемых по-разному. В такой ситуации очевидно — ни одна из существующих систем не соответствует бизнеспроцессам новой фирмы. А значит, есть необходимость хотя бы часть всего этого хозяйства свести под одну крышу. Раз одна из них купила другую, то, вероятнее всего, у них одна и та же сфера деятельности и, скорее всего, много одинаковых клиентов. Но у одной клиент может быть записан как «digital times», у другой — magazine digital times, а у третьей — SIA Mega Plus. С точки зрения человеческой логики — это один и тот же клиент, но если записи просто скопировать в одну базу, то из-за несоответствий получится дубликат. Соответственно, потом некоторые отчёты будут неверными или неполными, часть информации будет скрыта.

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

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

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

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

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

Если не слияние, то что?

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

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

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

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

Источник: отчёт компании «Интертех».

О процессе гармонизации данных

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

Позволяют ли данные вашей системы осуществлять эффективное взаимодействие между различными подразделениями? Если вы ответили «нет» на хотя бы один из этих вопросов, то вам необходимо задуматься о повышении эффективности вашей информационной системы за счёт гармонизации данных!»

Источник: отчёт компании Solteq bUSiNeSS

Очень часто скандалы с «откатами» в крупных компаниях связаны именно с проблемами в управлении данными. Если в системе отсутствует чёткий контроль над тем, кто, когда и на каких условиях может вносить те или иные изменения, то появляется почва для злоупотреблений. Устоять перед искушением способны далеко не все и далеко не всегда. Другой пример важности качества данных, это имплементация складов данных или т. н. data warehouse. Здесь качество критично, потому что основной целью при создании «склада» является уменьшение объёма данных, необходимых для отчётности, с одновременным ускорением доступа к статистической информации и уменьшением количества дискового пространства, потребляемого оперативной информацией. Если качество данных при архивировании было не слишком высоко, скорость доступа и доверие к ним резко уменьшится и это прямо повлияет на «value for money» такой системы. А фатальные ошибки, такие как использование разных единиц измерения (килограммы и штуки, например),может и вовсе заставить «вскрыть» архивы в ручном режиме.

Поэтому, перед тем как имплементировать data warehouse, клиент обязан подумать о гармонизации данных.

Безопасность — наше всё!

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

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

SAP vs факс

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

То есть при большом количестве данных сделать каждую запись идеальной практически невозможно. Людям свойственно допускать ошибки. Некоторые ошибки стандартны и потому их исправление можно поставить на поток. В нашем примере с факсами оказалось, что человек чаще всего ошибается в месте, где нужно указать код страны — пишет ошибочный или не вводит вовсе. Менее распространённая ошибка связана с кодом города. Вдобавок к этому данные собирались со всего мира и, как оказалось, в разных странах совершенно разные правила и возможные написания телефонного номера. Допустим, эти ошибки суммарно характерны для 15000 записей (а всего их у нас, скажем, 3000000). Это достаточно большой процент, для того чтобы его было выгодно исправить в полностью автоматическом режиме.

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

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

Словари — основа основ

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

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

Клиенты SAP не спешат

Согласно последнему отчёту SAP, несмотря на то что с момента приобретения компании Business Objects прошёл уже год, пользователи SAP NetWeaver business intelligence не спешат мигрировать на новые системы. Аналитики объясняют это тем, что клиенты компании защищают свои достаточно существенные инвестиции. Как известно, SAP объявила о том, что её собственная платформа не получит дальнейшего развития, и предложила всем своим пользователям мигрировать на решения Business Objects, а это 2–3 тыс. USD за рабочее место. Год назад решения SAP в области интеграции данных использовало порядка 40 тыс. клиентов, у Business Objects их было порядка 30 тыс. и из этих 70 тыс. около 5 тыс. использовали разные инструменты одного и другого вендора. SAP утверждает, что за год последняя группа «выросла», хотя и не уточняет, на сколько именно.

Informatica тоже покупает

Informatica объявила о поглощении компании Applimation, которая является (уже —«являлась») мировым лидером в области систем управления жизненным циклом информации (Information Lifecycle Management). Её продукты позволяют клиентам лучше управлять информацией на протяжении всего срока жизни — от появления до архивирования. Обычно системы Applimation используют в связке с другими крупными программными комплексами для бизнеса, характеризующимися аббревиатурами ERP, CRM, HR и SCM. Сумма сделки между Informatica и Applimation не разглашается плодом творчества сообщества opensource, какие-то исполнители создают сами. Единственное железное правило — «для себя» эти базы никогда не делаются из данных заказчиков (без их согласия на это, естественно), их источник всегда должен быть нейтрален. Таким источником могут быть либо словари, идущие в составе крупных продуктов для работы с базами данных, либо публичные государственные базы данных.

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

Не словарём единым

Вообще сфера программного обеспечения для гармонизации данных относительно молода и там не так много игроков. Однако есть признанные лидеры, в первую очередь, конечно же, Oracle, Informatica (усиленная бывшим лидером Athanor), Initiate Systems, IBM и Business Objects. Последняя была куплена SAP в 2007 году за 4.8 млрд EUR. У всех крупных вендоров исключительно мощные инструменты, и они предлагают всё, начиная от workflow и заканчивая множеством словарей и валидаторов. Причём решения предназначены скорее, для бизнес-профессионалов, нежели IT-спецов. В теории, заплатив миллионы за пакет, заказчик может самостоятельно провести гармонизацию данных. На практике это пока практически недостижимо.

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

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

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

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

Сегодня это куда более удобный и наглядный инструмент. И с каждым годом и с каждой новой версией удобнее и нагляднее. Но до кнопки «гармонизировать данные» дело дойдёт едва ли. Многие вещи оценить и продумать эффективные пути решения проблем могут только люди. !

По словам специалистов, на то, что в SAP Business Object уйдёт день, в MySQL потребуется неделя. И нельзя забывать про поддержку — кто-то потом должен ею заниматься. В случае с SAP Business Object ею будет заниматься сам вендор. А в случае с MySQL? Те, кто писал функции? Это непрофессиональный подход — каждый должен заниматься только своим делом.

Автор благодарит Дмитрия Львова, системного аналитика компании Accenture, за помощь в подготовке материала.

Источник: http://www.pcweek.ua