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

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

Для разбора возьмём практическую модель PDCA, выросшую из работ Уолтера Шухарта и получившую развитие благодаря Эдвардсу Демингу: Plan — спланируй, Do — сделай, Check — проверь результат, Act — скорректируй подход. И снова по кругу. Это не полное определение управления, но удобная рамка для проверки, замкнут ли управленческий цикл.

Перенесём на операционку любой компании:

• Plan. Поставили план продаж на месяц по направлениям. Спланировали производство под него. Запланировали закупки под производство. Сверстали бюджет.

• Do. Продавали, производили, закупали, платили. Регистрировали факты.

• Check. Сравнили план и факт. Увидели отклонения: направление А недовыполнило на 20%, закупки превысили бюджет, срок производства сорван по трём заказам.

• Act. Разобрались в причинах. Приняли решения: перераспределили ресурсы, скорректировали план, изменили правило. Решения вернулись в Plan следующего цикла.

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

Теперь положим на эту схему внедрение 1С:ERP. Не по возможностям программы, а по тому, как это обычно выглядит в проблемных проектах из моей практики — там, где внедрение ограничилось автоматизацией операций и отчётов.

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

Инструменты для Check в системе есть, но сам этап не всегда встроен в управленческий процесс.Отчётов много. План-факт по продажам есть. По бюджету — есть, если бюджет вообще введён в систему. По производству — есть, если план в системе. Но отчёт есть, а обязательного сценария реакции на отклонение — нет. Кто, когда и зачем смотрит план-факт? Что обязан сделать, увидев отклонение? Этого в проекте не было.

Кроме этого, мало отчетов, показывающих динамику. А ведь для управления динамика зачастую важнее текущего значения показателя.

Plan часто остаётся вне рабочего контура системы. Планы продаж — в Excel у коммерческого директора. План производства считается в системе, но раз в месяц (об этом ниже). Бюджет — в Excel у финансиста, в систему не загружен или загружен для галочки. Системные механизмы планирования используют эпизодически: они требуют дисциплины, нормативов, ответственных. В таблице проще.

Act чаще всего остаётся за пределами автоматизированного процесса. Решения принимают на совещании. Устно, в лучшем случае — в протокол. Решение не связывают с версией плана, причиной и ответственным. План не корректируется, правила не меняются, следующий цикл начинается с того же места.

В итоге система уверенно фиксирует Do и даёт инструменты для Check, но Plan и Act продолжают жить вне единого процесса. Компания вложилась в регистрацию фактов и отчёты, но не спроектировала обязательную реакцию на них.

Один симптом разберу подробно, остальные — в таблице.

План считается раз в месяц, хотя система считает за минуты. Пример, который я приводил не раз: без системы предприятие считало план производства раз в месяц — чаще слишком трудоёмко. Внедрили систему, расчёт занимает минуты. И компания всё так же считает раз в месяц. Цикл не ускорился, хотя инструмент позволяет. Потому что ускорение цикла — это изменение регламента, а не программы: кто-то должен каждый день смотреть на изменения и запускать пересчёт. Этого «кого-то» не назначили.

Чтобы не спорить «виновата 1С или нет», полезно разделить три уровня: возможности продукта (что умеет конфигурация), объём проекта (что решили внедрить и настроить) и управленческую практику (как сотрудники используют систему после запуска). Программа может поддерживать планирование; проект может не включать его полноценное внедрение; компания может не пересматривать регламенты даже после настройки. Разрыв цикла обычно возникает на втором и третьем уровнях.

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

Plan и Act требуют ответственности. Ввести план в систему — значит зафиксировать обязательство. Пересчитывать его по событию — значит назначить ответственного за реакцию. Записать решение в систему — значит сделать его проверяемым. Всё это неудобно. В Excel и на совещании удобнее: ничто не фиксируется жёстко.

Отчёты без регламента — это декорация. Можно построить сто отчётов. Если нет правила «кто, когда смотрит и что обязан сделать», они не влияют на поведение компании. Это как приборная панель в машине, на которую никто не смотрит: датчики работают, а водитель едет по ощущениям.

Замкнутый цикл — это когда для каждого управляемого контура (продажи, производство, закупки, бюджет) определены четыре вещи:

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

2.     Что запускает пересчёт. Не «раз в месяц», а событие: отклонение факта от плана больше N%, сбой поставки, крупный заказ, поломка в узком месте. Кто и в какой срок пересчитывает и переподтверждает.

3.     Кто реагирует на отклонение. У каждого показателя — владелец. У владельца — обязанность: при отклонении за порог в течение такого-то срока представить причину и действие. В этой логике KPIполезнее использовать как сигнал отклонения и запуска реакции, а не только как элемент премирования.

4.     Как решение возвращается в план. Решение с совещания — это изменение плана или правила в системе, с датой и автором. Не протокол в папке.

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

Пример: контур продаж. План продаж хранится в системе по направлениям и неделям. Если прогноз выполнения падает ниже установленного порога — допустим, 90%, — руководитель направления в течение согласованного срока, скажем двух рабочих дней, указывает причину и действие. Если меняются ресурсы или приоритеты, создаётся новая версия плана с датой, автором и основанием. На следующем цикле факт сравнивают не с устаревшим первоначальным планом, а одновременно с первоначальной и актуальной версиями. В одной сцене — план, триггер, владелец, срок реакции и возврат решения в план. Это не «ещё один отчёт», а организационный механизм.

Владелец показателя, порог отклонения, срок реакции — по сути это и есть система KPI, только развёрнутая не к премии, а к управлению. Мы такие системы проектируем отдельно: сначала определяем, какие показатели реально отражают результат контура, потом закрепляем владельцев и правила реакции, и только затем настраиваем расчёт в 1С.

Правильная последовательность — не «настроим планирование в системе», а:

• Определить управляемые контуры: чем именно компания хочет управлять, а не только учитывать.

• Для каждого контура описать цикл: план → факт → отклонение → реакция → корректировка. Кто, когда, с какой частотой.

• Определить показатели, по которым оценивается цикл, и их владельцев.

• Проверить, что данные для плана и факта в системе есть и сопоставимы (одни аналитики, одни статьи — иначе план-факт не построится).

• Только потом настраивать систему под этот цикл.

Это работа на стыке методологии управления и автоматизации. Она часто выпадает из проекта: методологи и внедренцы отвечают за разные части задачи, а проектирование полного управленческого цикла не закреплено ни за одной из сторон. Но без него ERP остаётся калькулятором.

Экспресс-тест из восьми вопросов. Это авторская шкала из практики, а не нормативная методика, но она быстро показывает, где рвётся цикл.

1.     Планы продаж, производства и бюджета находятся в едином управляемом контуре, связанном с фактом, а не в разрозненных таблицах?

2.     Есть правило, какое событие запускает перепланирование, и кто за это отвечает?

3.     У каждого ключевого показателя есть владелец, который обязан реагировать на отклонение?

4.     Определён порог отклонения и срок реакции?

5.     Решения совещаний фиксируются как изменения плана или правил в системе?

6.     План-факт появляется в срок, когда на отклонение ещё можно повлиять?

7.     Можно посмотреть историю: какой был первоначальный план, когда и почему скорректировали?

8.     Если убрать все отчёты из системы на месяц — кто-то это заметит?

• 0–3 «да» — автоматизирован преимущественно учёт факта; цикл управления разомкнут.

• 4–6 «да» — отдельные элементы управления работают, но цикл зависит от ручных действий и конкретных сотрудников.

• 7–8 «да» — цикл в основном замкнут; следующий шаг — проверить скорость реакции и качество решений.

Автоматизация учёта необходима: без надёжного факта управлять нечем. Но факт — только часть цикла. Чтобы ERP стала частью системы управления, компания должна хранить актуальный план в едином контуре, связанном с фактом, назначить владельцев отклонений, установить сроки реакции и возвращать решения в новую версию плана. Стоимость лицензий и настройки ещё не определяет, получится ли система управления. Разницу создают регламенты: где хранится план, кто отвечает за отклонение и как принятое решение меняет следующий цикл.

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

Smart Process — автоматизация управленческого учёта, бюджетирования и бизнес-процессов на базе 1С. Если хотите проверить, где рвётся цикл у вас, — первичная консультация бесплатна

Реклама: ИП Шарипов Руслан Рафикович, ИНН 780226784621, erid: 2W5zFGnRJfK