Электронная фабрика. Книга 1. Теория

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

Значит, с чего начинать на практике?

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

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

Первый шаг – не строить всё, а собрать скелет прохождения изделия

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

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

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

Второй шаг – искать не полную операционку, а опорный аналог

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

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

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

Третий шаг – выделить не всё подряд, а ключевые этапы и ключевые РЦ

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

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

Именно это и есть начало управляемости. Если НСИ неполная, не надо сначала дотягивать каждый винтик. Сначала надо увидеть gateway, bottleneck, длинный маршрут и критическую точку сборки.

Четвёртый шаг – разрешить себе экспертные нормы

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

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

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

Пятый шаг – сразу собирать факт, чтобы модель начинала учиться

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

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

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

Шестой шаг – не пытаться сразу описать критичные опасные операции упрощённо

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

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

Седьмой шаг – не ждать полного счастья, а собирать первую работоспособную модель

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

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

Что это означает для электронной фабрики

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

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

Во втором томе эта логика уже разложена по рабочим приложениям. В приложении 2 «Уровни зрелости НСИ и ТПП» показано, как отличать терпимую неполноту от критичной; приложение 3 «Минимальный набор данных для старта» задаёт стартовый каркас модели; приложение 10 «Шаблон расчёта реальной заготовки» помогает не путать чертёжную деталь с реальным запуском; приложение 11 «Шаблон учёта сопряжённых групп деталей» удерживает критические связи внутри изделия; а приложение 25 «Чек-лист зрелости предприятия перед запуском» позволяет честно ответить на вопрос, можно уже стартовать или пока рано. Второй том здесь даёт уже не общую надежду, а вполне рабочий маршрут старта.

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

Глава 12. Канонический словарь электронной фабрики: пока вы спорите о словах, система уже врёт

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

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

Пока это не проговорено, электронная фабрика не строится. Она расползается в языковую кашу.

Почему словарь важнее, чем кажется

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

Один говорит: «деталь готова» – и имеет в виду, что токарка закончена. Другой слышит это как «можно отдавать на сборку». Третий понимает под этим, что деталь просто физически существует. Четвёртый ожидает, что она уже проведена по документам. И вот в этом месте начинается типовая производственная драма.

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

Первый принцип словаря: сущность должна отражать управленческую реальность

Это очень важно. Словарь не должен собираться по принципу «как это когда-то называли в каком-то старом файле». Он должен собираться по принципу: что именно мы хотим видеть и чем именно хотим управлять.

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

Словарь – это не энциклопедия завода. Это язык решения.

Второй принцип: состояние объекта так же важно, как сам объект

Очень часто предприятия пытаются ограничиться словарём «вещей»: деталь, узел, заказ, участок, склад, операция. Но этого мало.

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

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

Третий принцип: словарь должен быть не философским, а рабочим

Это значит, что его должна понимать не только группа методологов, но и люди, которые реально живут в потоке. Если термин красив, но его не понимает мастер, кладовщик, плановик и диспетчер, значит он не канонический, а декоративный.

У хорошего словаря есть признак простоты. Его можно использовать в разговоре, в таблице, в отчёте, в статусе, в RPA-логике, в prompt для ИИ и в диспетчерском разборе – и везде он будет означать одно и то же. Вот тогда он работает.

Четвёртый принцип: названия не должны спорить между собой

На многих заводах одна и та же вещь распадается на синонимы. Где-то пишут «операция», где-то «этап», где-то «переход», где-то «стадия», где-то «работа». Где-то говорят «узел», где-то «сборка», где-то «комплект». Где-то пишут «остаток», хотя по факту имеют в виду НЗП. Где-то слово «событие» используют как синоним «проблемы», а где-то – как синоним «статуса».

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

Пятый принцип: словарь должен позволять связать

ERP

,

Excel

, ИИ и регламенты

Это один из самых практичных моментов во всей книге. Мы ведь уже договорились, что электронная фабрика собирается не из одной системы. У нас есть ERP как официальная память, Excel как расчётная модель, ИИ как слой объяснения и сценарного анализа, RPA как дисциплина факта и регламенты как форма воспроизводимости.

Если в каждом из этих слоёв один и тот же объект называется по-разному, контур будет ломаться на переводе. Поэтому словарь нужен ещё и как язык интеграции. Он позволяет связать поля ERP, колонки Excel, статусы в регламенте, термины в prompt и сущности в отчёте так, чтобы всё это было одной системой, а не набором соседних миров.

Что обычно обязательно должно войти в такой словарь

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

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

Что особенно часто надо вычищать

На практике почти всегда приходится чистить три вещи.

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

Во-вторых, дубли терминов. Когда один и тот же объект живёт под двумя-тремя названиями в разных подразделениях.

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

Хороший словарь всегда немного аскетичен. Он любит не богатство слов, а точность различений.

Почему без словаря ИИ особенно опасен

Это место надо проговорить отдельно. Человек ещё может удерживать локальные диалекты в голове. ИИ – нет. Если в модели нет канонического словаря, он будет старательно смешивать разные значения одного и того же слова, делать правдоподобные, но неточные обобщения и очень быстро превращать производственную путаницу в красиво написанную производственную путаницу.

Поэтому словарь для электронной фабрики – это не только удобство для людей. Это ещё и защита будущего ИИ-слоя от расползания смысла.

Что это означает для практического старта

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

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

Что это означает для электронной фабрики

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

Во втором томе этот слой уже собран в прикладную форму. В приложении 1 «Канонический словарь полей электронной фабрики» дан базовый словарь сущностей и полей модели; приложение 4 «Справочник статусов» задаёт устойчивый язык состояний; приложение 5 «Справочник событий» отделяет событие от статуса и от бытовой «проблемы»; а приложение 26 «Карта ролей и ответственности» помогает увидеть, кто именно какими сущностями и состояниями должен оперировать в реальной жизни. Второй том делает здесь именно то, чего не хватает одному только теоретическому описанию: переводит язык книги в рабочий управленческий словарь.

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

Глава 13. Какие документы ТПП реально нужны электронной фабрике – а какие можно не тащить в контур сразу

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

Обе позиции удобны. И обе по-настоящему вредны.

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

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

Сначала уберём неправильное ожидание

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

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

Значит, нам нужен не список «всего важного на свете», а иерархия документов по управленческой значимости.

Первый уровень необходимости – документы, без которых не виден сам путь изделия

Есть документы ТПП, без которых электронная фабрика просто не увидит, как изделие проходит через производство. Это ядро.

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

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

Второй уровень – документы, без которых нельзя различить состав и связность изделия

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

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

Поэтому состав изделия и его структурные связи – это второй документальный круг, без которого фабрика быстро начинает путать «много деталей» с «почти готовым изделием».

Третий уровень – документы, которые помогают различать реальную физику производства

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

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

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

Что можно не тащить сразу

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

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

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

Но это не значит, что можно презирать ТПП

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

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

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

Здесь важна не полнота любой ценой, а правильный порядок втягивания ТПП в цифровой контур.

Какие ошибки возникают, если тащить слишком мало

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

Слишком бедный документальный контур рождает очень правдоподобную, но неверную управленческую картину. А это особенно опасный тип ошибки.

Какие ошибки возникают, если тащить слишком много

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

Избыточность здесь не менее опасна, чем бедность.