Прием заявок до автоматизации: проблема и поиск решения
Один из наших клиентов — крупнейшая частная страховая компания, в которой работает несколько тысяч сотрудников. У нее большой сайт и много цифровых продуктов, например калькуляторов страхования. Они беспрерывно улучшаются и дорабатываются благодаря обратной связи от клиентов, а также по требованиям законодательства и регулятора страхового рынка.
Несмотря на то что в своей работе мы используем таск-трекер, не все задачи ставились в нем. Это связано с тем, что некоторые задачи были слишком маленькими, а иногда подключались новые отделы со стороны заказчика. В таких ситуациях быстрее и проще написать в почту.
Мы выделили специальный ящик и специалистов поддержки первой линии, которые быстро реагировали на сообщения и решали вопросы самостоятельно, если могли, или ставили задачу в таск-трекер на нужного специалиста. Но в какой-то момент таких задач стало слишком много. Мы поняли, что горизонтальное масштабирование и увеличение количества специалистов первой линии — тупиковый вариант.
Нужно было менять сами процессы так, чтобы то же количество людей могло обрабатывать больше задач и при этом тратить меньше сил. Поэтому стали искать решение.
На ретроспективах мы опрашивали специалистов, которые работали с входящими запросами, пробовали категоризировать и классифицировать задачи в таск-трекере по определенным признакам.
Выяснили, что есть много типовых задач. Они мало чем отличались друг от друга и всегда проходили один и тот же поток, требовали одинаковых действий и получали плюс-минус одинаковый результат.
Эксперименты и автоматизация рутины
Проверка гипотез и возможных вариантов автоматизации заняла несколько лет. За это время накопился достаточный бэклог идей. Мы провели вместе с командой Research and Development (R&D) AGIMA несколько мозговых штурмов и стратегическую сессию. На них придумали решения, выдвинули гипотезы и составили план их реализации.
Решили использовать инструменты кастомизации в таск-трекере. Для начала нужно было придумать алгоритм работы. Это взяли на себя руководители проектов, потому что у них был необходимый опыт приема заявок. Также в процессе участвовали системные аналитики, которые помогали все формализовать и описать в виде диаграмм последовательности. Реализацией занимались штатные программисты-автоматизаторы.
После создания алгоритма мы адаптировали таск-трекер под наши задачи: использовали привязанные к функционалу чек-листы и самописные аддоны, теги, автоматизацию перевода статуса и смены исполнителя, кастомизированные поля.
Также внедрили стандарты, которые являются залогом автоматизации и формализации процесса и показывают критерии отбора задач. Например, что должно быть в задаче на момент выхода из оценки в реализацию или из реализации в тестирование.
Каждая фича решала определенную задачу. Например, поля помогли нагляднее читать тикет и работать с ним большому количеству людей. В нашей компании много сотрудников, они периодически уходят в отпуск, часто приходят новые. Важно, чтобы любой человек из команды мог взять тикет и понять, что с ним делать.
Перед стартом работы над задачей в разработке нам необходимо максимально подробно ответить на все возможные вопросы, используя автоматические и ручные чек-листы. Мы знали, что нужно спросить и что потребуется потом.
Что мы автоматизировали и какие результаты получили
Мы автоматизировали различные типы задач. Например, задачи на выгрузку логов, процессы планового техобслуживания, задачи по обновлению контента и комплексные работы.
Задачи на выгрузку логов
Сотрудник страховой хочет получить логи по клиенту, который уже обращался в службу поддержки, потому что, например, не смог продлить или купить полис.
Все необходимые данные у страховщика есть, потому что клиент оставляет их в форме обратной связи. По сути, запрос нужно перемаршрутизировать технической команде.
По таким запросам не нужно ничего уточнять — они и так понятны, поэтому их решили автоматизировать в первую очередь.
Теперь заявку по логам перенаправляет в таск-трекер сотрудник страховой компании. Все логи практически полностью автоматизированы и идут отдельно. Входящая заявка попадает в отдельный swim-lane только для этой темы и отправляется сотруднику AGIMA с необходимой экспертностью. На этом этапе человек нужен, только если по заявке не хватает данных.
Поскольку логов копится очень много, они по расписанию выгружаются на отдельные серверы. Логи структурированы по продуктам и дате создания. Когда специалисту приходит заявка, он запускает скрипты, которые умеют получать необходимую информацию из хранилища сайта.
Скрипт ищет в нужном логе нужную запись по идентификатору пользователя и выгружает все найденные данные. Затем сотрудник получает результат и отписывается в тикет. Обратная связь уходит заказчику.
Наша компания работает над полной автоматизацией процесса. Сейчас она искусственно ограничена, потому что логи могут содержать чувствительные данные. Человек все равно нужен из-за технических ограничений и сложностей в политике безопасности.
Процессы обновления продуктов
Еще мы автоматизировали регулярные процессы технического обслуживания и обновления программных продуктов.
Выяснили, что эту работу всегда делаем примерно в одно время, с участием одних и тех же людей и с одинаковыми вводными данными. Собрали информацию, проанализировали, увидели необходимость расписания и создали автоматические задачи на обновление.
Раньше нужно было держать в голове или отмечать в календаре дату и вспоминать о том, что нужно провести обслуживание или обновить какой-то сертификат.
Теперь есть распорядок обслуживания и система нотификации в таск-трекере, который сам создает тикет в необходимое время на определенного человека и присылает ему на почту письмо с напоминанием. Сотрудник выполняет задачу и переводит ее в следующий статус. Затем задача проходит проверку и закрывается.
Комплексные работы, для которых нужно несколько специалистов
Мы поняли, что есть уникальные по содержанию задачи, у которых при этом всегда один и тот же процесс: сначала аналитика, дизайн, разработка, тестирование и релиз, а между ними валидация.
Раньше была одна большая доска в таск-трекере, на которой велись и двигались слева направо задачи, а статусы обновлялись на митингах.
После доработки функционала таск-трекера взаимодействие с каждым исполнителем таких задач идет по принципу конвейера, на котором максимально автоматизированы процессы. Задача приходит сотруднику автоматически, после ее выполнения исполнитель ставит галочки в чек-листе. Задаче присваивается новый статус, и она отправляется другому человеку. Менеджер теперь нужен не всегда, а только если есть вопросы, или задача нестандартная, или не хватает вводных данных.
Благодаря стандартизации количество согласований уменьшилось, поэтому мы можем назвать заказчику более точные сроки работы.
Средний показатель lead time от разработки до прода на проекте уменьшился с 120–130 дней до примерно 80. Мы видим возможность сократить его до 50. При этом важно помнить, что задачи разные по сложности и длительности. Некоторые закрываются одним днем, другие — одним часом.
Объем выручки, который генерируют менеджеры, увеличился почти на 30%. Также вырос объем проекта, но при этом с объемом задач успешно справляется то же количество менеджеров.
Год ушел на внедрение процессов, создание плагинов и их доработку. Сейчас мы в процессе реализации других идей. Некоторые задумки были масштабнее, чем конечная реализация, часть не сработала из-за технических ограничений таск-трекера. При этом все возможные однотипные задачи мы пытаемся автоматизировать любыми доступными способами.
Трансформация еще продолжается. Однако сейчас есть результат и понимание: количество людей в команде можно не увеличивать, а добиваться большей производительности благодаря автоматизации.
Дальнейшие планы
Сейчас мы хотим дать разработчикам возможность самим что-то кастомизировать для процесса работы. Предложение получило хороший отклик.
Еще планируем настроить интеграцию с почтой, чтобы по теме письма, слову или словосочетанию автоматически создавалась задача. Скрипт будет парсить информацию из почты и перекидывать ее в тикет, а затем отправлять ответ тому, кто обратился в техподдержку.
С какими сложностями мы столкнулись во время автоматизации
Внедрение новых процессов не обходится без сложностей — например, с людьми, так как не всем свойственен порядок, необходимый при автоматизации и стандартизации. Некоторым сотрудникам непривычно переводить тикеты в одни и те же статусы с необходимым для этого количеством информации, каждый раз писать комментарии, ставить галочки, заполнять необходимые поля.
Многие воспринимают перемены со скепсисом. При этом не все готовы вслух говорить о своих опасениях, в итоге сотрудники критикуют изменения или сопротивляются им, чтобы помешать их внедрению и обезопасить себя. В таких случаях встречаемся в переговорке или удаленно расшариваем экран, показываем процесс и реальную выгоду, чтобы человек сам убедился в полезности инструмента. Помогаем с выбором других задач.
Побороть страхи помогает открытость внутри компании, а также практика ретроспектив, командных встреч и обсуждений. Удается выяснить опасения и проработать страхи.
Сейчас мы постепенно трансформируем формат описания регламента и его подачи, чтобы меньше травмировать людей. Показываем новые идеи на ретроспективе или внутреннем демо.
Стараемся привлекать всю команду в работу над новыми решениями, чтобы собирать обратную связь и слышать новые идеи.
Процессы, которые можно автоматизировать
Автоматизация по умолчанию применима для однотипных задач: если мы автоматизируем тестирование, то используем одни и те же состояния в одной и той же последовательности. Здесь не требуется участие живого ума человека, достаточно описать сценарий.
По моему мнению, еще можно автоматизировать:
- Не процесс целиком, а его часть. Даже если цепочка действий уникальна, всегда можно упростить, автоматизировать, шаблонизировать ее части. Чтобы повторить удачно сработавшую практику, внедряются фреймворки управления проектом — шаблоны, по которым можно действовать и с большой вероятностью получить неплохой результат.
- Этап или какой-либо процесс внутри работ. Например, вместо того чтобы держать большой штат администраторов проекта, можно автоматизировать документооборот. Или хотя бы попробовать.
- Финансовый учет или согласование документов. Будет примерно один и тот же процесс: отметить, что задача выполнена, передать в бухгалтерию для оплаты, получить уведомление об оплате.
- Валидацию требований и внутреннюю валидацию с помощью ChatGPT и подобных ботов. Например, автоматизировать первичную валидацию полей в документации. Сейчас мы начинаем внедрять проверку того, что технические поля одинаково описаны по всему документу. Мы тестировали ChatGPT для этих задач, он прекрасно справляется. Поэтому его можно интегрировать в какие-то автоматические процессы и уйти от нудной работы — например, от проверки формулировок на 100 страницах.
Рекомендации тем, кто хочет повторить наш опыт
Для начала проанализируйте поток задач за год или два и попробуйте найти общее, сгруппировать их по каким-либо признакам.
Разделите задачи на требования, фичи и менеджмент, например. Ведите по ним разные доски, чтобы не отвлекать разработчиков менеджментом, а аналитиков сконцентрировать на требованиях.
Кастомизируйте доску, а затем сам тикет. Одинаковые вопросы можно вынести в обязательное поле тикета. Тогда сотрудник не сможет создать или передать задачу дальше, пока это поле не заполнено. Например, если нет подходящих тестовых данных для дальнейшей проверки задачи.
Собирайте обратную связь сотрудников, проводите ретроспективы. Узнайте, с какими трудностями сталкиваются сотрудники, от каких задач хотели бы избавиться. Скорее всего, современные инструменты автоматизации смогут помочь сотрудникам, что улучшит рабочие показатели.
