Проектируем систему, а не “лепим из того, что было”
Хотел накидать мысли, но по итогу получилось сложновато. Поэтому постараюсь в нескольких простых словах изложить суть в виде вывода, и поэтому поставил его вначале.
Выводы:
- Прежде чем решать проблемы в аналитике нужно взглянуть на систему в целом.
- Нужно прогрузиться в проблему и в то, как будут использоваться результаты.
- Данные для анализа должны обрабатываться по единым правилам, чтобы быть сопоставимыми.
- Нужно заставить сотрудников работать с аналитикой, особенно при принятии решений.
- Система должна меняться вместе с изменением рынка и “окружающей среды”.
Основной блок:
Мой опыт показывает, что нужно начать с проектирования системы анализа данных, а не на решении отдельных задач.
А. Эйнштейн сказал:
“Никакую проблему невозможно решить на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень“
Это означает, что мы рассматриваем не только алгоритмы и инструменты, но и всю экосистему: источники данных, процессы их обработки, хранение, визуализацию, потребление результатов и, главное, взаимодействие всех этих компонентов. Ошибки, с этой точки зрения, — это не просто неверные выводы, а недостатки архитектуры системы, которые приводят к систематическим проблемам.
1. Ошибка постановки задачи: “Решаем не ту проблему” (или “Решаем проблему не теми ресурсами”).
Суть проблемы: Неправильная постановка задачи приводит к созданию системы, которая либо решает неактуальную проблему, либо не способна решить поставленную задачу из-за фундаментальных ограничений. Это может быть связано с неверной оценкой потребностей бизнеса, неполным пониманием имеющихся данных или неправильным выбором технологий.
Как избежать:
- Глубокий анализ потребностей: Проведите тщательный анализ того, что нужно заказчику. Это может быть компания в целом, тогда вопрос как это соотносится с достижением целей компании. Задайте вопросы, хотя бы:
Что мы хотим решить?
Почему мы думаем, что наше решение повлияет на проблему?
Как люди будут этим пользоваться?
Используйте метод 5 Почему.
- Прототипирование: Прежде чем строить полноценную систему, создайте прототип (MVP – Minimum Viable Product), который решает ограниченный набор задач на небольшом объеме данных. Это позволит проверить жизнеспособность решения и выявить потенциальные проблемы на ранней стадии. Это может быть ретроспективная аналитика, это может быть A\B тестирование.
- Оценка масштабируемости: Убедитесь, что выбранные технологии и архитектура смогут справиться с ростом объемов данных, количества пользователей и сложности задач в будущем. Рассмотрите различные сценарии нагрузки и выберите решения, которые обеспечат необходимую производительность и отказоустойчивость.
- Оценка доступности данных: Определите, какие данные необходимы для решения задачи, доступны ли они, и в каком качестве. Если необходимых данных нет, продумайте, как их можно получить или заменить. Рекомендую, подумать, а какие данные нужны будут в будущем.
- Выбор правильного инструментария: Инструментарий должен соответствовать задачам, и ограничениям.
2. Ошибки в процессе анализа: “Несвязанный зоопарк” (вместо единой системы).
Суть проблемы: Данные хранятся в разрозненных источниках, процессы обработки не стандартизированы, инструменты не интегрированы между собой. Это приводит к “ручному труду”, дублированию данных, несогласованности информации и, как следствие, к ошибкам и низкой эффективности.
Как избежать:
- Единая архитектура данных (Data Architecture): Спроектируйте единую архитектуру данных, которая определяет, как данные собираются, хранятся, обрабатываются и предоставляются пользователям. Определите типы хранилищ данных, форматы данных, протоколы взаимодействия.
- ETL/ELT процессы: Разработайте и автоматизируйте процессы извлечения, преобразования и загрузки данных (ETL) или извлечения, загрузки и преобразования (ELT). Используйте специализированные инструменты для обеспечения надежности и масштабируемости этих процессов.
- Документируйте: Создайте систему управления правилами и инструкциями, которая описывает структуру, происхождение, качество и правила использования данных. Это обеспечит прозрачность и упростит поиск и понимание данных.
3. Ошибки интерпретации и принятия решений: “Недоступные знания” (вместо системы поддержки принятия решений).
Суть проблемы: Результаты анализа сложно интерпретировать, они не доходят до лиц, принимающих решения, или не интегрированы в их рабочие процессы. Это приводит к тому, что ценные insights остаются невостребованными.
Как избежать:
- Заставьте сотрудников работать с данными. Спрашивайте с них за это. Без этого остальное бессильно.
- Упростите доступ: Создайте интерактивные дашборды, которые позволяют пользователям самостоятельно исследовать данные, фильтровать информацию и получать ответы на свои вопросы. Автоматизируйте создание регулярных отчетов, которые предоставляют ключевую информацию в удобном для восприятия формате.
- Системы оповещений: Настройте системы оповещений, которые информируют пользователей о важных событиях, аномалиях или достижении определенных показателей. Иногда полезно, но часто расслабляет. Держите менеджмент в тонусе.
- Обмен знаниями и опытом: Создайте базу знаний, в которой будут храниться результаты анализа, стимулируйте обмен опытом и информацией. Это позволит накапливать и использовать данные, полученные в процессе анализа данных в, казалось бы, далеких от этого местах..
3,5. Отсутствие обратной связи: “Система в вакууме” (вместо самообучающейся системы).
Суть проблемы: Система не получает обратную связь от пользователей и не адаптируется к изменяющимся условиям. Это приводит к тому, что она устаревает и перестает соответствовать потребностям бизнеса.
Как избежать:
- Система сбора обратной связи: Пользователи должны быть заинтересованы в информации. В идеале должен быть long-list, что пользователям еще нужно.
- Мониторинг использования: Отслеживайте, как пользователи взаимодействуют с системой, какие функции используют чаще всего, какие данные запрашивают. Но без п.1, это бесполезно.
- Непрерывное улучшение: Рассматривайте систему анализа данных как постоянно развивающийся продукт. Регулярно пересматривайте ее архитектуру, функциональность и производительность, чтобы она соответствовала текущим и будущим потребностям бизнеса.
Если дочитали):
В начале я сказал о том, что получилось сложновато, но это от того, что я попытался в рамках ограниченного объема рассмотреть сложный вопрос. Набросать наблюдения и знания, чтобы как-то их структурировать, для себя в первую очередь. На самом деле вопрос еще шире, и я постараюсь раскрывать его блоками в будущих своих заметках, а, возможно, напишу версию 2 этих размышлений)