23 года я работал в американских компаниях SAS и C3 AI. Это, если что, очень дорогой интеллектуальный анализ данных корпораций и производств. Причём SAS много лет занимал места с 1-го по 3-е в мире как лучший работодатель, поэтому некоторая избалованность присутствует. Последние полтора года до ухода C3 AI из России я работал в подразделении EMEA с непосредственным руководителем в Париже.

Все эти годы коллеги убеждали меня, что в отечественных компаниях работать нельзя: там хамство, бардак, сотрудников обманывают, не уважают и не ценят. За последние два года многие мои коллеги уехали за границу со словами: «Где угодно работать, только не в локальных конторах».

Я пошёл в отечественную компанию. И не просто в отечественную компанию, а в ОМК, то есть на группу заводов (а на заводах, «ну это же общеизвестно», всегда стоит большая очередь кандидатов за забором, и где типа айтишников не ценят, всё вокруг в солидоле и мазуте, и вообще).

Ладно, про лужи смазки — для некоторых цехов это отчасти правда: утечки бывают.

По остальному мне есть что сказать. Сразу поясню: меня никто не заставлял писать этот пост, никакие эйчары не приходили и не просили. Просто достали те, кто ноет. Хорош ныть!

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

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

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

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

Один из коммутационных узлов старого СКУДа. Скрутки и спайки эффектно маскировали в корпусах от радиоприёмников.

Когда я только устроился на эту территорию, я немного обалдел. У нас на щёлковской заводской площадке впервые установили систему контроля и управления доступом (СКУД) в 2008 году.

Доступ на площадь 12 гектаров обеспечивала система с грозным названием «РУБЕЖ». Для подключения её блоков между собой использовались медные многопарные кабели для телефонии, 1980–1990-х годов предположительно.

В стародавние времена систему устанавливали местные кулибины-связисты. Вероятно, перед ними стояла задача что-то сделать без какого-либо финансирования. Они и сделали. СКУД, камеры наблюдения, всё, что можно было соединить, было соединено по телефонным линиям.

Технической документации до нас не дошло, а максимальный срок службы, отмеренный производителями системе «РУБЕЖ», был превышен лет так на пять.

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

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

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

На сегодняшний момент металлолом — наше всё. Нам его надо ОЧЕНЬ много, и мы его закупаем.

Лом нам везут ломовозами с площадок сбора металлолома.

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

— Я только спросить.
— А за меня друг занимал.
— Мне срочно — я беременный.
— Вас здесь не стояло.

Всё это вносило море хаоса.

Этот откровенный бардак не устраивал никого: ни водителей, ни операторов КПП, ни приёмщиков лома. Даже в ближайшем МФЦ уже внедрили электронную очередь! А мы чем хуже?

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

На словах просто, на деле — как обычно.

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

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

Если вам тревожно уходить в отпуск — это тоже оно. Это ваши знания куда-то не переложены.

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

Ещё два признака: мелкое изменение приводит к резкому увеличению трудоёмкости — и никто точно не знает, кто и в какой конкретно момент принимает решение.

Попробуйте проверить процесс на роботизируемость:

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

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

Это примерно одно и то же. И подход один и тот же — надо вовремя что-то с этим делать. Лучше раньше.

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

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

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

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

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

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

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

• Невозрастающей.
• Немонотонной.

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

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

Человек с рацией неизменно побеждал по экономическому эффекту.



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

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

Затем останавливает станок, идёт к терминалу и вводит в систему данные замеров.

Возвращается и снова смотрит на муфты.

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

Понадобилось добраться с автоматизацией до этого самого станка.

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

Устройство-ассистент должно понимать специалиста цеха буквально с полуслова.

Сейчас я расскажу отличную историю, как мы всё это внедряли.

Короче, ИТ на заводе — это вам не романтика, особенно в нашем цифровом направлении.

Между «давайте этим займёмся» и «о, смотрите, какая гламурная ML-модель» лежит очень много того, про что не рассказывают. Сейчас расскажу.

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

И на каждой из этих дорожек нас поджидали свои чудеса и сюрпризы.

Вот, к примеру, видеоаналитика:

• Мы поняли, что ML в 50% задач не нужны. Нужна, например, камера, которая по цвету определяет, где есть железка, и смотрит её геометрию в реальности. Всё. Или другая камера, которая следит, чтобы в нужной зоне ничего не шевелилось.
• Всё это прекрасно до первого солнечного зайчика. ML отлично показывают себя там, где вам лень строить крышу или ставить прожектор над конвейером.
• У нас была идея, что мы можем сами в нейросети. Чуть не написали свой сервис для распознавания номеров вагонов. Казалось, делов-то на 20 минут, а у подрядчика это стоит 25 копеек за фото. Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:

А потом внезапно пошёл дождь. Знаете что? Вагоны под дождём становятся мокрыми. Это было неожиданно. Ещё они бывают после снега, битые, немытые, обновлённые криворукими малярами и ПРОЧИЕ. И в солнечных зайчиках тоже.

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