Зрелость управления данными: предлагаю простую методику оценки

TL;DR

Зрелость управления данными определяется не количеством отчётов, размером команды или наличием хранилища. Она показывает, насколько осмысленно и устойчиво компания получает данные, отвечает за них и превращает их в решения.

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

Введение

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

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

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

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

Так как и зачем использовать данные и показания приборов в своём полёте?

Как, кем и где создаются и хранятся данные

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

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

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

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

В итоге данные могут:

• создаваться автоматически системами и устройствами

• вводиться вручную сотрудниками

• храниться в инфраструктуре компании

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

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

Будем держать в голове простую ситуацию. В понедельник руководитель просит показать выручку за прошлый месяц. CRM показывает 12.4 миллиона рублей, 1С — 11.8 миллиона, а складская система — 13.1 миллиона. Каждый отчёт формально построен правильно, но ответов получилось три.

Причина не обязательно в ошибке системы, и чаще не в ней. Одна система считает созданные заказы, другая — оплаченные, третья — отгруженные. Где-то уже учтены возвраты, где-то ещё нет. Таким образом, тривиальный вопрос может стать камнем преткновения и вызвать споры среди руководителей.

Для чего работать с данными

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

Малвин Конвей, оригинал статьи

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

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

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

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

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

Что такое зрелость управления данными

Сначала договоримся о терминах.

• Управление данными (Data Management) включает организационные, административные и технические процессы работы с данными на протяжении всего их существования.

• Корпоративное управление данными (Data Governance) определяет полномочия и ответственность: кто владеет данными, кто отвечает за их качество, кому они доступны, как согласуются определения и какие требования необходимо соблюдать.

• Жизненный цикл данных (Data Lifecycle) описывает этапы, которые проходят данные: создание или получение, хранение, обработка, использование, передача, архивирование и удаление.

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

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

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

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

Уровни зрелости

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

Она описывает не количество внедрённых систем и не сложность архитектуры, а преобладающий способ работы компании с данными: насколько эта работа осмысленна, управляема, повторяема и встроена в принятие решений.

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

Уровень 0. Данные почти не используются

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

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

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

Уровень 1. Ситуативная работа

Данные начинают использоваться для решения конкретных вопросов и уже возникших проблем. Руководитель замечает снижение продаж, рост остатков или увеличение количества жалоб и просит разобраться в причинах.

Отчётность появляется «под задачу». Её вручную готовят сотрудники, которые лучше других разбираются в Excel, 1С, CRM, рекламных кабинетах или метриках сайта. Результат может быть полезным и даже приводить к правильным решениям, но процесс каждый раз приходится собирать заново.

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

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

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

Уровень 2. Повторяемая работа

Часть отчётов выпускается регулярно, появляются согласованные инструменты и ответственные исполнители. Компания уже способна повторять основные операции без изобретения процесса заново.

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

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

Если один и тот же вопрос приводит к нескольким версиям выручки, значит, повторяемость появилась, но согласованность — ещё нет. Компания умеет регулярно выпускать отчёты, но пока не всегда может объяснить, почему они показывают разные результаты.

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

Уровень 3. Системное управление

Работа с данными становится управляемой системой. Основные источники, показатели, роли и правила определены. Компания знает происхождение критичных данных, контролирует их качество, сохраняет историю и управляет изменениями.

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

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

На этом этапе может возникнуть потребность в хранилище, озере данных, Data Mesh или другой архитектуре. Но само наличие DWH, Data Lake, Lakehouse или Data Mesh не переводит компанию на третий уровень. Архитектура подтверждает зрелость только тогда, когда решает понятные задачи и поддерживается устойчивыми процессами.

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

Уровень 4. Управление с опорой на данные

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

Иными словами, данные используются в трёх состояниях:

• когда уже стало плохо и необходимо понять причины

• когда всё ещё хорошо, но появились признаки возможной проблемы

• когда всё хорошо, но есть возможность сделать ещё лучше

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

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

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

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

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

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

Поэтому решения должны приниматься с опорой на данные, а не исключительно данными. Аналитика уменьшает неопределённость, но не отменяет опыт, интуицию и ответственность человека.

Уровень зрелости не отражает напрямую размер, оборот или успешность бизнеса. Небольшая компания может иметь согласованные показатели и качественную регулярную отчётность. А крупная торговая сеть — оставаться на первом уровне, если её подразделения используют разрозненные системы и не могут договориться о значении основных показателей.

Для чего бизнесу оценивать зрелость

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

• какие ограничения действительно мешают принимать решения

• в каких местах есть опасная зависимость от людей, поставщиков или ручного труда

• какой следующий шаг даст пользу и принесет пользу, а какой будет преждевременным и может принести убытки

• сколько компания тратит на данные и что получает взамен

• о чём руководители, бизнес и техническая команда должны договориться до покупки очередной системы

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

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

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

Какие модели зрелости существуют

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

DAMA-DMBOK

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

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

CMMI Data

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

DCAM

DCAM — подробная модель оценки возможностей управления данными и аналитикой. В DCAM v3 восемь компонентов, объединяющих 34 возможности и 101 подвозможность. Оценка опирается не только на ответы участников, но и на вовлечённость ответственных лиц, устойчивость процессов и проверяемые свидетельства.

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

CDMC

CDMC — специализированная модель EDM Association для управления и контроля данных в облачной, мультиоблачной и гибридной среде. Она уделяет особое внимание чувствительным данным, безопасности, контролю и облачным рискам. CDMC дополняет общую оценку, но не заменяет её.

Какую модель выбрать

Универсального ответа нет:

• DAMA-DMBOK помогает увидеть состав дисциплины;

• CMMI Data — оценить устойчивость и развитие процессов;

• DCAM — провести подробную оценку возможностей с подтверждающими материалами;

• CDMC — проверить управление данными в облачной среде.

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

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

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

Упрощённая методика оценки

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

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

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

• владельца или представителя руководства

• руководителей основных бизнес-направлений

• сотрудников, отвечающих за финансы и отчётность

• представителей ИТ и команды данных, если она есть

• владельцев ключевых систем

• специалистов по информационной безопасности и правовым требованиям — там, где это существенно.

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

Разница в ответах не помеха. Если руководитель ставит процессу 4, а исполнитель — 1, это показывает разрыв между формальным представлением и повседневной практикой.

До начала оценки необходимо:

1. Определить охват: всю компанию, подразделение, продукт или конкретный процесс.

2. Выбрать период, состояние которого оценивается.

3. Заранее отметить блокирующие критерии.

4. Договориться, какие свидетельства и доказательства считаются достаточными.

5. Не оценивать неприменимые критерии: помечать их как N/A и не учитывать в подсчете.

Критерии оценки зрелости вашей компании

Выделяю пять направлений:

1. Цели, ценность и экономика данных.

2. Люди, роли и ответственность.

3. Процессы и правила.

4. Данные и их качество.

5. Технологии и архитектура.

Это направления нашей упрощённой методики, а не буквальное воспроизведение структуры DAMA-DMBOK, например.

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

Единая шкала оценки

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

Оценка должна отвечать не на вопрос «кажется ли нам, что всё хорошо», а на вопрос «какое состояние мы можем подтвердить фактически».

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

Блокирующие критерии

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

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

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

Если критерий не относится к выбранному процессу или подразделению, ему присваивается значение N/A. Такой критерий не участвует ни в расчёте результата, ни в проверке блокировок.

Критерии:

1. Цели, ценность и экономика данных

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

Утверждения для оценки:

• [Блокирующий критерий] Для основных инициатив по работе с данными определены бизнес-задача, ожидаемый результат и приемлемые затраты.

• [Блокирующий критерий] Результаты работы с данными используются при принятии ключевых управленческих решений.

• Ключевые показатели связаны с целями компании.

• Понятно, какие решения принимаются на основе данных.

• Результат решений, принятых с опорой на данные, измеряется.

• Компания понимает полную стоимость работы с данными.

• В стоимости учитываются лицензии, инфраструктура, подрядчики и труд сотрудников.

• Затраты сопоставляются с получаемой пользой.

• Невостребованные отчёты, системы и наборы данных выявляются и выводятся из эксплуатации.

• При оценке учитывается стоимость ошибок и некачественных данных.

2. Люди, роли и ответственность

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

Утверждения для оценки:

• [Блокирующий критерий] Для ключевых данных и показателей назначены владельцы.

• [Блокирующий критерий] Критические процессы работы с данными не зависят исключительно от знаний и доступа одного сотрудника.

• Понятно, кто отвечает за обнаружение и исправление ошибок.

• Ответственность между бизнесом и технической командой разделена.

• Определено, кто согласовывает правила расчёта показателей.

• Сотрудники обладают знаниями, необходимыми для выполнения своих ролей.

• Руководители понимают смысл используемых показателей.

• Сотрудники доверяют отчётности и знают границы её применимости.

• Пользователи знают, к кому обратиться с вопросом о данных.

3. Процессы и правила

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

Утверждения для оценки:

• [Блокирующий критерий] Правила расчёта ключевых показателей зафиксированы и позволяют воспроизвести результат.

• [Блокирующий критерий] Обязательные правовые, регуляторные и внутренние требования к доступу, хранению и уничтожению данных определены и соблюдаются.

• Процессы получения и обработки ключевых данных описаны.

• Необходимая отчётность выпускается с установленной периодичностью.

• Определения показателей согласованы между подразделениями.

• Правила доступа, хранения, архивирования и уничтожения данных установлены.

• Изменения в данных, расчётах и отчётности вносятся по понятному и определённому процессу.

• Обнаруженные ошибки регистрируются и исправляются.

• Соблюдение установленных правил контролируется.

4. Данные и их качество

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

Утверждения для оценки:

• [Блокирующий критерий] Происхождение данных, используемых для ключевой отчётности и управленческих решений, известно.

• [Блокирующий критерий] Для критичных данных определены минимальные требования к точности, полноте и своевременности, и эти требования выполняются.

• Основные источники данных определены.

• Для принятия существенных решений достаточно данных.

• Данные из разных систем связаны согласованным способом.

• Дубли и противоречия выявляются.

• Качество данных контролируется вручную или автоматически.

• Исторические значения сохраняются.

• Ошибки исправляются в первичном источнике, когда это возможно.

• Изменения качества отслеживаются во времени.

5. Технологии и архитектура

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

Утверждения для оценки:

• [Блокирующий критерий] Доступ к конфиденциальным и критичным данным контролируется.

• [Блокирующий критерий] Резервные копии критичных данных создаются, а возможность восстановления регулярно проверяется.

• Для типовых задач определён согласованный набор инструментов.

• Основные источники интегрированы в необходимой степени.

• Ручные операции автоматизированы там, где это оправдано.

• Архитектура соответствует текущим задачам и рискам бизнеса.

• Система способна развиваться вместе с компанией.

• Основные компоненты и связи документированы.

• Работоспособность и стоимость инфраструктуры контролируются.

• Работа критических компонентов не зависит исключительно от одного сотрудника или поставщика.

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

Например, направление «Технологии и архитектура» может иметь медианную оценку 3,5, но оставаться заблокированным, если резервные копии создаются, а возможность восстановления ни разу не проверялась.

Как рассчитывать результат

Для каждого направления сначала рассчитывается медиана всех применимых оценок:

где:

• — оценка направления;

• — оценка отдельного критерия от 0 до 4;

• — количество применимых критериев в направлении.

Медиана может иметь промежуточное значение. Например, результат 2,5 означает, что направление находится между вторым и третьим уровнями.

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

где:

• — достигнутый уровень зрелости направления;

• — множество заранее определённых блокирующих критериев;

• — округление оценки вниз до полностью достигнутого уровня.

Например, оценка 3,5 означает, что направление находится между третьим и четвёртым уровнями, но достигнутым считается уровень 3. Оценка 4 соответствует уровню 4.

Если сработал блокирующий критерий, медиану всё равно можно показать как справочную:

Оценка направления — 3,5. Статус — блокировка: восстановление резервной копии не проверялось.

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

Нужны ли веса

Теоретически отдельным критериям можно назначить веса:

где — вес критерия.

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

Чек-лист оценки

Для практического использования методики подготовил таблицу с визуализацией. Скопируйте таблицу вместе с формулами.

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

Главный результат это согласованный перечень следующих действий. Если оценка не приводит к решению, назначенному ответственному и сроку проверки, она рискует стать ещё одним отчётом, который никто не использует.

Как интерпретировать результаты

Интерпретация уровней

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

Уровень 0 не всегда означает проблему, а уровень 4 не всегда является необходимой целью. Требуемая зрелость зависит от размера компании, сложности процессов, стоимости ошибок и требований законодательства.

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

Примеры:

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

• качественные данные при нераспределённой ответственности создают зависимость от отдельных сотрудников

• подробно описанные процессы при низком качестве данных означают, что правила существуют преимущественно на бумаге

• развитая отчётность при низком доверии сотрудников показывает, что формальное наличие данных ещё не сделало их частью управления

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

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

Определяется целевое состояние

После оценки компания выбирает целевой уровень отдельно для каждого направления. Цель не обязана равняться четырём.

Например:

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

Формируется план действий

Для каждого обнаруженного разрыва необходимо определить:

• что именно требуется изменить

• почему это важно

• кто отвечает за изменение

• какой результат ожидается

• как он будет измерен

• когда будет проведена повторная оценка

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

Итог оценки должен выглядеть не как «зрелость компании — 2,7», а примерно так:

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

Заключение

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

Начинать стоит не с покупки платформы. Сначала нужно договориться:

• какие решения компания хочет улучшить и зачем

• какие данные для этого нужны

• кто отвечает за их смысл и качество

• какие ошибки недопустимы

• сколько компания готова потратить

• как будет измерен результат

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

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

Источники и полезные ссылки

Основные источники

• DAMA International — международная ассоциация специалистов по управлению данными.

• DAMA-DMBOK — официальный раздел свода знаний по управлению данными.

• DAMA-DMBOK 3.0 Project — проект следующей версии DMBOK.

• CMMI Data — модель CMMI для развития практик работы с данными.

• Уровни возможностей и зрелости CMMI — описание логики уровней CMMI.

• DCAM — модель оценки возможностей управления данными и аналитикой.

• CDMC — модель управления и контроля данных в облачных средах.

• DataMesh — о принципах архитектуры и ее построения

Дополнительные обзоры и статьи

• Snowflake: DCAM Guide — обзор структуры и применения DCAM

• Actian: Data Management Maturity Overview — обзор подходов к оценке зрелости управления данными

• Закон Конвея: оригинальная статья

• https://www.youtube.com/watch?v=pIepQd4YSEQ — вебинар-конспект DAMA DMBOK на русском языке