Измена ИТ-партнеру: предательство или защита?

Абсолютно все проекты по автоматизации бизнес-процессов сопряжены с проблемами. Но не всегда можно выявить среди текущих затруднений фатальные ошибки, которые приведут к полному провалу проекта.

Как отличить первое от второго и в какой момент необходимо радикально изменить ход проекта ради его успешного завершения? Разобраться в жизненных циклах внедрения и выявить зоны особого риска «Консультанту» помог Олег Лысов.

Cправка об авторе:

Олег Лысов родился в 1976 году. Окончил Санкт-Петербургский государственный морской технический университет по специальности «Информационно-измерительные системы». Свою карьеру начал в 1996 году в ЗАО «Царскосельская энергетическая компания», последовательно занимал должности консультанта, руководителя проектов, руководителя департамента IТ. С 2004 года руководил направлением ERPв компании DigitalDesign. С 2008 года работает в GMCS в должности директора департамента продуктов Microsoft. Под его руководством выполнено множество крупных IТ-проектов, в том числе для таких компаний, как «ОГК-4», Valio, «Синтерра» и др.

«Консультант»: Сейчас в тяжелой экономической ситуации некоторые компании предпочитают отказываться от завершения IT-проектов. В сознании немалого числа директоров внедрение стало сродни ремонту: нельзя закончить, возможно лишь временно прекратить. Успешных проектов в разы меньше, чем незавершенных. В чем же причина?

Олег Лысов: Каждый проект сопряжен с рядом трудностей. Если коммуникация между партнером и клиентом налажена, то эти трудности преодолеваются, и работа по проекту проходит удачно. Но не всегда отношения складываются гладко, и проблемы, которые остались без решения, на каком-то этапе оборачиваются серьезным конфликтом. Клиент теряет доверие к подрядчику и либо меняет партнера, либо принимает решение заморозить проект совсем.

«Консультант»: Значит, смена партнера – крайняя мера. В какой момент может произойти переход?

Олег Лысов: Он возможен практически на любом этапе. У нашей компании есть опыт «перехватов» на всех фазах. Опираясь на этот опыт, могу сказать, что самым тяжелым является переход после этапа проектирования, перед запуском системы, или уже в ходе опытно-промышленной эксплуатации.

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

«Консультант»: Куда уходит доверие? И на ком в данном случае лежит ответственность за неудачный запуск?

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

С одной стороны, очевидно, как избежать подобной ситуации: четко формулировать цели внедрения и ответственно относиться к техническим документам. С другой стороны, следовать этим принципам на практике получается далеко не всегда и не у всех. Если все сложилось не самым лучшим образом, у клиента есть два пути разрешения ситуации: остановить проект либо привлечь к нему третью сторону. Новая команда входит в проект в качестве «скорой помощи». Если партнер, который начинал внедрение, не «реабилитируется», то это приводит к его замещению.

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

«Консультант»: Насколько сильно может вырасти бюджет внедрения в связи со сменой поставщика?

Олег Лысов: Бюджет может увеличиться в разы, а может – на несколько процентов. Все зависит от ситуации: состояния проекта, стадии, на которой происходит перехват, запаса времени и так далее. Смена партнера – это результат реализации комплекса операционных рисков. Риск-менеджеру вместе с финансовым директором необходимо заранее, еще на стадии принятия решения о внедрении проекта, оценить эти риски и определить сумму, которую компания может выделить на случай их реализации. К сожалению, на практике об этом часто забывают. В результате может возникнуть следующая ситуация: клиент истратил три четверти бюджета на реализацию одной четверти проекта, после чего принял решение о смене партнера. Новому подрядчику предлагается завершить внедрение за оставшиеся деньги. Поскольку работать по «ценам ниже рыночных» никто не хочет, клиент приходит к выводу, что без дополнительного финансирования внедрение не закончится никогда, и становится перед выбором: признать уже потраченные средства безнадежно утерянными и закрыть проект либо влить в него дополнительные деньги и получить рабочую систему. Выбор второго варианта провоцирует следующий вопрос: сколько допустимо потратить сверх бюджета. Если в свое время риск-менеджер оценил ситуацию, а финансист предусмотрел под нее резерв, озвученный вопрос решается автоматически. Если же предварительной оценки не было, компании предстоят дополнительные траты на аудит незавершенного проекта. Как правило, для проведения аудита приглашается сторонняя компания, которая не имела отношения к данному проекту и не будет привлечена к нему в будущем, что обеспечивает объективность оценок. Аудиторы определяют, на какой стадии находится проект, где допущены ошибки, и, соответственно, устанавливают фронт работ и их примерную стоимость.

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

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

«Консультант»: Что еще, помимо систематического аудита, можно порекомендовать заказчику внедрения для минимизации возможных потерь?

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

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

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

«Консультант»: Допустим, компания успешно пережила этап проектирования. Какие «грабли» ожидают ее в дальнейшем?

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

Если на фазе проектировки в работе над проектом участвуют только ответственные лица из числа инициаторов, то на этапе тестирования системы в процесс оказываются втянуты все пользователи. Именно в этот момент поднимается самая сильная волна возмущения. Недовольство системой непременно сопровождает процесс внедрения. Есть верная примета – если во время тестирования все довольны, значит, системой никто не пользуется! Определенный «фон» должен существовать обязательно. Задача партнера – отличить конструктивную критику от простого «ворчания» и отрабатывать недостатки. Это самый ответственный для подрядчика этап, именно на нем проявляются в полном объеме его управленческие качества, гибкость, умение находить компромиссы на всех уровнях, от младшего пользователя до генерального директора. Для клиента этот период также очень тяжел как в экономическом, так и в психологическом плане. Внедрение крупного проекта, как и любая оптимизация, вызывает напряженную обстановку в коллективе. Снижается производительность труда, нередко происходит очередь увольнений. Раздражение передается от «низов» к «верхам». В этот период наиболее высок риск личностных конфликтов между заказчиком и подрядчиком, и неумение разрешать их приводит к замене партнера, сопровождаемой скандалами, шумихой в прессе, взаимными претензиями и денежными требованиями. Я не помню случаев обращения в суд, но есть масса примеров, когда не подписывались месяцами акты выполненных работ или не возвращались авансы.

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

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

«Консультант»: В каком случае смена подрядчика происходит с наименьшими потерями?

Олег Лысов: Самая мягкая ситуация складывается при замене партнера на стадии поддержки. Почему-то считается, что поддержка является отдельной услугой. Нет, сервисное обслуживание системы такая же часть работы, как и опытно-промышленная эксплуатация.

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

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

«Консультант»: Значит даже в самом безболезненном варианте смена партнера остается «ложкой дегтя». Можно ли найти в этом опыте положительные стороны?

Олег Лысов: Не важно, позитивный или негативный опыт приобрела компания и по каким причинам произошло замещение. Главное, что благодаря этому сформировались четкие цели и понимание того, что нужно от системы, а в чем нет необходимости. То есть повторный выбор партнера делается осознанно, в то время как первоначальный выбор мог быть совершен под воздействием эмоций, иллюзий, рекомендации знакомых, без учета индивидуальных потребностей.

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

Кому-то необходимо четкое соблюдение сроков и бюджетов и минимальное вмешательство в пространство компании.

Кроме того, при замещении обязательно выбирается партнер с опытом перехватов проектов. Например, представим самую распространенную ситуацию – перехват на этапе тестирования. Пользователи уже ненавидят систему, а консультанты – это ее олицетворение. Смена одних «засланцев» на других не снимет негатив. Задача консультанта не только исправить и наладить систему, но и примирить с ней пользователей. Показать и доказать, что все не так плохо, что недочеты исправляются, объяснить причины их возникновения, в конце концов приказать сжать зубы и преодолеть сложный период. Справиться с этой задачей может лишь специалист, который уже «поварился» в этом и знает, на какие рычаги когда нужно воздействовать.

Такие специалисты не могут стоить дешево. Также дополнительные затраты для компании повлечет срочность исполнения проекта. Однако рабочий проект за 10 000 лучше, чем нерабочий проект за 5000 ровно в 10 000 раз.

Мнения экспертов

Залог успеха в сознательности клиента

Наталья Семушкина, заместитель директора по экономике и управленческому учету Группы компаний «ВОГ»:

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

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

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

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

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

Рынок услуг – рынок клиентов?

Илья Тарасов, директор управления ИТ и организационного развития ЗАО «АРМО»:

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

Отдел финансов первый в очереди

Екатерина Воропаева, вице-президент GMCS:

Внедрение системы всегда начинается в компании с автоматизации одного из ее бизнес-процессов. А так как финансовый департамент наиболее прозрачен и структурирован, интеграция, как правило, начинается с этого отдела. Что хотелось бы посоветовать финансовому директору, которому предстоит курировать внедрение:

• четко сформулировать цель проекта. Если клиент не может внятно изложить требования к системе, значит, в ней нет необходимости;
• определить контрольную дату, когда должен быть достигнут первый результат. Если спустя шесть месяцев с момента старта проекта система хотя бы частично не работает, это нездоровый признак.