Как омолодить инженеров: вербовать студентов или растить?

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

Что мы имели

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

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

  1. Все основные направления работы были заняты, как правило, к тому моменту уже более десяти лет, специалистами предпенсионного (на тот момент) и пенсионного возраста, то есть необходимо срочно готовить им смену. Еще хуже было то, что по многим направлениям деятельности в службе был один специалист, то есть он получался незаменимым. Такое положение дел я считал недопустимым. Учитывая, что процесс полноценной замены специалистов займет несколько лет, получалось, что временного запаса у нас нет.
  2. Не менее важным, стало признание факта недостаточного владения, в объеме требований поддержки производства, «старшим» поколением современными направлениями электроники (компьютерная техника и ее составляющие, принципы ее работы, программирование), которые активно внедряются в новые разработки на всех уровнях. В этом направлении деятельности следовало просто выстраивать полноценную инженерную команду на основе «молодых» кадров.
  3. Наша «молодежь» не неся и не ощущая на себе ответственности, очень медленно развивалась и слабо интегрировалась в коллектив службы и всего производства. Фактически мы имели две группировки, сильно отличающиеся друг от друга возрастом, опытом, взглядом на жизнь и интересами.

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

Реформы структуры службы

Решение проблем виделось в следующих шагах:

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

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

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

Активизация работы молодого поколения

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

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

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

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

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

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

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

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

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

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

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

Что у нас получилось

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

Ключевыми факторами такого успеха я считаю следующие:

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

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

Фото: pixabay.com

Комментарии
Генеральный директор, Москва
Александр Краснов пишет:

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

Очень хотелось бы узнать, более конкретно о какой конкретно дополнительной работе тут идет речь.

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

Извините меня, но я просил конкретики, а не общих заявлений типа:

Это были обычные рабочие поручения в рамках их должностных обязанностей.

Т.к. возникает вопрос:

КТО раньше выполнял эти обязанности, раз описываемые Вами сотрудники 20 лет их не выполняли?

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

Когда родители кричат на детей? Когда не знают что делать (от беспомощности). По той же причине описанных людей увольняют.

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

По поводу "все плохо" - когда я, как консультант, начинаю собирать инфу в компании, то работа начинается с того момента, когда я услышу критику "что все плохо" - а именно - то-то и то -то. Остальные (кто только хвалит) - могут просто умалчивать проблемы менеджмента в компании.

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

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

Так что на счет "Отличная статья, не к чему придраться" - имею пока иное мнение - не могу найти то, к чему не могу не придраться.

Инженер-конструктор, Санкт-Петербург
Олег Шурин пишет:

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

Извините меня, но я просил конкретики, а не общих заявлений типа:Это были обычные рабочие поручения в рамках их должностных обязанностей.Т.к. возникает вопрос:КТО раньше выполнял эти обязанности, раз описываемые Вами сотрудники 20 лет их не выполняли?

Конвейер похоже заработал быстрее. Ну, а когда конвейер раньше работал с такой интенсивностью, был не один уникальный специалист, а 2-3.

Это, разумеется, мое предположение.

Консультант по корп. финансам, Ростов-на-Дону
Александр Краснов пишет:

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

Уважаемый Александр, реальные должностные обязанности - это то, что человек на самом деле обязан делать на своей работе, если человек никогда этого не делал, это не входило в его реальные должностные обязанности) И зарплата у него формировалась исходя из этого, а не из того что написано в должностной инструкции:)

Инженер-конструктор, Санкт-Петербург
Андрей Панахов пишет:
Уважаемый Александр, реальные должностные обязанности - это то, что человек на самом деле обязан делать на своей работе, если человек никогда этого не делал, это не входило в его реальные должностные обязанности) И зарплата у него формировалась исходя из этого, а не из того что написано в должностной инструкции:)

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

Нач. отдела, зам. руководителя, Владимир

Извините меня, но я просил конкретики, а не общих заявлений типа:

Это были обычные рабочие поручения в рамках их должностных обязанностей.

Т.к. возникает вопрос:

КТО раньше выполнял эти обязанности, раз описываемые Вами сотрудники 20 лет их не выполняли?

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

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

Генеральный директор, Москва
Александр Краснов пишет:
Ну если уж совсем конкретика, то, например, начальник участка поверхностного монтажа (радиоэлементов) говорит, что закупленные элементы вызывают у него вопросы к качеству. Он просит кого-нибудь из инженерной службы решить вопрос - можно ли их использовать в производстве или надо решать вопрос с поставщиком об их возврате/замене. А специалист с 40-летним стажем говорит, что он не считает это своей работой, что, дескать, это унижает его как профессионала. Вы ставьте, а там будем разбираться. Кто раньше решал этот вопрос? Должен был этот же инженер, но если он тянул время, то привлекали другого человека или даже разработчиков. А с него особо не спрашивали, ситуация позволяла.
Или разработчик выпустил новую конфигурацию продукта, при этом сменил версию программного обеспечения (ПО). Инженеру поручают отработать её, выдать замечания, чтобы продукт был готов к эксплуатации. А в ответ слышим, что это дело разработчиков. Ситуация интересней. Это обязанности инженера, но долгое время к таким вопросам (не исправить ПО, а именно проверить работу выпускаемой продукции) не задумываясь привлекали разработчика. Потому что инженер имел возможность переложить эту работу на других (даже на рабочих) и ему, к сожалению, не препятствовали это делать. А в последние годы ситуация усугубилась увеличением объёмов, стало необходимо решать больший круг вопросов и быстрее.

Уважаемы Александр! Благодарю за столь развернутый ответ. Теперь по крайней мере появились какие-то проблески и как следствие возникли новые вопросы:

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

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

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

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

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

Нач. отдела, зам. руководителя, Владимир

Олег, у нас радиотехническое производство.

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

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

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

А по поводу того, что люди не хотят что-то, потому, что это не входит в их зону ответственности я не спорю. Только жизнь не стоит на месте и зона ответственности тоже. Если она изменилась, коллектив это понимает, а если кто-то не готов это принять, то...

Генеральный директор, Москва
Александр Краснов пишет:

Олег, у нас радиотехническое производство.

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

Спасибо за ответ! Давайте попытаемся продолжить разбор Вашей ситуации.

Когда Вы работали рядовым инженером, Вы сами, выполняли те виды работ, которые впоследствии стали требовать от своих подчиненных инженеров?

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

Как я понял, СТЕНДОВ для входной проверки работоспособности элементов у вас на производстве нет?

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

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

Предлагаемый Вами инженеру тип проверки, предусматривал не проверку работоспособности элемента, а лишь контроль его внешнего вида?

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

Александр Краснов пишет:
Теперь по программному обеспечению. Разработчиков привлекали по разным причинам, здесь же идёт речь о том, что наш инженер не хотел (и не научился) работать с ним. Понятно, что корректировать ПО может только тот, кто его написал, однако в наши обязанности входит проверить как работает изделие или система, всем ли требованиям она удовлетворяет. А это тоже перекладывали на разработчика.

Но Вы же сами написали, что

Александр Краснов пишет:
разработчик выпустил новую конфигурацию продукта, при этом сменил версию программного обеспечения (ПО).

Возникают резонные вопросы:

  • Должен ли инженер разбираться в программном обеспечении?
  • Или просто знать, прописанную в инструкции последовательность нажатия тех или иных кнопок?

Не знаю, как у Вас, но я уже писал, что для настройки совместимости ПО с оборудованием, на нашем заводе приглашались итальянские разработчики. И именно они сами + программисты в Италии, подключаясь удаленно производили проверку и настройку.

  • А сейчас, кто у Вас занимается проверкой и настройкой ПО?
  • Ваши новые инженеры или все же разработчики? Особенно учитывая, что как правило, стоимость "допила" ПО, уже включена в стоимость этого ПО.
  • Или у Вас как-то по другому?
Александр Краснов пишет:
А по поводу того, что люди не хотят что-то, потому, что это не входит в их зону ответственности я не спорю. Только жизнь не стоит на месте и зона ответственности тоже. Если она изменилась, коллектив это понимает, а если кто-то не готов это принять, то...

Но Вы же сами, будучи заместителем начальника сборочного производства по техническим вопросам, не стали же брать на себя ответственность по допуску тех элементов в производство?

А новое ПО, Вы лично, уже изучили досконально?

Нач. отдела, зам. руководителя, Владимир

Когда Вы работали рядовым инженером, Вы сами, выполняли те виды работ, которые впоследствии стали требовать от своих подчиненных инженеров?

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

Как я понял, СТЕНДОВ для входной проверки работоспособности элементов у вас на производстве нет?

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

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

Предлагаемый Вами инженеру тип проверки, предусматривал не проверку работоспособности элемента, а лишь контроль его внешнего вида?

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

Александр Краснов пишет:
Теперь по программному обеспечению. Разработчиков привлекали по разным причинам, здесь же идёт речь о том, что наш инженер не хотел (и не научился) работать с ним. Понятно, что корректировать ПО может только тот, кто его написал, однако в наши обязанности входит проверить как работает изделие или система, всем ли требованиям она удовлетворяет. А это тоже перекладывали на разработчика.

Но Вы же сами написали, что

Александр Краснов пишет:
разработчик выпустил новую конфигурацию продукта, при этом сменил версию программного обеспечения (ПО).

Возникают резонные вопросы:

  • Должен ли инженер разбираться в программном обеспечении?
  • Или просто знать, прописанную в инструкции последовательность нажатия тех или иных кнопок?

Не знаю, как у Вас, но я уже писал, что для настройки совместимости ПО с оборудованием, на нашем заводе приглашались итальянские разработчики. И именно они сами + программисты в Италии, подключаясь удаленно производили проверку и настройку.

  • А сейчас, кто у Вас занимается проверкой и настройкой ПО?
  • Ваши новые инженеры или все же разработчики? Особенно учитывая, что как правило, стоимость "допила" ПО, уже включена в стоимость этого ПО.
  • Или у Вас как-то по другому?
Александр Краснов пишет:
А по поводу того, что люди не хотят что-то, потому, что это не входит в их зону ответственности я не спорю. Только жизнь не стоит на месте и зона ответственности тоже. Если она изменилась, коллектив это понимает, а если кто-то не готов это принять, то...

Но Вы же сами, будучи заместителем начальника сборочного производства по техническим вопросам, не стали же брать на себя ответственность по допуску тех элементов в производство?

А новое ПО, Вы лично, уже изучили досконально?

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

Говоря о входном контроле, повторю, что элементы для поверхностного монтажа там проверяют только документарно. Поэтому у них нет стендов для их проверки. Если нужна инструментальная проверка, то привлекают инженеров производства. Но это только если возникают вопросы по качеству. И если бы в данной ситуации начальника участка монтажа не смутил бы их внешний вид, она (начальник - женщина) и вопрос бы не задала. Мы бы с ними разбирались потом в аппаратуре на этапе регулировки. Так что она нам облегчила задачу. Инженеры же у меня в такой ситуации проверяют параметры элементов. Я соглашусь, что это лучше делать на этапе входного контроля, но, как я уже писал, там этого не делают.Поэтому инженеру было поручено оценить соответствие подозрительных элементов своим параметрам до их монтажа. Технически сделать это на производстве не сложно, иначе он бы не получил такого указания. Ответственность за допуск (или недопуск) таких элементов в производство я беру на себя в таких случаях, но только по результатам проверки.

Программное обеспечение для нашей продукции пишет разработчик. Инженеры производства должны провести подготовку производства, то есть в том числе проверить работоспособность изделия по всем параметрам, предусмотренным разработчиком. Это предполагает знание всех возможностей и функций программ наших изделий. Надо попробовать, среди прочего разобраться с нюансами настройки и конфигурирования изделий, попробовать выявить дефекты программного обеспечения. Большинство наших изделий предоставляют широкий диапазон возможного конфигурирования готовых изделий, поэтому надо всё проверить. В теории эта работа подразумевает работу с кнопками, грубо говоря. На практике же, если видим какое-либо не соответствие приходится разбираться, что это: дефект программы или отказ какого-либо элемента. Бывали случаи, что дефект был в других программах, которые считались отлаженными или же было несколько случаев когда не работало наше ПО с покупным. После этого подключить конструкторов к его исправлению. Они тоже обычно просят провести дополнительные проверки. Поскольку у нас ПО присутствует в 90% модулей, то с ним приходится иметь дело всем инженерам. Что касается "допила" ПО, то с этим приходится постоянно сталкиваться. Реальная эксплуатация выявляет дефекты, не смотря на все наши старания.

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

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Вакансии (1518)
Все вакансии
Дискуссии
Все дискуссии