Аналитика в 1С и ERP: почему учётка не заменяет BI
Что учётная система показывает хорошо, где проходят её пределы как инструмента управленческой аналитики, как правильно выгружать из неё данные и связывать с другими источниками компании.
1С и другие учётные системы хорошо показывают то, что в них учитывается: движение товаров, документы, взаиморасчёты. Управленческой аналитикой они не становятся по трём причинам — данные лежат в учётной логике, отчёты тяжелы для регулярного просмотра, а данные соседних систем в них не попадают.
Разберу, что учётная система показывает хорошо, где её пределы и как правильно выгружать из неё данные в общий контур.
Что учётная система показывает хорошо
Начну с сильных сторон, потому что их часто недооценивают, покупая внешние инструменты для задач, которые решаются внутри.
- Движение товаров и остатки. Всё, что связано с номенклатурой, отражено детально и достоверно.
- Взаиморасчёты. Дебиторка и кредиторка по контрагентам — самая надёжная часть данных в любой компании.
- Документы и первичка. Прослеживаемость до конкретного документа, что критично для проверки любой цифры.
- Себестоимость по учётной методике. Расчёт есть, хотя управленческая себестоимость от него обычно отличается.
Для компаний, где вся деятельность помещается в учётную систему, настройки отчётов внутри неё бывает достаточно. Внешний инструмент нужен, когда появляются вопросы, требующие данных из других источников: связать продажи с рекламой, посмотреть воронку вместе с оплатами, соединить производственные данные с коммерческими.
Три предела учётной системы
| Ограничение | В чём проявляется | Как обходится |
|---|---|---|
| Учётная логика | Данные организованы под документооборот, а не под управленческие вопросы | Отдельный слой с управленческой моделью данных |
| Скорость отчётов | Тяжёлые отчёты нагружают систему и мешают операционной работе | Выгрузка в отдельное хранилище, расчёты вне боевой базы |
| Границы данных | Не знает про рекламу, сайт, воронку продаж | Сведение с другими источниками в общем контуре |
Второе ограничение проявляется неожиданно: компания настраивает подробный аналитический отчёт, запускает его в рабочее время, и вся система начинает тормозить. Это стандартная ситуация, а не признак плохой настройки — учётные системы оптимизированы под ввод документов, а не под расчёты по большим массивам.
Как правильно выгружать данные
Пятый шаг требует пояснения. Учётные системы хранят текущее состояние: если клиента перевели в другую категорию, все прошлые отчёты пересчитаются задним числом. Для управленческой аналитики это проблема — сравнение с прошлым годом становится некорректным. Решается сохранением состояния справочников на каждую дату выгрузки.
Самая частая ошибка при подключении к учётной системе — прямое чтение боевой базы в рабочее время. Первый понедельник после запуска обычно всё расставляет по местам: система замедляется, операционисты жалуются, проект получает репутацию вредного. Проверять нагрузку нужно до запуска, а выгрузку планировать на ночь или с отдельной копии базы.
Настрою выгрузку без нагрузки на рабочую базу, сведу справочники с CRM и соберу управленческую модель поверх. После этого продажи, реклама и деньги оказываются в одной картине.
Управленческая модель поверх учётной
Данные, выгруженные из учётной системы, не готовы к управленческому использованию — они организованы под документооборот. Между выгрузкой и панелью строится слой, где происходят три вещи.
Переклассификация. Учётные статьи затрат перекладываются в управленческие. В учёте расходы сгруппированы по нормативным требованиям, для управления нужна другая группировка — по направлениям, по типу затрат, по управляемости.
Разнесение общих затрат. Учёт обычно оставляет их одной строкой. Для расчёта рентабельности направлений они разносятся по базам, зафиксированным письменно. Как это устроено, разобрано в статье про финансовую аналитику.
Досчёт недостающего. Часть управленческих показателей в учёте не считается вовсе: маржинальность с учётом трудозатрат, оборачиваемость по категориям, выработка на человека. Они рассчитываются в этом слое.
Типовые ошибки
- Строить аналитику прямо в 1С. Тяжёлые отчёты мешают операционной работе, а управленческая логика застревает в учётной.
- Полная перевыгрузка каждый раз. Через год перестаёт укладываться в ночное окно, и обновление начинает срываться.
- Не сохранять историю справочников. Изменение категории клиента переписывает прошлое, сравнение периодов ломается.
- Считать учётную себестоимость управленческой. Решения принимаются по цифрам, посчитанным для других целей.
- Дорабатывать конфигурацию под отчёты. Усложняет обновления и привязывает к подрядчику.
- Игнорировать разрыв при переходе. История не переносится, аналитика начинается с нуля с даты миграции.
Учётная система отвечает на вопрос, что произошло по документам. Управленческая аналитика отвечает на вопрос, что с этим делать. Это разные вопросы, и одним инструментом они не закрываются.Владимир Герасимов
Практический вывод: не пытайтесь превратить учётную систему в аналитическую платформу и не заменяйте её. Правильная конструкция — учётная система остаётся местом ввода и первичного учёта, а поверх выгруженных из неё данных строится управленческий слой, куда подтягиваются и другие источники. Как этот слой устроен целиком, разобрано в статье про единый контур управления бизнесом.
Разберу, какие вопросы закрываются учётной системой, а для каких нужны данные извне. Соберу выгрузку и управленческий слой поверх, не трогая рабочую конфигурацию.
Сколько занимает подключение
Сроки зависят от двух вещей: дорабатывалась ли конфигурация и в каком состоянии справочники. Для типовой конфигурации без серьёзных доработок подключение и настройка регулярной выгрузки занимают от одной до трёх недель. Доработанная конфигурация добавляет времени: структура данных отличается от стандартной, и её приходится разбирать.
Основное время, однако, уходит не на техническую часть, а на сведение справочников с другими системами. Если контрагенты в учёте и в CRM не связаны, работа измеряется неделями и требует участия людей, которые знают клиентов, — автоматически такое сопоставление делается только частично.
Что делать при смене или обновлении системы
Момент, когда чаще всего теряется история, и потеря обнаруживается через год, когда понадобилось сравнение с прошлым периодом. Планировать перенос нужно заранее, и объём работ здесь невелик по сравнению с последствиями.
- Определите, что переноситьМинимум — агрегированные продажи, затраты и остатки по месяцам за прошлые годы. Полная детализация нужна не всегда.
- Выгрузите до миграцииПосле перехода доступ к старой базе часто теряется или усложняется.
- Сохраните справочникиСостояние на дату перехода, чтобы можно было сопоставить старые и новые коды.
- Проверьте сопоставимостьМетодика расчёта в новой системе может отличаться — расхождения нужно понять и задокументировать.
Четвёртый пункт часто пропускают, и это создаёт скрытую проблему: данные до и после перехода формально есть, но считались по разным правилам. График показывает скачок в момент миграции, который принимают за изменение в бизнесе. Документирование расхождений снимает этот вопрос заранее.
Учётная система и другие источники
Финальный вопрос — как учётные данные соединяются с остальными. Три основные связки, каждая через свой ключ.
С CRM — по контрагенту. Даёт связку сделок с оплатами, реальную маржинальность клиентов и завершение цепочки в сквозной аналитике.
С маркетплейсами — по номенклатуре. Артикулы обычно не совпадают, нужна таблица соответствий; подробнее — в статье про аналитику маркетплейсов.
С производственными или отраслевыми системами — по заказу или партии. Даёт связку плановой и фактической себестоимости.
Каждая связка держится на справочниках, и именно поэтому наведение в них порядка окупается быстрее любой другой работы с данными: одно решение открывает несколько управленческих сценариев сразу.
Когда учётной системы достаточно
Завершу тем, о чём редко говорят продавцы аналитических платформ. Есть ситуации, когда внешний инструмент не нужен и деньги на него будут потрачены зря.
Первая: вся значимая деятельность отражается в учётной системе, других источников нет или они несущественны. Тогда задача решается настройкой отчётов внутри и, при необходимости, выгрузкой в таблицу для месячного анализа.
Вторая: объёмы небольшие, а вопросы возникают редко. Компания, где управленческий разбор проводится раз в месяц по десятку показателей, справится без отдельной платформы — накладные расходы на её поддержание превысят пользу.
Третья: управленческий учёт не ведётся вообще. Здесь начинать нужно с методики — структуры статей, баз разнесения, определений показателей. Пока их нет, любая система будет быстро выдавать цифры, в которые никто не верит.
Признак, по которому видно, что учётной системы перестало хватать, простой: вопросы руководителя всё чаще требуют ручной выгрузки и доработки формулами в таблице, а на подготовку ответа уходит день и больше. Как выглядит следующий шаг, разобрано в статье про внедрение аналитики, а выбор инструмента — в разборе систем аналитики.
Порядок работ
- Оцените конфигурациюТиповая или доработанная, какая версия, где размещена. От этого зависит способ выгрузки и сроки.
- Проверьте справочникиНасколько контрагенты и номенклатура сопоставимы с другими системами. Здесь обычно основная работа.
- Настройте выгрузкуНочную, инкрементальную, с проверкой полноты и сохранением истории справочников.
- Постройте управленческий слойПереклассификация статей, разнесение общих затрат, досчёт недостающих показателей.
- Подключите остальные источникиCRM, реклама, площадки — на подготовленную основу они ложатся быстрее.
Начинать с учётной системы имеет смысл почти всегда: она содержит деньги, а все остальные данные так или иначе сверяются с выручкой. Обратный порядок — сначала подключить CRM и рекламу — даёт красивые отчёты по заявкам, которые невозможно соотнести с фактическим результатом.
Практическая проверка текущего состояния: попробуйте получить выручку по направлениям с разнесёнными общими затратами за прошлый квартал. Если это делается в учётной системе за минуты — управленческий слой уже есть. Если требует недели ручной работы в таблицах, задача понятна и решается описанным выше порядком.
Что остаётся в компании
При любой схеме работы внутри должны оставаться три вещи: понимание того, как устроена выгрузка и что именно из системы забирается; описание управленческой модели с базами разнесения и правилами переклассификации статей; доступы к учётной системе и к хранилищу.
Без этого компания оказывается в зависимости от подрядчика в вопросе, который касается её собственных финансов. Проверить состояние просто: попросите показать документ, где описано, как из учётных данных получается управленческий отчёт. Если такого документа нет, его создание — первая задача, независимо от того, что планируется делать дальше.
Такой документ обычно занимает несколько страниц и окупается при первом же вопросе о том, почему управленческая прибыль отличается от учётной.
Отдельно стоит зафиксировать порядок пересмотра методики: базы разнесения и структура статей меняются вместе с бизнесом, и без назначенного момента проверки они устаревают незаметно, а расхождения обнаруживаются в самый неподходящий момент — при разборе результатов квартала.
Практический минимум для регулярности: раз в квартал проверять, не появились ли новые статьи затрат без классификации, не изменились ли базы разнесения и сходится ли управленческая выручка с учётной в пределах объяснимого расхождения. Пятнадцать минут работы, которые предотвращают ситуацию, когда через год отчёты приходится пересобирать заново, а сравнение с прошлыми периодами оказывается некорректным.
Регулярность здесь важнее глубины: короткая проверка каждый квартал надёжнее подробного разбора раз в два года.
Именно поэтому пересмотр методики имеет смысл поставить в календарь наравне с закрытием периода — тогда он происходит, а не откладывается до момента, когда расхождения станут заметны всем.
При таком порядке учётная система остаётся надёжным фундаментом данных, а управленческие выводы строятся поверх неё — без доработок конфигурации и без нагрузки на операционную работу.
Это и есть рабочая конструкция для компании любого размера: учёт внизу, управленческий слой сверху, панели по ролям над ним.
Аналитика счетов, остатков и взаиморасчётов в учётной системе доступна из коробки. Управленческие разрезы — рентабельность направлений, оборачиваемость по категориям, выработка — требуют слоя поверх, и это нормальное разделение, а не недостаток системы.
Частые вопросы
Для задач внутри самой системы — да: движение товаров, остатки, взаиморасчёты, документы отражены детально и достоверно. Если вся деятельность компании помещается в учётную систему, настройки отчётов внутри неё бывает достаточно.
Внешний инструмент нужен, когда требуются данные из других источников: связать продажи с рекламой или воронку с оплатами.
Потому что учётные системы оптимизированы под ввод и проведение документов, а не под расчёты по большим массивам данных. Тяжёлый отчёт, запущенный в рабочее время, конкурирует за ресурсы с операционной работой.
Решение — выгружать данные в отдельное хранилище и считать вне боевой базы, а саму выгрузку выполнять ночью или с реплики.
Тремя способами. Через программный интерфейс — надёжнее всего, данные приходят структурированно. Прямым чтением базы — доступно всё, но требует понимания внутренней структуры, которая нетривиальна. Файловой выгрузкой по расписанию — простой вариант, работающий при зафиксированном формате.
Выбор зависит от версии, конфигурации и того, дорабатывалась ли система.
Потому что они считаются по разным правилам и для разных целей. Учётная формируется по нормативным требованиям, управленческая — по правилам, которые компания устанавливает себе: с другими базами разнесения общих затрат и другим составом расходов.
Расхождение нормально. Проблема возникает, когда управленческого расчёта нет вовсе и решения принимаются по учётным цифрам.
Обычно нет, и лучше избегать. Доработки усложняют обновления и привязывают компанию к конкретному подрядчику. Управленческую логику разумнее держать в отдельном слое поверх выгруженных данных.
Исключение — добавление полей, которые нужно фиксировать в момент работы: например, признак направления или причина операции. Это оправданная доработка.
Через общий идентификатор контрагента. Это главная организационная задача: в CRM клиент заведён под одним названием, в учёте — под другим, автоматически они не соединяются.
Решается либо единым идентификатором на стороне источников, либо таблицей соответствий, которую нужно поддерживать при появлении новых клиентов.
Планировать перенос истории заранее. Разрыв данных при смене системы — одна из самых частых находок при аудите: аналитика начинается с даты перехода, сравнение с прошлыми периодами становится невозможным.
Минимум, который стоит сохранить, — агрегированные данные по продажам, затратам и остаткам за прошлые годы в отдельном хранилище.
Для оперативного контроля — часто да. Для управленческой картины — нет, потому что она требует данных из нескольких систем и расчётов по методике компании, которая отличается от учётной.
Практический признак нехватки: вопросы руководителя всё чаще требуют ручной выгрузки в таблицу и доработки формулами.