Контакты

Выделенный центр разработки: новое слово в российском аутсорсинге

IT Manager - 23 июня 2010 - Артак Оганесян, EPAM

Обращение к аутсорсерам для разработки или модернизации информационной системы — достаточно распространенная в России практика. Но в большинстве случаев речь идет о привлечении подрядчика на основе моделей взаимодействия «фиксированная стоимость» или «фактические трудозатраты».

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

Когда нужен центр разработки?

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

В качестве подтверждения сравним модель работы с использованием выделенного центра разработки или компетенции (Outsourced/Offshore Development Center — ODC, Dedicated Development Center — DDC) с другими моделями взаимодействия с поставщиками ИТ-услуг. К их числу относятся фиксированная стоимость (fixed cost, FC), фактические трудозатраты (time&materials, T&M), фиксированная команда или именованные ресурсы (fixed team or dedicated named resources, FT), организация совместного предприятия (joint venture, JV). Для полноты картины сюда можно добавить и варианты с содержанием всех специалистов в штате ИТ-службы в центральном офисе компании (in-house team, IT) или в ее филиале (remote in-house team, RIT). Сравнение проводилось компанией EPAM Systems по ключевым для заказчика показателям: стоимость человеко-часа, точность соблюдения сроков, отклонение фактических трудозатрат от плановых, качество ПО, оценки по задачам и по проектам. Оценки заданы в диапазоне от 1 (наихудший вариант) до 5 (наилучший вариант — эффективный, экономически выгодный), для их определения использовался практический опыт EPAM Systems и статистика, накопленная в российской и западной ИТ-отрасли. Итоги подведены по среднеарифметическим данным (Таб. 1).

Таблица 1. Сравнение моделей аутсорсинга по ключевым показателям

Стоит обратить внимание на разброс оценок: 2–5 против 4–5. Чем больше разница в минимальном и максимальном значении для показателя, тем выше риск непредсказуемости (качество разработки ПО в случае удаленного филиала ИТ-подразделения может колебаться от низкого до очень высокого). Кроме того, в таблице не учитывается взаимосвязь показателей: достижение высокого качества работы внутренней команды может означать рост стоимости специалистов за счет вложений в повышение их квалификации. В результате максимальное значение итоговой оценки в последних двух столбцах может быть недостижимо на практике.

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

Подводные камни

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

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

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

Для минимизации этих рисков нужно сочетание четырех факторов:

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

Выбор поставщика

Приоритетные критерии выбора поставщика услуг для организации выделенного центра приведены в таблице 2.

Таблица 2. Приоритетные критерии выбора поставщика услуг

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

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

Условия сотрудничества

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

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

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

Прозрачная система управления

Выстраивание прозрачной системы взаимодействия ИТ-подразделения компании и специалистов центра — один из главных элементов снижения рисков использования этой модели аутсорсинга.

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

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

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

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

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

Метрики для оценки эффективности работы центра

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

Таблица 3. Метрики для оценки эффективности работы центра

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

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

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

Оригинал публикации