ИТ, данные и CDO-функция (Data Office) в компании дистрибьюторе - Data access governance: роли, доступы и аудит
Дистрибьюторские компании работают на стыке операций поставок, складирования, продаж и финансового учёта. Эффективное управление данными и доступами стало критическим фактором устойчивости, сервиса и соответствия требованиям регуляторов. В этой главе рассматривается роль Data Office и ИТ в контексте задач управления доступами к данным (Data Access Governance) - от формулирования политики и ролей до реализации механизмов аутентификации, авторизации и аудита. Особое внимание уделяется тем данным, которые проходят через ERP, WMS/TMS, CRM, BI-платформы и Data Lake, а также интеграции со странами и контрактными условиями.
Data Office выступает как интегрирующий фактор между бизнес-единицами, ИТ и соответствием требованиям. Его задача - определить, какие данные нужны бизнесу, какие роли владеют этими данными, какие уровни доступа необходимы и как обеспечить прослеживаемость каждой операций. Это становится особенно важным в условиях многопоточных поставок, управления запасами и обработки персональных данных клиентов и контрагентов. Архитектура DAG должна сочетать современные принципы наименьших привилегий, разделения обязанностей и автоматизации процессов, сохраняя при этом возможность оперативной поддержки бизнеса.
Ключевые концепции, обсуждаемые в главе:
- роли и принципы Data Office (Data Owner, Data Steward, Data Custodian, CDO);
- архитектура и протоколы управления доступами (RBAC, ABAC, политики);
- жизненный цикл доступа: запросы, утверждения, провижининг, аудит и рекертификация;
- технические решения и интеграции с ERP, BI и данным слоем (каталогизация, линейность и мониторинг);
- аспекты соответствия (регуляторика, приватность, управление данными по контексту дистрибуции).
Краткое содержание главы
- Определение ролей Data Office в контексте дистрибутора и карта взаимодействий с бизнес-подразделениями.
- Архитектура управления доступами: модели доступа, интеграции с IAM, каталоги и политики.
- Процессы доступа, аудита и соответствия требованиям: жизненный цикл, запросы, утверждения, мониторинг.
- Практические сценарии внедрения DAG в цепочке поставок, складирования и продаж: примеры интеграции и риск-обеспечение.
- Метрики эффективности, управление изменениями и устойчивость программы DAG.
Контекст и роли в Data Office для дистрибутора
Data Office выступает как централизованная функция, координирующая стратегию данных, качество, безопасность и доступ к данным во всей организации. В условиях дистрибуции это означает согласование между подразделениями продаж, закупок, логистики, склада и финансов, а также сотрудничество с ИТ и регуляторами. Основные роли:
- CDO (Chief Data Officer)обеспечивает стратегию данных, политику и архитектуру управления данными, формулирует требования к DAG и контролирует соответствие стандартам и регуляторике.
- Data Owner (владелец данных) - представитель бизнес-подразделения, ответственный за контекст, точность и целостность данных в своей области (например, каталог продукции, данные по заказам, клиентская база). Владелец данных имеет конечную ответственность за доступ и использование данных.
- Data Steward (куратор данных) - специалист по качеству метаданных, стандартам именования, классификации и управлению качеством. Steward обеспечивает консистентность данных, наличие описаний и обеспечение соответствия политики.
- Data Custodian (хранитель данных) - специалист ИТ, который реализует технические средства доступа, хранение и защиту данных, применяет политики DAG в системах хранения и обработки.
- Data Architect/Engineer - проектирует цепочки данных, модели, интеграции, а также механизмы обеспечения журнала аудита, мониторинга и совместимости между системами.
- Data Privacy Officer/Regulatory Liaison - обеспечивает соответствие требованиям приватности и регуляторным нормам, особенно в части обработки персональных данных клиентов и контрагентов.
Для дистрибутора критически важно обеспечить четкую разделяемость обязанностей, чтобы одна и та же роль не имела возможности без контроля затронуть критически чувствительные данные и финансовые операции. Политики DAG должны допускать гибкость для быстрого реагирования на изменения в цепочке поставок и рыночной конъюнктуре, при этом сохраняя неизменность процедуры аудита и контроля.
В контексте практического применения важно проработать взаимодействие Data Office с бизнес-единицами. Например, владелец данных продукции и владелец клиентской базы должны согласовывать доступ к чувствительным данным клиентов, а владелец финансовых и закупочных данных - к финансовым прогнозам и контрактам поставщиков. Такой подход снижает риски утечки, нарушений и неправильного использования данных в операциях, включая закупку, ценообразование и маркетинговые решения.
Параллельно с организационной структурой необходимо определить объективные регламенты и процедуры: кто имеет право одобрения, какие пороги допускаются для автономного доступа, какие ситуации требуют эскалации, и как будет происходить мониторинг и сертификация доступа. Важна способность DAG адаптироваться к новым данным и источникам - например, при внедрении нового поставщика, расширении ассортимента или внедрении новой BI-среды.
Архитектура управления доступами: модели, протоколы и интеграции
Эта часть главы описывает архитектуру, которая позволяет реализовать эффективное управление доступами к данным в условиях инфраструктуры дистрибутора. Архитектура DAG должна сочетать централизованную политическую составляющую и распределённую техническую реализацию в точках входа к данным: ERP, WMS/TMS, CRM, BI, Data Lake и внешним контрагентам.
- Принципы политики доступа. В основе лежат принципы наименьших привилегий и необходимости знать. Применяются гибридные модели RBAC и ABAC. RBAC обеспечивает управляемые роли, ABAC добавляет контекст (тайминг, локацию, контрактный статус, данные из конкретной группы клиентов). В сложных случаях применяются политики на базе атрибутов и условий.
- Архитектура централизованного DAG. В основе - единый сервис управления доступами, поддерживающий централизованные политики и аудит. Такой сервис интегрируется с системами идентификации и аутентификации предприятия (IAM): Active Directory/Azure AD, SAML/OIDC, федеративные подходы и протоколы SCIM для автоматизированной выдачи и прекращения доступов.
- Интеграция с системами хранения и обработки. Данные могут храниться в ERP-системах (например, 1С или SAP), Data Lake, хранилищах данных и BI-инструментах. Взаимодействие DAG с источниками доступа осуществляется через коннекторы и политики, которые выполняются рядом с источником или через прокси-слой, обеспечивающий единое логирование и аудит.
- Каталогизация и линейность. Важна синхронизация между каталогами данных (метаданные, классификация, линейность данных). Data Catalog и Data Lineage позволяют бизнесу видеть, какие данные доступны и как они использовались, что облегчает аудит и соответствие.
- Технологические решения. В рамках DAG можно использовать открытые инструменты и коммерческие решения. В качестве примера открытого ПО применимы Apache Ranger и Apache Atlas для управления доступом в средах Hadoop/хранилищах данных и для управления метаданными. Эти инструменты позволяют централизованно задавать политики доступа и отслеживать их исполнение. В качестве IAM-решений применяются стандартные индустриальные решения: Azure Active Directory или Okta, а для интеграции с сервисами - SCIM-пр provisioning и SSO. В контексте дистрибутора также полезны технологии для маскирования данных и динамического ограничения видимости (data masking, dynamic data masking) в BI-платформах и базах данных.
- Пример архитектурной картины. Центральный DAG-сервис публикует политики доступа и хранит журналы аудита. Коннекторы к ERP/WMS/TMS/CRM обращаются к заявкам на доступ, получая решения на основе прав и контекста запроса. Каталог данных управляет описанием метаданных, линейки и классификацией. Аудит и мониторинг - часть этой же цепочки, отправляются в SIEM и регуляторные хранилища.
Важно помнить, что архитектура DAG должна быть адаптивной. В дистрибьюторской организации часто встречаются периоды пиковых нагрузок: сезонные распродажи, промо-акции, изменение цепочек поставок. Архитектура должна позволять временный расширенный доступ под контроль, без нарушения базовых политик и без риска долговременной ошибки. В качестве практического принципа можно применять концепцию “policy as code” - политики доступа сохраняются как машиночитаемые конфигурации, которые можно версионировать, тестировать и разворачивать через CI/CD.
Удаление пропусков и исключение двойной обработки данных - критично в контексте конфиденциальной информации. В контрактной и персональной информации клиентов мы применяем маскирование, партицирование доступов и ограничение по контексту. Архитектура DAG должна поддерживать эти требования изначально, чтобы не возникло ситуации, когда бизнес-аналитика недоступна из-за чрезмерно строгих ограничений, но при этом данные остаются защищёнными.
Примерные технологии и подходы (упоминание по необходимости):
- RBAC и ABAC как базовые модели управления доступом с поддержкой контекстной фильтрации и временных прав.
- SCIM и SSO для автоматизации предоставления и отзыва прав доступа при изменении статуса сотрудника.
- Apache Ranger и Apache Atlas как открытые инструменты для управления политиками доступа и метаданными в облачных и локальных дата-центрах.
- Каталоги данных и линейка для обеспечения видимости происхождения данных и их использования.
- Маскирование и минимизация доступа к данным с чувствительной информацией.
Процессы доступа, аудит и соответствие требованиям
Эта часть главы описывает жизненный цикл доступа к данным и механизмы аудита, которые необходимы дистрибьюторской компании для контроля рисков, соблюдения правовых требований и оперативной поддержки бизнеса.
- Жизненный цикл доступа. Процедуры начинаются с запроса доступа через единый сервис заявок. Владелец данных или регуляторный орган в организации согласовывают или отклоняют запрос. После утверждения доступ provisioning выполняется автоматически или вручную, в зависимости от характера данных и политики. По истечении временного окна доступ автоматически реверсируется, если он не требуется продлить.
- Роли и ответственность. Владелец данных отвечает за содержимое и корректность, steward - за качество и описание, custodian - за реализацию доступа на техническом уровне и безопасность. Команды аудита и соблюдения следят за тем, чтобы практики соответствовали политикам DAG и регуляторным требованиям.
- Утверждения доступа. Для критичных наборов данных требуется двухступенчатое одобрение: владелец данных и, в некоторых случаях, руководитель бизнеса или комиссия по управлению данными. Для менее чувствительных данных может применяться упрощённая схема на основе заранее утвержденных ролей.
- Время отклика и SLA. В условиях оперативной деятельности дистрибьютора сроки рассмотрения заявок на доступ должны быть предсказуемыми и задокументированными - например, 1-2 рабочих дня на обычные запросы и 4-8 часов для особенно чувствительных данных.
- Аудит и журналирование. Все операции доступа должны логироваться: кто запросил доступ, какие данные, какой уровень доступа, в какое время и через какой источник. Журналы должны быть доступны для анализа в SIEM и иметь возможность репликации в регуляторный архив.
- Регуляторика и соответствие. В рамках GDPR, локальных законов и отраслевых норм важно иметь каталог классифицированных данных, политику защиты приватности, процедуры уведомления о нарушениях и возможности проведения регулярной сертификации доступа.
- Мониторинг и предотвращение инцидентов. Реализуется постоянный мониторинг неожиданных изменений в правах, частое сравнение реального использования прав с политиками, и автоматические уведомления при попытках обхода ограничений или аномалий в доступе.
Важно обеспечить не только техническую защиту, но и управляемую культуру прозрачности. Регулярные обзоры доступа, сертификации привилегий и обучение сотрудников снижает риск несанкционированного использования данных и ошибок пользователя. Для дистрибьютора критически важна способность быстро выявлять и реагировать на инциденты, связанные с доступами к персональным данным клиентов и контрагентов, особенно когда данные перерабатываются в рамках маркетинга, анализа спроса и финансового планирования.
Реализация DAG в рабочей среде дистрибутора: практические сценарии
Реальные сценарии внедрения DAG в цепочке поставок и операционной среде дистрибутора приводят к конкретным решениям и задачам:
- Сценарий 1: Внедрение DAG для единицы данных по клиентам. Клиентские профили, история заказов и платежные данные должны быть доступны аналитикам с различными уровнями прав. Владелец данных определяет, какие поля клиента являются чувствительными (например, номер банковской карты - полностью закрыт, номер телефона - ограничен для маркетинга только согласно политике). Архитектура поддерживает маскирование и выборку по сегментам, не нарушая требования приватности.
- Сценарий 2: Управление доступом к данным по поставщикам и контрактам. В распоряжении есть данные контрактов, цены и условия поставок. Владелец данных - бизнес-подразделение закупок - и custodian - ИТ-операции. Политики включают разделение обязанностей: операции не могут просматривать финансовые данные, если они не являются частью контракта.
- Сценарий 3: Интеграция со схемами оплаты и финансового учета. Для сокращения риска ошибок и мошенничества доступ к финансовым данным ограничен и отслеживаем через аудит. В рамках DAG используются строгие политики доступа к финансовым данным и контроль изменений.
- Сценарий 4: Обеспечение конфиденциальности и соответствия в BI-аналитике. BI-инструменты создают безопасные представления (views) для аналитиков, которые позволяют видеть агрегированные данные, не обнажая индивидуальные записи. Политики применяются на уровне источника или через представления, чтобы предотвратить вытекание чувствительных данных в дашборды.
- Сценарий 5: Эмерджентные сценарии и временный доступ. Во время пиковых периодов возможно предоставление временного доступа для внешних консультантов или временно привлечённых сотрудников. Это должно происходить через ограниченный по времени доступ и под контролем работодателя, с автоматическим откатом по истечении срока.
- Сценарий 6: Интеграции с внешними поставщиками и контрагентами. При обмене данными с контрагентами и партнерами применяются принципы минимизации доступа, обмен данными по согласованным сценариям, защиты передаваемой информации и аудит доступа на стороне получателя.
В каждом сценарии особый акцент делается на то, как Data Office координирует требования бизнес-подразделения с техническими возможностями ИТ: настройка политик доступа, создание датасета и надлежащую документацию для регуляторной проверки. Важная практика - использование каталога данных, чтобы бизнес мог видеть не только доступ, но и контекст использования данных: цель, источник, уровень чувствительности и правила обработки. Это позволяет управлять ожиданиями и повышает доверие к данным как к активу компании.
Управление изменениями, оценка эффективности и устойчивость
Для долговременной устойчивости DAG необходима системная политика изменений и непрерывное улучшение. В условиях дистрибутора это особенно критично ввиду роста данных, изменений в цепочке поставок и регуляторных требований.
- Маджоритная зрелость DAG. В начале следует построить базовую архитектуру и процедуры, далее - развивать уровни автоматизации, расширяя охват политик к новым источникам данных и инструментам BI. Спасибо, что архитектура, политики и процессы синхронизированы между собой, достигается более эффективная работа бизнес-подразделений и повышения доверия к данным.
- Методы оценки эффективности. В качестве ключевых индикаторов применяются: среднее время обработки запроса доступа, доля доступа, прошедшего сертификацию в срок, количество нарушений политики, число инцидентов аудита и частота обновления классификаций данных. Важна и оценка влияния DAG на бизнес-показатели: точность прогнозов спроса, качество клиентских данных, уменьшение ошибок в операциях.
- Управление изменениями. При внедрении DAG необходимы обучение сотрудников, создание документации по политикам и регламентам, согласование изменений с владельцами данных и руководством. Вводятся регулярные ретривы и обновления политик на основе уроков прошлого периода и изменений в регуляторной среде.
- Устойчивость и адаптивность. Архитектура должна быть масштабируемой и устойчивой к изменениям в бизнесе. Важно обеспечить резервирование, мониторинг и процедуры восстановления после сбоев. В условиях изменений цепочки поставок и технологий, DAG должен быстро адаптироваться к новым источникам данных, новым требованиям по приватности и новым инструментам аналитики.
- Роли и ответственности при изменениях. Любые изменения в политиках доступа требуют повторной сертификации и одобрения. Меняя состав бизнес-подразделений или внедряя новую систему, следует заново определить роль Data Owner и Data Steward, чтобы поддержать актуальность контекста и правильность политики.
Особенно важна культура прозрачности и обучение сотрудников. В рамках дистрибутора обучение должно охватывать принципы DAG, практики работы с заявками на доступ, требования к безопасному обмену данными и основы аудита. Регулярные внутренние аудиты помогают выявлять слабые места и позволяют корректировать политики и процессы, прежде чем они станут источниками риска.
Key takeaways
- Data Office - это кросс-функциональная структура, объединяющая бизнес и ИТ для управления данными и доступами в рамках дистрибьюторской компании.
- Архитектура DAG должна сочетать централизованные политики и локальные реализации доступа в системах ERP, WMS/TMS, CRM, BI и Data Lake, поддерживая RBAC и ABAC.
- Жизненный цикл доступа охватывает запросы, утверждения, автоматизированный провижининг, мониторинг и периодическую рекертификацию доступа.
- Контроль аудита и соответствие требованиям - неотъемлемая часть DAG: журналирование, SIEM-интеграция, регуляторный архив и возможность оперативного реагирования на инциденты.
- Внедрение DAG в дистрибьюторе требует четкой роли владельцев данных, кураторов и хранителей, а также синхронной работы бизнес-подразделений и ИТ.
- Практические сценарии демонстрируют необходимость маскирования, сегментации и безопасного взаимодействия с контрагентами, особенно в рамках клиентских, поставщиков и финансовых данных.
- Эффективность DAG измеряется временем обработки запросов доступа, долей сертифицированных прав, уровнем соответствия и влиянием на качество бизнес-показателей.
- Важно поддерживать культуру управления данными через обучение, документацию и регулярные аудиты.
FAQ
- Что такое Data Office и зачем он нужен дистрибьютору?
Data Office - это объединение ролей и процессов, ответственных за политику данных, качество, безопасность и доступ к данным. Он нужен для обеспечения согласования между бизнесом и ИТ, минимизации рисков утечки и нарушений приватности, а также для обеспечения оперативности и прозрачности при работе с большими массивами данных в цепочке поставок и продаж. В условиях дистрибуции Data Office обеспечивает единый подход к доступу к данным по всем системам: ERP, WMS/TMS, CRM, BI и Data Lake, что упрощает аудит и соблюдение регуляторных требований.
- Какие три ключевых принципа лежат в основе DAG?
- Принцип наименьших привилегий: пользователи получают доступ только к тем данным и функциям, которые необходимы для их задач.
- Разделение обязанностей: критические операции разделяются между разными ролями, чтобы снизить риск мошенничества и ошибок.
- Прослеживаемость: все действия с данными документируются и могут быть воспроизведены для аудита и анализа.
- Как выбрать модель доступа: RBAC, ABAC или их сочетание?**
RBAC обеспечивает простоту и управляемость через роли, что хорошо подходит для стабильной структуры. ABAC добавляет контекст (права зависят от условий, таких как роль, локация, контракт и т. п.), что полезно в динамичных условиях дистрибутора. Часто применяют гибридную схему: базовые роли + контекстная фильтрация через атрибуты.
- Какие данные требуют наибольшего внимания в DAG?
Персональные данные клиентов и контрактные данные поставщиков, финансовая информация и данные по оплате. Эти наборы данных требуют строгого контроля доступа, маскирования и кросс-платформенной видимости в каталоге данных для аудита и соответствия.
- Какие техники обеспечивают соответствие приватности в BI?
Использование безопасных представлений (views) и маскирование чувствительных полей, агрегирование данных там, где возможно, и применение политики на уровне источников или представлений в BI-платформах. Каталогизация и линейка позволяют видеть, какие данные доступны пользователям анализа и какие ограничения применяются.
- Какие технологические решения целесообразно использовать в DAG для дистрибьютора?
Можно применить открытое ПО, например Apache Ranger для управления доступами и Apache Atlas для метаданных и линейности. В качестве IAM - Azure AD или аналогичные решения. В качестве механизмов интеграции - SCIM для автоматизации provisioning и SSO для единого входа. Важно выбрать набор инструментов, который хорошо работает в существующей инфраструктуре и обеспечивает аудит и совместимость с регуляторикой.
- Какова роль аудита в DAG?
Аудит служит основой для выявления нарушений политики, анализа инцидентов и обеспечения соответствия. Журналы должны быть доступны для анализа в SIEM, а ключевые политики - корректироваться на основе результатов аудита и изменений в нормативной среде.
- Как обеспечить баланс между оперативностью бизнеса и безопасностью данных?
Через политики с контекстной фильтрацией, временные доступы под надзором и автоматизированные процедуры рекертификации. Включение бизнес-процессов в политику доступа позволяет бизнесу быстро получать доступ к нужной информации, не нарушая требования по приватности и безопасности.
- Какие показатели следует включать в KPI DAG?
Среднее время обработки запросов, доля запросов, прошедших сертификацию, количество инцидентов аудита, доля прав, аннулированных по истечении срока, и влияние DAG на точность аналитических выводов. Также полезна скорость внедрения новых источников данных и соответствие новым регуляторным требованиям.
- Какие риски возникают при недостаточном DAG и как их устранить?
Риски - утечки персональных данных, нарушение контрактов, задержки в операциях и недоверие к данным. Их можно снизить через внедрение единого процесса управления доступами, регулярную сертификацию и аудит прав, обучение сотрудников, а также внедрение архитектурных механизмов просмотра и контроля доступа на уровне источников данных.
- Как начать внедрение DAG в дистрибьюторской компании?
Начните с оценки текущего состояния: какие данные существуют, где они хранятся, какие процессы обработки данных применяются и какие регуляторные требования действуют. Определите владельцев данных и создайте дорожную карту DAG с краткосрочными и долгосрочными целями. Инвестируйте в базовую архитектуру - единый DAG-сервис, интеграцию с IAM и базовые политики доступа, затем расширяйте до каталогов данных, линейности и расширенных сценариев. Обязательно внедрите пилот в одной доменной области (например, клиенты или поставщики) и постепенно масштабируйте на другие области и источники.
- Какие шаги верифицируют успех DAG в дистрибуции?
Успех оценивается через сокращение времени на обработку запросов доступа, уменьшение количества нарушений политик, повышение уверенности бизнес-подразделений в качестве данных и соблюдение требований регуляторов. Важна также устойчивость архитектуры и её способность адаптироваться к новым источникам данных и новым регуляторным требованиям. Внедрение DAG - это не одноразовое мероприятие, а непрерывный процесс улучшения, который должен сопровождаться обучением персонала и регулярной пересмотрной политикой.
Эта глава предлагает практическое и сбалансированное руководство по проектированию, внедрению и эксплуатации DAG в компании дистрибьютора. Реализация Data Access Governance требует стратегического подхода к ролям, архитектуре и процессам, а также доверия между бизнесом и ИТ. Баланс между безопасностью и оперативной необходимостью, поддерживаемый сильной культурой управления данными, обеспечивает соблюдение регуляторных требований, качество аналитики и устойчивое развитие бизнеса.
Примечание по применению технологий
- В частности, для открытых проектов можно рассмотреть Apache Ranger и Apache Atlas как инструменты для централизованного управления доступами и метаданными в среде больших данных. Они позволяют формализовать политики доступа и обеспечивать прослеживаемость в рамках DAG.
- В рамках корпоративной инфраструктуры разумно использовать существующие решения IAM (например, Azure AD) для упрощения аутентификации, единых входов и автоматизации provisioning через SCIM.
- В проекте DAG следует предусмотреть совместимость с ERP, WMS/TMS и BI-платформами: построить вертикальные коннекторы, которые поддерживают авторизацию на уровне источника данных и позволяют видеть контекст доступа в каталоге данных.
FAQ (продолжение)
13) Что включать в документацию DAG для регуляторной проверки?
Документация должна охватывать политики доступа, роли и ответственности, процессы запроса доступа и утверждения, принципы маскирования и минимизации, журналы аудита, процесс сертификации прав и эскалации, а также описание архитектуры и интеграций между системами.
14) Как обеспечить аудит без снижения производительности?
Оптимизация журналирования и архитектурные решения с асинхронной записью логов, гранулированное уровневое журналирование и выборочное отслеживание событий доступа позволяют собрать необходимые данные без заметного влияния на производительность.
15) Какие вызовы могут появиться на ранних этапах внедрения DAG?
Недостаточное вовлечение владельцев данных, противоречивые политики между бизнес-подразделениями, сложности в интеграции с существующими системами и ограниченный бюджет на внедрение. Решение - начать с ограниченного пилота, четко определить роли и политики, и постепенно масштабировать, опираясь на быстрый анализ результатов.
16) Какие пути для обучения сотрудников в контексте DAG?
Регулярные обучающие сессии по правилам доступа, практикам безопасной работы с данными, инструментам DAG и нормативной базе. Включение в процесс соответствия и аудита, использование сценариев ситуационных учений и доступ к внутренним руководствам и документации по DAG.
17) Каковы первые шаги для старта проекта DAG в компании дистрибьютора?
Определите руководство и составьте команду DAG: CDO, владельцы данных, кураторы и ИТ. Зафиксируйте базовую политику доступа и классификации данных. Подберите пилотную область (например, данные клиентов или данные поставщиков), реализуйте централизованный DAG-сервис, интегрируйте IAM и создайте первую версию каталогов и журналов аудита. После этого можно расширять функциональность и источники данных по мере готовности.
