Service Desk в хозяйственном подразделении

В начале июня 2012 года руководством департамента ИТ компании была поставлена задача перевести подразделения, отвечающие за жизнеобеспечение магазинов (назовем их подразделениями инфраструктуры), на новое программное обеспечение по приему и обработке заявок от магазинов.

Что имеем?

На тот момент в одной из приобретенных структур компании для обработки обращений пользователей успешно использовалось ПО Naumen Service Desk. В качестве исполнителей в системе были задействованы не только сотрудники департамента ИТ, но и смежные подразделения (АХО, маркетинг, реклама, коммерция, ценообразование, безопасность, товародвижение). Все заявки регистрировались через контактный центр по телефону и электронной почте и распределялись в соответствии с установленным маршрутом. Для правильной маршрутизации операторы контактного центра использовали диагностические карты. В системе обрабатывалось порядка 7-8 тыс. запросов в месяц от 250-270 магазинов и около 1,5 тыс. пользователей. Территориально объекты находились в Москве и области, а также в Калининграде и Туле. Численность операторов контактного центра составляла 8 человек в смену. Система Naumen Service Desk уже была тиражирована и в часть магазинов «Дикси» (порядка 600) для обработки ИТ-заявок. Учитывая имеющийся положительный опыт работы с системой, было принято решение использовать этот программный продукт.

Чего хотим? Цели проекта

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

1. Текущий порядок приема и обработки заявок инфраструктуры от магазинов:

• порядок приема и обработки заявок как есть;
• количество и территориальное расположение обслуживаемых магазинов;
• необходимое количество диспетчеров инфраструктуры и инженеров — кураторов инфраструктуры;
• количество обращений в день и в месяц; пиковая нагрузка (дни недели/время);
• перечень всех необходимых отчетных форм.

2. Ключевые роли (функции) участников процесса (диспетчер/инженер-куратор/ответственные за процесс и т. п.).
3. Типы заявок, обрабатываемых в системе (техобслуживание/ холодильное оборудование/сметные заявки и т. п.).
4. Данные по подрядчикам:

• количество подрядчиков, временные нормативы на выполнение ими заявок;
• кто и как поддерживает актуальность данных по подрядчикам (внесение новых данных, привязка к магазинам, назначение кураторов).

Во время первой встречи мы рассказали заказчику о возможностях систем класса Service Desk. Разговор шел не о внедрении процессов ITIL, а о решении реальных задач АХО и достижении понятных ключевых целей, таких как:

• минимизация прямых потерь, в том числе сокращение времени вынужденного простоя магазина по техническим причинам;
• регистрация всех запросов магазинов;
• создание инструментов контроля качества выполняемых работ по запросам;
• учет вклада каждого работника, принявшего участие в работе над запросами;
• предоставление пользователям актуальной информации о состоянии их запроса;
• организация механизмов эскалации запросов в случае нарушения сроков или качества работ по запросам;
• предоставление прозрачной отчетной информации по затратам времени и по загрузке исполнителей для оптимизации штата сотрудников;
• контроль со стороны руководителей за своевременным выполнением заявок;
• оперативное предоставление подрядчикам информации о новых заявках;
• контроль выполнения ремонтных и регламентных работ;
• удобный интерфейс для пользователей (операторов и инженеров).

Проект предусматривал поэтапное внедрение системы во всех магазинах ГК «Дикси»: на первом этапе в магазинах Москвы и области, в дальнейшем — тиражирование на Рязань, Калугу, Ярославль, Владимир, Тверь, Тулу, Челябинск, Санкт-Петербург и прилегающие области.

Особенности сервиса АХО

Старт проекту был дан в начале июля 2012 года, к 10 июля мы подготовили первую версию схемы описания процесса. Уже 13 июля заказчик интересовался: «Как дела с новой версией программы?». От нас ждали результатов.

Придерживаясь терминологии системы Naumen, мы разработали новые соглашения, сервисы и типы запросов. В отличие от ИТ, где в зависимости от условий предоставления сервисов использовались различные соглашения, магазины работали по одинаковым условиям (время предоставления сервиса, время выполнения работ). Поэтому для них было создано одно соглашение «Инфраструктура» с одним сервисом «Техническое обслуживание». Магазинам обеспечивался уровень предоставления сервиса по схеме 24х7 и уровень обслуживания 12х7, то есть услуги предоставлялись 24 часа в сутки, а поддержка по ним могла быть оказана только с 9 до 21 часа. Для нас новым было определение специализированных для АХО типов запросов и разработка их жизненного цикла. Наименования запросов долго проверялись на правильное понимание. Мы проводили опрос сотрудников магазинов на местах, старались выяснить, насколько наши формулировки понимаются пользователями. Заказчик в итоге утвердил следующие базовые типы запросов:

• техническое обслуживание (ТО) – любой запрос от магазина по АХО;
• счет – используется при необходимости закупки чего-либо;
• смета – используется при необходимости проведения работ, требующих подготовки сметной документации.

Причем пользователю в личном кабинете системы для выбора оставили доступным только тип «ТО» (рис.1).

Рис.1. Личный кабинет пользователя

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

Для операторов диспетчерской службы типов запросов уже было несколько, и они имели возможность их изменять (рис. 2).

Рис.2. Возможность изменения операторами типа запроса

Таким образом, магазин подавал запрос типа «ТО», операторы инфраструктуры анализировали его и при необходимости изменяли на более конкретный (например с «ТО» на «Лифты»).

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

Настройка отчетности

Для настройки отчетов заказчик предварительно подготовил «шапки» требуемых отчетов в Excel. Обсуждалось, есть ли понимание каждого столбика. Утверждая отчет, мы должны были понимать наши возможности по его реализации в системе. Так как у меня и моих коллег по ИТ был достаточно большой опыт работы с системой Naumen SD, мы знали возможности системы для построения отчетов и учитывали их. Например, в самой системе нельзя было работать с отчетами как со сводной таблицей в Excel. Для формирования некоторых отчетов нужно было использовать скрипты и вычислимые функции.

Основными отчетами в итоге стали:

• общий отчет по всем запросам инфраструктуры, на основании которого инженеры-кураторы и их руководители получают информацию по всем запросам от магазинов за необходимый период (номер магазина, количество запросов, типы запросов, исполнитель по запросу, состояние запроса, просрочен запрос или нет);
• отчет по подрядчику, позволяющий организовать диалог с подрядными организациями, опираясь на конкретные заявки, в которых отображается в том числе и соблюдение SLA;
• отчет по инженеру-куратору для руководителей, показывающий реальную загрузку исполнителей и позволяющий при необходимости перераспределить ресурсы.

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

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

— интерфейс личного кабинета при вводе и отслеживании заявок из магазинов;

— интерфейс рабочего места оператора диспетчерской службы;

— интерфейс рабочего места инженера-куратора;

— необходимость и информативность оповещений на каждом шаге;

— наличие и информативность отчетов.

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

Во время тестирования мы приезжали в магазины Москвы и области и показывали личный кабинет пользователям на местах. Проверялось его общее восприятие, понятность последовательности действий и правильность выбора типов запросов из списка по конкретному обращению. Проводилось моделирование с реальными примерами. Мнения пользователей собирались и анализировались. Учитывался сленг, используемый сотрудниками магазинов при общении друг с другом. Например, слово «инфраструктура» в магазинах сразу ассоциировалось с заявками в АХО. А вот аббревиатура ИТ иногда ни о чем не говорила.

Обучение

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

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

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

Первые результаты

В июле 2012 года мы приступили к тестированию и опытной эксплуатации системы в 18 магазинах Москвы и ближайшего Подмосковья. В течение последующих пяти месяцев плавно подключали новые магазины. Таким образом, к концу ноября системой было охвачено порядка 820 магазинов Москвы и области и получены следующие результаты:

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

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

В результате проекта:

• более 97% всех запросов от магазинов регистрируется через личный кабинет;
• среднее время нахождения запроса в состоянии «Зарегистрирован» — 11 минут;
• контролируется соблюдение регламентных сроков по выполнению заявок;
• пользователи получают актуальную информацию о состоянии их запросов;
• работают механизмы эскалации запросов в случае нарушения сроков или качества выполнения работ по запросам;
• предоставляется отчетная информация по временным затратам и по загрузке различных исполнителей;
• руководители получили инструмент контроля за своевременным выполнением заявок;
• подрядчики в реальном режиме получают заявку по электронной почте;
• удобный интерфейс для пользователей (операторов и инженеров).

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

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

Дмитрий Мельников (D.Melnikov@hq.dixy.ru) – менеджер по стандартизации процессов ИТ ГК «Дикси»