Деньги, планирование и аналитика: контур, который считает бизнес

Эта статья есть и на английском: English version.

Четыре класса из этой статьи отвечают на четыре вопроса руководителя, и вопросы идут в строгом порядке. Что уже произошло — это учёт, ERP. Что мы собираемся сделать — это план и бюджет, EPM. Что происходит прямо сейчас и почему — это аналитика, BI. Чем мы заняты, чтобы это изменить — это проекты и портфель.

Порядок здесь не условность. Каждый следующий класс питается данными предыдущего, и попытка перепрыгнуть ступень заканчивается одинаково: система есть, цифрам не верят. Бюджет, построенный на учёте, где остатки трёх складов не сведены, — упражнение в чистописании. Аналитика поверх источников, где «выручка» у отделов считается по-разному, показывает три разных выручки и провоцирует спор вместо решения. Портфель проектов, где статусы зелёные до последнего дня, — не система управления, а отчётный ритуал.

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

Ниже — что делает каждый из четырёх классов, кому он нужен и после чего внедряется. В конце — как они связаны, российские системы и общий чек-лист выбора.

Что в этой статье

• Учётное ядро: ERP — что система считает, из чего состоит и как выбирать под дедлайн 2028

• Бюджеты и планирование: EPM и CPM — бюджетный цикл, консолидация, сценарии

• Аналитика: BI и путь к системам поддержки решений — от отчётов к решениям на данных

• Проекты и портфель: от таск-трекера до PPM — чем компания занята, чтобы измениться

• Как эти четыре класса связаны между собой — порядок ходов и общий словарь

• Роль ИИ в контуре управления — что работает, где граница и почему пропускают валидацию

• Российские системы — реестр, распространённые решения, как читать таблицы

• Типовые ошибки и чек-лист выбора — общий разбор и что проверить до покупки

Учётное ядро: ERP

ERP покупают первой чаще любого другого класса ИТ-систем: топ-менеджменту это кажется понятной ценностью и решением проблем. Но в итоге это часто и самая дорогая ошибка в последовательности внедрения. В пирамиде ИТ-систем ERP стоит наверху: без проработанного производственного контура она не считает ресурсы, а аккуратно складывает ручной ввод, которому нельзя доверять и который раздувает штат. То есть автоматизация начинает не сокращать ручной труд, а увеличивать. Но если убрать маркетинг, ERP — это система, в которой предприятие считает свои ресурсы: деньги, людей, материалы, мощности (Enterprise Resource Planning, планирование ресурсов предприятия). Это не система управления предприятием. Разберём подробнее, что она делает, чего не делает, из каких модулей состоит и какие показатели считает.

Что делает ERP — и чего не делает

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

Отсюда её граница, о которую разбился не один проект: ERP не годится для оперативного управления цехом. Она не работает с минутами, литрами и штуками, не предназначена для перепланирования смены в реальном времени. Для этого существует производственный контур — MES, SCADA, APS; ставить туда ERP — всё равно что управлять станком из бухгалтерии. Разбор этой границы — в отдельной статье про MES и промышленный контур.

И вторая оговорка из практики. Абсолютное большинство проектов под вывеской «ERP» оказываются гибридами: внутри — модули MES, WMS, MDM, то есть управление производством, складом и справочниками. Значит, сравнивать надо не названия систем, а состав модулей под ваши задачи. А самая опасная ошибка — внедрять всё одним проектом и сразу на всю организацию. Это практически гарантированный провал.

Модули, которые встречаются в жизни

На практике «внедрить ERP» почти всегда означает выбрать набор из этих блоков:

• Финансы и бухгалтерия — ядро; главный заказчик — финансовый директор и налоговая отчётность.

Эффект: закрытие периода из недель в дни, одна версия цифр.

Недостаток: самая жёсткая часть системы — перестройка учётной политики после запуска болезненна.

• Закупки и снабжение — заявки, лимиты, договоры; смежный класс — SRM.

Эффект: прозрачность обязательств и лимитов, меньше «внезапных» платежей.

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

• Объёмно-календарное планирование производства — «сколько и когда», без цеховой детализации.

Эффект: связка плана продаж с мощностями на горизонте месяцев.

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

• Управление персоналом — кадровый учёт и расчёт зарплаты; в крупных конфигурациях — отдельный HRM-контур.

Эффект: обязательный учёт и расчёты без ручных ошибок.

Недостаток: HR-функции глубже учёта (найм, развитие) модуль ERP закрывает хуже специализированных систем.

• Управление активами — базовый учёт; полноценный контур ТОиР — это уже класс EAM.

Эффект: активы видны в деньгах.

Недостаток: создаёт иллюзию «у нас есть ТОиР», которой нет.

• APS-модуль — расписания производства; как самостоятельный класс жизнеспособен редко, чаще — модуль ERP или MES.

Эффект: выполнимый план вместо желаемого.

Недостаток: требователен к точности нормативов — на неточных данных двигает план вправо день за днём.

Правило выбора простое: модуль, который вам критичен, должен быть у вендора зрелым, а не «в дорожной карте». Зрелость проверяется референсами в вашей отрасли, а не презентацией.

Что ERP считает: показатели и метрики

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

Деньги: от операции до отчёта. Плановая и фактическая себестоимость, отклонение факта от плана, маржа по продукту, заказу и клиенту. Дебиторская и кредиторская задолженность, платёжный календарь, кассовые разрывы. План-факт бюджета по статьям и центрам ответственности. Отдельный показатель — срок закрытия периода: сколько дней проходит от конца месяца до готовых цифр. Это самый честный индикатор зрелости учёта.

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

Мощности и план: от плана до выпуска. Загрузка мощностей по участкам, выполнение объёмного плана, нормо-часы на изделие, себестоимость передела. Важная оговорка: ERP считает это на горизонте недель и месяцев. Сменное задание и выработка на линии — территория MES.

Заказы и клиенты: от заказа до денег. Длительность цикла заказа, доля заказов, выполненных вовремя и в полном объёме, средний срок оплаты. Здесь ERP смыкается с CRM: сделка живёт в CRM, отгрузка и деньги — в ERP.

Люди. Фонд оплаты труда, численность и её динамика, фонд рабочего времени, доля переработок. Глубже — HR-tech.

Где проходит граница. ERP считает факт по ресурсам и производные от него. Она отвечает на вопрос «сколько потратили и сколько осталось», но не на вопрос «что с этим делать». Сравнение сценариев, тренды и витрины для руководителя живут в аналитическом контуре. Бюджетная модель группы компаний — в EPM, подготовка самого решения — в системах поддержки принятия решений. Поэтому ERP и не система управления предприятием: она даёт достоверную базу, на которой управление становится возможным.

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

Цифра без нормы бесполезна. Любой показатель из списка выше работает только в сравнении: с планом, с нормативом, с прошлым периодом, с другим подразделением. ERP умеет хранить и то и другое — но норматив в неё кладёт компания, а не вендор. Пустые справочники нормативов — самая частая причина, по которой «система есть, а показателей нет».

Что ERP даёт бизнесу — и её типовые недостатки

Эффект. Один контур учёта вместо десятка таблиц: закрытие месяца из недель превращается в дни; цифры перестают расходиться между отделами; появляется база для планирования закупок и производства и для честной аналитики поверх. Косвенный, но важный эффект — дисциплина справочников и процессов, которую система принуждает поддерживать.

Недостатки, о которых говорят меньше. Стоимость и срок: полноценное внедрение — от года до трёх, и миграция данных съедает до половины бюджета. Жёсткость: перестроить процессы после запуска дорого, поэтому кривой процесс, попавший в систему, живёт в ней годами. Зависимость от качества ввода: ERP не создаёт данные — она их учитывает, и на производстве без нижних уровней пирамиды это ручной ввод. Сопротивление людей: для половины пользователей ERP — «лишняя отчётность», и без работы с мотивацией проект буксует.

Кому нужна ERP, кому рано — и после чего внедрять

Нужна, когда компания переросла 50–100 человек и учёт перестал сходиться в головах и таблицах: несколько подразделений, полноценное планирование, налоговая отчётность по ОСНО, больше одного юрлица. Симптомы «пора»: закрытие месяца растягивается на недели; одни и те же цифры в разных отделах не совпадают; решения о закупках принимаются вслепую.

Рано или не нужна: бизнесу до ~50 человек обычно достаточно бухгалтерского контура, CRM и товарного учёта в торговле (1С:УТ, МойСклад). Полноценная ERP на этом масштабе окупается редко и съедает управление внедрением. По подклассам: модуль объёмного планирования не нужен сервисным компаниям без производства; HRM-контур в составе ERP избыточен, если людей меньше сотни.

С чем связана. ERP — учётное ядро ландшафта: берёт клиентские данные из CRM, производственные факты из MES, справочники — из MDM; отдаёт данные наверх в BI и EPM (бюджетирование). Чем чище эти связи, тем меньше ручных сверок.

После чего внедрять и почему. Зависит от профиля. Если компания разрабатывает собственные изделия, к этому добавляется ещё один вход: состав изделия и спецификацию ERP берёт из контура PLM, PDM и BIM, а не собирает заново.

Производственная компания идёт по пирамиде ИТ-систем снизу вверх — это и есть её главное отличие от торговой: АСУ ТП и SCADA → MES → и только затем ERP. Невозможно прийти на верхние уровни без проработки нижних: ERP без управления производством кормится ручным вводом — данные недостоверны, а штат растёт за счёт людей, которые их вбивают. Торгово-сервисная компания начинает с CRM (её данные рождаются в точке контакта с клиентом) и порядка в справочниках — затем ERP, затем аналитика и надстройки. Общее правило: ставить ERP до наведения порядка в процессах — значит забетонировать беспорядок.

2026 год: дедлайн, после которого выбор перестал быть добровольным

Три факта задают контекст любого ERP-решения в России:

• Минцифры установило срок перехода на отечественные ERP — 1 января 2028 года («Ведомости», июнь 2026). Норматив бьёт прежде всего по субъектам критической инфраструктуры и госсектору; для частной компании вне этого периметра это не приказ, а риск-менеджмент — поддержка, обновления, санкционные риски.

• С марта 2026-го ERP-системы субъектов КИИ отнесены к значимым объектам критической информационной инфраструктуры — со всеми требованиями к защите. Класс ПО сам по себе объектом КИИ не становится: категорируется система у конкретного субъекта.

• При этом SAP, по данным «Ведомостей» (июнь 2026), всё ещё работает в 80–90 % крупнейших промышленных холдингов — то есть основная волна миграций впереди, и очередь к интеграторам будет расти.

Что это значит на практике: если вы на SAP или Oracle, вопрос уже не «переходить ли», а «успеем ли выбрать и пройти пилот до того, как рынок внедрений перегреется». Крупнейший заявленный переход уже идёт: РЖД, один из крупнейших работодателей страны, уходит с SAP на 1С.

Ориентир по масштабу. Проект целиком обходится малому бизнесу в несколько миллионов рублей, среднему в десятки, холдингу в сотни — от ста миллионов до миллиарда. Сроки: компактный запуск занимает 6–9 месяцев, полноценное внедрение в среднем бизнесе — около года, холдинг разворачивает систему волнами по площадкам и укладывается в два-четыре года. Считать надо не лицензии: работы обычно кратно дороже них. Отдельными строками идут внедрение (анализ процессов, описание, согласование, настройка), сопровождение, инфраструктура, миграция данных и параллельная работа двух систем. Это ориентир для бюджетной заявки, а не смета.

Российские ERP: что есть в реестре

Рынок отечественных ERP измеряется сотнями миллиардов рублей, и большую его часть держит 1С. Это данность, с которой спорить дорого. Ниже — системы из единого реестра российского ПО (проверяли в августе 2026-го; реестровые имена местами отличаются от рыночных — не пугайтесь).

• 1С:ERP Управление предприятием — средний и крупный бизнес большинства отраслей. комментарий: де-факто стандарт рынка; широчайшая экосистема франчайзи и кадров

• Галактика ERP — промышленность, крупные предприятия. комментарий: ветеран рынка; вендор заявляет высокое покрытие функционала SAP — оценивайте по референсам, а не по заявлению

• Global-ERP — промышленность. комментарий: в реестре как «Global-ERP: Комплексная система управления предприятием»

• ТУРБО ERP — крупные компании, высоконагруженный учёт. комментарий: платформа «Консист»

• Монолит.ERP — производство, FMCG. комментарий: реестровое имя — «Монолит.ERP»

• ПАРУС-Предприятие 8 — госсектор, бюджетные учреждения. комментарий: сильная специализация на бюджетном учёте

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

Бюджеты и планирование: EPM и CPM

Бюджетный цикл в компании без EPM выглядит одинаково везде: сорок файлов Excel, которые собираются по почте, две недели сведения, три версии «финальной» модели. И вопрос собственника «а если выручка просядет на пятнадцать процентов?», после которого всё считается заново. Класс, о котором пойдёт речь, превращает это в процесс. Разберём, из чего он состоит, кому нужен и после чего его внедряют.

Что делает класс — и чего не делает

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

Чего класс не делает: не заменяет учёт и не наводит в нём порядок. Консолидировать можно только то, что учтено, — если в одном юрлице статьи затрат называются иначе, EPM это не исправит, а покажет. И не принимает решений: система считает сценарии, выбор между ними остаётся управленческим.

Подклассы: из чего состоит класс

Бюджетирование и планирование. Формы сбора, версии бюджета, согласование, лимиты, план-факт.

Эффект: цикл сжимается с недель до дней, а версия всегда одна.

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

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

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

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

Сценарное моделирование. «Что если» по выручке, курсу, ценам, объёмам; стресс-тесты.

Эффект: ответ на вопрос собственника считается за часы, а не за неделю.

Недостаток: качество сценария равно качеству модели: красивый инструмент на плохих допущениях даёт красивый неверный прогноз.

Цели и показатели: OKR, KPI. Каскадирование целей, связь стратегии с бюджетом.

Эффект: цели перестают жить отдельно от денег.

Недостаток: легко превращается в отчётный ритуал — показатели зелёные, стратегия стоит.

ESG и нефинансовая отчётность. Сбор и раскрытие нефинансовых показателей.

Эффект: требования инвесторов и контрагентов закрываются системно, а не разовым авралом.

Недостаток: нужен там, где этого требуют, — иначе избыточно.

Кому нужен класс, кому рано — и после чего внедрять

Нужен группе компаний, бизнесу с несколькими юрлицами или сложным бюджетным циклом. Симптомы «пора»: бюджет собирается в десятках файлов; закрытие занимает недели; на вопрос «а если» уходит несколько дней; версии бюджета расходятся между подразделениями.

Рано или не нужен: одному юрлицу с простой структурой затрат обычно хватает бюджетного модуля учётной системы и дисциплины.

Портфель проектов приходит сюда снизу — из систем управления проектами: EPM консолидирует деньги портфеля, но сами проекты живут не в нём.

С чем связан и когда внедрять. Класс, как правило, ставится после ERP и аналитического контура — консолидировать можно только то, что учтено, а сценарии строятся на данных, которые уже собраны и очищены. Вход — учётные данные из ERP и BI; выход — отчётность собственникам, инвесторам и аудиту.

Что класс даёт бизнесу — и его типовые недостатки

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

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

Какой уровень эффекта вы покупаете

Полезная рамка перед стартом. В книге Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» разведены два уровня изменений: точечная оптимизация даёт прибавку на порядок меньше, чем трансформация — перестройка того, как устроен бизнес (на кейсах книги — около полупункта EBIT против пяти). Разница не в старательности, а в замахе.

Для EPM это переводится буквально. Можно автоматизировать существующий бюджетный процесс: те же формы, те же сроки, только быстрее — это оптимизация, и её эффект честно невелик. А можно поменять сам способ управления: перейти от годового бюджета к скользящему планированию, связать цели с деньгами, начать принимать решения по сценариям. Второе даёт кратно больше и стоит кратно дороже — в усилиях, не в лицензиях. Ошибка в том, чтобы купить инструмент под второе, а сделать первое, — и потом удивляться отдаче.

2026 год: контекст

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

Ориентир по масштабу. Проект целиком: единицы миллионов рублей и 4–8 месяцев. Специализированные платформы цен публично не раскрывают, считают по запросу. Основной риск бюджета не в лицензии, а в методологии: несогласованная модель консолидации переделывается дороже, чем внедряется.

Аналитика: BI и путь к системам поддержки решений

Знакомая сцена: совещание, у финансового директора одна цифра выручки, у коммерческого — другая, и полчаса уходит на выяснение, чья правильная. Обе выгружены из систем, обе «верные» — просто посчитаны по-разному. Аналитический контур существует ровно для того, чтобы этой сцены не было: одна версия правды, доступная без недели ожидания отчёта. Разберём, из чего состоит контур, почему BI поверх хаоса визуализирует хаос и что должно появиться в компании раньше первого дашборда.

Что делает контур — и чего не делает

Аналитический контур собирает данные из рабочих систем — ERP, CRM, производственных, — приводит их к общему виду и превращает в картину для решений: отчёты, дашборды, сценарии «что-если».

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

Подклассы: из чего состоит контур

BI-платформы — отчёты и дашборды. Витрина контура: визуализация, регулярная отчётность, self-service — когда сотрудник собирает нужный срез сам, без заявки аналитику.

Эффект: руководитель видит бизнес сегодня, а не в отчёте за прошлый месяц; ручные сверки Excel уходят.

Недостаток: BI поверх хаоса визуализирует хаос — красивый дашборд на грязных данных лишь придаёт ошибке убедительности. А self-service без правил плодит сотни личных дашбордов с противоречивыми цифрами.

DWH и озёра данных. Хранилище под витриной: данные всех систем в одном месте, с историей, не нагружая рабочие системы. Классическое хранилище (DWH) держит структурированные данные под отчётность. Озеро данных хранит сырые данные под будущие задачи, а lakehouse совмещает оба подхода.

Эффект: история не теряется при смене систем, тяжёлые запросы не кладут рабочую ERP.

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

Слой подготовки данных (ETL/ELT). Незаметный, но обязательный: забрать данные из источников, очистить, привести к единой модели.

Эффект: сверки и склейки, которые аналитики делали руками, выполняются автоматически и одинаково каждый день.

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

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

Эффект: решение готовится минуты, а не дни; знания компании перестают жить только в головах.

Недостаток: качество рекомендации равно качеству данных и документов под ней — а проверить рекомендацию сложнее, чем цифру в отчёте.

Кому нужен контур, кому рано — и после чего внедрять

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

Рано или не нужен: бизнесу на одной-двух системах обычно хватает их встроенных отчётов; полноценное DWH на этом масштабе не окупится. СППР без выстроенного слоя данных под ней — верхний этаж, входа с него нет.

С чем связан и когда внедрять. Контур ставится после первого стабильного источника данных — и дорастает вместе с ландшафтом. Подключать к аналитике систему, в которой не навели порядок, значит умножать хаос на красивую визуализацию. По пирамиде ИТ-систем это уровень над учётными системами: вход — все системы компании, выход — руководителю и в бюджетный контур EPM. Опора контура — единая модель данных и справочники: без них три «Иванова» из трёх систем так и не склеятся в одного клиента.

Что контур даёт бизнесу — и его типовые недостатки

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

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

2026 год: контекст

После ухода Power BI, Tableau и Qlik российский сегмент BI — один из самых конкурентных на рынке отечественного ПО: за несколько лет платформы закрыли базовые сценарии визуализации и отчётности и соревнуются уже в ИИ-функциях. Практический вопрос выбора сместился с «есть ли замена» на «какая из замен приживётся у наших пользователей».

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

Проекты и портфель: от таск-трекера до PPM

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

Что делает класс — и чего не делает

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

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

Подклассы: из чего состоит класс

Таск-трекеры и командные доски. Задачи, спринты, канбан, комментарии, файлы.

Эффект: работа команды видна целиком, договорённости не теряются в переписке.

Недостаток: доска показывает задачи, но не проект: без сроков, зависимостей и ответственных за результат это список дел, а не управление.

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

Эффект: видно, какая задержка съедает срок, а какая нет, и во что обойдётся перенос вехи.

Недостаток: требует навыка планирования; красивый график, который никто не поддерживает, устаревает за две недели.

PPM — управление портфелем. Реестр проектов, приоритеты, ресурсы, ворота принятия решений.

Эффект: становится видно, что двадцать инициатив конкурируют за одних и тех же пятерых людей, — и появляется основание для честного «нет».

Недостаток: нужен там, где проекты действительно конкурируют за ресурсы; на трёх проектах это лишний слой.

PSA — проектная экономика в услугах. Учёт времени, ставки, рентабельность проекта, биллинг.

Эффект: видно, какие проекты и клиенты зарабатывают, а какие съедают маржу.

Недостаток: держится на учёте времени, а его сотрудники не любят; без объяснения «зачем» цифры будут рисованными.

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

Эффект: перегруз виден до того, как человек выгорит и сорвёт сразу три проекта.

Недостаток: точность зависит от честности данных о загрузке — а это снова дисциплина, не софт.

Кому нужен класс, кому рано — и после чего внедрять

Нужен примерно от пяти параллельных проектов; PPM — когда проекты начинают конкурировать за одних и тех же людей. Симптомы «пора»: статус зависит от того, кого спросили; сроки сдвигаются по цепочке и никто не видит связи; люди назначены в несколько проектов одновременно, и никто не считал, сходится ли это по времени.

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

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

Почему система не создаёт проектное управление

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

На практике это значит: если у проектов нет заказчика с полномочиями, если сроки назначаются сверху без разговора об объёме, если статус «зелёный» до самого срыва — трекер не поможет. Он сделает эти проблемы видимыми, что уже полезно, но лечить их придётся управленчески. Сначала договорённости о том, как мы ведём проекты, потом инструмент, который эти договорённости поддерживает.

Тот же порядок работает и на личном уровне. Управленческие договорённости начинаются с того, что руководитель сам удерживает цели, решения и обязательства, а не вспоминает их на статусе. Мы собрали это в «Соколе»: он связывает цели с ежедневной управленческой работой и помогает готовить решения. Честная граница: это личный контур одного человека — он не заменяет ни трекер, ни PPM-систему и не ведёт проекты команды.

Что класс даёт бизнесу — и его типовые недостатки

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

Недостатки, о которых говорят меньше. Класс требует постоянного поддержания данных — это ежедневная работа участников, а не разовая настройка. Легко скатывается в контроль ради контроля: чем больше полей обязательны, тем менее честны данные. И самая частая ловушка: систему внедряют вместо управленческих договорённостей, а потом обвиняют в том, что она «не заработала».

2026 год: контекст

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

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

Как эти четыре класса связаны между собой

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

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

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

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

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

Как выглядит нарушенный порядок. Компания покупает систему бюджетирования раньше, чем свела учёт. Ставит BI до порядка в источниках — и контур честно показывает всем, что порядка нет. Берёт корпоративную систему управления портфелем на пять проектов — и получает тяжёлый процесс на лёгкой задаче и гарантированный саботаж. Во всех трёх случаях технология работает, а доверия к цифрам не появляется.

Роль ИИ в контуре управления

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

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

Что на подходе (прогноз, не факт). Агенты, ведущие типовые операции закупочного цикла от заявки до проводки под контролем человека. Ассистент финансового директора, готовящий разбор к бюджетному комитету. Агенты-аналитики, собирающие материал к совещанию по повестке. Ассистент руководителя проектного офиса с предложениями по перераспределению ресурсов.

Условия, без которых не взлетит. Данные: два-три года чистой истории операций, вычищенные справочники, единые статьи и аналитики по всей группе. Прогноз на грязных данных врёт не краснея, а модель, обученная на несопоставимых рядах, честно выдаёт несопоставимый результат. Процессы: устоявшийся контур планирования и описанная методология — ИИ ускоряет расчёт, но не заменяет решение о том, как считать. И отдельно, самое важное для этого контура: единые определения метрик до всякого ИИ. Если «выручка» у отделов считается по-разному, ассистент молча выберет одну из версий и не скажет, что версий было две. Люди и безопасность: финансовые данные группы — чувствительный контур; права модели не шире прав сотрудника, которого она ассистирует, и ассистент не должен отвечать человеку тем, чего тому видеть не положено.

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

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

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

Российские системы

Рынок отечественных ERP измеряется сотнями миллиардов рублей, и большую его часть держит 1С. Это данность, с которой спорить дорого. В таблицах ниже — системы из единого реестра российского ПО и распространённые на рынке решения; проверка проводилась в августе 2026 года. Реестровые имена местами отличаются от рыночных — не пугайтесь.

Учётное ядро (ERP)

• 1С:ERP Управление предприятием — средний и крупный бизнес большинства отраслей. комментарий: де-факто стандарт рынка; широчайшая экосистема франчайзи и кадров

• Галактика ERP — промышленность, крупные предприятия. комментарий: ветеран рынка; вендор заявляет высокое покрытие функционала SAP — оценивайте по референсам, а не по заявлению

• Global-ERP — промышленность. комментарий: в реестре как «Global-ERP: Комплексная система управления предприятием»

• ТУРБО ERP — крупные компании, высоконагруженный учёт. комментарий: платформа «Консист»

• Монолит.ERP — производство, FMCG. комментарий: реестровое имя — «Монолит.ERP»

• ПАРУС-Предприятие 8 — госсектор, бюджетные учреждения. комментарий: сильная специализация на бюджетном учёте

Планирование, аналитика, проекты

• EPM и CPM — Optimacros · Форсайт · Планета · 1С:Управление холдингом

• BI — Yandex DataLens · 1С:Аналитика · PIX BI · Visiology · Modus BI · Форсайт · Luxms BI

• Трекеры и доски — Яндекс Трекер · Kaiten · Битрикс24 · Аспро.Cloud

• PPM и корпоративное управление проектами — ADVANTA · 1С:УП · Directum Projects

У PIX BI и Visiology реестровые записи проверены напрямую (№ 1182796 и № 305485, проверка — август 2026). Yandex DataLens добавлен как массовый бесплатный вход в BI, его реестровый статус не проверялся. По остальным позициям статус конкретной редакции проверяйте при выборе. По хранилищам данных и слою подготовки честного короткого списка не существует: состав сильно зависит от вашей инфраструктуры и объёмов.

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

Типовые ошибки и чек-лист выбора

Ошибки в этой четвёрке повторяются от класса к классу, поэтому собрал их в один список.

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

2. Автоматизировать процесс, не меняя его. Тот же бюджет быстрее — это оптимизация. Если ждали трансформации, разочарование неизбежно: это разные уровни эффекта и разные деньги.

3. Выбирать по названию, а не по модулям. «У них тоже ERP» — не аргумент: сравнивайте зрелость конкретных модулей под ваши задачи.

4. Тянуть ERP в цех. Оперативное производство — территория производственного контура; попытка закрыть её модулем ERP кончается таблицами у мастеров.

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

6. Внедрять до порядка в справочниках группы. Консолидация вскроет расхождения — чинить их придётся вручную и посреди проекта.

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

8. Мерить успех числом дашбордов. Сто отчётов, на которые никто не смотрит, — декорация. Успех меряется решениями, принятыми на данных.

9. Строить озеро данных без владельца. Складывать туда «всё на будущее» проще всего, достать — невозможно.

10. Строить сценарии на непроверенных допущениях. Инструмент придаёт уверенность цифрам, которые её не заслуживают.

11. Внедрять систему вместо договорённостей. В проектах сначала «как мы их ведём», потом «в чём».

12. Брать корпоративную систему на пять проектов. Тяжёлый процесс на лёгкой задаче гарантирует саботаж. И наоборот: лёгкий трекер не удержит портфель.

13. Делать обязательными десятки полей. Чем строже форма, тем менее честно её заполняют.

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

15. Использовать данные как повод для наказания. Один такой случай — и статусы навсегда станут зелёными.

16. Пропускать валидацию пилота. Без сравнения с базовым уровнем непонятно, что вы вообще купили.

17. Откладывать переход «до последнего». К 2027-му очередь к сильным интеграторам станет главным ограничением — дороже и медленнее для всех, кто ждал.

Чек-лист перед выбором системы

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

2. Согласован словарь ключевых метрик с формулами: подразделения признали одни и те же определения. Это условие для всех четырёх классов сразу.

3. Описана методология: правила консолидации, порядок планирования, договорённости о ведении проектов — кто заказчик, кто принимает результат, как меняется объём.

4. Проведён аудит источников и справочников. Их качество определит проект сильнее, чем выбор платформы, — я бы начинал с них.

5. Зафиксирована базовая линия до пилота: срок сбора бюджета, текущая ошибка прогноза, доля проектов с актуальным статусом, время на подготовку отчётности. Иначе эффект нечем доказать.

6. Короткий лист из трёх систем под ваш профиль, по каждой — референс в вашей отрасли и масштабе. Не презентация, а работающее внедрение.

7. Пилот идёт на одном контуре или одном бюджетном цикле с измеримым критерием — и с назначенной заранее точкой «идём дальше или нет».

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

9. Посчитана совокупная стоимость на пять лет: лицензии, внедрение, сопровождение, люди. Не цена контракта.

10. Назначены владельцы поимённо: у данных, у каждой витрины, у каждого ИИ-сценария. Иначе через год никто не скажет, каким цифрам верить.

11. Есть договорённость об использовании данных: они для управления, а не для разбора полётов. Я бы проговорил это до запуска — после первого наказания по данным честность в системе не восстанавливается.

Что дальше

Общая карта классов — в статье Типы основных ИТ-систем. Другие разборы цикла: Производство, активы и склад · Клиенты и продажи · Данные и документы · Автоматизация рутины и ИИ · Люди и ИТ-функция.

Разобраться глубже помогут книги Джимшера Челидзе «Цифровая трансформация для директоров и собственников» и «Искусственный интеллект. С неба на землю» — третья редакция, скачать бесплатно. Если у вас останутся вопросы, можете обратиться к нам за обучением или консультациями.