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

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

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

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

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

Оказалось — показалось.

Мне понадобился Excel, чтобы организовать сбор статистики. Затем я поговорил с «погромистами» и узнал, что можно выгружать произведённые объёмы труб из АСУ ТП. Потом думал над алгоритмами, рисовал интерфейсы в Пейнте и Паверпоинте.

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

Давайте я расскажу, как в цеху мы открывали для себя ИТ.

Начало

2007 год. Валки лежат на полу в цеху безо всякой системы — всё точно так же, как и 30 лет назад, когда запустили цех. Это наследие 90-х, но уже начинается восстановление: и страну, и заводы постепенно приводят в порядок.

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

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

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

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

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

Валки имеют пять основных состояний:

• В стане (установлены и находятся в работе).
• На складе (можно использовать).
• Валок с дефектом или с высоким износом (его нужно в переточку).
• На ремонте (его сейчас перебирают, меняют внутрянку: подшипники, прокладки или ось).
• В ломе/брак (которые уже выведены, «убитые»).

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

После разборки хаоса выяснилось, что некоторых валков у нас в избытке, а других, которые срочно нужны, не хватало или хватило бы впритык на те 6–10 месяцев, что они изготавливаются. Стоимость валков варьируется. Крупные могут стоить до полутора миллионов рублей, поменьше — около 200 тысяч. Медианная стоимость — где-то полмиллиона. Если перезаказать, то получится, что мы вморозили для цеха несколько десятков миллионов рублей плюс завалили склад ненужным вместо того, чтобы хранить более актуальные артикулы на меньшей площади. Если недозаказали — остановка производства, и страна останется без трубы на несколько месяцев, а завод — без части прибыли.

Для нас потеря репутации и клиентов критична.

Кроме того, раньше валки часто неправильно списывали, потому что не знали их точного статуса. Это вообще ни в какие ворота не лезло.

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

Стало понятно, что от руки всё это делать не очень удобно. Благо у нас шло переоснащение под проект, и мне закупили современный компьютер. На нём запустили трофейный Excel, который, к слову, я с интересом освоил.

Упорядочивание

Дальше рабочие-перевальщики начали постепенно наводить порядок в самом цеху.
Надо было разделить валки по типам, а затем выложить не просто в случайном порядке, а в своих зонах цеха. То есть «четырём ящикам с папками» стали соответствовать четыре склада цеха.

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

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

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

Вот только валков было две тысячи.

Вести учёт на бумаге было неудобно, так что тут и настало время трофейного экселя.

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

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


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

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

Так мы постепенно персонализировали валковый парк.

С нашей точки зрения, эта операция была важной для дополнения разработки ПО.

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




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

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

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

Мы начали вести биографию каждого валка.



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

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

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

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

Кросс-ревью

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



Мы смогли очень точно прогнозировать потребность валков. До 2012 года на старом стане мы расчистили запасы так, что большое количество комплектов осталось на ключевые сортаменты (самые большие объёмы производства трубы), а на редкие сортаменты — поменьше.

В 2012-м с запуском нового стана в цеху № 3 мы вышли с готовой системой. Было запланировано то же количество валков, что и для восьми сортаментов на старом стане, но нам удалось оптимизировать запасы уже для 23 сортаментов, которые мы производим сейчас. То есть склад и резервные запасы валков стали подстраиваться под объёмы производства и реальное физическое состояние валков, а также с учётом накопленных статистических данных. Конечно, помимо разработки системы, мы ещё провели огромную работу по повышению качества производимых валков, но это уже другая история.

Важно было знать, что в цеху нет ситуаций, когда износ валка не учли, то есть не было замен «втёмную». Периодически в случайный день месяца мы назначали аудиты. Инженер приходил в цех и сверял, что указано в документах и базе данных ПО, а что на практике стоит в стане. Ошибок практически не было: возможно, потому, что все знали, что это проверяется. Цеховых это тоже не особо замедляло, ведь они тоже стали управлять процессом, «спать спокойно» и понимать, где какие валки находятся.
Большой вклад в запуск системы на начальном этапе внесли бригадир ТЭСЦ-3 Дмитрий и мастер Алексей.

Первый коммерческий эффект

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

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

Соответственно, никакая бумажка или Excel-таблица не могли быть аргументом для производителя оборудования, чтобы ему что-то предъявить по качеству. А вот автоматический учёт c фиксированием наработок и полной историей — может.

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



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

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

В общем, наш завод получил золотую медаль, мы удивили Тацуми Кимуру (так звали нашего японского аудитора) нашим высоким уровнем развития производственной системы, где был и наш небольшой вклад с нашей системой управления валковым парком.

К нам пришли аудиторы

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

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

Я сейчас не объясню, почему именно, но оказалось, что наша система очень тесно вплетена и в нашу же MES, и в нашу же АСУ ТП. И выколупать её оттуда не получится, потому что у других цехов и системы другие.

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

Бизнес-процесс действительно похож.

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

Всё.

Система же должна подключаться к MES как плагин и налаживать с ней обмен по API, а не становиться её хардкодом.

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


И, напоминаю, перед нами стояла задача сделать систему для производства, а не наоборот.

Мы взяли курс на универсализацию.

Эпоха непонимания

Я стал всё больше погружаться в ИТ, а ИТ стали всё больше уходить подальше от цеха.

В 2019 году стало понятно, что нам нужна новая система, и мы начали писать ТЗ на её разработку, пользуясь всё тем же Power Point'ом. Потому что ничего лучше для рисования интерфейсов во внутреннем контуре мы тогда не знали.



У нас был опыт внедрения относительно простого (как нам казалось) продукта, надо было написать и внедрить сложный.

Сложный оказался суперсложным.

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



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



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

Проект затянулся, сменились пять архитекторов системы, поменялись программисты.

В 2021 году нам дали продукт, разработанный без нашего прямого участия.

Естественно, он оказался сырым.

Система разрабатывалась год без основных эксплуатантов и не включалась в реальные процессы. За всё время было три-четыре консультации. В итоге при первом тестировании оказалось, что система не работает, как должна. А там, где работает, она неудобна.

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

Система должна быть простой, но в то же время охватывать все тонкости процесса.



10 действий вместо двух — это фиаско. У рабочего на производстве — другая функция. Это не работа в системе. Его задача — быстро подготовить качественный инструмент деформации (валки либо какое-то сменное оборудование), обслужить его. Система должна помогать в отслеживании состояния, а не требовать лишних усилий, тем более значительных.

Когда стало понятно, что происходит, мы остановили тестирование, вернули проект и присоединились к новой, 100500-й команде разработчиков, которая начала всё это править.

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

Очень часто оказывалось, что мы обсуждаем одно и то же, но видим это настолько по-разному, что даже не можем понять, что речь-то идёт об одном и том же.

Потом программисты с архитектором преобразовывали это в электронный вид, а мы тестировали.

Сейчас

В 2024 году мы наконец-то вышли с огромной сложной системой.

Сейчас в трёх трубных цехах система находится в опытно-промышленной эксплуатации.

Оценка эффективности — от 2 до 20 % снижения затрат на инструмент в зависимости от цехов. Десятки миллионов экономии в год за счёт оптимизации и более точного планирования закупок, и это не предел. Снижение брака, которое очень сложно посчитать, но значимое. Упорядочивание и понимание, где у нас что, — это вообще бесценно. Удобство, внедрение прогнозирования и автоматического расчёта потребности — вишенка на торте.

Думаете, на этом всё? Нет, конечно. Мы постоянно генерим новые идеи и уже знаем, что будем улучшать дальше!

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

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