Когда стандартных отчетов 1С уже мало. Интервью с техническим директором "Денвик Аналитика"

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

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

Тогда рядом с 1С постепенно появляются Excel-файлы, дополнительные обработки, SQL-запросы, интеграции и отдельные базы данных. 

Где проходит эта граница и когда компании действительно нужен отдельный аналитический контур, мы поговорили со Степаном Пыстиным, техническим директором «Денвик Аналитика».

Где заканчиваются возможности отчетов 

- Обычно все начинается с решения внедрить BI? 

Степан Пыстин: Чаще намного раньше. Первый сигнал можно увидеть прямо в обычной работе с отчетами 1С. 

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

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

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

- То есть стандартные отчеты сами по себе не плохой вариант? 

Конечно. Если они закрывают задачи бизнеса, менять что-то ради самого изменения смысла нет. 
Вопрос обычно появляется тогда, когда новые управленческие запросы все чаще требуют доработок. 
Сегодня руководитель просит один дополнительный показатель. Через месяц - еще несколько. Потом нужно сравнить данные трех подразделений. Затем добавить CRM. В какой-то момент каждый новый вопрос начинает требовать отдельной технической работы.

Почему появляется Excel 

- Что обычно делает сотрудник, если одного отчета уже не хватает? 

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

- А в какой момент Excel начинает мешать? 

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

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

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

- Получается, проблема Excel в ошибках? 

Ошибки - только одна часть. 
Основной вопрос - воспроизводимость. 

Можно ли через полгода повторить расчет по тем же правилам? Понимает ли другой сотрудник, откуда взялась цифра? Можно ли изменить формулу и быть уверенным, что соседний отчет после этого не сломается? 

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

Когда нужна отдельная автоматизация 

- Логичный следующий шаг - позвать разработчика 1С? 

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

Такой вариант особенно удобен, если почти вся аналитика живет на данных одной 1С. 

- А когда этого становится мало? 

Когда количество источников и требований начинает расти. 

Представим обычную картину. 
Продажи находятся в 1С, информация о лидах - в CRM, план - в Excel, маркетинговые расходы приходят из внешнего сервиса.
 
А руководитель хочет увидеть цепочку: рекламный канал → клиент → продажа → себестоимость → финансовый результат 

Теперь нужно договориться, как связать эти данные. 

В одной системе компания может называться ООО Компания, в другой - Компания. 
Где-то используется внутренний ID, где-то ИНН. 
Подразделение в одной базе называется Москва, а в другой - Филиал МСК. 

Здесь задача уже выходит за пределы отдельного отчета. 

- И количество систем здесь главное? 

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

Что происходит с данными дальше 

- Что значит «постоянный процесс» с технической точки зрения? 

Раньше пользователь говорил: «Мне нужен отчет». 

Теперь появляются дополнительные требования. 

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

Для данных 1С эту задачу может закрывать Экстрактор 1С. 

Он получает данные из информационной базы 1С и передает их во внешний контур - например, в СУБД, где дальше с ними уже работают аналитические системы. 

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

- Можно сказать, что тогда нагрузки на 1С вообще нет? 

Так говорить было бы неправильно. 

Любое получение данных использует ресурсы системы. 

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

- Получили данные из 1С. Можно сразу подключать BI? 

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

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

Вот здесь появляется ETL.

- Все это обязательно писать на SQL или Python? 

Нет. Подход зависит от команды. 
Кому-то удобнее код. Особенно если уже есть свои процессы разработки, Git, тестирование и CI/CD. 
Есть и визуальные инструменты. 
В нашей архитектуре для таких задач используется Denvic Visual Transformer - DVT. 
В нем процесс можно собрать как последовательность операций: прочитать данные, отфильтровать, объединить, преобразовать, посчитать нужные поля и записать результат. 
Проекты можно запускать по расписанию и смотреть историю выполнения. 

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

- Тогда в чем смысл low-code? 

Одни из плюсов - структуру процесса проще увидеть, а результат проконтролировать. 

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

Нужен ли отдельный контур всем 

- Если BI умеет получать данные из 1С напрямую, зачем вообще строить отдельные слои? 

Иногда незачем. 

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

Создавать большое хранилище ради такого сценария избыточно. 

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

Тогда обработку и хранение данных часто выносят во внешний контур. 

Он тоже может быть очень разным: от одной аналитической таблицы до полноценного DWH. 
Размер решения должен соответствовать задаче. 

- Как тогда выглядит типовая схема? 

Если сильно упростить: 
1С → Экстрактор 1С → аналитическая БД / DWH → DVT → BI / CRM / API / Excel 

Экстрактор здесь отвечает за получение данных из 1С. 
DVT нужен в тех проектах, где данные требуется объединять или преобразовывать. 
А BI работает уже с подготовленным набором. 
При простой задаче часть элементов из этой схемы вообще может отсутствовать.

Как понять, что процесс пора менять 

- Есть какой-то простой способ понять, что компания уже выросла из текущего подхода? 

Я бы взял один важный регулярный отчет и прошел весь путь его подготовки. 

Откуда берутся исходные данные? Сколько файлов нужно выгрузить? Что сотрудник делает вручную? Какие таблицы объединяет? Где считает показатели? Как проверяет результат? Сколько людей понимают весь процесс? 

После этого обычно становится видно, что именно создает сложности. 

- Если ручных действий много, нужно сразу внедрять ETL-платформу? 

Нет. Иногда достаточно одной автоматической выгрузки или доработки отчета. 
В другом проекте понадобится отдельная аналитическая таблица. 
Где-то потребуется полноценный ETL-процесс. 
Архитектуру лучше наращивать по мере появления требований. 

- А как относиться к Open Source? 

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

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

Поэтому я бы сравнивал решения по полной стоимости владения. 

Например:

Что оценить	На какой вопрос ответить
Лицензии	Сколько стоит использование решения
Инфраструктура	Какие серверы и сервисы понадобятся
Разработка	Сколько собственной разработки потребуется
Поддержка	Кто будет разбираться со сбоями
Обновления	Кто проверяет совместимость после релизов
Обучение	Сколько времени нужно новому специалисту
Изменения	Насколько сложно добавить источник, расчет или витрину
Зависимость от команды	Сколько людей понимают, как все устроено

- Каков главный признак того, что аналитика компании становится более зрелой? 

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

Можно представить это так: 
источник → получение → хранение → подготовка → показатель → отчет 

Причем далеко не каждой компании сразу нужна вся эта цепочка. 

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

И уже после этого имеет смысл выбирать конкретную архитектуру и инструменты.