Оптимизация бизнес-процессов: методы, этапы и разбор типового примера

Оптимизация бизнес-процессов — целенаправленное изменение того, как выполняется работа, ради измеримого улучшения результата: срока, стоимости, качества или предсказуемости. IBM в материале о process optimization (март 2025) определяет её как улучшение процессов структурными методами и технологиями — технологии стоят в перечне после методов, а не вместо них.

Проблема начинается там, где вместо изменения процесса компания ускоряет его отдельные операции: сотрудники быстрее заполняют те же формы, согласующим приходят напоминания — а срок исполнения не меняется, потому что основную часть календарного времени процесс проводит не в работе, а в ожидании между шагами. Второй частый сценарий: улучшили участок, который не был ограничением, и получили красивую локальную метрику при нуле на выходе. McKinsey в статье «From lean to lasting» (ноябрь 2008) отмечает, что организации упускают до половины потенциальной экономии при внедрении программ улучшений в духе lean и Six Sigma — чаще всего из-за слишком узких целей и того, что система управления вокруг процесса остаётся прежней.

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

Что считать оптимизацией, а что — её имитацией

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

В жизненном цикле BPM, который IBM излагает в материале о business process management (сентябрь 2021), пять этапов — проектирование, моделирование, исполнение, мониторинг, оптимизация, — и последний замыкается на первый. Компания, прошедшая цикл однократно, через полтора-два года обнаруживает процесс в прежнем состоянии.

С какого процесса начинать: приоритизация

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

APQC в блоге по результатам исследования Best Practices in Process Improvement 2024 (публикация 11 декабря 2024) приводит две цифры: 33% организаций приоритизируют улучшения стратегически «значительную часть времени или чаще»; основные критерии отбора — связь со стратегическими целями и влияние на клиента, затем потенциальный ROI. Там же зафиксирована ловушка: усилия уходят не на самые ценные проблемы, а на самые «громкие». Это согласуется с более ранним наблюдением APQC (февраль 2024): лишь около четверти организаций связывают процессную работу с корпоративной стратегией.

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

Первые две оси перемножаются, третья отсекает. Отдельно оценивается состояние НСИ: при разъезжающихся справочниках расчётный эффект придётся сначала обеспечить данными, и это удлиняет проект на квартал-другой. McKinsey (март 2017) рекомендует организовывать улучшения вокруг сквозных процессов и отмечает, что концентрация примерно на 15–20 ключевых процессах раскрывает основную часть ценности; для средней компании перечень короче — 6–10 процессов покрывают основной объём проблем.

Методы оптимизации и границы их применимости

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

Устранение потерь

Классификация Тайити Оно, которую приводит Lean Enterprise Institute, включает семь видов потерь: перепроизводство, ожидание, лишняя транспортировка, излишняя обработка, избыточные запасы, лишние движения, исправления и брак. Перепроизводство LEI называет худшей формой, поскольку оно порождает остальные шесть; позже добавили восьмой вид — неиспользованный потенциал сотрудников. LEI разделяет работу на создающую ценность, сопутствующую и потери: сопутствующую не убирают, а сокращают, меняя условия. В административных процессах основную долю занимают ожидание и исправления — заявка, которая обрабатывается 40 минут суммарно, проходит по компании за девять дней.

Применим: повторяющиеся процессы с достаточным объёмом операций.

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

Расшивка узкого места

Теория ограничений Элияху Голдратта («Цель», 1984) сводит улучшение потока к пяти шагам: найти ограничение, максимально использовать его мощность, подчинить ему работу остальных участков, расширить ограничение, повторить цикл. Производительность системы равна производительности ограничения — улучшение любого другого участка выход не меняет.

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

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

Сокращение числа передач и согласований

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

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

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

Параллелизация

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

Применим: между шагами нет жёсткой зависимости по данным, результат раннего шага меняется редко.

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

Перенос контроля в точку возникновения данных

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

Применим: ошибки обнаруживаются позже возникновения и приводят к переделке или недостоверной отчётности.

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

Стандартизация

Один способ выполнения там, где вариативность не создаёт ценности. IBM в материале о process mining (октябрь 2021) описывает стандартизацию как выявление отклонений от эталонной модели и приведение вариантов к ней; там же указано ограничение — процессная аналитика не видит операций, выполняемых вне информационных систем.

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

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

Автоматизация

Перенос исполнения и контроля в информационную систему. Метод стоит последним потому, что фиксирует сложившуюся логику: автоматизированный лишний шаг становится обязательным лишним шагом с утверждённым маршрутом. Косвенное подтверждение приоритета процессных изменений над техническими есть у McKinsey: в кейсе глобальной химической компании (статья 2008 года) около 60% созданной пилотом ценности пришлось на новые рабочие процессы, а не на более эффективное оборудование.

Применим: правила стабильны и согласованы; НСИ достоверна; объём операций окупает стоимость владения.

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

Сводная таблица методов

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

Этапы работ: от выбора процесса до закрепления

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

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

3. Построение AS IS. Схема строится по фактам, а не по действующему регламенту, до уровня операции, у которой есть исполнитель, вход, результат и длительность. На схеме сразу отмечают длительность каждого шага и время ожидания между шагами — соотношение этих величин и определяет, куда направить усилия.

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

5. Проектирование TO BE. Целевая модель — не «AS IS без недостатков», а ответ на вопрос, как процесс должен работать исходя из задачи первого этапа. Проверяется реалистичность: хватит ли квалификации, нужна ли новая роль, готова ли компания изменить распределение ответственности. Результат — схема TO BE, матрица ответственности, перечень организационных изменений и список того, что реализуемо только в системе.

6. Пилот. Изменение проверяется на ограниченном контуре: одна площадка, одно подразделение, одна категория заказов. McKinsey в статье 2008 года рекомендует вместо множества слабо связанных инициатив полностью преобразовать одну-две операционные зоны со 100–200 сотрудниками, создав тиражируемый образец. Пилот имеет смысл только с заранее сформулированными критериями успеха, и брать для него самый удобный участок не стоит: результат окажется невоспроизводимым.

7. Тиражирование. Распространение отработанной модели на остальные площадки; здесь выясняется, какие элементы решения были специфичны для пилотной зоны. Тиражировать до стабилизации пилота — частая ошибка.

8. Закрепление. Регламент, обучение работе по новому процессу (а не интерфейсу), перевод KPI подразделений на данные нового процесса, отключение параллельных контуров учёта, назначение владельца, регулярный мониторинг. APQC по итогам исследования 2024 года указывает, что устойчивость улучшений чаще всего обеспечивают стандартами описания процессов, вовлечением участников и дашбордами.

Типовой пример: планирование полевых работ и обеспечение ТМЦ

Рассмотрим типовую ситуацию для растениеводческого хозяйства площадью 30–45 тыс. га с несколькими производственными участками. Ситуация собирательная и приведена как иллюстрация метода, а не как описание конкретного проекта.

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

AS IS. Агрономы участков формируют технологические карты в электронных таблицах в декабре — январе, каждый в своём формате. Агрономическая служба сводит потребность вручную, уточняя расхождения по телефону; сводная потребность готова к концу января, снабжение запускает закупку в феврале — марте. В сезоне агроном меняет препарат или состав операций по обстановке, согласуя устно; карта не переоформляется. Склад отпускает ТМЦ по устной заявке бригадира, накладные оформляются в конце декады общим списком.

Диагностика. От утверждения структуры посевных площадей до размещения первой закупки проходит 8–10 недель, из которых около шести — ручная консолидация и уточнения: ожидание и излишняя обработка. Страховой запас формируется на уровне каждого участка независимо, отсюда неликвиды. Списание задним числом даёт расхождения с фактом и исправления при инвентаризации. Узкое место потока — агрономическая служба из двух-трёх человек, через которую проходит и консолидация в межсезонье, и оперативные решения в сезон. Одно и то же средство защиты растений заведено в номенклатуре в трёх вариантах, справочники технологических операций различаются по участкам — проблема НСИ. Изменение карты в сезоне не проходит ни через одну точку фиксации, поэтому расхождение плана и факта объяснить невозможно.

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

Изменение процесса без информационной системы. Технологическая карта переопределяется как обязательство, а не рабочий файл агронома: её изменение оформляется новой версией с указанием причины и утверждается главным агрономом до выполнения работы. Закупка позиций с длинным сроком поставки и стабильной потребностью (основные удобрения, часть семян) отделяется от позиций, зависящих от фитосанитарной обстановки, и запускается по укрупнённой потребности сразу после утверждения севооборота. Страховой запас централизуется на одном складе, отпуск ТМЦ оформляется в момент выдачи с указанием поля и операции, вводится единый классификатор операций и номенклатуры с одним ответственным. Часть эффекта появляется уже здесь и не требует бюджета на IT.

Что требует автоматизации. Единая база технологических карт с версионностью; расчёт потребности в ТМЦ по площади, культуре и нормам с учётом остатков и сроков поставки; формирование плана закупок из рассчитанной потребности; оформление отпуска материалов в поле, в том числе без постоянной связи; учёт наработки техники и расхода ГСМ; расчёт затрат на гектар в разрезе поля, культуры и операции в течение сезона.

Проблема AS IS	Метод	Требование к системе
8–10 недель до размещения закупки	Параллелизация	Расчёт укрупнённой потребности после утверждения севооборота
Неликвиды СЗР на участках	Устранение потерь	Единый остаток, контроль сроков годности
Расхождения при инвентаризации	Перенос контроля	Первичный документ в поле с привязкой к полю и операции
План и факт несопоставимы	Стандартизация	Хранение версий карт, план-факт по операциям
Перегрузка агрономической службы	Расшивка узкого места	Единый справочник операций и норм, ввод данных на местах
Себестоимость гектара к декабрю	Автоматизация	Расчёт затрат в разрезе поля, культуры, операции

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

От процесса к системе: где появляется 1С

Требования к системе — производная от процесса. Цепочка выглядит так: бизнес-требование («срок размещения закупки не более 20 дней при сохранении бюджетной цены») → процесс TO BE (кто, что и в какой последовательности делает) → функциональное требование («расчёт потребности в ТМЦ по утверждённой структуре посевных площадей с учётом остатков и сроков поставки; ответственный — агрономическая служба») → выбор системы.

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

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

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

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

Локальная оптимизация без сквозного эффекта. Участок улучшен, его показатель вырос, срок исполнения обязательства перед клиентом не изменился. Изменение оценивается по показателю сквозного процесса, а не шага.

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

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

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

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

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

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

Группа	Показатель	Как считать	Когда проявляется эффект
Срок	Длительность цикла процесса	Календарные дни от входного события до результата, медиана и 90-й перцентиль	2–4 месяца после изменения процесса
Срок	Доля времени, добавляющего ценность	Сумма длительностей операций / общая длительность цикла	Сразу после перепроектирования
Структура	Число передач и согласований в маршруте	Количество переходов ответственности, среднее по выборке	Сразу после перепроектирования
Качество	Доля возвратов и переделок	Документы с повторным прохождением шага / все документы	2–4 месяца
Данные	Достоверность остатков	Расхождение учёта и инвентаризации, % позиций и % суммы	3–6 месяцев после наведения порядка в НСИ
Данные	Срок получения фактической себестоимости	Рабочие дни от закрытия периода до утверждённого расчёта	2–3 периода
Устойчивость	Доля операций вне утверждённого процесса	Оценка по журналам систем и подразделениям	3–6 месяцев

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

McKinsey (март 2017) описывает пять рычагов улучшения операций — цифровизация, продвинутая аналитика, интеллектуальная автоматизация, аутсорсинг и перепроектирование в логике lean — и подчёркивает, что в правильной последовательности они дают мультипликативный эффект; в приведённом там кейсе североамериканского страховщика сочетание этих рычагов дало рост эффективности на 40%.

Вывод

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

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

FAQ

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

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

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

Что делать, если сотрудники сопротивляются изменениям?
Разбираться, кому именно и чем стало хуже. Сопротивление почти всегда конкретно: выросла нагрузка, изменился показатель оценки или новый порядок мешает делать то, за что человек отвечает. По данным APQC (декабрь 2024), самый часто применяемый способ удержать вовлечённость — участие сотрудников в разработке решения, его назвали 60% респондентов.

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

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

---

Что дальше

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