Применение методологии Poka-Yoke (Концепция «Бережливое производство»). Защита от ошибок (POKA YOKE)
Страница
2
Эта концепция "нуль дефектов" отличается от того, что обычно связывается с именем американского наставника Филипа Кросби. В концепции Синго делается упор на достижение бездефектности путем использования хорошей инженерной подготовки производства и исследования производственных процессов, а не с помощью призывов и лозунгов, которые ассоциируются с кампаниями качества, проводимыми американскими и западно-европейскими фирмами. Сам Синго, подобно Демингу и Джурану, демонстрирует озабоченность таким американским подходом, утверждая, что публикация статистики дефектов только вводит в заблуждение и что вместо этого необходимо охотиться за дефектными элементами производственного процесса, которые порождают большинство дефектов продукции.
Система «пока-ека» – основа бездефектного производства.
Дефекты в производстве по большей части возникают из-за увеличения вариабельности характеристик процесса, разброс которых, в свою очередь, может быть следствием:
¾ некорректно разработанных стандартов или документированных процедур;
¾ использования некачественного или устаревшего оборудования;
¾ применения неподходящих материалов;
¾ изношенности инструментов;
¾ ошибок операторов.
Для всех этих причин дефектов, за исключением последней, могут быть применены корректирующие и предупреждающие действия. Предотвратить же ошибки операторов достаточно трудно.
В основе идеологии покэ-ека лежит тот факт, что совершать ошибки для людей в процессе работы – естественно. И это не является показателем непрофессионализма оператора. Цель покэ-ека – найти способы защиты от непреднамеренных ошибок. Перечень типичных действий операторов, приводящих к появлению дефектов представлен в таблице.
Метод покэ-ека базируется на семи принципах:
1 для создания эффективных процессов используйте робастное проектирование;
2 работайте в командах: только так можно максимально полно использовать знания сотрудников;
3 устраняйте ошибки, также используя робастное проектирование: это позволит приблизить число ошибок к нулю;
4 устраняйте коренные причины появления дефектов, применяя метод 5 "Why" (Пять "почему");
5 действуйте сразу, используйте все возможные ресурсы;
6 устраняйте деятельность, не добавляющую ценность;
7 внедряйте улучшения и сразу задумывайтесь над дальнейшими улучшениями.
Применяя покэ-ека не полагаются на то, что операторы сами найдут ошибку. Поэтому при выполнении работ используются сенсорные датчики и другие устройства. Это помогает эффективно выявлять дефекты, пропущенные операторами.
Метод покэ-ека следует применять как при входном контроле, так и в ходе всего процесса. Эффект от его внедрения зависит от того, на каком именно этапе процесса - входном контроле или контроле в ходе процесса - этот метод был использован. При этом, если несоответствия были выявлены, поступают предупреждающие сигналы или, даже, оборудование может быть остановлено.
Внедрение метода покэ-ека при входном контроле называют проактивным подходом. Выявление ошибки в таком случае произойдет до того, как были совершены те или иные операции, пользуются предупреждающие сигналы или даже, оборудование может быть остановлено на выходном контроле.
Подход, при котором метод покэ-ека применяется на других этапах производственного процесса, называют реактивным. В данном случае этот метод используется:
¾ сразу по завершении процесса;
¾ в ходе выполнения работ оператором;
¾ при передаче на следующий этап процесса.
Реактивный подход является эффективным, так как его применение способствует предотвращению передачи бракованных изделий на следующий этап процесса, но, тем не менее, не позволяет достичь столь высокой степени защиты от ошибок, как в случае с проактивным подходом. Применение методов покэ-ека в процессе поиска причин возникновения дефектов не дает высоких результатов, но в то же время он гораздо эффективнее выборочного контроля.
Существуют другие подходы к использованию метода покэ-ека: контролирующий и предупреждающий. При контролирующем подходе, если выявляется дефект, – происходит автоматическая остановка оборудования. Предупреждающий подход основывается на применении всевозможных сигнальных средств (световые и звуковые сигналы), которые сообщают оператору о возможной ошибке. Остановка оборудования часто не входит опции предупреждающего подхода.
Устройства, применяемые в покэ-ека, по методу лежащему в основе их работы, подразделяются на:
¾ контактные;
¾ считывающие;
¾ последовательного движения.
Все три типа устройств могут быть использованы как при контролирующем подходе, так и при предупреждающем.
Принцип работы устройств контактного метода основан на определении того, контактирует ли чувствительный элемент с проверяемым объектом. Примером таких устройств могут служить концевые выключатели. Если контакт нарушается, то срабатывает, например, звуковой сигнал.
Также к устройствам, работающим по контактному методу, относят передатчики и приемники, фотоэлектрические выключатели, пьезоэлектрические датчики и др. Устройства не обязательно должны быть высокотехнологичными. Простые пассивные устройства иногда являются самыми лучшими. Они не позволяют занять детали неправильное положение в ходе процесса.
Считывающие устройства применяются, когда существует фиксированное число операций в процессе и фиксированное число деталей в изделии. Датчик несколько раз просчитывает детали и пропускает изделие на следующий процесс только, если число деталей верно.
Третий тип устройств - датчики, определяющие выполнена ли операция процесса. Если операция не выполнена или выполнена неверно, то датчик сигнализирует, что следует остановить оборудование. По такому принципу работают многие сенсорные и фотоэлектрические устройства, которые связаны с таймером оборудования. Применение таких устройств наиболее эффективно, когда в процессе используются много деталей похожих друг на друга по форме и размеру.
Последовательное применение метода покэ-ека позволяет значительно сократить число ошибок, допускаемых операторами, что способствует снижению затрат и повышению удовлетворенности потребителей.
Применение пока-ека в организациях
Приемы защиты от ошибок, или «покэ-ёка», применяются с целью предотвращения попадания дефектной продукции на следующий этап производства. Для избавления от ошибок необходимо, чтобы проверка качества продукции являлась составной частью любой операции, и оборудование было снабжено сенсорами для обнаружения ошибок и остановки процесса. Метод защиты от ошибок, применяемый в сочетании с другими инструментами экономного производства, служит гарантией того, что продукт не имеет дефектов, а процесс его производства протекает без сбоев.
После появления подхода «пока-ека», он был успешно применен на различных заводах, был установлен рекорд продолжительности работы без дефектов, равный двум годам. В 1968 г. на металлургическом заводе в г. Сага (Saga Ironworks) Синго создал систему пре-автоматизации (Рге-Automation system), которая позже была распространена по всей Японии.
http://pravobez.ru/ по каким номерам телефона можно найти хороших автоюристов.- Перевод
Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип "poka-yoke".
При совместной работе с кодом в команде среднего или большого размера иногда возникают трудности с пониманием и использованием чужого кода. У этой проблемы существуют различные решения. Например, можно договориться следовать определённым стандартам кодирования или использовать известный всей команде фреймворк. Однако зачастую этого недостаточно, особенно когда нужно исправить ошибку или добавить новую функцию в старый код. Трудно вспомнить, для чего были предназначены конкретные классы и как они должны работать как по отдельности, так и совместно. В такие моменты можно случайно добавить побочные эффекты или ошибки, даже не осознавая этого.
Эти ошибки могут быть обнаружены при тестировании , но есть реальный шанс, что они-таки проскользнут в продакшн. И даже если они будут выявлены, может потребоваться довольно много времени, чтобы откатить код и исправить его.
Итак, как мы можем предотвратить это? С помощью принципа «poka-yoke».
Что такое poka-yoke?
Poka-yoke – японский термин, который переводится на английский примерно как «mistake-proofing» (защита от ошибки), а в русском варианте более известен, как «защита от дурака» . Это понятие возникло в бережливом производстве , где оно относится к любому механизму, который помогает оператору оборудования избежать ошибок.
Помимо производства, poka-yoke часто используется в бытовой электронике. Возьмём, к примеру, SIM-карту, которая благодаря своей асимметричной форме может быть вставлена в адаптер только правильной стороной.
Противоположным примером (без использования принципа poka-yoke) является порт PS/2, имеющий одинаковую форму разъёма и для клавиатуры, и для мыши. Их можно отличить только по цвету и поэтому легко перепутать.
Ещё концепция poka-yoke может использоваться в программировании. Идея в том, чтобы сделать публичные интерфейсы нашего кода как можно более простыми и понятными и генерировать ошибки, как только код будет использоваться неправильно. Это может показаться очевидным, но на самом деле мы часто сталкиваемся с кодом, в котором этого нет.
Обратите внимание, что poka-yoke не предназначен для предотвращения преднамеренного злоупотребления. Цель лишь в том, чтобы избежать случайных ошибок, а не в защите кода от злонамеренного использования. Так или иначе, пока кто-то имеет доступ к вашему коду, он всегда сможет обойти предохранители, если действительно этого захочет.
Прежде чем обсуждать конкретные меры, позволяющие сделать код более защищённым от ошибок, важно знать, что механизмы poka-yoke можно разделить на две категории:
- предотвращение ошибок
- обнаружение ошибок.
Механизмы предотвращения ошибок полезны для исключения ошибок на раннем этапе. Максимально упростив интерфейсы и поведение, мы добиваемся того, чтобы никто не мог случайно использовать наш код неправильно (вспомните пример с SIM-картой).
С другой стороны, механизмы обнаружения ошибок находятся вне нашего кода. Они контролируют наши приложения, чтобы отслеживать возможные ошибки и предупреждать нас о них. Примером может быть программное обеспечение, которое определяет, имеет ли устройство, подключённое к порту PS/2, правильный тип, и, если нет, сообщает пользователю, почему оно не работает. Такое ПО не могло бы предотвратить ошибку, поскольку разъёмы одинаковые, но оно может обнаружить её и сообщить об этом.
Далее мы рассмотрим несколько методов, которые можно использовать как для предотвращения, так и для обнаружения ошибок в наших приложениях. Но имейте в виду, что этот список является лишь отправной точкой. В зависимости от конкретного приложения могут быть приняты дополнительные меры, чтобы сделать код более защищённым от ошибок. Кроме того, важно убедиться в целесообразности внедрения poka-yoke в ваш проект: в зависимости от сложности и размера вашего приложения некоторые меры могут оказаться слишком дорогостоящими по сравнению с потенциальной стоимостью ошибок. Поэтому вам и вашей команде решать, какие меры подходят вам лучше всего.
Примеры предотвращения ошибок
Объявление типов
Ранее известное как Type Hinting в PHP 5, объявление типов – это простой способ защиты от ошибок при вызове функций и методов в PHP 7. Назначив аргументам функции определённые типы, становится сложнее нарушать порядок аргументов при вызове этой функции.
Например, давайте рассмотрим уведомление, которое мы можем отправить пользователю:
userId = $userId; $this->subject = $subject; $this->message = $message; } public function getUserId() { return $this->userId; } public function getSubject() { return $this->subject; } public function getMessage() { return $this->message; } }
Без объявления типов можно случайно передать переменные неверного типа, что может нарушить работу приложения. Например, мы можем предположить, что $userId должен быть string , в то время как на самом деле он может быть int .
Если мы передадим в конструктор неправильный тип, то ошибка, вероятно, останется незамеченной до тех пор, пока приложение не попытается что-то сделать с этим уведомлением. И в этот момент, скорее всего, мы получим какое-то загадочное сообщение об ошибке, в котором ничто не будет указывать на наш код, где мы передаём string вместо int . Поэтому обычно предпочтительнее заставить приложение сломаться как можно скорее, чтобы как можно раньше в ходе разработки обнаружить подобные ошибки.
В этом конкретном случае можно просто добавить объявление типов – PHP остановится и немедленно предупредит нас фатальной ошибкой, как только мы попытаемся передать параметр не того типа:
userId = $userId; $this->subject = $subject; $this->message = $message; } public function getUserId() : int { return $this->userId; } public function getSubject() : string { return $this->subject; } public function getMessage() : string { return $this->message; } }
Обратите внимание, что по умолчанию PHP попытается привести неверные аргументы к их ожидаемым типам. Чтобы этого не произошло и сгенерировалась фатальная ошибка, важно разрешить строгую типизацию (strict_types). Из-за этого объявление скалярных типов не является идеальной формой poka-yoke, но служит неплохой отправной точкой для уменьшения количества ошибок. Даже при отключённой строгой типизации объявление типов всё равно может служить подсказкой, какой тип ожидается для аргумента.
Кроме того, мы объявили типы возвращаемых данных для наших методов. Это упрощает определение того, какие значения мы можем ожидать при вызове той или иной функции.
Чётко определённые типы возвращаемых данных также полезны для избегания множества операторов switch при работе с возвращаемыми значениями, поскольку без явно объявленных возвращаемых типов наши методы могут возвращать различные типы. Поэтому кто-то, используя наши методы, должен будет проверить, какой тип был возвращён в конкретном случае. Очевидно, что можно забыть об операторах switch , что приведёт к ошибкам, которые трудно обнаружить. Но они становятся гораздо менее распространёнными при объявлении типа возвращаемого значения функции.
Объекты-значения
Проблема, которую не может решить объявление типов, заключается в том, что наличие нескольких аргументов функции позволяет перепутать их порядок при вызове.
Когда аргументы имеют разные типы, PHP может предупредить нас о нарушении порядка аргументов, но это не cработает, если у нас несколько аргументов с одним и тем же типом.
Чтобы в этом случае избежать ошибок, мы могли бы обернуть наши аргументы в объекты-значения (value objects):
class UserId { private $userId; public function __construct(int $userId) { $this->userId = $userId; } public function getValue() : int { return $this->userId; } } class Subject { private $subject; public function __construct(string $subject) { $this->subject = $subject; } public function getValue() : string { return $this->subject; } } class Message { private $message; public function __construct(string $message) { $this->message = $message; } public function getMessage() : string { return $this->message; } } class Notification { /* ... */ public function __construct(UserId $userId, Subject $subject, Message $message) { $this->userId = $userId; $this->subject = $subject; $this->message = $message; } public function getUserId() : UserId { /* ... */ } public function getSubject() : Subject { /* ... */ } public function getMessage() : Message { /* ... */ } }
Поскольку наши аргументы теперь имеют очень специфический тип, их почти невозможно перепутать.
Дополнительным преимуществом использования объектов-значений по сравнению с объявлением скалярных типов является то, что нам больше не нужно включать строгую типизацию в каждом файле. А если нам не нужно об этом помнить, то мы не сможем об этом забыть.
Валидация
При работе с объектами-значениями мы можем инкапсулировать логику проверки своих данных внутри самих объектов. Таким образом, можно предотвратить создание объекта-значения с недопустимым состоянием, которое может привести к проблемам в будущем в других слоях нашего приложения.
Например, у нас может быть правило, согласно которому любой UserId всегда должен быть положительным. Мы могли бы, очевидно, проверять его всякий раз, когда получаем UserId в качестве входных данных, но, с другой стороны, его также можно легко забыть в том или ином месте. И даже если эта забывчивость приведёт к фактической ошибке в другом слое нашего приложения, из сообщения об ошибке может быть сложно понять, что на самом деле пошло не так, а это усложнит отладку.
Чтобы предотвратить подобные ошибки, мы могли бы добавить некоторую валидацию в конструктор UserId:
class UserId { private $userId; public function __construct($userId) { if (!is_int($userId) || $userId < 0) { throw new \InvalidArgumentException("UserId should be a positive integer."); } $this->userId = $userId; } public function getValue() : int { return $this->userId; } }
Таким образом, мы всегда можем быть уверены, что при работе с объектом UserId он имеет правильное состояние. Это избавит нас от необходимости постоянно проверять данные на разных уровнях приложения.
Обратите внимание, что здесь мы могли бы добавить объявление скалярного типа вместо использования is_int , но это заставит нас включать строгую типизацию везде, где используется UserId . Если это не сделать, то PHP будет пытаться приводить другие типы к int всякий раз, когда они передаются в качестве UserId . Это может стать проблемой, так как мы могли бы, например, передать float , который может оказаться неправильной переменной, поскольку идентификаторы пользователя обычно не являются float . В других случаях, когда мы могли бы, например, работать с объектом Price , отключение строгой типизации может привести к ошибкам округления, поскольку PHP автоматически преобразует float-переменные в int .
Неизменяемость
По умолчанию объекты в PHP передаются по ссылке. Это означает, что, когда мы вносим изменения в объект, он мгновенно изменяется во всём приложении.
Хотя у этого подхода есть свои преимущества, он имеет и некоторые недостатки. Рассмотрим пример уведомления, отправляемого пользователю посредством SMS и электронной почты:
interface NotificationSenderInterface { public function send(Notification $notification); } class SMSNotificationSender implements NotificationSenderInterface { public function send(Notification $notification) { $this->cutNotificationLength($notification); // Send an SMS... } /** * Makes sure the notification does not exceed the length of an SMS. */ private function cutNotificationLength(Notification $notification) { $message = $notification->getMessage(); $messageString = substr($message->getValue(), 160); $notification->setMessage(new Message($messageString)); } } class EmailNotificationSender implements NotificationSenderInterface { public function send(Notification $notification) { // Send an e-mail ... } } $smsNotificationSender = new SMSNotificationSender(); $emailNotificationSender = new EmailNotificationSender(); $notification = new Notification(new UserId(17466), new Subject("Demo notification"), new Message("Very long message ... over 160 characters.")); $smsNotificationSender->send($notification); $emailNotificationSender->send($notification);
Поскольку объект Notification передаётся по ссылке, получился непреднамеренный побочный эффект. При сокращении длины сообщения в SMSNotificationSender связанный объект Notification был обновлен во всём приложении, так что сообщение тоже было обрезанным, когда позже отправлялось в EmailNotificationSender .
Чтобы исправить это, сделаем объект Notification неизменяемым. Вместо того чтобы предоставлять set-методы для внесения в него изменений, добавим with-методы, которые делают копию исходного Notification перед внесением этих изменений:
class Notification { public function __construct(...) { /* ... */ } public function getUserId() : UserId { /* ... */ } public function withUserId(UserId $userId) : Notification { $c = clone $this; $c->userId = clone $userId; return $c; } public function getSubject() : Subject { /* ... */ } public function withSubject(Subject $subject) : Notification { $c = clone $this; $c->subject = clone $subject; return $c; } public function getMessage() : Message { /* ... */ } public function withMessage(Message $message) : Notification { $c = clone $this; $c->message = clone $message; return $c; } }
Теперь, когда мы вносим изменения в класс Notification , например, сокращая длину сообщения, они больше не распространяются на всё приложение, что позволяет предотвратить появление различных побочных эффектов.
Однако обратите внимание, что в PHP очень сложно (если не невозможно) сделать объект по-настоящему неизменяемым. Но для того чтобы сделать наш код более защищённым от ошибок, будет достаточно добавить «неизменяемые» with-методы вместо set-методов, так как пользователям класса больше не нужно будет помнить о необходимости клонировать объект перед внесением изменений.
Возвращение null-объектов
Иногда мы сталкиваемся с функциями и методами, которые могут вернуть либо какое-то значение, либо null . И эти null’евые возвращаемые значения могут представлять проблему, поскольку почти всегда нужно будет проверять значения на null, прежде чем мы сможем что-то с ними сделать. Об этом опять же легко забыть.
Чтобы избавиться от необходимости проверки возвращаемых значений, мы могли бы возвращать вместо этого null-объекты. Например, у нас может быть ShoppingCart со скидкой или без:
interface Discount { public function applyTo(int $total); } interface ShoppingCart { public function calculateTotal() : int; public function getDiscount() : ?Discount; }
При вычислении конечной стоимости ShoppingCart перед вызовом метода applyTo нам теперь всегда нужно проверять, что вернула функция getDiscount(): null или скидку:
$total = $shoppingCart->calculateTotal(); if ($shoppingCart->getDiscount()) { $total = $shoppingCart->getDiscount()->applyTo($total); }
Если не выполнить эту проверку, то мы получим предупреждение PHP и/ или другие побочные эффекты, когда getDiscount() вернёт null .
С другой стороны, этих проверок можно избежать, если мы вернём null-объект, когда скидка не предоставляется:
class ShoppingCart { public function getDiscount() : Discount { return !is_null($this->discount) ? $this->discount: new NoDiscount(); } } class NoDiscount implements Discount { public function applyTo(int $total) { return $total; } }
Теперь, когда мы вызываем getDiscount() , мы всегда получаем объект Discount , даже если скидка отсутствует. Таким образом, мы можем применить скидку к итоговой сумме, даже если её нет, и нам больше не нужна инструкция if:
$total = $shoppingCart->calculateTotal(); $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);
Опциональные зависимости
По тем же причинам, по которым мы желаем избежать null’евых возвращаемых значений, мы хотим избавиться и от опциональных зависимостей, просто сделав все зависимости обязательными.
Возьмём, к примеру, следующий класс:
class SomeService implements LoggerAwareInterface { public function setLogger(LoggerInterface $logger) { /* ... */ } public function doSomething() { if ($this->logger) { $this->logger->debug("..."); } // do something if ($this->logger) { $this->logger->warning("..."); } // etc... } }
Есть две проблемы:
- Нам постоянно нужно проверять наличие логгера в нашем методе doSomething() .
- При настройке класса SomeService в нашем сервис-контейнере кто-то может забыть сконфигурировать логгер, или он может вообще не знать, что у класса есть возможность это сделать.
Мы можем упростить код, сделав LoggerInterface обязательной зависимостью:
class SomeService { public function __construct(LoggerInterface $logger) { /* ... */ } public function doSomething() { $this->logger->debug("..."); // do something $this->logger->warning("..."); // etc... } }
Теперь наш публичный интерфейс стал менее громоздким, и всякий раз, когда кто-то создаёт новый экземпляр SomeService , он знает, что класс требует экземпляр LoggerInterface , и поэтому он никак не сможет забыть указать его.
Кроме того, мы избавились от необходимости постоянной проверки наличия логгера, что делает doSomething() более лёгким для понимания и менее восприимчивым к ошибкам всякий раз, когда кто-то вносит в него изменения.
Если бы мы захотели использовать SomeService без логгера, то могли бы применить ту же логику, что и с возвращением null-объекта:
$service = new SomeService(new NullLogger());
В итоге этот подход имеет тот же эффект, что и использование необязательного метода setLogger() , но упрощает наш код и снижает вероятность ошибки в контейнере внедрения зависимостей.
Public-методы
Чтобы сделать код проще в использовании, лучше ограничить количество public-методов в классах. Тогда код становится менее запутанным, и у нас меньше шансов отказаться от обратной совместимости при рефакторинге.
Свести количество public-методов к минимуму поможет аналогия с транзакциями. Рассмотрим, к примеру, перевод денег между двумя банковскими счетами:
$account1->withdraw(100); $account2->deposit(100);
Хотя база данных с помощью транзакции может обеспечить отмену снятия денег, если пополнение не может быть сделано (или наоборот), она не может помешать нам забыть вызвать либо $account1->withdraw() , либо $account2->deposit() , что приведёт к некорректной операции.
К счастью, мы легко можем исправить это, заменив два отдельных метода одним транзакционным:
$account1->transfer(100, $account2);
В результате наш код становится более надёжным, поскольку будет сложнее совершить ошибку, завершив транзакцию частично.
Примеры обнаружения ошибок
Механизмы обнаружения ошибок не предназначены для их предотвращения. Они должны лишь предупреждать нас о проблемах, когда они обнаруживаются. Большую часть времени они находятся за пределами нашего приложения и проверяют код через определённые промежутки времени или после конкретных изменений.
Unit-тесты
Unit-тесты могут быть отличным способом убедиться в корректной работе нового кода. Они также помогают удостовериться, что код по-прежнему работает корректно после того, как кто-то реорганизовал часть системы.
Поскольку кто-то может забывать проводить unit-тестирование, рекомендуется автоматически запускать тесты при внесении изменений с использованием таких сервисов, как Travis CI и GitLab CI . Благодаря им разработчики получают уведомления, когда что-то ломается, что также помогает убедиться, что сделанные изменения работают так, как задумывалось.
Помимо обнаружения ошибок, unit-тесты являются отличными примерами использования конкретных частей кода, что в свою очередь предотвращает ошибки, когда кто-то другой использует наш код.
Отчёты о покрытии кода тестами и мутационное тестирование
Поскольку мы можем забыть написать достаточно тестов, полезно при тестировании автоматически генерировать отчёты о покрытии кода тестами с помощью таких сервисов, как Coveralls . Всякий раз, когда покрытие нашего кода снижается, Coveralls отправляет нам уведомление, и мы можем добавить недостающие тесты. Благодаря Coveralls мы также можем понять, как меняется покрытие кода с течением времени.
Ещё один способ убедиться, что у нас достаточно unit-тестов, - использование мутационных тестов, например, с помощью Humbug . Как следует из названия, они проверяют, достаточно ли наш код покрыт тестами, слегка изменяя исходный код и запуская после этого unit-тесты, которые должны генерировать ошибки из-за сделанных изменений.
Используя отчёты о покрытии кода и мутационные тесты, мы можем убедиться, что наших unit-тестов достаточно для предотвращения ошибок.
Статические анализаторы кода
Анализаторы кода могут обнаружить ошибки в нашем приложении в начале процесса разработки. Например, IDE, такие как PhpStorm , используют анализаторы кода, чтобы предупреждать нас об ошибках и давать подсказки, когда мы пишем код. Ошибки могут варьироваться от простых синтаксических до повторяющегося кода.
Помимо анализаторов, встроенных в большинство IDE, в процесс сборки наших приложений можно включить сторонние и даже пользовательские анализаторы для выявления конкретных проблем. Неполный список анализаторов, подходящих для проектов на PHP, можно найти на GitHub .
Логирование
В отличие от большинства других механизмов обнаружения ошибок, логирование может помочь обнаружить ошибки в приложении, когда оно работает в продакшне.
Конечно, для этого требуется, чтобы код писал в лог всякий раз, когда случается что-то неожиданное. Даже когда наш код поддерживает логгеры, про них можно забыть при настройке приложения. Поэтому следует избегать опциональных зависимостей (см. выше).
Хотя большинство приложений хотя бы частично ведут лог, информация, которая туда записывается, становится действительно интересной, когда она анализируются и контролируется с помощью таких инструментов, как Kibana или Nagios . Они могут дать представление о том, какие ошибки и предупреждения возникают в нашем приложении, когда люди активно его используют, а не когда оно тестируется.
Не подавлять ошибки
Даже при логировании ошибок случается, что некоторые из них подавляются. PHP имеет тенденцию продолжать работу, когда происходит «восстанавливаемая» ошибка. Однако ошибки могут быть полезны при разработке или тестировании новых функций, поскольку могут указывать на ошибки в коде. Вот почему большинство анализаторов кода предупреждают вас, когда обнаруживают, что вы используете @ для подавления ошибок , так как это может скрывать ошибки, которые неизбежно появятся снова, как только приложение станет использоваться.
Как правило, лучше установить уровень error_reporting PHP на E_ALL , чтобы получать сообщения даже о малейших предупреждениях. Однако не забудьте запротоколировать где-нибудь эти сообщения и скрыть их от пользователей, чтобы никакая конфиденциальная информация об архитектуре вашего приложения или потенциальных уязвимостях не была доступна конечным пользователям.
Помимо error_reporting , важно всегда включать strict_types , чтобы PHP не пытался автоматически приводить аргументы функций к их ожидаемому типу, поскольку это может приводить к трудно обнаруживаемым ошибкам (например, ошибкам округления при приведении float к int).
Использование вне PHP
Поскольку poka-yoke скорее концепция, чем конкретная методика, её также можно применять в сферах, не связанных с PHP.
Инфраструктура
На уровне инфраструктуры многие ошибки могут быть предотвращены путём создания общей среды разработки, идентичной среде production, с использованием таких инструментов, как Vagrant .
Автоматизация развёртывания приложения с использованием серверов сборки, таких как Jenkins и GoCD , может помочь предотвратить ошибки при развёртывании изменений в приложении, поскольку этот процесс может включать в себя множество шагов, часть из которых легко забыть выполнить.
REST API
При создании REST API можно внедрить poka-yoke, чтобы упростить использование API. Например, мы можем убедиться, что возвращаем ошибку всякий раз, когда неизвестный параметр передаётся в URL или в теле запроса. Это может показаться странным, поскольку мы, очевидно, хотим избежать «поломки» наших API-клиентов, но, как правило, лучше как можно скорее предупреждать разработчиков, использующих наш API, о некорректном использовании, чтобы ошибки были исправлены на ранней стадии процесса разработки.
Например, у нас в API может быть параметр color , но кто-то, кто использует наш API, может случайно использовать параметр colour . Без каких-либо предупреждений эта ошибка может запросто попасть в продакшн, пока её не заметят конечные пользователи.
Чтобы узнать, как создавать API, которые не доставят вам хлопот, прочтите книгу Building APIs You Won’t Hate .
Конфигурация приложения
Практически все приложения нуждаются в какой-либо пользовательской настройке. Чаще всего разработчики предоставляют как можно больше значений настроек по умолчанию, что упрощает конфигурирование. Однако, как в примере с color и colour , можно легко ошибиться в параметрах конфигурации, что заставит приложение неожиданно вернуться к значениям по умолчанию.
Такие моменты трудно отследить, ведь приложение не инициирует ошибку как таковую. И лучший способ получить уведомление при неправильной настройке – просто не предоставлять никаких значений по умолчанию и сгенерировать ошибку, как только будет отсутствовать параметр конфигурации.
Предотвращение ошибок пользователя
Концепция poka-yoke также может использоваться для предотвращения или обнаружения ошибок пользователей. Например, в бухгалтерском программном обеспечении номер счёта, введённый пользователем, может быть проверен с помощью алгоритма контрольной цифры. Это не позволит ввести номер счёта с опечаткой.
Заключение
Хотя poka-yoke представляет собой только концепцию, а не определённый набор инструментов, существуют различные принципы, которые мы можем применить к коду и процессу разработки, чтобы предотвратить ошибки или обнаружить их на раннем этапе. Очень часто эти механизмы будут специфичны для самого приложения и его бизнес-логики, но есть несколько простых методов и инструментов, которые можно использовать, чтобы сделать более надёжным любой код.
Главное – помнить, что, хотя мы хотим избежать ошибок в продакшне, они могут оказаться очень полезными в процессе разработки, и мы не должны бояться инициировать их как можно скорее, чтобы было легче их отслеживать. Эти ошибки могут быть сгенерированы либо самим кодом, либо отдельными процессами, которые выполняются отдельно от приложения и контролируют его извне.
Чтобы ещё больше уменьшить количество ошибок, мы должны стремиться к тому, чтобы public-интерфейсы нашего кода были максимально простыми и понятными.
Теги: Добавить метки
На страницах данного сайта часто можно встретить это название и интересным звучанием, но достаточно серьёзным значением. В настоящей статье мы разберём, что же такое Poka Yoke. В народе, термин Poka Yoke часто переводят как защита от дурака, что в свою очередь не лишено смысла.
Сам термин, как уже понятно из названия, пришёл из Японии. В своём первоначальном звучании: Boka Yoke, он как раз и означал «защита от дурака». Этим термином называли все простые устройства, которые препятствовали работнику (тому самому Boka) совершить ошибку. Со временем, из соображений политкорректности, эти устройства стали называться Poka Yoke. Суть от этого не поменялась и в настоящее время данный термин можно перевести как «защита от непреднамеренных ошибок». Под ошибкой понимается любое несоответствие: поломка (несоответствие в работе оборудования), дефект (несоответствие в и т.п.). Наиболее широкое распространение принцип получил в области качества.
В разделении по принципам, методам и инструментам , Poka Yoke относится скорее к принципам. Так как с точки зрения lean, Poka Yoke это не одно или несколько простых решений, предотвращающих ошибку. Это подход к исключению любых ошибок и .
Со временем, по мере развития принципа Poka Yoke, стало понятно, что не все ошибки можно предотвратить. Однако некоторые из них можно сделать более видимыми и обнаружить заранее. Принцип стал развиваться ещё и в этом направлении: предотвращая ошибку работник не производит дефект или не создаёт проблему, а быстро обнаруживая ошибку, работник не передаёт дефект и быстро реагирует на .
Разумеется, вряд ли можно найти такого работника, который сознательно совершает ошибки. Большинство ошибок происходят от отсутствия информации, от усталости, отсутствия возможности выполнить операцию иначе и т.д. Другими словами, процесс позволяет иметь место ошибке. Применение принципа Poka Yoke как раз и заключается в том, чтобы путём мелких улучшений и простых решений поправить процесс так, чтобы он обеспечивал правильный результат.
Особенность принципа заключается в том, что простые средства Poka Yoke должны находиться не в конце процесса, по факту оповещая о возникшей когда-то ошибке. Они должны находиться непосредственно в месте возникновения конкретной ошибки!
Например, на рисунке снизу изображён пример простого решения, в результате которого большие коробки не допускаются в ошибочное для них место.
Чтобы лучше понять суть работы принципа, приведём пару примеров.
Например, в детстве, ещё не слыша термина Poka Yoke, я легко собирал персональный компьютер, подключая к системному блоку монитор, мышь, клавиатуру и т.д. Принцип Poka Yoke в этом случае заключался в том, что каждый отдельный порт отличался друг от друга. Невозможно подсоединить кабель от принтера к разъёму от монитора. Даже два одинаковых порта: от мышки и клавиатуры раньше отличались цветами. Разумеется, производителям компьютерной техники проще было изготавливать одинаковые порты для всех устройств (это явно было бы дешевле), но к чему бы это привело?
Ещё один пример (см. рисунки ниже): установка наклейки на магнитолу можно было выполнить с ошибкой. После небольшой доработки вероятность возникновения такой ошибки практически исключена.
История появления системы «покэ-ека»
В 1961 году, анализируя производственную структуру предприятий «Yamaha Electric», Синго сформулировал метод бака-ёкэ (защита от дурака). Он пришел к выводу, что общепринятая система статистического контроля не предупреждает брака. Конечно, с ее помощью можно было предсказать степень вероятности появления очередного дефекта, однако это было бы лишь констатацией фактов. Синго решил внедрить элементы управления в сам процесс. Ведь брак появляется в результате ошибок людей. Ошибки, конечно же, неизбежны, но их можно предотвратить, создав станки и инструменты с обратной связью. Попытка неправильно вставить деталь мгновенно приводила к остановке работы. Тревожный сигнал поступал и в случае, когда работник забывал проделать какую-то операцию. После возникновения ошибки следовало ее выявление, идентификация и полное предотвращение возможности повторного возникновения. Таким образом, Сигэо Синго отделил причину от следствия -- ошибку от дефекта, гарантировав 100% качество продукции. Ведь проверка качества велась отныне не методом проб образцов на столе ОТК, а непосредственно у станка на всех без исключения изделиях. Результаты не замедлили сказаться. Например, в 1977 году производственные цеха компании «Matsushita Elecric», где была внедрена система Синго, в течение 7 месяцев работали без каких-либо дефектов. С. Синго стал по праву пользоваться на родине и за рубежом титулом «Мистер Улучшение».
Правда, название «защита от дурака» не удержалось. Однажды, когда Синго знакомил рабочих с новым методом, одна из работниц заплакала: «Я не дура!». Пришлось извиниться и дать методу новое название: система пока-ёкэ (защита от дефектов, или же 0-дефект). Эта система значительно повышает эффективность производственного процесса, способствуя уменьшению отходов, сокращению издержек и потерь времени.
Понятие метода «пока-ека»
В основе бездефектного производства лежит метод защиты от ошибок, получивший название покэ-ека (Poka-Yoke). Система «Пока-ека» на русский язык может быть переведена как «дуракоустойчивость».
Основная идея состоит в остановке процесса, как только обнаруживается дефект, определении причины и предотвращении возобновления источника дефекта. Поэтому не требуется никаких статистических выборок. Ключевая часть процедуры состоит в том, что инспектирование источника ошибки проводится как активная часть производственного процесса с целью выявления ошибок до того, как они становятся дефектами. Обнаружение ошибки или останавливает производство до ее исправления, или процесс корректируется, чтобы воспрепятствовать появлению дефекта. Это осуществляется на каждой стадии процесса путем мониторинга потенциальных источников ошибок. Таким образом, дефекты определяются и корректируются у самого их источника, а не на более поздних стадиях. Естественно, этот процесс стал возможным с применением инструментов и механизмов с немедленной обратной связью (в процессе избегают использовать персонал из-за его способности ошибаться). Однако использование персонала существенно для определения потенциальных источников ошибок. В 40-летнем возрасте Синго изучил и в значительной степени использовал статистические методы контроля качества, но спустя 20 лет, в 1977 г., он сказал, что наконец освободился от их колдовского очарования. Это случилось, когда он собственными глазами наблюдал, как на линии сборки сливных труб на заводе стиральных машин компании Мацускыта (Matsushita) в Сизуока (Shizuoka), на которой было занято 23 рабочих, удалось непрерывно работать без единого дефекта в течение месяца, благодаря установке устройств «Пока-Йеке», которые предотвращали появление дефектов. Синго утверждает, что бездефектности можно достигнуть путем использования контроля за источниками появления дефектов и системы «Пока-Йеке». Вместе они составляют "нулевой контроль качества (Zero Quality Control)".
Эта концепция "нуль дефектов" отличается от того, что обычно связывается с именем американского наставника Филипа Кросби. В концепции Синго делается упор на достижение бездефектности путем использования хорошей инженерной подготовки производства и исследования производственных процессов, а не с помощью призывов и лозунгов, которые ассоциируются с кампаниями качества, проводимыми американскими и западно-европейскими фирмами. Сам Синго, подобно Демингу и Джурану, демонстрирует озабоченность таким американским подходом, утверждая, что публикация статистики дефектов только вводит в заблуждение и что вместо этого необходимо охотиться за дефектными элементами производственного процесса, которые порождают большинство дефектов продукции.
Система «пока-ека» - основа бездефектного производства.
Дефекты в производстве по большей части возникают из-за увеличения вариабельности характеристик процесса, разброс которых, в свою очередь, может быть следствием:
ѕ некорректно разработанных стандартов или документированных процедур;
ѕ использования некачественного или устаревшего оборудования;
ѕ применения неподходящих материалов;
ѕ изношенности инструментов;
ѕ ошибок операторов.
Для всех этих причин дефектов, за исключением последней, могут быть применены корректирующие и предупреждающие действия. Предотвратить же ошибки операторов достаточно трудно.
В основе идеологии покэ-ека лежит тот факт, что совершать ошибки для людей в процессе работы - естественно. И это не является показателем непрофессионализма оператора. Цель покэ-ека - найти способы защиты от непреднамеренных ошибок. Перечень типичных действий операторов, приводящих к появлению дефектов представлен в таблице.
Метод покэ-ека базируется на семи принципах:
1 для создания эффективных процессов используйте робастное проектирование;
2 работайте в командах: только так можно максимально полно использовать знания сотрудников;
3 устраняйте ошибки, также используя робастное проектирование: это позволит приблизить число ошибок к нулю;
4 устраняйте коренные причины появления дефектов, применяя метод 5 "Why" (Пять "почему");
5 действуйте сразу, используйте все возможные ресурсы;
6 устраняйте деятельность, не добавляющую ценность;
7 внедряйте улучшения и сразу задумывайтесь над дальнейшими улучшениями.
Применяя покэ-ека не полагаются на то, что операторы сами найдут ошибку. Поэтому при выполнении работ используются сенсорные датчики и другие устройства. Это помогает эффективно выявлять дефекты, пропущенные операторами.
Метод покэ-ека следует применять как при входном контроле, так и в ходе всего процесса. Эффект от его внедрения зависит от того, на каком именно этапе процесса - входном контроле или контроле в ходе процесса - этот метод был использован. При этом, если несоответствия были выявлены, поступают предупреждающие сигналы или, даже, оборудование может быть остановлено.
Внедрение метода покэ-ека при входном контроле называют проактивным подходом. Выявление ошибки в таком случае произойдет до того, как были совершены те или иные операции, пользуются предупреждающие сигналы или даже, оборудование может быть остановлено на выходном контроле.
Подход, при котором метод покэ-ека применяется на других этапах производственного процесса, называют реактивным. В данном случае этот метод используется:
ѕ сразу по завершении процесса;
ѕ в ходе выполнения работ оператором;
ѕ при передаче на следующий этап процесса.
Реактивный подход является эффективным, так как его применение способствует предотвращению передачи бракованных изделий на следующий этап процесса, но, тем не менее, не позволяет достичь столь высокой степени защиты от ошибок, как в случае с проактивным подходом. Применение методов покэ-ека в процессе поиска причин возникновения дефектов не дает высоких результатов, но в то же время он гораздо эффективнее выборочного контроля.
Существуют другие подходы к использованию метода покэ-ека: контролирующий и предупреждающий. При контролирующем подходе, если выявляется дефект, - происходит автоматическая остановка оборудования. Предупреждающий подход основывается на применении всевозможных сигнальных средств (световые и звуковые сигналы), которые сообщают оператору о возможной ошибке. Остановка оборудования часто не входит опции предупреждающего подхода.
Устройства, применяемые в покэ-ека, по методу лежащему в основе их работы, подразделяются на:
ѕ контактные;
ѕ считывающие;
ѕ последовательного движения.
Все три типа устройств могут быть использованы как при контролирующем подходе, так и при предупреждающем.
Принцип работы устройств контактного метода основан на определении того, контактирует ли чувствительный элемент с проверяемым объектом. Примером таких устройств могут служить концевые выключатели. Если контакт нарушается, то срабатывает, например, звуковой сигнал.
Также к устройствам, работающим по контактному методу, относят передатчики и приемники, фотоэлектрические выключатели, пьезоэлектрические датчики и др. Устройства не обязательно должны быть высокотехнологичными. Простые пассивные устройства иногда являются самыми лучшими. Они не позволяют занять детали неправильное положение в ходе процесса.
Считывающие устройства применяются, когда существует фиксированное число операций в процессе и фиксированное число деталей в изделии. Датчик несколько раз просчитывает детали и пропускает изделие на следующий процесс только, если число деталей верно.
Третий тип устройств - датчики, определяющие выполнена ли операция процесса. Если операция не выполнена или выполнена неверно, то датчик сигнализирует, что следует остановить оборудование. По такому принципу работают многие сенсорные и фотоэлектрические устройства, которые связаны с таймером оборудования. Применение таких устройств наиболее эффективно, когда в процессе используются много деталей похожих друг на друга по форме и размеру.
Последовательное применение метода покэ-ека позволяет значительно сократить число ошибок, допускаемых операторами, что способствует снижению затрат и повышению удовлетворенности потребителей.
Курсовой проект по дисциплине
«Средства и методы управления качеством»
(заочная форма обучения)
Требования к выполнению
(Примерный объем: 20-30 страниц (без учета приложений по сертификации СМК), формат бумаги А4, размер шрифта 14 (Times New Roman), междустрочный интервал – 1.)
Введение (0,5 – 1страница).
Теоретическая часть
1. Управление. Качество как объект управления
2. Краткая характеристика действующих версий стандартов ISO серии 9000 (9000, 9001, 9004).
3. Теоретические аспекты применения средств и методов управления качеством, необходимые для выполнения раздела 2 работы (кратко, основные положения и этапы).
3.1 Миссия предприятия.
3.2 Цели предприятия.
3.3 Теоретические основы проведения SWOT-анализа и PEST-анализа.
3.4 Теоретические основы определения параметров качества и оценки качества продукта/услуги.
3.5 Теоретические основы проведения FMEA-анализа.
3.6 Теоретические основы построение схемы Исикава.
3.7 Теоретические основы построения диаграммы Парето.
3.8 Общая характеристика концепции Бережливое производство
3.9 Теоретические основы применения метода «Poka-Yoke»
Практическая часть
1 . Краткая характеристика предприятия . Дайте характеристику предприятия, включая следующую информацию: история, организационная структура, направления деятельности, ассортимент и особенности производимой продукции/оказываемых услуг, информация о системе менеджмента качества (при наличии), описание подразделения (подразделений), занимающихся вопросами качества, перспективы и стратегия развития).
2 . Миссия предприятия. Сформулируйте миссию выбранного предприятия.
3. Цели предприятия.
3.1 Разработайте иерархическую структуру целей, в зависимости от организационной структуры, с указанием целей роста предприятия, в соответствии с ключевыми требованиями. Укажите ответственных исполнителей подразделения предприятия за реализацию этих целей. Полученные результаты занесите в таблицу 1.
Таблица 1. Матрица целей компании
3.2 Постройте дерево целей на период в один год, стоящих перед руководством компании для успешного выполнения миссии (рис 1).
Рис. 1 Упрощенное структурное представление дерева целей
4. SWOT/ PEST анализ
Проведите SWOT (или PEST, на выбор) анализ предприятия. Заполните соответствующую матрицу по результатам анализа.
Сформулируйте выводы по результатам анализа. Разработайте рекомендации предприятию на основе результатов анализа.
5. Характеристика параметров качества продукта/услуги.
Выберите продукт/услугу для проведения анализа. Опишите перечень параметров качества продукта (услуги) и требования к ним.
6. FMEA-анализ
Для выполнения данного раздела используется информация о выбранном в разделе 5 изделии/услуге.
6.1 Определите перечень потенциальных дефектов (несоответствий) выбранного в разделе 5 изделия (услуги). Для каждого потенциального дефекта определить перечень последствий. Определите комплексный показатель S, характеризующий общий уровень всех последствий каждого потенциального дефекта (несоответствия) для потребителя, по 10-балльной шкале (1-минимальный уровень последствий или их отсутствие, 10 – максимальный уровень последствий).
6.2 Для каждого дефекта определите перечень потенциальных причин. Для одного дефекта может быть выявлено несколько потенциальных причин. Для каждой причины дефекта определите O, вероятность ее возникновения, по 10-балльной шкале (1-возникновение маловероятно, 10 – возникновение неизбежно).
6.3 Для каждого потенциального дефекта и каждой потенциальной причины определите балл сложности обнаружения D по 10-балльной шкале (10 – практически не обнаруживаемый дефект, 1 – достоверно обнаруживаемый дефект).
6.4. Для каждого потенциального дефекта и каждой потенциальной причины рассчитайте приоритетное число риска ПЧР по формуле (1). ПЧР может принимать значения от 1 до 1000. Заполните таблицу 2.
ПЧР =S*O*D (1)
ПЧР - приоритетное число риска;
S - степень последствий потенциального дефекта;
О - Вероятность возникновения
Таблица 2. Потенциальные дефекты (несоответствия) изделия (услуги) ___________________
| № п/п | S Степень последствий по 10-балльной шкале (1-минимальный уровень, 10 – максимальный) | O Вероятность возникновения по 10-балльной шкале (1-возникновение маловероятно, 10 – возникновение неизбежно) | D Сложность обнаружения по 10-балльной шкале (10 – практически не обнаруживаемый дефект, 1 – достоверно обнаруживаемый дефект). | ПЧР | |||
| 1.1 | 1.1.1 | ||||||
| 1.1.2 | |||||||
| … | |||||||
| 1.2 … | 1.2.1 | ||||||
| 1.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| 2.1 | 2.1.1 | ||||||
| 2.1.2 | |||||||
| … | |||||||
| 2.2 | 2.2.1 | ||||||
| 2.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| … |
6.5 Составьте перечень дефектов/причин, по который значение ПЧР превышает 100 (максимально допустимый уровень ПЧР).
6.6 Для составленного перечня разработайте предупреждающие мероприятия, включающие:
Меры по снижению степени последствий дефекта (несоответствия) S ;
Меры по предотвращению причин потенциального несоответствия O;
Меры по повышению степени достоверности обнаружения дефекта D;
Заполните таблицу 3.
Таблица 3. Мероприятия по предупреждению потенциальных дефектов, ПЧР которых превышает 100 (допустимое значение).
| № п/п | Потенциальные дефекты (несоответствия) | Перечень потенциальных последствий дефекта (несоответствия) | Потенциальные причины дефекта (несоответствия) | ПЧР | Предупреждающие мероприятия | ||
| Меры по снижению степени последствий дефекта (несоответствия) S | Меры по предотвращению причин потенциального несоответствия O | Меры по повышению степени достоверности обнаружения дефекта D | |||||
| 1.1 | 1.1.1 | ||||||
| 1.1.2 | |||||||
| … | |||||||
| 1.2 … | 1.2.1 | ||||||
| 1.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| 2.1 | 2.1.1 | ||||||
| 2.1.2 | |||||||
| … | |||||||
| 2.2 | 2.2.1 | ||||||
| 2.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| … |
7. «Простые методы» управления качеством (схема Исикава, диаграмма Парето).
Схема Исикава
Проведите анализ причин брака выбранного изделия/услуги. Заполнить таблицу 5.
Таблица 4. Причины брака изделия/услуги ___________________
| Категории причин | Причины 1 порядка | Причины 2 порядка | Причины 3 порядка |
| 1. | 1.1 | 1.1.1 | 1.1.1.1 |
| 1.1.12 | |||
| 1.1.1.3 | |||
| 1.1.2 | 1.1.2.1 | ||
| 1.1.2.2 | |||
| 1.1.2.3 | |||
| 1.1.3 | 1.1.3.1 | ||
| 1.1.3.2 | |||
| 1.1.3.3 | |||
| … | … | ||
| 1.2 | 1.2.1 | 1.2.1.1 | |
| 1.2.1.2 | |||
| 1.2.1.3 | |||
| 1.2.2 | 1.2.2.1 | ||
| 1.2.2.2 | |||
| 1.2.2.3 | |||
| 1.2.3 | 1.2.3.1 | ||
| 1.2.3.2 | |||
| 1.2.3.3 | |||
| … | … | ||
| 1.3 | 1.3.1 | 1.3.1.1 | |
| 1.3.1.2 | |||
| 1.3.1.3 | |||
| 1.3.2 | 1.3.2.1 | ||
| 1.3.2.2 | |||
| 1.3.2.3 | |||
| 1.3.3 | 1.3.3.1 | ||
| 1.3.3.2 | |||
| 1.3.3.3 | |||
| … | … | ||
| … | |||
Постройте схему Исикава, отобразив на ней данные таблицы 4.
Сделайте и опишите выводы по результатам ее анализа.
Диаграмма Парето
7.2.1 Проведите анализ схемы Исикава с помощью диаграммы Парето- выберите наиболее значимые причины, приводящие к 80% брака изделия/услуги, на решении которых необходимо сконцентрироваться. Для этого необходимо построить таблицу 5. Основой для построения таблицы 5 является последний столбец таблицы 4 – причины последнего (2-го, 3-го …n-го порядка, выявленные при анализе причин брака изделия/услуги)
Таблица 5. Причины брака изделия/услуги ___________________
| Оценка каждой причины по 10-балльной шкале с точки зрения степени ее влияния на поселение брака (10- максимальная степень, 1- минимальная степень) | |
| 1.1.1.1 | |
| 1.1.12 | |
| 1.1.1.3 | |
| 1.1.2.1 | |
| 1.1.2.2 | |
| 1.1.2.3 | |
| 1.1.3.1 | |
| 1.1.3.2 | |
| 1.1.3.3 | |
| … | |
| 1.2.1.1 | |
| 1.2.1.2 | |
| 1.2.1.3 | |
| 1.2.2.1 | |
| 1.2.2.2 | |
| 1.2.2.3 | |
| 1.2.3.1 | |
| 1.2.3.2 | |
| 1.2.3.3 | |
| … | |
| 1.3.1.1 | |
| 1.3.1.2 | |
| 1.3.1.3 | |
| 1.3.2.1 | |
| 1.3.2.2 | |
| 1.3.2.3 | |
| 1.3.3.1 | |
| 1.3.3.2 | |
| 1.3.3.3 | |
| … | |
Таблица 6. Данные для построения диаграммы Парето при анализе брака изделия/услуги ___________________
| Причины n-го (последнего) порядка | Оценка каждой причины по 10-балльной шкале (из таблицы 4), проранжированные в порядке убывания значимости | Вес (значимость) каждой причины, % | Кумулятивный вес (значимость) каждой причины, % |
| 1.1.1.1 | |||
| 1.1.12 | |||
| 1.1.1.3 | |||
| 1.1.2.1 | |||
| 1.1.2.2 | |||
| 1.1.2.3 | |||
| 1.1.3.1 | |||
| 1.1.3.2 | |||
| 1.1.3.3 | |||
| … | |||
| 1.2.1.1 | |||
| 1.2.1.2 | |||
| 1.2.1.3 | |||
| 1.2.2.1 | |||
| 1.2.2.2 | |||
| 1.2.2.3 | |||
| 1.2.3.1 | |||
| 1.2.3.2 | |||
| 1.2.3.3 | |||
| … | |||
| 1.3.1.1 | |||
| 1.3.1.2 | |||
| 1.3.1.3 | |||
| 1.3.2.1 | |||
| 1.3.2.2 | |||
| 1.3.2.3 | |||
| 1.3.3.1 | |||
| 1.3.3.2 | |||
| 1.3.3.3 | |||
| … | |||
| ИТОГО | 100% |
7.2.3 Постройте диаграмму Парето по данным таблицы 6, определите графически причины, вызывающие 80% брака.
Проведите анализ диаграммы Парето, сделайте выводы. Разработайте корректирующие/предупреждающие мероприятия по устранению/предупреждению каждой из причин.
Применение методологии Poka-Yoke (Концепция «Бережливое производство»)
Для выполнения данного пункта используется сформированный в п. 6.5 перечень дефектов/причин, по который значение ПЧР превышает 100 (максимально допустимый уровень ПЧР), а также частично – данные таблиц 2 и 3.
8.1 Определите степень приоритетности проблем – проранжируйте их в соответствии с расчетным уровнем ПЧР
8.2 Заполните таблицу 7.
Таблица 7. Применение методологии Poka-Yoke для защиты от потенциальных несоответствий с уровнем ПЧР>100
Заключение (0,5 – 1страница).
