«Уровни» в VOGBIT в 2021 г. Отличия, особенности, область применения.

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

Количество уровней и их названия с тех пор остались неизменными. Всё те же, что и 10 лет назад:

• Минимальный
• Средний
• Высокий
• Максимальный

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

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

• Появились «цеховые терминалы». Отметки о выполнении работ стали вноситься непосредственно в цехе (чаще всего, тем же кто, собственно, выполнял) путем считывания штрих-кода или пальцем на сенсорном экране. Качество «обратной связи» от производства стало совсем другим, открылись новые интересные возможности.
• Накопился опыт реальной эксплуатации VOGBIT непосредственно в производстве на разных предприятиях. Увеличилось количество активных пользователей. Это, в свою очередь, дало «взрывной» рост обратной связи от них и соответствующее развитие возможностей программы.

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

В итоге, на сегодняшний день (на момент написания статьи: июль 2021 г., версия VOGBIT 21.2) ситуация с «уровнями» поменялась настолько, что некоторые старые ролики и материалы стали смотреться уже совсем не актуально. Поэтому я решил написать статью об «уровнях» в VOGBIT в реальности сегодняшнего дня.

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

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

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

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

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

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

А сначала поговорим об основных особенностях и области применения разных «уровней» в современном их виде.

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

Рис. 1. Цеховой терминал Рис. 2. Цеховой терминал

Основную суть «минимального» уровня в современном его виде можно описать примерно так:

«Минимальный» уровень позволяет контролировать и отслеживать выполнение неких «работ». «Работой» в данном случае можно считать, по большому счёту, всё, что угодно: погрузка машины, наладка станка, изготовление дизель-генераторной установки – всё равно. Что вы сами определите и как назовёте.

Сбор данных о выполнении «работы» при использовании «Минимального» уровня сейчас повсеместно осуществляется с помощью цеховых терминалов (так называемый, «Терминал Тип 0»). Выглядит это следующим образом: в цехе стоит железная коробка с сенсорным экраном, сканером RFID (карточек, брелков, браслетов) и сканером штрих-кодов. Рабочий подходит к ней прикладывает свою карточку (брелок, браслет). Тем самым программа понимает, кто это подошёл. После того, как приложил свою карточку, работник выбирает соответствующий заказ/изделие/работу, чем он сейчас занимается. Выбирает либо нажатием пальцем на экране, либо (если много вариантов, что выбрать, чтобы долго не мотать, не искать нужное) считыванием штрих-кода с некоей «карточки» заказа/изделия/работы. И начинается отсчёт фактически потраченного этим человеком времени на соответствующую «работу». Дальше работник может аналогичным образом отметить, что он закончил взятое «задание» или «взять в работу» другое. В последнем случае, предыдущее, ранее взятое им в работу, задание автоматически «закроется» и «откроется» новое.

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

С другой стороны, те же внутренние цеховые работы, вроде погрузки/разгрузки, уборки и т. п. могут и не иметь в программе определенного «конца» (так тоже можно). Что-то вроде «постоянно открытого наряда», в который можно продолжать дописывать потраченные человеко-часы по мере надобности.

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

В итоге «Минимальный» уровень в современном его варианте преимущественно используется как инструмент для максимально простого и в то же время довольно точного сбора реальной статистики по выполненным работам, в том случае, когда излишние усложнения или детализация просто не нужны.

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

Учитывая вышесказанное, на сегодняшний день на практике сформировалось три основных варианта практического применения в VOGBIT «Минимального уровня»:

• Как предельно упрощённый вариант учёта трудозатрат по заказам в производстве. Просто фиксируется по факту, кто когда над каким заказом/изделием работал без дальнейшей детализации, и собирается статистика (по людям, по заказам). При полном отсутствии необходимости ввода каких-либо исходных данных в виде «спецификаций», «техпроцессов» и т. п. Достаточно ввести «заказ» из одной строчки, и можно начинать.
• Для учета фактических трудозатрат и сбора статистики по работам, слабо поддающимся нормированию. Например проектирование, создание 3D моделей, конструкторско-технологическое сопровождение в цехе, ручная доводка индивидуальных изделий и т. п.
• Для учёта текущих «цеховых работ», вроде наладки оборудования, переточки инструмента, погрузочно-разгрузочных работ и т. п.

В последних двух случаях «Минимальный» уровень обычно применяется совместно (параллельно) со «средним» или «высоким» (о них чуть ниже), которые, в свою очередь, используются для планирования и контроля «основных работ» - изготовления неких деталей, сборочных единиц, изделий. Тем самым пользователи получают максимально точную картину фактических трудозатрат своих сотрудников, включая не только «основные» работы, которые выполняются на основании неких, «заданий» и «технологии», но и времени, затрачиваемого теми же самыми рабочими на различные «вспомогательные работы», а также трудоемкость инженерного сопровождения заказа (большое значение имеет в единичном производстве сложных изделий, например пресс-форм).

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

Любой уровень от «среднего» и выше предполагает, что работы в производстве выполняются на основании некоего «задания». В целом производству, на участок, на рабочее место, конкретному исполнителю (здесь уже как раз начинаются различия между уровнями). «Задание» может быть примерным, или точным. Может быть просто, в виде списка «что делать дальше», или персонального задания конкретному человеку на конкретную смену. Уже в ходе производства такие «задания» могут видоизменяться и дополняться при необходимости. Общим является то, что в любом случае существует некий перечень работ (заданий), определяемый тем, какие «изделия» должно сделать производство, и «технологией», то есть какие операции (работы) нужно выполнить непосредственно на участках/рабочих местах, чтобы получить в итоге эти самые «изделия». Дальнейшее сводится к следующим основным моментам:

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

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

Так в чём основное отличие между ними? Об этом и поговорим далее.

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

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

Вот именно для такой ситуации предназначен «высокий» (/ «максимальный») уровень.

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

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

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

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

Небольшое лирическое отступление, За много лет работы с предприятиями мне доводилось неоднократно сталкиваться со схожей ситуацией, которую можно описать примерно так – когда речь заходит о работе по сменным заданиям, люди говорят: «Да, да. Мы именно так и работаем. Только по сменным заданиям!». Но на самом деле, при ближайшем рассмотрении в реальности это оказывается, мягко говоря, не совсем так.

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

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

Через несколько дней назначенная на это дело со стороны завода женщина позвонила мне вся в слезах и сказала, что её выгнали из цеха со словами: «тебе нужно сменное задание на Иванова (условно) на сегодня? Приходи через 3 дня, и мы тебе его дадим. За сегодня».

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

Глубоким заблуждением в такой ситуации является то, что само появление программы «для выдачи сменных заданий» как-то всё резко изменит, и все сразу начнут по неким «заданиям из программы» работать. Нет. Этого не произойдёт. Потому что первопричины - например, те, что указаны выше в качестве примера (п. 1–4) или подобные, никуда не исчезнут с появлением программы. И само по себе только появление «программы» (не важно, в принципе, какой) никак их не искоренит. Другое дело, если вашей целью является именно искоренение данных факторов, и у вас есть некий план мер и мероприятий, посредством которых вы собираетесь это сделать1. Вот в этом случае программа «для формирования сменных заданий» может стать вам большим подспорьем, поскольку будет, как минимум, хорошим индикатором, насколько у вас на самом деле получается или не получается двигаться в нужном направлении в части проводимых изменений в реальном производстве.

Теперь, возвращаясь к теме статьи и «высокому» уровню в VOGBIT.

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

Соответственно, применение в VOGBIT именно «высокого» уровня оправдано в двух основных случаях:

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

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

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

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

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

И там, и там цель в итоге была достигнута. Результаты очень впечатляют. В первом случае – это увеличение объемов выпуска продукции более, чем в 2 раза на той же самой площадке, том же самом оборудовании и тем же количеством людей. Во втором случае – самое «отстающее» подразделение («это они всегда не успевают и всё тормозят») в группе стало в результате «передовым», обогнав другие, в которых как до этого считалось «проблем и так нет».

Однако, тут нужно отметить 2 ключевых момента:

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

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

«Средний уровень» больше всех «эволюционировал» за время развития программы. Если в начальном варианте он когда-то представлял собой нечто вроде «чуть-чуть расширенного минимального», то на сегодня по возможностям это скорее «почти что тот же высокий, только без некоторых ограничений» (которые, к слову, как оказалось, зачастую и не нужны). По практическому же применению среди пользователей VOGBIT на сегодняшний день именно «средний» уровень занимает безусловное первое место.

Глобально, на сегодняшний день «средний» уровень позволяет делать те же ключевые вещи, что и «высокий» (/ «максимальный»). То есть:

• формировать текущие задания для производства (только в более простом, не в таком детальном варианте, как при использовании «высокого» уровня);
• вести отметки о выполнении работ, в том числе с использованием «терминалов» в цехе, в том числе с фиксацией фактического времени начала и окончания работ, в т. ч. с учётом выполнения одной операции несколькими работниками и т.п.;
• контролировать в различных разрезах текущую ситуацию в производстве и движение заказов и деталей;
• формировать статистику по работникам, станкам, заказам, участкам, видам работ и т. п. и получать соответствующие отчёты<./li>

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

Некое заранее созданное задание на среднем уровне если и есть, то носит довольно приблизительный, укрупненных вид. Оно не является каким-то жёстким ограничением (как на «высоком» уровне), а скорее носит рекомендательный характер. А может и вообще не быть никакого «заранее подготовленного задания» (отметки о выполнении работ просто вносятся по факту). Такое «средний» уровень тоже вполне допускает.

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

В программе есть окно (экранная форма), где в любой момент времени можно при желании посмотреть все «текущие задания» в производстве - то есть, какие детали, сколько, на какой операции по маршруту сейчас находятся2. Строится такой список автоматически, исходя из внесенных (обычно через терминалы в современных условиях) отметок о выполнении работ в цехе. Можно этот список (что сейчас на какой операции) отсортировать, например, по приоритету. Можно сделать выборку по заказу, по участку, по какой-то конкретной операции. Можно выделить что-то из списка и распечатать в виде «задания» (бумажного документа, который отдать в цех) - что в первую очередь делать дальше.

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

Такой подход, в свою очередь, вносит определенную специфику в то, каким именно образом вносятся обычно в VOGBIT отметки о выполнении работ при использовании «среднего» уровня. Какого-то заранее созданного ограниченного списка, что работник конкретно сейчас будет отмечать, в данном случае нет. А выбор, что он в принципе, теоретически, может отметить, запросто может оказаться очень большим (как минимум, десятки разных позиций). Поэтому, чтобы не выискивать на экране терминала в списке из сотни (условно) похожих друг на друга названий нужную деталь, выбор «что сделал» производится на терминалах для «среднего уровня» считыванием штрих-кода соответствующей детали.

Технически это реализуется так:

Рис. 3. Сопроводительный ярлык

При запуске очередных деталей в производство из VOGBIT сразу распечатываются на них какого-либо вида «сопроводительные ярлыки». Физически такой «ярлык» в большинстве случаев представляет собой бумажку (наиболее популярные варианты размера: А4 / А5 / 50*100мм) на которой указано: что за деталь, номер чертежа, сколько всего должно быть штук, для какого это заказа, когда отдано в производство, штрих-код (который как раз и используется далее для отметки при движении этих деталей по производству). Часто такой «ярлык» делается в виде «маршрутного листа». То есть помимо основной информации (выше) ещё добавляется материал, размеры заготовки, маршрут по участкам и по операциям, место для ручных примечаний. В последнее время популярен вариант двусторонней печати, когда на одной стороне печатается такой «маршрутный лист» (заказ, деталь, количество, штрих-код, маршрут), а на другой стороне – чертёж.

Рис. 4. Сопроводительный ярлык - маршрутный лист

Указанные сопроводительные ярлыки (в том или ином виде) прикладываются к соответствующим заготовкам после первой по техпроцессу операции. Наличие в производстве не просто стопки заготовок (деталей), но с приложенным к ней аккуратным печатным ярлыком, с указанием, что это, сколько штук, из какого заказа, когда запущено, и по желанию чертежом на обратной стороне – это само по себе хорошо, и однозначно добавляет порядка. А также сильно упрощает дальнейшие отметки. Работнику, чтобы зафиксировать на цеховом терминале, что он сделал свою операцию, достаточно приложить к датчику терминала свой браслет (брелок, карточку) – кто делал, и считать штрих-код с сопроводительного ярлыка, который был с деталями - что делал3.

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

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

Рис. 5. Пример "текущего задания" на "среднем" уровне

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

• закрепить заранее конкретного исполнителя (человека, пост, станок) за конкретной работой (назначить, что именно он должен в такую-то смену точить (условно) такую-то деталь из такого-то заказа) и заранее увидеть, что в заданное время этот исполнитель будет заниматься именно этой работой;
• раздать созданные таким образом точные сменные задания конкретным работникам или постам. То есть, ещё до начала работ выдать конкретному человеку список, что он в течение сегодняшнего дня (ночи) конкретно он должен делать такие-то детали, до конца смены он должен сделать столько-то штук4.

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

И во всех этих случаях именно «средний» уровень будет лучшим выбором. Да, он плохо приспособлен для задачи заранее составлять точные персональные задания для конкретных исполнителей на конкретное время (для этого, как раз, есть «высокий» уровень). Однако, во многих случаях этого и не нужно. С другой стороны, самое главное, что «средний уровень» и не требует от производства фактически обязательно работать строго по заранее составленным точным заданиям. Что в реальности для очень многих является скорее плюсом, чем минусом.

Подведём итог.

«Минимальный» уровень стоит несколько особняком. Он намного проще всех остальных и хорошо подходит для контроля каких-то работ, плохо поддающихся нормированию и планированию заранее.

«Средний» и «Высокий/Максимальный» уровни по своим возможностям во многом похожи, но имеют принципиальное отличие:

• «высокий» (/«максимальный») уровень предполагает, что реальная работа каждого работника (поста) в производстве строится только на основе заранее подготовленного точного сменного задания, сформированного конкретно для этого работника (поста) на конкретную смену. Ещё до начала этой смены. И основной инструментарий, предоставляемый в данном случае программой, в первую очередь ориентирован на удобное составление таких сменных заданий, отслеживание их дальнейшего выполнения, и при необходимости корректировку. Эта особенность является и главным плюсом (что так делать можно) и в то же время основным ограничением «высокого» уровня (что это обязательно нужно делать, что далеко не всегда соответствует реалиям конкретного производства).
• «средний» уровень плохо подходит для выдачи настолько точных заданий, спланированных заранее. Это с одной стороны его минус по сравнению с «высоким», но с другой стороны и главный плюс. Во многих случаях составить точные персональные задания заранее или невозможно, или просто не нужно. И «средний» уровень этого и не требует. А в части сбора статистики фактического выполнения работ, и контроля ситуации в производстве, он почти ничем глобально не уступает «высокому».

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

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

Здесь будет уместно обозначить ещё один важный момент: современная версия VOGBIT позволяет на одном предприятии использовать разные «уровни» одновременно. Параллельно. Об этом чуть подробнее ниже. А пока, чтобы закончить тему, приведу краткую таблицу сравнения разных «уровней» в том виде, как она выглядит на сегодняшний день (на момент написания статьи – июль 2021, версия VOGBIT 21.2).

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

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

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

Разберем на двух примерах, как выглядят типичные ошибки и заблуждения при выборе «уровня».

Пример 1.

Ситуация:

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

Решение (ошибочное):

«Давайте наймём (выделим) специального человека, которого посадим чисто на постоянное исправление «заданий» в программе. Чтобы он в течение дня составлял и менял «задания» в соответствии с тем, что реально происходит».

Комментарий:

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

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

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

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

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

Но сейчас, с учётом возможностей современной версии VOGBIT, это уже не так.

Правильным решением в такой ситуации на сегодняшний день будет следующее:

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

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

Пример 2.

Ситуация:

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

Комментарий:

Неоправданно сложный путь с учётом возможностей современной версии программы.

По сути, как такового задания посту на конкретную смену в данном случае в реальности нет. По той или иной причине из всего списка работ пользователь не может выделить те, которые пост должен сделать именно в течение следующей смены (т. к. по идеологии «высокого» уровня, включение в «план посту на смену» - это именно задание, т.е. пост должен это и делать в течение смены). Включение в «план на смену» вообще всех работ, какие в принципе есть, с последующей отметкой, что из них сделали – это по смыслу то же самое, что подход «среднего» уровня. Когда «текущим заданием» по умолчанию считается всё, что «дошло» по маршруту до соответствующего исполнителя, и он может отметить из этого то, что сделал по факту. Только на «среднем» уровне для этого не нужно никаких манипуляций вроде «включения в план», «переноса» и т. п. Строго говоря, вообще ничего не нужно, кроме как просто отмечать, что было сделано. При этом конечный результат в плане отражения выполненных работ в «графике производства» и в «статистике производства» совершенно никак не будет отличаться. Учитывая, что при использовании указанным способом «высокого» уровня помимо «переноса» нужно ещё подготовить в программе все «смены» (куда переносить), а сам «перенос» занимает значительное время и мощности сервера (потому что «переносимых» заданий при таком подходе обычно скапливается очень много), в итоге получается как минимум часы, а то и десятки часов в неделю/месяц потраченные на абсолютно бесполезные в плане получения конечного результата действия в программе.

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

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

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

Хочу отметить ещё раз основную мысль – отправной точкой для выбора «уровня» является реальная ситуация в вашем производстве, ваши цели и возможности. Принципиальный «водораздел» в части самого подхода к работе производства пролегает между «средним» и «высоким» уровнями. Всё что ниже («минимальный», «средний») подразумевает достаточно много свободы на уровне исполнителя. Всё, что выше («высокий/максимальный») – наоборот, минимизацию этой свободы, только исполнение чёткого, заранее выданного задания. Что из этого ближе к тому, что вы хотите видеть в реальности у себя на производстве? Решать Вам. Но определяющими факторами является то, какую цель вы преследуете, внедряя/используя программу, и путь, как вы этой цели собираетесь достичь. Правильно выбранный вариант использования программы в производстве, т. е. «уровень», поможет вам на вашем пути. Неправильный выбор, вряд ли сильно приблизит Вас к цели, но почти точно создаст дополнительные сложности в части работы с программой.

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

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