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

Кирилл Ледовский

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

Предисловие автора

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

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

При этом первый том сознательно не перегружен рабочими формами, развёрнутыми примерами настройки, шаблонами Excel, картами ролей, регламентами, матрицами, чек-листами, промптами и техническими инструкциями. Всё это вынесено во второй том – «Электронная фабрика. Рабочая документация». Там находятся приложения, на которые здесь даны целевые отсылки: не как рекламные вставки, а как мосты к прикладному слою. Во втором томе читатель найдёт именно то, чего не должно быть слишком много в теоретической книге: сквозные примеры реализации, шаблоны рабочих документов, Excel-контуры, регламенты движения НЗП, формы диспетчеризации, RPA-сценарии, рабочие промпты, инструкции по настройке и диагностике зрелости.

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

Часть

I

. Где заканчивается

ERP

и начинается электронная фабрика

Глава 1. Почему

ERP

есть, а цех всё равно живёт в ручном режиме

Утро на заводе начинается не с плана, а со сбоя.

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

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

Вот в этом месте человек, который не работал в живом производстве, обычно спрашивает: «Подождите, а зачем вам ещё что-то? У вас же ERP внедрена». Именно ради ответа на этот вопрос и написана эта книга.

Где человек обычно тушит это руками

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

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

Иначе говоря, человек в реальности занимается не тем, что «вводит данные в систему», а тем, что каждое утро собирает из обломков событий хоть какое-то исполнимое решение. И здесь надо честно признать одну неприятную правду: ERP не живёт в событиях; ERP живёт в ресурсах, нормах, документах и состояниях учёта. А цех живёт в событиях. Это не недостаток ERP, а просто другой этаж управления.

Не надо воевать с

ERP

. Надо перестать требовать от неё чужую работу

Сразу договоримся: эта книга не против ERP, не против MRP II, не против DDMRP и не против Lean, Kanban или Six Sigma. Наоборот, если на предприятии нет нормального транзакционного ядра, дальше вообще говорить не о чем. Заказы, спецификации, маршруты, статусы, остатки, документы движения, закупки и выпуски должны жить в системе. Классический MRP II именно этим и занимается: он связывает план продаж и операций, главный календарный план, потребности в материалах, потребности в мощностях и поддержку исполнения плана в единый управленческий контур. [1][2][3][4][6][7][8][9]

Но вот где начинается взрослый разговор. ERP и MRP II очень хорошо отвечают на вопросы о том, что надо произвести, из чего это состоит, что для этого нужно, какие мощности и запасы есть в принципе и в каком горизонте всё это должно происходить. А цех каждый день задаёт другой вопрос: что конкретно делать сейчас? [1][2][3][4]

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

Даже 1С

ERP

честно показывает эту границу

В материалах по 1С ERP прямо сказано, что при интервальном планировании этапы размещаются в графике с точностью интервала, а точное расписание выполнения не составляется. Локальный диспетчер уже внутри интервала может определять конкретную дату и последовательность выполнения, руководствуясь своей производственной логикой. Там же отдельно признаются и ограничения такого режима: невозможность точного планирования переналадок, неточность при нескольких ВРЦ внутри этапа, растяжение графика и общая погрешность исполнимости.

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

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

Это давно описано в теории. Просто у нас до этого уровня часто не доходят

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

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

А как же Lean, Kanban, Six Sigma и прочая «современность»?

Этот вопрос обязательно всплывёт, причём с интонацией человека, который уже бывал на тренингах и слышал правильные слова. Поэтому лучше сразу расставить всё по местам. Lean – это про потери, поток, дисциплину, визуальное управление и организацию процесса. Kanban – это про сигнал вытягивания и правила пополнения или передачи в потоке. Six Sigma – это про вариацию, качество, устойчивость процесса и снижение дефектности. DDMRP – это про буферы, decoupling points, пополнение и защиту потока материалов и запасов. MRP II и ERP – это про нормативы, потребности, мощности, статусы, транзакционный контур и управленческую иерархию планов. [6][7][8][9]

А электронная фабрика, как мы её понимаем в этой книге, – про другое. Она про событие, исполнимость, выбор действия, переплан, объяснение решения и, в конечном счёте, про ответ на вопрос: что именно делать сейчас. Мы не спорим ни с Lean, ни с Kanban, ни с Six Sigma, ни с DDMRP; мы просто не даём им занять чужое место. [6][7][8][9]

Очень легко скатиться к разговорам в духе: «А давайте повесим канбан – и всё заработает», «А давайте настроим буферы – и цех сам начнёт всё делать правильно», «А давайте нарисуем доску – и проблема уйдёт». Но если у вас сломался критичный ресурс, заболел редкий специалист, не найдена деталь после операции, не собрана оснастка, сопряжённая группа не дошла, а кооперация сорвала срок, то никакой сам по себе Kanban вам не ответит, кого, куда и в каком порядке сейчас отправлять. [7][8]

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

Производственная практика чувствует это особенно остро

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

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

Когда практик говорит: «По системе вроде есть, а в жизни нет», – это не нытьё. Это диагноз.

Где здесь место технологии

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

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

И это снова возвращает нас к главной мысли.

В чём настоящая проблема

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

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

Что это значит для нашей модели

Из этой главы должно остаться не просто эмоциональное впечатление, а очень конкретное понимание. Если мы строим электронную фабрику, она не должна заменять ERP, спорить с MRP II, конкурировать с DDMRP, подменять Lean, Kanban или Six Sigma, а также забирать на себя бухгалтерию и транзакционный учёт. [1][3][4][6][7][8][9]

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

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

Во втором томе это уже доведено до прикладного уровня и разложено по конкретным приложениям. В приложении 4 «Справочник статусов» собрана рабочая шкала состояний заказа, операции и НЗП; в приложении 5 «Справочник событий» описаны типовые отклонения и их управленческий смысл; в приложении 12 «Шаблон движения НЗП по зонам» показано, как удерживать межоперационное движение и не терять полуфабрикат между участками; а в приложении 16 «Регламент „план → факт → событие → переплан“» собрана сама логика перехода от текущей картины к решению. Второй том здесь даёт уже не тезис, а рабочую схему, по которой этот слой можно собирать руками.

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

Глава 2. Что мы называем электронной фабрикой – и почему это не игрушка для презентаций

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

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

Поэтому здесь надо очень точно зафиксировать: что мы вообще называем электронной фабрикой.

Электронная фабрика – это не витрина, а управленческий слой

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

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

Именно это делает её отдельным слоем, а не расширением чужой функции.

Почему её нельзя путать с

ERP

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

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

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

Почему её нельзя путать с цифровой декорацией

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

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

Электронная фабрика не начинается с того, что «мы стали лучше видеть». Она начинается с того, что мы научились переводить видимость в повторяемое действие.

Почему её нельзя путать с ИИ

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

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

Что в ней обязательно должно быть

Если убрать красивости и назвать минимум, то электронная фабрика должна содержать хотя бы несколько обязательных слоёв.

Во-первых, язык сущностей: заказ, узел, деталь, операция, НЗП, зона, событие, статус, основание выбора, ограничение.

Во-вторых, язык состояний: чтобы система различала не просто наличие объекта, а его управленчески значимое положение.

В-третьих, событийный слой: чтобы отличать обычное состояние от того, что уже меняет решение.

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

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

И, наконец, в-шестых, слой объяснимости: чтобы решение не было магией ни для мастера, ни для плановика, ни для руководителя.

Почему это особенно важно для небольшого и среднего производства

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

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

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

Как отличить настоящую электронную фабрику от её имитации

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

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

Электронная фабрика определяется не красотой интерфейса, а степенью повторяемости управленческого цикла.

Почему в этой книге определение такое жёсткое

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

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

Именно это мы и будем дальше называть электронной фабрикой. Не больше. Но и не меньше.

Что это означает для читателя

После этой главы у читателя должна остаться очень важная ясность. Электронная фабрика – это не декоративный цифровой фасад, не просто улучшенная видимость, не модная приставка к ERP и не “ИИ на заводе” как самостоятельный предмет. Это управленческий слой, который возникает там, где предприятие получает язык сущностей, состояний, событий, ролей и объяснимого выбора действия.

Во втором томе этот слой уже разложен по конкретным рабочим приложениям. В приложении 1 «Канонический словарь полей электронной фабрики» дан состав базовых сущностей и полей модели; в приложении 4 «Справочник статусов» собраны рабочие состояния заказа, операции и НЗП; в приложении 5 «Справочник событий» – перечень типовых отклонений; в приложении 6 «Справочник оснований выбора операций» – логика, по которой система объясняет, почему сейчас выбирается именно это действие; а в приложении 16 «Регламент „план → факт → событие → переплан“» эти сущности уже собраны в последовательность управленческого хода. Иначе говоря, если в первом томе мы объясняем, что именно называем электронной фабрикой, то во втором томе читатель получает её уже как набор именованных рабочих элементов.

Когда само понятие электронной фабрики очерчено, нужно сразу показать её конструкцию. Поэтому дальше книга разбирает, из каких слоёв она реально собирается: ERP, Excel, ChatGPT и RPA. [1][17][18]

Глава 3. Из чего собирается электронная фабрика:

ERP

,

Excel

,

ChatGPT

и

RPA

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

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

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