Как выбрать BI систему, если у вас «1С», Excel и хаос в данных

По данным Gartner, около 52% цифровых инициатив не достигают целевых бизнес-результатов. Основная причина – разрыв между ожиданиями руководства от новых инструментов и реальным состоянием данных и процессов внутри предприятия.

Есть и техническая проблема: большинство западных BI платформ (Power BI, Tableau, Qlik) проектировались под работу с реляционными базами, облачными хранилищами и стандартными API. Структура данных «1С» – регистры накопления, регистры сведений, планы видов характеристик – для них чужеродна.

Коннектор «из коробки» либо отсутствует, либо работает через OData с существенными ограничениями по производительности – типичный OData запрос к регистру накопления с миллионом записей в «1С» выполняется 40 120 секунд. Для сравнения: пользователь интерактивного дашборда ожидает отклик в 1–3 секунды. Если каждый клик по фильтру или детализация заставляет ждать по минуте – пользователь просто перестанут считать это инструментом и вернутся в Excel.

Как компании обычно работают с данными

Разберем типичный стек данных компании с оборотом 500 млн – 5 млрд рублей:

Ядро – «1С». Конфигурации варьируются:

• «1С:Бухгалтерия» – есть у всех, но содержит только бухгалтерские данные. Управленческая аналитика там минимальна.

• «1С:Управление торговлей» – хранит данные о продажах, закупках, складских остатках. Здесь находятся регистры «Продажи», «ЗаказыКлиентов», «ОстаткиТоваров». Обычно это основной источник информации для коммерческой аналитики.

• 1С:ERP или «1С:Комплексная автоматизация» – объединяет торговлю, производство, финансы. Здесь структура данных сложнее: регистры накопления могут содержать десятки измерений, а объем таблиц регистров доходит до 50 100 млн. записей.

• «1С:ЗУП» – зарплата и кадры. Отдельная база, с основной не синхронизирована или синхронизирована частично.

Все, что выходит за рамки учета, содержится в таблицах.

• Бюджеты и планы – финансовая служба ведет в Excel, потому что структура план факта в «1С» слишком жесткая и не поддерживает сценарное моделирование.

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

• Воронки продаж и пайплайн – их коммерческий отдел ведет параллельно с CRM.

• Операционные данные – логистика ведет графики отгрузок, маршруты доставки и загрузку производства в Excel, потому что в «1С» нет удобных инструментов для оперативного планирования с учетом ежедневных изменений.

CRM-системы (например, «Битрикс24») – хранят данные о лидах, сделках и коммуникациях. Синхронизация с «1С» обычно реализована через штатный обмен или через промежуточный сервис. Типичные проблемы:

• Сделка в CRM закрыта, а заказ в «1С» не создан (менеджер забыл).

• Заказ в «1С» создан, но привязан к другому контрагенту (ошибка при ручном заведении).

• Суммы не совпадают: в CRM – сумма без НДС и без скидки, в «1С» – с НДС и с учетом бонуса.

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

Проблемы разрозненных источников

Разрозненность данных – это не просто неудобство. Это конкретные бизнес-проблемы, которые стоят компании денег и времени:

Например, контрагент «ООО Ромашка» в базе «1С:УТ», в базе «1С:Бухгалтерии» и в CRM – это три разных сущности. Объединить данные по ним можно только через ИНН, но в CRM поле ИНН заполнено у 60% контрагентов. Остальные 40% придется сопоставлять вручную или через поиск по наименованию, например, «ООО "Ромашка"», «Ромашка ООО» и «ООО РОМАШКА», которые для алгоритма – три разные компании.

Например, финансовая служба закрывает период до 5 го числа следующего месяца. До закрытия данные в «1С» «плывут»: корректируется себестоимость продукции, перепроводятся документы, меняются суммы. Если BI читает данные из «1С» в реальном времени, дашборд за январь 2 го февраля и 6 го февраля покажет разные цифры. Пользователи не понимают, почему так происходит, и перестают доверять данным.

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

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

Что важно при выборе BI для «1С»

Если вы осознали проблему и решили внедрять BI, первый вопрос – по каким критериям выбирать систему? Рынок предлагает десятки решений, от глобальных платформ до нишевых продуктов.

Рассмотрим, что действительно важно, если ваш основной источник данных – «1С».

• Нативная интеграция с «1С». Это критический пункт. Если BI-система не умеет напрямую работать с «1С», вам придется строить промежуточное звено между ними – настраивать выгрузки, писать дополнительный код для передачи данных. Это время, деньги и усложнение системы: чем больше звеньев в цепочке, тем выше вероятность сбоя. Ищите решения, которые понимают структуру данных «1С» из коробки: справочники, регистры, документы.

• Возможность работать без предварительного построения DWH (хранилище данных). Для многих компаний создание хранилища данных – это проект на год. Хорошая BI-система должна уметь работать с данными «как есть», без обязательного этапа построения DWH. Это не значит, что DWH не нужно в принципе – просто вы должны иметь возможность получить первые результаты быстро, а архитектуру наращивать постепенно.

• Работа с «грязными» данными. В реальном мире данные неидеальны. Дубли в справочниках «1С», разные наименования одного и того же контрагента, пропуски в полях. BI-система должна предоставлять инструменты для очистки и маппинга данных – без обязательного привлечения разработчика.

• Возможность объединять источники. «1С» + Excel + CRM – типичный набор. Система должна уметь объединять данные из разных источников в единую модель, чтобы вы могли, например, сопоставить продажи из «1С» с маркетинговыми расходами из таблиц.

• Порог входа для пользователей. Если для построения отчета нужен SQL или Python, инструментом будет пользоваться один человек в компании. Нужен интерфейс, в котором финансовый директор или руководитель отдела продаж сможет сам собрать нужный отчет.

• Скорость получения первых результатов. Время до первого полезного дашборда – один из ключевых критериев. Если через две недели после старта проекта у вас нет ни одного работающего отчета, что-то идет не так.

Как устроены решения Modus ETL и Modus BI: архитектура простыми словами

Все, что описано выше – подключение к «1С» без выгрузок, работа с большими объемами данных, анализ без отдельного DWH – можно реализовать в связке решений Modus: ETL+BI.

• Слой подключения источников. Нативный коннектор к «1С», который «понимает» структуру конфигурации: регистры накопления, регистры сведений, справочники, документы. Система подключается напрямую к базе – без промежуточных выгрузок в Excel и без необходимости строить отдельное хранилище данных. При этом можно подключить и другие источники: SQL-базы, Excel-файлы, CRM – и объединить их в единую аналитическую модель.

• Слой обработки данных. Информация из «1С» не «подтягивается» каждый раз заново. Modus ETL забирает данные во внутренний кэш и работает уже с ним. Это принципиальный момент: аналитические запросы не нагружают рабочую базу «1С», а пользователи быстро получают отчеты – даже по сложным выборкам. Обновление данных настраивается: можно по расписанию, можно вручную.

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

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

Работа с большими объемами данных без DWH

Традиционная архитектура BI предполагает цепочку: источник → ETL → DWH → OLAP-куб → визуализация. Каждый элемент этой цепочки – отдельный проект, отдельные компетенции, отдельные затраты. Для бизнеса энтерпрайз-сегмента это оправдано. Для среднего бизнеса – часто избыточно.

Современные BI-инструменты предлагают альтернативный подход. Они умеют подключаться к источникам данных напрямую и дают возможность работать с данными «на лету». В случае с «1С» это означает, что система может читать данные прямо из базы, кэшировать их на своей стороне и строить отчеты без промежуточного хранилища.

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

Ключевой аспект при таком подходе – производительность. Если за несколько лет в базе «1С» накопились миллионы строк из документов, прямые запросы будут тяжелыми. Здесь спасает правильная стратегия кэширования: инкрементальная загрузка (забирать только изменившиеся данные), заранее рассчитанные итоги и разбивка данных по периодам – чтобы запрос не ворошил всю базу, а брал только нужный квартал или месяц.

Инструменты визуализации

Когда данные собраны и доступны, встает вопрос: как их показать, чтобы это было полезно? Хороший BI – это не только про красивые графики. Это про информацию, доступную в нужном виде конкретному человеку.

Генеральный директор не будет разбираться в сводной таблице на 200 строк. Ему нужен экран, который за 10 секунд отвечает на три вопроса: «Как дела в целом?», «Где проблема?», «Насколько все хорошо/плохо?». Что это означает?

• Карточки показателей с цветовой индикацией: выручка, маржа, крупные цифры с отклонением от плана. Зеленый – в норме, желтый – отклонение 5 10%, красный – свыше 10%. Конкретные пороги значений настраиваются под задачи конкретного бизнеса.

• Тренды – линейные графики за 12 месяцев, чтобы видеть динамику, а не статичную цифру. Выручка 50 млн – это хорошо или плохо? Без контекста не понятно. А вот «50 млн, рост 12% к прошлому году, но падение 5% к предыдущему месяцу» – уже информация для решения.

• Детализация по клику. Видите, что выручка упала – кликаете на цифру, проваливаетесь в разбивку по направлениям. Видите проблемное направление – еще клик, и вы на уровне конкретных сделок или товарных групп. Это принципиальное отличие BI от статичного отчета: не нужно просить аналитика «копнуть глубже и найти причины», вы сможете сделать это сами.

Финансовый директор и его команда мыслят таблицами. Для них таблица – не примитив, а основной инструмент. Но таблица в BI отличается от таблицы в Excel несколькими важными свойствами:

• Автоматические группировки данных с раскрытием по уровням. Год → квартал → месяц → неделя → день. Статья ДДС → подстатья → конкретная операция. Дерево разворачивается по клику, а не зашито в структуре файла.

• Условное форматирование по правилам. Не просто «красный, если отрицательное», а «красный, если отклонение от бюджета больше 10% и сумма отклонения больше 500 тысяч». Это отсекает шум. Если статья с бюджетом 50 тысяч ушла на 15% – это 7 500 рублей и не критично. А если на те же 15% ушла статья с бюджетом 20 млн. – это 3 миллиона, и с этим нужно разбираться.

• Перекрестные таблицы. Строки – статьи, столбцы – месяцы, на пересечении – суммы. С промежуточными итогами по кварталам и долей каждой статьи в общих расходах. То, что финансисты привыкли делать в Excel, но с реальными данными.

Здесь важна география и сегментация.

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

• Рейтинги – топ 20 клиентов, топ 10 менеджеров, топ-5 товаров/услуг по маржинальности. С возможностью быстрого переключения периода и сегмента.

• Воронки – если данные из CRM подключены, визуализация конверсии между стадиями лида: заявка → квалификация → КП → сделка → оплата. На каждом этапе видно количество лидов и сумму потенциальной выручки, а также среднее время перехода лида с одной стадии на следующую.

Независимо от роли пользователя, есть требования, которые должна закрывать любая BI платформа.

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

• Экспорт. Как бы мы ни хотели уйти от Excel, руководители продолжают пересылать данные по почте. BI система должна давать возможность выгрузить любой виджет или весь дашборд в PDF, Excel или PNG.

• Расписание рассылок. Автоматическая отправка отчета на почту каждый понедельник в 8:00. Звучит просто, но именно это превращает BI из инструмента «для тех, кто заходит» в инструмент «для всех».

Конструктор отчетов: примеры

Отдельная и очень важная тема – насколько просто пользователю создать нужный отчет. Это то, что отличает «BI для аналитиков» от «BI для бизнеса».

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

• Пример 1: отчет по продажам. Финансовый директор хочет видеть продажи в разрезе товарных групп по месяцам с нарастающим итогом. В конструкторе: перетащил «Товарная группа» в строки, «Месяц» в столбцы, «Сумма продаж» в значения, добавил вычисляемое поле «Нарастающий итог». Готово – без программиста, без запроса в ИТ-отдел.

• Пример 2: анализ дебиторской задолженности. Нужно увидеть просроченную дебиторку в разрезе контрагентов с группировкой по срокам просрочки: до 30 дней, 30–60 дней, более 60 дней. Через конструктор можно создать вычисляемое поле на основе разницы между текущей датой и датой оплаты, применить группировку по диапазонам и вывести результат в виде таблицы или диаграммы.

• Пример 3: план-факт. Данные о плане продаж лежат в Excel, факт – в «1С». Конструктор позволяет объединить два источника по общему ключу (например, анализ по товарной группе и периоду), рассчитать отклонение и вывести отчет с цветовой индикацией: зеленый – план выполнен, красный – нет.

Ограничения и нюансы

У подхода «BI без DWH напрямую к 1С» есть свои ограничения, о которых важно знать заранее.

• Качество данных – ваша ответственность. BI-система покажет то, что есть в данных. Если в «1С» – бардак, на дашборде тоже будет бардак. Инструменты очистки данных помогают, но не заменяют наведение порядка в источниках.

• Сложные аналитические модели потребуют DWH. Если вам нужен предиктивный анализ, сложные статистические модели или объединение данных из десяти источников с нетривиальной логикой – на каком-то этапе хранилище все равно понадобится. Но это не обязательно произойдет на старте использования системы.

• Нагрузка на сервер «1С». Если BI-система забирает данные из рабочей базы «1С», это создает дополнительную нагрузку. Решения: забирать данные в нерабочее время, использовать реплику базы, настроить инкрементальную загрузку. Этот вопрос нужно решить заранее, до того как проводить анализ.

• Безопасность и разграничение доступа. Когда данные из «1С» становятся доступны через BI, нужно внимательно настроить права доступа. Не все сотрудники должны видеть зарплатные ведомости или маржинальность по контрактам.

Выбор BI-системы для компании, живущей в экосистеме «1С» – это не выбор между «идеальным» и «неидеальным» инструментом. Это выбор между «начать получать пользу сейчас» и «строить идеальную архитектуру неопределенно долго». Все потому, что BI – это проект для бизнеса, а не для ИТ. Если инструментом не могут пользоваться бизнес-пользователи без помощи разработчиков, ценность решения падает в разы.

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