Почему автоматизацию бизнес-процессов нужно начинать с процессов, а не с выбора IT-системы

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

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

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

Что показывает статистика по проектам трансформации

Оценки успешности изменений стоит читать аккуратно: в открытых источниках много цифр без указания методики. Из проверяемых данных полезны результаты McKinsey Global Survey по цифровым трансформациям, опубликованные в октябре 2018 года. Опрос проводился в январе 2018 года, в нём участвовали 1793 респондента, из которых 1521 человек участвовал минимум в одной цифровой трансформации за предыдущие пять лет.

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

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

Второй ориентир — данные APQC, некоммерческой организации, специализирующейся на бенчмаркинге процессов. В материале февраля 2024 года о стратегии процессного управления APQC приводит наблюдение: лишь около четверти организаций связывают работу по управлению процессами с корпоративной стратегией. Остальные занимаются процессами точечно, без ответа на вопрос «зачем», — и затем не могут объяснить руководству, какую ценность создала эта работа.

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

Почему информационная система не исправляет процесс

Управление бизнес-процессами (BPM) по определению Gartner, которое приводит IBM, включает методы обнаружения, моделирования, анализа, измерения, улучшения и оптимизации бизнес-стратегии и процессов. Обратите внимание на порядок: обнаружение и анализ идут до улучшения, а улучшение — до автоматизации. Жизненный цикл BPM в изложении IBM состоит из пяти этапов: проектирование процесса, моделирование, исполнение, мониторинг, оптимизация. Инструмент появляется на третьем этапе, когда уже понятно, что именно исполняется.

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

Дальше срабатывают четыре механизма.

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

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

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

Сопротивление возникает там, где сотруднику стало хуже. Люди не саботируют систему абстрактно. Кладовщик ведёт параллельную тетрадь, потому что в системе остатки расходятся с фактом. Мастер держит свой файл графика, потому что план из системы приходит с задержкой и не учитывает переналадки. Финансист сводит отчёт в Excel, потому что аналитика в системе не соответствует управленческой структуре. Каждый параллельный контур — симптом того, что процесс TO BE не был спроектирован и согласован до настройки.

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

Четыре уровня причин: где на самом деле находится проблема

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

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

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

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

Последовательность работ: от бизнес-задачи до запуска

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

Шаг 1. Сформулировать бизнес-задачу и границы

Проект начинается не с формулировки «нам нужна ERP», а с измеримой задачи: сократить срок исполнения заказа с 45 до 30 дней, снизить долю просроченных отгрузок с 18% до 5%, получить достоверную себестоимость по заказу к пятому рабочему дню, высвободить оборотные средства за счёт снижения неликвидных запасов.

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

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

Шаг 2. Описать AS IS по фактам, а не по представлениям

Описание «как есть» имеет смысл, только если оно отражает реальную работу, а не утверждённый несколько лет назад регламент. Что нужно собрать:

Данные из учётных систем: даты создания, согласования, изменения и закрытия документов; количество корректировок; фактические длительности этапов; частота ручных операций. Даже без специализированных инструментов process mining выгрузка журналов регистрации 1С даёт объективную картину задержек и переделок.

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

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

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

Уровень детализации: до операции, у которой есть исполнитель, входной документ, результат и длительность. Более мелкая детализация на этом этапе только увеличивает объём работы.

Шаг 3. Диагностика: найти потери и их причины

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

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

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

Шаг 4. Спроектировать целевую модель TO BE

Проектирование TO BE — это не «AS IS без недостатков». Это ответ на вопрос, как процесс должен работать, если исходить из бизнес-задачи шага 1.

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

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

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

Шаг 5. Разделить изменения на организационные, регламентные и системные

Из всего списка изменений выделяются три группы:

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

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

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

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

Шаг 6. Сформулировать функциональные требования из процесса

Требования пишутся не в формате «нужен модуль планирования», а в формате «в процессе TO BE на шаге N необходимо: получить перечень дефицитных позиций по заказу с учётом резервов и незавершённого производства; ответственный — снабженец; периодичность — ежедневно; источник данных — спецификация и остатки».

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

Шаг 7. Цифровизация, запуск и сопровождение изменений

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

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

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

Типовая ситуация: сквозной процесс «заказ — отгрузка»

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

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

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

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

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

TO BE. Срок клиенту подтверждается только после предварительной проверки: есть ли аналогичная спецификация в базе, каков объём технологической проработки, какова загрузка ключевых участков в требуемом периоде. Технологическая подготовка выделяется в отдельный управляемый этап с приоритизацией по стоимости и сроку заказа. Расчёт потребности в материалах выполняется сразу после утверждения спецификации, до постановки заказа в производственный план, с учётом остатков, резервов и сроков поставки. Планирование ведётся в два уровня: межцеховой план по этапам и внутрицеховое исполнение. Отклонения фиксируются в момент возникновения, а не при закрытии месяца.

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

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

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

Что меняется без IT, а что — только в системе

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

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

Когда допустимо начинать с системы

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

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

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

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

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

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

Чек-лист готовности к автоматизации

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

1. Сформулирована измеримая бизнес-задача, а не «внедрить систему».
2. Определены границы сквозного процесса и события входа-выхода.
3. Назначен владелец процесса со стороны бизнеса, обладающий полномочиями менять правила.
4. Есть описание AS IS, построенное на данных и наблюдении, а не на действующем регламенте.
5. Потери оценены количественно — в днях, штуках или деньгах.
6. Проблемы разнесены по четырём уровням: архитектура, ответственность, НСИ, исполнение.
7. Спроектирована целевая модель TO BE, согласованная всеми участвующими подразделениями.
8. Определено, какие изменения выполняются организационно и когда.
9. Оценено состояние НСИ: спецификации, нормы, маршруты, справочники контрагентов и номенклатуры.
10. Функциональные требования сформулированы от процесса, а не от названия модуля.
11. Зафиксированы базовые значения KPI до начала изменений.
12. Определено, кто отвечает за отключение параллельных контуров учёта после запуска.

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

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

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

Проект без владельца со стороны бизнеса. Если проект ведёт IT-директор, а функциональные заказчики участвуют факультативно, требования будут формироваться по принципу «повторить как сейчас, но в системе». Возражения появятся на этапе опытной эксплуатации, когда изменения стоят дороже.

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

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

Игнорирование НСИ. Проект расписан по этапам, но подготовка справочников, спецификаций и нормативов не выделена в отдельный блок с ответственным и сроком. Это самая частая причина смещения сроков запуска.

Отсутствие базовых замеров. Если не зафиксировать показатели «до», после запуска невозможно доказать эффект. Через год дискуссия сведётся к субъективным оценкам.

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

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

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

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

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

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

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

Вывод

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

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

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

FAQ

Сколько времени занимает диагностика процессов перед автоматизацией?
Для одного сквозного процесса на среднем предприятии — обычно от трёх до шести недель: сбор данных и наблюдение, построение AS IS, рабочие сессии по диагностике, проектирование TO BE. Комплексное обследование производственной компании со всеми основными процессами занимает два-три месяца. Это существенно меньше типичного срока внедрения ERP и меньше срока, который теряется при переделке неверно настроенного контура.

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

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

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

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

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

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

---

Что дальше

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