Ручная обработка запросов на обслуживание — это вечные звонки, потерянные письма и бесконечные уточнения. Особенно в крупных компаниях, где сотрудникам ежедневно нужна помощь ИТ-поддержки и хозяйственной службы. Поэтому сегодня в блоге ЛАНИТ на Хабр поделимся, как мы разрабатывали систему, которая облегчила работу канцелярии, с какими вызовами столкнулись и каких результатов удалось достичь.

Для центральной ИТ-службы и административно-хозяйственного отдела (АХО) ЛАНИТ мы уже внедрили систему Service Desk. Теперь вместо поиска ответственных или согласования через чаты сотрудники могут быстро заказать настройку рабочего места или доступ к корпоративным сервисам; вызвать уборщицу или грузчика в несколько кликов; оформить гостевой пропуск для автомобиля без долгих согласований.

Когда сотрудники канцелярии ЛАНИТ увидели, как работает Service Desk для ИТ и АХО, они захотели аналогичное решение для своих задач. Это неудивительно – их работа связана с критически важными документами: договорами, счетами, трудовыми книжками, личными делами сотрудников. Ведь любая ошибка или задержка могут обернуться серьезными проблемами. 

Какие процессы требовали автоматизации

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

1. Курьерская доставка документов. Ежедневно отправляется от 5 до 20 документов по Москве и области, поэтому критически важен четкий контроль сроков и маршрутов.

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

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

4. Работа с архивом. Постоянные запросы на получение и возврат документов создают риск потери или задержек при ручном управлении, что требует надежной системы учета.

Как работали раньше

Весь процесс держался на ручном управлении:

• заявки приходили в почту и в чаты;

• для отчетности данные вручную сводили в таблицы.

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

Как устроен процесс обработки заявки в сервисных подразделениях

Независимо от того, куда подается запрос — в ИТ, АХО, канцелярию или юридический отдел, — обработка заявки следует единой логике. Разберем ключевые этапы на примере схемы.

Начальный этап — регистрация — является фундаментом всего процесса. Заявка может поступать через различные каналы: специализированную информационную систему (наиболее эффективный вариант), электронную почту или даже в бумажном виде. Критически важно на этом этапе зафиксировать два ключевых параметра: кто именно подает запрос (с указанием отдела и контактных данных) и в чем состоит суть проблемы или задачи. Пропуск или нечеткое указание этих деталей почти гарантированно приведут к проблемам на последующих этапах.

После регистрации заявка проходит маршрутизацию — процесс определения ответственного исполнителя. В подразделениях, где работают специалисты разного профиля, правильное распределение задач становится особенно важным. Например, в ИТ-службе сначала проводится предварительная диагностика проблемы (аппаратная часть, сетевое подключение или программное обеспечение), после чего заявка направляется соответствующей рабочей группе. В АХО запрос автоматически распределяется между сантехниками, электриками или плотниками в зависимости от характера проблемы. Аналогичный принцип работает в канцелярии, где разные сотрудники отвечают за доставку корреспонденции, работу с архивом или закупку канцтоваров. Дополнительно на этом этапе происходит классификация по срочности и типу задачи, что помогает расставить приоритеты в работе.

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

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

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

Старт проекта: неожиданно детальное ТЗ от канцелярии

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

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

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

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

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

Проанализировав все требования, мы спроектировали систему и приступили к работе.

Ход работ: итеративная разработка по Agile

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

Такой подход оказался эффективным по нескольким причинам.

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

2. Для заказчика — он регулярно видел прогресс и мог оперативно давать обратную связь.

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

Неожиданный поворот: когда Agile встречает реальность

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

• заказчики часто меняют требования в ходе проекта;

• не всегда могут четко сформулировать свои потребности;

• постоянно вносят новые пожелания.

Однако в этом проекте мы столкнулись с обратной ситуацией. В ходе тестирования мы сами выявили несколько моментов, требующих доработки, особенно в части функционала курьерской доставки.

Проблема ручного планирования маршрутов

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

• анализировать все заявки вручную;

• сопоставлять адреса доставки и сроки;

• использовать  карту города на втором мониторе, пытаться построить оптимальные маршруты;

• учитывать перенесенные с предыдущих дней доставки.

Этот процесс требовал значительных временных затрат и часто приводил к неоптимальным маршрутам. Особые сложности возникали с:

• распределением доставок между курьерами;

• учетом временных окон;

• включением перенесенных отправок в текущий график.

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

Конечно, вручную спланировать маршруты для нескольких курьеров и пары десятков адресов — задача выполнимая. Но мы же инженеры! Нам хотелось создать по-настоящему удобное и максимально автоматизированное решение.

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

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

Во-первых, это долго. Нужно подключать внешнюю ГИС-систему, или разворачивать локальную, или подключать модуль для отображения карты. Многие внешние системы имеют платные API, а бесплатно позволяют только отобразить точку на карте. Нам же нужно было строить маршруты и высчитывать расстояние между точками.

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

Поэтому мы пошли другим путём.

1. Взяли базу адресов с Mosopen.ru. 

2. На форме регистрации реализовали выбор адреса из списка (доставки идут не только по Москве, но и по области).

3. Сформировали базу улиц Москвы и городов Подмосковья, куда ездят курьеры.

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

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

Один курьер едет в Королев, за МКАД (выделено курсивом), а у второго целых шесть доставок, три в центре и три на юге (если в один район несколько доставок, добавляем цифру). Здесь мы использовали особенность Москвы: названия большинства районов совпадают со станциями метро. Поскольку станции метро у всех на слуху, достаточно просто знать район — и можно легко сопоставить адреса, быстро построив оптимальный маршрут.

С точки зрения трудозатрат решение оказалось крайне эффективным:

• реализация заняла несколько недель;

• альтернативный вариант с «игровой» стратегией потребовал бы несколько человеко-месяцев работы;

• фактическая эффективность маршрутизации при этом не пострадала.

Неочевидные сложности районного подхода

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

1. Пограничные адреса — некоторые здания находятся на границе районов, что создает неоднозначность в определении принадлежности. 

2. Транспортная изолированность — географически близкие районы иногда имеют плохую транспортную связность, особенно в промзонах.

3. Длинные магистрали —  например, проспект Мира, который проходит через несколько районов от Садового кольца до МКАД.

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

Техническая реализация

Для наполнения системы данными мы:

1. с  помощью Selenium спарсили данные с mosopen.ru в локальную базу данных;

2. разработали Python-скрипты для поэтапного переноса:

   • сначала загружали округа и получали их ID,

   • затем создавали JSON с районами и привязкой к округам,

   • и наконец, загрузили улицы с привязкой к районам.

После согласования с заказчиком мы исключили неактуальные округа (итого получилось  9 округов, 119 районов, 4008 улиц, города Подмосковья).

Решение проблемы длинных улиц

Для адресов, проходящих через несколько районов, мы реализовали бизнес-правило, отображающее улицы в формате: <Название улицы> (<Район>). Это позволило однозначно идентифицировать принадлежность каждого адреса при сохранении простоты интерфейса.

Вторая наша идея оптимизации – Telegram-бот

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

Возникали следующие проблемы:

• приходилось обзванивать всех курьеров;

• курьеры часто находятся в метро и не всегда доступны;

• каждый использует разные мессенджеры (телефон, WhatsApp, Telegram).

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

Как это работает:

• курьер получает маршрутный лист в Telegram;

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

• выполненные заказы автоматически перемещаются вниз списка.

Теперь вместо бумажной пачки документов курьер получает удобный интерактивный список в мессенджере.

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

Система не имела доступа в Интернет, поэтому для взаимодействия с Telegram реализовали отдельный сервис. Бот был внедрен на Python с использованием библиотек aiogram и aiogram-dialog, которые значительно упрощают разработку.

Архитектура бота:

• диалоги – сохраняют контекст общения и обрабатывают цепочки команд, позволяя создавать сложные интерактивные сценарии взаимодействия;

• окна – представляют различные панели или разделы интерфейса, которые отображаются пользователю в зависимости от контекста;

• виджеты – реализуют интерактивные элементы (кнопки, формы, поля ввода), делая бота более удобным для пользователей.

Изначально функционал разрабатывался только для курьеров, но позднее по запросу заказчика была добавлена операторская часть. Благодаря гибкости aiogram-dialog это удалось реализовать без увеличения запланированных трудозатрат.

Для реализации уведомлений курьеру был разработан отдельный микросервис на FastAPI. Его задача — передавать сообщения из системы к API Telegram (напомним, что сама система не имеет прямого доступа в Интернет).

Вывод

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

Статья написана в соавторстве с @VladislavZh.