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

Они никогда не заканчиваются?

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

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

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

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

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

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

Естественно, завершение работ всегда должно сопровождаться подписанием документа, свидетельствующего о завершении проекта (часто - акта приема-сдачи работ). Причем, не стоит думать, что эта формальная "бумажка" нужна только исполнителю, как часто приходиться слушать. "Документ важен как для заказчика, так и для исполнителя, - отмечает Виктор Горбунов, директор по консалтингу группы "Борлас". - В противном случае проект будет бесконечен, и взаимными претензиями могут быть погублены достигнутые результаты". Более того ,в мировой практике управления проектами допустимо, чтобы этот документ содержал перечень замечаний, устраняемых в согласованном порядке.

Важно отметить, что, вопреки распространенному мнению, не обязательно на любой ИТ-проект готовить техническое задание. Техническое задание - только один из способов установить критерии выполнения обязательств исполнителя перед заказчиком. Методологией внедрения вполне могут быть определены и другие документы. "Разновидностей договоров великое множество, в зависимости от условий, на которых "сошлись" заказчик и исполнитель", - говорит Виктор Горбунов. Правда, надо сказать, что в ряде случаев отсутствие документа, озаглавленного "Техническое задание", вызывает трудности при закрытии проекта, особенно когда внутрикорпоративная практика компании предполагает обязательное наличие именно ТЗ. Единственный способ застраховаться от подобных проблем - четко планировать этап сдачи проекта еще перед его стартом.

Регламентированное расширение

Одна из сложностей здесь состоит в том, что по ходу проекта могут произойти (и, как правило, происходят) изменения объема или рамок проекта. Как в этом случае согласовать критерии окончания работ по проекту? "Если изменения производились с помощью соответствующей процедуры управления изменениями, то они никоим образом не влияют на закрытие работ, так как уже учтены в проекте", - говорит Сергей Киреев (TopS BI). "Организационные документы проекта должны предусматривать процедуры управления изменениями, - соглашается Виктор Игнатов (IBM Business Consulting Services). В соответствии с этими процедурами в случае расширения объема проекта могут быть пересмотрены первоначальные сроки, результаты и критерии завершения проекта". Заметим, что именно в этот момент возникает необходимость пересмотра сроков проекта, но это уже не неконтролируемое "ИТ-проекты никогда не заканчиваются", а расширение, четко регламентированное проектным управлением. В российской практике, если в процессе проекта расширился круг задач или объем работ, подписывается дополнительный договор, условия которого, как правило, выполняются уже после завершения основного проекта. "И чем сложнее основной проект, тем жестче мы настаиваем на последовательном выполнении дополнительных работ", - замечает Сергей Крутов ("Верисел Проекты").

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

Скрытые конфликты

Составление таких документов необходимо, но, как показывает практика, его совершенно недостаточно для нормального завершения проекта. Казалось бы, интересы заказчика и исполнителя при закрытии проекта должны совпадать! Теоретически они и совпадают, однако на практике конфликты в понимании критериев окончания проекта случаются. "Конечно, каждый ИТ-проект имеет специфику, - говорит Сергей Крутов ("Верисел Проекты"). - Мы различаем принципиально два типа: проекты, реализация которых приведет к изменению бизнес-процессов у заказчика, и все остальные. Проблемы формального закрытия проекта обычно возникают, если мы реализуем проекты с изменением бизнес-процессов у заказчика. В таких проектах на первое место выходит человеческий фактор. Если персонал заказчика, участвующий в проекте, целенаправленно не мотивирован на его успех, то можно столкнуться с нежеланием, отторжением, саботажем, конфликтами и так далее".

Что делать в этом случае? Спорные вопросы обычно решаются путем переговоров. Если сторонам не удается согласовать акт приемки системы (или акт по закрытию промежуточного этапа) с помощью стандартных процедур согласования документов в проекте, то эффективным механизмом решения данной проблемы может стать независимый аудит. "Опыт TopS BI по проведению независимого аудита основан, в частности, на аудите всех стадий проекта по внедрению Oracle E-Business Suite в компании "Вымпелком" и компании "ИФД КапиталЪ". Он свидетельствует, что с помощью внешней команды консультантов удается в кратчайшие сроки сформировать независимую оценку по спорным вопросам проекта, - говорит Александр Тукунов, директор по развитию бизнеса консалтинга компании TopS BI. - Такая оценка может служить серьезным подспорьем при приемке системы".

Уход консультантов

Закрытие проекта означает, что консультанты должны уйти. Именно такой исход дела, чаше всего, предполагают как заказчики, так и исполнители. "Да, мы изначально ставили такую цель, - говорит руководитель проекта внедрения ERP-системы mySAP Business Suite в одной из крупных российских компаний. - После того как система будет запущена в промышленную эксплуатацию, мы собирались отказаться от услуг консультантов. Эта цель была заложена в плане проекта". Уход консультантов должен стать как можно менее заметным и болезненным для заказчика событием, однако отнюдь не всегда так происходит в действительности. Например, трудности с поддержанием функционирования ERP-системы после ухода консультантов могут быть вызваны как недостаточной квалификацией ответственного персонала на предприятии, так и неэффективной организацией работы. "Проблемы у заказчика после завершения проекта и ухода консультантов возникают, если интегратор не осуществил два важных этапа при реализации проекта, - считает Сергей Крутов. - Первое - это обучение персонала заказчика, а второе - аттестация персонала на предмет соответствия полученным знаниям. И если обучение персонала обычно проводится, то аттестация совместно с представителями заказчика - большая редкость".

Как минимизировать эти риски? Очевидно, чтобы уход консультантов был менее болезненным, необходимо организовать активнейшее участие специалистов заказчика в работах в ходе всего проекта. Как правило, они обучают конечных пользователей, составляют инструкции, тестируют систему, готовят данные из унаследованных систем для конвертации, но при этом не участвуют в наиболее сложных работах по внедрению системы. Это принципиальная ошибка. "Мы последовательно готовили нашу внутреннюю команду. Мы все больше и больше вовлекали их в процесс проработки проектных решений и готовили к сопровождению системы", - замечает тот же руководитель проекта внедрения ERP-системы. - Консультанты и наша внутренняя команда вместе рассматривали все основные аспекты построения системы, выбирали наилучшие методики обслуживания этих процессов. И в конечном итоге наша команда вышла на уровень профессионализма, сравнимый с консультантами". "При правильно организованном проекте передача функций поддержки происходит на протяжении всех фаз проекта", - подтверждает Виктор Горбунов ("Борлас"). Таким образом, постепенно специалисты служб заказчика приобретают необходимые знания и навыки, а перед запуском в промышленную эксплуатацию полностью берут эти функции на себя.

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

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

Закрытие ИТ-проекта определяет уровень зрелости ИТ-службы

Александр Буйдов, директор по ИТ компании "Крок"

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

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

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