Почему трансформация компании не даёт результата: системные ошибки изменения операционной модели

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

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

Признаки того, что трансформация буксует

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

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

Сроки сдвигаются без пересмотра содержания. План переносится на квартал, потом ещё на квартал, объём работ и целевые показатели прежние: значит, план не был основан на оценке трудоёмкости.

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

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

Ключевые люди выходят из программы. Уходит руководитель направления, затем методолог, потом заказчики начинают присылать на встречи заместителей — раньше, чем ухудшаются формальные показатели. Bain (апрель 2024 года, опрос более 400 руководителей) называет сильнейшим предиктором успеха способность удерживать и развивать нужных людей: среди успешных две трети обеспечивали участникам не менее половины рабочего времени.

Что показывают исследования

McKinsey Global Survey «Unlocking success in digital transformations» (октябрь 2018 года; опрос 16–26 января 2018 года, 1793 респондента, из них 1521 участвовал минимум в одной цифровой трансформации за предыдущие пять лет): только 16% сообщили, что трансформация улучшила показатели и закрепила улучшения, ещё 7% — что эффект был, но не удержался; в нефтегазовой, автомобильной, инфраструктурной и фармацевтической отраслях — 4–11%. При этом 68% назвали основной целью именно цифровизацию операционной модели.

BCG («Flipping the Odds of Digital Transformation Success», 2020 год; данные по 70 компаниям и опрос 825 руководителей) отнесла к успешным 30% трансформаций, Bain (апрель 2024 года) оценивает долю достигших исходных амбиций примерно в 12%.

Исследование McKinsey по редизайну операционных моделей (июнь 2025 года; опрос 2000 руководителей в 16 отраслях и шести регионах, 13–27 февраля 2025 года) показывает улучшение: 63% редизайнов достигли большинства целей против 21% десятью годами ранее, но высокоуспешными признаны 24%. По наблюдению APQC (февраль 2024 года), около четверти организаций связывают процессное управление с корпоративной стратегией; остальные не могут подтвердить его ценность, потому что не с чем сопоставлять. Неудача трансформации — статистически нормальный исход, и её причины лежат в управленческой конструкции, а не в качестве исполнения отдельных задач.

Системные причины: пять групп

Группа 1. Цели не переведены в экономику

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

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

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

Группа 2. Изменения не дошли до конструкции управления

Полномочия не перераспределены. Проверяется вопросом: назовите три решения, которые раньше принимались на уровне N, а теперь — на уровне N–1. Типичная картина: кросс-функциональная команда отвечает за сквозной результат и не может ни изменить приоритет в производственном плане, ни утвердить изменение регламента, ни распорядиться бюджетом. McKinsey приводит пример банка со сквозными подразделениями: дизайн выглядел отлично, но каждая команда оказалась переводом старой структуры, и довести что-либо до клиента по-прежнему занимало месяцы.

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

Группа 3. Программа живёт параллельно основной деятельности

Отдельный контур управления. У программы свой комитет, ритм и показатели, у компании — бюджетный цикл, план продаж, производственная программа. Контуры не пересекаются, и в конфликте приоритетов побеждает основная деятельность; симптом — решения программы не влияют на бюджетный процесс. Лечение McKinsey описывает как единый цикл управления: квартальный обзор бизнеса, спроектированный совместно финансами, стратегией и проектным офисом, вместо обзора «сбоку».

Ключевые люди в режиме совмещения. Формально 20% времени, фактически вечера и остатки. McKinsey оценивает необходимое участие в четыре часа в неделю от каждого члена топ-команды в основной фазе (обычно 6–12 месяцев), а по её исследованию agile-трансформаций 2021 года готовность менее чем за 18 месяцев давала в 1,6 раза более высокую вероятность успеха.

Группа 4. Улучшения заперты в функциональных колодцах

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

Группа 5. Нет процессной и информационной основы

Система проектируется под текущую практику. Аналитик спрашивает заказчиков, кто создаёт документ и кто согласует; ответы берутся из текущей практики, потому что другой описанной не существует. Система получает на вход процесс AS IS и закрепляет его вместе с лишними согласованиями и разрывами ответственности.

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

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

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

Нет базовых замеров — эффект недоказуем. Без зафиксированных значений «до» спор об эффекте становится спором мнений, и программы, которые действительно что-то улучшили, закрываются как неуспешные просто потому, что улучшение нечем предъявить.

Симптом, причина, проверка, действие

Симптом	Вероятная системная причина	Что проверить	Первое действие
Пилот дал результат, тираж не идёт	Результат держался на ручном режиме и усиленном ресурсе	Часы сверх штатной нагрузки; решения вне регламента	Закрепить условия воспроизводимости либо признать пилот нерепрезентативным
Эффект заявлен, в P&L его нет	Нет владельца эффекта в бюджете, экономия не изъята	Строка бюджета, изменившаяся из-за инициативы	Назначить владельца эффекта из руководителей с бюджетом
Пользователи вернулись к таблицам	Обучение интерфейсу, процесс не изменён, параллельный учёт не отключён	Доля операций вне системы; отчёты, собираемые вручную	Разобрать причину: интерфейс, данные или логика процесса
Функции улучшают показатели, сквозные не меняются	Локальные улучшения в колодцах, потери на передачах	Длительность сквозного процесса и время ожиданий на стыках	Перевести отчётность на сквозные метрики; назначить владельца процесса
Данные не совпадают с фактом	НСИ не в порядке, нет владельца справочников	Расхождение учёта и инвентаризации; дубли	Выделить НСИ в блок с ответственным и сроком
Сроки сдвигаются, содержание неизменно	План не основан на трудоёмкости	Загрузка ключевых ролей; инициатив на методолога	Считать срок от ресурса; сокращать объём, а не переносить дату
Спор об эффекте не имеет разрешения	Нет базовых замеров	Зафиксированы ли значения до начала изменений	Восстановить базу по данным учётной системы

Почему в неудаче обвиняют систему

Объяснение неудачи сначала ищут в технологическом слое: не тот подрядчик, не та платформа, не хватило доработок. Технологический слой при этом редко бывает первопричиной. Если у сквозного процесса нет владельца, никакая система его не создаст.

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

Диагностика застопорившейся программы

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

Разумный срок для крупной компании — от четырёх до восьми недель.

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

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

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

Бумажный и подтверждённый эффект

Параметр	Бумажный эффект	Подтверждённый эффект
Источник цифры	Расчёт команды инициативы	Расчёт согласован финансовой службой по утверждённой методике
База сравнения	Оценка «как было бы без проекта»	Зафиксированные значения показателя до начала изменений
Единица измерения	Высвобожденные часы, сокращённые шаги	Изменение бюджета, численности, себестоимости
Отражение в управлении	Отсутствует	Бюджет подразделения на следующий период уменьшен на сумму эффекта

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

Типовой пример: машиностроительный холдинг

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

Исходное положение. Три производственные площадки, позаказное и мелкосерийное производство, управляющая компания. Восемнадцать месяцев назад запущена программа с двумя контурами — организационным (сквозные процессы, новая система показателей, централизация закупок и НСИ) и системным (внедрение 1С:ERP взамен разрозненного ландшафта). Отчётность показывает 71% выполнения; при этом запасы выросли на 6% за год, срок исполнения заказа не изменился, а финансовый директор не подтверждает ни рубля из заявленных 340 миллионов эффекта.

Что показала диагностика. В официальном перечне 22 инициативы, фактически ведётся 41 — девятнадцать запущены внутри функций без включения в программу. Эффект в деньгах посчитан у 14, подтверждён финансовой службой у одной; пять человек закрывают 26 ролей при полной основной нагрузке. Из 340 миллионов заявленного эффекта 210 приходятся на высвобожденное время, которое никто не изымал: ни одна штатная единица не сокращена, ни от одного найма не отказались. Ещё 80 миллионов — снижение закупочных цен, оказавшееся следствием изменения структуры номенклатуры; оставшиеся 50 посчитаны корректно, но реализуются после дважды перенесённого тиража на третью площадку.

Владельцы четырёх сквозных процессов назначены, но ни один не может изменить приоритет в производственном плане или распорядиться бюджетом, а все KPI, влияющие на премию, остались функциональными. В номенклатурном справочнике около 14% дублей, спецификации переносятся из конструкторских файлов вручную, ответственного за НСИ нет — а производственный контур считает потребность именно по этим данным. Доля операций, выполняемых параллельно в таблицах, — 35–40%, и основная причина не интерфейс, а недоверие к данным. Претензии к подрядчику звучали чаще всего, но из 63 спорных требований 11 относятся к качеству реализации, 29 — к требованиям, воспроизводящим текущую практику, 23 — к данным.

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

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

План восстановления

Первые три шага занимают недели и не требуют бюджета.

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

Шаг 2. Назначить владельцев эффекта. По каждой оставшейся инициативе — руководитель, у которого изменится бюджет, численность или показатель; отсутствие кандидата на эту роль — сигнал, что инициатива не нужна.

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

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

Шаг 5. Восстановить базу замеров. Если базовые значения не фиксировались, их восстанавливают по историческим данным учётных систем за сопоставимый период; одновременно фиксируются внешние факторы, чтобы не приписать программе то, что вызвано рынком.

Шаг 6. Пересмотреть целевую модель там, где она нереализуема. Части модели, которые за полтора года не сдвинулись, требуют не удвоения усилий, а пересмотра. Типичные кандидаты: централизация функций, для которых нет ни компетенций, ни данных; единые справочники для площадок с разной номенклатурой; сквозные роли без полномочий; процессы, требующие идеальной дисциплины от всех.

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

KPI восстановления

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

Показатель	Как считать	Ориентир через два квартала
Число активных инициатив	Все ведущиеся работы, включая незарегистрированные	Сокращение в 2–4 раза
Доля инициатив с владельцем эффекта	С назначенным владельцем бюджета / все активные	100%
Доля подтверждённого эффекта	Признанный финансовой службой / заявленный	Рост до 60% и выше
Эффект в бюджетах	Сумма, включённая в плановые бюджеты подразделений	Не менее половины подтверждённого
Доля сквозных KPI в премии руководителей	Вес в переменной части	30–50%

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

Каждый ответ «нет» указывает на зону, которую нужно восстанавливать.

1. Есть полный перечень ведущихся инициатив, включая запущенные внутри функций.
2. По каждой посчитан эффект в деньгах с описанной методикой расчёта.
3. По каждой инициативе с эффектом назначен владелец, у которого меняется бюджет или показатель.
4. Эффект признан финансовой службой и отражён в плановых бюджетах подразделений.
5. Зафиксированы базовые значения показателей до начала изменений.
6. Исключено влияние внешних факторов и двойной счёт эффекта между инициативами.
7. Известна фактическая, а не формальная загрузка ключевых участников.
8. Владельцы сквозных процессов имеют право принимать решения, а не только координировать.
9. Есть показатель уровня компании, за который несколько руководителей отвечают совместно.
10. Работа с НСИ выделена в блок с ответственным, сроком и бюджетом.

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

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

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

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

Диагностика силами команды программы. Люди, отвечающие за результат, не могут дать беспристрастную оценку: они внутри собственных допущений.

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

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

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

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

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

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

Вывод

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

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

FAQ

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

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

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

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

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

---

Что дальше

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