Избегание частых подводных камней в проектах аналитики данных — практическое руководство

Последние исследования Capgemini показывают, что 15% инициатив по big data в Европе проваливаются. Чтобы войти в 85% успешных, нужно осторожно обойти самые частые подводные камни. В этом посте я охвачу первые две основные ловушки — остальные две детализированы в отдельной статье.

Эти вызовы универсальны. На наших ранних воркшопах по аналитике данных мы часто встречаем их от запуска до завершения. Опираясь на десятки успешных проектов, я опишу каждый подводный камень, объясню, почему он важен, и проиллюстрирую конкретными примерами.

1. Кто инициирует проект — IT или бизнес?

Аналитика данных и «big data» часто смешивают, но они служат разным целям. IT-команды обычно запускают проекты, потому что могут предоставить необходимую инфраструктуру — базы данных, кластеры, пайплайны. Однако простое накопление данных не создает бизнес-ценность.

Настоящая ценность возникает, когда не-IT отдел определяет четкие, коммерчески релевантные цели. Эти цели направляют data scientists фокусироваться на actionable инсайтах, а не на сырой объеме. Тесное сотрудничество между владельцами бизнеса и data scientists критично; первые дают доменные знания, вторые переводят их в модели и визуализации.

Инженеры по аналитике данных выступают мостом между IT и бизнесом. Их операционный опыт — в производстве, логистике или другой сфере — гарантирует, что данные коррелируют с реальными процессами (станки, датчики, рабочие процессы). Успех проекта зависит от этого перевода знаний.

Хотя IT часто инициирует проекты, успех зависит от активного вовлечения целевого отдела для определения конкретных технических и бизнес-целей.

2. Не все данные созданы равными

После запуска проекта, пауза. До передачи данных ученым, вы должны аудировать их качество и количество.

а) Качество данных

Оцените согласованность форматов, прозрачность источников и целостность данных. Для мульти-источника интеграции уникальный идентификатор (например, timestamp, номер детали) критичен. Берегитесь гетерогенных форматов даты/времени или несинхронизированных часов между системами — они могут испортить слияния.

б) Количество данных

Больше данных обычно преимущественно, но релевантность важна. Для предсказательных моделей, целевых на редкие события (например, отказ или дефект), ваш тренировочный набор должен содержать достаточно негативных примеров. Если датасет скошен, модель будет бороться с обучением минорного класса. Расширение окна наблюдения или аугментация данных могут смягчить эту проблему.

в) Правильные данные

Помимо объема, данные должны содержать переменные, необходимые для достижения технической цели. Например, если вы целитесь предсказать шероховатость поверхности, сырое измерение должно быть захвачено и сохранено; иначе никакая модель не может быть построена. Отсутствие критических признаков задерживает прогресс и раздувает затраты.

Обеспечение успеха проекта

Для адресации качества, количества и релевантности мы предоставляем набор гайдлайнов по качеству данных в начале проекта. Эти гайдлайны, объединенные с ранними воркшопами, фокусирующимися на quick-win кейсах, повышают осведомленность производственных экспертов и ускоряют последующие этапы.

Источник: Bosch.IO