Необходимые навыки от Хэппи Хольдена: Решение проблем. Часть 6

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

Я начинал в Hewlett-Packard в совершенно новом отделе производства интегральных схем. Что за дикое время это было в 1970! После шести месяцев знакомства и ориентирования на рабочем месте, однажды ко мне пришел мой босс со срочным предложением: «Ты наш единственный инженер химик, а мы в полном кризисе с нашим новым заводом по производству печатных схем. Ты можешь спуститься с горы и помочь решить проблемы процесса, которые их преследуют?»

«Конечно, - ответил я. А что такое печатные схемы?»

Он ответил: «Это просто большие интегральные схемы!»

Я спустился с горы (с Page Mill Road на Porter Drive в Пало Альто), решил их проблемы процесса за несколько недель… и больше никогда с этим не расставался! У меня было два инструмента, которых не было у инженеров-электриков и инженеров-механиков на заводе печатных плат: инженерная статистика, включая разработку экспериментов (далее в тексте – DOE), и опыт в решение проблем – тотальный контроль качества.

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

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

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

Я уже описывал в данном проекте процесс тотального контроля качества PDCA: Планируй – Делай – Проверь – Действуй. А также процесс Шесть Сигма DMAIC: Определи – Измерь – Анализируй – Улучшай – Контролируй. Многим из вас знаком основной научный метод:

  • Определи проблему/сделай наблюдения
  • Собери информацию и факты
  • Сформулируй гипотезы
  • Проведи эксперименты и собери данные
  • Проанализируй данные
  • Интерпретируй данные и сделай заключения
  • Суммируй результаты

Обычная методология, используемая многими поставщиками, - это «Восемь дисциплин решения проблем» (8D), созданная Департаментом обороны США и популяризированная Фордом (Таблица 1), и CAR, основанная на этом процессе, иногда ссылается на отчеты 8D. Другая популярная методология – «7 шагов решения проблем», приписываемая Тойоте и описанная в Таблице 2.

Моя любимая методология решения проблем – та, которую предлагают Кепнер и Трегоу (Kepner-Tregoe) [1]. Это скрупулёзный трехдневный курс, обычно называемый КТ, который расширяет процессы решения проблем до четырех зон: Оценка Ситуации – Анализ проблемы – Анализ решения – Анализ потенциальных проблем (Рис.1). Их три последовательности действий (Рис.2) суммируют важнейшие шаги в КТ процессе.

 

ЭТАП

ЦЕЛЬ

РЕЗУЛЬТАТ

КЛЮЧЕВЫЕ ВОПРОСЫ

1. Определение проблемы

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

· Обозначение проблемы

· Ведущий проекта

· Бизнес приоритет

· Группа интересов (клиенты, поставщики, члены команды)

· В чем проблема или пробел?

· Почему она имеет клиентский/бизнес приоритет?

· Кто ключевые игроки, связанные с этим проектом?

· Оценка ресурсов (люди, время, деньги)?

· Каковы действия по сдерживанию для клиентов?

2. Текущая ситуация

Прояснить зону (-ы) проблемы на сегодняшний день. Описать все, что известно, о проблеме.

· Идентифицировать где есть проблема, где нет.

· Поддерживающая информация для фокусирования на анализе корневых причин

· Какие вы имеете данные о проблеме?

· Если ли в этих данных тренды (ТКК 7-инструментов, статистика)?

· Нужны ли вам другие данные (диаграмма потока процесса)?

· На каких зонах вам нужно сфокусироваться, основываясь на этих данных?

3. Анализ

причин

Определить и уточнить корневые причины проблемы/ситуации

· Причина/влияние на проблему

· Определить, что повлияло на проблему

· Данные и анализ уточнения корневых причин

· Почему проблема происходит (диаграмма причин и следствий)

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

· Какие причины оказывают наибольшее влияние на проблему (почему)?

· Используйте инструменты анализа для оценки данных (ТКК, DOA)

4. Решения

Разработать планы для устранения корневых причин проблемы/ситуации

· Документирование предложенных решений, которые устранят причины

· План для внедрения и отслеживания результатов

· Выступление против графика (PAS) для внедрения плана

· Какие возможные решения устранят причины, определенные в Шаге 3?

· Каковы рекомендуемые решения?

· На кого повлияют эти решения?

· Каков план внедрения?

· Какие системы отслеживания будут установлены для измерения улучшений?

5. Проверка результатов

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

· Данные, подтверждающие то, что решения устранили корневые причины

· Решение, стоит ли стандартизировать улучшения

· До какой степени данные решения устранят корневые причины?

· Достигнуты ли желаемые цели (из Шага 1)?

· Были ли отклонения от планируемых улучшений?

· Должны ли улучшения быть стандартизированы?

6. Стандар-тизация

Модифицировать процесс/систему, чтобы убедиться, что улучшения будут поддерживаться и в дальнейшем

· Документированный план для коммуникации, интеграции и мониторинга изменений

· Внедрение плана

· Что представляет собой новый процесс (поток процесса)?

· Как вы будете интегрировать изменения в организацию?

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

7. Планы на будущее

Оценить, где мы были и куда нам надо двигаться

· Данные и документация, показывающая эффект усилий по улучшению

· Резюме оставшихся проблем и план работы с ними

· До какой степени ваше решение улучшило ситуацию/проблему?

· Требует ли проблема дальнейшего расследования?

· Какие сложности не были учтены во время решения проблемы?

· На какие другие зоны должен быть направлен процесс изменений?

· Чему научилась команда во время решения проблемы?

· Празднование успеха команды

Таблица 2. «7 шагов решения проблем»

Дисциплина

Описание

D1

Использование командного подхода

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

D2

Описание проблемы

Используйте специальные термины, фотографии и тестируйте или инспектируйте результаты, чтобы объяснить природу проблемы, включая кто, что, где, когда, как и как много.

D3

Разработка промежуточного плана сдерживания

Определите план изолирования проблемы от потребителя

D4

Определение, идентификация и проверка корневых причин

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

D5

Выбор и проверка постоянных корректировок проблемы

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

D6

Проведение и оценка корректирующих действий

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

D7

Принятие превентивных мер

Модифицируйте системы, практики и процедуры для предотвращения повторного возникновения данной проблемы или подобных проблем.

D8

Поздравление команды

Оцените усилия команды.

Таблица 1. 8D - «Восемь дисциплин решения проблем»

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

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

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

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

Следующая моя статья посвящена Разработке экспериментов (DOE). Именно она была моим секретным оружием для решения проблем, когда я впервые столкнулся с проблемами процесса печатных плат. Больше ресурсов и чтения по этому вопросу есть в ASQ (Американское Общество Качества) [2]. У Университета Villanova есть множество он-лайн курсов и сертификатов по шесть сигма и Agile [3].

Ссылки:

  1. Kepner-Tregoe: www.kepner-tregoe.com
  2. ASQ: www.asq.org
  3. Villa Nova University www.villanovau.com

Хэппи Хольден (Happy Holden) работает в сфере технологий печатных плат с 1970 года с Hewlett-Packard, NanYa/ Westwood, Merix, Foxconn и Gentex. В настоящее время со-редактор Printed Circuit Handbook-7th Ed. Для связи с ним, нажмите здесь.

Источник: http://pcb.iconnect007.com/index.php/column/archive/95581/happys-essential-skills/95584/#96109

 

Задать вопрос