Разбор ручного процесса «как есть» помогает превратить переписки и звонки в понятные шаги, чтобы ИИ предложил автоматизацию без лишних экранов.
Разбор ручного процесса «как есть» нужен не для «документов ради документов», а чтобы понять, что реально происходит каждый день. В переписках и звонках процесс часто выглядит как поток фраз: «проверь», «уточни», «скинь скрин», «подожди ответ». Но из этого потока почти всегда пропадают детали, из-за которых потом ломается автоматизация.
Обычно теряются три вещи: кто именно принимает решение, по какому правилу и чем подтверждается результат. В чате могут не сохраниться вложения, в звонке могут прозвучать исключения («если клиент новый, делаем иначе»), а ручные сверки остаются «в голове» у одного человека. Когда эти куски не зафиксированы, ИИ предлагает слишком общую схему, и вы снова возвращаетесь к ручным уточнениям.
Фиксация «как есть» отличается от «как должно быть» тем, что вы описываете не идеальный сценарий, а фактический: с обходными путями, задержками и «костылями». Это важно: автоматизировать можно только то, что понятно и повторяется. А улучшать процесс проще, когда видно, где именно он спотыкается.
Пора описывать шаги, если вы узнаете себя хотя бы в нескольких пунктах:
Когда шаги зафиксированы, вы можете дать это описание ИИ и попросить предложить автоматизацию без лишних экранов: какие действия делать в фоне, какие проверки формализовать, какие поля обязаны быть. Такой черновик помогает быстрее перейти от разговоров к работающему прототипу, потому что понятно, что именно должно происходить на каждом шаге.
Чтобы разбор ручного процесса «как есть» получился честным, нужны не общие слова, а следы реальной работы. Лучше собрать материалы заранее. Тогда на встрече вы не будете вспоминать по памяти и спорить о деталях.
Начните с переписок. Возьмите 1-2 цепочки из мессенджера, 1-2 письма и пару обсуждений из задачника, где видно: кто написал, что попросили, какие уточнения были и чем закончилось. Сохраните не только итог, но и вопросы, которые повторяются.
По звонкам достаточно коротких итогов. Если есть записи, отлично, но часто хватает заметок: что решили, кто что обещал, какие сроки назвали, что осталось открытым. Хороший сигнал для автоматизации: когда после звонка все равно приходится дописывать в чат «правильную формулировку» и отдельно согласовывать детали.
Соберите артефакты, которые люди реально трогают руками: таблицы, шаблоны сообщений, скриншоты, документы, формы, выгрузки. Даже один «типовой» файл с правками по красным пометкам быстро показывает, где теряется время.
Чтобы сбор не раздувался, ограничьтесь понятным набором:
Пример: если вы разбираете обработку заявки, возьмите несколько заявок за последнюю неделю, где были переносы сроков, уточнения и отказ. Именно такие случаи помогают ИИ позже предложить автоматизацию без лишних экранов, потому что в них видно реальные развилки и причины задержек.
Начните с одного реального случая, а не с «как обычно бывает». Возьмите один прогон процесса от старта до финала: одна переписка, один звонок, один исход. Так вы увидите настоящие шаги, а не «правильную» схему.
Откройте материалы и идите по времени. Цель простая: превратить фразы из чата и речи в короткие действия. Записывайте шаги глаголами в прошедшем времени: «получили», «уточнили», «проверили», «внесли», «отправили». Один шаг - одно действие.
Сразу зафиксируйте две опорные точки: что запускает процесс и по чему понятно, что он закончен. Например, старт - «клиент написал в мессенджер», конец - «счет оплачен и статус обновлен». Эти рамки спасают от бесконечных уточнений и помогают ИИ не добавлять лишние экраны.
Дальше на каждом шаге отмечайте минимум контекста, который влияет на автоматизацию:
Небольшой пример, как это выглядит в записи. Был звонок от клиента: менеджер принял запрос, затем в чате попросил ИНН и почту, после получения данных проверил клиента в CRM, создал сделку, отправил КП, а в конце поставил задачу на перезвон через 2 дня. Здесь уже видно, что часть шагов можно автоматизировать: вытягивать данные из чата, создавать сущности, напоминать о задаче.
Если где-то «прыгаете» между каналами, так и пишите: «получили в чате, подтвердили по телефону, сохранили в CRM». Это важнее красивых формулировок и дает ИИ понятную основу для предложений по автоматизации.
Чтобы разбор ручного процесса «как есть» не занял полдня, заранее выберите один тип кейса. Например: «обработка входящей заявки из мессенджера до выставления счета». Сразу договоритесь, что будет считаться успехом: заявка закрыта, оплачено, назначена встреча, отправлен договор. Так вы не расползетесь по деталям.
Дальше работайте как с хронологией, а не как с улучшением. Цель - честно зафиксировать, что происходит сейчас, даже если это выглядит неудобно.
Возьмите 3-5 реальных примеров из переписок и звонков и разложите их по времени: что было сначала, что потом. Для каждого шага запишите три вещи: вход (что пришло), действие (что сделал человек), выход (что получилось). Отдельно отмечайте, где процесс ждет: ответа клиента, согласования, оплаты, решения руководителя.
После этого у вас уже есть черновик, который можно показать ИИ. Но добавьте еще один слой: где шаг «переходит из рук в руки». Например: менеджер передал бухгалтеру, бухгалтер вернул менеджеру, руководитель утвердил.
Выпишите вопросы и пустые места: «кто решает», «по каким правилам», «что делаем, если нет данных». Закройте их коротким созвоном на 10-15 минут с человеком, который реально делает работу. Затем отправьте черновик на быстрый просмотр 1-2 участникам с вопросом «это так происходит?», а не «как лучше?».
На выходе получится короткое описание шагов, ожиданий и передач. Его уже можно отдавать ИИ, чтобы получить более точные предложения по автоматизации.
Когда вы делаете разбор ручного процесса «как есть», сложнее всего описать не «что делаем», а «почему именно так». Обычно это прячется в фразах вроде «если норм, то отправляем», «если не получилось, то звоним», «на всякий случай перепроверяем».
Чтобы ИИ предложил адекватную автоматизацию, фиксируйте не экран и не кнопку, а правило. Удобный формат - дописать к каждому шагу пять коротких пунктов:
Пример из обработки заявки. Шаг «подтвердить цену по телефону» часто содержит решение: «если клиент просит скидку больше 10% - нужен руководитель». Исключение: «если клиент уже покупал в прошлом месяце, скидку можно дать без согласования». Проверка: «телефон в заявке совпадает с номером в CRM». Ошибка: «в CRM два контакта, звонят не тому». Признак качества: «в карточке заявки есть запись звонка и финальная сумма».
Правила лучше писать так, чтобы их можно было проверить, а не «по ощущениям».
Если решение зависит от человека, так и пишите: «решает менеджер» или «решает руководитель». И добавьте, какие данные он смотрит. Тогда ИИ сможет предложить автоматизацию без лишних экранов: часть правил уйдет в логику, а человеку останутся редкие исключения.
При разборе ручного процесса «как есть» легко скатиться в «давайте нарисуем систему целиком». Лучше держать фокус на минимуме: какие данные реально нужны, какие правила повторяются и какие действия люди делают руками каждый день.
Начните с одной главной сущности. В большинстве процессов это «заявка» (или задача, обращение, заказ). Для нее часто хватает базовых полей: кто клиент, что попросили, текущий статус, сумма (если есть), дедлайн и ответственный. Остальное добавляйте только если без этого нельзя принять решение.
Чтобы не плодить ручной ввод, отделите справочники от данных. Справочник - это короткий список вариантов, который редко меняется: статусы, типы заявок, причины отказа, канал (чат, звонок, почта). Чем меньше свободного текста, тем проще автоматизация и отчеты.
Обычно минимальный интерфейс сводится к 2-3 формам: быстрое создание заявки (в идеале прямо из чата), карточка заявки (просмотр, смена статуса, короткий комментарий) и список заявок (поиск, фильтры по статусам и ответственному).
Все «дополнительные» экраны проверяйте вопросом: человек заходит туда каждый день или раз в квартал? Если раз в квартал, это может быть не экран, а отчет или выгрузка.
Логику фиксируйте как события: что произошло и что должно случиться дальше. Примеры: «заявка без ответа 2 часа», «дедлайн завтра».
Полезный минимум уведомлений обычно такой:
Интеграции тоже начинайте с минимума: откуда берем вход (чат, форма, таблица) и куда отправляем результат (ответ клиенту, задача в трекере, счет).
Чтобы ИИ предложил адекватную автоматизацию, ему нужно не «красивое ТЗ», а ясная картинка: кто что делает, в каком порядке, на каких данных и где чаще всего все ломается. Для темы «разбор ручного процесса «как есть»» хорошо работает формат: короткое описание плюс факты (примеры сообщений, правила, исключения).
Начните с запроса в одну фразу: «Собери процесс по шагам и предложи, как его автоматизировать». Затем добавьте контекст: цель процесса (что считаем успехом), участники (роли, не фамилии) и где процесс живет сейчас (чат, почта, звонки, таблица).
Дальше приложите «сырье», на котором ИИ будет думать:
Отдельно задайте ограничения, чтобы ИИ не предлагал лишние интерфейсы. Например: «без новых экранов», «разрешен только один экран статуса», «все действия через чат и уведомления», «данные храним в одной таблице».
Попросите ИИ выдать несколько вариантов, а не один:
Проверка понимания простая: попросите пересказать процесс своими словами и перечислить спорные места. Если в пересказе исчезли важные проверки или перепутались роли, значит, нужно уточнить формулировки и добавить один пример, где ошибка точно проявляется.
Представим типичную ситуацию: заявки приходят в Telegram, дальше менеджер уточняет детали по телефону, а итог фиксирует в таблице. Задача не в том, чтобы сразу придумать идеальный регламент, а сделать разбор ручного процесса «как есть», чтобы ИИ увидел реальный порядок действий и узкие места.
Как это выглядит на практике. Клиент пишет в чат: «Нужна поставка, сколько будет стоить?». Менеджер задает пару вопросов, затем созванивается, потому что в переписке долго. После звонка он переносит данные в таблицу, проверяет реквизиты, согласует цену с руководителем и выставляет счет.
Если разложить процесс на фактические шаги (без лишних деталей), получится:
Где обычно теряется время: ожидание ответа клиента в чате, ручная сверка реквизитов по нескольким источникам и дублирование, когда одно и то же пишут в чат, проговаривают по телефону и потом заносят в таблицу.
Вариант «без лишних экранов» можно описать так: одна карточка заявки, где есть статус, ключевые поля (контакт, товар или услуга, сумма, реквизиты, дедлайн) и история всех сообщений плюс короткая заметка по звонку. Не нужно отдельного окна под каждый шаг, важнее, чтобы карточка обновлялась по мере движения.
Что стоит автоматизировать первым, чтобы эффект был быстрым:
Цель разбора ручного процесса «как есть» - поймать реальность. Не красивую схему, а то, что правда происходит в переписках, звонках и таблицах. Ниже ошибки, из-за которых ИИ потом предлагает «лишние экраны» или ведет автоматизацию не в ту сторону.
Часто люди сразу начинают рассказывать, как должно быть по регламенту. А в жизни есть обходные пути: «если менеджер занят, пишет ассистент», «если клиент в чате, не звоним», «если сумма маленькая, согласование пропускают». ИИ не сможет учесть это, если вы это не зафиксировали.
«Обработка заявки» для нового клиента, для постоянного и для проблемного долга может выглядеть похоже только в начале. Если склеить все в один поток, получится каша: лишние развилки, непонятные правила и спорные шаги. Лучше выбрать один самый частый кейс, а остальные добавить как отдельные варианты.
Самые важные детали обычно звучат так: «мы всегда еще проверяем…» или «если что, на всякий случай…». Это и есть реальные правила. Например: «если номер выглядит странно, ищем в базе вручную» или «если клиент нервничает, переносим на звонок руководителю». Такие моменты лучше записывать прямо в виде условий.
Фразы вроде «обработать запрос» или «проверить данные» ничего не объясняют. Нужна конкретика: что именно проверяем, где, по каким признакам и что делаем при результате A или B. Иначе ИИ не поймет, какие действия автоматизировать, а какие оставить человеку.
Когда начинают с экранов, разговор быстро уходит в кнопки и поля. А потом выясняется, что не определены входы (откуда берется информация), выходы (что должно получиться) и правила (когда какой шаг нужен). Если вы используете TakProsto.ai, полезнее сначала описать логику и данные, а интерфейс уже подстроится под это.
«Кто делает шаг?» - обязательный вопрос. Частая поломка процесса именно в передаче: менеджер ждет бухгалтера, бухгалтер ждет подтверждение, никто не понимает, кто последний держал задачу. Отметьте, где меняется ответственный и чем подтверждается передача (сообщение, отметка, статус, комментарий).
Короткая проверка себя: после описания должно быть понятно, какой сигнал запускает процесс, кто делает каждый шаг, какие есть условия и что считается готовым результатом.
Перед тем как просить ИИ предложить автоматизацию, важно, чтобы ваш разбор ручного процесса «как есть» был достаточно точным. Не идеальным, а пригодным для работы: чтобы по нему можно было собрать MVP без десятков уточняющих вопросов.
Главный тест простой: если завтра эту задачу будет делать новый человек, сможет ли он пройти процесс по вашему описанию и не потеряться.
Проверьте себя по чеклисту:
Отдельно зафиксируйте ограничения для MVP: какие экраны точно не нужны, что можно оставить в одном окне, какие действия должны быть в один клик и за какой срок вы хотите получить первую рабочую версию.
Когда шаги процесса «как есть» уже собраны, не пытайтесь сразу «сделать идеально». Сначала нужен понятный план и быстрый прототип, который можно показать тем, кто реально делает работу.
Скопируйте ваш список шагов, роли (кто делает), входы и выходы (что получаем на каждом шаге) и попросите ИИ предложить MVP: какие 2-3 функции дадут максимум пользы в первую очередь. Отдельно попросите указать, какие данные нужно хранить и какие проверки обязательны, чтобы не пропустить ошибки.
Хороший результат выглядит как короткий план на 1-2 недели с понятными статусами и правилами, а не как попытка «переписать весь процесс целиком».
Дальше лучше действовать через быстрые уточнения. Прототип может быть простым: форма, список заявок и карточка с действиями. После первого прогона соберите 5-10 вопросов, которые всплыли, и уточните их у исполнителей.
Пример спорного места: «кто должен перезвонить клиенту, если менеджер занят?» или «что делать, если в чате нет номера телефона?». Такие вещи лучше решить до разработки, иначе потом действительно появятся лишние экраны.
Чтобы не разрастись, держите фокус на минимуме:
Часто хватает одного веб-приложения: удобно руководителю и быстро править. Мобильное приложение имеет смысл, если сотрудники работают «в поле» и им нужны пуши, камера или офлайн. Серверная часть нужна там, где есть интеграции, правила и хранение данных.
Если вы собираете это в TakProsto (takprosto.ai), можно идти тем же путем: сначала описать процесс в чате и получить план в режиме планирования, затем собрать веб, сервер или мобильное приложение. А когда нужно продолжить работу вне платформы, полезно, что там поддерживается экспорт исходного кода и есть снимки с откатом.
Фиксация «как есть» нужна, чтобы ИИ увидел реальный ход работы: кто принимает решения, по каким правилам и чем подтверждается результат. Если описывать только «как должно быть», в автоматизации пропадут исключения и ручные проверки, и вы снова скатитесь в уточнения и переделки.
Начните с одного реального кейса от старта до финала и пройдите по времени по переписке и заметкам со звонка. Записывайте шаги короткими действиями в прошедшем времени и сразу отмечайте три вещи: что пришло на вход, что сделал человек, что получилось на выходе.
Соберите следы реальной работы: пару цепочек из чатов, 1–2 письма, несколько обсуждений из задачника и короткие итоги звонков. Добавьте артефакты, которые реально трогают руками (шаблоны, таблицы, документы, скриншоты), и 5–10 последних кейсов без «идеальных» примеров.
Старт — это конкретный сигнал, после которого работа точно начинается (например, сообщение клиента в чате или новая заявка в CRM). Финиш — понятный критерий «готово» (например, счет оплачен и статус обновлен). Эти рамки помогают не раздувать процесс и не заставляют ИИ придумывать лишние шаги.
На каждом шаге фиксируйте канал, хранилище, роль ответственного, артефакт на выходе и условие/проверку перед действием. Этого обычно достаточно, чтобы увидеть, где вы прыгаете между чатами и таблицами и где можно убрать ручной перенос данных.
Пишите правило, а не интерфейс: кто принимает решение, какие данные смотрит и какой порог или критерий используется. Если правило «на опыте», переведите его в проверяемый вид и добавьте, что делать в каждом исходе, чтобы ИИ мог заложить логику, а человеку оставить редкие исключения.
Отдельным блоком отмечайте исключения: что делаете, когда нет данных, клиент молчит, сумма выше порога, есть конфликт в реквизитах или в базе дубль. Полезно также указать, как часто это бывает, чтобы ИИ не строил процесс вокруг редкого случая, но учитывал его.
Уложиться помогает ограничение: берите один тип кейса и цель «зафиксировать, а не улучшать». За первые 30 минут соберите скелет шагов с входом/действием/выходом и местами ожидания, затем еще 30–60 минут закройте пробелы короткими вопросами у исполнителя и быстрым подтверждением у 1–2 участников.
Сведите описание к минимуму: одна главная сущность (чаще всего «заявка»), несколько обязательных полей, статусы и 2–3 действия, которые делают каждый день. Все, что нужно раз в квартал, лучше оставить отчетом или выгрузкой, а не отдельным экраном, чтобы MVP был простым и быстрым.
Дайте ИИ цель процесса, роли, где живут входы и выходы, затем вставьте список шагов, примеры сообщений, шаблоны и правила с исключениями. Отдельно пропишите ограничения вроде «без новых экранов» или «одна карточка заявки», и попросите выдать MVP и список спорных мест — так вы быстрее придете к прототипу, например в TakProsto с режимом планирования и быстрыми итерациями.
