Вопрос: Знаете ли вы, кто является владельцем данных в вашем подразделении?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 9 | 10 | 1 | 0 | 2 | 2 | 24 |
Не уверен(а) | 2 | 5 | 0 | 0 | 2 | 5 | 14 |
Нет | 3 | 1 | 0 | 0 | 0 | 0 | 4 |
Всего | 14 | 16 | 1 | 0 | 4 | 7 | 42 |
🧠 Основные выводы:
-
Более половины респондентов (24 из 42) уверены, кто является владельцем данных в их подразделении — это хороший базис для дальнейшего развития ролевой модели.
-
14 респондентов (включая 5 аналитиков и 5 представителей других ролей) затруднились с ответом, указав, что не уверены в владельце данных — что сигнализирует о недостатке прозрачности или документации.
-
4 человека прямо заявили, что не знают владельцев данных, при этом все ответы приходятся на технические роли (аналитики и инженеры).
✅ Рекомендации:
-
Формализовать и визуализировать роли владельцев данных по подразделениям:
- Создать карту владельцев (data owners), с указанием ответственности и каналов связи.
-
Публично закрепить и прокоммуницировать эти роли:
- Включить в onboarding, разместить на внутреннем DG-портале или wiki.
-
Проводить регулярные сессии Q&A или консультации по ролям:
- Особенно в командах, где доля “неуверенных” велика (дата-инженеры, аналитики, другие).
Вопрос: Назначены ли официально владельцы данных для ключевых наборов данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 5 | 7 | 1 | 0 | 1 | 0 | 14 |
Частично | 6 | 5 | 0 | 0 | 3 | 2 | 16 |
Нет | 1 | 0 | 0 | 0 | 0 | 2 | 3 |
Не знаю | 1 | 4 | 0 | 0 | 0 | 3 | 8 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Лишь 14 из 41 опрошенного подтвердили, что владельцы данных официально назначены — это только треть выборки.
-
Самая популярная категория ответа — “частично” (16 ответов), что может указывать на отсутствие системного подхода к назначению ролей.
-
8 респондентов не знают, назначены ли владельцы — это свидетельствует о недостаточной коммуникации и отсутствии прозрачности.
-
Среди дата-инженеров наблюдается высокая доля осведомлённости — 7 утвердительных ответов, но также и 4 — “не знаю”.
✅ Рекомендации:
-
Провести аудит и инвентаризацию статуса назначения владельцев данных:
- Обозначить, для каких наборов данных уже есть владельцы, а где — нет.
-
Создать реестр (справочник) назначенных владельцев данных с описанием их зон ответственности:
- Этот документ должен быть доступен через корпоративную вики или портал Data Governance.
-
Поддерживать регулярную актуализацию и публичность информации о владельцах данных:
- Это уменьшит количество “не знающих” и повысит уверенность в управляемости данных.
Вопрос: Знаете ли вы, кто отвечает за качество данных в вашей области?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 7 | 12 | 1 | 0 | 2 | 1 | 23 |
Не уверен(а) | 4 | 3 | 0 | 0 | 2 | 5 | 14 |
Нет | 2 | 1 | 0 | 0 | 0 | 1 | 4 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Лишь 56% респондентов (23 из 41) уверены, кто отвечает за качество данных в их области.
-
При этом 34% (14 человек) не уверены в этом, а ещё 4 человека прямо ответили, что не знают.
-
Среди аналитиков и дата-инженеров осведомлённость относительно высокая (соответственно 7 и 12 «да»), но среди «других» ролей почти половина не уверены.
-
Такая ситуация может снижать эффективность контроля качества данных, особенно в межкомандных процессах.
✅ Рекомендации:
-
Явно назначить и задокументировать роли, ответственные за качество данных (Data Stewards):
- Назначения должны быть официальными, опубликованными и доступными для всех участников процессов.
-
Коммуникация и онбординг:
- Каждому сотруднику в команде следует понимать, кто отвечает за качество данных в смежных зонах.
-
Разработка карты ответственности за качество данных по доменам:
- В виде визуального артефакта или таблицы, закреплённой в корпоративной вики.
Вопрос: Понимаете ли вы, за какие аспекты данных вы лично отвечаете?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да, полностью | 8 | 12 | 0 | 0 | 2 | 4 | 26 |
Частично | 4 | 4 | 0 | 0 | 1 | 2 | 11 |
Не знаю | 1 | 0 | 1 | 0 | 0 | 0 | 2 |
Нет | 0 | 0 | 0 | 0 | 1 | 1 | 2 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Только 63% (26 из 41) респондента полностью понимают свою зону ответственности в отношении данных.
-
Почти 27% (11 человек) понимают её частично, что может привести к размытию ответственности.
-
Оставшиеся 10% не знают или отрицают наличие ответственности за данные — это тревожный сигнал.
-
Особенно важно, что среди менеджеров и “других” сотрудников понимание ответственности наиболее слабое.
✅ Рекомендации:
-
Провести инвентаризацию зон ответственности по данным:
- Сформировать ясные области ответственности на уровне ролей/проектов.
-
Запустить инициативу по повышению прозрачности:
- Включить описание зон ответственности в onboarding-документы и процедуры.
-
Обеспечить регулярное подтверждение понимания ролей:
- Например, через опросы, Q&A-сессии или включение темы в performance review.
Вопрос: Есть ли у вас доступ к информации о ролях и зонах ответственности по данным?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Частично | 7 | 6 | 0 | 0 | 2 | 6 | 21 |
Нет | 4 | 3 | 0 | 0 | 1 | 1 | 9 |
Да | 2 | 7 | 1 | 0 | 1 | 0 | 11 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Лишь 27% участников сообщили, что имеют полный доступ к информации о ролях и зонах ответственности.
-
Половина (51%) респондентов отметили, что информация доступна частично, что создаёт риски недопонимания и дублирования функций.
-
Почти четверть опрошенных (22%) вообще не имеют доступа к такой информации — особенно это касается аналитиков и инженеров данных.
-
Такая картина указывает на низкий уровень прозрачности в распределении ролей, что может тормозить реализацию инициатив по управлению данными.
✅ Рекомендации:
-
Создать централизованный, доступный реестр ролей и зон ответственности:
- Например, на внутреннем портале, в Confluence или Wiki-странице.
-
Обеспечить регулярное обновление и коммуникацию ролей:
- Обновления по ролям должны быть частью релизов и организационных изменений.
-
Интегрировать информацию о ролях в процессы управления данными:
- Указывать ответственных при согласовании проектов и изменениях в системах данных.
Вопрос: Насколько чётко распределены обязанности по работе с данными в вашей команде?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Очень чётко | 2 | 4 | 0 | 0 | 2 | 3 | 11 |
В целом понятно | 6 | 10 | 1 | 0 | 0 | 4 | 21 |
Размыто | 4 | 2 | 0 | 0 | 1 | 0 | 7 |
Нет распределения | 1 | 0 | 0 | 0 | 1 | 0 | 2 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Большинство участников (32 из 41) ощущают определённость в распределении обязанностей, включая «очень чётко» и «в целом понятно».
-
Тем не менее, у 22% участников (9 из 41) обязанности остаются размытыми или вовсе не распределены, что может вести к конфликтам зон ответственности и потерям в качестве данных.
-
Особенно высока чёткость восприятия у инженеров данных, а вот у аналитиков и менеджеров встречается больше неопределённости.
✅ Рекомендации:
-
Закрепить зоны ответственности по ключевым аспектам данных (качество, доступ, безопасность):
- Использовать матрицу RACI по направлениям деятельности.
-
Периодически пересматривать роли и обязанности в команде:
- Актуализировать в случае реструктуризации, новых инициатив или технологических изменений.
-
Внедрить onboarding-модуль по ролям для новых участников команды:
- Чтобы с первых дней была ясность, кто за что отвечает в области работы с данными.
Вопрос: Существуют ли конфликты ролей и зон ответственности при работе с данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Иногда | 4 | 7 | 0 | 0 | 1 | 3 | 15 |
Редко | 7 | 5 | 1 | 0 | 1 | 4 | 18 |
Никогда | 2 | 4 | 0 | 0 | 1 | 0 | 7 |
Часто | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Каждый третий участник (15 из 41) сталкивается с иногда возникающими конфликтами ролей при работе с данными.
-
Редкие конфликты также упомянуты часто (18 случаев), что в совокупности указывает на регулярную, но не критичную зону напряжения.
-
Лишь 7 респондентов сообщили об отсутствии подобных ситуаций, а часто возникающие конфликты указал только 1 участник.
-
Особенно уязвимыми кажутся инженерные и кросс-функциональные роли, где чаще всего возникает пересечение ответственности.
✅ Рекомендации:
-
Уточнить и зафиксировать зоны ответственности в критичных точках пересечения ролей:
- Примеры: Data Owners vs. Data Stewards, аналитики vs. инженеры.
-
Внедрить механизм разрешения конфликтов по зонам ответственности:
- Например, назначение “арбитров” в спорных кейсах или регулярные синки команд.
-
Проанализировать частые кейсы конфликтов:
- На основании инцидентов и ретроспектив внести корректировки в структуру ролей.
Вопрос: Насколько понятна вам разница между владельцем данных и потребителем данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Полностью понятна | 11 | 16 | 1 | 0 | 4 | 6 | 38 |
Частично понятна | 2 | 0 | 0 | 0 | 0 | 1 | 3 |
Не очень понятно | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Вообще не понятно | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Всего | 13 | 16 | 1 | 0 | 4 | 7 | 41 |
🧠 Основные выводы:
-
Абсолютное большинство (38 из 41) чётко различает роль владельца данных и потребителя, что говорит о высокой зрелости в этом аспекте.
-
Лишь 3 участника ответили, что различие понятно лишь частично — это изолированные случаи и не представляют системную проблему.
-
Ни один участник не выбрал негативные формулировки (“не очень понятно”, “вообще не понятно”), что говорит о достаточном уровне осведомлённости.
✅ Рекомендации:
-
Использовать эту зрелость как базу для дальнейшего формализма:
- Внедрение ролевой модели, основанной на чётком разграничении функций и ответственности.
-
Документировать и распространять типовые сценарии взаимодействия владельцев и потребителей данных:
- Особенно для новых участников команд.
-
Провести точечную работу с теми, кто отметил лишь частичное понимание:
- Возможно, потребуется разъяснение на уровне конкретных процессов или систем.
Вопрос: Есть ли утверждённые документы/описания ролей в области работы с данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да, есть и доступны | 4 | 5 | 1 | 0 | 0 | 2 | 12 |
Есть, но недоступны | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
Не знаю | 7 | 10 | 0 | 0 | 2 | 4 | 23 |
Нет | 2 | 0 | 0 | 0 | 1 | 1 | 4 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Лишь 30% участников (12 из 40) подтвердили наличие доступных описаний ролей, что сигнализирует о дефиците формализованной и доступной документации.
-
Самая распространённая позиция — «не знаю» (23 респондента), что указывает на низкую видимость и коммуникацию вокруг документации о ролях.
-
Единичные участники указали на то, что документы существуют, но недоступны, что также снижает практическую полезность даже при наличии описаний.
✅ Рекомендации:
-
Создать централизованное хранилище описаний ролей (например, wiki или раздел в корпоративном портале):
- Доступ должен быть открыт всем заинтересованным сторонам.
-
Провести коммуникационную кампанию:
- Проинформировать команды о существовании, целях и содержании ролевой модели в контексте Data Governance.
-
Регулярно обновлять документы и фиксировать их статус:
- Желательно назначить владельца или администратора этих описаний для обеспечения актуальности и поддержки.
Вопрос: Знаете ли вы, кто в вашей организации отвечает за реализацию политики Data Governance?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 5 | 6 | 1 | 0 | 1 | 2 | 15 |
Не уверен(а) | 6 | 6 | 0 | 0 | 2 | 4 | 18 |
Нет | 2 | 3 | 0 | 0 | 1 | 1 | 7 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Лишь 38% респондентов (15 из 40) знают, кто отвечает за реализацию политики DG — это говорит о недостаточной прозрачности распределения ответственности на организационном уровне.
-
Почти половина участников (18 человек) не уверены, что указывает на необходимость улучшения коммуникации и визуализации оргструктуры DG.
-
Остальные открыто признают, что не знают, кто отвечает за политику DG, включая представителей инженерных и управленческих ролей.
✅ Рекомендации:
-
Обеспечить публичную видимость ключевых ролей в DG:
- Разместить имена и зоны ответственности ответственных за политику DG на корпоративном портале.
-
Провести краткие встречи/брифинги в командах:
- Обозначить, кто за что отвечает в рамках политики DG, как с этими людьми взаимодействовать, в каких случаях и по каким каналам.
-
Добавить блок про роли и ответственных в материалы по обучению и онбордингу:
- Особенно важно для новых сотрудников и смежных команд.
Вопрос: Насколько легко вам определить, кто ответственный за конкретный набор данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Очень легко | 1 | 1 | 0 | 0 | 0 | 1 | 3 |
Скорее легко | 6 | 5 | 1 | 0 | 2 | 0 | 14 |
Скорее сложно | 6 | 8 | 0 | 0 | 2 | 4 | 20 |
Очень сложно | 0 | 1 | 0 | 0 | 0 | 2 | 3 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Только 17 из 40 респондентов (43%) отметили, что им легко определить ответственного за конкретные данные.
-
Половина участников (20 из 40) сталкиваются со сложностями в этом вопросе, особенно инженеры и аналитики, что может тормозить решения инцидентов и запуск инициатив.
-
3 респондента указали, что определить ответственного — очень сложно, при этом ни один из них не относится к управленческому звену, что может говорить о разрыве между операционными и управляющими уровнями.
✅ Рекомендации:
-
Внедрить справочник владельцев данных:
- С возможностью фильтрации по доменам, системам и ключевым наборам данных.
-
Регулярно обновлять и распространять матрицу ответственности (RACI):
- Обеспечить доступность для всех команд.
-
Упростить доступ к этой информации через BI/вики/чат-бот:
- Например, добавить поиск владельцев данных по ключевым словам или тегам.
Вопрос: Есть ли команда или роль, ответственная за проверку корректности данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 4 | 6 | 0 | 0 | 0 | 2 | 12 |
Частично | 4 | 4 | 0 | 0 | 2 | 2 | 12 |
Не знаю | 3 | 3 | 0 | 0 | 0 | 2 | 8 |
Нет | 2 | 2 | 1 | 0 | 2 | 1 | 8 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Только 30% респондентов (12 из 40) уверены, что существует назначенная роль или команда, проверяющая корректность данных.
-
Ещё 12 участников указали на частичное наличие ответственности, что указывает на неформализованные или нефиксированные процессы.
-
Оставшиеся 40% (16 человек) либо не знают, либо прямо заявляют об отсутствии таких ролей, что создаёт риски для качества данных и подрывает доверие к ним.
-
Менеджеры особенно неоднородны в ответах — от “нет” до “частично”, что говорит о необходимости выравнивания понимания в управленческом звене.
✅ Рекомендации:
-
Формализовать роли, связанные с контролем качества данных:
- Внедрить или обозначить
Data Quality Owner
или аналогичную позицию в рамках RACI.
- Внедрить или обозначить
-
Обеспечить прозрачность обязанностей через документацию и коммуникацию:
- Отразить ответственность в Confluence
-
Регулярно информировать команды о назначенных ролях:
- Через чаты, рассылки или дашборды в системах контроля качества данных.
Вопрос: К вам обращаются по вопросам, связанным с управлением данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Иногда | 6 | 8 | 1 | 0 | 2 | 2 | 19 |
Редко | 4 | 3 | 0 | 0 | 1 | 3 | 11 |
Никогда | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
Регулярно | 2 | 4 | 0 | 0 | 1 | 2 | 9 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Половина участников (19 из 40) отметила, что иногда к ним обращаются по вопросам DG, что говорит о наличии неформальной экспертности, но отсутствия устойчивого процесса.
-
Только 9 человек указали на регулярные обращения, и в основном это аналитики и инженеры, что подтверждает их роль как ключевых носителей знаний о данных.
-
11 человек сообщили, что обращения случаются редко, что может сигнализировать об ограниченном взаимодействии между ролями или недостаточной осведомлённости коллег о точках входа.
-
1 человек вообще никогда не сталкивался с подобными запросами, что, впрочем, не является критичным при общем объёме выборки.
✅ Рекомендации:
-
Создать публичный перечень компетентных лиц по вопросам DG:
- Например, в виде “справочника экспертов” или ответственных в рамках бизнес-областей.
-
Назначить координаторов в каждой ключевой роли (data steward, owner):
- Это повысит узнаваемость и упростит маршрутизацию запросов.
-
Периодически напоминать, к кому можно обращаться:
- Через onboarding материалы, DG рассылки, внутренние порталы.
Вопрос: Как часто вы взаимодействуете с владельцами данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Регулярно | 3 | 5 | 1 | 0 | 2 | 0 | 11 |
В случае необходимости | 8 | 7 | 0 | 0 | 2 | 6 | 23 |
Очень редко | 2 | 2 | 0 | 0 | 0 | 1 | 5 |
Никогда | 0 | 1 | 0 | 0 | 0 | 0 | 1 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Регулярное взаимодействие с владельцами данных присутствует у 11 участников, что является позитивным индикатором встроенности ролей владельцев данных в операционные процессы.
-
Большинство (23 из 40) взаимодействует по мере необходимости, что указывает на нерегулярный и, вероятно, реактивный характер общения.
-
5 респондентов сообщили о редком взаимодействии, а 1 — об отсутствии такового, что может сигнализировать о пробелах в видимости или доступности ролей владельцев данных.
✅ Рекомендации:
-
Формализовать механизмы взаимодействия с владельцами данных:
- Создать понятные маршруты обращения, шаблоны запросов, каналы коммуникации.
-
Повысить видимость ролей владельцев данных:
- Отображать в глоссариях, каталогах данных, на внутренних страницах подразделений.
-
Поддерживать регулярность коммуникации через ритуалы:
- Например, ежемесячные сессии Q&A, участие владельцев данных в демо и ретроспективах.
Вопрос: Знаете ли вы, кто отвечает за обновление метаданных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Нет | 6 | 5 | 0 | 0 | 2 | 4 | 17 |
Частично | 7 | 6 | 0 | 0 | 2 | 1 | 16 |
Да | 0 | 4 | 1 | 0 | 0 | 2 | 7 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Только 7 из 40 участников (18%) уверены, кто отвечает за обновление метаданных — это крайне низкий уровень осведомлённости.
-
Половина респондентов (17 из 40) вообще не знает, кто несёт ответственность, особенно среди аналитиков и инженеров.
-
Ещё 16 ответов — частичное понимание, что может указывать на недостаточную формализацию или слабую коммуникацию.
✅ Рекомендации:
-
Определить и задокументировать ответственных за обновление метаданных по ключевым наборам данных.
- Информация должна быть легко доступна в каталогах данных и wiki.
-
Коммуницировать роли и зоны ответственности по метаданным через onboarding и обучающие материалы.
- Включить в базовые тренинги по работе с данными и платформой.
-
Настроить системные оповещения или отчёты по устаревшим метаданным, чтобы стимулировать регулярное обновление и видимость задач.
Вопрос: Как определяется, кто должен решать проблемы с качеством данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Установлен процесс | 2 | 9 | 0 | 0 | 0 | 2 | 13 |
Решается по ситуации | 6 | 5 | 1 | 0 | 4 | 3 | 19 |
Не определено | 3 | 1 | 0 | 0 | 0 | 0 | 4 |
Не знаю | 2 | 0 | 0 | 0 | 0 | 2 | 4 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Только треть опрошенных (13 из 40) указали, что существует установленный процесс решения проблем с качеством данных. Это тревожный сигнал о слабой институционализации практики data quality management.
-
Половина респондентов (19 человек) указали, что решение таких проблем зависит от ситуации, что говорит о высокой степени неформальности и рисках дублирования или игнорирования задач.
-
Ещё 8 человек не знают или заявляют об отсутствии определённости, что усиливает риск “ничейных” данных и потери качества.
✅ Рекомендации:
-
Формализовать процесс реагирования на инциденты качества данных:
- Зафиксировать роли (data owner, steward) и регламент в случае обнаружения проблем.
-
Внедрить централизованный процесс и маршрутизацию инцидентов по качеству данных:
- Возможно в рамках Jira или аналогичного инструмента.
-
Обеспечить прозрачность — где и как можно зафиксировать проблему с качеством, и кто её увидит:
- Это может быть часть роли data steward’а или специализированной команды контроля качества.
Вопрос: Насколько формализована передача ответственности при увольнении вашего коллеги?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Формализована полностью | 2 | 0 | 1 | 0 | 1 | 0 | 4 |
Частично формализована | 5 | 8 | 0 | 0 | 1 | 1 | 15 |
Неформализована | 1 | 4 | 0 | 0 | 2 | 2 | 9 |
Не сталкивался(ась) | 5 | 3 | 0 | 0 | 0 | 4 | 12 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Лишь 10% респондентов (4 из 40) уверены, что передача ответственности полностью формализована.
-
Наиболее типичный сценарий — частичная формализация (15 ответов), что может создавать риски потери ответственности или знаний.
-
23% опрошенных (9 человек) прямо указали на отсутствие формализации процесса.
-
Почти треть респондентов (12 человек) не сталкивались с подобной ситуацией, что может говорить как о низкой текучести, так и о недостаточной вовлечённости в процессы передачи данных.
✅ Рекомендации:
-
Создать стандартизированную процедуру передачи ответственности:
- С чек-листами и фиксированными шагами при увольнении/смене роли.
-
Формализовать Knowledge Transfer:
- Например, через обязательные handover-сессии, заполнение карточек роли/ответственности, обновление реестра владельцев данных.
-
Интегрировать процесс в HR- и IT-операции:
- Включить в offboarding-процессы автоматическое уведомление data governance координаторов или владельцев доменов.
Вопрос: Принимаете ли вы участие в определении ролей и обязанностей по данным?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да | 0 | 1 | 1 | 0 | 2 | 1 | 5 |
Иногда | 5 | 4 | 0 | 0 | 1 | 3 | 13 |
Нет | 8 | 10 | 0 | 0 | 1 | 3 | 22 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
Только 5 из 40 участников прямо вовлечены в формирование ролей и обязанностей по данным — это всего 12.5%.
-
Более половины опрошенных (22 человека) не участвуют в этих процессах вовсе.
-
Роль аналитиков и инженеров данных остаётся преимущественно операционной, без участия в управленческих решениях.
-
Менеджеры вовлечены заметно больше, чем другие группы, но всё ещё недостаточно для зрелой системы распределения ответственности.
✅ Рекомендации:
-
Вовлекать ключевых специалистов (особенно data engineers и analysts) в процессы определения ролей:
- Это повысит принятие ролей и снизит конфликты зон ответственности.
-
Формализовать подход к ролевой модели:
- Чётко определить, кто и на каком уровне должен участвовать в определении ролей и обязанностей.
-
Установить регулярные ревью и обновление ролевой структуры:
- Особенно при изменении процессов, данных или командной структуры.
Вопрос: Кто в вашей команде принимает решения по вопросам владения данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Руководитель команды | 5 | 7 | 0 | 0 | 2 | 3 | 17 |
Владельцы данных | 4 | 4 | 0 | 0 | 0 | 1 | 9 |
Не знаю | 2 | 1 | 0 | 0 | 0 | 2 | 5 |
Нет конкретного лица | 2 | 3 | 1 | 0 | 2 | 1 | 9 |
Всего | 13 | 15 | 1 | 0 | 4 | 7 | 40 |
🧠 Основные выводы:
-
В 42.5% случаев (17 из 40) решения по владению данными принимает руководитель команды, что может говорить о низкой формализации роли data owner.
-
В 22.5% случаев решения действительно принимаются владельцами данных, что является целевым поведением в зрелых DG-практиках.
-
Почти четверть респондентов (14 из 40) либо не знают, кто принимает такие решения, либо указали, что ответственный не определён.
-
Среди менеджеров и аналитиков наблюдается неопределённость в структуре ответственности.
✅ Рекомендации:
-
Формализовать модель владения данными:
- Зафиксировать, что именно владельцы данных, а не руководители команд, принимают решения по своим наборам.
-
Провести коммуникационную кампанию по разграничению ролей:
- Уточнить, кто такие владельцы данных, как они назначаются и какую ответственность несут.
-
Выделить ответственность за обучение и координацию владельцев данных:
- Возможно, через роль Data Steward или координатора DG.
Вопрос: Есть ли в вашей команде ролевые конфликты, связанные с управлением данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Никогда | 9 | 9 | 1 | 0 | 2 | 2 | 23 |
Редко | 2 | 2 | 0 | 0 | 1 | 4 | 9 |
Иногда | 2 | 3 | 0 | 0 | 1 | 1 | 7 |
Да, часто | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Всего | 13 | 14 | 1 | 0 | 4 | 7 | 39 |
🧠 Основные выводы:
-
59% участников (23 из 39) заявляют, что никогда не сталкивались с ролевыми конфликтами — это позитивный сигнал о стабильной распределённости ответственности.
-
При этом, около 41% респондентов упомянули редкие или периодические конфликты, что указывает на наличие зон риска.
-
Особенно часто конфликты упоминаются у инженеров данных и аналитиков, что может быть связано с пересечением в зонах ответственности.
✅ Рекомендации:
-
Провести диагностику точек пересечения ролей в командах:
- Особенно среди аналитиков и инженеров, где чаще фиксируются конфликты.
-
Обновить или разработать матрицу ответственности (RACI):
- Это поможет устранить неясности и снизить риск конфликтов на пересечении задач.
-
Внедрить механизм эскалации и разрешения ролевых споров:
- Включая назначенного координатора или data steward, наделённого функцией урегулирования.
Вопрос: В каких системах зафиксированы роли и ответственность по данным?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Wiki / документация | 8 | 11 | 1 | 0 | 2 | 1 | 23 |
В Excel-файлах | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Не зафиксированы | 1 | 1 | 0 | 0 | 0 | 2 | 4 |
Не знаю | 4 | 2 | 0 | 0 | 2 | 3 | 11 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Wiki / документация — основной канал фиксации ролей (23 упоминания). Это положительный сигнал, особенно от аналитиков и инженеров.
-
Однако 29% респондентов (11 из 38) не знают, где зафиксированы роли — это тревожный показатель невидимости или отсутствия распространения информации.
✅ Рекомендации:
-
Обеспечить централизованный и легко доступный ресурс:
- Актуализировать Wiki/портал и обеспечить ссылки в onboarding-документах.
-
Провести коммуникационную кампанию:
- Рассказать, где искать информацию по ролям и кто за неё отвечает.
Вопрос: Как часто пересматриваются роли и обязанности, связанные с работой с данными?
📌 Количественные итоги:
Частота пересмотра | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
По мере необходимости | 10 | 11 | 1 | 0 | 2 | 3 | 27 |
Очень редко | 2 | 2 | 0 | 0 | 1 | 1 | 6 |
Никогда | 1 | 1 | 0 | 0 | 1 | 1 | 4 |
Регулярно (ежеквартально / ежегодно) | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Роли и обязанности пересматриваются преимущественно по мере необходимости — так ответили 71% респондентов. Это указывает на реактивный, а не проактивный подход к управлению ролями.
-
Только один участник указал на наличие регулярного пересмотра, что говорит об отсутствии формализованного процесса review/ревизии.
-
10 человек (26%) считают, что роли пересматриваются очень редко или вообще никогда, что может способствовать накоплению неактуальной информации и ролевым конфликтам.
✅ Рекомендации:
-
Внедрить регулярный цикл ревизии ролей:
- Привязать к корпоративному календарю: ежегодный аудит ролей или пересмотр при изменении бизнес-процессов.
-
Создать артефакт (матрицу ролей и обязанностей):
- С отображением частоты пересмотра, ответственных за обновление и источников изменений.
-
Внедрить автоматизированные напоминания или задачи в трекере (Jira):
- Чтобы не забывали проверять релевантность описанных зон ответственности и назначений.
Вопрос: Проводилось ли обучение по ролям и обязанностям в Data Governance?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Нет | 7 | 4 | 1 | 0 | 2 | 3 | 17 |
Не знаю | 4 | 7 | 0 | 0 | 1 | 1 | 13 |
Частично | 1 | 3 | 0 | 0 | 1 | 1 | 6 |
Да | 1 | 0 | 0 | 0 | 0 | 1 | 2 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Обучение почти не проводилось: только 2 человека подтвердили его наличие, и ещё 6 респондентов отметили частичное проведение.
-
Более трети участников (17 ответов) прямо указали, что обучение не проводилось.
-
Значительное число респондентов не в курсе, было ли обучение (13 человек), что указывает на низкий уровень коммуникации и документирования инициатив.
✅ Рекомендации:
-
Запустить базовую обучающую программу по ролям в Data Governance:
-
Для всех участников, работающих с данными (аналитики, инженеры, менеджеры).
-
Сделать акцент на разнице между владельцами, стюардами и потребителями данных.
-
-
Документировать и сделать доступной информацию об обучении:
- Создать централизованный репозиторий или wiki-раздел с материалами.
-
Провести диагностику текущего уровня знаний команд:
- Возможно, частичное обучение проводилось, но не воспринимается как таковое из-за низкой вовлечённости.
Вопрос: Насколько удобно вам выполнять ваши обязанности, связанные с управлением данными?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Скорее удобно | 9 | 12 | 1 | 0 | 1 | 4 | 27 |
Скорее неудобно | 3 | 0 | 0 | 0 | 1 | 2 | 6 |
Очень удобно | 1 | 2 | 0 | 0 | 1 | 0 | 4 |
Очень неудобно | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Большинство (27 из 38) участников считают, что им скорее удобно выполнять обязанности, связанные с управлением данными.
-
Лишь 7 человек указали на неудобство (6 — скорее неудобно, 1 — очень неудобно), что может быть связано с отсутствием инструментов или неясностью ролей.
-
Высокий комфорт особенно характерен для аналитиков и инженеров, что говорит о более зрелых процессах или большей самостоятельности в этих ролях.
✅ Рекомендации:
-
Углублённо изучить причины неудобства для отдельных ролей (особенно среди менеджеров и прочих):
- Провести фокус-группы или анкетирование для уточнения проблем (инструменты, процессы, документация и т.д.).
-
Поддержать и масштабировать удачные практики, где участникам удобно работать с данными:
- Выделить команды с высоким уровнем удобства и изучить их подходы, чтобы тиражировать в другие подразделения.
-
Сопоставить восприятие удобства с фактической зрелостью процессов:
- Возможно, субъективное ощущение удобства не всегда соответствует зрелым и контролируемым практикам.
Вопрос: Понимаете ли вы, как ваша роль влияет на общее качество данных?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Полностью понимаю | 8 | 12 | 1 | 0 | 3 | 4 | 28 |
Частично понимаю | 4 | 2 | 0 | 0 | 1 | 1 | 8 |
Слабо понимаю | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
Не понимаю | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
73% респондентов (28 из 38) заявили, что полностью понимают влияние своей роли на качество данных, что можно считать сильной стороной.
-
8 человек (21%) осознают свою роль частично, что даёт пространство для повышения прозрачности и просвещения.
-
Лишь 2 ответа указывают на слабое или полное непонимание, но даже они представляют риски, особенно если связаны с операционной работой с данными.
-
Вовлечённость аналитиков и инженеров — высокая, что положительно отражается на операционном контроле качества данных.
✅ Рекомендации:
-
Сделать акцент на документации и обучении для ролей с частичным или отсутствующим пониманием:
- Это особенно важно для “прочих” участников и менеджеров, где наблюдается более низкая осведомлённость.
-
Внедрить или усилить фреймворки ответственности (например, RACI):
- Для чёткого позиционирования роли каждого сотрудника в обеспечении качества данных.
-
Выделить best practices от тех, кто “полностью понимает”, и интегрировать в обучение новых и смежных ролей:
- Это может быть особенно ценно при масштабировании DG-практик и формализации ролей.
Вопрос: Есть ли согласованные правила передачи ролей и зон ответственности при изменениях в команде?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Частично | 8 | 2 | 0 | 0 | 3 | 1 | 14 |
Не знаю | 3 | 7 | 1 | 0 | 0 | 3 | 14 |
Нет | 1 | 3 | 0 | 0 | 1 | 1 | 6 |
Да | 1 | 2 | 0 | 0 | 0 | 1 | 4 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Лишь 4 участника опроса подтвердили наличие согласованных правил передачи ролей, что указывает на низкий уровень формализации процесса.
-
Самый частый ответ — «частично» (14 упоминаний) — свидетельствует о фрагментарной или неунифицированной практике.
-
Вторая по частоте категория — «не знаю» (14 ответов) — особенно выражена среди инженеров данных и аналитиков, что говорит о низкой прозрачности процесса.
-
Отсутствие чёткого протокола передачи ролей создаёт риски для непрерывности владения данными и качества управления.
✅ Рекомендации:
-
Разработать и внедрить стандарт процедуры передачи ролей и ответственности при изменениях в составе команды:
- Особенно важно при увольнении, внутреннем перемещении или масштабировании проектов.
-
Коммуницировать правила и кейсы использования через доступные каналы (wiki, onboarding-гайды, внутренние тренинги):
- Это поможет снизить процент ответов “не знаю” и повысить вовлечённость.
-
Назначить ответственных за контроль соблюдения и актуализации роли и зон ответственности:
- Например, через функцию data stewardship или участие HR/PM в процессах передачи ответственности.
Вопрос: В вашей команде есть назначенные data stewards?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Нет | 7 | 7 | 0 | 0 | 4 | 2 | 20 |
Да | 5 | 5 | 1 | 0 | 0 | 2 | 13 |
Не знаю | 1 | 2 | 0 | 0 | 0 | 2 | 5 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Более половины участников (20 из 38) указали, что в их команде нет назначенных data stewards, что говорит об отсутствии одной из ключевых ролей в рамках Data Governance.
-
Только 13 респондентов подтвердили наличие таких ролей, при этом они отсутствуют в управленческом сегменте (0 у менеджеров).
-
Незнание о существовании роли data steward отмечено в 5 ответах, в основном среди инженеров данных и других специалистов, что дополнительно подчеркивает недостаток осведомлённости и формализации.
✅ Рекомендации:
-
Внедрить роль data steward в команды, работающие с критичными наборами данных:
- Начать с пилотных областей, где уже обозначены владельцы данных или есть проблемы с качеством.
-
Обозначить задачи и зоны ответственности data steward’ов:
- Фокус на контроле качества, обеспечении документации и поддержке бизнес-глоссария.
-
Провести обучение и информационную кампанию:
- Чтобы сотрудники понимали, кто такой data steward, зачем он нужен и как взаимодействовать с ним.
Вопрос: Есть ли различия в понимании ролей между бизнесом и IT?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да, значительные | 5 | 7 | 0 | 0 | 1 | 0 | 13 |
Да, частично | 6 | 3 | 1 | 0 | 1 | 1 | 12 |
Нет | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
Затрудняюсь ответить | 2 | 4 | 0 | 0 | 1 | 5 | 12 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
25 из 38 участников (66%) отметили наличие различий в понимании ролей между бизнесом и IT, причём 13 из них указали на значительные расхождения.
-
Только 1 респондент считает, что различий нет вовсе.
-
12 человек затруднились ответить, что также может свидетельствовать о недостаточной коммуникации и слабом вовлечении бизнес-стороны.
✅ Рекомендации:
-
Провести совместную сессию по выравниванию ролей и ожиданий между бизнесом и IT:
- С фокусом на функциях владельцев данных, аналитиков и ИТ-исполнителей.
-
Зафиксировать и визуализировать распределение ролей в формате RACI или аналогичной матрицы:
- Это позволит устранить недопонимание и повысить прозрачность.
-
Интегрировать единые определения и роли в корпоративные документы, вики и onboarding-процессы:
- Сформировать единое понимание ролей в области данных на уровне всей организации.
Вопрос: Вовлечены ли владельцы данных в процесс принятия решений?
📌 Количественные итоги:
Ответ | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Да, всегда | 6 | 6 | 1 | 0 | 2 | 3 | 18 |
Иногда | 3 | 5 | 0 | 0 | 1 | 2 | 11 |
Редко | 4 | 2 | 0 | 0 | 1 | 0 | 7 |
Никогда | 0 | 1 | 0 | 0 | 0 | 1 | 2 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Лишь 18 из 38 опрошенных (47%) считают, что владельцы данных всегда вовлечены в принятие решений, остальные 53% отметили более низкую степень участия.
-
Почти каждый третий участник (11 ответов) указал, что вовлечение происходит лишь периодически.
-
В 9 случаях (7 “редко” и 2 “никогда”) зафиксировано фактическое отсутствие устойчивого участия data owners в процессе принятия решений, что говорит о слабой институционализации их роли.
✅ Рекомендации:
-
Укрепить участие владельцев данных в жизненном цикле решений, особенно на этапах согласования требований и оценки качества данных.
-
Определить формальные точки вовлечения владельцев данных в процесс принятия решений (например, через схемы участия в steering committees).
-
Оценить текущие практики и внедрить KPI/метрики вовлечённости владельцев данных для отслеживания прогресса.
-
Повысить осведомлённость руководства и команд о роли и ценности владельцев данных — через кейсы и внутренние коммуникации.
Вопрос: Что бы вы хотели улучшить в распределении ролей и обязанностей в области Data Governance?
📌 Количественные итоги:
Инициатива | Analytics | Data Engineers | Data Scientists | Business | Managers | Others | Итого |
---|---|---|---|---|---|---|---|
Провести обучение | 5 | 4 | 0 | 0 | 2 | 4 | 15 |
Назначить ответственных по всем наборам данных | 4 | 10 | 0 | 0 | 2 | 2 | 18 |
Сделать роли прозрачнее | 4 | 0 | 0 | 0 | 0 | 0 | 4 |
Обновить описания ролей | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
Всего | 13 | 14 | 1 | 0 | 4 | 6 | 38 |
🧠 Основные выводы:
-
Наиболее часто упоминаемая мера — необходимость формального назначения ответственных за все наборы данных (18 ответов), особенно от инженеров данных.
-
15 респондентов отмечают потребность в обучении, что подтверждает предыдущие сигналы о недостаточной осведомлённости и понимании ролей.
-
Проблема непрозрачности ролей отмечена аналитиками, но не поддержана другими группами, что может говорить о различии в восприятии.
-
Обновление описаний ролей почти не встречается среди ответов, что может указывать либо на незнание их существования, либо на более насущные первичные проблемы.
✅ Рекомендации:
-
Формально назначить ответственных за ключевые наборы данных и внести данные в корпоративные справочники или каталоги.
-
Организовать обучающие сессии по ролевой модели DG с кейсами и примерами для разных типов команд.
-
Разработать и опубликовать понятные описания ролей, сопровождая их визуальными схемами взаимодействия.
-
Обеспечить доступ к актуальной информации о ролях в централизованном ресурсе (wiki, каталог, портал).