Целевая модель бизнеса: как спроектировать компанию до начала цифровизации

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

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

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

Что такое целевая модель и чем она не является

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

Стратегия отвечает на вопросы «что продаём, кому и за счёт чего выигрываем»; модель — на вопрос «как компания должна быть устроена, чтобы это исполнить». К оргструктуре она не сводится: по данным McKinsey Quarterly (июнь 2025 года, опрос 757 руководителей крупных компаний), высокие показатели встречаются при любой из шести распространённых конфигураций структуры. Результат определяет не расстановка блоков на схеме, а согласованность элементов между собой.

Целевое состояние отдельного процесса, TO BE, производно от модели предприятия: пока не решено, централизованы ли закупки и кто отвечает за оборотный капитал, целевой процесс закупки спроектировать невозможно.

Элементы целевой модели: восемь групп решений

В подходе McKinsey «Organize to Value» (2025) элементов двенадцать — от назначения и повестки создания ценности до вознаграждения и талантов. Для российской производственной компании удобнее перечень из восьми групп решений, каждая с прямым продолжением в учёте и в системе.

Элемент модели	Какое решение принимается	Признак, что решение не принято
Ценностное предложение и сегменты	За что клиент платит премию, какие продуктовые группы приоритетны	Ассортимент расширяется по запросу продаж; убыточные позиции не выявляются
Состав и границы сквозных процессов	Какие процессы сквозные, где вход и выход каждого, что основное, что обеспечивающее	Процессы описаны по подразделениям; на стыках нет ни владельца, ни срока
Оргструктура и центры ответственности	Как нарезаны бизнес-единицы, что относится к ЦФО, где граница между УК и площадкой	Финансовая структура совпадает с юридической; ЦФО не различаются по типу
Полномочия и правила решений	Кто принимает решение и кто согласует; лимиты по суммам; что эскалируется	Решения стекаются к первому лицу; согласования множатся без содержания
Модель данных и НСИ	Единые справочники и их владельцы, правила ведения, обязательные аналитические разрезы	Один и тот же материал ведётся под разными кодами на разных площадках
Система показателей	Какие показатели целевые, как каскадируются на бизнес-единицы, как связаны с вознаграждением	KPI существуют отдельно от бюджета и управленческой отчётности
ИТ-архитектура	Какие контуры автоматизируются, где единая база, что является источником истины по объекту	Архитектура сложилась из последовательности отдельных внедрений
Компетенции и роли	Какие роли нужны в целевом состоянии, каких компетенций не хватает	Новая функция появляется как поручение сотруднику «в дополнение»

Смысл таблицы не в перечне, а в связях. Централизация закупок меняет схему ЦФО и полномочия (директор площадки теряет право выбора поставщика, но получает право эскалации по срокам), делает справочник номенклатуры единым, добавляет площадке показатель обеспеченности, а закупкам — цены и своевременности, и перестраивает маршруты согласования и права доступа. Пропуск любого из следствий превращает централизацию в декларацию.

Откуда берутся требования к модели

На уровне модели предприятия отраслевые «лучшие практики» почти не переносятся: модель обслуживает экономику конкретной компании.

Экономика продуктов и сегментов. Где компания зарабатывает — не по валовой марже в отчётности, а с распределением косвенных затрат и стоимости оборотного капитала. Направление с маржой 8% и направление с маржой 27% не обслуживаются одинаковой моделью: первому нужны стабильность и контроль себестоимости, второму — скорость технологической проработки и гибкость согласований.

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

Ограничения и планы собственника. Сезонность в АПК, длительный цикл конструкторской подготовки, зависимость от якорного заказчика, лимиты по энергомощностям. Отдельно — горизонт три — пять лет: компании, готовящейся к покупке активов, имеет смысл заранее строить тиражируемое ядро (единая методология учёта, единая НСИ, типовой набор процессов площадки), даже если сегодня площадка одна.

Опрос McKinsey (13–27 февраля 2025 года, 2000 руководителей из 16 отраслей и шести регионов) зафиксировал главные мотивы перепроектирования: эффективность и переориентация на рост, следом — исполнимость стратегии и скорость решений. Там же: две трети респондентов проходили перестройку операционной модели за предшествующие два года.

Последовательность проектирования: семь этапов

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

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

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

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

5. Детализация по элементам. Реестр сквозных процессов с владельцами и границами, финансовая структура с типами ЦФО, матрица полномочий с лимитами, справочники с владельцами и регламентом ведения, методология учёта затрат, дерево показателей, целевая архитектура с системой-источником по каждому объекту данных.

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

7. Дорожная карта. Разумная последовательность для производственного холдинга: методология и НСИ (без них не считается ничего) → разграничение полномочий и запуск централизуемых функций → перевод сквозных процессов на целевую логику → автоматизация → перевод мотивации на новые показатели. По данным McKinsey (2021), компании, укладывавшие основную часть изменений в 18 месяцев, в 1,6 раза чаще сообщали об успехе.

Развилки, которые придётся пройти

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

Централизация или децентрализация функций

Функция	Когда централизовать	Что оставить на площадке	Чем платите за централизацию
Закупки	Совпадающая номенклатура на нескольких площадках, значимый объём	Уникальные позиции, срочные закупки в пределах лимита, локальные услуги	Скорость реакции, разрыв между закупщиком и производством
НСИ и справочники	Всегда при двух и более площадках или при консолидации отчётности	Подача заявок на новые позиции, но не создание записей	Узкое место в согласовании; нужен регламент со сроками
Финансы и учёт	Потребность в сопоставимой себестоимости и единой учётной политике	Первичный учёт, кассовые операции	Удаление финансиста от производственного контекста
Планирование производства	Общий портфель заказов, взаимозаменяемые мощности	Внутрицеховое исполнение и диспетчеризация	Потеря оперативности, если не разделены горизонты планирования
ИТ	Практически всегда: единая архитектура и правила разработки	Локальная поддержка пользователей и специфичное оборудование	Очередь на доработки, отдалённость от площадки

Ориентир из отраслевых данных: по результатам Deloitte Global Shared Services and Outsourcing Survey (май 2021 года, более 600 респондентов из 500 организаций) в общих центрах обслуживания чаще всего оказываются финансы (94% участников), персонал (57%), закупки (54%) и ИТ (52%). Централизуют то, что легче стандартизировать и где эффект от единых правил выше потерь в скорости.

Сам выбор не бинарен: центр может задавать методологию, оставляя исполнение на местах; вести категорию А, отдав площадке В и С; выполнять операцию, оставляя площадке утверждение результата. BCG в материале о платформенных операционных моделях (октябрь 2023 года) отмечает ключевое условие: общие платформы устраняют дублирование, но требуют явных договорённостей о том, что платформа обязана давать бизнес-единице.

По функциям или по продуктам и дивизионам

Функциональная нарезка даёт глубину компетенции и экономию на масштабе, но плохо отвечает за сквозной результат: за срок исполнения заказа отвечают одновременно продажи, технологи, снабжение и производство — то есть никто. Дивизиональная даёт понятную ответственность за финансовый результат, но плодит дублирование функций и разнобой в методологии. По данным того же опроса McKinsey (757 руководителей, 2024 год), 89% организаций сохраняют традиционные конфигурации. Выбор конфигурации сам по себе не снимает вопроса о сквозной ответственности.

Кто отвечает за сквозной результат

Три рабочих ответа. Владелец сквозного процесса с полномочиями менять правила на всём маршруте, даже если исполнители подчинены другим. Либо результат закрепляется за руководителем бизнес-единицы, а функции переводятся в сервисный режим с соглашениями об уровне обслуживания. Либо создаётся постоянная кросс-функциональная команда вокруг процесса или продукта — один из четырёх строительных блоков операционной модели нового поколения в описании McKinsey (2017). Ошибочный ответ — назначить ответственного без полномочий и бюджета.

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

Типовой пример: агрохолдинг с тремя площадками

Рассмотрим типовую ситуацию. Пример собирательный и приведён для иллюстрации метода.

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

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

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

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

Централизуются закупочные категории с общей потребностью — удобрения, СЗР, ГСМ, запчасти по унифицированному парку; локально остаются услуги и срочные позиции в пределах лимита. У централизованных категорий появляется категорийный менеджер с показателями по цене и своевременности, у площадки — показатель обеспеченности и право эскалации. Ведение справочников переходит в службу НСИ управляющей компании: площадка подаёт заявку, но не создаёт запись. Вводится единая методология учёта — статьи, объекты калькуляции, общая база распределения косвенных расходов, порядок учёта внутригрупповых операций и трансфертных цен: до этого завод получал сырьё по себестоимости хозяйства, что делало маржу переработки неинформативной.

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

Что стало требованием к системе. Единая база с общим справочником и аналитикой, консолидация отчётности, расчёт себестоимости по единой методике, маршруты согласования с лимитами, права доступа по ролям и площадкам, план-факт по ЦФО. Разговор об архитектуре начинается только здесь.

Как целевая модель превращается в требования к системе

Связь между управленческим решением и настройкой системы прямая. Если решение принято, требование формулируется однозначно; если не принято, аналитик его не додумает — он воспроизведёт текущую практику.

Элемент целевой модели	Принятое решение	Что из этого следует для системы
Финансовая структура	Перечень ЦФО, их типы, соответствие подразделениям и юрлицам	Справочник ЦФО, обязательная аналитика на документах, правила консолидации
Методология учёта затрат	Статьи, объекты калькуляции, базы распределения	Настройка статей и способов распределения, схема калькулирования, операции закрытия
Полномочия и лимиты	Кто принимает решение по каждому типу и в каких границах	Роли и права доступа, маршруты согласования по сумме и категории, контроль лимитов
Сквозной процесс	Границы, шаги, владелец, точки контроля, действия при отклонении	Статусная модель документа, обязательные реквизиты на переходах, уведомления и эскалация
Модель данных и НСИ	Единые справочники, владельцы, правила кодирования	Единая база или правила синхронизации, запрет создания записей вне регламента, контроль дублей
Система показателей	Дерево показателей, формулы, периодичность, ответственные	Источники данных по каждому показателю, регламент расчёта, отчётные формы и панели
Разграничение УК и площадок	Что решает площадка, что согласует центр	Профили доступа по площадкам, разделение прав на создание и утверждение
Модель планирования	Горизонты, уровни, периодичность пересмотра	Виды планов, связь между уровнями, механизм пересчёта при отклонении

Функциональные требования выводятся отсюда почти механически: «заявка сверх лимита X по категории Y направляется финансовому директору группы; при отсутствии решения в течение Z рабочих дней эскалируется; исполнитель видит только заявки своей площадки». Требование в таком виде проверяется на приёмке.

Цепочка «бизнес-требование → процесс → функциональное требование → система» для производственного холдинга приводит к комбинации контуров: оперативный и производственный учёт площадок, консолидация и корпоративные финансы, маршруты согласования, кадровые процессы. На платформе 1С это, соответственно, 1С:ERP, 1С:Управление холдингом, 1С:Документооборот и 1С:ЗУП КОРП. Сама архитектура выводится из решений: при единой методологии и связанности площадок разумна единая база, при автономных площадках — раздельная схема с корпоративным контуром сверху. Обратный порядок приводит к тому, что управленческие решения принимаются исходя из удобства настройки.

Почему целевая модель остаётся на бумаге

Материал McKinsey о трансформациях операционной модели (август 2025 года) разбирает шесть ловушек. Часть узнаваема в российской практике напрямую.

Цели не связаны с изменением модели. «Повысить управляемость» и «стать прозрачнее» не задают ни направления, ни критерия, и проект теряет приоритет перед задачами, за которые руководителей действительно спрашивают. Там же: 63% компаний достигают большей части целей перепроектирования, но лишь 24% относятся к высокоуспешным.

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

Технологии меняются отдельно от организации. Здесь уместен закон Конвея: архитектура систем воспроизводит структуру организации, которая их создаёт. Централизация функции при сохранении раздельных баз и справочников остаётся декларацией.

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

Проект делегирован далеко от первого лица. Перепроектирование затрагивает распределение власти, и такие решения не принимаются на уровне рабочей группы. Ориентир из практики McKinsey — около четырёх часов в неделю от каждого члена управленческой команды на основной фазе (6–12 месяцев).

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

Чек-лист готовности к проектированию

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

1. Посчитана экономика по продуктовым группам и сегментам с распределением косвенных затрат.
2. Определён источник конкурентного преимущества и планы собственника на три — пять лет.
3. Описано фактическое распределение решений: кто что реально принимает и по каким данным.
4. Составлен реестр сквозных процессов с границами и владельцами, а не перечень функций.
5. Финансовая структура описана отдельно от юридической: ЦФО, их типы и ответственность.
6. Утверждены принципы проектирования, по которым разрешаются спорные вопросы.
7. По каждой централизуемой функции определено, что остаётся на площадке.
8. Есть решения по единым справочникам и методологии учёта затрат; зафиксированы базовые значения показателей.

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

Типичные ошибки

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

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

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

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

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

Как оценить результат

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

Группа	Показатель	Как считать	Когда проявляется эффект
Управляемость	Доля решений, принимаемых на установленном уровне	Выборка против матрицы полномочий	3–6 месяцев
Экономика	Сопоставимость себестоимости между площадками	Расчёт по единой методике для сопоставимой продукции	1–2 периода
Отчётность	Срок закрытия периода и выпуска отчётности	Рабочие дни до утверждённой отчётности	2–3 периода
Организация	Доля сквозных процессов с владельцем и измеряемым результатом	Процессы с владельцем и KPI / все выделенные	3–6 месяцев

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

Вывод

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

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

FAQ

Чем целевая модель отличается от целевого состояния процесса TO BE?
Масштабом. TO BE описывает, как должен работать конкретный сквозной процесс: шаги, точки контроля, ответственных. Целевая модель описывает устройство предприятия: какие процессы выделены, как нарезаны бизнес-единицы, где границы полномочий, по каким правилам считается экономика. TO BE выводится из модели.

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

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

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

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

---

Что дальше

Если задача звучит как «навести порядок в группе компаний» или «подготовиться к единой системе», начинать разумно с проектирования модели, а не с выбора конфигурации. ERP Band разбирает текущее устройство управления, помогает принять решения по финансовой структуре, полномочиям, методологии учёта и составу сквозных процессов, а затем переводит их в функциональные требования, из которых вырастает архитектура решения на 1С. Такой порядок позволяет увидеть реальный объём проекта заранее и не закреплять в системе решения, которые компания ещё не приняла.