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

С компьютером в этом смысле всё достаточно честно. Он либо работает, либо нет. Хотя иногда и старается изобразить нечто среднее.

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

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

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

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

Когда ИТ приблизилось к реальной работе

Следующим местом работы стала торговая сеть с территориально распределёнными объектами. К компьютерам и базам данных добавились кассы, весы, POS‑терминалы, сканеры штрихкода и терминалы сбора данных.

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

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

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

В 2022 году я начал работать ведущим инженером MES. И здесь привычного ответа на вопрос «работает система или нет?» оказалось недостаточно.

Система работает, но производство получает не то

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

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

Система могла совершенно точно показать, что участок выпустил за смену. Одновременно из неё становилось понятно, что выпущено совсем не то, что стояло в задании.

Технической ошибки не было. MES правильно зарегистрировала факт.

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

У нас это называли «посмертным» учётом. Название жёсткое, зато точное. Система всё знает, только помочь уже ничем не может.

Так я увидел разницу между исправно работающей информационной системой и управляемым производственным процессом.

Запрос пользователя ещё не постановка задачи

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

Постепенно изменился сам порядок работы с требованиями.

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

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

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

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

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

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

Новая кнопка не заменяет решение

В работе с производственными системами довольно быстро появляется соблазн автоматизировать любую проблему ещё одним полем, статусом или запретом.

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

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

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

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

Автоматизировать отсутствие решения — занятие неблагодарное.

Как изменилась работа руководителя

После позиции ведущего инженера я стал руководителем группы развития и сопровождения MES, а затем начальником отдела.

Вместе с должностью изменился масштаб взгляда.

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

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

Поэтому приходится постоянно возвращаться к исходной проблеме предприятия.

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

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

Что добавил опыт ERP

Сейчас я участвую во внедрении 1С:ERP на химическом производстве. Это позволило посмотреть на предприятие шире.

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

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

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

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

Вопрос, который я задаю теперь

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

После появления MES я стал чаще спрашивать, правильно ли работает система.

Сегодня вопрос звучит иначе. Помогает ли решение предприятию вовремя сделать то, что требуется?

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

Компьютер может включаться. Сервер может отвечать. Обмен может завершаться без ошибок. Отчёт может полностью совпадать с данными в системе.

Для производства этого всё равно может оказаться недостаточно.

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

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

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