Аналитика и большие данные на low-code без дата-инженеров: что работает, а где технологический потолок

Для бизнеса low-code аналитика — это прежде всего быстрый способ получать управленческий результат без вовлечения ИТ-команды в каждый небольшой запрос. Даже большой объём записей не становится проблемой, если источник подготовлен, а требования к обновлению остаются умеренными.

Рынок аналитических инструментов даёт противоречивые сигналы. Одни поставщики утверждают, что бизнес-подразделение закрывает девять задач из десяти самостоятельно, без единой строки кода и без обращения в ИТ-службу. Другие эксперты называют такую картину преувеличением и напоминают, что за пределами простых отчётов начинается инженерная работа, которую визуальный конструктор не выполняет.

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

В этом материале разбор построен не по принципу «за или против», а по шкале: до какой точки визуальные средства действительно снимают зависимость от специалистов по обработке информации, где начинается инженерная зона и почему граница у каждой компании проходит в своём месте. Дополнительно рассмотрены рабочая архитектура, чек-лист требований к платформе и короткая диагностика перед пилотом.

Реально ли строить аналитику и работу с большими данными на low-code без дата-инженеров

Операционная аналитика строится на визуальных конструкторах силами бизнес-пользователей: регламентные отчёты, дашборды, KPI подразделений, контроль SLA, показатели по заявкам, загрузке сотрудников и исполнительской дисциплине. Это закрывает основную массу управленческих потребностей средней компании. А вот работа с большими данными в инженерном понимании, то есть терабайтные объёмы, потоковая обработка, многоступенчатые конвейеры и промышленные модели машинного обучения, остаётся зоной профильных специалистов. Здесь low-code выступает удобным интерфейсом к тому, что уже построили инженеры, а не заменой их труда.

Даже большой набор записей не переводит задачу автоматически в инженерную зону: решающими остаются структура источника, частота обновления и требования к времени ответа.

«Low-code действительно ускоряет операционную аналитику, если источники уже описаны, данные очищены, а правила доступа настроены. Ограничения проявляются при объединении большого количества систем, потоковой обработке, собственных ML-моделях и высокой нагрузке»

Александр Воробьев, Product Owner СЭД ТЕЗИС

Практика крупных компаний подтверждает, что low-code прежде всего востребован в операционной аналитике. В отчёте Comindware и PEX за 2025 год указано: 64% организаций используют дашборды, 42% — визуализацию данных, 27% — процессную аналитику, а 31% планируют инвестировать в аналитику в течение следующего года.

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

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

На заметку: формулировка «без инженеров» корректна только для бизнес-слоя. Кто-то всё равно разворачивает платформу, настраивает подключения, разграничивает доступ и следит за нагрузкой. Меняется объём этой работы, а не сам факт её существования.

Что понимают под low-code аналитикой

Low-code аналитика — это подход, при котором логика обработки собирается в графическом редакторе из готовых блоков, а не пишется вручную целиком. Пользователь соединяет источник, шаг очистки, агрегацию и визуализацию, а платформа автоматизирует часть рутинной разработки. Документация Microsoft поясняет, что low-code опирается на знакомые пользователям с Excel конструкции, но сохраняет возможности для профессионального расширения; поэтому порог входа зависит от класса задач и конкретного продукта.

Отдельный сценарий low-code особенно полезен там, где нужно быстро проверить гипотезу, а затем передать рабочую логику в корпоративный контур с установленными правилами доступа и сопровождения.

Важно, что подход не отменяет программирование, а сокращает его долю. Типичная пропорция выглядит так: основная часть сценария собирается визуально, а нестандартные фрагменты при необходимости дописываются на SQL или Python. Наличие таких точек расширения зависит от конкретной платформы и отличает low-code от закрытого конструктора.

Хороший пример зрелого продукта этого класса даёт отечественный рынок. Платформа Loginom, по описанию и официальной документации, собирает сценарии обработки из готовых компонентов в визуальном конструкторе и закрывает цикл от консолидации данных и построения моделей до моделирования, прогнозирования, визуализации и интеграции в бизнес-процесс. В этом смысле Loginom — аналитическая low-code платформа, рассчитанная на последовательную работу с аналитическими сценариями.

Чтобы не путать классы инструментов, полезно держать перед глазами их различия:

Разница между вторым и третьим столбцами определяет судьбу проекта. Если платформа не позволяет заглянуть в сгенерированный код и дописать своё, любая нетиповая потребность превращается в заявку поставщику.

Какие задачи low-code закрывает без участия дата-инженера

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

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

Без привлечения профильного инженера уверенно закрываются следующие сценарии:

• Регламентная отчётность по процессам: заявки, обращения, договоры, закупки, согласования;
• Дашборды для руководителей с фильтрами по подразделениям, периодам и ответственным;
• Контроль SLA и сроков, включая расчёт просрочек и причин отклонений;
• Метрики исполнительской дисциплины и распределение загрузки между сотрудниками;
• Простые витрины на понятных источниках, собираемые визуальным ETL;
• Управленческие сводки для отдельных функций: финансы, персонал, сервис, продажи;
• Расчёты по расписанию с рассылкой готовых форм заинтересованным получателям.

Практический эффект low-code подхода — принципиальное сокращение цикла от постановки задачи до готового результата. Аналитик получает возможность показать первый вариант отчёта на той же встрече, где зафиксированы требования, и внести правки немедленно, не передавая задачу разработчику и не теряя контекст в цепочке согласований. По опубликованному кейсу Loginom, время проектирования сценариев в отдельном проекте сократилось примерно в десять раз по сравнению с написанием кода, как показывает кейс ТБМ.

Общий признак этих задач: источник структурирован, объём укладывается в возможности одной аналитической базы, а правила расчёта формулирует сам заказчик отчёта. Как только хотя бы одно условие нарушается, появляется потребность в инженерной поддержке.

Где проходит технологический потолок

Граница возможностей определяется не логотипом на лицензии, а двумя факторами: архитектурой информационного ландшафта и квалификацией людей, которые с ним работают. Одна и та же платформа в компании с выстроенным хранилищем закрывает почти всё, а в компании с пятнадцатью несогласованными системами упирается в потолок на первом же отчёте.

Ниже разобраны пять типовых точек, где визуального конструктора перестаёт хватать. Полезно проверить каждую заранее, до того как проект превратится в набор ручных выгрузок.

Объемы, историчность и десятки источников

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

«Пока речь идёт о срезах и агрегатах по собственной оперативной базе, серверные отчёты с соединениями и агрегацией закрывают подавляющее большинство бизнес-задач без отдельного дата-инженера. Объёмы, историчность и десятки внешних источников требуют OLAP-витрин и ETL, после чего платформа становится источником для внешнего хранилища, а не его заменой»

Денис Голдобин, управляющий директор-партнер GreenData

Здесь появляются OLAP-витрины, корпоративное хранилище и промышленный ETL с инкрементальной загрузкой. Настроить полную выгрузку способен аналитик, а вот корректно определить, какие данные изменились с прошлого запуска, и не сломать при этом историчность — задача инженерная.

Инженер данных отвечает не только за загрузку, но и за устойчивость контура: корректность инкрементов, контроль изменений схемы и восстановление после сбоев.

В такой конфигурации low-code платформа становится источником данных для внешнего хранилища и потребителем его подготовленных наборов, а не заменой хранилища. Попытка держать многолетнюю историю в транзакционной базе приложения может закончиться деградацией производительности.

Потоковая обработка и сложные конвейеры

Второй ограничитель связан со скоростью и структурой потока. Когда события поступают непрерывно, требуется брокер сообщений, буферизация, обработка отказов и гарантия доставки. Apache Kafka поддерживает публикацию, долговременное хранение и обработку потоков событий в реальном времени, однако настройка и эксплуатация такого контура остаются инженерной задачей.

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

Интерес к потоковой обработке выходит за пределы инженерного контура. Отчёт Confluent за 2025 год показывает, что 86% руководителей ИТ считают инвестиции в потоковую обработку стратегическим или важным приоритетом; доля компаний на начальном этапе внедрения выросла до 25% против 8% в 2024 году.

Отдельная сложность возникает при обогащении: значение из одной системы дополняется атрибутами из десяти других, и каждый шаг нуждается в проверке. Добавьте требования к отказоустойчивости и оптимизацию запросов под пиковую нагрузку, и объём инженерной работы становится очевидным.

Важно: визуальный редактор конвейеров снижает трудоёмкость сборки, но не снимает ответственности за поведение системы под нагрузкой. Решение о партиционировании, индексах и стратегии повторной обработки принимает человек с инженерной подготовкой.

Машинное обучение промышленного уровня

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

«Визуальный конструктор снижает порог входа, но пользователь всё равно должен сформулировать гипотезу и правильно интерпретировать результаты анализа. При этом самые сложные сценарии не стоит автоматически считать недоступными low-code: ещё в 2019 году мы настраивали ML-сценарии для маркетинга на собственном конструкторе»

Сергей Трухин, директор по продажам FIS

Промышленная модель отличается не сложностью алгоритма, а дисциплиной вокруг него. Этот комплекс практик принято обозначать термином MLOps: подготовка признаков, контроль качества обучающей выборки, валидация, отслеживание смещения данных во времени, дообучение и версионирование. Google Cloud описывает тот же контур как автоматизацию интеграции, тестирования, выпуска, развёртывания, управления инфраструктурой и мониторинга ML-систем.

Конструктор ускоряет сборку, однако не заменяет навык проектирования и проверки модели. Отдельный критерий промышленной зрелости — интерпретируемость предсказаний: бизнес-заказчик вправе требовать объяснения того, почему алгоритм рекомендует конкретное решение. Платформы с поддержкой методов визуализации вклада признаков (SHAP, LIME и аналогичных) снижают этот барьер, однако не устраняют потребность в специалисте, способном корректно интерпретировать результаты и оценить модельные риски.

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

В задачах с ИИ роль инженерной основы также сохраняется. Исследование dbt Labs за 2025 год показывает, что 70% специалистов по аналитике уже используют ИИ для разработки кода, а 38% команд планируют увеличить инвестиции в качество данных и наблюдаемость в ближайшие 12 месяцев.

В дата-инженерии это особенно заметно: инструменты могут ускорить подготовку решений, но не заменяют проектирование надёжного контура хранения и обработки.

Потребность в инженерной основе отражается и в корпоративных приоритетах: в отчёте Comindware и PEX за 2026 год указано, что 48% участников опроса назвали совершенствование инфраструктуры для работы с данными фактором, который позволил бы компании получать больше пользы от внедрения ИИ.

Показательно, что современные российские BI-платформы движутся в сторону встроенного интеллекта. В релизе Visiology 3.15, как сообщает вендор, появился помощник Cortex, который даёт бизнес-пользователям ответы без участия аналитика и снижает рутинную нагрузку на BI-команду. Такие функции расширяют самостоятельность, но не отменяют экспертизу там, где цена ошибки высока.

В сложных случаях помощь специалиста по данным по-прежнему необходима: он проверяет источники, ограничения модели и корректность применения автоматических рекомендаций.

Качество данных и мастер-данные

Четвёртый ограничитель самый недооценённый. Отчёт с безупречной визуализацией бесполезен, если в справочнике контрагентов три версии одного наименования, а часть записей пришла с пустыми обязательными полями.

Контроль качества на входе из сырых источников — это отдельная дисциплина: проверки на пропуски и дубликаты, соблюдение ссылочной целостности, правила нормализации, регламент исправления. К этому добавляются мастер-данные, то есть единые эталонные справочники, и требования регуляторов к достоверности отчётности.

В 2026 году приоритет сместился от одной скорости к сочетанию скорости и доверия к данным: отчёт dbt Labs зафиксировал, что важность доверия выросла с 66% до 83% год к году, а важность скорости — с 50% до 71%; при этом доля команд, называющих недостаток доверия к данным со стороны заинтересованных лиц ключевой операционной проблемой, снизилась с 33% до 24%.

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

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

Смежная, но самостоятельная задача — прослеживаемость преобразований на уровне отдельных полей (data lineage). Подход помогает фиксировать, какие наборы данных, задания и запуски участвуют в происхождении информации, что экономит время при изменении методики расчёта, требований регулятора или структуры источников. Зрелые аналитические платформы могут регистрировать эти зависимости автоматически; в их отсутствие любое изменение логики превращается в ручной аудит десятков связанных объектов.

Постановка задачи и интерпретация результата

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

Практика показывает, что потолок наступает раньше именно здесь. Сотрудник получает мощный инструмент, строит десяток срезов и делает вывод на основании выборки, которая не отражает реальность: исключены отменённые заявки, смешаны разные типы обращений, период сравнения выбран неудачно.

Ниже сведены типовые задачи и уровень самостоятельности, на который стоит рассчитывать:

Почему вендоры расходятся в оценках

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

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

Практическую разницу создаёт наличие логического слоя. Это описание бизнес-смысла поверх физических таблиц: паспорт показателя с формулой и владельцем, витрина с зафиксированными связями, единые определения справочников. Если такой слой есть, инструменты визуализации и подготовки работают через него, и цифры совпадают у всех потребителей.

«В большинстве low-code-платформ такая работа нереалистична, но сочетание логического слоя паспорта показателя, витрин данных, BI- и ETL-инструментов делает её возможной. Ключевое условие — чтобы эти инструменты работали через логический слой»

Игорь Простоквашин, ведущий аналитик Comindware

Зрелость этого слоя как раз и отличает продукты друг от друга. Например, у платформы Visiology вычислительное ядро было переработано полностью: как отмечает обзор, прежний OLAP-движок ViQube заменён в третьей версии на новое ядро «ДанКо» с иной внутренней архитектурой и подходом к обработке.

Вывод: спорить стоит не о low-code как подходе, а о зрелости конкретного продукта и о готовности собственного ландшафта.

Архитектура, которая работает на практике

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

Слои такой архитектуры выглядят следующим образом:

1. Источники: учётные системы, CRM, сервисные платформы, файлы, внешние сервисы;
2. Хранилище: озеро для сырых записей и аналитическая база для подготовленных наборов;
3. Логический слой: витрины данных, справочники, паспорта показателей с формулами и владельцами;
4. Визуализация: дашборды, регламентные формы, ad-hoc срезы, выгрузки в таблицы;
5. Процесс: карточка заявки или сделки, где показатель виден в момент принятия решения.

Связки в реальных проектах встречаются в двух вариантах. Первый: платформа автоматизации процессов отдаёт свои события во внешнее хранилище, а BI-система строит по ним корпоративную отчётность. Второй: BI-система публикует готовую витрину, а платформа встраивает её в интерфейс исполнителя, дополняя контекстом текущей задачи.

«Low-code не должен подменять озеро данных или аналитическую базу: тяжёлые вычисления и хранение логично оставлять в специализированных системах. Платформа через API и коннекторы забирает результат и показывает его в контексте процесса, где по этим данным принимается решение»

Юрий Востриков, генеральный директор BPMSoft (ИТ-холдинг LANSOFT)

На заметку: практическая ценность возникает не от красивой панели показателей, а от того, что цифра появляется в том экране, где сотрудник совершает действие. Отчёт, за которым нужно идти в отдельную систему, требует дополнительного шага перед принятием решения.

Что должна уметь low-code платформа, чтобы аналитика жила без дата-инженеров

Заявленные возможности поставщиков совпадают почти дословно, поэтому сравнивать стоит по проверяемым признакам. Ниже перечень требований, который удобно превратить в опросный лист для пресейла; отдельно стоит проверить дату обновления показателей и наборов:

1. Конструктор отчётов и панелей показателей с фильтрами, группировками и расчётными полями, доступный без разработки;
2. Готовые коннекторы к учётным системам, реляционным базам, файлам и внешним интерфейсам, включая типовые российские продукты;
3. Визуальный ETL с инкрементальной загрузкой, а не только полной перезаписью набора;
4. Логический слой показателей: единое определение метрики с формулой, владельцем и описанием источника;
5. Ролевой доступ вплоть до строк и отдельных полей, плюс полный аудит изменений логики расчёта;
6. Расчёт по расписанию с очередями, контролем повторов и оповещением об ошибках;
7. Возможность дописать фрагмент на SQL или Python и увидеть сгенерированный код;
8. Встраивание панелей во внешние приложения и расширение платформы собственными компонентами;
9. Предсказуемое масштабирование по числу пользователей и объёму обрабатываемых наборов;
10. Штатная выгрузка подготовленных наборов во внешнее хранилище для корпоративной отчётности;
11. Программный интерфейс (API) для запуска расчётов по внешнему сигналу, управления расписаниями и встраивания платформы в корпоративные конвейеры автоматизации;
12. Автоматическая фиксация зависимостей между объектами (lineage) для аудита и анализа влияния изменений на связанные показатели.

Проверять каждый пункт лучше на собственных источниках, а не на демонстрационном наборе поставщика. Сопоставить заявления вендоров между собой помогают независимые обзоры и рейтинги low-code платформ, BI-систем и BPM-систем, которые публикуются на портале IaaSSaaSPaaS.ru: такое сравнение экономит время на этапе формирования короткого списка и снижает риск неприятных открытий уже во время пилота.

Кто в компании реально работает с данными на low-code

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

Основных ролей три:

• бизнес-аналитик собирает витрины и отчёты;
• руководитель подразделения формулирует потребность и читает результат;
• владелец процесса отвечает за смысл показателей и их изменение вслед за регламентом.

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

От такого специалиста разумно ожидать следующего набора навыков:

• Знание предметной области и понимание, как устроен автоматизируемый процесс;
• Базовая логика структурированных наборов: таблицы, ключи, связи, гранулярность;
• Уверенная работа в визуальном конструкторе и умение переиспользовать готовые компоненты;
• Представление об интеграции: что такое коннектор, расписание обновления, инкремент;
• Желательно чтение SQL, чтобы понимать, что именно выполняет собранный сценарий.

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

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

Повторное создание компонентов из проверенной библиотеки сокращает время запуска новых сценариев и уменьшает вероятность расхождений между отчётами разных подразделений.

Риски и типовые ошибки внедрения

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

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

Важно: расхождение цифр в двух отчётах почти никогда не является программной ошибкой. В основе лежит отсутствие единого определения метрики, поэтому первым артефактом проекта должен стать реестр показателей с формулами и владельцами, а не первый дашборд.

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

Как оценить, где ваш потолок: короткая диагностика

Диагностику полезно провести до выбора продукта, потому что она определяет не только инструмент, но и состав команды. Для предварительного сопоставления вариантов можно использовать независимый рейтинг low-code-систем на IaaSSaaSPaaS.ru, а затем проверить заявленные возможности на собственных данных. Достаточно честно ответить на несколько вопросов и зафиксировать ответы письменно:

1. Объём и глубина истории. Оперативный срез за месяцы означает самостоятельную работу, многолетняя история требует хранилища;
2. Количество источников. Один-три однородных источника обычно проще подключить; десятки разнородных систем требуют оценки схем, инкрементальной загрузки, качества данных и прав доступа;
3. Требования к скорости обновления. Ночной расчёт по расписанию доступен сразу, обновление в реальном времени означает потоковую архитектуру;
4. Готовность инфраструктуры. Наличие аналитической базы и регламента загрузки резко расширяет самостоятельность бизнеса;
5. Требования регуляторов. Обязательная прослеживаемость расчёта и подтверждение достоверности переводят задачу в инженерный контур;
6. Потребность в моделях. Встроенные алгоритмы подойдут для оценок и прогнозов внутреннего использования, решения с внешними последствиями нуждаются в валидации;
7. Наличие ответственных. Если владельцы метрик не назначены, проект упрётся в организацию раньше, чем в технологию.

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

Вопросы и ответы

Чем low-code отличается от no-code в аналитике?

No-code обычно опирается на встроенные функции и готовые интеграции, а low-code предоставляет точки расширения для нестандартной логики — в некоторых продуктах через формулы, SQL, Python или программные компоненты. Граница зависит от конкретного продукта: Microsoft описывает low-code как спектр между no-code и pro-code.

Нужен ли SQL бизнес-аналитику?

Формально нет, большинство задач решается визуально. На практике чтение запросов помогает понять, почему отчёт считается медленно и откуда взялось расхождение, поэтому базовый уровень крайне полезен.

Заменит ли low-code дата-инженера?

Нет. Подход снимает с инженера рутину по сборке отчётов и типовых преобразований, освобождая время на архитектуру, оптимизацию и качество источников.

Можно ли считать большие данные внутри low-code платформы?

Умеренные объёмы, укладывающиеся в одну аналитическую базу, считаются штатно. Терабайтные наборы и потоковую обработку правильнее выносить в специализированный контур, а результат забирать через интерфейсы.

Какие российские платформы применяют для аналитики?

В обзорах рынка регулярно фигурируют Loginom, Visiology, «Форсайт», Polymatica, Modus BI, а также платформы автоматизации процессов вроде ELMA365 и Comindware. Выбор зависит от того, что важнее: подготовка наборов, визуализация или встраивание показателей в процесс.

Как искусственный интеллект меняет low-code аналитику?

Возможности зависят от платформы: одни помощники отвечают по готовым показателям, другие генерируют SQL или оформляют виджеты. Например, в анонсированной функции Cortex Визы дашборд собирается из подключённых данных по запросу на естественном языке; ответственность за постановку задачи и трактовку вывода остаётся на человеке.

Несмотря на появление таких инструментов, самостоятельная аналитика в России пока не стала массовой практикой. В исследовании СберАналитики и СберКорус, проведённом в феврале 2026 года, 39% респондентов сообщили о внедрении инструментов анализа данных в своих организациях; реальное использование BI с ИИ подтвердили 15% компаний, а 57% сотрудников имели опыт пилотных или демонстрационных проектов.

Заключение

Визуальные конструкторы забирают на себя весь бизнес-слой: отчётность по процессам, панели показателей, контроль сроков, простые витрины и регулярные расчёты. В этой зоне участие профильных специалистов действительно не требуется, а скорость получения результата измеряется днями.

За границей остаётся инженерная дисциплина, и её отменить нельзя. Многолетняя история, десятки разнородных систем, потоковая обработка, промышленные модели, качество источников и мастер-данные требуют отдельных компетенций и отдельной архитектуры. Смешивание двух зон в одном обещании и создаёт разочарование от внедрений.

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