Журнал ВРМ World

Мировая история развития технологий управления эффективностью бизнеса – обзоры зарубежных публикаций

Пять общепринятых отговорок против реинжениринга унаследованных данных

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

Хорошие данные + хорошие данные = плохие данные. После слияния, даже отдельные унаследованные файлы, изначально содержащие данные необходимого качества, будут испытывать проблемы с качеством данных. Ввиду отсутствия общих для систем стандартов и бизнес-правил, а также "творческого" подхода к вводу данных и обработке ошибок, интеграция множества унаследованных файлов создает разные ключи в связанных между собой записях. Без выявления и связывания взаимоотношений объектов по всем точкам ввода унаследованной информации, результатом слияния будет недостаточная "целостность объектов", привносящая в системы неверную информацию и генерирующая ошибочные ответы на запросы.




Например, пользователь выполняет запрос к системе, содержащей информацию по клиентам, с целью определения объема продаж за четвертый квартал года в компании Bristol-Myers Squibb. Ответ может лежать где-то среди записей о: Bristol-Myers, Bristol Myer, Bristol Meyer, Bristol-Meyers, Brystol Myers, Bristol-Myers Squib, Bristol Myers Squibb Corp, Bristol Myer Squibb Co., и т.д. Если ваше информационное подразделение не желает или не в состоянии построить такие нечеткие связи - без использования уникальных ключей - доверие к новой системе будет утрачено довольно быстро.


2. "Обычно у нас есть ключи соединения данных"
Для корпоративной информационной системы, лежащей в основе улучшения процесса принятия решений на предприятии, усовершенствования обслуживания клиентов и активизации новых маркетинговых инициатив, "обычно" - не самая лучшая характеристика. Поскольку аномалии и индивидуальные ключи по своей природе имеют тенденцию к сосредоточению около информации по наиболее крупным клиентам, даже небольшой процент загрязненности унаследованных данных могут свести на нет всю достоверность по самым важным для компании клиентам. По опыту, 80% запросов связаны с 20% клиентов компании - как раз с теми, информация по которым в данном случае оказывается недостоверной.




ЭФФЕКТ НАЛОЖЕНИЯ ЗАГРЯЗЕНИЙ В УНАСЛЕДОВАННЫХ ДАННЫХ:

"Плохим" данным свойственно располагаться как раз в области наиболее важных для компании клиентов и бизнес-объектов - в области информации, к которой пользователи обращаются в свои запросах чаще всего. В данной статье все "примеры" по компании Digital Equipment Corp. взаимосвязаны, за исключением одной аномалии. Но эта единственная "ошибка" в данных способна негативно повлиять на точность всех запросов по продажам данной компании.


3. "При необходимости можно очистить данные после их ввода в новую систему, после пробного запуска"
К сожалению, очищать данные после их перемещения уже слишком поздно. Может случиться так, что надежность новой системы будет уже сведена к нулю, что, в свою очередь, приведет к потере финансовой поддержки спонсоров, не верящих в возможность восстановления системы. Даже если у предприятия еще останутся средства, исправления, вносимые пост-фактум, всегда сопряжены со значительными затратами, сложностями и риском. Что, если восстановление данных потребует расширения модели данных ввиду невозможности предвидеть атрибуты, скрытые в текстовых полях свободного формата? Стоимость повторной системной обработки такого рода может запросто превысить четверть исходной стоимости реализации.

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

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


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

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


Реальный (и типичный) пример данных по клиенту Vality...

KENTUCKY FRIED CHCKN
KENTUCKY FRIED CHKN
KENTUCKY FRIED
KENTUCKY FRIED CHIC
KENTUCKY FRIED CHIK
KENTUCKY FRIED CHKN
KENTUCKY FRIED 01
KENTUCKY, FIRED CH
KFC CORP
KFC CORP X270-915
KFC CORP OF DESHTSPR
KFC CORP OF POLLYS INC

Как можно точно выявить и объединить аномальные записи среди миллионов правильных?

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

И, наконец, в-четвертых, исправлять данные в точке ввода начиная с данного дня - дело, конечно, хорошее, но что делать с огромными объемами уже имеющихся записей, ожидающих перемещения из унаследованных систем в новые? Компания, имеющая миллионы записей по клиентам, нуждается в автоматизированных средствах для изучения, распознавания и объединения информации с целью достижения целостности областей и объектов. Целостность области будет иметь место в случае, когда значения данных допустимы в своем диапазоне и правильно соотносятся с другими значениями в данной записи. Например, имя, Ричард, является допустимым именем и правильно соотносится со значением поля Пол: "мужской". Целостность объекта будет иметь место в случае, когда объект (т.е. лицо, предприятие или местоположение) безусловно идентифицируется одним и только один набором атрибутов.


5. "Пользователи никогда не согласятся изменить свои данные"
А может им не нужно и высокое качество данных, и точные ответы на запросы относительно их бизнеса? В любом случае можно достичь точности и без изменения данных. С помощью внешних ключей, таблиц синонимов и организации связей между записями можно сохранить исходные унаследованные значения, получая при этом точные ответы на запросы, требующие объединенного представления. Пользователи могут и не понимать, что в реляционных системах для представления сложных взаимоотношений можно обращаться ко многим записям без опасности разрушения, уничтожения или изменения значений каких-либо исходных данных. Нет необходимости ведения "дедупликации" или стандартизации "DEC", "Digital" и "Digitl (sic) Equipment" в одну запись. Можно предоставить пользователям точное объединенное представление, просто связывая записи после того, как их соотношения определены. Если вы не отвечаете за реальные значения данных, формирующих отражение вашего бизнеса, вы можете так никогда и не получить искомый результат. Если вы тратите такие огромные средства на новые информационные системы, можете ли позволить себе быть неточно и неправильно информированными?

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


Автор: По материалам зарубежных сайтов