Когда сопровождение ИС в пищевом производстве тормозит бизнес

Гендир бобдей разбирает, где в пищевом производстве проходит граница между сопровождением ИС и новым проектом, и почему ошибки в изменениях бьют по выручке

ИТ-контур в крупной компании давно перестал быть «службой поддержки», это часть операционной модели. В России затраты на цифровую экономику в 2024 году достигли 6,7 трлн руб., а в 2025 году, по предварительной оценке, выросли до 7,1 трлн. По итогам 2025 года сегмент ПО для управления операционной деятельностью и финансами оценивался в 173,6 млрд руб. 

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

• расходы растут;
• объем изменений растет вместе с ними;
• цена ошибки в управлении изменениями тоже растет.

Доработки — это нормально

Пищевое производство быстрее показывает слабые места сопровождения. Причина в устройстве отрасли. Когда продукт скоропортящийся, предприятие должно удерживать прослеживаемость движения сырья, полуфабрикатов и готовой продукции от входа ингредиентов до выпуска и отгрузки. Когда речь идет о безопасности, процедуры должны быть документированы и поддерживаться. Для части категорий к этому добавляется цифровой контур государственного контроля. В такой среде слабый порядок изменений в системе и данных быстро выходит в операционные сбои: в выпуске, складском учете, документах и отгрузке. ТР ТС 021/2011 закрепляет требование прослеживаемости пищевой продукции и сырья и обязанность изготовителя разрабатывать, внедрять и поддерживать процедуры на принципах ХАССП.

Изменения для пищевого предприятия естественны. Меняется продуктовая матрица, корректируются составы, упаковка, требования к данным, документам, планированию и расчету себестоимости. Давление со стороны рынка и регуляторов делает этот поток постоянным.

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

Формальный change management не спасает

В российских компаниях этот разрыв встречается регулярно. По исследованию, опубликованному ICT.Moscow по материалам «Инфосистем Джет», только 47% компаний имеют актуальную ИТ-стратегию. При этом 49% компаний испытывают недостаток ИТ-ресурсов, а переработки стали нормой для заметной части команд. По исследованию ТеДо, о котором писал ComNews, процессы управления изменениями входят в число наиболее зрелых ИТ-процессов, но рядом сохраняются проблемы с управлением знаниями, ИТ-активами, конфигурациями, актуальностью информации и уровнем автоматизации.

Формального процесса недостаточно. Для бизнеса критично другое:

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

Без этой логики процесс быстро превращается в диспетчеризацию задач.

Когда каждое подразделение приходит в ИТ со своим требованием, предприятие довольно быстро получает:

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

Проблема возникает в среде, в которой принимаются решения об изменениях.

Где проходит граница между сопровождением и новым проектом

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

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

• правила процесса;
• методологию учета;
• роли и ответственность;
• данные;
• связи между смежными функциями;
• архитектуру контура.

Внешний масштаб изменения не дает надежного ориентира. Для руководителя важен другой вопрос: компания все еще развивает систему в режиме сопровождения или уже проводит новый проект под его видом.

Технический долг показывает, успевает ли ИТ за бизнесом

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

Он проявляется в нескольких формах:

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

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

ИТ не должно быть входной точкой любого изменения. До подключения ИТ бизнесу нужно пройти основную часть пути.

После этого ИТ переводит управленческое решение в системную реализацию.

Владелец изменения — это не руководитель ИТ и не аналитик 1С. ИТ помогает реализовать, но не должно определять, как бизнес будет жить после изменения.

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

НСИ — не справочник, а опора для изменений

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

Если в НСИ нет порядка, последствия быстро переходят в операционный контур:

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

ИТ подключается после того, как бизнес описал целевую модель, а роль НСИ закреплена как критичная для изменений.

Последствия вместо развития

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

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

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

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

Сопровождение ИС в такой конфигурации выполняет функцию реакции на последствия.

Самая дорогая ошибка

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

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

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

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

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

Текущая ИС уже не справляется

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

Текущая информационная система компании не справляется, когда:

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

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

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

Сначала gap-анализ, потом разговор о платформе

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

Дальше нужен gap-анализ текущей ИС. 

После этого компания должна:

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

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

Где на самом деле лежит решение

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

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

Для бобдей в этой точке и начинается работа. Автоматизация не рассматривается как самостоятельная цель. Сначала бизнес определяет, какой контур управления должен получить на выходе. Только после этого имеет смысл обсуждать, какие изменения нужны в системе, а какие проблемы лежат в процессах, данных, ролях и методологии.

Источники изображений:

Freepik.com

Выбор редакции

Все

Публикации, которые получают больше внимания и попадают в Сюжеты РБК

Рекомендации партнеров: