Что же именно исчезает вместе с ручной проверкой? Один из «скрытых» слоёв ручной проверки часто становится виден только после автоматизации. Например, есть две заявки на одинаковый товар от одного подразделения, с доставкой в один день, получили статус «Проверено». Опытный сотрудник спросил бы, не оформили ли одну потребность дважды. А откуда об этом вопросе узнает новичок?   Представим, что раньше заявки сверяли вручную, а теперь система проверяет заполнение полей и наличие согласований. Совпадения она не ищет: две похожие заявки могут быть и разными заказами, и случайным повтором. Инструкция объясняет, что делать с найденной ошибкой, но не говорит, чего система вообще не проверяет.   Это не довод против автоматизации. Возможно, правило осталось в голове опытного человека и раньше тоже было недоступно остальным. Как передать это знание, не сохраняя всю прежнюю сверку?   В опыте Toyota на практике часто приводят пример - о мастере ковки Тосио Андо. На заводе с автоматизированным производством он учит молодых сотрудников работать ручным молотком: чтобы разобраться с проблемой в машине, нужно представлять, что происходит внутри неё с металлом.   Это не доказывает преимуществ ручной работы или эффективности именно такого обучения. Ручная практика служит обучению, а не заменяет автоматизированное производство. В офисе тоже стоит отделить обучение от обычной работы.   Сохранять нужно не весь прежний порядок, а способность понять, что проверила система, заметить возможное отклонение и выбрать следующий шаг.   Я бы начал не с инструкции, а с названия статуса - с того, что именно он обещает пользователю. «Проверено» звучит так, будто с заявкой всё в порядке. Точнее написать «Поля и согласования проверены» и указать рядом: совпадение заявок система не оценивает. Если статус нельзя изменить, нужна заметная подсказка рядом с ним. Но и она не найдёт повтор: сперва нужно решить, как похожие заявки попадут на рассмотрение.   Если система показывает заявки по подразделению, товару и дате, сотрудник, оформляющий закупку, может просматривать совпадения перед заказом. Это всё ещё ручная работа, но не повторная проверка всех полей и согласований. Такая выборка не заметит повторы с разными названиями товара: прежде чем отказаться от прежней сверки, нужно понять, какие случаи она пропустит и допустим ли этот риск. Если собрать похожие заявки в одном списке нельзя, отменять прежнюю сверку без замены этого шага рискованно: сначала нужна выборка или сигнал в инструменте.   Совпадение - повод задать вопрос, а не сразу отклонять заявку. Заказчик мог разделить закупку на два назначения или дважды отправить одну потребность. Стоит спросить, нужны ли оба заказа; если ответ неясен - лучше не гадать, а передать вопрос тому, кто вправе решать. Чтобы не вернуть прежнюю работу под новым названием, надо оценить время просмотра совпадений и как часто он выявляет повторы.   Я бы попросил опытного сотрудника разобрать случаи, которые его насторожили: что он заметил, что спросил и почему пропустил обе заявки или попросил отменить одну. Не каждую привычку стоит превращать в правило: данные могли измениться. Важно спросить не только «на что вы смотрите», но и «какую ошибку это помогает найти сейчас».   Новичку можно дать несколько обычных и необычных заявок: какие он пропустит, по каким уточнит потребность, где передаст решение другому? Такой разбор проверит понимание границ проверки и полномочий, а не знание памятки наизусть. Несколько примеров не гарантируют готовности ко всему, зато обнаружат пробелы до самостоятельной работы.   Не всем нужны одинаковые знания. Исполнителю важно понимать, что проверено, откуда берутся сигналы о повторах и к кому обращаться. Ответственному за правила - какие случаи выбранный признак пропускает. Новый тип ошибки стоит добавить в учебные примеры и решить, менять ли проверку или пояснение.   Так прежнюю сплошную сверку не сохраняют только ради обучения. Но и не делают вид, что после её отмены подозрительные заявки найдутся сами собой. Нужно передать знание людям, предусмотреть способ заметить случай и учесть время на его разбор.