Кто не рискует: управление рисками ИТ-проекта

Исследования, проводимые в сфере разработки и внедрения ИТ-проектов, показывают, что только около 30…40% от общего числа всех внедрений завершается успешно. Как оценить успешность ИТ-проекта? По трем основным критериям:

- соблюдение бюджета проекта;

- соблюдение запланированных сроков проекта;

- достижение цели, поставленной перед началом внедрения, удовлетворение всех ожиданий заказчика.

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

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

Вижу цель! 

Корректное выявление целей заказчика

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

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

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

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

Тянем потянем. Трудноисполнимые сроки проекта

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

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

За двумя зайцами 

Влияние смежного ИТ-проекта

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

Кадры решают все 

Квалификация специалистов

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

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

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

Где будем делать талию?

ИТ-инфраструктура заказчика

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

Ты кто такой? Давай, до свидания! 

Взаимодействие со смежными контрагентами заказчика

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

Учиться, учиться и еще раз учиться. 

Обучение пользователей

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

www.westconcept.ru