Коротко о главном
Модели AS IS и TO BE помогают не тратить время и деньги на внедрение бесполезных практик и сервисов. Суть методики — подобрать те инструменты, которые помогут достичь цели компании.
Модель AS IS («Как есть») — схема показывает, как выстроена работа всех отделов (или одного) сейчас. Проанализировав её, можно понять, где возникают ошибки, какие операции отнимают больше всего денег.
Модель TO BE («Как будет») — помогает выстроить чёткую систему работы, убрать лишние действия, повысить качество сервиса и т. д. Модель опирается на схему AS IS и показывает идеальный вариант рабочих процессов.
Что такое AS IS и TO BE простыми словами
AS IS («Как есть») и TO BE («Как будет») — два состояния одного и того же бизнес-процесса. AS IS показывает, как что-то работает сейчас. TO BE демонстрирует, как должно работать в идеале.
Поэтому я бы сказала, что AS IS и TO BE — больше способ мышления об изменениях, привычка сначала разобраться в реальности, а уже потом предлагать решения
Что такое модель AS IS
Это схема, которая описывает существующий процесс без попытки его улучшить, пометок и рекомендаций. На этом этапе нужно отбросить любую предвзятость (это не так легко, как кажется) и расписать процессы без прикрас, но и без преувеличения градуса трагедии.
Модель нужна, чтобы увидеть узкие места, обнаружить дублирование функций и бесполезные операции, которые отнимают время. Также можно понять причины ошибок и оценить нагрузку на сотрудников.
Для руководителей это тоже может быть неприятным открытием. Иногда они искренне уверены, что процесс устроен одним образом, а команда уже давно работает совершенно по-другому
Что такое модель TO BE
Схема уже улучшенного процесса. На этом этапе аналитики и владельцы бизнесов решают, какие шаги можно убрать, что автоматизировать, где снизить количество согласований, как сократить время выполнения задачи, какие системы и инструменты внедрить.
Объясним на маленьком кусочке, чтобы тебе было понятнее, как это работает.
| 🥲 AS IS | 🤩 TO BE | 🤗 Результат |
|---|---|---|
| Менеджер вручную ставит задачи сотрудникам, тратит время на одни и те же операции | Когда задача попадает в определённую колонку на Канбан-доске или в проект, нужный исполнитель назначается автоматически | У менеджера появилось больше времени, которое можно было бы потратить на более важные задачи. Процесс взаимодействия внутри команды ускорился |
TO BE всегда связана с целями бизнеса: снизить расходы, ускорить процессы, повысить качество сервиса, увеличить прибыль, масштабировать компанию — и так до бесконечности.
❗ Модель «Как будет» невозможна без «Как есть», иначе ты рискуешь столкнуться с тем, что придётся улучшать то, чего по факту не существует
В чём разница между «как есть» и «как должно быть»
AS IS и TO BE решают разные задачи, хотя и работают в связке. AS IS помогает понять проблемы, а TO BE отражает способы их устранения. Если ты посмотришь на готовые схемы, то тебе не составит труда определить, где какая модель отрисована. Но по факту разница воспринимается примерно вот так.
ИЛЛЮСТРАЦИЯ
Как выглядят схемы AS IS и TO BE
Диаграмма или схема AS IS и TO BE визуализирует бизнес-процесс и, соответственно, содержит в себе визуальные элементы, которые обозначают конкретные события или действия.
То есть схематические обозначения процессов, зон ответственности, точек принятия решений и так далее. Вместо тысячи слов покажем картинку.
Остаётся дело за малым — попытаться отразить эти элементы в схемах. Но сначала — ещё немного теории, а потом перейдём к самому интересному.
Где можно применять модели AS IS и TO BE
Модели AS IS и TO BE используют практически везде. Другой вопрос — нужны ли они конкретно тебе. В этом блоке коротко опишем, в каких сферах и зачем применяют.
Оптимизация HR-процессов и найма
Ускорить наём, автоматизировать онбординг и сократить бумажный документооборот. Когда у HR на одну вакансию сотни откликов, то без автоматизированной фильтрации кандидатов она просто загнётся. И весь отдел вместе с ней.
Построение эффективной системы продаж
В отделах продаж AS IS-анализ помогает найти место, на котором отваливаются лиды, выявить медленные согласования, перегрузку менеджеров. TO BE-модель автоматизирует воронку, ускоряет обработку заявок, снижает нагрузку на сотрудников.
Управление циклом разработки продукта
Для того чтобы AS IS превратить в TO BE, нужно сделать одну простую вещь — убрать всё, что не несёт ценности. Это один из главных принципов гибкой методологии Agile.
Поэтому такие схемы популярны в командах разработки. Ускоряют планирование релизов, распределение задач и помогают автоматизировать контроль сроков.
Настройка логистики и складского учёта
AS IS помогает обнаружить потери товаров, ошибки учёта, задержки поставок. TO BE-модель автоматизирует склад, сокращает время комплектации, улучшает маршрутизацию.
Клиентский сервис и работа службы поддержки
Службы поддержки используют модели для ускорения ответов, распределения обращений, контроля SLA. Если настроить всё правильно, то смогут автоматически классифицировать обращения, назначать ответственных, уведомлять клиента о решённом обращении и так далее.
Финансовый учёт и документооборот
Одна ошибка — и ты ошибся. Такой фразой можно охарактеризовать отдел бухгалтерии. TO BE-модель позволяет сократить этапы согласований документов, ускорить их оборот, автоматически выставлять счета, делать сверки, обрабатывать первичные документы и сокращать рутину.
Кто в компании отвечает за составление моделей AS IS и TO BE
А вот навыков для составления модели пригодится не так уж много:
- Уметь задавать вопросы. Это кажется очевидным, но именно от качества вопросов зависит качество итоговых выводов
- Обладать высоким уровнем эмоционального интеллекта. Чтобы люди делились мнением, нужно уметь выстраивать доверительный диалог и понимать мотивацию людей
- Иметь аналитическое мышление и понимать предметную область. Нельзя проектировать HR-процессы, продажи или финансовые процессы, не понимая хотя бы базово, как они работают
Подробные этапы создания модели AS IS
Создание модели «Как есть» начинается с душного, утомительного, раздражающего сбора информации о том, как реально идут дела в компании. Если бы можно было выкинуть этот этап, то мы бы все стали счастливее. Но нет, нельзя.
Поговорить с командой
Нужно пообщаться с каждым человеком, который работает в компании. Задавать вопросы не только руководителям отделов, но и рядовым сотрудникам, потому что они каждый день погружаются в рабочий процесс и знают, где система может тормозить.
Что спросить:
- как проходит рабочий день
- сколько времени уходит на задачи
- где процессы тормозят
- часто ли теряются задачи
- сколько согласований нужно
- какими сервисами пользуются сотрудники
Важно получить честный ответ. Можно использовать анонимные формы, чтобы сотрудники не боялись открыто говорить о проблемах.
Проанализировать документы и системы
Изучить регламенты, должностные инструкции, воронки CRM, посмотреть отчётность, статистику по задачам. В общем, собрать всю аналитику, чтобы проверить, насколько слова сотрудников совпадают с тем, что написано в отчётах и бумажках.
Если должностной инструкции нет, то придётся работать с теми данными, которые существуют.
Узнать, сколько времени уходит на задачи
На этом этапе важно понять, сколько времени занимает процесс, где происходят задержки, какие операции выполняются вручную. Отсылаем тебя к сервису Аналитика в Weeek, который покажет, сколько времени сотрудник тратил на одну задачу или все за конкретный промежуток времени.
Найти «узкие горлышки»
Когда на руках будет вся информация о том, как выглядят процессы сейчас, будет проще понять узкие места, которые тормозят работу и мешают компании масштабироваться или достигать своих целей.
Всю информацию, которую ты собираешь, нужно фиксировать и структурировать хотя бы в текстовых файлах. Позже всё это можно скормить ИИ, который отыщет в километровых описаниях важное и даст тебе сжатую версию.
Написать и согласовать схему
Далее берёшь все данные, которые собирались таким кропотливым трудом, и распределяешь по схеме, которую мы показывали выше. Это трудно, нужно полностью включиться в процесс, понять логику действий, но оно того стоит.
Далее уже готовую схему «Как есть» ты показываешь каждому участнику процесса. Если они согласны с ней, то всё — можно считать, что первая часть огромной работы закончена. Теперь можно перейти к улучшению.
Этапы создания модели TO BE
Модель должна иллюстрировать решение тех проблем, которые показала AS IS. Если в результате работы схема оказалась ещё сложнее и запутаннее, значит, что-то пошло не так и нужно начинать заново.
Найди возможности для оптимизации
На этом этапе команда отвечает на вопросы, какие этапы можно убрать, где сократить согласования, что можно автоматизировать, какие задачи объединить.
| 😐 Было | 🙂 Стало |
|---|---|
| Менеджер вручную создаёт счёт Бухгалтер проверяет данные Руководитель согласует оплату | CRM автоматически формирует счёт Система проверяет лимиты Согласование запускается только для крупных сумм |
Автоматизируй то, что можно делать руками
TO BE-модель подразумевает автоматизацию, потому что ручные ежедневные действия отнимают достаточное количество времени, которое можно было бы потратить на более важные вещи.
Автоматизировать можно уведомления, создание задач, распределение заявок, подготовку документов и отчёты.
внедрим Weeek
ваши процессы в таск-менеджере
Продумай, какую пользу изменения принесут бизнесу
Польза или результат может выглядеть примерно вот так:
- время обработки заявки сокращается с 40 до 10 минут
- количество ошибок падает на 60%
- нагрузка на менеджеров снижается на 30%
Проверь, насколько реальна схема
Всегда хочется сделать идеально с первого раза и чтобы у всех всё получилось, все остались довольны, выручка скакнула в необычайной прогрессии и вообще — жизнь в кайф.
Но так не работает. Поэтому, перед тем как внедрять улучшения и новые правила, нужно определиться, а какие возможности у компании есть сейчас для того, чтобы схема оказалась рабочей.
Например, ты пишешь о том, что нужно автоматизировать уведомления и постановку задач, но команда даже не знает, что такое таск-менеджер. В таком случае придётся начинать с малого: сначала внедрять таск-менеджер, а потом уже улучшать процессы.
Основные правила описания схем AS IS и TO BE
Схема может визуально быть понятной, но если внутри блоков аббревиатуры, непонятные сокращения и чёрт ногу сломит, то ты добавляешь себе ещё пару лишних часов на объяснение этой схемы коллегам. Подготовили шпаргалку, чтобы было проще описывать процессы.
Каждое действие обозначай глаголом
Хорошие формулировки помогают быстрее понимать логику процесса.
| ✅ Ок | ❌ Не ок |
|---|---|
| Проверить заявку Отправить документ Согласовать оплату | Заявка Документ Согласование |
Не смешивай уровни детализации
Одна из самых частых ошибок — смешивать крупные этапы и мелкие действия. В таком случае запутаешься даже ты, если оставишь схему на пару дней без внимания.
| ✅ Ок | ❌ Не ок |
|---|---|
| Собрать требования Подготовить дизайн Разработать функциональность Провести тестирование Согласовать релиз Опубликовать обновление | Запустить проект Провести встречу Нажать кнопку «Создать задачу» Написать сообщение дизайнеру Продумать стратегию релиза Открыть Figma Нажать «Сохранить» Проверить бизнес-метрики |
❗Если схема описывает бизнес-процесс верхнего уровня, не нужно показывать каждый клик мышкой
Нумеруй этапы
Нумерация помогает обсуждать процесс, согласовывать изменения, быстрее находить проблемные места. Показали в примере выше.
Не перегружай схему
Если она слишком сложная, её перестают понимать. Если её не понимают, то никто не будет её использовать. Лучше разделять большие схемы на несколько уровней. Чем проще готовое решение, тем лучше.
Ошибки при реализации моделей AS IS и TO BE
Ни одна модель в принятии бизнес-решений не гарантирует успех. Вот что увеличивает шансы на провал.
Не учитывать мнение сотрудников
Собрались руководители, обсудили процессы между собой и пошли рисовать схему, не поговорив с теми, кто ежедневно работает с этими процессами и знает все реальные проблемы. Например, почему сотрудники вручную переносят данные в CRM или тратят время на лишние действия.
В итоге получается модель, далёкая от реальности. Сотрудники не принимают изменения, потому что их мнение никто не учёл, а все усилия по описанию процессов оказываются напрасными.
Создавать сложные схемы
Слишком подробные диаграммы быстро становятся бесполезными. Если схема содержит сотни блоков, десятки стрелок, множество уровней, то её перестают понимать = использовать.
Пытаться автоматизировать бардак
Ни одна автоматизация и методология управления проектами не будет работать, если в головах и процессах мрак и хаос. Это как приложить подорожник к ране — не очень эффективно. Сначала нужно убрать лишние действия, сократить согласования, упростить процесс и только потом внедрять инструменты.
Не обучать сотрудников
Перед тем как начать менять процессы, сначала нужно объяснить всем, зачем это нужно. Далее — добавить инструкции, памятки, расписать регламенты и объяснить каждый шаг.
Также не забываем про сбор обратной связи, вопросов и помощи в тех моментах, в которых могут возникнуть трудности, а они обязательно будут.
Работать без метрик эффективности
Без них ты не сможешь понять, работает ли новая схема и окупилась ли автоматизация и все усилия, которые были вложены. Показатели эффективности нужно прописать заранее, чтобы ориентироваться на них.
Как инструменты Weeek помогают воплотить модель TO BE в жизнь
Если тебе нужно разложить всё по полочкам и автоматизировать задачи, то тогда мы идём показывать тебе сервисы и фичи, которые не подведут во время внедрения.
Канбан-доски
Канбан-доски помогают визуализировать путь задачи от создания до завершения.
TO BE — это желаемое состояние процесса. Его тоже можно отразить на Канбан-доске Weeek через новые статусы. Например, Бэклог → В работе → На проверке → На согласовании → Готово.
Также удобно усиливать модель дополнительными параметрами: метками, приоритетами, ответственными, дедлайнами и чек-листами.
Диаграмма Ганта
Если Канбан показывает поток работы, то Гант фокусируется на сроках, зависимостях и загрузке ресурсов. Как только построишь диаграмму, можно увидеть, где слишком длинные этапы согласования, какие задачи зависят друг от друга сильнее, чем нужно, когда сроки проекта растянуты.
Автоматизация задач
Одна из частых проблем AS IS — неясно, кто отвечает за следующий шаг. В TO BE можно настроить автоматическое назначение исполнителей. Допустим, после создания статьи задача уходит редактору, после редактуры — дизайнеру, после дизайна — контент-менеджеру на публикацию.
Уведомления
После внедрения TO BE сотрудникам пока сложно привыкнуть к новым правилам. Уведомления напомнят о сроках и покажут изменения в процессах. Так, они станут своего рода «напоминалочкой» о новых требованиях.
В Weeek можно настраивать напоминания самостоятельно.
База знаний
В контексте модели база знаний помогает описать текущее и целевое состояние процессов, а ещё закрепить изменения так, чтобы они не остались на словах.
На этапе AS IS здесь обычно собирают информацию о том, как работа устроена сейчас: шаблоны документов, текущие регламенты. После анализа можно создать описание целевого процесса.
После внедрения TO BE база знаний становится местом, где хранится вся документация по новым процессам. Это поможет сохранить, внедрить и масштабировать изменения, чтобы команда работала по новой модели, не возвращаясь к старым привычкам.
Подписаться 
