Заказной инжиниринг

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

Каждая индустрия, а зачастую и каждое предприятие, обладают разными технологиями и подходами к проектированию. Надо владеть разными САПР. Быть открытым ко всему новому. А иногда отбросить привычные подходы и начать с чистого листа (или с чистого сознания😆)

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

Кто знает их названия?

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

Библиотека #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