Как совместить работу штатных специалистов и аутсорсинг

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

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

Какие бизнес-потребности такая модель может закрывать?

• Первый и наиболее очевидный — ускорение развития системы. Если объем потребностей бизнеса в развитии превышает возможности текущей команды — быстрее и эффективнее привлечь подрядчика, нежели расширять команду.
• Экономия бюджета. Это хорошая мотивация для региональных компаний среднего размера, с устоявшейся сильной ИТ-командой, детально разбирающейся в нюансах бизнес-процессов компании. Также такой формат сотрудничества подойдет территориально-распределенным компаниям во время бурного роста и открытия новых подразделений.
• Мотивация команды. Часто бывает так, что команда “закисает” на внутренних задачах, и поставить их в условия конкуренции полезно для повышения производительности работы.
• И наоборот, сохранение своей команды. В условиях перегретого ИТ-рынка трудно сохранить амбициозных специалистов, держа их годами на эксплуатации. Если нет выстроенной карьерной лесенки, нет новых интересных, амбициозных задач, наиболее ценные члены команды могут разбежаться. Выход — отдать регулярные процессы на аутсорс, а новые, интересные задачи поручить прогрессивным сотрудникам.
• Консервативным руководителям подойдет обратное решение. Если, например, в компании есть лояльные сотрудники, с которыми не хочется расставаться, но при этом с новыми задачами им справляться тяжело — развитие можно поручить профессиональным подрядчикам, которые уже имеют опыт в ведении подобных проектов.

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

Давайте рассмотрим варианты взаимодействия смешанной команды

1. Часто опция удаленной поддержки выглядит так: внутренним ресурсом закрывается эксплуатация системы (и это позволяет эффективно планировать ресурс на постоянную загрузку), а на крупные или сложные изменения (развитие) привлекается внешний подрядчик.
   В таком формате ФТО сотрудничает с одной из крупнейших ресторанных сетей, а также с крупным производителем премиальных сыров
2. Еще один подход, когда различные задачи или проекты по развитию отдаются разным подрядчикам. Это позволяет построить конкурентную модель, но с другой стороны, требует существенно более высокого уровня зрелости процесса разработки как на стороне клиента, так и на стороне исполнителей. С большой долей вероятности потребуются дополнительные усилия по взаимодействию между всеми сторонами, чтобы они не “толкались локтями” в приложении.
   Обычно, клиент, который может управлять таким форматом — это очень крупная и зрелая компания с высоким уровнем менеджмента. Мы реализуем такой подход с тремя клиентами.
3. Ну и наконец последний работоспособный вариант — когда зрелый подрядчик дает клиенту кост-модель, в которой клиент фиксирует свои затраты на эксплуатацию (и возможно, какой-то плановый объем услуг развития), а большие проекты проводятся и защищаются как экстра-бюджет в CAPEX. При этом внутри компании остается ключевая компетенция по бизнес-процессам и функциональности системы. В этом случае внутренняя команда играет роль бизнес-партнеров, предлагает бизнесу варианты развития системы, развивает архитектуру системы. Скучную текучку отдают на аутсорс-партнера.
   Так сделал, например, ведущий мясной агрохолдинг, отдав эксплуатацию систем в ФТО, и сохранив при этом экспертизу по процессам внутри собственного ИТ департамента. Сейчас этот департамент прекрасно выполняет роль ИТ-партнера как в расширении бизнеса, так и в переводе его на новую платформу.
   Другой пример из нашего опыта — одна из крупнейших розничных сетей. Передав на поддержку ФТО повторяющиеся операции, они кратно ускорили развитие своей системы, с соответствующим уменьшением негативного давления со стороны бизнеса.

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

Единственный работоспособный способ реализовать такой вариант — выделение первой линии поддержки. Причем первая линия в этом случае — это группа, работающая только по инструкциям (условно, колл-центр, или “нулевая линия”). SLA такой группы в этом случае будет ориентирован на скорость и корректность маршрутизации, а также долю решенных самостоятельно заявок из тех, на которые есть соответствующая инструкция. Мы в ФТО можем предоставить такую услугу — она успешно работает у нескольких наших клиентов.

Как организовать взаимодействие внешней и внутренней команд?

Необходимо выстроить между командами механику управления релизами:

• Необходимо требовать и контролировать 100% документирование работы (технические задания или функциональные дизайны, протоколы релизов). Это актив компании, и он должен быть всегда в порядке. Если этого не делать, будет сложнее и дороже вносить изменения в систему, а также сменить подрядчика в случае необходимости.
• Контролировать правильную передачу компетенций по новому функционалу из команды, которая занимается развитием системы, в поддержку. Обязательным здесь является заблаговременная передача документации на изменения, а также выделение времени до релиза на ознакомление с функциональностью в тестовой или сборочной среде. Хорошая практика — организовать конф-колл для обсуждения нюансов работы нового функционала.
• В случае разделения работы по развитию и доработке систем между разными командами необходимым условием будет выработка и соблюдение общих стандартов по документированию изменений (как техническому, так и пользовательскому), а также общих правил оформления и комментирования кода, использования среды разработки и тестирования.

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

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

Также важное замечание, что предложенные выше модели точно не будут работать без единого механизма управления развитием. В каких-то компаниях решения по приоритизации и “делаем/не делаем” принимает ИТ-директор. Где-то (хороший вариант) — комитет по изменениям, в который входят представители разных департаментов. Бывает, что одна бизнес-функция доминирует в использовании системы (например, финансовое подразделение для бек-офисной системы) и задает приоритеты, выделяя небольшие квоты прочим подразделениям. Важно заранее определить понятную модель принятия решений по работе задачей или проектом, а также сквозную приоритизацию проектов и довести ее до всех участников проекта.