Почему проваливаются проекты в сфере IT-аутсорсинга? Часть 3

Проведение работ

Нет встреч на уровне топ-менеджмента

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

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

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

Не учтены риски

Риски — это отклонения от плана, которые могут возникнуть вследствие изменений условий сотрудничества. И риски есть всегда. Каким бы опытом не обладал поставщик или ваша компания, сколь компетентными и лояльными не были бы ваши сотрудники. Типичные риски: ухудшилась экономическая ситуация, как для поставщика, так и для клиента; необходимые данные находятся в состоянии намного худшем, чем предполагалось на этапе подписания контракта; уходит ключевой сотрудник со стороны клиента или с нашей стороны; подводят наши поставщики и т.п. Вы даже не представляете, сколько проектов в сфере IT-аутсорсинга проваливается только потому, что стороны забывают договориться о рисках! Банальный пример: у клиента уволился главный бухгалтер, который вел весь проект и имел доступ ко всем данным. Проект встает, сроки сильно сдвигаются, все несут издержки. А бывают ситуации и с более плохим финалом. Хотя, если бы были алгоритмы работы в таких ситуациях, все было бы решаемо.

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

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

Не учтено отношение сотрудников

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

Другой случай — с IT-руководителем. Допустим, у него в подчинении 5–6 программистов, и это — целый крупный IT-бюджет, которым он заведует. После вовлечения в работу аутсорсеров вся работа этого руководителя сводится к управлению договорами с этими аутсорсерами. Подчиненных почти или совсем нет, за сервис отвечает внешняя компания или несколько компаний. Как следствие, роль этого руководителя в компании может быть существенно упрощена, а иногда и совсем упразднена. И он, возможно, осознает, что для компании так — эффективнее. Даже скорее всего. Но у него есть и свои интересы, и очень вероятно, что он будет сопротивляться заключению контракта и всей дальнейшей работе по нему. Причем бывает даже так, что топ-менеджмент не понимает, кто в его компании блокиратор и что он вообще присутствует. В итоге весь аутсорсинговый проект объявляется провальным.

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

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

Непонимание необходимости значимых собственных усилий

Есть такие клиенты, которые думают, что аутсорсинг — это волшебная палочка. И что он заработает сам по себе, сразу и эффективно. Но это, конечно же, не так. Ведь люди, которые работают в компании-аутсорсере, они не умеют читать мысли. Поэтому они не могут запустить проект без участия сотрудников клиента. Аутсорсинг — это всегда совместный проект, особенно — поначалу.

Некоторые руководители активно включаются в переговоры на первом этапе, но с момента подписания контракта вдруг попадают. Им кажется, что как только контракт подписан, с этих пор проект полностью в руках аутсорсера. Таким отношением менеджер подписывает проекту смертный приговор. Представители поставщика, конечно, будут бегать за ним и теребить его. Бывает, что руководство «приходит в себя». А бывает, наоборот, резко негативная реакция: мол, мы вам заплатили, мы с вами контракт подписали, отстаньте от нас. Хорошо, мы отстанем, но с кем же нам взаимодействовать, у кого запрашивать данные, информацию, кто, в конце концов, будет принимать нашу работу?.. Вся коммуникация на стратегическом уровне (включая обсуждение вектора развития бизнеса) и на оперативном уровне (включая расстановку целей и приоритетов) остается за клиентом. Вроде бы, это даже очевидно, но я уже объяснил, как редко на деле соблюдается столь очевидная вещь.

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

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

Отсутствие оперативного контроля

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

Отсутствие анализа неудачи

Здесь я говорю только о тех проектах, которые закончились плохо. Да, такое случается. И чаще всего — из-за того, что были допущены какие-то из перечисленных мной ошибок. Но вот у компании случилась неудача, аутсорсинговый проект был свернут и забыт. И все, никакого анализа. Да, проект умер, но давайте разберемся, почему это произошло!

Странно отказываться от аутсорсинга в целом, испытав неудачу. Аутсорсинг — это подход, и он гарантирует успешный результат только если вы все делаете правильно. У вас есть негативный опыт в сфере IT-аутсорсинга? Проанализируйте объективно, что послужило причиной? Быть может, вы и сами допустили ошибки?

Я слышал от руководителей различного уровня истории вроде такой: пару раз пробовали, не получилось, в итоге само направление аутсорсинга было признано неуспешным. Но если я спрашиваю их, был ли проведен детальный анализ причин провала сразу же после этого самого провала, причем самого первого, а не какого-то по счету, я всегда узнаю: нет. У них есть предположения, и они всегда касаются несостоятельности поставщика в плане качества услуг. Но если я задаю вопросы и мы пробегаемся по этому списку ошибок, оказывается, что многие из них делал и сам клиент.

Сергей Кожин
генеральный директор филиала компании «1С-Рарус» в Санкт-Петербурге