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

Если мы хотим, чтобы информация помогала нам строить конструктивные отношения с партнерами и принимать обоснованные бизнес-решения, мы должны следить за точностью этой информации. Иначе от всей системы управления отношениями с клиентами (Customer Relationship Management, CRM) проку не будет — разве что с ее помощью мы сможем быстрее принимать неправильные решения. Но есть и еще одно обстоятельство, влияющее на полезность и применимость информации: содержимое баз данных и уровень его качества.

Использование некачественных данных часто приводит к возникновению самых разных проблем. Перечислим только некоторые из возможных ситуаций.

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

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

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

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

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

Типы данных

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

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

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

Справочные и базовые данные

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

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

Транзакционные данные

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

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

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

Данные хранилищ

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

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

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

Вот почему в случае изменения транзакционных или базовых данных мы никогда не вносим изменения в данные хранилища, а вместо этого создаем новую запись, отражающую текущее состояние дел. Если бы мы отследили дату начала и завершения «приписки» того или иного продукта к определенной серии изделий, мы бы с легкостью преодолели последствия того бедствия, которое постигло нас в связи с подпиской на бюллетень. Соображения, которые следует учитывать при разработке хранилищ данных, подробно описаны в монографии Билла Инмона, посвященной этому вопросу (Bill Inmon, Building the Data Warehouse, 1992), которая по сей день остается одной из самых популярных книг на эту тему.

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

Бизнес-представления

Данные этого типа генерируются из содержимого хранилищ данных. Бизнес-представления — это расчеты или сводки исторической информации, в которых часто сопоставляются тенденции на различных отрезках времени. Бизнес-представления обычно отражают некоторые коммерческие показатели для конкретной географической зоны. Бизнес-представление может содержать ответ на такой, к примеру, вопрос: «Какое число клиентов из Северной Америки на протяжении последних трех лет увеличило объемы ежегодных закупок более чем на 10%?» Эффект от применения инструментов генерации отчетов и анализа гораздо выше, когда они обрабатывают не все содержимое хранилища данных, а консолидированное бизнес-представление. Данные бизнес-представлений никогда не обновляются; вместо этого представления периодически воссоздаются на основе данных из хранилища.

Идентификация качества данных

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

  1. Ухудшение качества данных о клиенте (клиенты меняют адреса, переходят на другую работу и т. д.).
  2. Низкое качество исходных данных (структура базы данных, отсутствие стандартов).
  3. Отсутствие доверия (сопротивление со стороны агента по продаже товаров и со стороны клиента).

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

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

Качество данных ухудшается с той минуты, когда вы начинаете вводить информацию о клиенте в базу. От 7 до 10% индивидуальных потребителей и предприятий ежегодно меняют свои физические адреса, и прежняя контактная информация становится бесполезной. Добавьте к этому большое число работников, переходящих в другие организации (само предприятие при этом никуда не переезжает), и получится, что коэффициент ухудшения персональных данных в сфере отношений В2В будет составлять 30-35% в год (или более 70%, если мы учтем к тому же все изменения, вносимые в визитные карточки). Не пройдет и двух лет, и более половины содержимого базы данных с именами контактов на других предприятиях потеряет актуальность, если в обслуживание данных не будут вкладываться необходимые средства.

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

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

Сегодня интерес к качеству данных повышается потому, что компании начинают понимать: знания о клиентах, которые они получают в виде записей в транзакционных системах, — это настоящая золотая жила. Они хотят консолидировать все данные и составить на их основе столь желанное всеобъемлющее представление о клиенте, позволяющее осуществлять анализ и планирование. Но поскольку стандартов в этом деле нет, а базы данных предназначены для обслуживания оперативных функций, собранные данные по большей части просто не стыкуются друг с другом. Адрес получателя заказа используется для печати почтовой наклейки; это четыре-пять строк текста, в котором указывается, куда нужно доставить изделие. В первой строке адреса может быть указано имя клиента, но вполне возможно, что в ней значится слово «внимание» или содержатся специальные инструкции для перевозчика. Как бы то ни было, транзакционная система сработала нормально, но в справочное досье по клиентам или в хранилище данных попадут огромные объемы мусора — и все потому, что в методах заполнения данных нет единообразия. Чтобы создать (или приобрести) транслятор, нужны дополнительные деньги, но трансляторы, по крайней мере, функционируют. То есть они функционируют, если только исходные данные соответствуют тем образцам, для обработки которых был создан конкретный транслятор.

Когда нет стандартов, а данные не редактируются

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

Торговый агент компании XYZ отвечал за работу с корпорацией General Dynamics. Однажды этот человек был просто огорошен, когда узнал, что в его месячную квоту не вошла огромная сделка, заключенная с его участием. После кропотливого расследования выяснилось, что этот крупный заказ был оформлен на клиента GD/EBD, и компьютер, естественно, не воспринял его как заказ General Dynamics.

Kaк же получилось, что заказ был оформлен столь странным образом? Оказывается, все очень просто. Для своего удобства агент обозначил счет, выставленный подразделению Electric Boat Division корпорации General Dynamics, как GD/EBD. Разумеется, при этом он исходил из того, что администратор по заказам, обрабатывавший его документы, сможет распознать и правильно внесет в заказ имя General Dynamics. Ho как раз в ту неделю опытный администратор приболел, а временный сотрудник, заполнявший заказы, и понятия не имел о том, что GD/EBD — это всего лишь сокращенное написание названия General Dynamics. Вот по этой причине заказ и не записали на имя участвовавшего в его размещении агента. Можно себе представить, какой скандал разразился бы, если бы в результате этого инцидента клиент потерял скидку, причитающуюся ему за большие объемы!

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

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

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

Неудовлетворительная организация баз данных

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

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

Отсюда принципиальный вывод: одно поле — один факт.

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

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

Judith W. Kincaid. Bad Data In, Bad Decisions Out. Darwin, March 2003.