Как убить аутсорсинг
Еще Лев Толстой в романе «Анна Каренина» отметил, что все счастливые семьи счастливы одинаково, а каждая несчастная семья несчастна по-своему. Это тонкое наблюдение вполне подходит и к отношениям с поставщиками ИТ-услуг, в том числе аутсорсинга. В успешных отношениях наблюдаются примерно одни и те же практики, признанные «правильными», а практически у каждого неудачного контракта свой путь. Тем не менее в особо печальных случаях наблюдается несколько общих характеристик. Даже с появлением опыта и взрослением рынка отдельные ошибки имеют свойство появляться снова и снова, убивая проекты. Осведомленность об уже совершавшихся ранее ошибках ничему не учит следующее поколение менеджеров.
Эксперты консалтинговой компании Swingtide выделили 10 источников проблем, которые встречаются с удручающей регулярностью. На их основе они создали «инструкцию» по обрушению проектов.
• Не планируйте изменений. Часто компании знают, что потребуются изменения, но не задумываются, как они будут проводиться.
• Полагайте, что SLA начнут исполняться мгновенно. Неудовлетворенные клиенты часто сетуют, что целевые характеристики по цене и качеству достигаются далеко не сразу.
• Игнорируйте скрытые издержки. Многие заказчики бывают крайне разочарованы, когда им приходится нести дополнительные расходы.
• Начните управление проектом через два месяца после подписания договора. Часто выясняется, что у назначенных менеджеров не хватает на это времени, хотя первые месяцы проекта — самые рискованные.
• Часто изменяйте подписанный контракт. Практически любое изменение будет выливаться в увеличение стоимости услуг.
• Не выделяйте денег на тестирование. Во многих проектах сделанные изменения требуют тестирования ИТ-специалистами и пользователями. Возможно, что-то придется переделать.
• Полагайтесь исключительно на право разорвать контракт, если что-то пойдет не так. Стоимость выхода из сделки для заказчика всегда была велика. Следует искать компромиссные решения.
• Путайте перемещение людей с перемещением знаний. Когда клиент переводит людей в штат подрядчика, он зачастую полагает, что знания для компании не будут потеряны. Но подрядчик имеет право перевести приобретенных сотрудников на любой другой проект.
• Доверяйте отчетам поставщика об уровне сервиса. В 80% случаев они не точны.
• Полагайте, что ИТ-менеджеры в нерабочее время будут становиться специалистами по управлению отношениями с вендорами. В ИТ существуют «герои» — люди, работающие круглосуточно, знающие недокументированные детали и умеющие устранить любую проблему. Но именно такие люди не будут сидеть и читать 300-страничный контракт.
Скрупулезно формализовать отношения с подрядчиком бессмысленно: в любом случае за неудачу ответит ИТ-директор — таково единодушное мнение экспертов, высказанное в ходе дискуссии «KPI для подрядчика» на портале GlobalCIO.
«Даже на фоне того, что подрядчики становятся более адекватными и заинтересованными в результате, не многие из них предложат оценить KPI максимально полно», — считает Александр Шняк, руководитель ИТ-подразделения группы компаний «Марко». Очевидно, что на фоне большего количества KPI больше и ответственности.
В любом случае именно ИТ-директору придется эти коэффициенты формулировать и на него ложится ответственность за полноту этих данных. Кроме того, на разработку такой детализированной схемы KPI уйдет очень много времени, а потому многие просто не хотят тратить силы, а оценивают ситуацию «в общем».
«Если заказчик адекватно себя ведет, то оплата проекта будет только по факту оказания услуг с соответствующей приемкой. Исполнитель отвечает деньгами и репутацией», — подчеркивает Александр Огнивцев, руководитель управления сервисной поддержки компании «Альфастрахование». Если же компания-заказчик не в состоянии себя адекватно вести, то результат будет негативным. Понятно, что оплата по факту оказания услуг несколько дороже, но авансовые схемы в несколько раз повышают риски проекта. Заказчик для себя должен четко решить — либо он выбрасывает деньги на ветер, либо достигает результата.
«Мы у себя обсуждали вопрос создания показателей эффективности для ИТ-подрядчиков и в итоге все же решили вывести проектную деятельность из системы KPI», — делится Марк Шварцблат, директор департамента ИТ и проектного управления группы компаний «Квадрат». KPI нужны для вертикальной интеграции показателей в систему сбалансированных показателей, они гораздо удобнее для регулярной деятельности как индикаторы проблем и план-факта. Проектная же деятельность не является основной.
В любом случае все показатели сводятся к качеству, времени и ресурсам. У проекта эти параметры определены с допустимой точностью, а если проект длительный, то все равно ИТ-директор их отслеживает — постоянно или по этапам