SCQA Framework: Презентация для руководства¶
SCQA (Situation, Complication, Question, Answer) — структура для убедительных бизнес-презентаций, разработанная McKinsey.
Situation (Ситуация)¶
Что происходит сейчас¶
Компания [Название] активно использует данные для принятия бизнес-решений:
- Дашборды и отчёты: руководство ежедневно опирается на метрики продаж, склада, финансов
- Аналитика: команда из [X] аналитиков работает над инсайтами и прогнозами
- ML/AI: запущены или планируются проекты по автоматизации на основе данных
- Интеграции: данные поступают из [1С, CRM, WMS, внешних источников]
Текущие источники данных¶
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 1C │ │ CRM │ │ WMS │ │ Внешние │
│ Бухгалтерия│ │ Продажи │ │ Склад │ │ API/CSV │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
└──────────────────┴──────────────────┴──────────────────┘
│
▼
┌─────────────────────┐
│ Data Warehouse │
│ (ClickHouse/PG) │
└─────────────────────┘
│
▼
┌─────────────────────┐
│ BI / Аналитика │
└─────────────────────┘
Complication (Проблема)¶
Что идёт не так¶
Несмотря на инвестиции в данные, мы регулярно сталкиваемся с проблемами:
Инциденты с данными¶
"Цифры в отчёте за прошлый месяц оказались неверными — 1С изменила формат выгрузки, а мы узнали через 2 недели."
| Тип проблемы | Частота | Влияние |
|---|---|---|
| Неверные данные в дашбордах | 2-3 раза/неделя | Неверные решения |
| Сломанные пайплайны | 3-5 раз/месяц | Простой аналитики |
| "Кто изменил данные?" | Еженедельно | Часы на расследование |
Скрытые издержки¶
Ситуация: Аналитик тратит ~30% времени на проверку "а можно ли верить этим данным?"
При средней зарплате 150K руб./мес. и 3 аналитиках:
→ 150K × 3 × 30% = 135K руб./мес. потерь
→ 1.6 млн руб./год "мусорной работы"
Конкретные примеры (из практики клиентов)¶
- Convoy (логистика): Неверные данные в дашборде привели к $XXX,XXX расходов на ненужную маркетинговую кампанию
- Glassdoor (HR tech): Потеря рекламных доходов из-за некорректного подсчёта impressions
- Adevinta (маркетплейсы): Месяц пропущенных данных обнаружен случайно аналитиком
Корневая причина¶
Отсутствие формализованных соглашений между издателями и потребителями данных:
- Никто явно не отвечает за качество данных
- Изменения происходят без уведомления downstream
- Нет автоматической проверки breaking changes
- Документация устаревает или отсутствует
Question (Вопрос)¶
Ключевой вопрос для руководства¶
Как обеспечить надёжность и качество данных, не блокируя скорость разработки и не создавая избыточную бюрократию?
Под-вопросы¶
- Как узнавать о проблемах с данными до того, как они попадут в отчёты?
- Как чётко определить ответственность за качество данных?
- Как автоматизировать проверки вместо ручного контроля?
- Как масштабировать управление данными при росте компании?
Answer (Ответ)¶
Контракты данных (Data Contracts)¶
Data Contract — формализованное соглашение между издателем и потребителем данных, которое:
- ✅ Определяет схему данных и правила качества
- ✅ Автоматически проверяется при каждом изменении
- ✅ Фиксирует ответственного за данные
- ✅ Версионируется как код
Как это работает¶
┌─────────────────────────────────────────┐
│ GitLab /contracts │
│ ┌────────────────────────────────────┐ │
│ │ sales/orders/contract.yaml │ │
│ │ ───────────────────────────── │ │
│ │ owner: sales-team@company.ru │ │
│ │ schema: │ │
│ │ - order_id: string (required) │ │
│ │ - amount: decimal (>0) │ │
│ │ sla: │ │
│ │ freshness: 1h │ │
│ └────────────────────────────────────┘ │
└─────────────────────────────────────────┘
│
┌───────────────────┴───────────────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ CI/CD проверка │ │ Runtime валидация │
│ (при MR) │ │ (при поступлении) │
│ ────────────────── │ │ ────────────────── │
│ ✓ Схема валидна │ │ ✓ Правила качества │
│ ✓ Нет breaking │ │ ✓ prod/dlq split │
│ changes │ │ ✓ Алерты владельцу │
└─────────────────────┘ └─────────────────────┘
Результаты внедрения (из case studies)¶
| Метрика | До | После | Источник |
|---|---|---|---|
| Инциденты с данными | 15-20/мес | 3-5/мес | Convoy |
| Время обнаружения | 2-48 часов | 5-15 минут | Glassdoor |
| Время на "отладку" | 30% | 10% | Adevinta |
| PII compliance | Ручной | 40% авто | Adevinta |
Инвестиции и возврат¶
| Категория | Сумма | Срок |
|---|---|---|
| Начальные инвестиции | 600K - 1.5M руб. | Единоразово |
| Операционные расходы | 30-80K руб./мес | Постоянно |
| Экономия | 150-280K руб./мес | После пилота |
| Payback period | 4-7 месяцев |
Рекомендация¶
Запустить пилотный проект на 1-2 критичных data products:
- Срок: 6 недель
- Инвестиции: Консалтинг + 0.5-1 FTE
- Результат: Работающий PoC с измеримыми улучшениями
- Решение Go/No-Go: По результатам пилота
Приложение: Как использовать этот документ¶
Для презентации CEO/CFO (5 минут)¶
- Ситуация — 1 слайд (30 сек)
- Проблема — 1-2 слайда с цифрами потерь (1 мин)
- Вопрос — 1 слайд (15 сек)
- Ответ — 2-3 слайда (2-3 мин)
Для более глубокой дискуссии (30 минут)¶
- Использовать полный документ
- Подготовить конкретные примеры из вашей компании
- Иметь под рукой Business Case и ROI расчёты
Ключевые тезисы для запоминания¶
"Контракты данных — это не новый инструмент, это новый способ работы. Мы переходим от реактивного тушения пожаров к проактивной защите качества."
"Стоимость отсутствия контрактов — это не только деньги на зарплату аналитиков. Это неверные бизнес-решения на основе неверных данных."
"Пилот за 6 недель покажет, работает ли это для нас. Риски минимальны, потенциал — значителен."
Документ для внутреннего использования Версия: 1.0