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

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

В [1, 2] мы рассмотрели два процесса, обеспечивающие взаимодействие бизнеса и информационной службы в ходе реализации ИТ-проектов: процесс контроля проектов и процесс управления портфелем. Наряду с этим с ИТ-проектами связаны четыре процесса модели ITIL/ITSM: процесс управления изменениями, процесс управления релизами, процесс управления конфигурациями и процесс управления уровнем сервиса. Возникают вопросы:

  • как эти процессы взаимодействуют между собой?
  • какие организационные структуры в них задействованы?
  • как распределяются роли этих организационных структур?

Взаимодействие процессов

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

Стадия запуска

На этой стадии проектная инициатива отвергается или становится проектом. Основной механизм решения этой задачи – процесс контроля проектов. В его рамках выполняется следующее:

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

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

По результатам стадии запуска (1) заказчик принимает решение запустить проектную инициативу в качестве проекта, либо приостановить инициативу, либо отменить ее. В первом случае заказчик направляет на Service Desk информационной службы запрос на изменение, который в дальнейшем обрабатывается менеджером изменений. Во втором случае проектная инициатива приостанавливается, например, до решения вопроса о финансировании. В третьем – проектная инициатива закрывается.

Стадия выбора

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

Прежде всего, в рамках процесса управления изменениями собирается информация, необходимая для принятия решения (3):

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

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

Стадия проектирования

На стадии проектирования создается модель бизнес-процесса «как должно быть», реализующего проектную инициативу (5). Важной составной частью бизнес-процесса «как должно быть» становятся вновь создаваемые ИТ-услуги. Эти новые услуги должны быть согласованы с менеджером уровня сервиса в рамках обсуждения концептуального проекта внедряемой информационной системы (6). Принятие решений по концептуальному проекту и по итогам стадии в целом осуществляется в процессе контроля проектов [1].

Стадия выполнения

С точки зрения управления проектами (в отличие от рассматриваемого нами контроля проектов) это не одна стадия, а две – разработка решения и его развертывание.

Разработка решения включает в себя настройки и программирование внедряемой системы, создание массива нормативно-справочной информации (далее – НСИ), наконец, интегральный тест системы, оценивающий всю вновь созданную функциональность в совокупности (7). В итоге разработки решения должны быть получены:

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

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

Собственно мероприятия по развертыванию системы координируются в рамках процесса управления релизами (10). Подготовку среды промышленной эксплуатации и тестирование последней выполняет проектная команда. Готовность к принятию новой информационной системы в промышленную эксплуатацию определяется в рамках процесса контроля проектов (9). Информация о готовности инфраструктуры ИТ передается из процесса управления изменениями (11).

Стадия эксплуатации

На этой стадии решаются две задачи: оценка реализации проекта и планирование дальнейшей реализации выгод.

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

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

Процесс в целом

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

Расширение портфеля проектов

Процесс контроля проектов обеспечивает простое и естественное закрытие проектов, не оправдавших ожиданий заказчика. При отлаженном процессе своевременное закрытие проекта – заслуга, а не вина проектного менеджера и бизнес-заказчика. Другая особенность процесса – возможность остановки проекта без его закрытия, что позволяет вернуться к нему при получении дополнительной информации и/или необходимых ресурсов. Таким образом, при данном подходе можно запустить значительно больше проектных инициатив, чем при традиционном. Часть этих инициатив будет закрыта, часть – реализована, а часть – приостановлена (проекты, для реализации которых не хватает информации и/или ресурсов). Диаграмма состояний проекта приведена на рис. 2.

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

Другой вариант перераспределения ресурсов – изменение относительных приоритетов проектов. При снижении относительного приоритета проект приостанавливается или закрывается, а при повышении – запускается в действие.

Например, банк планирует разработку новой версии программы депозитария. Однако в 2004 году выходит закон «О кредитных историях», который предписывает банку предоставлять информацию о своих клиентах хотя бы в одно кредитное бюро [3]. В результате банк создает дочернее кредитное бюро, для которого необходима система учета кредитных историй. Принимая во внимание, что с 1 сентября 2005 года такое предоставление данных становится обязательным, банк приостанавливает проект новой версии депозитария, направляя ресурсы на внедрение ПО кредитного бюро.

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

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

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

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

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

Учет взаимосвязей проектов

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

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

Во-вторых, взаимосвязь проектов по результату может привести к единому решению для целой группы бизнес-проектов. Например, автор участвовал в анализе группы взаимосвязанных проектов: доступа к расчетным листкам по расчету заработной платы, обеспечения командировок, ведения персональных данных в корпоративном портале и т. д. Для этих проектов, первоначально независимых, было найдено общее техническое решение – система SAP ESS (Employee Self Service). Поскольку в организации уже эксплуатировалась система SAP R/3, данное решение оказалось оптимальным для всей совокупности проектов.

В-третьих, при остановке или закрытии проекта необходимо учитывать стратегические взаимосвязи и вытекающие из них стратегические последствия. Например, при внедрении системы SAP R/3 возможна такая последовательность проектов: автоматизация финансового менеджмента (казначейство), автоматизация учета закупок, автоматизация бухгалтерии. В этом случае, принимая решение, скажем, по остановке проекта казначейства, мы должны учитывать перспективные проекты учета закупок и бухгалтерского учета, которые также откладываются при данном решении.

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

Адаптация ИТ-бюджета к финансовым решениям

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

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

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

Влияние на выгоды бизнеса организации

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

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

Распределение требуемого сокращения в соответствии с приоритетами проектов

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

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

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

Учет взаимосвязей проектов

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

Литература

1. Скрипкин К.Г. Экономический анализ в процессе контроля проектов//Директор ИС, 2005, б№8.

2. Скрипкин К.Г. Управление портфелем ИТ проектов//Директор ИС, 2005, б№9.

3. Ступин И. Бюро не вышли на старт//Эксперт, 2005, б№33.

Кирилл Скрипкин – директор департамента ИТ-планирования и взаимодействия с бизнесом компании «СУАЛ», k.skripkin@sual.com