Как убить аутсорсинг

Еще Лев Толстой в романе «Анна Каренина» отметил, что все счастливые семьи счастливы одинаково, а каждая несчастная семья несчастна по-своему. Это тонкое наблюдение вполне подходит и к отношениям с поставщиками ИТ-услуг, в том числе аутсорсинга. В успешных отношениях наблюдаются примерно одни и те же практики, признанные «правильными», а практически у каждого неудачного контракта свой путь. Тем не менее в особо печальных случаях наблюдается несколько общих характеристик. Даже с появлением опыта и взрослением рынка отдельные ошибки имеют свойство появляться снова и снова, убивая проекты. Осведомленность об уже совершавшихся ранее ошибках ничему не учит следующее поколение менеджеров.

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

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

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

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

Начните управление проектом через два месяца после подписания договора. Часто выясняется, что у назначенных менеджеров не хватает на это времени, хотя первые месяцы проекта — самые рискованные.

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

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

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

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

Доверяйте отчетам поставщика об уровне сервиса. В 80% случаев они не точны.

Полагайте, что ИТ-менеджеры в нерабочее время будут становиться специалистами по управлению отношениями с вендорами. В ИТ существуют «герои» — люди, работающие круглосуточно, знающие недокументированные детали и умеющие устранить любую проблему. Но именно такие люди не будут сидеть и читать 300-страничный контракт.

Скрупулезно формализовать отношения с подрядчиком бессмысленно: в любом случае за неудачу ответит ИТ-директор — таково единодушное мнение экспертов, высказанное в ходе дискуссии «KPI для подрядчика» на портале GlobalCIO.

«Даже на фоне того, что подрядчики становятся более адекватными и заинтересованными в результате, не многие из них предложат оценить KPI максимально полно», — считает Александр Шняк, руководитель ИТ-подразделения группы компаний «Марко». Очевидно, что на фоне большего количества KPI больше и ответственности.

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

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

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF