Сначала факт, потом решение | Наумов

От чертежа до сдачи: где на самом деле умирают сроки в закупке и цехе
(Часть 2: как довести сложное оборудование до паспорта изделия без «магии ИИ»)

В первой части разбирали, почему проекты сыплются еще на этапе ТЗ и КД: https://t.me/ainaumov/15
Технология и КД проверены. Дальше — собрать железо. Здесь обычно и умирают сроки, причем не в цехе, а до него.
Сначала комплектация. Лот на сотни позиций: метизы, кабель, прокат. Предложения приходят в сканах с печатями поверх цифр, в Excel с семью уровнями объединений, в PDF, где «эквивалент по ТУ» вместо ГОСТа, а доставка без НДС спрятана в сноске. Как мы сводим это в шахматку без судьи-модели и почему решение всегда за комиссией — писал тут: https://t.me/ainaumov/13. Без чистого и сопоставимого комплекта цеху просто нечего собирать.

Потом цех. Про понедельники, доску с маркером и планирование по нормам, которого нет, — тоже уже писал: https://t.me/ainaumov/14. Коротко для сборки: нормы приезжают из технологии, а не забиваются второй раз; запущенные партии фиксируются и не двигаются; пересчитывается только свободный хвост; факт возвращается в учетную систему. Иначе план отдельно, цех отдельно.
И финал, про который в канале еще не было, — собственно готовое оборудование.

Узел собран, дальше — предъявительские и приемо-сдаточные: проливка, опрессовка, проверка моментов затяжки, комплектность по ведомости, паспорт изделия, ЗИП. Здесь ИИ вообще не принимает решений. Его работа — только собрать пакет: что по маршруту закрыто, какие операции подтверждены, где были отклонения и кем подписаны. Сдает человек, принимает комиссия и военприемка, если она есть.

Польза, которую можно забрать прямо из этого поста. Проверь свой тракт за 30 минут, возьми один текущий узел и ответь да/нет:
1. ТЗ–КД: давление, марка стали и ГОСТ одни и те же в обоих документах?
2. КД–технология: есть маршрутная карта с нормами, а не «в голове у технолога»?
3. Технология–закупка: единицы бьются (метры, а не тонны), ГОСТ, а не «эквивалент по ТУ»?
4. Технология–цех: названы 5 сбоев, которые роняют график, нормы = смена, а не бумага?
5. Цех–сдача: паспорт собирается из факта (операции, отклонения, подписи), а не пишется задним числом?

Где первое «нет» — там и рвется срок. Именно этот стык и надо чинить первым, а не «внедрять ИИ».

Полный список вопросов для такого разбора — тут: https://naumovai.ru/insights/as-is-checklist/
Вот весь тракт целиком: ТЗ и КД прошли нормоконтроль, чертежи превратились в данные, закупка свелась в сопоставимый вид, цех пережил свои понедельники, узел собран и сдан с паспортом.
Ни на одном шаге модель не подписывала и не командовала станком. Она забирала рутину чтения и сведения, математика держала геометрию и расписание, люди отвечали за решения.

Поэтому пилоты у меня узкие: один поток, одна метрика, хозяин на связи. Широкий «ИИ на весь завод» — это презентация.

Почему проекты сыплются еще на бумаге: как разрыв между ТЗ и чертежом останавливает производство
(на примере задач судостроения и тяжелмаша: архитектура двухслойного контроля)

В судостроении и тяжелом инжиниринге есть жесткое правило: если ошибка просочилась в металл — готовь миллионы на переделки и простой. При этом спорят на предприятиях обычно про станки и софт, а сыплется всё задолго до цеха — на бумаге.
Приходит ТЗ страниц на двести. Половина требований — текстом, половина — «по согласованию», таблицы без единиц, ссылки на ГОСТы разных лет. К нему — конструктив: часть в Компасе, часть в PDF, часть — сканы старых узлов, которые надо повторить.
Дальше по учебнику: ТЗ → КД → технология → комплект → цех → готовое оборудование. По факту первый разрыв — между ТЗ и чертежом. Конструктор прочитал одно, технолог — другое, закупщик — третье. Ошибка, заложенная здесь, потом превращается в переточку, простой и «внесите изменение в КД задним числом».

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

Первый — жесткий, детерминированный: структура документа, штампы, единицы по ГОСТ 8.417, сокращения, даты, пробелы у №, комплектация разделов под ГОСТ 34.602, если речь про ТЗ. Тут никакой вероятности — или сошлось, или нет.

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

Подпись здесь уже работает: нормоконтролер и конструктор видят пакет замечаний, а не «ИИ все исправил».
Только после этого имеет смысл читать чертежи в данные. Как мы внутри периметра разбираем сканы и PDF в черновик для 1С — я уже писал отдельно, повторяться не буду: про чертежи и облака — тут: https://t.me/ainaumov/9

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

Продолжение во второй части: https://t.me/ainaumov/16.

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

Начало смены. На ключевом центре летит шпиндель, станок №4 встает до 16:00. Следом останавливается термообработка — везти заготовки не с чего. За ней проседают еще два участка.

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

Дальше — белая доска, маркер и полтора часа согласований. Вся цифровизация.

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

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

Как мы это чинили в «Поток-ОД» и что спрашивать до старта — расписал по шагам:
👉 https://naumovai.ru/insights/isklyucheniya-v-ponedelnik/

Кейс:
👉 https://naumovai.ru/cases/planner/

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

Типичная картина крупной закупки на производстве: лот на 400-600 позиций (метизы, кабель, металлопрокат, комплектующие).
Приходят коммерческие предложения от пяти поставщиков:
Первое: в кривом скане с косой синей печатью прямо поверх цифр;
Второе: в Excel с семью уровнями объединенных ячеек и формулами, вбитыми вручную;
Третье: на 30 страниц PDF, где марка стали заменена на «эквивалент» по ТУ, а фраза «цена без НДС и доставки» спрятана в сноске на 18-й странице 8-м шрифтом.

Что происходит дальше? Трое специалистов по закупкам запираются в кабинете на трое суток и с красными глазами вручную сводят это в общую «шахматку». На двухсотой строчке внимание неизбежно плывет.
И вот в этот момент возникает соблазн: «А давайте отдадим выбор модели!»
Но нейросеть - это вероятностная машина, а не юрист и не член закупочной комиссии. Она не несет субсидиарной ответственности. Она не пойдет свидетелем в арбитражный суд, когда отклоненный участник оспорит процедуру по 223-ФЗ. А если модель галлюцинирует и пропустит замену ГОСТа или скрытую наценку за доставку - за срыв поставок и простой цеха ответит начальник закупки. Своей подписью.

В проекте Ось мы сразу провели железобетонную границу: модель не выносит приговоров и не выбирает победителя.
Она делает другую, тяжелую и неблагодарную работу:
За 40 минут разбирает разношерстный зоопарк из PDF, сканов и таблиц в единую нормализованную структуру;
Ловит расхождения: когда в ТЗ запрашивали метры, а цену выставили за тонны;
Подсвечивает скрытые риски: не бьющийся НДС, исключения в базисе поставки, фирмы-однодневки по открытым реестрам;
Выдает членам комиссии готовый аналитический пакет: вот сопоставимые цены «яблоко к яблоку», вот расхождения, вот 3 момента, куда нужно посмотреть глазами.
Сведение лота сократилось с 3 рабочих дней до полутора часов.
Но решение принимает человек. Потому что задача ИИ в закупках - не изображать неподкупного судью, а забрать у людей тупую рутину сведения таблиц, чтобы комиссия принимала решения с ясной головой, а не в полуобморочном состоянии.
Кейс проекта Ось и как устроена аналитика закупок:
👉 https://naumovai.ru/cases/axis/

Пятничное наблюдение за рынком B2B и «ИИ-стартапами».

За последнюю неделю в LinkedIn стабильный поток:
1. Пишет зам. директора гигантского аутстаффера: «У нас 1800 разрабов на бенче, возьмите кого-нибудь по T&M».
2. Пишет фаундер «топовой отечественной AI-платформы»: обещает внедрить DWH + AI за 100 тысяч рублей. Под капотом — ClickHouse, n8n и бесплатная обертка над Text-to-SQL.

Рынок наводнили либо продавцы дешевых «рук», либо продавцы воздуха, переупаковывающие open-source связки в «национальные платформы аналитики».

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

Разрыв между «хайпом вокруг ИИ» и реальным производственным инжинирингом в 2026 году стал просто космическим.

Кто на каком фронте этой войны сейчас находится? Делитесь в комментах, интересно сверить часы.

На днях будут новые практичные кейсы.

Обещал вчера рассказать про чертежи и чужие облака.
Есть одна очень простая и неприятная история из практики.
Конструкторское бюро отправляет сборочный чертёж нового узла во внешний ИИ-сервис с вполне невинной целью:

«Да мне только техтребования на английский перевести».

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

Поэтому правило у нас простое:
Если документ нельзя отправить конкуренту на личную почту — его нельзя загружать в публичный веб-интерфейс нейросети.
Но возникает закономерный вопрос: а почему инженеры вообще туда лезут?
Потому что альтернатива часто выглядит так.

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

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

В проекте АИСТ это выглядит так:
локальная VLM-модель работает на сервере предприятия, без необходимости отправлять документацию во внешнее облако;
система распознаёт штамп, таблицы, параметры и специальные требования;
в 1С:ERP формируется черновик данных;
технолог не перепечатывает сотни строк, а проверяет результат, сверяет критические параметры и подписывает его.

И главное:
ИИ не управляет станком и не принимает производственных решений.
Он просто забирает у инженера тупую перепечатку цифр.
Потому что инженер должен заниматься технологией, а не изображать человека-сканер.
Кейс проекта АИСТ и как устроен локальный контур КТПП: 👉 https://naumovai.ru/cases/aist/

В любой компании есть два параллельных мира: «как написано в регламенте» и «как на самом деле крутятся шестерёнки».

Типичная картина, с которой я сталкиваюсь на аудите:

Руководство показывает красивую блок-схему в Visio на 18 шагов: заявка падает в систему, автоматически согласуется, уходит на склад, формируется маршрутная карта.

Приходишь на рабочее место к диспетчеру или инженеру.
На мониторе открыт файл с говорящим названием «Остатки_на_станках_НЕ_ТРОГАТЬ_2026.xlsx».

Спрашиваешь: «А почему не через ERP?»
Ответ: «Павел, если я нажму кнопку в системе, у меня станок встанет на три дня, потому что база не знает, что у нас фреза вчера сточилась, а заготовки пришли не того калибра».

И вот в этот момент приходит восторженный интегратор и предлагает: «Давайте обучим нейросеть на ваших регламентах!»

Что происходит дальше?
Нейросеть идеально выучивает фантазии из регламента. Выкатывают пилот. А мастер смены смотрит на сгенерированные подсказки как на бред сумасшедшего, закрывает систему и возвращается к своему Excel.

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

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

Сначала факт, потом решение | Наумов pinned «📌 Нейросеть сдала экзамен по регламенту на 100 баллов. Мастер смены сдал регламент в макулатуру. В этом канале мы говорим о мастере.»

📌 Нейросеть сдала экзамен по регламенту на 100 баллов.
Мастер смены сдал регламент в макулатуру.
В этом канале мы говорим о мастере.

В интернете каждый день обещают «ИИ, который заменит всех людей».
В реальности цех завода и отдел ВЭД продолжают жить в Excel.
Привет. Меня зовут Павел Наумов.
Я инженер-архитектор систем локального ИИ и автоматизации b2b-процессов (проекты ДОКА, АИСТ, Axis, Planner).
Я создал этот канал с одним главным правилом: "Сначала факт, потом решение."
Сначала мы смотрим, что сотрудники реально кликают в 1С, какие исключения происходят каждый понедельник и где спрятаны теневые таблицы. И только потом решаем, нужен ли здесь скрипт, жесткое правило базы данных или локальная нейросеть на сервере завода.
О чем здесь будем говорить:
1. Теневой контур (as-is): Как найти, где в компании реально живут процессы, до того как сжечь бюджет на сервера.
2. ВЭД и таможня (ДОКА): Как разобрать сложный 32-страничный инвойс в проект XML за 5 минут без утечки коммерческой тайны во внешние облака.
3. Производство и КТПП (АИСТ): Локальное техническое зрение на сервере завода, связка с 1С:ERP и Компас-3D.
4. Эксплуатация On-Premise: Что реально нужно для защищенного контура и кто будет поднимать упавший инференс в пятницу в 21:00.
Чего здесь НИКОГДА не будет:
❌ Пересказов новостей про «очередной прорыв нейросетей»;
❌ Списков «топ-10 промптов для менеджеров»;
❌ Обещаний «100% автономии без участия человека».
Юридическая и производственная подпись всегда остается за человеком. Модель готовит проект решения, отвечает — специалист.
Для старта — 7 прямых вопросов, которые стоит задать до покупки серверов:
👉 https://naumovai.ru/insights/as-is-checklist/
Погнали.

Channel name was changed to «Сначала факт, потом решение | Наумов»

Channel photo updated

Channel created