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

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

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

Как аутсорс-команде организовать работу с заказчиком?

Шаг первый: подготовка документов и сбор информации

Чтобы составить грамотный проработанный план, менеджер будущего проекта должен запросить у заказчика пакет документов, состоящий из:

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

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

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

1. Планирование перевода услуг.
2. Этап передачи знаний.
3. Предоставление услуг при поддержке заказчика.
4. Предоставление услуг с льготным периодом.
5. Полная готовность предоставления услуг.

Шаг второй: планирование перевода услуг на сопровождение

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

На этом же этапе проектная команда проводит аудит инфраструктуры и системы управления ИТ-услугами заказчика. Обычно он включает в себя как удалённую работу, так и выезд в офисы заказчика для очных встреч.

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

Шаг третий: формирование команды из ключевых сотрудников (core team) и команды поддержки для оказания сервиса

При формировании основной команды проекта необходимо выбирать сотрудников, которые:

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

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

Шаг четвёртый: передача знаний как один из сложнейших этапов в проекте передачи сервиса

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

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

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

Шаг пятый: первые попытки оказания сервиса — совместная работа с поддержкой команды заказчика

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

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

• время решение заявок немного выросло;
• «раньше было лучше».

Давайте разберём эти проблемы. Рост времени решения заявок — это временное явление. Оно связано с тем, что наша команда перенимает опыт, консультируется с командой заказчика и дополняет информацию в базу знаний.

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

Шаг шестой: льготный период предоставления сервиса — штрафные санкции не применяются

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

Шаг седьмой: передача сервиса на полноценную поддержку

Заключительный этап проекта — заказчик полностью передаёт сервис в руки профессионалов. Это значит, что теперь команда проекта самостоятельно поддерживает приложения заказчика. SLA и C-SAT (качество работы) измеряются, и если показатели не соблюдаются, заказчик применяет штрафные санкции.

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

Отсутствует описание процесса incident management, из-за чего нагрузка неэффективно распределяется между сотрудниками.

Эксперты нашей команды обычно адаптируют процесс под структуру проектной команды.

У бизнеса отсутствует понимание метрик SLA и приоритезации обращений, из-за чего затягивается решение высокоприоритетных задач.

Наши специалисты вырабатывают процесс приоритезации под каждый проект индивидуально.

Нет инструкций по решению инцидентов с обслуживаемым ПО. Крайне сложно формализовать подход к решению задач.

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

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

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

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

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

Самая популярная проблема — устаревшее ПО и самописные костыли для приложений.

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

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

Какие плюсы можно получить при правильной передаче сервиса на внешнюю ИТ-поддержку?

1. На управление приложениями тратится меньше времени, что даёт возможность сосредоточиться на поддержке бизнеса и важных стратегических проектах.
2. Качество сервиса контролируется через измеримые и прозрачные SLA.
3. Сервисные процессы стандартизируются с использованием лучших практик и зарекомендовавших себя бизнес-подходов.
4. Процессы предоставления сервиса соответствуют нуждам бизнеса.
5. Качество услуг постоянно совершенствуется через определение изменений ценности сервиса.
6. Команда специалистов формируется на основе специфики ПО и пожеланий заказчика.

Благодаря правильно и прозрачно проведённому проекту по передаче знаний, заказчик передаёт нам стек приложений, состоящий, например, из нескольких WMS и TMS систем, БД SQL и Sybase, а также поддержку серверной инфраструктуры. Весь проект передачи знаний в среднем занимает от 3 до 6 месяцев. За это время мы можем создать правильную команду, изучить новые приложения, разобраться в дебрях накопленных годами костылей и багов, создать и структурировать базу знаний с нуля и при этом не уронить качество передаваемого сервиса.