Poka-Yoke, або Захист від дурня

Всім привіт! Мене звати Денис Шматков. Я працюю PMO Competency Manager в Eleks. Уже кілька років ділюсь своїм досвідом на різних платформах (ютуб, подкаст, курси тощо). Зараз разом з Орестом Дмитрасевичем запустили платформу Kaizen — для розвитку лідерів. Один з проєктів — це подкаст «Майже Вчасно»!

У цій статті пропоную познайомитися з методом Poka-Yoke. Назва менш відома ніж Lean або Kanban, але ми натрапляємо на цей метод кожного дня. Якщо простими словами — це інструмент захисту від дурня. Перейдемо трохи до історії та деталей.

Що таке Poka-Yoke

Poka-Yoke — це японська стратегія безперервного вдосконалення, заснована на концепції захисту від помилок або запобігання помилкам ще до того, як вони виникнуть.

Термін Poka-Yoke походить від японського Baka-Yoke, що означає «захист від ідіотів», який було визнано образливим для персоналу та замінено на Poka-Yoke — «захист від помилок».

Хто придумав Poka-Yoke

Poka-Yoke розроблений японським інженером Сінґо Сіґео (Shigeo Shingo) в 1960-х роках в корпорації Toyota. До речі, цей поважний пан є одним із засновників виробничої системи Toyota, а також системи SMED і моделі Сінґо. Основна ідея Poka-Yoke полягає в тому, щоб уникнути виникнення помилок або знизити їхню імовірність шляхом впровадження спеціальних механізмів або перевірок у процесі виробництва.

Під час відвідування виробничого підприємства на початку 1960-х років Сінґо зауважив, що працівники пропустили додавання пружин до основного вимикача, що призвело до виготовлення та відправлення несправних деталей.

Помітивши цю просту людську помилку, Сінґо почав шукати шляхи вдосконалення та переналаштування процесу так, щоб операція не могла тривати, доки пружина не буде вставлена ​​в перемикач. Це і вважається першим випадком реалізації принципів Poka-Yoke.

Чому Poka-Yoke важливий для виробництва

Poka-Yoke є важливою частиною системи ощадливого виробництва (lean manufacturing), основною метою якої є усунення відходів, постійне вдосконалення та додавання вартості. Ми розв’язуємо проблеми споживачів, одночасно зменшуючи витрати виробників; а концепції економічного використання, такі як Poka-Yoke, є простими інструментами, які легко реалізувати.

Виробники використовують методи Poka-Yoke для вдосконалення дизайну продукту та процесів його виробництва. Процес безперервного вдосконалення допомагає усунути людські та механічні помилки, отримати правильні продукти з першого разу та зменшити кількість спроб і вартість помилок.

Різні виробники охоче почали використовувати Poka-Yoke завдяки його гнучкості та економічній ефективності. Це дало змогу запобігти помилкам в процесах з невеликими витратами, водночас підвищуючи якість і надійність своєї продукції за рахунок зменшення кількості дефектів.

Ключові принципи Poka-Yoke

  • Виявлення помилки. Першим кроком є розпізнавання помилок у виробничому процесі. Це може стосуватися таких помилок: неправильне збирання, помилкове розміщення компонентів або налаштування обладнання.
  • Попередження про помилку. Наступним етапом є розробка та впровадження механізмів, які автоматично виявляють, сигналізують або блокують помилки. Ці механізми можуть бути фізичними або програмними засобами, призначеними для попередження працівників про помилку.
  • Виправлення помилки. У разі, якщо помилка все ж таки відбулася, важливо, щоб вона могла бути виправлена з легкістю і без збитків для виробництва. Наприклад, це можливість легко розібрати та зібрати продукт для усунення дефекту.

В основі цих принципів лежить fail-safe метод. Його суть у тому, що у випадку певного типу помилки чи відмови система реагувала так, щоб завдати мінімальної шкоди або не завдати шкоди взагалі іншому обладнанню, навколишньому середовищу чи людям.

Приклади застосування Poka-Yoke

Toyota і Poka-Yoke:

Toyota, відомий виробник автомобілів, популяризувала концепцію Poka-Yoke і широко використовувала її у своїх виробничих процесах. Вони розробили прості, але ефективні методи, такі як використання кольорового кодування та надійних механізмів, щоб запобігти помилкам і дефектам під час збірки. Це значно зміцнило їхню репутацію як високоякісних автомобілів.
  • Приклад кольорового кодування.
    При збірці гібридних автомобілів, таких як Toyota Prius, батареї грають важливу роль. Батареї складаються з великої кількості ідентичних елементів, які необхідно встановити в правильному порядку та з правильною полярністю. Це може створити ризик помилки під час збирання. Для уникнення цього роду помилок, Toyota використовує кольорове кодування: кожен елемент батареї має свій унікальний колір або маркування, яке вказує на його положення та полярність. Монтажники можуть легко розрізнити елементи за кольором та маркуванням, що робить процес збирання більш точним та зменшує ризик помилок.
  • Приклад надійних механізмів.
    Перед тим як батарея буде остаточно закрита та герметично запаяна, встановлюють датчики, які перевіряють наявність та правильне розташування елементів. Якщо датчики виявлять невідповідність, система автоматично зупинить процес збирання, надаючи операторам можливість виправити помилку.

Захист від помилок в системі охорони здоров’я

Метод Poka-Yoke застосовується в медичних закладах для зменшення медичних помилок і підвищення безпеки пацієнтів. Наприклад, системи введення ліків зі штрих-кодами та сканерами можуть гарантувати, що пацієнту призначають відповідні ліки, мінімізуючи ризик помилок при лікуванні.

Poka-Yoke у розробці програмного забезпечення

  • Метод Poka-Yoke можна використовувати для виявлення помилок кодування на ранній стадії. Інструменти аналізу коду та автоматизовані тести можуть виявити потенційні помилки, наприклад синтаксичні або логічні, перш ніж вони спричинять серйозні проблеми. Це призводить до створення надійніших програмних систем.
  • Системи резервного копіювання можуть бути налаштовані так, щоб автоматично виконувати регулярні резервні копії даних. Це запобігає втраті даних у разі аварії та забезпечує їх відновлення.
  • Системи контролю версій дозволяють відстежувати зміни в коді програми та спільно працювати над ним. Унаслідок цього — потенційне уникнення конфліктів у коді та злагоджена спільна робота розробників.
  • Використання автоматичних сповіщень може допомогти вчасно виявляти та реагувати на критичні проблеми, такі як падіння серверів або порушення безпеки.
  • Застосування інструментів для управління конфігураціями допомагає контролювати зміни в інфраструктурі та програмному забезпеченні, гарантуючи стабільність та відсутність несподіваних помилок

Poka-Yoke у сферах послуг

Poka-Yoke не обмежується виробництвом, його застосовують і у сфері послуг. Наприклад, онлайн-перевірка форм на вебсайтах допомагає користувачам вводити точні дані, зменшуючи помилки та покращуючи взаємодію з сервісом. Системи самообслуговування в супермаркетах використовують датчики ваги, щоб переконатися, що всі товари були проскановані та оплачені до того, як клієнти покинуть магазин.

Чим Poka-Yoke може бути корисним для керівників проєктів

  1. Планування проєкту на основі контрольних списків: керівники проєктів можуть створювати контрольні списки або шаблони. Ці контрольні списки містять важливі етапи, завдання та показники результатів і гарантують, що нічого не буде пропущено чи забуто. Дотримуючись стандартизованого контрольного списку, керівники проєктів зменшують ризик помилок і забезпечують узгоджену практику управління проєктами.
  2. Виявлення та пом’якшення ризиків: Poka-Yoke може допомогти визначити та пом’якшити ризики на ранніх стадіях проєкту. Упроваджуючи методи управління ризиками, такі як проведення ретельної оцінки ризиків, використання історичних даних і залучення членів команди до процесу, менеджери зможуть своєчасно почати працювати з потенційними підводними каміннями. Такий підхід зменшує ймовірність затримок, перевитрат коштів та інших негативних наслідків.
  3. Чітка комунікація та документація: ефективна комунікація має вирішальне значення для успіху. Принципи Poka-Yoke підкреслюють важливість чіткого та недвозначного спілкування. Менеджери, забезпечуючи точне документування вимог, цілей і очікувань проєкту та надаючи їх усім відповідним зацікавленим сторонам, зменшують ймовірність непорозумінь та потенційних переробок у проєкті.
  4. Стандартизовані інструменти та процеси управління проєктами: їх упровадження є ще одним способом застосування принципів Poka-Yoke. Наприклад, використання програмного забезпечення для керування проєктами, яке пропонує вбудовану перевірку якості та сповіщення про помилки, може допомогти керівникам виявити невідповідності, залежності або конфлікти планування. Це дозволяє їм оперативно вживати коригувальних заходів, мінімізуючи ризик зриву.
  5. Отримані уроки та постійне вдосконалення: Poka-Yoke заохочує культуру постійного вдосконалення. Менеджери можуть сприяти післяпроєктному аналізу, щоб зафіксувати отримані уроки та визначити області для покращення. Використовуючи цю інформацію в майбутніх проєктах, менеджери зможуть запобігти повторенню помилок, оптимізувати процеси та покращити загальну практику управління в компанії.

Висновки

Застосування Poka-Yoke може надати величезні переваги не тільки для компанії, а і для працівників:

  • по-перше, це допоможе знизити кількість відбракованих товарів та додаткових витрат на перероблення або повернення;
  • по-друге, уникнення помилок підвищує якість продукції, як результат — задоволеність клієнтів та підвищення довіри до бренду компанії.
  • по-третє, Poka-Yoke сприяє оптимізації виробничих процесів, адже виявлені проблеми можуть бути виправлені на ранніх стадіях, а це, відповідно, допамагає уникнути масштабних проблем у майбутньому.

Ефективне впровадження системи Poka-Yoke в наших проєктах допоможе розв’язати проблему людських помилок та забезпечити більш ефективний та продуктивний процес роботи з фокусом на результат. Для менеджерів це надзвичайно важливо, оскільки ми маємо за мету постійне удосконалення процесів та створення сприятливого середовища для розробки та успішного впровадження нових механізмів Poka-Yoke в робочому потоці.

Якщо вам буде цікаво дізнатись більше про Poka-Yoke і його застосування в житті, запрошую послухати один з епізодів нашого подкасту «Майже Вчасно» — «Poka-Yoke або Захист від дурня».

Пам’ятайте, що успіх полягає у відданості якості та сталому поліпшенню, і Poka-Yoke може стати цінним інструментом для досягнення цих цілей!

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В наші часи це називалося «захист від дурня»

Побачивши що це вигадали Японці дуже хотілось у тексті знайти де ж там про харакірі

знову «здоровий глузд» називають якимось дивним словом )))

А як тоді продавати «здоровий глузд» за великі гроші?)

це формалізація абстрактного «здоровий глузд»

Інструменти аналізу коду та автоматизовані тести можуть виявити потенційні помилки, наприклад синтаксичні або логічні, перш ніж вони спричинять серйозні проблеми

І до яких таких проблем приводять синтаксичні помилки?
І як цікаво аналізатор коду виявить проблему у логіці?

І до яких таких проблем приводять синтаксичні помилки?

ну, именно «синтаксические» проблемы могут появится, видимо, только в случае применения динамического когда, однако корявый синтаксис нередко приводит к проблемам
К примеру, классическое сишное if(a=0) {....} из за чего все вменяемые сишники пишут if(0==a) {....}
вот єто if(0==a);{........}
во многих языках это можно встречтить в той или иной мере

І як цікаво аналізатор коду виявить проблему у логіці?

Если взять, скажем, т-скл, то можно найти проблему тут
select * from Master m left join Slave l on m.id = l.MasterId
where l.Qty > 10
тот же шарп (чтоб он был трижды проклят в данном случае) ругается на code unreachable, not all code paths returns the value и так далее — а єто свидетельство (зачастую) проблем в логике (не всегда, конечно, но зачастую)

Щось не зрозуміло. Що не так із запитом що має збудитися статичний аналізатор? До чого тут C# и code unreachable / not all code paths ... (які, до речи, є жорсткими помилками, а не попередженнями).

Щось не зрозуміло. Що не так із запитом що має збудитися статичний аналізатор?

Ну, тут иннер джойн, хотя хотели лефт джойн. Я не думаю что это намеренное, а не ошибочное поведение.

До чого тут C# и code unreachable / not all code paths ...

Если ві написали код, и внезапно оказівается, что часть єтого кода недоступна (а єта часть кода видимо делает что-то полезная) — то ві где-то профукали точки входа в єти блоки — а следовательно у вас ошибка в логике программі

(які, до речи, є жорсткими помилками, а не попередженнями)

Да, и иногда єто ОЧЕНЬ бесит и мешает, я хотел бы чтобы при дебаге, к примеру, это были предупреждения.

Що не так із запитом

вдогонку, одно из любимых — select * from tab1, tab2 where a=b

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

Люди делятся на две категории: те, кто уже делает бекап, и те, кто будет делать бекап.

С опытом приходит 3я категория — «те кто пробует эти бэкапы восстановить» и 4я «те, кто после восстановления проверяет целостность данных в базе» ©

Вообще, бекапы в коммерческих проектах — это вчерашний день. Просто использовал крылатую фразу.

Вообще, бекапы в коммерческих проектах — это вчерашний день

А что «сегодняшний день»? «Я потерял все данніе и меня вігнали с вольчим билетом на мороз»?

Для БД репликация, для файлов пользователей — синхронизируемые хранилища с дисками чётности, для файлов проекта — репозиторий и конфигурация быстрого развёртывания. А с игрушками типа кубернетес вообще можно спокойно спать если сервак упал: до утра подождёт, другой сервер подхватит его роль.

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

Для БД репликация, для файлов пользователей — синхронизируемые хранилища с дисками чётности, для файлов проекта — репозиторий и конфигурация быстрого развёртывания.

ага, т.е. я біл прав «на мороз»

с одной стороні єто хорошо — услуги нормальніх админов будут ценится больше
с другой стороні — есть опасение — а вдруг мой банк обслуживается админом, которій не делает резервніх копий?

зі история из прошлого
я как-то пообщался (длительное время) на одном из форумов — с разработчиками ПО для банков. После єтого года 3, наверное, я (по зачислении ЗП) сразу снимал её налом всю, в кассе (не в банкомате).

В итоге ни один банк не закрылся из-за проблем с ПО, но зато их убила администрация Порошенко — вот уж яркий пример ситуации, когда не знаешь заранее где перину стелить и Poka-Yoke внедрять ))

Для объёмов транзакций банка, даже среднего, спустя десять лет работы полный бекап будет разворачиваться от 4 часов и дольше. Суммы недополученной прибыли за это время превысят годовую зарплату сисадмина, как минимум. Потому это инструмент последней надежды, когда других вариантов не осталось.

Если помните атаку вирусом Petya в 2017 году, то как раз все, кто полагался на бекапы, лежали два-три дня, а некоторые до недели. А приватбанк свою сеть банкоматов по всей Украине (около 7000 на то время) восстановил менее, чем за 12 часов, потому что использовали протокол автоматизированного развёртывания.

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

но зато их убила администрация Порошенко

Єто вам в политику, а не в контроль качества в айти

Для объёмов транзакций банка, даже среднего, спустя десять лет работы полный бекап будет разворачиваться от 4 часов и дольше.

Именно поєтому опытные архитекторы изнанчально закладывают секционирование, архивирование и тому подобные решения в систему

Потому это инструмент последней надежды, когда других вариантов не осталось.

Вот видите, вы и сами понимаете, что резервные копии — нужны, т.к. это «инструмент последней надежды», оби ван кеноби мира информационных систем.
но почему-то упорно спорите со мной. Не надо так.

Если помните атаку вирусом Petya в 2017 году, то как раз все, кто полагался на бекапы, лежали два-три дня, а некоторые до недели.

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

А приватбанк свою сеть банкоматов по всей Украине (около 7000 на то время) восстановил менее, чем за 12 часов, потому что использовали протокол автоматизированного развёртывания.

Совершенно верно. у них есть «протокол» — т.е. набор инструкций, правил и чеклистов.
Ну и плюс всё к ним прилагаюзщееся

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

Ога. И всё это не спасает, к примеру, от ошибок ПО, от намеренной или случайно порчи данных — ну и так далее.

то, что вы предлагаете, это «а давайте возложим функции резервного копирования на RAID1».

Вы путаете «Доступность» и «надежность»
То что вы упоминаете — ноды, кластера, етк — есть обеспечение «доступности», т.е. уменьшение количества времени, которое понадобится на воссстановление системы в случае сбоя.
Да, если одна нода падает, то вроде бы у нас есть работающая другая — но она уже а) ненадежна по определению и б) с неё всё равно надо делать резервные копии (в том же скуле есть вариант делать резервные копии со вторичной ноды, чтобы не нагружать основную)

А вот резервные копии есть обеспечение «надежности», т.е. обеспечение восстановления данных в случае сбоя
И я (да и любой ДБА) может обеспечить доступность при помощи надежности, а вот надежность при помощи доступности — это врядли.
при помощи одних только резервных копий можно добится времени восстановления системы на вторичном сервере в, скажем, 10-15 минут (ну это конечно надо иметь админа под рукой или набор скриптов).
Да и по сути все «ноды-кластера-етк» есть тот или иной способ (а)синхронной доставки и применения резервных копий с первичного сервера на вторичный.

Да и по сути все «ноды-кластера-етк» есть тот или иной способ (а)синхронной доставки и применения резервных копий с первичного сервера на вторичный.

На этом можно считать, что консенсус достигнут ;)

я вообще не помню тогда проблем с приватом, может просто не пользовался банкоматом так часто.
те, кого вообще не задело или почти не задело, либо с какой-то регулярностью таки апдейтились, а патч дыры в SMB был выпущен более квартала раньше начала атаки, либо 3rd party типа медка запускали под сервис-аккаунтом, а не под энтерпрайз/домен админом, позволяющим зловреду сразу читнуть сервера из AD, не запуская скан сети. Либо и то и другое. Что также, в той или иной мере, реализация принципов из статьи.

Ещё не задело тех, у кого всё построено на Unix-системах.

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

«Захист від дурня» — це зробити умовну кнопку неактивною, якщо зараз її не можна / не треба натискати. А кольорова ідентифікація — це зробити цю кнопку яскраво червоною, сигналізуючи цим про небезпеку, але все ще залишаючи можливість для «дурня».

Зробити всі батареї різного розміру — це захист від дурня, бо зібрати неправильно тупо не вийде фізично. А контролювати щось там датчиками — це звичайний Quality Assurance

Короче в статті шось намішано теплого з мʼяким, попахує Chat-GPTщиной

«Контролювати щось там датчиками» це quality control😉.
Навіть поняття таке є від Quality control до Quality Assurance.

Я б сказав що Poka Yoke — це інструмент ближче до quality assurance.
Безперервне покращення або постійне вдосконалення називається Kaizen.
Приклад із різними кольорами батарейок це відноситься до інструменту visual management. Тобто, фактично помилку можна зробити але її буде легко ідентифікувати.

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі