Как описать жизненный цикл заявки простыми предложениями: статусы, переходы, исключения и чеклист, чтобы получить корректный workflow без схем.
Workflow чаще ломается не из-за инструмента, а потому что процесс живет в головах. Один сотрудник считает, что «в работе» значит «уже назначен исполнитель», другой думает, что это «увидели и прочитали». В итоге задача застревает между людьми, а виноватых нет.
Кажется, что спасут схемы. Но их долго рисовать, они быстро устаревают и пугают тех, кто не любит диаграммы. А главное, многие просто не будут их читать, особенно если схема выглядит как карта метро.
Текстовое описание проще и честнее: вы договариваетесь о правилах обычными предложениями. Когда команда может одним абзацем объяснить, что происходит в каждом статусе и кто имеет право двигать заявку дальше, споров становится меньше. Это особенно важно, если жизненный цикл должен одинаково понимать заявитель, исполнитель и руководитель.
Простой пример: «Заявка создана. Диспетчер ее видит и либо назначает исполнителя и переводит в “Назначено”, либо возвращает на уточнение с комментарием». Это уже задает переходы и ожидания, даже без стрелок.
Подход работает почти для любого объекта, где есть путь от «появилось» до «закрыто»: заявки в сервис-деске, заказы, задачи, инциденты, согласования документов.
Если есть спорные случаи вроде «отменили», «вернули», «заморозили», текст помогает заметить их заранее. Тогда workflow получается не «красивым», а рабочим: понятным людям и пригодным для автоматизации.
Статус - это короткий честный ответ на вопрос: «Что сейчас происходит с заявкой?». Если человек открывает карточку и не понимает ситуацию за 2 секунды, статус выбран плохо.
Переход - событие, после которого статус меняется. Обычно это действие человека («согласовал», «взял в работу», «отправил на доработку») или понятное условие («истек срок ожидания ответа», «получили оплату»). Если нельзя назвать, что именно случилось, переход будет «мутным», и начнутся споры.
Когда описываете жизненный цикл, используйте бытовые формулировки. Хороший статус звучит так, как вы написали бы коллеге в чате: «ждем ответа клиента», «делаем установку», «на согласовании у руководителя».
Важно не путать режимы «делаем» и «ждем»:
Финальное состояние тоже должно быть однозначным. Часто полезнее не просто «Закрыто», а «Выполнено и принято» или «Отменено (причина известна)». Так выполненные заявки не смешиваются с теми, что остановились по дороге.
Пример: «Заявка на доступ к системе». Статусы: «Новая», «На согласовании», «Доступ выдан», «Ждем подтверждение от пользователя», «Закрыта». Переходы тоже простые: сотрудник отправил заявку, руководитель согласовал, админ выдал доступ, пользователь подтвердил.
Начинайте не со схемы, а с конца. Нужен один понятный стартовый статус и один, максимум два финальных. Так легче договориться о жизненном цикле так, чтобы его одинаково понимали исполнитель, автор и руководитель.
Старт обычно один: «Новая» или «Принята». Финалы тоже простые: «Выполнена» и, если нужно, «Отклонена» или «Отменена». Остальное добавляйте позже, когда появится реальная потребность.
Хороший признак здорового набора статусов: по статусу сразу понятно, что делать дальше и кто отвечает.
Для заявки (поддержка, ИТ, сервис): «Новая», «В работе», «Выполнена», «Отклонена».
Для заказа (интернет-магазин, закупка): «Создан», «Оплачен», «Отправлен», «Доставлен», «Отменен».
Это не универсальная «идеальная модель», но она помогает быстро зафиксировать базовую логику и не утонуть в деталях.
Статус почти всегда лишний, если никто не может одним предложением объяснить, чем он отличается от соседнего. Например, «В обработке» и «В работе» часто означают одно и то же. Еще один сигнал: статус существует только ради отчета, но не меняет действий, прав или обязательных данных.
Быстрый тест: спросите у двух людей из процесса, что должно измениться при переходе в этот статус. Если ответы расплывчатые, статус лучше убрать или объединить.
Чтобы получить понятный workflow, полезно писать не «список статусов», а короткие предложения про события и действия. Из такого текста легко собрать переходы, роли и проверки.
Рабочая формула: «Когда ..., переводим из ... в ... потому что ...». В ней сразу видно, что случилось, куда двигаемся и зачем.
Пример: «Когда пользователь подтвердил время визита, переводим из “Уточнение деталей” в “Запланировано”, потому что можно бронировать слот у исполнителя».
Чтобы правила не превращались в спор «на словах», добавьте ограничение: «Перевести может ..., если ...». Так фиксируются ответственность и минимальные условия.
Ожидание лучше описывать отдельно, иначе статусы расползаются на «Ждем ответа», «Ждем согласования», «Ждем оплаты» и так далее. Удобный формат: «Ждем ... до ...». Дедлайн важен, даже если он примерный.
Пример: «Ждем ответ от владельца системы до 17:00 следующего рабочего дня». Если ответа нет, сразу допишите, что делаем дальше: напоминаем, ставим паузу или возвращаем на уточнение.
Для финала используйте четкое условие: «Считаем выполненным, когда ...». Это убирает размытое «Готово», которое у каждого означает разное.
Пример: «Считаем выполненным, когда задача выполнена в системе и пользователь подтвердил результат, или прошло 2 рабочих дня без замечаний».
Чтобы текст легко превращался в workflow, каждое состояние можно дополнить короткими пометками: что обязательно написать в комментарии, какие сроки, кто отвечает и какие данные должны быть заполнены.
Когда жизненный цикл описан обычными фразами, следующий шаг - собрать из них точный workflow: порядок, роли и проверка логики. Это не про диаграммы, а про то, чтобы всем было ясно, что делать дальше.
Соберите статусы в один ряд и поставьте в естественном порядке: «Новая», «В работе», «На согласовании», «Готово», «Закрыта».
Для каждого статуса ответьте на три вопроса (по 1-2 фразы): как заявка сюда попадает, что считается нормальной работой в этом статусе, когда можно двигать дальше.
Выпишите переходы отдельными короткими строками в формате «Из [статус] в [статус]». Если переходов слишком много, значит статусы слишком общие или вы смешали разные процессы.
Для каждого перехода добавьте «кто переводит» и «при каком условии». Пример: «Из “В работе” в “На согласовании” переводит исполнитель, если приложены файлы и заполнено поле “срок”».
Прогоните весь путь от начала до конца и отдельно проверьте исключения. Ищите тупики (нельзя выйти) и «телепорты» (прыжок через важный шаг без причины).
Проверьте, что:
Одного списка статусов мало. Нужны правила переходов: кто переводит, что должно быть заполнено и когда это надо сделать. Иначе процесс будет «застревать» или прыгать назад без причины.
Начинайте с ролей, а не с должностей. Роль описывает действие в процессе. Часто хватает таких ролей: заявитель (создает и уточняет), исполнитель (делает работу), руководитель (согласует), поддержка (помогает с доступами и инцидентами), бухгалтерия (проверяет оплату и документы). Один человек может совмещать роли, но правило лучше привязывать именно к роли - так проще менять процесс.
Каждый переход удобно фиксировать одной фразой: «Роль X может перевести из A в B, если выполнено условие». Если сомневаетесь, задайте себе четыре вопроса: кто отвечает за следующий шаг, какие причины разрешают переход, что запрещено (например, заявитель не может ставить «Выполнено»), чем подтверждается результат (комментарий, вложение, номер счета).
Переход должен проверять минимум данных. Например: перед статусом «В работе» обязательны контакт, описание и приоритет; перед «Согласование» - сумма и статья; перед «Закрыто» - результат и подтверждение заявителя.
Сроки и SLA пишите простыми словами: «реагируем в течение 2 часов в рабочее время» или «закрываем за 2 рабочих дня, если не нужна закупка». Для исключений добавьте явное правило: «если ждем ответ, ставим “На уточнении”, и срок паузы не считается».
Уведомления тоже лучше привязывать к переходам. Например, заявителю - когда взяли в работу и когда нужен ответ; исполнителю - когда назначили и когда вернули на доработку; руководителю - когда требуется согласование.
Исключения чаще всего и ломают процесс не потому, что они сложные, а потому что их не называют вслух. На каждое исключение нужно одно простое предложение, где ясно: кто, когда и что делает.
Отмена - это не просто статус, а событие. Например: «Инициатор может отменить заявку до начала работ, указав причину». Причина нужна не для бюрократии, а чтобы потом отличить «передумали» от «ошибка в данных».
Возврат на доработку описывайте как движение назад с понятным адресатом: «Согласующий возвращает заявку исполнителю на доработку, если не хватает документов». И обязательно уточните, куда именно возвращаем: не «в начало», а в конкретный статус, где проблему реально можно исправить.
Статус «приостановлено» часто превращается в кладбище задач. Дайте ему смысл: «Заявка приостановлена, если мы ждем ответ или доступ, и у нее есть дата следующей проверки». Выход тоже фиксируйте: по событию (пришел ответ) или по сроку (проверяем раз в 3 дня).
С повторными обращениями тоже лучше договориться заранее. Например: если клиент создал две одинаковые заявки, одну закрываем как дубликат и в комментарии пишем номер основной. Если это повтор после закрытия, это новая заявка с пометкой «повтор».
Чтобы исключения работали, минимально зафиксируйте: кто может сделать действие, из какого статуса это разрешено, что обязательно заполнить (причина, комментарий, вложение), какой следующий статус ставится и что делаем при молчании (например, через сколько дней без ответа переводим в «ожидаем» или «закрыта без ответа»).
Ситуация простая: сотруднику нужно установить ПО на рабочий ноутбук или получить доступ к корпоративному сервису. Обычно это затрагивает ИТ и владельца бюджета, поэтому без согласования быстро начинается хаос: «я попросил», «мне обещали», «кто должен нажать кнопку».
Вот как может выглядеть жизненный цикл одной заявки обычными фразами, без схем. Статусы по цепочке: Новая -> На уточнении -> На согласовании -> В работе -> Готово -> Закрыта.
Заявка становится Новой, когда сотрудник отправил запрос. ИТ переводит в На уточнении, если не хватает деталей. Сотрудник добавляет данные, и ИТ отправляет в На согласовании. Руководитель или владелец сервиса подтверждает «разрешаю установку/доступ», после чего заявка попадает в В работе. Когда установка сделана или доступ выдан и проверен, ИТ ставит Готово. Сотрудник подтверждает, что все работает, и заявка уходит в Закрыта.
Чтобы переходы не были «на глаз», добавьте к каждому по одному триггеру: кто делает и что должно случиться. Например: «ИТ переводит в “На согласовании”, когда в заявке указаны устройство и дедлайн», или «Сотрудник переводит в “Закрыта”, когда проверил вход и запуск программы».
Чаще всего задержки возникают в двух местах: на уточнении (нет данных) и на согласовании (непонятно, кто согласует и до какого срока). Это лучше сразу прописать в правилах: у На уточнении есть срок ответа сотрудника, а у На согласовании - срок решения и однозначный результат «одобрено/отклонено».
Минимальные обязательные данные, без которых заявку лучше не двигать дальше: устройство и тип доступа, нужная версия ПО или сервис, причина и подразделение, дедлайн, согласующий (ФИО или роль).
Частая причина, почему workflow не работает: статусы и переходы придумывают «на будущее». На старте процесс выглядит умно, но через неделю люди начинают обходить правила, потому что они мешают работе.
Первая ловушка - слишком много статусов «на всякий случай». Если у вас 15-20 шагов, часть будет пустовать, а часть начнут использовать «как удобно». Лучше держать статусы крупными блоками, а детали фиксировать в полях (комментарий, причина, дедлайн).
Вторая ошибка - статусы как действия: «Проверяю», «Думаю», «Смотрю». Это описывает состояние человека, а не состояние заявки. Такие статусы невозможно проверить. Гораздо яснее звучат состояния, которые можно подтвердить фактом: «На проверке», «Ожидает согласования», «Ожидает данные от клиента».
Третья проблема - переходы без условий. Когда нет правил, непонятно, почему заявку нельзя двигать дальше или почему она внезапно перескочила этап. Минимум, который стоит зафиксировать: кто переводит, что должно быть заполнено и что считается результатом этапа.
Четвертая ошибка - нет финального критерия. Тогда закрывают «когда захотели»: кто-то после звонка, кто-то после реальной установки. Помогает одна фраза: «Заявка закрывается, когда выполнено X и подтверждено Y». Например: «ПО установлено, лицензия активирована, пользователь подтвердил в комментарии».
Пятая ошибка - нет пути назад. Без возврата в доработку любой сбой превращается в хаос: создают новую заявку или пишут в чат «ну просто доделайте». Нужен понятный обратный переход и причина: «Вернуть в доработку можно только из статуса “На проверке”, если не пройден тест или не хватает данных».
Чтобы жизненный цикл можно было потом без боли автоматизировать, проверьте текст на «собираемость».
Мини-тест на минуту: возьмите любой статус из середины и спросите «кто отвечает за следующий шаг и что именно он делает?». Если ответ укладывается в одно предложение, workflow, скорее всего, получится. Если всплывает «ну, дальше как обычно» или «смотря по ситуации», допишите условия и исключения.
Когда жизненный цикл описан простыми фразами, важно проверить, что эти фразы одинаково понимают люди, которые реально работают с процессом.
Соберите короткую встречу на 20-30 минут с 2-3 участниками: исполнитель, согласующий, тот, кто принимает результат. Пройдите текст по шагам и на каждый статус задайте один вопрос: что именно должно быть сделано, чтобы заявка могла перейти дальше.
Затем устройте пробный прогон на реальности. Возьмите 5-10 недавних кейсов и «прокатите» их по вашим статусам. Почти всегда всплывают мелочи: где-то не хватает шага про уточнение, где-то непонятно, что делать при молчании автора, где-то переход должен быть доступен только определенной роли.
Чтобы не появлялись разные версии, держите статусы и переходы в одном месте: один документ или одна карточка процесса. Любое изменение делайте через правку этого источника и короткое согласование.
Практичный порядок действий:
Если вы хотите быстро превратить такое текстовое описание в работающий процесс, TakProsto (takprosto.ai) обычно удобно использовать как «песочницу»: задать статусы и правила через чат, прогнать их на кейсах и при неудачной правке откатиться к снимку. Это помогает сначала стабилизировать базовый процесс, а уже потом наращивать уведомления, отчеты и более тонкие роли."}
Начните с простого: выберите один стартовый статус и один-два финальных, а между ними оставьте 1–3 рабочих состояния. Если по статусу не ясно, кто делает следующий шаг, значит статусов мало или формулировки размыты. Если люди путаются и выбирают «как привыкли», статусов слишком много или они дублируют друг друга.
Плохой статус не отвечает быстро на вопрос «что происходит прямо сейчас». Если два человека читают один и тот же статус и представляют разные действия, статус нужно переименовать или разделить. Хороший статус звучит как сообщение коллеге и описывает состояние заявки, а не настроение исполнителя.
Разделяйте их по смыслу: «делаем» означает, что есть исполнитель, который прямо сейчас отвечает за результат, а «ждем» означает, что работа остановилась и нужен внешний ответ или ресурс. «Пауза» отличается тем, что вы сознательно решили не продолжать до даты или условия, а не просто ждете в неопределенности. Это сильно уменьшает споры и скрытые просрочки.
Опишите переход одной фразой: что произошло, из какого статуса в какой переводим и почему. Затем добавьте, кто имеет право переводить и какое минимальное условие должно быть выполнено. Если вы не можете назвать событие, переход получится «мутным» и начнутся конфликты.
Привязывайте правила к ролям, а не к должностям: заявитель создает и уточняет, исполнитель делает, согласующий принимает решение, принимающий подтверждает результат. Один человек может совмещать роли, но правило должно описывать действие в процессе. Так проще менять команду и не переписывать весь workflow.
Делайте обязательными только те поля, без которых следующий шаг невозможен. Чаще всего это контакт и описание перед стартом работ, сумма и основание перед согласованием, а перед закрытием — результат и подтверждение. Если требовать слишком много данных «на всякий случай», люди начнут обходить процесс.
Сформулируйте SLA простыми словами: когда реагируем и за сколько закрываем при обычных условиях. Отдельно уточните, что происходит со сроком, когда заявка в ожидании ответа или на паузе, иначе вы будете спорить о просрочках. Главное — чтобы правило было понятно без трактовок.
Сразу договоритесь об одном понятном предложении для каждого исключения: кто может сделать действие, из какого статуса, что нужно указать и куда заявка попадает дальше. Для отмены почти всегда нужна причина, чтобы отличать «передумали» от «ошибка в данных». Для возврата на доработку важно возвращать в конкретный статус, где это реально исправить.
Назначьте для «приостановлено» четкий смысл и правило выхода: по событию или по дате проверки. Если у статуса нет следующего шага и ответственного, он быстро превращается в склад забытых задач. Лучше заранее прописать, что делать при молчании и как часто напоминать.
Сначала прогоните текстовый жизненный цикл на реальных кейсах и найдите тупики и «прыжки» через важные шаги. После этого добавляйте права, обязательные поля и уведомления, а не наоборот. Удобно делать это в среде, где можно быстро менять статусы через интерфейс и откатывать неудачные правки, чтобы процесс стабилизировался до автоматизации.
