Как понять, какой процесс сильнее всего тормозит компанию
Автоматизация бизнес-процессов начинается не с выбора программы и не со списка задач, которые всем надоели. Сначала нужно найти ограничение — участок работы, из-за которого компания теряет скорость, деньги или возможность обслужить больше клиентов.
Раздражающий процесс и реальное ограничение часто выглядят похоже. Например, менеджеры могут жаловаться, что дважды переносят данные из письма в таблицу. Это неудобно, но занимает несколько минут в день и почти не влияет на продажи. А согласование коммерческого предложения может не вызывать громких жалоб, хотя из-за него клиент ждёт ответа двое суток и уходит к более быстрой компании.
Поэтому я смотрю не на громкость жалоб, а на последствия. Сильнее всего тормозит тот процесс, после которого накапливается очередь, возникают регулярные задержки или останавливается следующая часть работы. Если отдел продаж быстро получает заявки, но долго готовит расчёты, ускорение рекламы только увеличит очередь. Если заказы оформляются без задержек, но производство поздно узнаёт об изменениях, проблема находится уже не в продажах.
Полезно проследить путь одной типичной задачи от начала до конца. Для продажи это может быть путь от обращения до оплаты. Для операционной работы — от поступления заказа до его исполнения. Для обслуживания — от сообщения клиента до закрытия вопроса. На каждом переходе стоит отметить, кто принимает задачу, сколько она ждёт, что приходится уточнять и где информация вводится повторно.
Особенно показательны четыре признака: очередь, частые возвраты на доработку, зависимость от одного человека и потеря информации между отделами. Если один из них возникает регулярно и влияет на следующий этап, передо мной уже не просто бытовое неудобство, а возможная точка потерь.
Какие потери нужно посчитать до начала автоматизации
До запуска полезно сравнить стоимость текущего процесса с ценой проблемы, которую предстоит решить. Точный финансовый отчёт для этого не всегда нужен. Часто достаточно разумной оценки, основанной на нескольких неделях наблюдений.
Первая категория — рабочее время. Я считаю не только минуты на основное действие, но и поиск информации, исправление ошибок, ожидание ответа, повторный ввод данных. Если сотрудник заполняет документ десять минут, а затем ещё два человека проверяют и уточняют его, стоимость процесса складывается из времени всех участников.
Вторая категория — задержки. Здесь важно понять, что происходит с бизнесом, пока задача ждёт. Поздний ответ может снижать вероятность продажи. Задержавшееся согласование мешает начать работу. Медленная передача сведений на склад приводит к переносу отгрузки. Не каждую задержку можно точно перевести в деньги, но можно посчитать её частоту и среднюю продолжительность.
Третья категория — ошибки и переделки. Нужно зафиксировать, сколько задач возвращается, почему это происходит и какие дополнительные действия требуются. Одна опечатка может ничего не стоить. Неверная цена в предложении или пропущенная заявка уже создаёт прямые потери, особенно если такие случаи повторяются.
Четвёртая категория — упущенный объём. Иногда команда справляется с текущей нагрузкой, но не может принять больше заказов без найма новых людей. Тогда ограничение проявляется не в явных убытках, а в потолке производительности.
Считать лучше в понятных единицах: часы сотрудников, количество задержанных задач, доля возвратов, число потерянных обращений. Денежную оценку стоит добавлять только там, где связь действительно прослеживается. Иначе красивое число создаст ложную уверенность, но не поможет принять решение.
Стоит ли автоматизировать процесс, если сотрудники выполняют его по-разному
Различия сами по себе не запрещают автоматизацию. Сначала нужно понять, почему сотрудники действуют по-разному. Иногда у процесса просто нет общего порядка: каждый хранит файлы в своём месте, по-своему называет статусы и запрашивает разные сведения. Автоматизировать такой хаос целиком опасно — система закрепит противоречия и сделает их менее заметными.
В другой ситуации различия оправданы. Например, постоянному клиенту может не требоваться та же проверка, что новому. Срочный заказ проходит по отдельному маршруту. Обращения с разной темой передаются разным специалистам. Здесь не нужно насильно сводить всё к одному сценарию. Нужно выделить общую часть и явно описать допустимые исключения.
Для автоматизации подходят повторяемые действия с понятным входом и проверяемым результатом: регистрация обращения, создание задачи, перенос согласованных данных, уведомление ответственного, подготовка типового документа. Неподходящий кандидат — работа, где решение каждый раз зависит от незафиксированного контекста, профессионального суждения или сложных переговоров.
До запуска я бы попросил нескольких сотрудников отдельно показать, как они выполняют одну и ту же задачу. Не рассказать «как положено», а пройти реальный пример. Так становятся видны расхождения, которые не отражены в регламентах.
После этого можно разделить действия на обязательные, вариативные и спорные. Обязательные автоматизируются первыми. Вариативные превращаются в явные ветки процесса. Спорные лучше временно оставить человеку и собрать больше наблюдений. Контроль человека особенно нужен там, где ошибка влияет на деньги, обязательства перед клиентом или доступ к чувствительной информации.
Как выбрать небольшой, но показательный первый проект
Хороший первый проект должен быть ограниченным по размеру, но связанным с заметным результатом. Автоматизация одной редкой операции может быть простой, однако ничего не покажет бизнесу. Попытка сразу перестроить продажи, склад и обслуживание даст обратную проблему: слишком много участников, исключений и причин возможного сбоя.
Я бы выбирал законченный фрагмент процесса с ясным началом и концом. Например: обращение поступило, зарегистрировалось, получило ответственного и появилось в рабочей очереди. Или: согласованные данные о заказе переданы из одной системы в другую, а сотрудник получил подтверждение. Такой фрагмент можно наблюдать отдельно и сравнивать до и после запуска.
В состав первого проекта входят не только автоматические действия. Нужны источник данных, правила обработки, место назначения и способ увидеть ошибку. Источник — это то, откуда приходит задача: форма, письмо, таблица или учётная система. Правила определяют, что делать с полученными сведениями. Место назначения — куда попадёт результат. А журнал событий, то есть обычная запись выполненных операций, помогает понять, что прошло успешно, а что требует внимания.
Показательность создаёт связь с исходной потерей. Если компания теряет обращения, проект должен показать, уменьшилось ли число пропусков. Если сотрудники заняты переносом данных, нужно увидеть, сколько ручных действий исчезло. Если задерживается передача заказов, измеряется время между двумя этапами.
Границы проекта лучше описать заранее: какие случаи он обрабатывает, какие оставляет сотруднику и что происходит при нехватке данных. Тогда первая версия остаётся небольшой, но её результат можно честно оценить.
По каким признакам оценивать результат после запуска
Результат стоит проверять по тем же показателям, которые были зафиксированы до начала. Иначе после запуска останется только общее впечатление: стало удобнее или, наоборот, непривычно. Оно полезно, но не заменяет сравнение.
Основной показатель должен отражать исходную проблему. Это может быть время прохождения задачи, количество пропущенных обращений, доля возвратов на исправление или число ручных операций. Рядом нужны защитные показатели: не выросло ли количество ошибок, не появились ли новые задержки и не приходится ли сотрудникам обходить систему вручную.
Важно смотреть и на устойчивость. Процесс может хорошо работать на типичных случаях, но ломаться при неполных данных, повторной заявке или временной недоступности другой системы. Такие события не обязательно означают провал проекта. Они показывают, какие исключения нужно учесть перед расширением.
Ещё один признак — фактическое использование. Если сотрудники продолжают вести параллельные таблицы или перепроверяют каждое действие, значит, они не доверяют результату либо система не закрывает важную часть работы. Причину лучше выяснить по конкретным примерам, а не объяснять всё сопротивлением изменениям.
Первый шаг можно сделать без покупки платформы и большого проекта. Выберите один процесс, возьмите несколько недавних задач и восстановите их путь по времени: где каждая ждала, возвращалась, теряла данные или требовала повторной работы. Если одна и та же потеря повторяется, её можно измерить, а границы участка понятны, это хороший кандидат для проверки автоматизации.