Разбор ручного процесса «как есть»: как фиксировать шаги для ИИ

Зачем фиксировать процесс «как есть» и что это решает

Разбор ручного процесса «как есть» нужен не для «документов ради документов», а чтобы понять, что реально происходит каждый день. В переписках и звонках процесс часто выглядит как поток фраз: «проверь», «уточни», «скинь скрин», «подожди ответ». Но из этого потока почти всегда пропадают детали, из-за которых потом ломается автоматизация.

Обычно теряются три вещи: кто именно принимает решение, по какому правилу и чем подтверждается результат. В чате могут не сохраниться вложения, в звонке могут прозвучать исключения («если клиент новый, делаем иначе»), а ручные сверки остаются «в голове» у одного человека. Когда эти куски не зафиксированы, ИИ предлагает слишком общую схему, и вы снова возвращаетесь к ручным уточнениям.

Фиксация «как есть» отличается от «как должно быть» тем, что вы описываете не идеальный сценарий, а фактический: с обходными путями, задержками и «костылями». Это важно: автоматизировать можно только то, что понятно и повторяется. А улучшать процесс проще, когда видно, где именно он спотыкается.

Пора описывать шаги, если вы узнаете себя хотя бы в нескольких пунктах:

• ошибки повторяются, и каждый раз приходится «разбираться, как получилось»
• сроки плавают из-за ожиданий ответов и ручных согласований
• появляются двойные проверки «на всякий случай»
• один сотрудник становится узким горлом, потому что только он знает порядок
• данные приходится переписывать между чатами, таблицами и CRM

Когда шаги зафиксированы, вы можете дать это описание ИИ и попросить предложить автоматизацию без лишних экранов: какие действия делать в фоне, какие проверки формализовать, какие поля обязаны быть. Такой черновик помогает быстрее перейти от разговоров к работающему прототипу, потому что понятно, что именно должно происходить на каждом шаге.

Какие материалы собрать перед разбором

Чтобы разбор ручного процесса «как есть» получился честным, нужны не общие слова, а следы реальной работы. Лучше собрать материалы заранее. Тогда на встрече вы не будете вспоминать по памяти и спорить о деталях.

Начните с переписок. Возьмите 1-2 цепочки из мессенджера, 1-2 письма и пару обсуждений из задачника, где видно: кто написал, что попросили, какие уточнения были и чем закончилось. Сохраните не только итог, но и вопросы, которые повторяются.

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

Соберите артефакты, которые люди реально трогают руками: таблицы, шаблоны сообщений, скриншоты, документы, формы, выгрузки. Даже один «типовой» файл с правками по красным пометкам быстро показывает, где теряется время.

Чтобы сбор не раздувался, ограничьтесь понятным набором:

• 5-10 последних кейсов по одному типу задачи, без «идеальных» примеров
• переписки и итоги звонков по этим кейсам
• файлы и шаблоны, которые использовались
• список ролей: кто просит, кто выполняет, кто утверждает, кто дает данные
• финальный результат: что считается «готово» и куда это уходит

Пример: если вы разбираете обработку заявки, возьмите несколько заявок за последнюю неделю, где были переносы сроков, уточнения и отказ. Именно такие случаи помогают ИИ позже предложить автоматизацию без лишних экранов, потому что в них видно реальные развилки и причины задержек.

Как превратить разговоры в список шагов

Начните с одного реального случая, а не с «как обычно бывает». Возьмите один прогон процесса от старта до финала: одна переписка, один звонок, один исход. Так вы увидите настоящие шаги, а не «правильную» схему.

Откройте материалы и идите по времени. Цель простая: превратить фразы из чата и речи в короткие действия. Записывайте шаги глаголами в прошедшем времени: «получили», «уточнили», «проверили», «внесли», «отправили». Один шаг - одно действие.

Сразу зафиксируйте две опорные точки: что запускает процесс и по чему понятно, что он закончен. Например, старт - «клиент написал в мессенджер», конец - «счет оплачен и статус обновлен». Эти рамки спасают от бесконечных уточнений и помогают ИИ не добавлять лишние экраны.

Дальше на каждом шаге отмечайте минимум контекста, который влияет на автоматизацию:

• канал: где пришло и где ответили (чат, почта, телефон, CRM)
• хранилище: куда сохранили результат (таблица, CRM, папка, база)
• ответственный: роль, а не имя (менеджер, бухгалтер, оператор)
• артефакт: что получилось на выходе шага (сообщение, задача, счет, запись)
• условие: что проверили перед действием (есть ли реквизиты, совпадает ли сумма)

Небольшой пример, как это выглядит в записи. Был звонок от клиента: менеджер принял запрос, затем в чате попросил ИНН и почту, после получения данных проверил клиента в CRM, создал сделку, отправил КП, а в конце поставил задачу на перезвон через 2 дня. Здесь уже видно, что часть шагов можно автоматизировать: вытягивать данные из чата, создавать сущности, напоминать о задаче.

Если где-то «прыгаете» между каналами, так и пишите: «получили в чате, подтвердили по телефону, сохранили в CRM». Это важнее красивых формулировок и дает ИИ понятную основу для предложений по автоматизации.

Пошаговый метод фиксации процесса за 60-90 минут

Чтобы разбор ручного процесса «как есть» не занял полдня, заранее выберите один тип кейса. Например: «обработка входящей заявки из мессенджера до выставления счета». Сразу договоритесь, что будет считаться успехом: заявка закрыта, оплачено, назначена встреча, отправлен договор. Так вы не расползетесь по деталям.

Дальше работайте как с хронологией, а не как с улучшением. Цель - честно зафиксировать, что происходит сейчас, даже если это выглядит неудобно.

1) За 30 минут: собрать скелет процесса

Возьмите 3-5 реальных примеров из переписок и звонков и разложите их по времени: что было сначала, что потом. Для каждого шага запишите три вещи: вход (что пришло), действие (что сделал человек), выход (что получилось). Отдельно отмечайте, где процесс ждет: ответа клиента, согласования, оплаты, решения руководителя.

После этого у вас уже есть черновик, который можно показать ИИ. Но добавьте еще один слой: где шаг «переходит из рук в руки». Например: менеджер передал бухгалтеру, бухгалтер вернул менеджеру, руководитель утвердил.

2) За 30-60 минут: закрыть пробелы и подтвердить реальность

Выпишите вопросы и пустые места: «кто решает», «по каким правилам», «что делаем, если нет данных». Закройте их коротким созвоном на 10-15 минут с человеком, который реально делает работу. Затем отправьте черновик на быстрый просмотр 1-2 участникам с вопросом «это так происходит?», а не «как лучше?».

На выходе получится короткое описание шагов, ожиданий и передач. Его уже можно отдавать ИИ, чтобы получить более точные предложения по автоматизации.

Как описать решения, исключения и проверки без усложнений

Когда вы делаете разбор ручного процесса «как есть», сложнее всего описать не «что делаем», а «почему именно так». Обычно это прячется в фразах вроде «если норм, то отправляем», «если не получилось, то звоним», «на всякий случай перепроверяем».

Чтобы ИИ предложил адекватную автоматизацию, фиксируйте не экран и не кнопку, а правило. Удобный формат - дописать к каждому шагу пять коротких пунктов:

• решение: где именно нужно «да/нет» (кто решает и на основании чего)
• исключение: что делаете, когда «не как обычно» (и как часто это бывает)
• проверка: что сверяете (поле, документ, сумму, статус) и какое правило
• ошибка: что чаще всего ломается и как это чинят
• признак качества: как понимаете, что шаг выполнен правильно

Пример из обработки заявки. Шаг «подтвердить цену по телефону» часто содержит решение: «если клиент просит скидку больше 10% - нужен руководитель». Исключение: «если клиент уже покупал в прошлом месяце, скидку можно дать без согласования». Проверка: «телефон в заявке совпадает с номером в CRM». Ошибка: «в CRM два контакта, звонят не тому». Признак качества: «в карточке заявки есть запись звонка и финальная сумма».

Правила лучше писать так, чтобы их можно было проверить, а не «по ощущениям».

• плохо: «если клиент надежный»
• хорошо: «если нет просрочек за 90 дней и сумма заказа до 100 000»

Если решение зависит от человека, так и пишите: «решает менеджер» или «решает руководитель». И добавьте, какие данные он смотрит. Тогда ИИ сможет предложить автоматизацию без лишних экранов: часть правил уйдет в логику, а человеку останутся редкие исключения.

Минимальная структура данных и логики без «лишних экранов»

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

Начните с одной главной сущности. В большинстве процессов это «заявка» (или задача, обращение, заказ). Для нее часто хватает базовых полей: кто клиент, что попросили, текущий статус, сумма (если есть), дедлайн и ответственный. Остальное добавляйте только если без этого нельзя принять решение.

Чтобы не плодить ручной ввод, отделите справочники от данных. Справочник - это короткий список вариантов, который редко меняется: статусы, типы заявок, причины отказа, канал (чат, звонок, почта). Чем меньше свободного текста, тем проще автоматизация и отчеты.

Обычно минимальный интерфейс сводится к 2-3 формам: быстрое создание заявки (в идеале прямо из чата), карточка заявки (просмотр, смена статуса, короткий комментарий) и список заявок (поиск, фильтры по статусам и ответственному).

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

Логику фиксируйте как события: что произошло и что должно случиться дальше. Примеры: «заявка без ответа 2 часа», «дедлайн завтра».

Полезный минимум уведомлений обычно такой:

• напоминание ответственному, если нет реакции после нового сообщения
• уведомление руководителю, если заявка просрочена
• сообщение клиенту, когда статус меняется на «в работе» или «готово»

Интеграции тоже начинайте с минимума: откуда берем вход (чат, форма, таблица) и куда отправляем результат (ответ клиенту, задача в трекере, счет).

Как подготовить описание для ИИ, чтобы он предложил автоматизацию

Чтобы ИИ предложил адекватную автоматизацию, ему нужно не «красивое ТЗ», а ясная картинка: кто что делает, в каком порядке, на каких данных и где чаще всего все ломается. Для темы «разбор ручного процесса «как есть»» хорошо работает формат: короткое описание плюс факты (примеры сообщений, правила, исключения).

Начните с запроса в одну фразу: «Собери процесс по шагам и предложи, как его автоматизировать». Затем добавьте контекст: цель процесса (что считаем успехом), участники (роли, не фамилии) и где процесс живет сейчас (чат, почта, звонки, таблица).

Дальше приложите «сырье», на котором ИИ будет думать:

• список шагов с триггером старта и понятным финишем (что именно считается сделанным)
• 3-5 реальных примеров сообщений (как клиент пишет, как отвечает сотрудник)
• шаблоны: текст ответа, поля заявки, названия статусов
• правила: сроки, кто согласует, по каким признакам выбирают вариант
• исключения: «если нет телефона», «если цена выше X», «если клиент молчит 2 дня»

Отдельно задайте ограничения, чтобы ИИ не предлагал лишние интерфейсы. Например: «без новых экранов», «разрешен только один экран статуса», «все действия через чат и уведомления», «данные храним в одной таблице».

Попросите ИИ выдать несколько вариантов, а не один:

• MVP на 1-2 недели (самое простое, но полезное)
• улучшенная версия (что добавить после MVP)
• план внедрения (что проверить, какие риски, как тестировать)

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

Пример: как разобрать обработку заявки из чата и звонка

Представим типичную ситуацию: заявки приходят в Telegram, дальше менеджер уточняет детали по телефону, а итог фиксирует в таблице. Задача не в том, чтобы сразу придумать идеальный регламент, а сделать разбор ручного процесса «как есть», чтобы ИИ увидел реальный порядок действий и узкие места.

Как это выглядит на практике. Клиент пишет в чат: «Нужна поставка, сколько будет стоить?». Менеджер задает пару вопросов, затем созванивается, потому что в переписке долго. После звонка он переносит данные в таблицу, проверяет реквизиты, согласует цену с руководителем и выставляет счет.

Если разложить процесс на фактические шаги (без лишних деталей), получится:

• прием заявки в Telegram и фиксация контакта
• уточнение параметров (часть в чате, часть по телефону)
• проверка: реквизиты, наличие, базовые ограничения
• согласование цены или условий (если нужно)
• выставление счета и отметка результата в таблице

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

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

Что стоит автоматизировать первым, чтобы эффект был быстрым:

• шаблоны ответов и вопросы для уточнения по типу заявки
• статусы и напоминания, если клиент не отвечает или счет не оплачен
• подсказки по проверкам (чек по реквизитам, обязательные поля)
• автоматическое заполнение отчета вместо ручной таблицы

Частые ошибки при описании процесса «как есть»

Цель разбора ручного процесса «как есть» - поймать реальность. Не красивую схему, а то, что правда происходит в переписках, звонках и таблицах. Ниже ошибки, из-за которых ИИ потом предлагает «лишние экраны» или ведет автоматизацию не в ту сторону.

1) Описывают «идеальный процесс», а не реальный

Часто люди сразу начинают рассказывать, как должно быть по регламенту. А в жизни есть обходные пути: «если менеджер занят, пишет ассистент», «если клиент в чате, не звоним», «если сумма маленькая, согласование пропускают». ИИ не сможет учесть это, если вы это не зафиксировали.

2) Смешивают разные кейсы в один сценарий

«Обработка заявки» для нового клиента, для постоянного и для проблемного долга может выглядеть похоже только в начале. Если склеить все в один поток, получится каша: лишние развилки, непонятные правила и спорные шаги. Лучше выбрать один самый частый кейс, а остальные добавить как отдельные варианты.

3) Пропускают исключения и ручные проверки «на опыте»

Самые важные детали обычно звучат так: «мы всегда еще проверяем…» или «если что, на всякий случай…». Это и есть реальные правила. Например: «если номер выглядит странно, ищем в базе вручную» или «если клиент нервничает, переносим на звонок руководителю». Такие моменты лучше записывать прямо в виде условий.

4) Заменяют шаги общими словами

Фразы вроде «обработать запрос» или «проверить данные» ничего не объясняют. Нужна конкретика: что именно проверяем, где, по каким признакам и что делаем при результате A или B. Иначе ИИ не поймет, какие действия автоматизировать, а какие оставить человеку.

5) Сразу обсуждают интерфейсы вместо входов, выходов и правил

Когда начинают с экранов, разговор быстро уходит в кнопки и поля. А потом выясняется, что не определены входы (откуда берется информация), выходы (что должно получиться) и правила (когда какой шаг нужен). Если вы используете TakProsto.ai, полезнее сначала описать логику и данные, а интерфейс уже подстроится под это.

6) Не фиксируют ответственность и точки передачи

«Кто делает шаг?» - обязательный вопрос. Частая поломка процесса именно в передаче: менеджер ждет бухгалтера, бухгалтер ждет подтверждение, никто не понимает, кто последний держал задачу. Отметьте, где меняется ответственный и чем подтверждается передача (сообщение, отметка, статус, комментарий).

Короткая проверка себя: после описания должно быть понятно, какой сигнал запускает процесс, кто делает каждый шаг, какие есть условия и что считается готовым результатом.

Короткий чеклист перед тем, как просить ИИ об автоматизации

Перед тем как просить ИИ предложить автоматизацию, важно, чтобы ваш разбор ручного процесса «как есть» был достаточно точным. Не идеальным, а пригодным для работы: чтобы по нему можно было собрать MVP без десятков уточняющих вопросов.

Главный тест простой: если завтра эту задачу будет делать новый человек, сможет ли он пройти процесс по вашему описанию и не потеряться.

Проверьте себя по чеклисту:

• есть один реальный кейс, разобранный от начала до конца (например, конкретная заявка клиента из чата, которая дошла до оплаты или отказа)
• каждый шаг описан в формате: вход (что пришло), действие (что сделали), выход (что получилось) и ответственный (кто делает)
• на развилках отмечено решение «да/нет» и что происходит в исключениях (нет ответа, нет данных, клиент передумал, ошибка в документе)
• собраны живые артефакты: шаблоны сообщений, файлы, формы, таблицы, которые реально используют сотрудники
• понятен минимум данных: что нужно хранить постоянно (карточка клиента, статус, история контакта), а что можно не хранить (временные заметки, черновики)

Отдельно зафиксируйте ограничения для MVP: какие экраны точно не нужны, что можно оставить в одном окне, какие действия должны быть в один клик и за какой срок вы хотите получить первую рабочую версию.

Следующие шаги: от описания к рабочей автоматизации

Когда шаги процесса «как есть» уже собраны, не пытайтесь сразу «сделать идеально». Сначала нужен понятный план и быстрый прототип, который можно показать тем, кто реально делает работу.

1) Попросите ИИ составить план MVP

Скопируйте ваш список шагов, роли (кто делает), входы и выходы (что получаем на каждом шаге) и попросите ИИ предложить MVP: какие 2-3 функции дадут максимум пользы в первую очередь. Отдельно попросите указать, какие данные нужно хранить и какие проверки обязательны, чтобы не пропустить ошибки.

Хороший результат выглядит как короткий план на 1-2 недели с понятными статусами и правилами, а не как попытка «переписать весь процесс целиком».

2) Соберите прототип и закройте спорные места

Дальше лучше действовать через быстрые уточнения. Прототип может быть простым: форма, список заявок и карточка с действиями. После первого прогона соберите 5-10 вопросов, которые всплыли, и уточните их у исполнителей.

Пример спорного места: «кто должен перезвонить клиенту, если менеджер занят?» или «что делать, если в чате нет номера телефона?». Такие вещи лучше решить до разработки, иначе потом действительно появятся лишние экраны.

Чтобы не разрастись, держите фокус на минимуме:

• один главный объект (например, заявка) и его статусы
• 3-5 полей, без которых нельзя работать
• 2-3 действия, которые реально делают каждый день
• одно место для комментариев и истории

3) Выберите, где это жить: веб, мобильное, сервер

Часто хватает одного веб-приложения: удобно руководителю и быстро править. Мобильное приложение имеет смысл, если сотрудники работают «в поле» и им нужны пуши, камера или офлайн. Серверная часть нужна там, где есть интеграции, правила и хранение данных.

Если вы собираете это в TakProsto (takprosto.ai), можно идти тем же путем: сначала описать процесс в чате и получить план в режиме планирования, затем собрать веб, сервер или мобильное приложение. А когда нужно продолжить работу вне платформы, полезно, что там поддерживается экспорт исходного кода и есть снимки с откатом.