Риск нарушения методологии ведения проекта
Это, пожалуй, первый и самый большой риск, с которым мне пришлось столкнуться. Его выявили не на стадии планирования проекта, а уже в процессе работы. Большой и непростой проект состоял во внедрении ERP-системы SAP R/3 на предприятии, оказывающем сервисные услуги. Объем проекта был достаточно велик, внедрялось пять модулей - FI, MM, CO, SD и CRM. Выявленный риск состоял в том, что проект велся не по методологии ASAP.
На самом деле ситуация очень распространенная, я сталкивался с ней не в одном проекте. Дело в том, что методологии внедрения ERP-систем требуют описания и утверждения огромного количества документов на разных стадиях. И на первый взгляд часть этих документов может показаться ненужной. Тем более что при внимательном рассмотрении оказывается: некоторые документы пишутся исключительно для того, чтобы в случае неудачи подстраховать производителя ERP-системы и компанию-внедренца от претензий. Поскольку методологии, как правило, созданы либо поставщиками систем, либо компаниями-внедренцами, они неминуемо направлены на защиту их интересов.
Понимая все это, мы в начале проекта решили некоторые документы просто не делать, пропустить. И все были согласны - компания-внедренец пошла нам навстречу, потому что считала, что проект маленький. Менеджеры финансового и коммерческого департаментов то же самое считали - "зачем нам это все надо, и так понятно". Ведь в принципе кампания небольшая, около 500 сотрудников, все и так в курсе происходящего. У нас было налажено управление рисками этого проекта, но на такой риск - вообще говоря, считающийся типовым и входящий в стандартный список рисков ИТ-проекта, - никто просто не обратил внимания.
Все это продолжалось до стадии настройки системы, пока вдруг один из менеджеров не заметил: "Посмотрите, у нас ведь финансовый модуль настраивается чуть ли не на глазок, мы ведь не продумали на стадии концептуального проектирования вот эти и эти вопросы". Подняли документацию, посмотрели и увидели, что на самом деле это именно так. После этого было принято решение вести весь проект по методологии ASAP. Но потери от риска были огромными - мы вынуждены были сразу израсходовать почти половину, 3% средств, из 10% резерва в бюджете этого проекта. В результате, когда сыграли три других риска, нам не хватило средств, выделенных в этом резерве. Бюджет проекта был превышен. Мы вынуждены были выделить дополнительных 30 человеко-часов на переделку сделанного и пересмотреть ожидаемые сроки сдачи проекта почти на полтора месяца. Вот цена некачественного управления рисками.
Риск недостаточной заинтересованности менеджеров
Второй риск, с которым я столкнулся, - это недостаточная задействованность функциональных менеджеров. Несмотря на все PR-мероприятия по проталкиванию проекта, мотивацию и приказы руководства предприятия функциональные менеджеры все-таки воспринимали проект как сугубо внутренний, не приносящий прибыли и уделяли больше внимания внешним задачам и проблемам.
В нашем перечне рисков мы учитывали риск недостатка времени у функциональных менеджеров. Например, конкретный менеджер должен согласовать схему бизнес-процессов, но он ведь может заболеть, уехать в командировку или в отпуск. А кроме него это сделать никто не может. Этот риск был выявлен и оценен. Его вероятность согласно экспертной оценке была средней (около 0,3), влияние на бюджет - минимальным. Но он оказывает среднее влияние на сроки и существенное влияние на качество решений. Поскольку общая величина риска была значительной, то для его минимизации были приняты определенные меры. Но риск того, что нам не удастся в достаточной степени заинтересовать функциональных менеджеров, учтен не был. Тем не менее он сработал, и при утверждении концептуального проекта нам пришлось потратить дополнительно несколько дней на его устранение. Оценка ущерба от него - несколько дней работы руководителя проекта (что эквивалентно 20-30 тыс. долл.), которые я теперь непременно закладываю в график каждого ИТ-проекта.
Риск неверного технического решения
Это тоже стандартный риск, который прописан во всех перечнях проектных рисков. Но проблема не в том, чтобы его выявить, а в том, как оценить его величину. Можно при старте проекта, когда мы согласовываем план и бюджет, предусмотреть то, что где-то было принято неверное проектное решение. И очень на многих проектах это делается. Предусматриваются бюджетные резервы - откуда можно взять бюджет на доработку и изменение проектного решения - и резервы времени.
Конечно, посчитать конкретную величину этого риска невозможно. Как оценить то, что на этапе проектирования принято на 5% неоптимальное решение? Так, при настройке ERP-системы и реализации бизнес-процессов в ряде случаев могут быть выбраны разные варианты, каждый из которых по-своему близок к оптимальному и имеет свои риски. Мы учитывали, что этот вариант решения имеет такие-то риски, а этот вариант - такие-то. Но оценить их величину было невозможно. Поэтому мы прибегли к опыту проектов в западных странах. Как правило, этот резерв составляет от 10 до 20% стоимости проекта и от 5 до 10% резерва времени. Кроме того, мы минимизировали риски, прибегнув к многошаговой процедуре утверждения проектного решения, но не привлекали внешний аудит.
Однако принятых мер оказалось недостаточно: риск сработал, и где-то на середине проекта мы увидели, что проектное решение неверно. Само по себе это не так страшно, но в нашем случае мы имели дело с чрезвычайно инновационным проектом - реорганизацией и оптимизацией работы крупного склада посредством технологии RFID и соответствующего ПО. Такие проекты в то время (пару лет назад) были еще в диковинку, опыта не накопилось, а у компании, с которой мы проводили внедрение, это вообще был первый подобный проект. В определенной степени они учились на этом проекте. Мы понимали это и потребовали повышенного внимания к этому проекту с их стороны, и они на это пошли, но мы недооценили этот риск.
В результате технического анализа оказалось, что решение неверно и его надо переделывать почти на 50%. Никакие 10% резерва денег и времени, которые мы выделили на этот риск, не смогли его компенсировать. Бюджет проекта был превышен почти на 250 тыс. долл. (около четверти бюджета проекта), а сроки перенесены на три месяца (треть времени проекта). Такова цена недооценки степени инновационности проекта.
Риск снижения производительности
Следующий риск также присутствует во всех списках типовых рисков ИТ-проекта. Известно, что при запуске в продуктив новой ERP-системы или бизнес-приложения производительность всегда будет падать. Система новая, и как бы мы ни тренировали сотрудников, они привыкли работать со своими процессами в своей старой системе. А с изменениями снижается темп работы - например, уменьшается отгрузка продукции и соответственно доходы компании. К сожалению, это объективно, с этим надо мириться. Конечно, производительность потом вырастает, но при запуске она объективно падает. Понимая это, мы приняли данный риск и оценили его.
При планировании проекта нужно принять решение, как запускаться. Когда мы планировали проект, то оценили степень падения производительности примерно в 10% (это была экспертная оценка, основанная на опыте аналогичных проектов). Исходя из этого была назначена определенная дата пуска системы. Но когда мы провели некоторые подготовительные мероприятия к запуску системы на более мелких объектах и отследили тенденцию снижения производительности, то насторожились. Оказалось, что ожидаемое снижение производительности существенно выше - 20-25%. Мы доложили эту информацию руководству. Ответ был такой: "Если мы сейчас запускаем систему на наиболее важных для бизнеса объектах, то наши доходы серьезно падают, мы теряем конкурентное преимущество. Это очень большой риск для компании, и мы не можем на это пойти. Необходимо сначала разработать превентивные мероприятия по снижению этого риска. Сколько вам нужно времени, чтобы полностью решить эту проблему?" - "Год". - "Тогда давайте перенесем запуск системы на год".
Конечно, за год можно все отладить, повторно обучить и протестировать сотрудников, в общем, много чего можно придумать для минимизации риска. Однако это решение порождает встречные риски.
Если переносить на год запуск системы на серьезных объектах, то появляется, во-первых, риск расхолаживания проектной команды. Проектная команда должна иметь очевидную цель, и тогда она будет напряженно работать. Во-вторых, есть большой риск, что за год сотрудники проектной команды могут уйти на другую работу, потому что, занимаясь проектом, приобрели ценные знания и повысили свою ценность на рынке.
В-третьих - возникает риск изменения бизнес-процессов. Если мы работаем на проекте автоматизации процессов некоторой бизнес-единицы, которая имеет некоторый организационный цикл, то изменение процессов этой бизнес-единицы во время хода проекта должно быть в пределах 10%. Мы должны, в некотором смысле, ситуацию замораживать. Это требуют все методики внедрения бизнес-приложений. И это оправданно. Поэтому такие системы, как ERP, все-таки должны ставиться на более-менее устойчивую организационную структуру. Допустим, мы знаем, что в этой операционной единице больших изменений не предполагается, то есть бизнес работает, приносит доход, но нас не устраивает, как он организован на уровне информационной поддержки. Тогда мы начинаем проект по автоматизации бизнес-процессов этой единицы.
Увеличение срока проекта на год - очень серьезное изменение "замороженного" периода. Появляется огромный риск, что за это время изменится операционная и организационная структура. В результате проектное решение нужно будет пересматривать. Таков основной риск при затягивании проектов внедрения бизнес-приложений. В результате, если переносить запуск на год, возникает риск, что мы вообще не запустим систему и поставленная цель проекта вообще не будет достигнута. Это очень большой встречный риск.
Все эти риски были изложены на руководящем комитете проекта. И решение, которое мы приняли, было компромиссным. Мы договорились перенести запуск не на двенадцать месяцев, а на пять. За это время уточнить стратегию перехода, сделать очень четкий детальный план с контролем, с мониторингом, аккуратно проанализировать все риски и т. д. И это решение было абсолютно правильным: в результате мы запустили систему с небольшим уменьшением производительности на 7%. Какова была стоимость риска недооценки падения производительности? Детальный отчет мы не составляли, но отодвигание срока запуска на пять месяцев потребовало увеличения бюджета проекта на 30%.
