Необходимые навыки от Хэппи Хольдена: Решение проблем. Часть 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].
Ссылки:
- Kepner-Tregoe: www.kepner-tregoe.com
- ASQ: www.asq.org
- 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
