Модуль 1. Введение в проекты по данным и типы систем
Цель модуля
Дать глубокое понимание, какие бывают типы систем работы с данными (BI, DWH, Lakehouse, MDM, DQ и др.), как они связаны друг с другом, чем различаются, и какие особенности предъявляют к техническому заданию. В этом модуле закладывается фундаментальная база, без которой невозможно правильно формировать требования и участвовать в проектировании архитектуры.
Что такое "системы работы с данными"
Под системами работы с данными понимаются информационные и программные решения, обеспечивающие сбор, интеграцию, обработку, хранение, анализ, контроль качества и визуализацию данных в организации. Такие системы объединяют данные из разных источников (учетных систем, внешних API, Excel-файлов и т. д.), обеспечивают консолидацию информации, и предоставляют доступ к аналитике, справочникам, прогнозам, метаданным и другим структурам, необходимым для принятия решений.
На практике системы работы с данными включают:
- Системы хранения и агрегации (DWH, Data Lake, Lakehouse)
- Системы аналитики и визуализации (BI)
- Системы управления качеством данных (DQ)
- Системы управления мастер-данными (MDM)
- Каталоги данных (Data Catalogs)
- Метаданные, lineage, API-шлюзы, инструменты ETL/ELT
- Системы планирования и моделирования (IBP, EPM)
Эти компоненты не всегда внедряются одновременно. На практике внедрение идет поэтапно, с фокусом на приоритетные потребности бизнеса. Однако все эти компоненты формируют общую экосистему Data Management.
Роль ТЗ в проектах по данным
Техническое задание (ТЗ) — это формализованный документ, описывающий, что именно нужно построить: какие задачи решать, какие данные использовать, как выглядит архитектура, что считается успешным результатом. В проектах по данным ТЗ имеет критическое значение, потому что:
- Проекты мультидисциплинарные: задействованы аналитики, ИТ, бизнес, интеграторы, архитекторы. Без четкого ТЗ неизбежны конфликты.
- Данные — ресурс со множественными контекстами: например, клиент в CRM и клиент в бухгалтерии — это разные сущности. ТЗ помогает согласовать определения.
- Систем много, и они тесно связаны: BI отчеты невозможны без DWH, а DWH невозможен без нормального описания источников. Без ТЗ возникает «архитектурный хаос».
В отличие от ТЗ на разработку пользовательского интерфейса или мобильного приложения, ТЗ в проектах по данным должно фиксировать:
- логические слои (какие витрины, справочники, расчетные таблицы будут созданы)
- архитектурные ограничения (on-prem/cloud, лицензии, требования ИБ)
- требования к данным: объемы, SLA обновления, уровни агрегирования
- сценарии использования и роли пользователей
- нефункциональные требования: безопасность, масштабируемость, поддержка
Без этого документа невозможно качественно провести оценку трудоемкости, выбрать платформу, согласовать сроки внедрения и ожидания сторон.
Типы систем и подходов в работе с данными
BI (Business Intelligence)
Что это: BI-системы предназначены для визуализации, анализа и принятия решений на основе структурированных данных. Они включают дешборды, отчетность, self-service аналитику.
Типовые системы: Power BI, Qlik, Tableau, FineBI, PIX BI, Looker, Superset
Фокус ТЗ:
- Какие отчеты и дашборды будут построены
- Какие витрины и источники потребуются
- Какую структуру метаданных, иерархий и показателей нужно описать
- Как будет организован доступ и drill-down
Особенности: BI не работает «в отрыве» от источников. Даже если платформа BI мощная, без хорошей архитектуры и подготовленных витрин система будет медленной и неудобной. Поэтому даже BI-проекты начинаются с описания источников, витрин, процессов загрузки.
DWH (Data Warehouse)
Что это: DWH — это централизованное хранилище данных, в котором данные из разных источников собираются, очищаются, нормализуются, агрегируются и хранятся для последующего анализа. Это основа корпоративной аналитики.
Типовые платформы: Microsoft SQL Server, Greenplum, Oracle, Snowflake, Postgres Pro, ClickHouse, SAP BW, Vertica
Ключевые особенности DWH:
- Поддержка историчности (SCD1/SCD2)
- Централизация мастер-данных и расчетов
- Возможность построения витрин для разных бизнес-функций
- Поддержка ETL/ELT процессов и автоматизации
Архитектуры DWH:
- 2-уровневая: staging + витрины
- 3-уровневая: staging → core → datamart
- Data Vault — для гибкой историзации
Что фиксировать в ТЗ:
- Источники: какие системы, по каким каналам, в каком формате
- Частота обновления и расписание ETL
- Точки входа/выхода (интерфейсы, API, FTP, файлы)
- Объемы: ежедневный прирост, полные загрузки
- Соглашения об именованиях (naming conventions)
- Требования к логике расчётов и агрегации
- Требования по SLA (доступность данных к 8 утра, 99.5% аптайм)
Частые ошибки при составлении ТЗ на DWH:
- Нет описания бизнес-правил трансформации данных
- Смешаны логические и физические требования (например, «таблица должна быть в Postgres» без указания причины)
- Отсутствие схемы архитектуры
- Недооценка объемов данных и времени ETL
Рекомендации:
- Использовать примитивы архитектуры (хаб, линк, сателлит, витрина)
- Описывать требования к качеству данных и метаданных
- Указывать механизмы контроля целостности и ошибок загрузки
Lakehouse
Что это: Lakehouse — это архитектурный подход, объединяющий свойства DWH и Data Lake. В нем сочетается масштабируемость и гибкость озер данных (Lake) с управляемостью, структурированностью и скоростью анализа хранилищ (Warehouse).
Типовые платформы: Databricks, Dremio, Snowflake (в режиме unstructured support), Amazon Athena + S3 + Glue, Microsoft Fabric
Ключевые особенности:
- Возможность работы с полу- и неструктурированными данными (JSON, изображения, логи)
- Использование форматов хранения типа Parquet, Delta Lake, Iceberg
- Разделение слоев: Bronze (сырые данные), Silver (очищенные), Gold (агрегаты)
- Встроенные механизмы версионности и транзакций (ACID на файловой системе)
Что фиксировать в ТЗ:
- Поддерживаемые форматы (CSV, JSON, Parquet, Delta и др.)
- Технологические ограничения: хранилище (S3, HDFS, ADLS), compute (Spark, Presto, SQL engines)
- Требования к latency (реакция на запрос), data freshness (свежесть)
- Варианты доступа: SQL, API, Jupyter, BI-инструменты
- Поддержка каталогов данных, версионность таблиц, дата-тайм путешествия (time-travel)
Частые ошибки:
- Попытка использовать Lakehouse как обычную DWH без понимания форматов хранения и особенностей latency
- Отсутствие требований к уровням очистки данных (Bronze/Silver/Gold)
- Пропущенные нефункциональные требования: мониторинг, failover, контроль версии таблиц
Рекомендации:
- Всегда фиксировать слои данных и их правила трансформации
- Задокументировать, кто и как имеет доступ к сырым данным
- Указать требуемые SLAs по времени доступа и обновления для каждого слоя
MDM (Master Data Management)
Что это: MDM — это система и процесс централизованного управления справочными (мастер-)данными, которые используются в разных информационных системах организации: клиентами, продуктами, подразделениями, поставщиками, единицами измерения, контрагентами и другими ключевыми сущностями.
Типовые платформы: Informatica MDM, IBM InfoSphere, Ataccama, Semarchy, TIBCO EBX, отечественные решения: Справочник.Про, Datalens МДМ, МАСТЕР-DATA
Ключевые принципы MDM:
- Единство и непротиворечивость справочной информации
- Определение владельцев данных и их ответственности
- Поддержка процессов согласования, маршрутизации, утверждения
- Версионность справочников и аудит изменений
- Распространение мастер-данных в ИС потребителей (через API, выгрузки, очереди и др.)
Когда внедряют MDM:
- Есть дубли в данных: одни и те же клиенты, товары, поставщики с разным написанием
- Частые ошибки в отчетах и расчетах из-за несогласованных справочников
- Невозможно организовать сквозной процесс, т.к. справочники различаются в системах
- Для создания витрин требуется ручная работа с Excel/ручные сопоставления
Что фиксировать в ТЗ:
- Перечень сущностей, подлежащих управлению: какие справочники, в каких разрезах
- Источники данных: кто подает значения, откуда берутся первоначальные записи
- Целевые системы: куда мастер-данные должны распространяться и в каком формате
- Правила согласования и утверждения: маршруты, роли, статусы
- Обязательные атрибуты и их типы (валидаторы, справочники, маски)
- Требования к интеграциям: API, очередь, выгрузка
- Версионность и хранение истории изменений
- Бизнес-правила валидации (например: ИНН должен быть уникальным в пределах страны)
Особенности:
- MDM — это в первую очередь процесс, а не просто система. Поэтому ТЗ должно описывать не только поля и формы, но и маршруты, роли, тайминги, автоматические уведомления.
- Часто требуется создание полноценного регламента владения данными и описание RACI-модели (кто отвечает за создание, модерацию, контроль).
Частые ошибки в ТЗ на MDM:
- Перечислены справочники, но не указано, как они формируются и утверждаются
- Нет связей между MDM и другими системами (ERP, CRM, BI)
- Нет указания, кто владелец данных, как обрабатываются конфликты
- Пропущена роль согласующих и процесс версионирования
Рекомендации:
- Четко разделять понятия: "справочник" (данные) и "процесс согласования" (workflow)
- Указывать требования к визуальному представлению, фильтрам, маскам и пр.
- Прописывать критерии качества данных и реакцию на невалидные значения
- Разграничивать роли: кто может создавать, кто утверждать, кто блокировать
DQ (Data Quality)
Что это: DQ (Data Quality) — это совокупность процессов, стандартов и технологий, направленных на обеспечение высокого качества данных, необходимых для корректной работы бизнес-процессов, отчетности и аналитики. Система контроля качества данных позволяет выявлять ошибки, пробелы, дубли, логические несоответствия и другие нарушения в информации.
Типовые платформы: Talend Data Quality, Informatica Data Quality, Ataccama, DataGalaxy, отечественные решения: Polyanalytika DQ, Datalens DQ, ФОРС DQ Suite
Основные метрики качества данных:
- Полнота (Completeness)
- Актуальность (Timeliness)
- Точность (Accuracy)
- Целостность (Integrity)
- Уникальность (Uniqueness)
- Согласованность (Consistency)
Ключевые функции DQ-систем:
- Профилирование данных (data profiling)
- Валидация и правила контроля
- Обнаружение и устранение дублей (matching/deduplication)
- Мониторинг качества во времени (dashboards, метрики)
- Рассылка уведомлений о нарушениях
- Поддержка правил на уровне источников, DWH, MDM
Что фиксировать в ТЗ:
- Какие метрики качества актуальны для данного проекта и на каких сущностях
- Источники контроля: какие таблицы и поля подлежат проверке
- Частота проверки (на загрузке, ежедневно, раз в час и т.д.)
- Форматы отчетов: визуальные панели, таблицы, рассылки
- Уровни критичности нарушений и сценарии реагирования
- Требования к журналу изменений: кто исправил, когда, по какому правилу
- Интеграция с другими системами: DWH, MDM, BI, ETL-платформами
Примеры правил DQ:
- У клиента должен быть указан ИНН и телефон
- Поле "Дата рождения" не может быть позже текущей даты
- В таблице заказов не может быть заказов без клиента
- Код региона должен соответствовать справочнику ФИАС
- ИНН и КПП должны быть уникальны в рамках юрлица
Типовые ошибки в ТЗ на DQ:
- Нет определения, какие именно правила качества применяются
- Не указана зона ответственности: кто отвечает за настройку, за отклонения
- Отсутствует процесс обработки выявленных проблем (workflow)
- Пропущена необходимость в отчётности по качеству
Рекомендации:
- Начинать с базового профилирования текущих данных до запуска проекта
- Указывать отдельно правила для критичных и некритичных нарушений
- Добавлять контрольные правила на каждом этапе цепочки: источник → staging → витрина
- Прописывать ответственность: кто видит отчёт, кто исправляет, кто согласовывает
Связь с другими системами:
- DWH: контроль корректности загрузки и трансформаций
- BI: контроль достоверности показателей на витринах
- MDM: контроль корректности справочников и атрибутов
Каталоги данных, DataOps и другие
Что это: Помимо BI, DWH, Lakehouse, MDM и DQ, в зрелой data-инфраструктуре появляются дополнительные классы систем, поддерживающих работу с метаданными, автоматизацию, сопровождение и масштабирование процессов. Они не являются основой для аналитики напрямую, но критичны для обеспечения управляемости и качества.
Каталоги данных (Data Catalogs)
Назначение: систематизировать и описывать данные, доступные в организации: что есть, где находится, кто владелец, какие правила применимы.
Типовые платформы: Alation, Collibra, Atlan, Informatica Data Catalog, Microsoft Purview, отечественные: Datalens Каталог, Поляна, DataCam.
Функции:
- Обнаружение и описание таблиц, полей, источников
- Описание lineage: откуда пришли данные и куда идут
- Классификация по тематикам и бизнес-объектам
- Назначение владельцев данных (data stewards)
- Поиск по данным: мета-информация, профили, теги
Что фиксировать в ТЗ:
- Источники, подлежащие каталогизации
- Структура карточки объекта (таблицы, поля, витрины)
- Требования к автоматическому пополнению (интеграции с DWH, BI)
- Роли и права: кто может видеть/редактировать
- Форматы импорта/экспорта метаданных
- Связь с политиками доступа, DQ и MDM
Особенности: каталог данных — это не просто справочник, а платформа взаимодействия между бизнесом и ИТ. Его важность возрастает в больших компаниях и при self-service BI.
DataOps и Orchestration
Назначение: автоматизировать и координировать процессы загрузки, трансформации, публикации и проверки данных.
Типовые инструменты: Apache Airflow, dbt, Prefect, Dagster, Luigi, отечественные: Modus ETL, RT.Monitoring, Airius ETL
Функции:
- Планирование и выполнение ETL/ELT
- Управление зависимостями
- Мониторинг выполнения и ошибок
- Логирование и нотификации
- Поддержка dev/prod окружений
Что фиксировать в ТЗ:
- Сценарии оркестрации: последовательность выполнения задач
- Описание пайплайнов, узлов, параметров запуска
- Требования к перезапуску, откатам, ретраям
- Форматы логирования и интеграции с мониторингом (Grafana, Prometheus)
- SLA на завершение задач и нотификации при сбоях
Рекомендации:
- Включать пайплайны в архитектурные схемы
- Указывать уровни ответственности: кто сопровождает пайплайн, кто мониторит
- Отдельно фиксировать dev, test, stage и prod среды, если поддерживаются
AI/ML-инфраструктура
Назначение: поддержка проектов по машинному обучению, включая работу с наборами данных, моделями, фичами и метаданными.
Компоненты:
- Хранилища для фичей (feature store)
- Репозитории моделей (MLflow, SageMaker Model Registry)
- Мониторинг и аудит моделей
- CI/CD пайплайны для моделей
Что фиксировать в ТЗ:
- Требования к воспроизводимости экспериментов
- Источники данных для обучения моделей
- Форматы хранения моделей, логов и метрик
- Интеграции с хранилищем и оркестратором
- Механизмы деплоя и мониторинга моделей
Особенности:
- В проектах ML особенно важна прозрачность и контроль версий. Если в организации идет запуск data science-инициатив, это должно быть отражено в архитектурных и процессных разделах ТЗ.
Типовые ошибки при составлении ТЗ
Правильное техническое задание — основа успеха проекта. Однако на практике часто встречаются типовые ошибки, которые приводят к затягиванию сроков, перерасходу бюджета, недовольству заказчика и повторной переработке архитектуры.
Ошибка 1: Отсутствие чётко сформулированных целей и задач
Без чётко описанных целей невозможно определить границы проекта и оценить его успех. Общие формулировки вроде "улучшить аналитику" или "сделать витрину" не позволяют технической команде понять, что именно нужно.
Как исправить: формулируйте цели по SMART: измеримо, конкретно, с ориентацией на результат (например: "сократить время подготовки управленческой отчетности с 2 дней до 2 часов").
Ошибка 2: Подмена требований описанием решения
В ТЗ часто встречается: "использовать Power BI", "разработать в Oracle" — без описания, почему выбран именно этот инструмент и какие есть ограничения. Это мешает архитекторам предложить более подходящее решение.
Как исправить: описывать требования к системе, а не конкретную технологию, если выбор еще не утвержден. Указывать ограничения, если они существуют (например, лицензионные или инфраструктурные).
Ошибка 3: Недостаточное описание источников данных
Откуда приходят данные? Какого они качества? В каком формате? Кто отвечает за корректность? — отсутствие этих ответов в ТЗ блокирует запуск проекта.
Как исправить: перечислите все источники, укажите:
- тип источника (БД, Excel, API, FTP, JSON)
- ответственного за наполнение
- объём и частоту
- наличие истории
- кто владелец/куратор источника
Ошибка 4: Нет архитектурной схемы или схемы потоков данных
Даже если в голове у аналитика есть картинка, без схемы другие участники не смогут понять, как связаны компоненты. Это вызывает неоднозначность и конфликты.
Как исправить: используйте простые блок-схемы: источники → зоны загрузки → хранилище → BI. Обозначайте направления и способы передачи данных, хранилища, витрины, пользователей.
Ошибка 5: Отсутствие требований к качеству данных
Если в ТЗ не указаны критерии качества, могут быть внедрены процессы, которые не обеспечивают бизнесу достоверную аналитику.
Как исправить: для каждой критичной сущности описывать:
- какие поля обязательны
- какие значения считаются ошибочными
- допустимый уровень пропусков, дубликатов
- кто и как будет проверять корректность
Ошибка 6: Смешение уровней требований
Часто ТЗ включает как цели верхнего уровня, так и детальные технические инструкции, но в произвольном порядке. Это усложняет чтение и верификацию.
Как исправить: структурировать ТЗ по блокам: цели → область охвата → функциональные требования → нефункциональные → архитектура → сценарии → риски.
Ошибка 7: Нет описания ролей и сценариев использования
Система создается для пользователей, а в ТЗ ничего не говорится об их ролях, потребностях и сценариях использования.
Как исправить: перечислить роли пользователей и описать:
- что каждый из них делает
- к каким данным имеет доступ
- какие отчеты или витрины использует
- какие действия выполняет (согласование, ввод, экспорт, настройка)
Ошибка 8: Не указаны нефункциональные требования
Без этого можно получить систему, которая будет работать медленно, неудобно или нестабильно.
Как исправить: зафиксировать:
- SLA на доступность и обновление
- требования по безопасности и аудиту
- требования к масштабируемости и отказоустойчивости
- интеграции с мониторингом, логированием
Ошибка 9: Отсутствие границ проекта
Без ограничения области охвата проект расползается и превращается в бесконечную разработку.
Как исправить: указать:
- какие подразделения входят в проект
- какие источники охватываются
- какие данные будут включены, а какие нет
- временные рамки и фазы внедрения
Ошибка 10: Нет критериев успеха и приёмки
Как понять, что проект завершён успешно? Без чётких критериев заказчик и исполнитель могут по-разному понимать результат.
Как исправить: зафиксировать:
- что должно быть реализовано
- что считается рабочим
- как проводится приёмка
- какие метрики или показатели будут применяться для оценки результата
Примеры: хорошие и плохие формулировки требований
Разделение между "хорошими" и "плохими" требованиями часто кажется субъективным. Однако в проектах с данными критерии чёткости, полноты, однозначности и измеримости становятся особенно важными. Ниже приведены типовые формулировки и варианты, как их можно улучшить.
Пример 1. Общая цель проекта
× Плохо: "Нужно построить BI-систему для управленческой отчетности."
✓ Хорошо: "Необходимо внедрить BI-систему, обеспечивающую автоматическое построение отчетов по финансовым и операционным показателям для руководства и функциональных подразделений. Ожидаемый эффект: сокращение времени подготовки отчетности с 2 рабочих дней до 2 часов."
Пример 2. Источники данных
× Плохо: "Забирать данные из 1С."
✓ Хорошо: "Источником данных является база 1С:УПП (версия 8.3.15), размещённая на MS SQL Server. Подключение через прямой SQL-доступ, ежедневно в 03:00. Объём ежедневной выборки — до 150 тыс. строк. Ответственный за предоставление структуры — Иванов И.И., ИТ-отдел."
Пример 3. Расчёт показателя
× Плохо: "Нужно рассчитать оборачиваемость."
✓ Хорошо: "Показатель оборачиваемости рассчитывается как отношение среднего остатка ТМЦ за период к себестоимости реализованной продукции. Источник: таблица DWH.Inventory_Balance (остатки), DWH.Sales_Cost (реализация). Период — месяц, агрегирование по SKU и складу."
Пример 4. Сценарий использования
× Плохо: "Менеджер должен видеть отчёты."
✓ Хорошо: "Пользователь с ролью 'Менеджер отдела продаж' имеет доступ к дешборду 'Выручка и маржинальность по регионам'. В рамках отчета доступны фильтрация по регионам, drill-down до уровня SKU, экспорт в Excel, обновление раз в сутки."
Пример 5. Форма справочника
× Плохо: "Сделать справочник контрагентов."
✓ Хорошо: "Создать справочник контрагентов с обязательными полями: ИНН, КПП, наименование, код в 1С, страна, город. Проверка уникальности по ИНН+КПП. Реализовать согласование записей: роль 'Менеджер' — создание, 'Финансовый контролёр' — утверждение."
Пример 6. Нефункциональные требования
× Плохо: "Система должна работать быстро."
✓ Хорошо: "Среднее время ответа на типовой запрос (поиск по справочнику на 50 тыс. записей) не должно превышать 2 секунд. Витрины обновляются ежедневно к 07:00. Общая доступность BI-платформы — не ниже 99,5% в месяц."
Пример 7. Критерии приёмки
× Плохо: "Система должна быть протестирована."
✓ Хорошо: "Критерии приёмки включают: успешное прохождение 100% тест-кейсов, подтверждение загрузки данных из всех источников, формирование всех предусмотренных витрин, подтверждение работоспособности 5 ключевых дешбордов, положительная оценка от бизнес-пользователей по шкале 'удобства' не ниже 4 из 5."
Эти примеры демонстрируют, что хорошие формулировки требований всегда:
- конкретны,
- имеют контекст,
- воспроизводимы,
- привязаны к бизнес-целям,
- соотносимы с архитектурой и техническими ограничениями.
Связь между целями, требованиями и архитектурой
Одним из ключевых признаков качественного ТЗ является логическая связность всех его разделов. Бизнес-цели должны «перетекать» в требования, а те — в архитектурные решения. Несоблюдение этой связи ведёт к дублированию, противоречиям и ошибкам в проектировании.
Цели задают направление
Каждый проект по данным запускается ради конкретного бизнес-результата:
- ускорение подготовки отчетности,
- повышение достоверности информации,
- автоматизация процессов согласования,
- консолидация справочников и т. д.
Важно, чтобы эти цели были четко зафиксированы в ТЗ и стали источником формулировки требований. Например, цель "повысить достоверность отчетности" требует требований к качеству данных и валидации; цель "ускорить аналитическую отчетность" требует оптимизации SLA загрузки данных.
Требования конкретизируют цели
Каждая цель должна быть разбита на один или несколько наборов требований:
- функциональных: что должно быть реализовано (формы, отчеты, справочники);
- нефункциональных: каким должен быть результат (время отклика, частота обновления, безопасность);
- требований к данным: источники, объемы, SLA, владельцы, форматы;
- требований к архитектуре: тип хранения, механизмы трансформации, используемые платформы.
Все требования должны быть "подвязаны" к цели — если в ТЗ появляется требование, не связанное с бизнес-целью, его целесообразность вызывает сомнение.
Архитектура вытекает из требований
Описание архитектуры — это не абстрактная схема. Это логическое следствие требований:
- если нужны витрины с агрегированием по дням — значит, нужна DWH с историчностью;
- если требуется self-service BI — архитектура должна предусматривать Semantic Layer и понятные модели;
- если важна гибкость справочников — потребуется MDM с маршрутизацией согласования;
- если бизнес требует частые пересчеты — следует учитывать мощности и механизмы кеширования/инкрементальности.
Типовые подходы к выстраиванию логики
Матрица "Цель → Требование → Компонент"
|
Цель проекта |
Требование |
Архитектурный компонент |
|
Сократить время подготовки отчетности |
BI-дешборд с автообновлением к 08:00 |
BI + DWH с ночным ETL |
|
Обеспечить единый справочник клиентов |
Управление через централизованный мастер-справочник |
MDM-система |
|
Повысить качество данных |
Проверка уникальности и полноты ИНН и email |
DQ-инструмент, встроенные правила |
|
Обеспечить self-service для аналитиков |
Semantic Layer с описанием метрик и фильтрацией по ролям |
BI-инструмент + витрины |
|
Упростить аудит данных |
Отслеживание lineage от отчета до источника |
Data Catalog |
Цепочка построения:
- Цель: Повысить прозрачность складских запасов
- Требование: Отчеты по остаткам по SKU, складу, категории, ежедневное обновление
-
Архитектура:
- Источник: 1С ERP
- Загрузка: ETL в staging → трансформация в DWH
- BI-дешборды: Qlik с drill-down
- Расчетные витрины: DWH.Inventory_Mart
Связь между целями, требованиями и архитектурой должна быть:
- Явной: зафиксированной в документе или его приложении
- Проверяемой: можно проследить от задачи к реализованному решению
- Обоснованной: архитектурные решения должны опираться на требования, а не быть взяты «по привычке»
Шаблоны, инструменты, примеры успешных ТЗ
Чтобы ускорить и упростить подготовку качественного технического задания, важно не изобретать структуру с нуля, а использовать проверенные шаблоны и инструменты. Этот раздел включает практические рекомендации по шаблонам, а также реальные примеры, которые можно адаптировать под свой проект.
Структура шаблона ТЗ
-
Общие сведения
- Название проекта
- Инициатор и заказчик
- Дата составления и версия документа
-
Цели и задачи проекта
- Бизнес-цели (по SMART)
- Ожидаемые эффекты
-
Область охвата и ограничения
- Подразделения и процессы
- География
- Системы-источники и системы-потребители
- Что входит в проект, что исключено
-
Требования
- Функциональные (BI, витрины, формы, сценарии)
- Нефункциональные (производительность, SLA, безопасность)
- Требования к данным (источники, форматы, обновление, объемы)
- Требования к архитектуре (слои, компоненты, интеграции)
-
Описание пользователей и ролей
- Перечень ролей
- Сценарии использования для каждой роли
- Уровни доступа и ограничения
-
Архитектурная схема и описание потоков данных
- Блок-схемы
- Связи между компонентами
- Каналы передачи
-
План внедрения и этапы
- Предпроект, разработка, тестирование, эксплуатация
- Ответственные за этапы
-
Критерии приёмки и оценки успеха
- По каждому требованию
- Методы проверки
-
Риски и предпосылки
- Зависимости
- Ограничения инфраструктуры или лицензий
Инструменты подготовки и ведения ТЗ
- Confluence — для хранения ТЗ в виде wiki-документа
- Word/Google Docs — для формальных документов
- Draw.io, Lucidchart — для архитектурных схем
- Notion, Coda — для модульного сбора требований в распределённых командах
- Miro — для фасилитации на рабочих сессиях
- BPMN-редакторы (например, Bizagi) — для описания бизнес-процессов
Пример фрагмента ТЗ
Фрагмент: Требования к витрине выручки в DWH
Витрина DWH.Sales_Mart должна содержать показатели выручки, себестоимости, прибыли, количества продаж и скидки. Данные агрегируются по дате, региону, каналу продаж, SKU. Источники: DWH.Sales_Fact, DWH.Product_Dim, DWH.Customer_Dim. Витрина должна быть доступна в BI-платформе Qlik и обновляться ежедневно до 07:30. Поля: Date, RegionName, ChannelName, SKUCode, SKUName, Revenue, Cost, Profit, Quantity, DiscountPct.
Фрагмент: Описание источника данных из 1С
Источник — 1С:УТ 11.4, база на MS SQL Server 2017. Доступ через чтение представлений с префиксом RPT_ в схеме dbo. Обновление — ежедневно в 01:00. Ожидаемый прирост — 50 000 строк. Используемые таблицы: RPT_Sales, RPT_Customers.
Фрагмент: Сценарий использования BI
Пользователь: Руководитель направления. Сценарий: ежедневно с утра открывает дашборд "Выручка по регионам", фильтрует по ЦФО, просматривает 5 регионов с падением выручки, проваливается до SKU, экспортирует в Excel. Требуется drill-down, фильтры, возможность отправки по почте.
Примеры удачных практик
- BI-дешборды проектируются только после согласования структуры витрин в DWH
- В каждой сущности MDM фиксируется владелец и маршрут согласования
- В DQ для каждого поля критичной витрины прописано не менее 2 правил контроля
- Каждое требование из ТЗ сопровождается метрикой приёмки
- Архитектура визуализирована и согласована до старта разработки
Итог: качественное ТЗ — это не просто текст, а управляемый документ, обеспечивающий взаимопонимание между бизнесом, аналитиками, архитекторами, разработчиками и интеграторами. Использование шаблонов, примеров и инструментов позволяет избежать ошибок и существенно сократить срок проекта.
