Данные решают. Как управлять данными, чтобы создавать ценность для бизнеса - Светлана Бова

режиме. Установленная норма уровня качества данных — постоянно замеряемый показатель, демонстрирующий эффективность работ по обеспечению «чистоты» данных в организации. Он устанавливается для владельцев данных, и из года в год по мере «взросления» компании пороговое значение нормы возрастает. В рассматриваемом нами выше примере логистической компании после внедрения MDM-системы на первый год ее эксплуатации владельцу данных — начальнику отдела продаж — был установлен Run DG KPI = «Уровень качества данных по корпоративным клиентам не менее 95%». В последующие годы этот целевой показатель будет повышаться, амбиции по качеству данных станут расти с шагом + 1–2%, пока не будет достигнуто значение 100% качественных записей по клиентам. Далее эта планка должна быть удержана.

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

Рассмотрим направление «Качество данных» из табл. 7.1. Компания сначала разрабатывает политику управления данными и внедряет технологический инструмент для автоматизации проверок качества данных (Data Quality, DQ) в формате проектной деятельности с Change DG KPI: 1) внедрение платформы качества данных; 2) разработка политики по управлению данными; 3) разработка не менее 50 автоматизированных проверок качества клиентских данных. После внедрения DQ-системы в эксплуатацию и перевода задач по реализации проверок качества данных в режим текущей деятельности, а также выстраивания процессов анализа и решения выявляемых инцидентов качества данных Change KPI закрываются, но количество и глубина проверяемых метрик по Run KPI растет. В первый год набор Run DG KPI может выглядеть так: 1) процент прироста количества автоматизированных проверок качества данных = 50%; 2) уровень качества клиентских данных не менее 95%; 3) процент инцидентов качества данных, выявляемых автоматизированными проверками на DQ-платформе, не менее 60% от общего объема. В последующие годы планка целевых значений этих метрик будет повышаться, а периметр данных, покрываемых проверками, — расширяться. Также по мере роста зрелости компании в области управления данными методики расчета KPI будут усложняться: аппетит всегда приходит во время еды, и неизбежно появится желание измерять общий индекс здоровья данных в разрезе разных категорий данных с учетом зависимостей данных и бизнес-процессов организации.

Выводы

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

1. НАЧИНАЙТЕ С БИЗНЕСА, А НЕ С ДАННЫХ

Не изобретайте KPI в отрыве от стратегии. Найдите «боль» компании — рост клиентской базы, снижение логистических потерь, ускорение процессов — и переведите ее на язык данных. Как в примере с логистической компанией: цель «увеличить портфель корпоративных клиентов» превратилась в KPI по качеству клиентских данных. Данные — инструмент, а не самоцель.

2. ГОВОРИТЕ НА ЯЗЫКЕ ИСПОЛНИТЕЛЕЙ

Если KPI по «качеству данных» непонятен работнику склада, он станет «стеклянным боем»: будет имитировать выполнение, а проблемы — прятать. Сформулируйте KPI так, чтобы сотрудник видел прямую связь: заполнил все поля в системе — получил премию. Но не перегружайте — вес KPI по данным не должен превышать 10–15% от общего пакета мотивации.

3. ВЫБИРАЙТЕ НАПРАВЛЕНИЕ DG КАК ТОЧКУ ПРОРЫВА

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

4. РАЗДЕЛЯЙТЕ KPI НА «СТРОИТЕЛЬСТВО» И «ЭКСПЛУАТАЦИЮ»

Change KPI — для проектов: «внедрить MDM за год», «запустить 50 проверок качества данных».

Run KPI — для текучки: «качество данных не ниже 95%», «время обработки запроса на доступ — не более четырех часов».

По мере взросления DG 80% метрик должны стать «эксплуатационными». Если все KPI остаются «проектными» — вы не вышли на операционную эффективность.

5. СДЕЛАЙТЕ KPI ВИДИМЫМИ, КАК ПУЛЬС НА ДАШБОРДЕ

Если метрики обсуждаются раз в полгода на совете директоров, они уже мертвы. KPI должны быть на экранах у руководителей ежедневно, а отклонения — запускать действия. Автоматизируйте сбор, но не доверяйте данным слепо — проверяйте, не «заклеивают ли водители датчики пластырем», как в кейсе «Удачных перевозок».

6. БУДЬТЕ ГОТОВЫ ПЕРЕСМАТРИВАТЬ KPI КАК СТРАТЕГИЮ

Жизненный цикл KPI — не линейный план, а спираль. Законодательство изменилось? Появились новые технологии? Бизнес сменил фокус? KPI должны эволюционировать. Месяц на корректировку лучше, чем год на реализацию устаревшей цели.

7. СВЯЖИТЕ KPI С ДЕНЬГАМИ И КАРЬЕРОЙ

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

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

Начните с ответа на простой вопрос: «Какой один показатель данных, если его улучшить на 10%, даст бизнесу больше всего денег или сэкономит больше всего нервов?» — и сделайте его KPI № 1. Остальное приложится.

Глава 8. Управление данными в разных индустриях

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

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

В этой главе мы