Почему нельзя автоматизировать заявку, пока не понятен ее маршрут

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

Проблема была не в том, что не было кабинета

После первых заявок и ручной работы в Telegram и таблицах естественная мысль звучала просто: надо делать свою систему.

Мысль понятная. И опасная.

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

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

С чего на самом деле началась автоматизация

Автоматизация INSAL началась не с разработки кабинета. Она началась с консультаций и разбора бизнес-процесса.

Мы начали проговаривать, как именно живет заявка. Откуда она приходит. Кто берет ее в работу. Где начинается согласование. Какие данные клиент обязан дать сразу, а какие можно уточнить позже. В какой момент заявка перестает быть просто интересом и становится заказом. Кто отвечает за следующий шаг. Где процесс зависает. Где теряется контекст.

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

Например, очень быстро выясняется, что даже простые вещи люди понимают по-разному. Для одного менеджера заявка уже готова к следующему этапу, для другого в ней не хватает половины данных. Один считает, что после уточнения параметров должен писать клиенту менеджер, другой ждет, что клиент сам вернется с ответом. В ручной работе такие расхождения могут жить долго. В системе — уже нет.

Что дает разбор процесса на блок-схеме

Блок-схема — не украшение для презентации. Это способ поймать реальность за рукав.

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

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

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

Автоматизация равна оптимизации

В какой-то момент сформулировалась очень простая мысль: автоматизация = оптимизация бизнес-процессов.

Если процесс кривой, автоматизация не делает его хорошим. Она делает его быстрым. А быстрый бардак — это не достижение. Это просто бардак с интерфейсом.

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

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

Вот с этого и начинается взрослая автоматизация.

Какие данные действительно нужны для заявки

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

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

Это кажется очевидным. Но в реальности именно на таких вещах процесс и ломается. Если обязательные данные не определены заранее, менеджер начинает собирать их вручную. Клиент отвечает кусками. Часть информации теряется в переписке. Дальше все живут в режиме «сейчас уточним». А потом удивляются, почему заявка идет медленно.

Какой каркас ролей выбрали на старте

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

На старте ролевая модель получилась максимально простой: директор, менеджер, клиент.

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

Простая модель помогала не утонуть в лишней сложности. Для стартовой версии этого хватало.

На короткой дистанции.

Первый архитектурный прокол

И вот здесь был наш первый серьезный прокол.

Уже тогда стоило настаивать на более гибкой системе прав — такой, где можно добавлять новые роли без переделки всего контура. Потому что если компания растет, новые роли появятся почти неизбежно. Руководитель направления. Операционный сотрудник. Специалист, который видит только часть заявок. Отдельный участник согласования. Это не вопрос фантазии. Это вопрос времени.

Но в случае INSAL победил бюджет. И это факт.

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

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

Почему система прав не может быть раз и навсегда

В бизнесе почти ничего не стоит на месте. Особенно процессы и роли.

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

То же самое происходит и с самим процессом. Растет поток заявок. Меняются требования клиентов. Появляются новые внутренние сценарии. Давит рынок. Меняется регуляторика. Подтягиваются новые технологии. Следовательно, и система, которая обслуживает процесс, должна уметь меняться вместе с бизнесом.

В информационных системах главное не то, что работает сейчас. Главное — насколько безболезненно это можно поменять потом.

Если система не умеет меняться вместе с бизнесом, она быстро превращается из опоры в тормоз.

Почему не начали с интерфейса

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

Поэтому на старте пришлось сделать правильный выбор: не начинать с дизайна.

Сначала — маршрут заявки. Потом — обязательные данные. Потом — роли. Потом — права доступа. И только после этого уже можно обсуждать, как все это будет выглядеть в интерфейсе.

Это не потому, что дизайн не важен. Важен. Но в первом этапе автоматизации он не главный. Главная ценность — в рабочей архитектуре. В системе, которая соответствует реальной логике бизнеса, а не рисует красивую витрину поверх неразобранного процесса.

Как начал рождаться каркас кабинета

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

Не как набор экранов «на вырост». Не как попытка сделать экосистему под все случаи жизни. А как рабочий инструмент под конкретный сценарий: формирование заявки на выкуп товара.

Каркас был очень приземленный. Форма заявки с обязательными полями. Понятная логика заполнения. Видимость данных по ролям. Переход между этапами без ручного пинг-понга между чатом и таблицей. И главное — понятный следующий шаг для клиента и менеджера.

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

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

Вот в этот момент автоматизация и стала реальной.

Что этот этап дал на уровне мышления

Самый важный результат этого этапа был даже не в том, что появился каркас будущего кабинета.

Бизнес начал думать иначе.

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

Это и есть настоящий переход. В момент, когда бизнес перестает считать ручной хаос нормой и начинает видеть в нем прямое ограничение роста.

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