Зачастую аутсорсинг — это выход, но что вы скажете своим сотрудникам? Мэри Шеклет, президент консалтинговой компании Transworld Data, обсуждает на портале InformationWeek некоторые положительные и отрицательные аспекты аутсорсинга, понимание которых может сделать его беспроигрышным для всех.

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

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

Когда следует передавать работу на аутсорсинг

  1. Когда у вас нет абсолютно никаких внутренних альтернатив для выполнения работы, а сроки проекта слишком сжаты, чтобы позволить развивать внутренние ИТ-навыки. Существуют отличные сценарии для аутсорсинга. Один из них — когда вам срочно нужны навыки для проекта, который не терпит отлагательств, и нет времени на повышение квалификации сотрудников для этого проекта. В такой ситуации и сотрудники, и ИТ-руководители понимают практическую необходимость аутсорсинга, и это будет особенно хорошо воспринято, если вы заранее предупредите сотрудников, а также если у вас есть план повышения квалификации сотрудников, чтобы они могли продолжить работу над проектом после его завершения.
  2. Когда работа утомительна и занимает много времени. Если у вас есть проект преобразования, в котором миллионы строк кода и/или элементов данных должны быть преобразованы вручную из-за отсутствия на рынке подходящего инструмента, имеет смысл передать эту работу группе, которая может справиться с этими утомительными и повторяющимися действиями, выполняя их «вручную». Ваши ИТ-специалисты смогут продолжить работу над более стратегическими проектами, и они будут благодарны вам за то, что вы сняли с них эту ответственность.
  3. Когда компании нужна новая система и лучше всего выбрать систему «под ключ». Когда поставщик поставляет систему «под ключ» (например, CRM), обычно предполагается, что он будет продолжать поддерживать и улучшать эту систему. Таким образом, система становится аутсорсинговой. Покупка систем «под ключ» и предоставление им возможности функционировать в рамках своих лучших методик и функций — это ИТ-практика, которая работает уже много лет.
  4. Если для тестирования приложений вам потребуется больше ресурсов для обработки и хранения данных, обратитесь к облачному провайдеру. Многие коммерческие поставщики облачных вычислений теперь предлагают хранение, обработку и настройку приложений для тестирования по требованию. Это отличная возможность для аутсорсинга, которая может сэкономить драгоценное время администраторов баз данных и сотрудников системной поддержки, поскольку им больше не придется выкраивать время из своего графика для создания тестовых сред для группы разработчиков приложений.
  5. Всегда сообщайте сотрудникам о причинах, прежде чем принять решение о заключении соглашения об аутсорсинге. Это событие может напугать ваших сотрудников, которые вдруг заинтересуются гарантиями сохранения рабочих мест и тем, планирует ли компания вообще вкладывать средства в повышение квалификации сотрудников внутри компании. Если вы заранее объясните сотрудникам, почему вы хотите прибегнуть к аутсорсингу и каковы долгосрочные планы после его завершения, вы сможете снять тревогу и сохранить доверие персонала.

Когда не следует передавать работу на аутсорсинг

  1. Когда у вас нет плана по развитию внутренней экспертизы. Если вы не будете вкладывать средства в развитие внутренней экспертизы, вы поставите себя в полную зависимость от времени и навыков ваших внешних помощников. Это рискованное положение. Кроме того, это не вызовет положительных эмоций у сотрудников ИТ-отдела, которые, вероятно, считают, что компания должна инвестировать в обучение внутренних специалистов, чтобы они могли взять на себя проекты, которые изначально выполнял аутсорсер.
  2. Когда аутсорсер не хочет предоставлять вам исходный код. Ваша цель — взять на себя управление кодовой базой после завершения работы аутсорсера. Для этого вам нужен как исходный, так и объектный код. Именно исходный код позволит вашим сотрудникам взять на себя управление кодовой базой и поддерживать ее после завершения работы аутсорсера.
  3. Не передавайте всю систему на аутсорсинг поставщику решения «под ключ», если он не обязуется соблюдать SLA по миграции системы на свою платформу и обратно. Мигрировать с одной системы на другую всегда непросто. Обязательно заключайте набор соглашений об уровне обслуживания со всеми новыми поставщиками. Цель SLA — обязать поставщиков соблюдать определенные уровни производительности при миграции на их платформы и, при необходимости, при миграции с их платформ.
  4. Не передавайте на аутсорсинг критически важные приложения. Компании должны очертить круг своих критически важных приложений и сохранять над ними полный контроль. Это обязательная стратегия управления рисками, поскольку даже если вы разместите критически важное приложение в облаке надежного поставщика, нет никакой гарантии, что он не будет приобретен, подвергнут слиянию или не произойдет смена руководства, которая может затруднить продолжение хостинга.
  5. Не передавайте приложения на аутсорсинг, не пообщавшись сначала с сотрудниками. Я видела ИТ-среды, где было принято решение о передаче на аутсорсинг, аутсорсинг начался, а весь ИТ-персонал был застигнут врасплох, потому что никто не сказал им, что вся система или проект будут переданы на аутсорсинг. В большинстве случаев это происходит из-за недостаточной коммуникации со стороны CIO или руководителей проекта, и долгосрочный эффект от этого может быть разрушительным. ИТ-персонал может начать не доверять руководству и его конечным мотивам. Ключевые сотрудники могут начать уходить, опасаясь за свою работу. Это также может привести к ухудшению морального состояния персонала, поскольку сотрудники видят, что аутсорсеру достается вся новая и интересная работа, а они и их навыки остаются за бортом.