44
Результатами пользовательского тестирования:
- Успешно пройденные кейсы;
- Кейсы, пройденные с несущественными комментариями;
- Кейсы, проведенные с существенными комментариями;
- Не пройденные кейсы – кейсы, завершить которые не удалось из-за
блокеров или выявленных технических ошибках в системах. Также в данную
категорию результатов могут попасть кейсы которые не удалось пройти вижу
невозможности их повторения на тестовом окружении или отсутствия
необходимых тестовых данных.
По кейсам с несущественными и несущественными замечаниями, а также
по не пройденным тестовым кейсам заводятся подзадачи для выяснения
причин их возникновения. Данными задачами занимается Аналитик и либо
данные замечания признаются багами разработки и возвращаются для
исправления разработчику, либо замечания признаются запросом на
изменение (CR), не заявленным в текущей реализации и считаются
дополнительным требованием в проекта. Если замечание признано «запросом
на изменение» по нему в проекте заводится отдельная задача, которая
назначается на менеджера по продукту. Менеджер по продукту, совместно с
менеджером проекта выносит все такие задачи для дополнительного
обсуждения с участниками проекта и представителями бизнеса для
совместного обсуждения необходимости и возможности их реализации в
рамках данного проекта или переноса их в список отложенных идей для
дальнейшей оценки на Workshop и RMB.
По всем успешно пройденным кейсам, менеджер по продукту производит
демонстрацию разработанного функционала для заинтересованных лиц по
проекта – данный этап называют «приемкой». Приемка считается
завершенной, когда все кейсы тестирования были продемонстрированы и
утверждены ответственными лицами.
После завершения этапа приемки функционала осуществляется
«заморозка» кода и его билда. Функционал считается разработанным и
45
готовым к размещению на продукционном окружении.
До выпуска продукта на продукционные серверы систем менеджер по
продукту обеспечивает передачу информации о продукте в департаменты,
которые затрагивает данная разработка и контролирует обучение персонала,
при необходимости проводит обучающие вебинары или тренинги.
Фаза 8. Релиз. После завершения разработки, тестирования и приемки
функционала, код и билд продукта ожидает своего включения в общую ветку
планируемо релиза. По техническим регламентам, выпуск продуктов
осуществляет только по средствам релизов.
Подготовка и сборка релизной ветки производится силами релизных
менеджеров и системных администраторов в департаменте информационных
технологий. По итогам релиза, весь функционала, запланированный в рамках
проектной деятельности развертывается на продукционных серверах систем
компании. Перед развертыванием, все билды проходят ряд технических тестов
на совместимости, а также регрессное тестирование, чтобы исключить
конфликты доработки с действующим функционалом, уже развернутом на
продукционном окружении.
В течение года, в компании ООО «ДИРЕКТ КАТАЛОГ СЕРВИС»
проводится два главных релиза «Major Release» и 6 обычных «Feature
Release».
Рисунок 16. Схема проведения релизов в компании
ООО «ДИРЕКТ КАТАЛОГ СЕРВИС»
Главные релизы проходят в конце января и конце июля – в низкий сезон
продаж. Обычные релизы размещаются также, чтобы не попасть в высокий
46
сезон маркетинговых активностей и продаж. Все эти действия направлены на
минимизирование рисков, возможных по итогам развертывания новых
продуктов и сокращение потенциальных дополнительных затрат, связанных с
устранением последствий неудачного выхода релиза.
По завершению данной фазы зона ответственности сотрудников из
департамента информационных технологий заканчивается, а продукт в рамках
проекта считается выпущенным.
Рисунок 17. Релизный план 2-4 кварталов 2018 года
в компании ООО «ДИРЕКТ КАТАЛОГ СЕРВИС»
Фаза 9. Оценка эффективности проекта. После выпуска продукта на
продукционный сервер, проект переходит в стадию его завершения.
На данной фазе Менеджер по продукту и менеджер проекта
подготавливают совместный анализ эффективности проекта и проводят его
презентацию для заинтересованных лиц проекта, представителей бизнеса
(и/или спонсоров проекта) и финансового департамента.
Данный анализ включает в себя две основные оценки:
- оценка ожидаемых и полученных «профитов» по итогам реализации
проектам – поводится и является ответственностью Менеджера по продукту;
47
- оценка реализации бюджета – проводится и является ответственностью
Менеджера проектов.
По итогам предоставления аналитики:
- спонсор проекта подтверждает завершение проекта;
- менеджер проекта закрывается задачу по проекту в Jire;
- бюджет считается реализованным и будет закрыт в соответствующий
финансовый срок;
- ресурсы проекта высвобождаются и считаются доступными для работ в
следующей проектной деятельности.
- проект считается завершенным.
Рассмотрев описанную выше, схему ведения проектной деятельности в
компании ООО «ДИЕРКТ КАТАЛОГ СЕРВИС» можно выделить ее
следующие преимуществ и недостатки:
Преимущества организованной схемы:
- строгое разделение зон ответственности, на каждой из фаз жизненного
цикла;
- документирования результатов работы каждой фазы;
- прозрачный контроль хода выполнения проекта, поскольку схема
реализации едина для всех видов проектов, реализуемых в компании.
- единая и простая схема выделения бюджета для проектов;
- высокая рентабельность реализованных проектов;
- высокий уровень кооперации бизнес подразделений и ИТ.
Недостатки организованной схемы:
- не всегда эффективное использование ресурсов: для реализации
небольшого краткосрочного продукта требуется и согласование сотрудников
из разных департаментов с фактически неполной загруженностью на проекте
и ситуации, когда организовать дозагрузку для таких сотрудников ролями в
других проектах не представляется возможным.
- ограниченность ресурсов: в рамках одного релиза может быть
выпущено только строго определенное количество функционала. Компания не
48
привлекает к проектной деятельности аусорсинговые или аутсафинговые
ресурсы;
- отсутствие гибкости, в случаях, когда объем требований к изменениям в
системах не возможно полностью сформировать на стадии анализа, что как
следствие может привести к неуспешному завершению проекта или возврата
его на более ранние этапы.
- длительные сроки всего процесса: от появления идеи, до ввода продукта
по ней в эксплуатацию, проходит не менее 2 месяцев.
Выводы по главе 2.
В данной главе были рассмотрены организационная структура компании
ООО «ДИРЕКТ КАТАЛОГ СЕРВИС» и распределение функций между ее
подразделениями, проведены анализы кадрового состава и деятельности
предприятия по его основным экономическим показателя. В пункте 2.3.
подробно описан и проанализирован организованный в компании процесс
управления проектами. На основании полученных результатов были
сформированы следующие выводы и предложения:
- описанная выше схема является рабочей и успешно функционирует и на
текущий момент;
- за время ее ввода в эксплуатацию, все подтвержденные проект были
выполнены в срок, согласно выделенным бюджетам, без дополнительных
затрат;
- проблема с потенциальной не дозагруженностью ресурсов наблюдается
только в период низкого сезона и может быть решена административным
путем. Например, планированием на данный период для сотрудник отпусков
или проведением образовательных тренингов для увеличение уровня их
компетенций и увеличением вариативности набора ролей, для участие в
проектной деятельности;
- проблема с потенциальной нехваткой ресурсов в высокий сезон может
быть решена либо путем привлечении дополнительных внешних ресурсов.
49
Например, привлечение аутсорсинговых партнеров только на роли не
связанные с кодированием в системах: менеджер проекта, продукта,
административный координатор или бизнес-аналитик. Либо путем увеличения
штата собственных сотрудников. Также позитивно на данную проблематику
может повлиять повышение или развитие компетенций в рамках проектной
деятельности у сотрудников из числа экспертов.
- каждый проект реализуется строго только из забюджетированых
средств центров затрат бизнеса или операционных департаментов и только
силами сотрудников, которые принимают участие в проектной деятельности.
В случае возникновения незапланированных проектов, выполнение которые
обязательно для деятельности всех компании (например, требования
вызванные изменение законодательства) компания не имеет резервов для
выполнения данных задач. Чаще всего такие задачи, ввиду их приоритетности,
отодвигают реализацию других задач, нацеленных на увеличение прибыли
или запуск новых услуг для клиентов. Данный аспект является существенным
риском. Мерой сокращения таких рисков может стать резервные статьи
бюджета, которые будут использованы либо для оплаты переработок
собственного персонала или для оплаты работы аусорсинговых партнеров.
50
ГЛАВА 3. РАЗРАБОТКА ПРОЕКТА РЕАЛИЗАЦИИ
ФУНКЦИОНАЛА «АВТОМАТИЧЕСКАЯ ИДЕНТИФИКАЦИЯ
КЛИЕНТОВ НА ВХОДЯЩИХ ВЫЗОВАХ» В КОМПАНИИ
ООО «ДИРЕКТ КАТАЛОГ СЕРВИС»
3.1. Выбор и обоснование проекта реализации функционала
«Автоматическая идентификация клиентов на входящих телефонных
вызовах»
Функционал автоматической идентификации клиентов на входящей
линии представляет собой возможность определять клиента, путем сравнения
входящего телефонного номера абонента и данных телефонных номеров в
картах клиента в системе.
Данный функционал не является новым в сегменте клиентского
обслуживания компаний, однако большее распространение в использовании
он получил в сфере банковского обслуживания, в сфере он-лайн ритейла
реализация данного функционала менее популярна. Такое явление
обусловлено сразу несколькими факторами:
- автоматическая идентификация подразумевает под собой
интеграционные работы между системами управления взаимоотношения с
клиентами и телефонии. Как правило, интеграционные задачи с участием
нескольких систем, всегда являются более сложными и трудозатратными, а
выгоды полученные от внедрения не всегда покрывают или быстро окупают
вложенные затраты. Банковский сегмент выделяет на технические разработки
гораздо большие средства и может позволит себе функционалы с длительным
сроком окупаемости. Он-лайн ритейлеры же напротив, в первую очередь
вкладывают инвестиции в реализации проектов, которые покажут быстрый и
позитивный результат, существенно повлияют на увеличение продаж, чтобы
далее возвращенные инвестиции вложить в следующие проекты.
- интеграция, связанная с внедрение функционала с автоматической
идентификацией, чаще всего строго подстраивается под одну систему
телефонии. Тенденция последних лет показывает, что банки сокращают долю
звонков, которые отдают на обслуживание в аусортс и усиливают позиции
51
собственных (in-house) контакт центров. Такое поведение вызвано высоким
уровнем конкуренции в данном сегменте, повышая качество обслуживания в
собственном клиентском сервисе, они делают его своим конкурентным
преимуществом. В направлении электронной коммерции наблюдается
обратный тренд: ритейлеры стараются отладить свои бизнес процессы и
отдать аутсорсинговому партнеру максимальную долю звонков для
обслуживания. Это поведение является следствие политики сокращения
затрат: стоимость обслуживания: себестоимость минуты обслуживания в
собственном контакт центр всегда выше чем в аутсорсе, масштабируемость и
гибкость ресурсов в in-house ниже. Соответственно риски не выдержать
ключевые показатели на высоком сезоне, диктуют он-лайн ритейлерам тесную
кооперацию с аутсорсом. На практике, аутсорсинговые партнеры имеют
собственные системы телефонии и они могут отличаться от системы в in-
house, чем влекут за собой дополнительные затраты в реализации
функционала, а также налагаю риски, что в случае смены аутсорс-партнера
потребуется еще доработка, т.к. его система будет отличатся от уже
подключенных.
- еще один фактор, который чаще подталкивает банки на реализацию
данного функционала – это сокращение рисков, по некорректной
идентификации абонента.
Несмотря на это, функционал автоматической идентификации имеет ряд
неоспоримых преимуществ:
- сокращение времени диалога оператора, т.к. ему не потребуется тратить
время на поиск клиента в системе;
- увеличение уровня качества обслуживания, за счет ошибок, которые
оператор может допустить при ручном поиске;
- увеличение уровня удовлетворенности клиентов, за счет отсутствия
необходимости диктовать оператору свои данные по телефону и ждать
результатов поиск;
- сокращение рисков по некорректной идентификации.
52
Учитывая данные описанные выше, в конце мая 2018 года, занимая в
компании ООО «ДИРЕКТ КАТАЛОГ СЕРВИС» позицию бизнес аналитика в
отделе «Клиентский Сервис» (департамент «Тверь Логистика») и имея роль
«бизнес-партнер», я сформировала и вынесла данную идею для реализации на
встрече рабочей группы в рамках Workshop, которая состоялась 01.06.2018.
По итогам Workshop’а были согласованны следующие данные:
- главной бизнес целью проекта считать реализацию возможности
приветствовать клиента по имени при обращении по телефону;
- ожидаемый результат от реализации - интеграция CRM с телефонией на
всех площадках обслуживания, для всех действующих проектов (интернет-
магазинов) и автоматическая идентификация звонящего клиента с поднятием
его карточки клиента.
- сценариями бизнес процесса считать 3 варианта:
• одно уникальное совпадение номера телефона в карте клиента;
• >1 совпадений;
• отсутствие совпадений.
- ожидаемые «профиты»:
• сокращение времени диалога оператора;
• увеличение уровня качества обслуживания.
• увеличение уровня удовлетворенности клиентов.
Участники встречи согласились, что несмотря на все описанные выше
особенности и потенциальные большие затраты на реализацию, внедрение
функционала может оказать позитивное влияние на уровень клиентского
обслуживания в компании, стать преимуществом перед другими он-лайн
ритейлерами. Также возникла гипотеза, что из спецификации процесса поиска
клиента в текущей crm системе, по итогам реализации функционала,
произойдет сокращение времени диалога оператора. По итогам проведенных
замеров был выведен показатель времени диалога для поиска клиента, среднее
значение которого составило 15 секунд.
Идея получила высокий приоритет и была подтверждена к переходу на
53
следующую фазу – создание заявки в ИТ и подготовка бизнес концепции.
3.2. Управление проектом по жизненному циклу
Вся проектная деятельность в компании ООО «ДИРЕКТ КАТАЛОГ
СЕРВИС» проводится единой регламентированной схеме:
Этап 1. Инициация:
∙ Стадия 1. Инициация:
- Фаза 1. Формирование идей для будущих проектов к реализации.
- Фаза 2. Подача заявки в Департамент информационных технологий.
∙ Стадия 2 Анализ:
- Фаза 3. Подготовка бизнес концепции.
Этап 2. Планирование:
- Фаза 4. Оценка трудозатрат.
- Фаза 5. Комитет «Request Management Board (RMB)».
Этап 3. Исполнение:
∙ Стадия 3. Реализация:
- Фаза 6. Техническая разработка.
- Фаза 7. Тестирование.
∙ Стадия 4. Распространение:
- Фаза 8. Релиз.
Этап 4. Завершение:
∙ Стадия 4. Потребление
- Фаза 9. Оценка эффективности проекта.
Реализация проекта «Автоматическая идентификация клиентов на
входящих телефонных вызовах» производилась согласно данной
утвержденной схемы.
Поскольку идея о внедрении успешно прошла Workshop, для нее
стартовал этап 1 «Инициализация» и была завершена фаза 1. Формирование
идей для будущих проектов к реализации.
Далее описание жизненного цикла проекта «Автоматическая