54
идентификация клиентов на входящих телефонных вызовах» будет
проводится в разрезе каждой из его фаз. Общий план реализованного проекта
и его детали представлены в Project Summary в приложении 4.
Фаза 2. Подача заявки в Департамент информационных технологий.
Будучи сотрудником Клиентского сервиса с ролью «бизнес партнер»,
ответственность за подачу заявки в отдел информационных технологий была
на моей стороне. Заявка была создана на следующий рабочий день 04.06.2018
- №56790.
Фаза 3. Подготовка бизнес концепции. В рамках подготовки данного
документы, со стороны департамент информационных технологий был
предоставлен системный аналитик – Семен Ковалев. После коммуникации с
департаментом проектов, была получена информация об отсутствии
свободных ресурсов для проведения бизнес анализа, поэтому решением
Руководителя Клиентского Сервиса стало назначение меня на выполнение
данной задачи. В связи с этим, на данной фазе, я одновременно совмещала
роли автора заявки и бизнес аналитика, а соответственно занималась
подготовкой анализа требований и бизнес анализом.
В рамках бизнес анализа были запланированы и выполненные следующие
задачи:
- описание схемы текущего процесса (as is) – схема размещена в
Приложении 5;
- описание схемы будущего процесса (to be) – схема размещена в
Приложении 6;
- анализ структуры данных телефонных номеров в системе и расчет
прогнозируемого процента совпадений по итогам реализации функционала.
Результаты анализа описаны в Приложении 7.
Работа по подготовке бизнес анализа была завершена 15.06.
В рамках подготовки анализа требований мною было проведено
несколько встреч с системным аналитиков, в результате которых было
принято решение об объединении результатов анализа и выделение
55
следующих пунктов:
А) Условия и предположения:
- Сервис автоматической идентификации звонящего клиента должен
быть реализован и доступен на всех площадках (КЦ + все действующие АКЦ)
обслуживания клиентов. Запуск сервиса должен быть осуществлен
одновременно.
- Чтобы выдерживать KPI на приеме звонка и не потерять
производительность, время поиска и сравнения данных в системе не должно
быть более 3 секунд.
- Вариант технической реализации интеграции между системами должен
быть гибким для запуска и с новыми партнерами (АКЦ), тип телефонной
системы которых может отличаться от действующих.
- Предполагается, что собственная систем будет являться основным
хранилищем информации, т.е. там будут размещаться данные уз оператора и
соответствующие им логины из телефонных систем.
- Предполагается, что на этапе запуска функционала, в MOVEX
необходимо будет одновременно добавить информацию о логинах всех
действующих операторов из телефонных систем, а в дальнейшем вносить
данную информацию при создании уз.
- Поиск и сравнение информации о телефонных номерах должен быть
реализован только по базе клиентов того интернет-магазина, по которому
поступил звонок, базу подписчиков проверять не требуется.
- Сравнение телефонных номеров долно проводиться по всем полям с
номерами телефонов (моб. телефон, дом. телефон, в карте клиента. иной
телефон). Формат данных во всех полях системы идентичный:
+7(ХХХ)ХХХХХХХ. АОН номеров в системе телефонии может отличаться в
зависимости от провайдера: 8ХХХХХХХХХХ; 7ХХХХХХХХХХ;
ХХХХХХХХХХ.
- Система должна открывать оператору карту клиента, вне зависимости
от того, какой в текущий момент у оператора открыт проект.
56
- Уникальность АОН при входе снижает процент распознавания
клиента, т.к. клиент может обратиться несколько раз за период
Б) Что обязательно должно быть решено в рамках реализации:
- Должна быть реализована интеграция между всеми действующими
системами телефонии КЦ и АКЦ и сrm cсистемой. Список действующих
систем телефонии в КЦ и АКЦ: AVAYA, Genesys, Naumen.
- Данные о логинах из системы телефонии должны быть внесены в crm
систему.
- В crm системе должен быть реализован алгоритм поиска и сравнение
данных телефонных номеров, данная операция должна не превышать более 3
секунд.
- В системе, требуется создание дополнительного экрана для вывода
информации с результатами поиска для оператора.
Аналитика была завершена 20.06.
Таким образом работы по формированию бизнес концепции были
завершены. Документы были приложены к заявке, для проведения
качественной оценки (Quality Gate). Виза об успешном завершении оценки
получена 26.06., на этом фаза 3 завершилась.
Фаза 4. Оценка трудозатрат.
Оценка трудозатрат проводилась со стороны старшего менеджера
разработки и руководителя департамента проектов и была завершена 09.07.
Идеи был присвоен средний уровень сложности разработки.
Трудовые ресурсы были оценены следующим образом:
- разработчик 45 ч/дней;
- аналитик 15 ч/дней;
- проектный менеджер 20 ч/дней;
- менеджер по продукту 20 ч/дней;
- координатор 15 ч/дней.
На этом фаза оценки трудозатрат была завершена.
Фаза 5. Комитет «Request Management Board (RMB)». Дата ближайшего
57
комитета для презентации и защиты идеи была назначена на 11.07. По итогам
обсуждения задачи, были приняты следующие решения:
- разработку функционала осуществить только для in house контактного
центра, поэтому необходимо сократить ресурсы разработчика с 45 ч/дней до
35 ч/дней, остальные выделяемые ресурсы оставить без изменений;
- ввиду ограничений по ресурсам и потенциальных рисков запуска
функционала в высокий сезон, осуществить разработку в течение двух
релизов и выпустить функционал в релизе 12/2018.
- заложить ресурсы бизнес-аналитика для проведения оценки
эффективности реализованного проекта по итогам работы функционала за
период не менее трех месяцев. Результаты анализа представить на ближайшем
RMB и повторно рассмотреть реализацию функционала на всех площадках
аутсорсинговых партнеров;
- реализацию функционала произвести для интернет-магазинов: bonprix
ru, bonprix kz и witt. Затраты по проекту разделить между проектами в равных
долях.
Идея получила комментарий «подтверждена к разработке в нескольких
релизах» и перешла в статус «проект к реализации» - завершение фазы.
Фаза 6. Техническая разработка. После перехода идеи в статус проекта к
реализации началось формирование проектной группы, выделение ресурсов и
организация установочной встречи.
В рабочую группу проекта вошли следующие сотрудники:
- разработчики: А.Дерябин, А. Абалян.
Поскольку фаза технической разработки была разбита на два релиза,
департамент информационных технологий выделил двух разработчиков,
между которыми запланировано было разделение всего объема задач.
- аналитик: А.Сазонова.
- проектный менеджер: Е.Перфильева Е.
- роли менеджера по продукту и координатор: Е. Сафонова.
58
Ввиду длительной протяженности проекта (около 6 месяцев) было
принято решение объединить эти две роли и назначить их мне.
Установочная встреча в рамках проекта прошла 17.07. В рамках данной
встречи были определены следующие данные:
- зафиксирована карта коммуникации:
Рисунок 18. Карта коммуникации проектной группы
- регламент проектной группы:
• Встречи рабочих групп организовывает менеджер проекта, по мере их
необходимости для решения важных открытых вопросов по проекту.
• Актуальная информация о ведении проекта направляется в виде
краткого текущего отчета Project Summary, каждые две недели, по вторникам,
до 10:00.
• Результаты обсуждений, также фиксируются в Project Summary и
направляются участникам проектной группы, согласно карте коммуникаций.
• Визирование и согласования документации осуществляет по средствам
эл. почты или по итогам встречи в Project Summary.
Формат и данные Project Summary размещены в Приложении 4.
23.07. состоялась первая встреча Менеджера по продукту, аналитика и
разработчиками по декомпозиции задач: были обсуждены все текущие
59
подзадачи к разработке, проведена их декомпозиция, а также сформирован
список открытых вопросов.
Далее, до приближения фазы тестирования обзорные встречи в рамках
декомпозиции и встречи рабочих групп проводились на один раз в месяц
основе.
Фактические работы по технической разработке были начаты с 03.09. и
продлились до 15.11. Общее количество затраченных 35 ч/дней:
- 20 ч/дней первого разработчика;
- 15 ч/дней второго разработчика.
Таким образом, была завершена фаза 6.
Фаза 7. Тестирование. В рамках данной фаз, в период с 19.11 по 23.11
включительно, со стороны Аналитика был зарезервирован тестовый сервер
preprod3, на котором были развернуты билды разработчиков и подключен
тестовый сплит телефонии. Аналитику и Менеджеру по продукту необходимо
было провести три кейса тестирования:
- Входящий звонок с результатом единичной идентификации клиента;
- Входящий звонок с результатом множественной идентификацией
клиента, т.е. получено более одного результата совпадения телефонного
номера;
- Входящий звонок с нерезультативной идентификацией, т.е. совпадений
тестовых номеров не выявлено.
Все три кейса были успешно и без замечаний пройдены в рамках
тестирования. Дополнительно, кейсы проверены для всех проектов, итого
было проведено 9 тестовых звонков и их идентификация. Время
автоматической идентификации клиента в системе не превышало заявленных
в требованиях 3 секунд.
Результаты тестирования были зафиксированы на видео, для дальнейшей
приемки со стороны бизнес спонсоров и передачи тренерам для подготовки
учебных материалов и проведения тренингов. После ознакомления с видео
материалами бизнес спонсоры подтвердили успешную приемку функционала
60
и запуск работы на продукционный сервер. На этом была завершена фаза 7.
Фаза 8. Релиз. Функционал был успешно реализован на продукционном
сервере в ночь с 02-03.12, запуск его работы запуск состоялся 03.12 с 09:15.
По итогам релиза технических ошибок в работе функционала не
наблюдалось.
Фаза 9. Оценка эффективности проекта будет подробно описана в
следующем параграфе.
3.3. Оценка эффективности реализации проекта
Оценка эффективности реализации проекта по сути является проектной
Фазой 9. 03.12. После выпуска функционала автоматической продукта на
продукционный сервер, проект переходит перешел в стадию его завершения.
На данной фазе было сформировано два ключевых анализа:
- оценка реализации бюджета, проведенная со стороны Менеджера
проектов.
- оценка ожидаемых и полученных «профитов» по итогам реализации
проектам – проведенная Менеджером по продукту.
07.12. по итогам оценки реализации забюджетированных трудовых
ресурсов зафиксировано, что работы были выполнены согласно
утвержденного плана, в полном объеме и без дополнительных затрат.
По согласованию со спонсорами проектов, на данном этапе проект был
признан успешно завершенным, а аналитика в рамках оценки ожидаемых
результатов вынесена за границы проекта и запланирована на июнь 2019 года.
Данная оценка ожидаемых и полученных «профитов» была выполнена
мной в рамках прохождения преддипломной практики.
Основными задачами в рамках данного анализа стали:
1. Проанализировать динамику изменений уровня качества
обслуживания у операторов контактного центра.
2. Проанализировать динамику изменений уровня
удовлетворенности покупателей компаний ООО «ДИРЕКТ КАТАЛОГ
61
СЕРВИС».
3. Оценить и произвести расчет сокращенных затрат по обработки
телефонных вызовов по итогам запуска функционала.
Анализ динамики изменений уровня качества обслуживания у операторов
контактного центра. В рамках проводимого анализа, с целью оценить влияние
внедрения функционала автоматической идентификации клиентов на
входящих телефонных звонках, мною были рассмотрены статистические
данные с информацией об уровне качества обслуживания сотрудников
контактного центра за период с января по май 2018 г. - до ввода функционала,
и аналогичный период в 2019 г. - после запуска.
Рисунок 19. Уровень качества обслуживания клиентов за период
январь-май 2018 и 2019 гг.
Таблица 3.
Динамика изменения показателя качества обслуживания
клиентов
В целом, на всех проектах наблюдается положительная тенденция роста
показателя – наибольший рост показателя качества обслуживания в 2019 году
наблюдается на проекте бонпри kz – среднее значение прироста данного
показателя составило «+1,26 %». Наибольший рост показателя в 2019 году
62
приходится для всех проектов на май, в данном месяце наибольшие значения
уровня качества обслуживания.
Исходя из общей статистики и динамики изменения показателя, нельзя
однозначно утверждать, что основной причиной рост стало введение в 2019
году функционала автоматической идентификации. Для фактической оценки
уровня влияния ввода функционала, дополнительно я рассмотрела структуру
показателя в разрезе блоков оценочной формы и объема ошибок, допущенных
операторами в каждом из блоков.
Таблица 4.
Оценочная форма для определения уровня качества
обслуживания клиентов
Категория
оценки
Критерий оценки
Вес,
балл
Влияния
критерия,
%
Влияния
категории,
%
1.Техника
речи
Дружелюбная интонация,
вежливые слова
5
5%
10%
Деловой стиль
общения/грамотная речь
5
5%
2.Техника
ведения
диалога
Корректная идентификация
клиента
20
20%
40%
Точное определение цели
обращения
10
10%
Корректная работа с
возражениями/претензиями
10
10%
3.Знание и
применение
проектной
информации в
решении
вопроса
клиента
Соблюдение алгоритма
консультации
10
10%
20%
Предоставление клиенту
полной информации по
запросу
10
10%
4.Уверенное
владение ПО и
информационн
ыми
системами
Корректное и полное
внесение информации в БД
для решения вопроса
клиента
10
10%
20%
Соблюдение процедуры
регистрации обращения в
системах
10
10%
5.Свободный
диалог
Заинтересованность в
решении вопроса клиента
10
10%
10%
63
Формат и категории в оценочной форме являются едиными для всех
проектов. Из структуры оценочной формы видно, что распределение баллов
внутри категорий неравномерно, наибольшее значение приходится на
категорию «2. Техника выделения диалога» - 40%. Именно в ней расположен
критерий «Корректная идентификация клиентов», на который влияет ввод в
систему функционала автоматической идентификации. В связи с этим для
проведения оценки, мною была рассмотрена динамика количества ошибок за
аналогичные периоды.
Рисунок 20. Количество ошибок по критерию «Корректная
идентификация клиентов» за период январь-май 2018 и 2019 гг.
Таблица 5.
Динамика изменения количества ошибок по критерию
«Корректная идентификация клиентов»
Можно утверждать, что ввод функционала оказал положительное
влияние на уровень ошибок, допускаемых в данном критерии на всех
проектах. Наибольшее влияние наблюдает на проекте bonprix ru «– 90,08%».
Наименьшее влияние наблюдает на проекте в Казахстане и это обусловлено
низкой валидностью телефонных номеров введенных в систему, а следственно
и низким показателем % единичных совпадений на входящих вызовах.