AS-IS и TO-BE
По регламенту заявка идёт в системе через двух согласующих. На деле менеджер пишет обоим в мессенджер, получает «ок» за двадцать минут и заводит заявку задним числом - потому что в системе то же самое занимает два дня. Нарисуешь по регламенту - опишешь процесс, которого не существует, и будешь улучшать выдумку.
Стержень: AS-IS фиксирует реальность, а не документ; TO-BE обязан приходить с измеримыми показателями и точкой отсчёта.
// Формулировки: «зачем AS-IS, если всё равно менять?», «сотрудники работают не по регламенту», «показатели не улучшились»
Расхождение с регламентом - находка, а не нарушение
AS-IS описывает, как работа идёт на самом деле: с обходными путями, письмами вместо системы, согласованиями в чате, табличкой у ведущего специалиста, где лежат «настоящие» данные.
Люди обходят порядок редко от лени. Обычно причин три: шаг избыточен, инструмент неудобен, срок нереален. Каждая причина - готовое требование к целевому процессу, и найти их можно только через расхождение. Аналитик, который приходит наводить порядок, эти причины закапывает вместе с обходными путями.
// Вопрос, который открывает больше всего: «а как вы делаете, когда надо срочно?». Обычный маршрут люди описывают по регламенту, а срочный - как есть, потому что им гордятся.
Три источника картины, и у каждого слепое пятно
Рассказы участников. Дают смысл и причины, но теряют привычное: действие, которое человек делает пятнадцать лет, из рассказа выпадает, оно для него не работа, а воздух.
Данные систем - журналы переходов и штампы времени. Показывают фактические сроки и реальные маршруты, включая те, о которых никто не рассказал. Слепое пятно: всё, что происходит вне систем, для них не существует - переписка, звонки, таблички.
// Наблюдение за работой. Ловит именно то, что не видно первым двум, но меняет поведение: пока рядом сидит аналитик, работают по регламенту. Лечится временем - к третьему дню про наблюдателя забывают. Сходятся все три источника редко, и каждое расхождение между ними стоит разобрать отдельно.
Зачем текущая картина, если всё меняем
Две причины, обе практические. Первая: в целевой модели теряются шаги, которые выглядели лишними, а на деле закрывали риск. Прежде чем выкинуть «бюрократию», найди инцидент, после которого она появилась, и ответь, чем риск закрывается теперь. Нет ответа - инцидент повторится, уже без страховки.
Вторая: точка отсчёта. Без замера сегодняшних сроков доказать улучшение нечем, и разговор о пользе сведётся к ощущениям участников, а ощущения после любого внедрения отрицательные - людям неудобно.
// Целевую модель поэтому сопровождают числами до и после: срок обработки заявки с трёх дней до четырёх часов, доля возвратов на доработку с 30 процентов до 10. Цифра «до» снимается заранее, иначе через полгода её взять уже неоткуда.
Переход этапами и проверка результата
Одномоментная смена процесса, системы и ролей не оставляет пути назад: старого порядка уже нет, новый ещё не работает, а заявки идут. Поэтому переход режут на этапы, оставляют период параллельной работы и заранее пишут условие отката - при каком показателе возвращаемся.
Условие отката формулируют числом до запуска. «Если доля успешно завершённых заявок за неделю упала ниже 90 процентов, возвращаемся на старый маршрут» - такое решение принимается за час. Без числа спорят неделями, пока копится ущерб.
// Показатели не улучшились - смотри сначала не на схему, а на фактическую работу. Чаще всего процесс изменили на бумаге, а работают по-старому: неудобно, непонятно, не объяснили зачем, старый путь остался открытым.
Как отвечать: «Сотрудники описывают процесс не так, как в регламенте. Что делаешь?»
Фиксирую фактический ход и выясняю, почему он разошёлся с документом. Это не нарушение, которое надо пресечь, а самая ценная часть работы: люди обходят порядок обычно потому, что шаг избыточен, инструмент неудобен или срок нереален, и каждая такая причина превращается в требование к целевому процессу. Схема по регламенту описывала бы процесс, которого не существует, и любые улучшения строились бы на выдумке. Дальше сверяю рассказы с журналами систем - фактические переходы и сроки, а где можно, сажусь рядом и смотрю на работу: часть обходных путей живёт в почте и таблицах, и в рассказ они не попадают, потому что кажутся людям само собой разумеющимися. И отдельно спрашиваю, как они действуют, когда надо срочно, - там обходные маршруты рассказывают сами.
Кандидат относится к расхождению как к источнику требований, называет три способа проверки картины и знает вопрос, который вскрывает обходные пути.
На чём валятся
- −− Рисуют AS-IS по регламенту и описывают несуществующий процесс.
- −− Проверяют модель только рассказами и теряют привычные действия.
- −− Выкидывают «лишний» шаг, не выяснив, какой риск он закрывал.
- −− Не замеряют показатели до изменения и потом не могут доказать улучшение.
- −− Переходят к целевому состоянию одним шагом, без параллельной работы и условия отката.
- −− Ищут причину провала в схеме, хотя люди просто работают по-старому.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Что обязательно сопровождает модель TO-BE, кроме самой схемы?A)Показатели, по которым видно улучшениеB)Штатное расписание подразделенияC)Смету на закупку оборудованияD)Список используемых программных продуктов
показать ответ и разбор
+A)Показатели, по которым видно улучшение// разбор: Целевой процесс без измеримой цели невозможно защитить и потом подтвердить. Нужны конкретные числа: срок обработки заявки с трёх дней до четырёх часов, доля возвратов на доработку с 30% до 10%. Иначе после внедрения спор о пользе решается ощущениями участников.
- В целевом процессе выкинули шаг проверки, который казался бюрократией. Какой риск?A)Сотрудники не примут новый процессB)Шаг закрывал риск, о котором не спросилиC)Схема станет менее нагляднойD)Придётся переобучать персонал
показать ответ и разбор
+B)Шаг закрывал риск, о котором не спросили// разбор: Странные шаги обычно появились после конкретного инцидента: кто-то отгрузил товар без предоплаты, и добавили визу. Прежде чем убирать, надо найти причину появления и понять, чем риск закрывается теперь. Если ответа нет, инцидент повторится — и уже без страховки.
- Чем опасен переход к TO-BE одним большим шагом?A)Схема получится слишком подробнойB)Потребуется больше согласованийC)При сбое некуда откатиться и всё встаётD)Показатели будет труднее считать
показать ответ и разбор
+C)При сбое некуда откатиться и всё встаёт// разбор: Одновременная смена процесса, системы и ролей означает, что при проблеме нельзя вернуться к прежнему порядку — старого уже нет. Поэтому переход разбивают на этапы, оставляют период параллельной работы и заранее определяют условия отката. Медленнее, зато обратимо.
- Процесс изменили, показатели не улучшились. Что проверить в первую очередь?A)Точность рисования схемы процессаB)Квалификацию участников процессаC)Достаточность бюджета на внедрениеD)Работают ли люди по новой схеме
показать ответ и разбор
+D)Работают ли люди по новой схеме// разбор: Самая частая причина — процесс изменили на бумаге, а работают по-прежнему: неудобно, непонятно, не объяснили зачем. Прежде чем менять схему второй раз, надо посмотреть фактический ход по данным системы и поговорить с исполнителями. Иначе улучшать будете модель, а не работу.
- Как убедиться, что модель AS-IS отражает реальность, а не рассказы участников?A)Собрать подписи всех участников под схемойB)Сверить с данными систем и понаблюдатьC)Опросить как можно больше сотрудниковD)Согласовать схему с руководителем отдела
показать ответ и разбор
+B)Сверить с данными систем и понаблюдать// разбор: Люди описывают процесс таким, каким он должен быть, и честно забывают про обходные пути. Журналы систем показывают фактические переходы и сроки, а наблюдение за работой вскрывает то, чего в системах нет вовсе: звонки, таблицы на рабочем столе, согласования в мессенджере.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.