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

Это рефлекс. Вы не доверяете своему мозгу, потому что знаете: мозг может отвлечься, задуматься, «залагать». Вы используете физическую проверку. В бизнесе мы почему-то ведем себя иначе. Мы нанимаем живых людей, даем им сложные инструменты (CRM, ERP, админки сайтов) и надеемся на их «ответственность». А когда менеджер отправляет счет с лишним нулем или удаляет базу клиентов, мы кричим: «Ну как так можно! Будь внимательнее!»

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

Термин Poka-yoke (пока-ёкэ) родился на заводах Toyota в 1960-х. Его придумал инженер Сигео Синго. Изначально он назвал концепцию Baka-yoke — «защита от дурака» (или даже грубее — «от идиота»).
Но рабочие обиделись. Никто не хочет чувствовать себя идиотом, за которым нужно подтирать ошибки. Синго понял психологию и сменил название на Poka-yoke — «защита от непреднамеренной ошибки».

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

Вы видите это каждый день:

Но в IT и бизнесе мы часто игнорируем эти принципы. И это стоит дорого.

Если вы думаете, что Poka-yoke — это только про заводы, вспомните историю японской компании Mizuho Securities.

В декабре 2005 года трейдер компании должен был продать 1 акцию компании J-Com за 610 000 иен. Вместо этого он ввел приказ продать 610 000 акций за 1 иену.

Это классическая ошибка «толстого пальца» (fat finger error). Трейдер попытался отменить операцию, но... система Токийской биржи не дала этого сделать. В ней просто не было функции «отмены» для ордеров после их исполнения, и не было лимитов на абсурдность сделки (Poka-yoke отсутствовал).

Итог: компания потеряла $225 млн за пару минут. Просто потому, что в интерфейсе не было всплывающего окна: «Чувак, ты реально продаешь полмиллиона акций за копейки?».

Мы занимаемся внедрением CRM и ERP систем. И для нас интерфейс — это не «красивые кнопочки». Это жесткий коридор, по которому мы ведем пользователя к деньгам.

Я называю этот подход «цифровые тиски». Звучит, возможно, авторитарно, но в хаосе операционки это спасение. Мы не надеемся, что сотрудник захочет сделать правильно. Мы делаем так, что неправильно сделать нельзя.

У нас жесткое правило: мы работаем только с B2B. Нам не нужны сделки с контактом «Иван 8917...». Нам нужны компании, ИНН, реквизиты.

В нашей CRM настроен Poka-yoke: менеджер технически не может перетащить сделку на этап «Защита Коммерческого Предложения», если в карточке не заполнены поля «Компания» и «Контакты ЛПР». Кнопка перехода просто серая. Она не нажимается.

Система говорит: "Сначала заполни данные, потом иди продавать". Это исключает ситуацию, когда мы тратим часы юристов на подготовку договора для «ООО Ромашка», которого даже не существует.

В проектном управлении главная беда — начать работу без четкого ТЗ.
«Ну давайте начнем, а там разберемся». В итоге — срыв сроков и убытки.

Мы внедрили поле «Паспорт проекта» (ссылка на утвержденный документ).
Статус проекта нельзя перевести в «В работе», пока это поле пустое.
Нет паспорта — нет старта. Система блокирует энтузиазм менеджера, заставляя его сначала заняться бюрократией (которая, как мы помним, мать порядка).

Я увлекаюсь 3D-печатью и даже планирую микро-производство. Там принцип Poka-yoke виден наглядно.

Если стол принтера не откалиброван (стоит криво), деталь превратится в пластиковую вермишель. Современные принтеры имеют датчики автокалибровки. Перед печатью они «тыкаются» в стол, проверяют горизонт и сами вносят поправки.

В бизнесе ваши бизнес-процессы — это «стол». Если он кривой (нет регламента, нет данных), результат будет бракованным. Poka-yoke в CRM — это и есть та самая автокалибровка, которая не дает запустить «печать» (сделку), пока условия не идеальны.

Как понять, где ставить эти «блоки»? Сидя в кабинете директора, этого не придумаешь. Вы слишком хорошо знаете свой продукт, у вас «замылен глаз».

Нужно идти «в поля». Мы используем элементы CustDev и подход JTBD (Jobs To Be Done), но с фокусом на ошибки.

Как мы это делаем:

1.Shadowing («Тень»): я или бизнес-аналитик садимся рядом с менеджером (или подключаемся к демонстрации экрана) и просим: «Просто поработай час как обычно. Я буду молчать»

2.Поиск фрустрации: мы не слушаем, что он говорит. Мы смотрим, где он «тупит».

• Где он завис мышкой на 5 секунд? (Значит, интерфейс непонятен).
• Где он открыл Excel или калькулятор? (Значит, CRM не считает сама — это дыра).
• Где он случайно нажал «Назад» и выругался, потому что данные слетели?

3.Тест на младенца: хороший интерфейс должен быть понятен без инструкции. Если вы нанимаете нового сотрудника, и вам нужно 2 недели учить его, куда нажимать в 1С или Битрикс24 — ваша система провалила тест Poka-yoke.

Кнопки «Удалить» и «Сохранить» не должны быть рядом. Опасные действия должны требовать подтверждения («Напишите УДАЛИТЬ, чтобы подтвердить»)

Не обязательно переписывать весь софт. Начните с малого.