Библиотека #Excogitator

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

Замечательный стандарт VDA 4 «Обеспечения качества в ландшафте процессов» собрал в себя, если не все, то большинство известных инструментов. Написан совместно с инженерами ведущих немецких концернов, стандарт вобрал всё самое лучшее!

В одной книге собрано:

⚙️ Элементарные инструменты управления качеством. Диаграммы: Исикавы, Паретто и корреляционная. Анализ: дисперсионный, дискриминантный и регрессионный. Метод стратификации и контрольные листы

⚙️FTA (Fault Tree Analysis) Анализ дерева отказов

⚙️ FMEA продукта и процесса. Анализ видов и последствий потенциальных отказов

⚙️ SWOT-анализ (Strengths-Weaknesses-Opportunities-Threats)

⚙️ DFMA (Design for Manufacturing and Assembly). Инструмент параллельного инжиниринга с отдельными элементами DFM, DFA, DFS, DFE

⚙️ DMU (Digital mock-up). Наши любимые цифровые двойники, методы и способы управления ими

⚙️ DoE. Планирование эксперимента

⚙️ Анализ возможности изготовления

⚙️ Poka Yoke (японская забава😅)

⚙️ QFD (Quality Function Deployment). Развертывание функций качества

⚙️ ТРИЗ (наша родная😉). Теория решения изобретательских задач

⚙️ Эффективная организация процесса и управления процессом

⚙️ Метод 8D

⚙️ 6 Sigma

⚙️ Эффективный процесс назначения допусков

Мне нравится второе издание (2009), в котором еще осталось FMEA и 8D, в последующих публикациях VDA4 эти разделы вынесены в отдельные стандарты.

К сожалению, очень трудно найти в продаже издание на русском языке😢
Но (!) для наших подписчиков мы поделимся ссылкой на скан-копию из нашей библиотеки.
Пишите в личку🤫

Проектируй. Созидай. #Excogitator🦾
#Library@excolab

Редакторская колонка:
Социальная ответственность

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

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

Я не выбирал кому помогать, скорее меня выбрала тема развития высшего технического образования.

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

С тех пор мы много работали с ребятами над учебными программами ДГТУ, изучали опыт Бауманки и передовые практики. А потом стали обращаться другие вузы за консультациями и советом.

Вот один из запросов уважаемого сибирского университета. Ребята хотят сместить фокус на подготовку будущих  конструкторов и технологов сельхозмашиностроения. Придумали опросник, прислали...
Сижу правлю⌛

Подумал, а вдруг, кто-то из моих подписчиков тоже не равнодушен к высшей школе, тому как и чему учат подрастающих инженеров🤨

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

В награду пришлю финальную версию, которую с вами и заполним🏆

Проектируй. Созидай🦾
СЕО #Excogitator
@AleksakovYuriy

Agile vs Waterfall

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

В начале 2000-х годов в сфере IT произошла революция. Ключевым событием на стыке веков стало появление AGILE-манифеста, который стал основополагающим документом для разработчиков по всему миру. 

AGILE (буквальный перевод – «проворный») — прямая противоположность методологии Waterfall («Водопад»).  Waterfall была доминирующей методологией управления проектами во второй половине XX века.

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

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

Перед появлением AGILE-манифеста многие проекты по разработке программного обеспечения велись в соответствии с традиционными методологиями, такими как Waterfall. В таких методологиях разработка длится многие месяцы или даже годы, а заказчики знакомятся с результатами только на конечной (!) стадии проекта. Это приводило к ряду серьезных проблем:

⚙️Низкая гибкость. Традиционные методологии были малопригодны для адаптации к изменяющимся требованиям заказчиков

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

⚙️ Долгие циклы разработки. Процессы были чрезмерно медленными, что мешало компаниям быстро реагировать на рыночные изменения

⚙️ Отсутствие коммуникации. Разработчики и заказчики редко взаимодействовали напрямую, что приводило к недопониманию и ошибкам.
 
Основные ценности AGILE нацелены как раз на устранение этих проблем:

⚙️ Люди и взаимодействие важнее процессов и инструментов. AGILE призывает к активному сотрудничеству между разработчиками и заказчиками, а также между членами команды разработки

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

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

⚙️ Адаптация к изменениям важнее следования плану. AGILE призывает к гибкости и способности быстро реагировать на изменяющиеся обстоятельства, что помогает улучшить качество конечного продукта.

За прошедшие 20 с лишним лет AGILE вышел далеко за пределы ИТ-сферы и стал применяться в различных отраслях.

А что с машиностроением? Почему так мало удачных (!) примеров?
Или много, а мы не знаем?🤔 Только так, чтобы с выводом на рынок сложных продуктов, а не лозунгами…
Можете припомнить? Пишите!

А мы поделимся нашим мнением в следующем посте🫢

Проектируй. Созидай. #Excogitator 🦾
#Design@excolab

Сам пришел

У нас в гостях Святослав, инженер с двумя десятками лет опыта за плечами, не побоюсь этого слова, ветеран автопрома и робототехники. Продолжим вчерашнюю дискуссию про проектное управление. Для любителей латыни спойлер: Duobus certantibus tertius gaudet😉
Остальные, наслаждаемся текстом:

"Это вечный спор😅 Много с кем общался на эту тему.

Agile = быстро делаем бесконечное количество макетов, пока не заработает… лет через 5.
Waterfall = проектируем чудо-юдо в подвале 3 года, чтобы выйти на свет и выяснить, что такой совершенный с инженерной точки зрения продукт никому не нужен💩

В чистом виде оба подхода - крайне опасные крайности. Истина по середине:

1️⃣ Agile работает там, где MVP (то есть минимальная версия продукта, которую можно продать, а не демо-макет) может составлять проценты от конечного продукта. В том же автопроме, увы, первый продаваемый экземпляр это 95% от конечного задуманного продукта, просто потому что без сертификации и всех кругов ада PPAP машину произвести и продавать нельзя. С этой точки зрения, с помощью инструментов Agile попросту нечего сокращать и выводить на рынок раньше.

2️⃣ Agile способствует развитию мышлению в ключе: что мы сейчас что-то быстро слепим, а потом допилим за несколько заходов. Особенно у стартаперов это прям как пароль: "Мы стартап! Мы должны быстро проверять гипотезы!" Вот многие так и пробуют до сих пор...  Я не спорю, что итеративный метод самый надежный, но самый долгий и очень дорогой ввиду того, что в машиностроении, в отличие от IT, гораздо больше сроки (логистика, производство прежде всего), гораздо выше риски (неправильно спроектировал  - выкинул деньги на производство, сборку и потратил кучу времени на то чтобы дождаться деталей, проверить и понять, что это не то), а еще есть шанс, что кому-то оторвет голову🤯

Пример: я видел, как партию из 20 прототипных машин за десятки миллионов каждая пилили пополам (!) и наращивали корпус, потому что на ходу допроектировали, проверяли... пока место внутри не закончилось😱 Не все машины этот процесс пережили...

Именно поэтому во всем мире пришли к V-диаграмме процесса разработки🦾

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

В такой концепции серии прототипов автомобилей делаются всего 1 - 2 раза и между циклами срок 1 - 1,5 года.

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

3️⃣ Тем не менее, полезные зерна в Agile есть. Пытаться что-то понять раньше, в рамках цикла разработки можно и нужно.

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

НО❗️ нужно соблюдать правила. Какие? О них в завтрашнем посте🫢

4️⃣ Agile как подход к управлению разработкой всего продукта может и плох, а вот в микропроцессах работы инженерного отдела очень даже хорош: недельные спринты, ежедневные стендапы, анализ и корректировка требований на лету (но без фанатизма), KANBAN в трекерах задач упорядочивают и ускоряют все процессы.

Неуместен тут только постулат о меньшей важности документации. Два бича "железной" разработки:
❗️кто-то что-то сделал и ушел, а потом пойди разберись, что зачем и почему
❗️нет чертежа 🔜 деталь рандом 🔜 сегодня прототип собрался, из следующей партии деталей – не собрался.
Зато все развлеклись за деньги инвестора🤑"

Проектируй. Созидай. #Excogitator 🦾
#Design@excolab

Сам пришёл. Часть II

Вчера закончили разговор со Святославом на том, чем может быть полезен Agile на ранних стадиях R&D процесса, говорили про лабриги и мулы шасси.

Сегодня Святослав поделится правилами, которые он использует в своей практике для повышения эффективности процессов Agile:

📌 Делаем функциональные макеты если:

⚙️ нам нужно отработать внешний вид (тут все субъективно и без итераций не обойтись)

⚙️ вам нужно дать хоть что-то электронщикам и программистам для разработки системы управления

⚙️ вам нужно что-то понять, или проверить из области того, что вы не знаете (новый тех. процесс и т.д.)

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

📌 Собираем все метрики с прототипа, разбираемся со всеми причинами отказов и разрабатываем решения, которые по расчетам должны это исправить. Сделал один прототип и сломал – великолепно! Сделала 4 подряд, потому что показалось, что тут вот так будет лучше – искусство ради искусства

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

📌 Никогда не стоит думать, что прототип — это то, что пойдет в серию, “только допилим немножко”. Если получилось – хорошо. Но чаще прототип иметь общего с пилотным продуктом только концепцию, и ни одной общей детали (реальный случай из практики). Вообще, одно из типовых заблуждений владельцев стартапов – “О, он же едет! Завтра начинаем готовить производство партии в 1000 штук”. Часто бывает, что прототип “допилить” невозможно, проще сделать заново.
Не похоже на IT, не правда ли?😉

Проектируй. Созидай. #Excogitator 🦾
#Design@excolab

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

Постараемся описать ожидания и инструменты их достижения:

⚙ Определяем что делать вместе. План развития технической дирекции должен быть единый для Технического директора и Директора по персоналу. Единство цели - это важно!

⚙ Регулярные коммуникации. Как правило, очень сложно организовать методичную работу сразу двух директоров ключевых функций. Поэтому я обеими руками за HR BP. Работает - проверено на практике!

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

⚙ Адаптация - важнее количества принятых сотрудников. Если мы говорим не о массовом подборе, а об ИТР, то важно помнить, что 1-2 новичка на 10-15 сотрудников - это тот максимум, который вы сможете ассимилировать в месяц. Не выжимайте показатели из отдела подбора, а проработайте с вашим HR BP реалистичный план реальной, а не формальной (!) адаптации. Снижаем текучку кадров сразу на входе!

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

⚙ Мотивация. Зарплата важна, но для технического специалиста очень важен результат его трудов и физические мерила успеха. Грамоты, медали, выделить лучшего - всё это работает. Кстати, у меня есть практика награждать и "Провал месяца!" - переходящим цельнометаллическим кубом 150х150х150 мм🦾. И поверьте, стремятся исправиться как можно скорее. В мотивации нет пределов креатива!

⚙ Расставание. Жизнь есть жизнь, иногда приходится прощаться с сотрудником, по разным причинам: переход в другую компанию, семейные обстоятельства, пенсия, да мало ли что еще. Всегда старайтесь сохранить теплые отношения, поговорите, поймите истинную (!) причину ухода. Помните, что сегодня специалист уходит от вас, а завтра он будет ведущим экспертом у вашего заказчика или ЛПР у потенциального клиента. А иногда просто надо кому-то позвонить и проконсультироваться по сложному техническому вопросу. Оставайтесь людьми!

Ещё больше про управление творческими инженерными коллективами, опыт топ-менеджеров крупных машиностроительных предприятий Юрий пишет в своем ТГ-канале EXCOGITATOR.