Проблемы автоматизации аналитики: как избежать распространенных ошибок

Для автоматизации аналитики часто применяют no-code /low-code ETL-инструменты. Однако у этих инструментов есть недостаки. Правильный ли это выбор?

Внедрение автоматизированной аналитики в компании часто начинается неосознанно, благодаря энтузиазму некоторых сотрудников, которым надоедает выполнять однообразные расчеты. Когда компания осознает, что рутиные операции можно автоматизировать, она начинает внедрять no-code и low-code ETL-инструменты.

Однако у этих инструментов есть существенный недостаток: ограниченные алгоритмы для обработки данных. Так как данные часто бывают «неидеальными» (то есть они могут быть неполными, неправильно храниться или обрабатываться), готовых инструментов для решения задач вроде обработки ошибок, создания сложной логики или математических операций обычно не найти. В итоге, рано или поздно наступает момент, когда в готовых no-code и low-code ETL-решениях не находятся нужные алгоритмы обработки данных и компании снова вынуждены прибегать к ручной обработке – что ведет к необходимости перехода на более профессиональные инструменты.

Часто в компаниях переход на профессиональные ETL-инструменты осуществляется небольшой командой из 1-3 человек с недостаточным или неоднородным уровнем компетенций аналитиков и дата-сайентистов. Для полноценной работы в этом направлении нужны архитектор данных, бизнес- или системный аналитик, дата-инженер, BI-аналитик, а для сложной аналитики – дата-сайентист. Компании же нередко пытаются силами нескольких аналитиков с недостаточной квалификацией поднять архитектуры и расчетные модули.

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

Как и для любого ИT-проекта при внедрении аналитических ИТ-инструментов требуется проработка архитектурных решений, разработка интеграционных механизмов, проектирование хранилища данных и создание программных сервисов. Как правило, бизнес не обладает достаточным количеством компетенций в этой области, поэтому нужно решить следующий вопрос: создавать с нуля свою команду для внедрения и последующей поддержки аналитических ИТ-инструментов или обратиться к профильным подрядчикам.

Если у компании в планах продавать систему на рынке, либо внешние условия динамично меняются, тогда есть смысл нанимать специалистов и создавать свою команду, вложения могут быть оправданы.

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

И вот тут возникает интересный парадокс, который часто приводит к тому, что проект никогда не заканчивается. Сотрудники, которые работают на проекте понимают, что «закончить проект» означает «начать искать новую работу», так как доработка и техподдержка системы не предполагают такого количества специалистов в штате.

Сейчас во многих компаниях, которые когда-то внедряли собственные решения, связанные со сбором, хранением и обработкой данных, данные процессы начинают стагнировать. Несколько лет назад, когда специальности дата-аналитики и дата- сайентисты были на пике популярности, компании создавали свои команды и набирали специалистов. У некоторых получилось развить это направление (в основном это крупные ритейлеры и финсектор), но у многих других компаний это направление пока не получило такого развития.

Хорошая пословица для тех, кто решил пройти этот путь самостоятельно. Только за ошибки обычно расплачивается компания. Задумывались ли вы, почему новый сотрудник сразу замечает ошибки других, но вскоре его энтузиазм спадает. Это связано с тем, что изначально он видит систему «сверху», но со временем погружается в детали и утрачивает способность оценивать работу отстраненно и, следовательно, объективно.

Когда компания создает свою команду разработки и внедрения, важно понимать, что без внешней экспертизы процесс может быстро «забуксовать». Как я уже говорила выше, отсутствие знаний в разных направлениях у небольшой команды – основная причина замедления реализации проекта. Один человек не способен охватить все области сразу, особенно за короткий срок. Это приводит к затягиванию разработки, размытым результатам, а в итоге — к выгоранию и уходу ключевых специалистов.

Лучшее решение в такой ситуации — это декомпозиция процессов и поэтапное внедрение модулей системы. Это можно сделать объединив усилия внутренней команды и внешних подрядчиков. Такой симбиоз позволяет сохранить свежий взгляд на проект, улучшить динамику развития и минимизировать риски выгорания команды.

• Не ограничивайтесь только на no-code решениями — они подходят для начала, но для сложных задач потребуются более мощные инструменты.
• Четко планируйте архитектуру — без проработанной структуры данных и интеграций проект может столкнуться с трудностями.
• Определитесь, что будет оптимальнее: развивать внутреннюю команду или привлекать внешних партнеров. Если система предназначена для внутреннего пользования, лучше привлечь специалистов со стороны. Это сэкономит ресурсы и ускорит процесс внедрения. Если же планируется дальнейшее развитие продукта для выхода на внешний рынок, стоит инвестировать в создание собственной команды.
• Не растягивайте проект — внедряйте систему поэтапно, чтобы избежать затянутости и выгорания команды.