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

Александр Кузнецов родился в 1959 году в Москве.
В 1986 году окончил Московский институт электронного машиностроения по специальности инженер-системотехник.
Работал в ВЦ «Главмособлстройматериалы», в ВМЦ «ИНТЕГРАЛ», являлся старшим научным сотрудником Института проблем управления.
С 1991 года работает на Микояновском мясокомбинате. Прошел путь от ведущего инженера-электронщика до начальника службы ИТ.
Женат, отец взрослой дочери.

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

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

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

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

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

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

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

В области планирования производства также сильно влияние «логистического компонента». У нас производственный план формируется на основании анализа исторических данных с поправкой на сезонность и актуальные тенденции рынка. Дистрибьюторы и сети чувствуют изменения спроса буквально кончиками пальцев и стремительно меняют закупочную политику, ориентируясь на то, какой товар хорошо идет в данный момент. Прекрасно, если клиент оформляет свой заказ за сутки: значит, у нас достаточно времени, чтобы выработать эту продукцию, упаковать и доставить. Но если заказ делается за четыре часа до предполагаемого получения товара — это проблема, и без ИТ в такой ситуации не обойтись.

И как вы подходите к решению этих «логистических» задач?

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

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

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

Базовый подход к автоматизации мы выработали давно, и за последние годы он практически не изменился. Суть его очень проста, и в среде ИТ-специалистов он фактически принят как стандарт де-факто. Есть стандартные функции, для реализации которых существуют готовые решения. Разрабатывать свой модуль для бухгалтерии нет никакого смысла — надо пользоваться тем, что есть. Выбор конкретного инструмента зависит от масштаба и специфики предприятия, от его потребностей. Мы уже много лет пользуемся «Галактикой», которая успешно решает все бухгалтерские задачи. В последнее время мы добились того, что эта система работает стабильно, производительно и без потерь данных. Пользователей устраивает и её функциональность, и заложенный в ней уровень аналитики. Хотя отдельные шероховатости, конечно, имеются. Сейчас мы внедряем модуль «Галактики» для управления ремонтами. Это вполне достойное тиражное решение.

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

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

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

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

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

Считается, что ограниченность внутренних ресурсов — это наиболее здоровый и естественный повод прибегнуть к аутсорсингу…

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

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

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

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

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

Другое дело, если речь идет о «сложносоставной» системе, включающей в себя программную и аппаратную части. Допустим, складской комплекс — система, состоящая из разных исполнительных механизмов. Это может быть роботизированный участок хаотичного хранения. Скажем, есть сортировочный участок, где происходит «пикинг» — штучная сборка продуктов разного ассортимента в одну коробку. На следующем участке формируется сборный заказ. Далее — так называемая зона комиссионирования, где уже перед погрузкой в машину все заказы следует выстроить в нужном порядке, чтобы потом их правильно загрузили и соответственно выгрузили. Управление всем этим комплексом должна осуществлять единая складская система — WМС.

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

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

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

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

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