Планирование в 1С:Управление торговлей 11.5 и 1С:Аналитика

Архитектура подсистемы планирования

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

Чтобы избежать этих крайностей, в системе 1С:Управление торговлей 11.5 (1С:УТ) реализована мощная подсистема планирования. Она позволяет не просто вводить цифры в таблицы, а выстраивать логичную, математически обоснованную цепочку от прогноза спроса до заказа конкретной партии у поставщика.

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

!Архитектура подсистемы планирования в 1С

Фундамент: Сценарии планирования

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

Что именно определяет сценарий?

Периодичность: В чем мы измеряем время? Это могут быть дни, недели, декады, месяцы, кварталы или годы. Нельзя в рамках одного сценария планировать продажи по неделям, а закупки — по месяцам.

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

Отражение в бюджетировании: Будут ли наши товарные планы передаваться в финансовый блок (если используется 1С:ERP или комплексная автоматизация).

> Сценарии позволяют бизнесу моделировать разные варианты будущего. Вы можете создать сценарий «Оптимистичный 2024» и «Пессимистичный 2024». В первом вы заложите рост продаж на 30%, а во втором — падение на 10%. Система параллельно рассчитает потребность в закупках для обоих вариантов, и эти данные не перемешаются между собой.

Каркас: Виды планов

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

Вид плана отвечает на два главных вопроса: что мы планируем и как мы это делаем.

Во-первых, здесь задается тип процесса: план продаж, план закупок, план остатков или план сборки/разборки.

Во-вторых, определяется важнейшая концепция 1С — вариант записи планов. Он бывает двух типов:

| Вариант записи | Как это работает | Когда применять | Пример из жизни | | :--- | :--- | :--- | :--- | | Суммирующий | Планы, созданные разными людьми или для разных подразделений, складываются вместе. | Когда менеджеры планируют продажи независимо друг от друга. | Менеджер Иванов запланировал продать 100 столов, а менеджер Петров — 50. Итоговый план компании составит 150 столов. | | Замещающий | Более новый план полностью стирает (замещает) данные старого плана за тот же период. | Когда планы спускаются «сверху вниз» или регулярно корректируются. | Отдел продаж составил план на 100 столов. Коммерческий директор посмотрел аналитику, создал свой план на 120 столов. План директора заместил план отдела. |

Кирпичи: Документы планирования и Источники данных

Самый нижний уровень — это сами документы (например, документ «План продаж»). Именно здесь появляются конкретные номенклатурные позиции, их количество и суммы.

Вводить тысячи строк вручную — неэффективно. Поэтому в 1С:УТ встроены Источники данных планирования. Это механизм, который позволяет системе автоматически собирать статистику из базы и на ее основе рассчитывать будущие показатели.

Источниками могут выступать:

Фактические продажи за прошлые периоды.

Текущие заказы клиентов.

Фактические остатки на складах.

Другие планы (например, план закупок может опираться на план продаж).

Математика автоматического планирования

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

Где:

— то, что нам нужно заказать у поставщика.

— наш утвержденный план продаж на будущий период.

— товары, которые уже лежат на нашем складе (или ожидаются к поступлению).

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

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

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

Сквозной процесс: от прогноза до обеспечения

Понимание архитектуры позволяет выстроить правильный сквозной процесс. В 1С:УТ он обычно состоит из четырех последовательных шагов.

Анализ и прогнозирование (План продаж). На основе статистики прошлых месяцев (источник данных) система генерирует черновик плана продаж. Коммерческий директор вносит корректировки с учетом сезонности или маркетинговых акций и переводит документ в статус «Утвержден».

Оценка ресурсов (План остатков). Система фиксирует, сколько товара есть на складах сейчас и сколько уже едет от поставщиков. Это позволяет понять стартовую позицию.

Формирование потребности (План закупок). Используя формулу, описанную выше, 1С вычитает из плана продаж имеющиеся остатки. Результат записывается в документ «План закупок».

Исполнение (Формирование заказов по плану). Утвержденный план закупок не делает движений товаров, это лишь намерение. Чтобы товар реально приехал, менеджер по закупкам открывает специальное рабочее место «Формирование заказов поставщикам по плану». Система показывает: «По плану нужно 400 кресел, заказов пока создано 0». Менеджер в пару кликов генерирует реальные документы «Заказ поставщику».

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

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

Формирование планов продаж

Любая коммерческая деятельность начинается с ответа на один простой вопрос: сколько мы собираемся продать? План продаж — это локомотив, который тянет за собой весь остальной состав бизнес-процессов. Если этот локомотив стоит на месте или едет в неверном направлении, склады переполняются ненужным товаром, а отдел закупок тратит бюджет впустую.

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

Два уровня планирования: от общего к частному

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

Чтобы удовлетворить потребности обоих, в 1С:УТ предусмотрено два взаимосвязанных документа:

План продаж по категориям — укрупненный инструмент для топ-менеджмента. Здесь планирование ведется товарными группами (например, «Холодильники», «Смартфоны», «Офисная мебель»).

План продаж по номенклатуре — детальный документ. Здесь фигурируют конкретные позиции с артикулами, характеристиками и точным количеством.

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

> Представьте, что вы запланировали продать 1000 пар кроссовок (категория). Система анализирует прошлые продажи и видит, что 40% спроса обычно приходится на 42 размер, 30% — на 43 размер, и так далее. Опираясь на эти доли, 1С автоматически создаст детальный план продаж по номенклатуре, где укажет точное количество пар каждого размера.

Способы заполнения плана продаж

Когда вы создаете документ «План продаж по номенклатуре», перед вами открывается пустая таблица. Внести в нее данные можно тремя основными способами, в зависимости от масштабов вашего бизнеса и уровня автоматизации.

1. Ручное заполнение

Самый простой, но трудоемкий метод. Пользователь вручную подбирает товары из справочника и вписывает цифры в колонки с периодами.

Этот метод оправдан только в двух случаях:

Компания продает узкий ассортимент (до 50 позиций).

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

2. Заполнение по отбору

Если ассортимент насчитывает тысячи позиций, ручной ввод невозможен. В этом случае используется механизм отбора. Пользователь задает фильтры (например, «выбрать все товары из папки 'Бытовая химия', которые есть в наличии на центральном складе»). Система автоматически формирует список строк в документе. Менеджеру остается только проставить плановое количество.

3. Автоматическое заполнение по формулам (Источники данных)

Это самый мощный и профессиональный инструмент 1С:УТ. Он позволяет системе самой рассчитать будущие продажи на основе математических формул и исторических данных.

!Схема автоматического формирования плана продаж

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

Где:

— расчетное количество товара, которое мы ожидаем продать.

— реальные продажи этого же товара за аналогичный период в прошлом (например, за прошлый месяц или за тот же месяц прошлого года).

— ожидаемый процент роста или падения рынка (задается вручную).

— поправочный коэффициент, учитывающий всплески или падения спроса в определенные месяцы.

Рассмотрим работу формулы на числах. Компания продает снегокаты. В ноябре прошлого года было продано 500 штук (). В этом году компания провела масштабную рекламную кампанию и ожидает рост продаж на 20%, то есть . Ноябрь — начало сезона, поэтому .

Подставляем значения: . Итого, система автоматически рассчитает и подставит в план продаж цифру 900 снегокатов.

!Интерактивный калькулятор прогноза продаж

Статусы документа: управление жизненным циклом плана

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

| Статус документа | Что означает | Влияние на систему | Пример использования | | :--- | :--- | :--- | :--- | | В подготовке | Черновик. Менеджер еще работает с цифрами, подбирает формулы, корректирует данные. | Никакого. Другие подсистемы (закупки, производство) этот план не видят. | Аналитик собирает статистику за прошлый год и генерирует первичные цифры. | | На утверждении | Расчет окончен. Документ передан руководству на проверку. Редактировать его рядовой сотрудник уже не может. | Никакого. План все еще не является руководством к действию. | Коммерческий директор проверяет, бьются ли расчеты аналитика со стратегией компании. | | Утвержден | Официальный документ. Руководство согласно с цифрами. | Критическое. Именно этот статус делает план источником данных для формирования планов закупок и бюджетов. | План согласован. Отдел закупок видит потребность и начинает искать поставщиков. | | Отменен | План признан неактуальным (например, из-за резкого изменения ситуации на рынке). | Документ перестает влиять на систему, его данные обнуляются для других подсистем. | Из-за сбоя поставок сырья компания отменяет план продаж определенной линейки товаров. |

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

Сквозной пример: от настройки до утверждения

Давайте соберем все концепции воедино и посмотрим, как выглядит процесс формирования плана продаж в реальной жизни торговой компании «Альфа», торгующей электроникой.

Шаг 1. Выбор аналитики. Коммерческий директор решает, что планировать продажи мы будем на следующий месяц (периодичность — месяц) в рублях. Он создает документ «План продаж по номенклатуре» и выбирает соответствующий сценарий.

Шаг 2. Настройка источника данных. Менеджер нажимает кнопку «Заполнить товары» и выбирает автоматический расчет по формуле. В качестве источника он указывает «Продажи за прошлый месяц».

Шаг 3. Корректировка. Система загружает в таблицу 2000 позиций электроники и проставляет цифры, идентичные прошлому месяцу. Менеджер знает, что в следующем месяце ожидается «Черная пятница». Он выделяет группу товаров «Телевизоры» и применяет к ним групповую обработку: увеличить плановое количество на 30%.

Шаг 4. Согласование. Менеджер переводит документ в статус «На утверждении». Коммерческий директор открывает план, проверяет итоговую сумму ожидаемой выручки. Если цифра его устраивает, он меняет статус на «Утвержден».

Шаг 5. Передача эстафеты. Как только план продаж утвержден, он становится фундаментом для следующего этапа. Теперь менеджер по закупкам может открыть свой интерфейс, нажать одну кнопку, и система автоматически рассчитает, сколько телевизоров нужно докупить у поставщиков, чтобы обеспечить этот утвержденный план продаж (с учетом того, что уже лежит на складе).

Формирование плана продаж — это перевод интуитивных ожиданий бизнеса на строгий язык цифр. Использование автоматических формул и правильная работа со статусами в 1С:УТ позволяют сделать этот процесс быстрым, прозрачным и защищенным от человеческих ошибок.