Собрать данные из 1С, CRM и таблиц в одно место — это отдельный инженерный слой между учётными системами и дашбордом, а не настройка внутри BI. Он забирает данные из источников по расписанию, приводит их к единым справочникам, складывает историю и отдаёт наверх готовые витрины. В модельной смете, которую мы разбираем ниже, этот слой стоит 250 000 ₽ — 56 % бюджета типового BI-проекта на 450 000 ₽. Сама платформа визуализации занимает в этом бюджете около 13 %.
Именно поэтому обещание «подключим BI напрямую к вашей 1С за неделю» звучит дёшево ровно до первого квартала эксплуатации. Прямое чтение боевой базы даёт отчёт сегодня и счёт за переделку через полгода: структура таблиц 1С недокументирована и меняется при обновлении конфигурации, тяжёлый аналитический запрос конкурирует за блокировки с работой менеджеров, а истории изменений в боевой базе нет вовсе — она хранит текущее состояние, а не то, каким оно было в июне.
Ниже — четыре способа забрать данные с ценой каждого, три слоя, через которые проходит строка «продажа за вторник», влияние частоты обновления на смету, порядок легализации ручных таблиц отделов и чек-лист доступов, который подписывается до начала работ. Выбор самой платформы — тема отдельного разбора: десять живых российских BI и семь критериев отбора мы уже сравнивали.
Что на самом деле стоит между 1С и дашбордом
Учётная система оптимизирована под ввод документов, а не под чтение годовых срезов. Она хранит текущее состояние: остаток такой, цена такая, контрагент называется так. Отчётность требует обратного — она спрашивает, каким был остаток на конец мая, по какой цене отгружали в марте и как назывался этот же контрагент до переименования. Слой сбора существует для того, чтобы удерживать разницу между этими двумя задачами.
Набор регламентных выгрузок, промежуточная база и правила приведения справочников, между источниками и BI. Он отвечает на четыре вопроса: когда данные забираются, что делать при сбое выгрузки, как одна и та же номенклатура из 1С и CRM превращается в одну строку и где лежит история, которой в боевой базе уже нет. Дашборд читает только результат его работы и в источники не ходит.
У этого слоя есть третья, неочевидная функция — он фиксирует договорённости. Пока данные лежат в трёх системах, «выручка» существует в трёх версиях, и каждая по-своему верна. Как только появляется витрина, кто-то обязан написать, что именно в неё попадает: отгрузка или оплата, с НДС или без, считаются ли внутренние обороты между юрлицами. Это не техническая работа, но без неё дашборд превращается в повод для спора. Мы разбирали эту механику отдельно — когда одна цифра в трёх системах разная, проблема почти никогда не в графике.
Модельная компания дальше по тексту одна и та же: 40 человек, 1С:УТ 11 как основная учётная система, amoCRM в продажах, телефония Mango Office, две живые таблицы отделов — прайс поставщиков и план продаж. За последние 12 месяцев в 1С проведено около 84 000 документов, в табличных частях примерно 610 000 строк. Это типичная оптовая компания, и все расчёты ниже привязаны к этим числам.
Четыре способа забрать данные и цена каждого
Способов ровно четыре, и они отличаются не «продвинутостью», а тем, что ломается при росте. Ниже — сравнение с разовой ценой по рынку, слабым местом и ситуацией, в которой способ действительно правильный.
| Способ | Разовая цена | Слабое место | Когда это правильный выбор |
|---|---|---|---|
| Прямое подключение BI к боевой базе | 40 000–80 000 ₽ | Блокировки в рабочее время, недокументированная структура таблиц, отчёты рассыпаются после обновления конфигурации | Разовый разбор на копии базы. В постоянном контуре — почти никогда |
| Ночная выгрузка по расписанию | 120 000–250 000 ₽ | Данные вчерашние; если ночная загрузка не прошла, утром отчётов нет | Управленческая отчётность, план-факт, деньги, склад — примерно 80 % задач |
| Low-code коннекторы: Albato, ApiX-Drive, n8n на своём сервере | 60 000–150 000 ₽ плюс 2 200–15 000 ₽/мес за платформу | Хороши на событиях, плохи на пересчёте года: перезалить 610 000 строк через коннектор дорого и медленно | Оперативные витрины, склейка нескольких облачных сервисов, быстрый старт |
| ETL в собственное хранилище | 250 000–600 000 ₽ | Самый дорогой старт, нужен владелец модели данных на стороне заказчика | Несколько юрлиц и источников, требуется история и неизменность закрытых периодов |
Способы комбинируются, и в жизни это нормально: ночная выгрузка тянет тяжёлые документы из 1С, а коннектор в реальном времени подхватывает события из CRM и телефонии. Что именно умеет отдавать 1С — OData-интерфейс, HTTP-сервисы, регламентная выгрузка файлами — мы разбирали в материале про способы обмена с 1С; там же разница между конфигурациями, у которых состав объектов отличается сильнее, чем принято думать.
Про третью строку таблицы стоит сказать отдельно, потому что вокруг неё больше всего путаницы. Zapier и Make из России недоступны, и предлагать их как рабочий инструмент нельзя. Живых вариантов на сентябрь 2026 года три: Albato с российским юрлицом и серверами в РФ, ApiX-Drive в реестре Минцифры со стоимостью от 2 200 ₽/мес и n8n, развёрнутый на собственном сервере, — облачную подписку n8n из России оплатить проблематично, self-hosted этой проблемы не имеет. Все три хорошо переносят события — «сделка перешла на этап», «пришла оплата», «создан контакт» — и плохо переносят историю: пересчёт года по 610 000 строкам через коннектор упирается в лимиты запросов и тарификацию по операциям.
Практическая граница простая. Если объём — сотни и тысячи событий в сутки, коннектор дешевле и быстрее разработки. Если речь про десятки тысяч строк документов и перезагрузку истории — нужна регламентная выгрузка, а коннектор оставляют там, где он силён. Ошибка выбора здесь не фатальна: связка на коннекторе разбирается за неделю и не тянет за собой переписывание витрин, если справочники приведены в порядок заранее.
Сравнение в четыре колонки-карточки: «Прямое подключение к боевой базе — 40 000–80 000 ₽», «Ночная выгрузка по расписанию — 120 000–250 000 ₽», «Low-code коннекторы — 60 000–150 000 ₽ плюс 2 200–15 000 ₽/мес», «ETL в хранилище — 250 000–600 000 ₽». В каждой карточке две строки: «слабое место» и «когда правильно». Под первой карточкой красная отметка «в постоянном контуре — почти никогда», под второй — зелёная «≈80 % задач отчётности». Чертёжный стиль, подписи по-русски.
Что именно забирать из каждой системы
Второй по частоте способ потерять деньги — забрать «всё на всякий случай». Полная выгрузка боевой базы вместе со служебными регистрами и планами обмена весит в разы больше, обновляется дольше и не отвечает ни на один управленческий вопрос. Правильный вход в проект — список объектов, который умещается на половине страницы и напрямую выводится из перечня отчётов. Для модельной компании он выглядит так.
- Из 1С:УТ — девять объектов. Реализация товаров и услуг с табличными частями, поступление, платёжные документы, номенклатура с группами и единицами измерения, контрагенты с ИНН и договорами, склады, остатки на конец каждого дня, история цен, движения по регистрам взаиморасчётов. Всё остальное добавляется потом и по конкретному запросу.
- Из amoCRM — четыре. Сделки со всеми полями и суммой, контакты и компании, события смены этапа с отметкой времени, задачи и звонки. События воронки важнее самих сделок: без них нельзя посчитать ни длину цикла, ни конверсию между этапами, а именно эти два показателя обычно и заказывают.
- Из телефонии — один. Журнал звонков: направление, номер, длительность, ответственный, ссылка на запись. Записи разговоров в хранилище не переносят — хранят ссылку, иначе объём растёт на порядок и вместе с ним растут требования к защите персональных данных.
- Из таблиц отделов — по одному файлу на процесс. План продаж по менеджерам и месяцам, закупочные цены поставщиков. Не «папка с планами», а конкретный файл с фиксированной структурой и фамилией владельца.
Список объектов проверяется обратным ходом: берётся каждый заказанный отчёт и выписывается, из каких полей он собирается. Если поле не участвует ни в одном отчёте — оно не выгружается. Эта проверка занимает полдня и обычно сокращает исходный список на треть, а вместе с ним и время ночной загрузки. Обратная ошибка тоже встречается: отчёт «маржа по менеджерам» заказан, а себестоимость в 1С не заполнена — и это лучше обнаружить на обследовании, чем на приёмке.
Почему аналитика не ходит в боевую 1С напрямую
Возражение звучит разумно: база уже есть, BI умеет подключаться, зачем платить за промежуточный слой. Причин три, и все три проявляются не в первый месяц, а на втором квартале, когда отчётов становится больше десяти.
- 1Блокировки. Аналитический запрос читает документы за 18 месяцев и удерживает записи, которые в этот же момент пытается изменить менеджер, проводящий реализацию. Пользователь видит не «медленно», а «не проводится документ». В модельной компании такие эпизоды случались трижды за год по 40 минут — по нашему опыту это скромная оценка для базы, к которой прикручен живой дашборд.
- 2Структура. Прямое чтение таблиц СУБД под 1С вендором не поддерживается: имена таблиц и полей служебные, структура не документирована и переписывается при обновлении конфигурации. Отчёт, собранный на такой структуре, — это не интеграция, а зависимость от того, что 1С не будут обновлять. За год конфигурацию обновляют минимум дважды.
- 3Истории нет. Боевая база отвечает на вопрос «как сейчас». Цена изменилась — прошлая пропала. Контрагента переименовали — во всех прошлых отчётах он мгновенно стал называться по-новому. Закрытый период пересчитался задним числом, и майский отчёт, распечатанный в июне, больше не воспроизводится. Для управленческой отчётности это дисквалифицирующий недостаток.
Арифметика первого года выглядит так. Слева — «сэкономили» на слое сбора и подключились напрямую, справа — сделали слой сбора сразу. Ставки в расчёте: 1С-специалист 3 500 ₽/час, средняя стоимость часа сотрудника отдела продаж 900 ₽.
Компромисс, который действительно работает, — читать не боевую базу, а её ночную копию. Копия снимается регламентом, живёт на отдельном сервере, блокировок в рабочее время не создаёт. Это дешевле полноценного хранилища и закрывает часть задач, но не решает вторую и третью проблемы: структура всё так же поедет при обновлении, а истории в копии ровно столько же, сколько в оригинале, — никакой. Где физически держать такую копию и что это меняет по деньгам, разобрано в материале про облачной 1С и своём сервере.
Права только на чтение защищают данные от изменения, но не защищают базу от нагрузки. Тяжёлый запрос на чтение точно так же удерживает блокировки и точно так же останавливает проведение документов у менеджеров. Безопасность доступа и производительность — разные вещи, и первое регулярно предъявляют как доказательство второго.
Три слоя: путь строки «продажа за вторник»
Внутри слоя сбора данные лежат не одной кучей, а тремя уровнями. Разделение выглядит бюрократией ровно до первого расхождения в отчёте — после него становится понятно, зачем нужен уровень, куда данные попадают в исходном виде и не правятся никогда.
- 1Сырой слой: как пришло, так и лежит
Копия выгрузки без единой правки, с отметкой времени загрузки и признаком источника. Ничего не удаляется и не переписывается. Этот слой отвечает на вопрос «что нам реально отдала 1С 14 августа в 03:15», и именно к нему возвращаются, когда цифра в отчёте вызывает сомнение. Стоит дёшево, занимает место, окупается на первом же споре.
- 2Очищенный слой: одинаковые сущности из разных систем
Здесь контрагент из 1С и компания из amoCRM становятся одной записью, единицы измерения приводятся к справочнику, отменённые документы помечаются, а не исчезают. Здесь же живёт таблица соответствий между кодами систем. Это самый трудоёмкий слой, и он напрямую зависит от того, начали ли вы с порядка в справочниках.
- 3Витрины: одна таблица под один отчёт
Плоская таблица, посчитанная заранее под конкретный вопрос: продажи по менеджерам и месяцам, дебиторка по срокам, остатки по складам. В витрине уже нет соединений и вычислений на лету, поэтому дашборд открывается за секунду, а не за минуту, и все отчёты берут одну и ту же цифру из одного места.
Практический смысл разделения проще всего показать на возврате задним числом. Клиент вернул товар 29 августа, документ провели 3 сентября с датой 29-го. В прямом подключении августовский отчёт молча изменился — и никто не знает, когда и почему. В трёхслойной схеме сырой слой хранит обе версии выгрузки, очищенный отмечает корректировку, витрина пересчитывается по регламенту, а в журнале остаётся запись, что август пересчитан 3 сентября. Ровно этого требует любой разговор про сроки закрытия месяца.
Горизонтальная схема из шести блоков со стрелками слева направо: «Документ реализации в 1С:УТ» → «Выгрузка 03:15» → «Сырой слой: как пришло» → «Очищенный слой: единые справочники, пометка отмен» → «Витрина: продажи по менеджерам и месяцам» → «Плитка на дашборде». Под сырым слоем подпись «не правится никогда», под очищенным — «самый трудоёмкий», под витриной — «одна таблица на один отчёт». Снизу отдельная ветка от блока «Возврат, проведённый 3 сентября задним числом 29 августа» со стрелкой в очищенный слой и подписью «пересчёт по регламенту, запись в журнале». Чертёжный стиль, подписи по-русски.
Частота обновления — это статья сметы
«Хотим, чтобы данные были в реальном времени» — самая дорогая фраза в техническом задании на аналитику. Она почти никогда не нужна и почти всегда добавляет к смете больше, чем все дашборды вместе. Разница в цене возникает не в BI, а в слое сбора: суточная выгрузка забирает всё целиком ночью, а обновление раз в 15 минут требует уметь забирать только изменившееся и не мешать работе людей.
| Частота | Что для этого нужно | Надбавка к внедрению | Надбавка к сопровождению |
|---|---|---|---|
| Раз в сутки, ночью | Регламентное задание в окно 02:00–05:00, полная перезагрузка витрин | Входит в базовую цену | Входит в 20 000 ₽/мес |
| Раз в 15 минут | Инкрементальная выгрузка по изменённым объектам, отдельная реплика базы, контроль дублей | 80 000–120 000 ₽ | 8 000 ₽/мес |
| Почти реальное время, до минуты | Подписка на события, очередь сообщений, отдельный контур и дежурство | 250 000–400 000 ₽ | 25 000–40 000 ₽/мес |
Проверка на необходимость одна: назовите решение, которое принимается чаще, чем раз в сутки, и меняется от того, что цифра свежая. Отгрузка со склада, распределение горячих заявок, диспетчеризация транспорта — да, здесь минуты имеют значение. Выручка, маржа, дебиторка, план-факт по менеджерам — нет: ночного обновления достаточно, потому что решение по ним всё равно принимается на планёрке. Разумная схема для большинства компаний — суточная выгрузка для управленческого контура и события в реальном времени для двух-трёх оперативных витрин.
Сравнение в три колонки. Колонка 1: «Раз в сутки, ночью» — надбавка к внедрению «входит в базовую цену», сопровождение «входит в 20 000 ₽/мес», примеры решений «выручка, маржа, дебиторка, план-факт». Колонка 2: «Раз в 15 минут» — «+80 000–120 000 ₽», «+8 000 ₽/мес», примеры «остатки, распределение заявок». Колонка 3: «Почти реальное время, до минуты» — «+250 000–400 000 ₽», «+25 000–40 000 ₽/мес», примеры «отгрузка со склада, диспетчеризация транспорта». Под колонками одна общая подпись-вопрос: «какое решение принимается чаще раза в сутки?». Чертёжный стиль, подписи по-русски.
Ручные таблицы отделов: легализовать, а не запрещать
В каждой компании есть файлы, без которых отчёт не собрать: план продаж, прайс поставщиков, бюджет проектов, график отпусков. Их ведут руками, и первая реакция подрядчика — «переносим в систему». Это правильная цель и неправильный первый шаг: пока данные не переехали, отчёт всё равно нужен, а половина таких файлов переезжает годами. Почему они вообще появляются и что за ними стоит, разобрано в материале про параллельный учёт в таблицах — почти всегда это техническое задание, написанное пользователем бесплатно.
Рабочий подход — принять таблицу как полноценный источник, но с правилами. Файл кладётся в согласованную папку или загружается через форму, структура колонок фиксируется, на входе стоит проверка, а при несовпадении загрузка отклоняется целиком с понятным сообщением. Модельный пример: плановый файл на 340 строк, при первой приёмке отклоняется 26 строк — 7,6 %. Причины всегда одни и те же: месяц написан текстом вместо даты, сумма с пробелом внутри числа, менеджер, которого нет в справочнике, и две строки на один и тот же артикул.
- 1Шаг 1. Зафиксировать структуру и владельца
Колонки, типы значений, обязательные поля и один человек, который отвечает за файл. Не отдел, не «коммерческий блок», а фамилия. Без владельца файл перестают обновлять на третий месяц, и дашборд показывает план прошлого квартала как текущий.
- 2Шаг 2. Поставить проверку на входе
Загрузка проверяет структуру, типы, ссылки на справочники и дубли ключа. Ошибка возвращается автору списком строк, а не молча правится загрузчиком — иначе через полгода никто не знает, откуда в отчёте взялась цифра, которой не было в файле.
- 3Шаг 3. Отложить перенос в систему до понятного момента
Файл переносится в учётную систему тогда, когда его правят чаще раза в неделю, им пользуется больше трёх человек или ошибка в нём стоит денег. До этого момента таблица дешевле любой доработки, и это нормальное инженерное решение, а не компромисс.
Пока плана нет, все понимают, что плана нет. Когда план подгружается в дашборд без валидации, отчёт выглядит рабочим — и по нему принимают решения, не зная, что в июльской строке потерялся ноль. Проверка структуры на входе стоит несколько часов работы и снимает целый класс споров о том, кто испортил отчёт.
Схема из пяти блоков: «Файл отдела: 340 строк» → «Форма загрузки» → «Проверка: структура, типы, справочники, дубли ключа» → развилка на два блока: вниз «Отказ: 26 строк (7,6 %) с перечнем ошибок автору» и вправо «Принято: 314 строк → сырой слой». Под блоком отказа мелким списком четыре типовые причины: «месяц текстом», «пробел внутри числа», «менеджер не из справочника», «две строки на один артикул». Рядом с формой — подпись «владелец файла: конкретная фамилия». Чертёжный стиль, подписи по-русски.
Доступы: чек-лист, который подписывают до старта
Самая частая причина срыва первых двух недель проекта — не техника, а доступы. Подрядчик готов, а ключа к amoCRM нет, потому что интеграцию три года назад делал другой исполнитель на свою учётную запись. Поэтому список собирается и подписывается до начала работ, а не по ходу.
- 1С. Отдельный пользователь только на чтение с ролью под выгрузку, включённый OData или опубликованные HTTP-сервисы, доступ к тестовой копии базы для отладки. Кто подписывает: владелец учётной системы и ИТ.
- CRM. Ключ API и права на чтение сделок, контактов, компаний и событий воронки. Ключ оформляется на компанию, а не на личную почту сотрудника, — иначе увольнение менеджера останавливает загрузку данных.
- Телефония. Доступ к журналу звонков и записям, если в отчётности есть конверсия и нагрузка на линию. Здесь же проверяется, что записи разговоров обрабатываются законно и согласия зафиксированы.
- Таблицы отделов. Папка или форма загрузки, список файлов и фамилия владельца каждого. Файлы с личной почты и мессенджеров в контур не принимаются.
- Инфраструктура. Сервер или облачный ресурс под хранилище, сетевой доступ, окно регламентных работ. Сюда же — договорённость о том, в какое время ночью выгрузка не мешает бэкапу.
- Правовая часть. Если данные обрабатывает подрядчик, оформляется поручение обработки персональных данных. Порядок и минимально необходимый объём прав мы описали в материале про принцип минимальных прав доступа.
Отдельный вопрос — что делать, если ключи от действующих обменов остались у бывшего подрядчика. Ответ неприятный: не пытаться их вернуть, а завести свои. Старые учётные записи после этого отключаются по списку, и это отдельная небольшая работа, которую лучше сделать в начале проекта, чем обнаружить через год. Как выглядит нормальная передача доступов и почему забытые учётные записи подрядчика — типовая находка любого аудита, мы разбирали отдельно.
Карта связей. Слева четыре узла-источника: «1С:УТ 11 — 84 000 документов за год», «amoCRM — сделки, контакты, события», «Mango Office — журнал звонков», «Таблицы отделов — план продаж, прайс поставщиков». От каждого стрелка к центральному блоку «Слой сбора: хранилище и загрузки». На стрелках подписи о типе доступа: «пользователь только на чтение, OData», «ключ API на компанию», «журнал звонков», «форма загрузки с проверкой». Справа от центра два узла: «Витрины» и «BI-дашборды». Внизу отдельная пометка «поручение обработки ПД, окно регламентных работ 02:00–05:00». Чертёжный стиль, подписи по-русски.
Смета: из чего складываются 250 000 ₽
Считаем слой сбора для модельной компании: 1С:УТ 11, amoCRM, две таблицы отделов, суточное обновление. Это та часть проекта, которая идёт до витрин и дашбордов и почти никогда не расписывается в коммерческих предложениях подробно.
Последняя строка выглядит самой скучной и режется первой. Режется зря: без журнала загрузок вы узнаёте о непрошедшей ночной выгрузке от коммерческого директора, который в 10 утра смотрит на вчерашний день и делает выводы о падении продаж. Уведомление о сбое и кнопка повторного запуска — это разница между «отчёты обновились с опозданием на два часа» и «квартал считали по неполным данным». Что ещё входит в такой контур наблюдения, разобрано в материале про мониторинг автоматизации.
Что меняет цену в обе стороны. Вниз, до 150 000–180 000 ₽: один источник вместо двух, отсутствие ручных таблиц, готовый порядок в справочниках, суточное обновление и согласие жить на восьми объектах вместо пятнадцати. Вверх, до 400 000–600 000 ₽: несколько юрлиц с разными справочниками, самописная конфигурация 1С, три и более источника, требование обновления чаще раза в час, необходимость восстановить историю за прошлые годы из архивных копий. Отдельно дорожает всё, что связано с миграцией данных из старой системы: архив почти всегда оказывается грязнее, чем помнит заказчик.
На сопровождение закладывается 20 000 ₽/мес для суточного контура — это разбор сбоев загрузки, правка витрин при появлении новых складов и статей, добавление метрик. Три года владения при таком раскладе дают 720 000 ₽ сопровождения поверх проекта, и именно эта сумма, а не цена лицензии, определяет бюджет аналитики. Логика такого счёта подробно разобрана в материале про стоимость владения автоматизацией.
Две группы столбцов в рублях. Левый столбец «Слой сбора сразу — 250 000 ₽» одним цветом. Правый столбец «Прямое подключение, первый год — 495 600 ₽» разбит на пять сегментов с подписями: подключение и дашборды 60 000 ₽, разбор инцидентов 84 000 ₽, простой отдела 21 600 ₽, восстановление после обновлений 80 000 ₽, пересборка на слой сбора 250 000 ₽. Между столбцами выносная подпись «переплата 245 600 ₽». Ось Y — рубли, все значения подписаны.
Как понять, что слой сбора действительно работает
Приёмка такого этапа проходит не по слову «настроено», а по пяти проверкам, которые заказчик может провести сам. Каждая делается за несколько минут и не требует технических знаний.
- 1Откройте журнал загрузок за последние 14 дней. Там должно быть 14 записей со статусом, временем начала и числом принятых строк по каждому источнику — а не пустая таблица и фраза «всё грузится».
- 2Попросите показать, что происходит при сбое. Правильный ответ: загрузка помечается неуспешной, витрины не перезаписываются наполовину, ответственный получает уведомление, есть кнопка повторного запуска. Неправильный: «мы посмотрим логи».
- 3Сверьте одну цифру вручную. Возьмите выручку за прошлый вторник из витрины и из 1С. Они обязаны совпасть до рубля, а если не совпадают — должно существовать письменное объяснение, почему именно так и задумано.
- 4Проверьте закрытый период. Пересчитайте отчёт за позапрошлый месяц дважды с интервалом в неделю. Цифра не должна измениться сама по себе; если изменилась — в журнале обязана быть запись о том, какой документ это вызвал.
- 5Спросите, кто получает уведомление о сбое, и убедитесь, что это сотрудник компании, а не только подрядчик. Иначе в день окончания договора на сопровождение контур становится немым.
Эти же пять пунктов стоит внести в акт приёмки этапа. Разница между «слой сбора сдан» и «слой сбора сдан и проверен» измеряется одним кварталом: неконтролируемая загрузка ломается тихо, и обнаруживают это по расхождению в квартальном отчёте, а не в момент поломки.
Когда всё это не нужно
Слой сбора окупается не всегда, и честнее сказать это до договора. Есть четыре ситуации, в которых мы сами советуем не строить хранилище и обойтись малым.
- Один источник и один читатель. Вся отчётность собирается из 1С, смотрит её собственник и главный бухгалтер. Здесь достаточно ночной копии базы и десятка типовых отчётов конфигурации — разбор границы есть в материале про автоматизацию без замены 1С.
- Меньше пяти регулярных отчётов. Слой сбора стоит почти одинаково при пяти и при двадцати витринах, поэтому на малом наборе цена одного отчёта получается неприемлемой. Сначала имеет смысл довести до ума ручную сборку и посмотреть, какие отчёты действительно открывают.
- Справочники в беспорядке. Если контрагенты дублируются, а номенклатура заведена в трёх группах, слой сбора аккуратно доставит этот беспорядок в дашборд. Порядок в данных идёт первым: сколько это стоит и как считается доля брака, разобрано в материале про семь проверок качества данных.
- Процесс ещё меняется. Компания перестраивает продажи, вводит новые юрлица или переезжает на другую конфигурацию 1С. Витрины, построенные на структуре, которая изменится через квартал, придётся переписать целиком. Разумнее подождать и жить на выгрузках.
Во всех четырёх случаях работает промежуточный вариант: выгрузка по расписанию в одну таблицу-приёмник и отчёты поверх неё. Он стоит десятки тысяч рублей вместо сотен, живёт год-полтора и не пропадает зря — определения метрик, справочники и логика расчёта, оформленные на этом этапе, переезжают в полноценное хранилище без переписывания. Строить сразу большое имеет смысл только тогда, когда есть чем его наполнить.
Дашборд читает не 1С. Он читает договорённость о том, что считать продажей, — слой сбора эту договорённость и хранит.
