Почему данные становятся грязными и при чём здесь бизнес-процесс

Фраза «данные грязные» нередко звучит как диагноз IT-системе: не доработана CRM, плохо настроены интеграции, расходятся справочники или некорректно собрана аналитическая витрина. Но во многих случаях проблема появляется раньше: в самом бизнес-процессе.

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

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

Почему пустые поля нередко указывают на проблему в процессе

Один из заметных симптомов низкого качества данных: незаполненные или формально заполненные атрибуты в CRM и ERP: нет сегмента клиента, причины отказа, канала привлечения, обещанной даты отгрузки, кода склада или типа доставки. В BI такие записи попадают в категории «прочее» и «не заполнено», а причиной как правило считают человеческий фактор.

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

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

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

Ещё одна распространённая проблема: техническая ответственность определена, а бизнес-ответственность нет. Администратор может контролировать формат поля, права доступа и наличие значения, но правила сегментации клиентов, определения канала или классификации причин отказа относятся уже к бизнес-логике.

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

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

Интеграции не исправят то, чего нет в процессе

Ещё одна типичная проблема с качеством данных: расхождения между системами. В CRM клиент записан одним образом, в ERP: другим, в WMS отличается адрес, в BI не сходятся идентификаторы. В такой ситуации компании быстро приходят к обсуждению мастер-данных, MDM и единых справочников.

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

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

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

Качество данных: часть управленческого контура, а не отдельный проект

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

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

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

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

Грязные данные нередко появляются при переходах, а не внутри этапа

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

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

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

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

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

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

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

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

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