Управление портфелем проектов

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

Выделим все различия в табличной форме (на основании Стандарта по управлению программами, разработанному в 2006 г. составителем РМВоК, институтом PMI, и Руководства ICB IPMA, табл. 7.10).

Таблица 7.10

Проект, программа и портфель проектов

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

Рис. 7.15. Проекты как составные части программы проектов

Пример

Рассмотрим программу проектов, цель которой — «Организация обеспечения информационной поддержкой управления сетью распределенных мультифункциональных придорожных комплексов». При этом среди предоставляемых комплексом услуг: терминалы оплаты, вендинговые автоматы, кафе с wifi и, разумеется, сама заправка (газом, нефтепродуктами, стеклоомывающей жидкостью и т. д.). Соответственно, среди систем автоматизации будут, как минимум:

• • система управления автозаправочным комплексом;
• • система управления гостиничным комплексом;
• • система управления розничной торговлей в региональной сети АЗК;
• • мультисервисная корпоративная сеть;
• • ИТ-инфраструктура в центральном офисе;
• • системы безопасности и охраны:
• — система видеонаблюдения внутренней территории комплекса,
• — автоматическая паркинг-система,
• — система регистрации автомобильных номеров (въезды и выезды на территории комплекса),
• — система видеонаблюдения касс,
• — другие системы.

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

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

Для успешного прохождения всего жизненного цикла ИС крайне важен учет тесной взаимосвязи его этапов как отдельных проектов. К тому же неизбежно и их взаимодействие с прочими реализующимися компанией проектами, возможно, в рамках борьбы за совместно используемые ресурсы. Соответственно, удобнее и целесообразнее рассматривать ЖЦИС до этапа эксплуатации как единую программу проектов, планирование которой, как правило, осуществляется «сверху вниз» в силу необходимости распределения временных, денежных и прочих ресурсов. Критическим фактором успеха является логическая связь этапов/проектов (определяемая выбранной моделью жизненного цикла). На рис. 7.16 приведен пример для каскадной модели.

Рис. 7.16. Пример для каскадной модели

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

Допустим, компания (головной офис которой находится в одной из европейских стран) во всех российских подразделениях использовала Microsoft Dynamics Nav версии 3.01. При анализе и сборе требований, предшествовавших модернизации, было определено, что с ростом масштабов бизнеса, числа операций, количества пользователей возникла необходимость расширения функциональных возможностей системы и поддержки вдвое увеличившегося числа одновременно работающих в системе сотрудников.

В результате было принято решение модернизировать И С для обеспечения полноценного учета финансовой деятельности (по двум стандартам: РСБУ и US GAAP), получения информации из систем других филиалов компании (для чего понадобится разработка интеграционного решения и интерфейсов), увеличения скорости обработки данных.

11ри подготовке технического задания на модернизацию был проведен анализ всех финансовых операций, сформирована схема работы сотрудников в системе (с проверкой вводимых данных, оптимизацией многих процедур), а также выбрана программная платформа для модернизации (Microsoft Dynamics Nav, только уже версии 4.0).

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

А значит, действительно, этап модернизации (как и остальные стадии, за исключением эксплуатации) имеет признаки проектной деятельности, и каждым из этапов можно управлять через определение конечного результата проекта, а также временных и стоимостных ограничений.