Создание цифровой платформы сервисов поддержки и ИТ-инфраструктуры ресторанов сети Бургер Кинг.

Заказчик:
ООО БУРГЕР РУС
Руководитель проекта со стороны заказчика
Поставщик
SmartServiceDesk
Год завершения проекта
2021
Сроки выполнения проекта
Октябрь, 2020 - Сентябрь, 2021
Масштаб проекта
2679 человеко-часов
Цели

Главная цель: Создание эффективной и удобной для пользователей цифровой платформы по поддержке ресторанов и ИТ-инфраструктуры компании «Бургер Кинг»

Подцели:

1. Миграция на новую платформу

2. Формализация и автоматизация сервисов на новой платформе

3. Развитие ресторанных и ИТ- сервисов на обновленной платформе

4. Интеграция с Service Desk – системами подрядчиков

5. Интеграция с системами BI и отчетности

Уникальность проекта

Уникальными результатами проекта можно назвать следующие:
• Создан уникальный каталог услуг, хорошо понятный пользователям системы, включающий широкий спектр услуг для ресторанов, от услуг по ремонту кофемашин, ремонту мебели, перемещения и обслуживания киосков, взаимодействия с курьерскими службами до кадровых сервисов, согласования маркетинговых акций, а также традиционных ИТ-сервисов;
• Всего формализовано и автоматизировано более 200 предложений сервисов в Каталоге услуг;
• Автоматизирована маршрутизация запросов в зависимости от месторасположения ресторанов и выбранного сервиса как на стадии согласования, так и выполнения запросов. При этом количество ошибок маршрутизации запросов составляет менее 5% при общем количестве заявок в месяц от 20 до 30 тысяч;
• Компания смогла полностью отказаться от первой линии технической поддержки;
• Создана цифровая платформа для дальнейшего развития сервисов и повышения их качества, отвечающая современным требованиям.
Использованное ПО

Ivanti Service Manager powered by HEAT

Сложность реализации

1) Система является business critical для Бургер Кинг, и обновление системы должно было происходить без нарушения действующих процессов техподдержки компании. Поэтому особое внимание было уделено вопросам тестирования и качеству выполнения работ. Показателем высокого качества выполненных работ стало отсутствие проблем со своевременным вводом и эксплуатацией обновленной платформы.

2) переход на новую платформу с Ivanti Service Desk powered by LANDESK на Ivanti Service Manager powered by HEAT технологически является переходом на абсолютно новый продукт, поэтому все ранее автоматизированные на платформе Ivanti Service Desk powered by LANDESK процессы необходимо было настраивать с нуля с переносом всего ранее реализованного функционала на новую платформу с улучшением качества интерфейсов пользователя.

3) Наличие филиалов в различных часовых поясах приводит к сужению «технологических окон» для выполнения регламентных работ. Часть работ была выполнена в вечернее и ночное время, в период минимальной активности ресторанов.

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

Описание проекта

В конце 2020 года в компании Бургер Кинг было принято решение об обновлении существующей платформы оказания техподдержки, работавшей на базе Ivanti Service Desk powered by LANDESK. Основными причинами принятого решения стали: необходимость улучшения интерфейса пользователя, отсутствие возможности множественного выбора тикетов для их массовой обработки, проблемы с производительностью, проблемы со стабильностью почтового коннектора, отсутствие выпуска новых версий на базе платформы Ivanti Service Desk powered by LANDESK со стороны вендора.

Была проведена работа по выбору платформы для миграции, рассмотрены решения на плаформах Atlassian Jira, Naumen и др., включая обновленную платформу Ivanti Service Manager powered by HEAT. В результате была выбрана платформа Ivanti Service Manager powered by HEAT. Подрядчиком для выполнения работ был выбран SmartServiceDesk – подразделение АО ТРОНИК, предложивший разумное ценовое предложение с процессом внедрения по модели DevOps, специалисты которого обладают как глубокими знаниями и практическим опытом автоматизации различных бизнес- и ИТ-процессов, так и исключительными для России и СНГ знаниями и опытом настройки как системы Ivanti Service Desk powered by LANDESK, так и Ivanti Service Manager powered by HEAT.

Проект был реализован в 2 этапа:

1) миграция существующих процессов техподдержки ресторанов и ИТ-инфраструктуры

В рамках 1-го этапа были перенесены все ранее автоматизированные процессы техподдержки ресторанов и ИТ-инфраструктуры. Пользователи платформы начали работу в более современном удобном интерфейсе. Были устранены недостатки предыдущей версии.

2) развитие системы в направлении автоматизации ресторанных сервисов и сервисов поддержки ИТ-инфраструктуры.

Все работы были выполнены в удаленном режиме.

Дополнительно были проведены:

· Интеграционные работы с внешними системами Service Desk подрядных организаций, оказывающих услуги ресторанам,

· Интеграционные работы с имеющимися системами BI и отчетности

· Автоматизированы новые сервисы

Развитие платформы продолжается.

Расширяется перечень автоматизированных сервисов для ресторанов, доступных на платформе.

Также идет развитие услуг по управлению ИТ-инфраструктурой. В ближайшее время планируется интеграция Ivanti Service Manager powered by HEAT с Microsoft Endpoint Configuration Manager (formerly System Center Configuration Manager (SCCM) и автоматизация процесса инсталляции программного обеспечения на рабочее место пользователя.

Одним из возможных направлений развития системы в перспективе является внедрение средств ИИ для анализа и классификации запросов пользователей и интеграция Системы с мессенджерами и чат-ботами для повышения качества сервисов..

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

География проекта
Сеть ресторанов во всех регионах России и ряде стран СНГ (порядка 1000 ресторанов)
Коментарии: 8

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    16.11.2021 00:25

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

  • Мария Гороховская
    Рейтинг: 151
    ООО БУРГЕР РУС
    Руководитель проектного ИТ офиса
    17.11.2021 15:04

    Добрый день,

    Подходили к задаче несколько раз с учетом очень слабой грамотности со стороны различных инициаторов, которых у нас около 30 000.

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

    Структура каталога достаточно простая:
    1 – Раздел
    2 – Услуга
    3 – Категория
    4 – Подкатегория
    5 – Дополнительные поля

    1ый уровень «Раздел» чисто пользовательский. При собеседованиях выяснили, что инициаторам проще всего понимать, что если техника, то это ИТ. Как пример. Поэтому независимо от того, что сломалось у компьютера, они ищут всегда помощи в ИТ, даже если на деле нет электричества в розетке. К определению, что же сломалось на самом деле мы приходим только на 4 уровне, где у нас настроено автоматическая маршрутизация уже на ответственный департамент. Для розетки это будет Эксплуатация.

    При использовании столь детального каталога с корректным выбором от пользователей, удалось достичь максимальной детализации проблемы, что на 90% исключило у нас использование 1ой линии поддержки. Тем самым мы автоматизировали назначения сразу на 2ую и даже 3ю линию и сократили сроки работ. Для каждого пользователя или группы в системе указан маршрут его заявок. Например, для ресторана Урала теми же розетками занимается не та группа, что в Москве. Местами эта «маршрутизация» включает десятки разных групп для одной проблемы. Сотни тысяч строк маршрутов, которые мы можем добавить, исправить и даже загрузить из экселя.

    Так же этот каталог развивается на постоянной основе и дает нам аналитику. Мы меняем группы в зависимости от их времени работы и даже качества. У нас больше 200 групп поддержки, львиная доля которых - это сторонние компании оказывающие услуги. Причем услуги как ИТ, так и Стройки. Внутренние отделы работают так же. У нас каталог содержит задачи от разработки и стройки до задача на создание заявки на оплату.

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

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

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

    Надеюсь, смогла ответить на вопрос. Если не совсем корректно поняла суть, уточните, пожалуйста. Попытаюсь детальнее уточнить.

    • Михаил Петров Мария
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      17.11.2021 16:02

      спасибо!

  • Роман Цыганков
    Рейтинг: 1055
    АВТОЗАВОД Санкт-Петербург
    Директор по информационным технологиям
    17.11.2021 15:24

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

    • Мария Гороховская Роман
      Рейтинг: 151
      ООО БУРГЕР РУС
      Руководитель проектного ИТ офиса
      22.11.2021 10:44

      Добрый день,
      Это был целый комплекс мер и решений. Описать каждое будет сложно. Расскажу про очевидное.

      Как писала в комментарии выше, у нас достаточно глубокий каталог из 4 уровней. Причем детализация растет от верхнего до нижнего уровня в сотни раз. В среднем на каждый тип обращения присутствуют 3-5 дополнительных полей, которые добавлялись для каждого отдельного раздела, категории и подкатегории. Каждое такое поле влияет на маршрут заявки и на решение по заявке. Функция первой линии по корректному отнесению обращения в таком случае оказалась не нужна. Мы оценили процент ошибок по каталогу и он не превышает 7-10%. Причем и этот 7-10% прорабатываются постоянно. Мы смотрим в какой услуге и уровне каталога возникает ошибка и либо детализируем каталог, либо добавляем очередное поле, которое заставит пользователя корректно завести заявки.

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

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

      Далее по части заявок у нас сделана обязательность вложения и описано, что нужно приложить. Без прочтения этих требований и вложения заявку просто нельзя создать. Для другой части мы создали историю с требованием что-то прочитать. То есть при создании обращения самой первой строкой идет гиперссылка на очень краткую инструкцию и пользователь может ее скачать и прочитать. По анализу работы мы оценили, что на этом этапе порядка 24% обращений отваливаются в силу получения ответа еще на этапе создания, то есть до сохранения заявки даже не доходит. В некоторых каталогах инструкция будет отправлена пользователю уведомлением системой, без участия живого человека.

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

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

      • Роман Цыганков Мария
        Рейтинг: 1055
        АВТОЗАВОД Санкт-Петербург
        Директор по информационным технологиям
        22.11.2021 15:19

        Мария,
        Спасибо за детальный ответ. Из описания видно, что проделано и делается большой объем работы по автоматизации и такой опыт очень интересен. Желаю удачи в конкурсе!

  • Максим Часовиков
    Рейтинг: 4767
    РАНХиГС
    Директор Проектов проектного офиса ректора
    23.12.2021 10:23

    Добрый день! как думаете, за счет этого проекта квалификация и уровень цифровой культуры будет на сколько повышаться?

  • Дмитрий Турчановский
    Рейтинг: 2527
    Зарубежнефть
    Заместитель начальника Управления информационных технологий
    08.01.2022 18:56

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

Год
Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.