Химические и амперные материалы; Materials Engineering
Общие ошибки, которых следует избегать при строительстве Wbs в машиностроении
Table of Contents
Введение: Критическая роль структуры разбивки работ в машиностроении
Структура разбивки работ (WBS) является основой любого хорошо управляемого проекта машиностроения. Независимо от того, разрабатываете ли вы новый автомобильный компонент, разрабатываете систему HVAC или строите сложную производственную линию, WBS превращает неопределенную концепцию проекта в четкий, иерархический список результатов и задач. Это позволяет менеджерам проектов распределять бюджеты, назначать обязанности и отслеживать вехи с точностью. Тем не менее, несмотря на свою важность, многие инженерные команды попадают в предсказуемые ловушки при строительстве WBS. Эти ошибки могут привести к ползучести по охвату, конфликтам ресурсов, перерасходу графика и, в конечном итоге, к провалу проекта. Понимая наиболее распространенные подводные камни и применяя дисциплинированный подход, инженеры-механики и менеджеры проектов могут создать WBS, который действительно способствует успеху проекта. В этой статье рассматриваются частые ошибки, возникающие при создании WBS в машиностроении, и предоставляют действенные стратегии, чтобы избежать их.
Ошибки при создании WBS
1.Сделать WBS слишком подробным или слишком широким
Одна из самых постоянных проблем при создании WBS - это поиск правильного уровня детализации. WBS, который чрезмерно гранулирован - перечисляя каждый отдельный проход гайки, болта или сварки - быстро становится неуправляемым. Команда тратит больше времени на обновление WBS, чем на выполнение работы, и структура теряет свою ценность как инструмент связи. И наоборот, WBS, который слишком широк, объединяет несколько недель работы под одной записью, что делает невозможным отслеживание прогресса или выявление рисков на значимом уровне.
Решение заключается в концепции «рабочих пакетов». Каждый рабочий пакет должен быть управляемым блоком работы, который может быть назначен одному человеку или команде, завершен в течение отчетного периода (часто от одной до двух недель) и производит ощутимые критерии доставки или завершения. Например, вместо одной задачи «Создать коробку передач», разбить его на «Создать расположение коробки передач», «Вычислить передаточные коэффициенты», «Проверить отклонение вала» и «Произвести 3D-модель». Но сопротивляйтесь более глубокому проникновению в индивидуальные диаметры отверстий или размеры крепежа, если они не имеют решающего значения для планирования закупок или изготовления. Хорошим эмпирическим правилом является правило 8/80: ни один рабочий пакет не должен требовать менее 8 часов усилий или более 80 часов (две недели). Это сохраняет WBS достаточно подробным для управления и достаточно широким для ясности.
2. Игнорирование масштабов проекта
Еще одна повторяющаяся ошибка заключается в построении WBS без предварительного определения и проверки объема проекта. Когда WBS не соответствует целям, результатам и границам проекта, вы неизбежно включаете задачи «отличного качества», которые выходят за рамки или пропускают необходимые результаты, требуемые заказчиком. В машиностроении, где многие проекты включают соблюдение нормативных требований, тестирование и документацию, пропуски области могут быть особенно разрушительными.
Например, , проект по разработке гидравлического привода может сосредоточиться исключительно на проектировании и прототипировании, но не учитывать необходимость сертификации испытаний на давление, совещаний по обзору дизайна или руководств по установке. Чтобы предотвратить это, всегда начинайте с Заявление о масштабе и четкий список результатов. Перекрестите каждый элемент WBS по объему. Если вы найдете элемент WBS, который не привязан к утвержденному результату или требованию, удалите его. Если требуемый результат отсутствует, добавьте необходимые пакеты работ. Вовлечение клиента или ключевых заинтересованных сторон во время этого выравнивания может сэкономить переделку позже.
3. не вовлекать всю команду
Создание WBS в изоляции — будь то один менеджер проекта или ведущий инженер — это рецепт для слепых зон. Проекты машиностроения являются многодисциплинарными, включающими стресс-аналитиков, специалистов по материалам, инженеров-производителей, сотрудников по закупкам и техников. Каждый член команды понимает конкретные задачи, зависимости и потенциальные риски в своей области намного лучше, чем один человек может.
Когда команда не участвует, вы рискуете пропустить критические задачи, такие как квалификация поставщика, требования к поверхностной отделке или анализы стекапов толерантности. Более того, если с людьми не консультируются, они не могут «купиться» на WBS, что приводит к сопротивлению и неточному отчету о состоянии позже. Совместный семинар WBS, где все члены команды способствуют разложению с помощью липких заметок или цифровых инструментов, обеспечивает всестороннюю идентификацию задач и способствует собственности. Это не означает, что каждая второстепенная задача должна обсуждаться; но ключевые эксперты по предмету должны подтвердить разбивку своих областей. Усилия, вложенные в этот шаг, выплачивают дивиденды на протяжении всего жизненного цикла проекта.
4.Недостаточно четко определенные зависимости от задачи
WBS — это в основе своей разложение работы, а не график. Однако многие команды делают ошибку, игнорируя отношения между рабочими пакетами при строительстве конструкции. Без четкого последовательности и зависимостей ваше расписание будет нереалистичным. Например, вы не можете заказать изготовленные компоненты до завершения выбора материала, и вы не можете выполнить сборочное тестирование до завершения проектирования.
Наилучшая практика заключается в определении типов зависимостей для каждого рабочего пакета. В машиностроении общие зависимости включают:
- Задание B не может начаться до завершения задачи A (например, анализ FEA должен закончиться до начала обработки прототипа).
- Старт-к-старту (SS): Задачи могут пересекаться, общий сценарий проектирования и закупки деталей с длинным лидом.
- Финиш-финиш (FF): Задачи должны заканчиваться вместе (например, интеграция программного обеспечения и прошивки).
Документируйте эти зависимости во время создания WBS, а затем используйте их для создания реалистичного сетевого графика. Инструменты, такие как метод программирования прогнозирования (PDM) [FLT: 1], могут помочь визуализировать эти ссылки. Пренебрежение зависимостями приводит к конфликтам планирования, простою и аварийной переработке - ошибкам, которые гораздо легче предотвратить во время планирования, чем исправить во время выполнения.
5. неспособность разложиться до последовательного уровня
Еще одним частым упущением является несоответствие глубины разложения в различных рабочих областях. Одна команда может разбить электрическую подсистему на шесть подробных рабочих пакетов, в то время как механическая подсистема остается в качестве одной входной позиции высокого уровня. Эта несоответствие создает путаницу, поскольку WBS больше не служит сбалансированной основой для оценки затрат, усилий и продолжительности.
Для поддержания согласованности , применяйте правило «100%» (каждая часть работы должна быть представлена, и никакой дополнительной работы) и убедитесь, что каждая ветвь WBS разлагается до тех пор, пока результаты не будут четко определены и управляемы. Используйте общий уровень детализации — в идеале уровень пакета работы — во всех подсистемах. Если определенная область по своей сути проще, приемлемо иметь меньше уровней, но окончательные пакеты работы должны быть похожими по гранулярности. Например, как «Кадры Шасси», так и «Поставка электроэнергии» филиалы должны заканчиваться пакетами работы, которые не превышают двухнедельное усилие, если нет веского обоснования, такого как внешние зависимости.
6. Не рассматривает работу по проверке и валидации
Проекты машиностроения часто требуют обширных испытаний, проверок качества и сертификации. Распространенной ошибкой является перечисление только задач разработки и производства, при этом опущены этапы проверки, которые доказывают, что продукт соответствует спецификациям. Для судна под давлением нужны задачи для гидростатического тестирования, NDE (неразрушающий контроль) и документация соответствия коду. Для коробки передач нужны термические испытания, измерение шума и пробеги на выносливость.
Как включить проверку : Добавьте рабочие пакеты для каждого этапа тестирования, отслеживания дефектов и критериев принятия клиентов. Убедитесь, что WBS включает в себя «контроль качества» и «поддержку испытаний» в качестве отдельных отделений или как часть каждого результата. Например, вместо просто «Мануфактурная коробка передач», включите «Проверить размеры корпуса передач», «Проверить без нагрузки» и «Сертифицировать крутящий момент». Включение этих задач на ранней стадии позволяет избежать неожиданности обнаружения действий проверки, которые не имеют бюджета или распределения графика.
7.Пытаясь построить WBS в одном проходе
Многие команды пытаются создать «идеальный» WBS в одном совещании или документе, и они парализуются при анализовом параличе. WBS не является статическим; он должен развиваться по мере того, как проект становится лучше понятым. В машиностроении ранние стадии проектирования часто имеют неизвестные, которые невозможно полностью разложить. Например, вы можете не знать точное количество итераций, необходимых для комплексного анализа конечных элементов (FEA). Попытка перечислить все подзадачи заранее приводит либо к нереалистичной детализации, либо к нереалистичной краткости.
Лучший подход заключается в принятии метода планирования волн : разложить ближайшую работу (следующие 4-8 недель) на очень подробный уровень пакета работ, оставляя более поздние этапы в качестве задач резюме более высокого уровня. По мере продвижения проекта и улучшения ясности разложить эти будущие этапы. WBS должен быть живым документом, регулярно пересматриваемым и обновляемым, так же как график и бюджетные базовые линии. Этот адаптивный подход уважает характер инженерных открытий и уменьшает отходы.
Лучшие практики для создания эффективного WBS в машиностроении
Начните с четкой Хартии проекта и его объема.
Прежде чем нарисовать единую коробку WBS, убедитесь, что цели проекта, результаты, исключения и критерии успеха документированы и одобрены. WBS должен быть точным отражением работы, необходимой для достижения этих целей. Если область действия неоднозначна, WBS также будет неоднозначной. Используйте устав проекта или заявление о сфере в качестве основы.
Используйте иерархическую структуру со стандартным кодированием
Организуйте WBS с четкой системой нумерации (например, 1.0, 1.1, 1.1.1), которая позволяет легко ссылаться и ссылаться на счета затрат. Многие машиностроительные фирмы принимают стандартную для отрасли схему кодирования, такую как Обычно используемые шаблоны WBS от Института управления проектами (PMI). Каждый уровень WBS должен быть существительным, который описывает результат, а не действие. Например, используйте «Окончательный отчет о дизайне», а не «Написать отчет». Это подчеркивает результат, а не процесс.
Вовлечение кросс-функциональных заинтересованных сторон в семинар
Соберите представителей инженерных, производственных, закупочных, качественных и ориентированных на клиента команд для структурированной сессии создания WBS. Используйте такие методы, как мозговой штурм, картирование аффинити и открытое обсуждение, чтобы обеспечить захват всех перспектив. Документируйте выход в общей цифровой среде (проект Microsoft, Jira или даже электронная таблица). Время, проведенное в сотрудничестве, уменьшает переработку и создает приверженность.
Применяйте 100% правило строго
Это фундаментальное правило гласит, что сумма работы на каждом нижнем уровне должна представлять 100% работы на родительском уровне, и никакая дополнительная работа сверх того, что описано, не должна включаться. На практике это означает, что каждая задача в WBS должна быть необходимой и достаточной для получения результатов. Если рабочий пакет не способствует достижению результата на более высоком уровне, он является посторонним. И наоборот, если результат не имеет поддержки в WBS, он отсутствует. Проверяйте это правило с каждым уровнем.
Определите рабочие пакеты с четкими критериями завершения
Каждый рабочий пакет должен иметь четко определенный результат, который может быть проверен. Например, «Испытание гидравлического насоса» лучше выразить как «Выполнение гидравлического насоса потока и давления теста по спецификации XYZ - доставка протокола испытаний подписан». Эта ясность позволяет команде точно знать, когда рабочий пакет «сделан» и избегает серых областей, которые вызывают задержки и указывание пальца.
Регулярно пересматривайте и пересматривайте WBS
Планируйте периодические обзоры (например, ежемесячные или после основных этапов), чтобы гарантировать, что WBS остается точным. По мере изменения происходят - масштабные изменения, новые требования, непредвиденные технические проблемы - обновляйте WBS соответственно. Поддерживайте контроль версий и сообщайте текущую версию всем членам команды. WBS не является статическим документом; это динамический инструмент для управления и связи.
Примеры ошибок WBS в машиностроении в реальном мире
Пример 1: Забытая сертификация медицинского изделия
Небольшая машиностроительная фирма разрабатывала новый хирургический инструмент. Их WBS в значительной степени сосредоточилась на итерации дизайна, прототипировании и выборе материалов. Однако они опустили задачи, связанные с документацией системы качества ISO 13485 и подготовкой к подаче заявки FDA. В конце этапа разработки они поняли, что у них нет выделенных часов для написания файлов управления рисками или тестирования биосовместимости, что приводит к проскальзыванию шестимесячного графика. Урок: Всегда включать в себя пакеты работ по соблюдению и сертификации, привязанные непосредственно к регуляторному пути.
Пример 2: Непоследовательная глубина WBS в крупном промышленном проекте
Инженерная компания, создающая автоматизированную конвейерную систему, разработала WBS в двух отдельных командах. Механическая команда разложила свою подсистему на 50 отдельных рабочих пакетов (например, «Дизайн приводного шкива», «Избранный материал ремня»), в то время как электрическая команда выполнила только 3 широкие задачи, охватывающие всю систему управления. Менеджер проекта не мог сравнить прогресс между двумя командами, что привело к несоответствию графиков и позднему обнаружению зависимостей. Урок: Установить единый руководящий принцип разложения перед началом.
Внешние ресурсы для эффективного строительства WBS
Для читателей, желающих углубить свое понимание, вот несколько авторитетных источников:
- Институт управления проектами (PMI) — Структура разбивки работ (WBS): ключевой инструмент управления проектами — стандартное руководство PMI по принципам WBS, включая разложение и правило 100%.
- NASA — Work Breakdown Structure Handbook — Специально разработан для аэрокосмических и механических инженерных проектов, с шаблонами и практическими примерами.
- ASME — Ресурсы управления проектами в области инженерии — Американское общество инженеров-механиков предоставляет рекомендации и тематические исследования, касающиеся структур поломок в работе машиностроения.
- Стандарт практики PMI для структур разбивки работ — Эта книга предлагает пошаговый процесс для построения WBS в разных отраслях промышленности с выборкой WBS для инженерных и строительных проектов.
Вывод: создание WBS, который работает для проектов машиностроения
Структура разбивки работ - это больше, чем артефакт управления проектом; это основополагающая карта, которая направляет каждого члена команды от концепции до завершения. Избегайте распространенных ошибок, обсуждаемых здесь - сверх- или недоразборчиво, игнорируя масштаб, работая в бункерах, пренебрегая зависимостьми, непоследовательное разложение, пропуская проверку и замораживая план слишком рано. Охватывая совместное создание, придерживаясь правила 100% и рассматривая WBS как живой документ, команды машиностроителей могут достичь большей предсказуемости, контроля и успеха проекта. Дополнительные усилия, вложенные в правильно построенный WBS, окупаются меньшим количеством сюрпризов, более четкой связью и более плавным путем к доставке сложных инженерных систем вовремя и в рамках бюджета.