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

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

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

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

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

«В случае провала проекта (в любой конфигурации – с подрядчиком или без) ответственным всегда выставляется CIO», — продолжает Шняк. – Хотя очевидно, что ИТ не может нести полную ответственность за автоматизацию бардака, а именно такой подход очень часто практикуется». В итоге такой автоматизации, именно «выставляется» является точным определением того, что происходит при «разборе полетов».

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

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