Зарубежные реалии управления проектами

Ряд международных исследований, проведенных в 2005-2012 годах компаниями IBM, MetaGroup, McKinsey, показывает, что около 50% проектов по ИТ являются неэффективными, что означает нерациональное использование примерно 20% ИТ-бюджетов.

Вот результаты исследований:

• Около 40% бюджетов ИТ расходуется на проекты;
• Более 35% проектов по ИТ приносят незначительные выгоды компании;
• От 15% до 20% от всех ИТ-проектов типичной компании могут быть остановлены, поскольку они почти не способствуют ее успеху;
• 25% проектов по ИТ слишком велики и могут быть уменьшены;
• 70% всех проектов по ИТ не дали ожидаемых результатов (оценка Gartner).

В исследованиях были выделены причины неэффективного управления проектами:

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

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

Типовые российские подходы к планированию проектов по ИТ

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

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

Первая попытка: все и сразу

Вот такой план появился в голове генерального директора где-то на новый год:

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

слушать сотрудников ИТ не стоит, а то опять какими-то внутренними работами займутся, вроде все бегают, а выгод для бизнеса нет, одни затраты. А если затраты на ИТ сократить на 10%, то можно наконец-то новую машину купить;

CRM позволит продавать хотя бы на 20-30 процентов больше, а заодно и всех продавцов контролировать (об этом подробно рассказал разработчик CRM). А то продавцы расслабились, а времена непростые.

С учетом вот таких задумок генеральный директор объявил следующий план проектов по ИТ — что-то вроде «блицкрига экспромтом» (см. рисунок):

рис. 1 Пример плана проектов по ИТ: вариант 1, план

Однако на деле попытка гендиректора получить от ИТ все и сразу не удалась, блицкриг провалился. Внедрение CRM и расширение ERP все-таки удалось реализовать, хотя и раза в четыре медленнее, и в два раза дороже (см. рисунок 2):

  рис. 2 Пример плана проектов по ИТ: вариант 1, факт

Далее во врезке перечислены только основные ошибки, да и то, скорее, только первые десять из них, совершенные при планировании этих работ. Видно, что отсутствие планирования серьезных проектов приведет к увеличению времени и ресурсов в два-три раза, а то и более.

Далее рассмотрено еще несколько вариантов планов, разработанных с учетом опыта, полученного при выполнении рассмотренного выше варианта 1.

Вторая попытка: немного попланировали связи между проектами и имеющиеся ресурсы

В варианте 2 предполагается, что опыт выполнения варианта 1 не прошел даром. Допустим, предыдущая попытка планирования (точнее его отсутствия) проектов по ИТ была проведена в соседней компании, и ее неутешительные результаты известны и бизнес-руководству и ИТ-менеджерам вашей компании. Хотя в реальности, чужой неудачный опыт никого не учит, да и свой учит не всегда.

Генеральному директору большие затраты на свой ЦОД не понравились, но проблемы с явным недостатком вычислительных мощностей в варианте 1 были свежи в памяти. Кроме того, генеральный директор считал, что свой ЦОД — это «круто». Опыта по созданию своего ЦОДа ни у кого не было, поэтому на этот проект запланировали 2,5 месяца, с учетом того, что помещение для ЦОДа уже было.

Планируемая последовательность второй попытки выполнения проектов по ИТ рассмотрена на рисунке 3, а пример того, что получилось на самом деле – на рисунке 4.

Рис.3. Пример плана проектов по ИТ: вариант 2, план

Рис 4. Пример плана проектов по ИТ: вариант 2, факт

Во врезке ниже перечислены основные ошибки, допущенные во время второй попытки планирования.

Третья попытка: спланировали получше, учли требуемые ресурсы

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

Планируемая последовательность третьей попытки выполнения проектов по ИТ рассмотрена на рисунке 5, а пример того, что получилось на самом деле – на рисунке 6.

Рис.5. Пример плана проектов по ИТ: вариант 3, план

Рис.6. Пример плана проектов по ИТ: вариант 3, факт

Четвертая попытка: учли связи между проектами, требуемые ресурсы, резервы времени

Четвертый вариант плана проектов был разработан с учетом первых трех неуспешных вариантов.

Планируемая последовательность четвертой попытки выполнения проектов по ИТ рассмотрена на рисунке 7, а пример того, что получилось на самом деле – на рисунке 8.

Рис.7. Пример плана проектов по ИТ: вариант 4, план

Рис.8. Пример плана проектов по ИТ: вариант 4, факт

Вариант Х: если бы вначале оценили приоритеты проектов

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

Даже если планировал проекты не руководитель ИТ-службы, а генеральный директор, вряд ли это будет существенным оправданием для руководителя ИТ-службы. Генеральный директор потом заявит, что ИТ-руководитель на то и поставлен, чтобы «руководить ИТ», и надо было квалифицированно объяснить, что надо было подправить в плане проектов.

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

Рис.9. Пример плана проектов по ИТ: вариант Х (если заранее оценить приоритеты проектов)

На рисунке 9 также учтены и взаимосвязи между проектами.

Сравнение примеров вариантов планирования

Вот сравнение рассмотренных вариантов планирования проектов (см. таблицу 1):

• в варианте 1 учли только ожидаемые выгоды от проектов;
• в варианте 2 учли также и зависимости между проектами;
• в варианте 3 учли также и затраты на проекты;
• в варианте 4 учли также и резервы времени на выполнение проектов;
• в варианте Х учли также и приоритеты проектов (как их определять, рассмотрено здесь).

Табл. 1 Сравнение рассмотренных примеров планирования проектов по ИТ

Обозначения: «√»: да; «~»: частично; «-»: нет.

Из сравнения вариантов планирования проектов (таблица) видно, что совсем небольшие затраты на планирование проектов (всего несколько дней) могут позволить в разы более точно планировать проекты. Если в варианте совсем без планирования (вариант 1) реальное время выполнения составило 13 месяцев (а мечтали о сроке в 2,5 месяца), то в вариантах 4 и Х реальное время сократилось до 9-9,5 месяцев и почти совпало с плановым.

Эффект от планирования в десятки раз может превосходит затраты.

Портфельное управление проектами

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

Отличия портфеля проектов от отдельных проектов:

для портфеля проектов указывается, что надо сделать, а не как конкретно. А для конкретного проекта — что и как конкретно надо сделать;

очень часто большие проекты можно рассматривать как отдельный портфель проектов, в который входит множество более мелких проектов.

Табл.1. Примеры отличий портфеля проектов от отдельных проектов

Портфельное управление проектами: основные этапы

Портфельное управление проектами состоит из трех этапов: планирование, управление и оценка (см. Рис. 1):

• Планирование: выбор проектов и разработка плана проектов;
• Управление: управление портфелем проектов;
• Оценка: периодическая оценка и корректировка плана проектов.

Рис.1. Этапы портфельного управления проектами

Все эти этапы выглядят просто, но организации, где все это выполняется, вряд ли превышают 1% от всех российских компаний. Хотя, по моим оценкам, и в странах ЕС только процентов десять от всех компаний используют портфельное управление проектами. Но, все равно это пока больше, чем в России.

Портфельное управление проектами: выбор проектов и разработка плана проектов

Большинство российских ИТ-менеджеров (точнее те, с кем я знаком) знают об управлении отдельными проектами, и, иногда даже используют это знание, например, рисуя этапы проекта в MS Project.

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

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

1. Определение целей портфельного управления, а также основные этапы (сроки) выполнения проектов;
2. Определение критериев выбора проектов. Примеры возможных критериев: соответствие целям бизнеса, финансовые показатели, риски и т.д.;
3. Оценка приоритетов проектов;
4. Выбор проектов и разработка плана проектов.

1. Определение целей портфельного управления

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

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

при объединении двух крупнейших российских бирж (ММВБ и РТС) точная дата начала объединения информационных систем заранее задана не была. Представители бизнеса до самого последнего момента тянули с объявлением этого срока Однако требование завершить интеграцию информационных систем в очень сжатые сроки было выставлено с самого начала;

проекты, связанные с Олимпиадой-2014 в Сочи, явно имели жесткий срок завершения – непосредственно к самой Олимпиаде. А вот сроки выполнения конкретных проектов иногда можно было менять, а от некоторых проектов вовсе отказаться, например, были выведены из плана работ к Олимпиаде, проекты по улучшению портов на побережье Черного моря (собственно, они не были обязательны именно для проведения Олимпиады).

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

2. Определение критериев выбора проектов

На Рис. 2 приведен типовой для портфельного управления проектами пример сравнения проектов в соответствии с выбранными критериями:

Рис.2. Пример оценки проектов по методике портфельного управления проектами

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

Рассмотрим группы критериев выбора проектов:

«Внешние условия (must-projects)»

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

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

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

«Бизнес взгляд»

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

Однако, расчет ROI только по одному проекту может занять пару недель.

«Проектный взгляд»

Здесь должны быть рассмотрены критерии, позволяющие оценить, насколько потенциальные проекты хороши как проекты (то есть для них нужны небольшие ресурсы и т.д.).

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

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

3. Оценка приоритетов проектов

Для оценки и визуализации приоритетов проектов, в портфельном управлении проектами используется следующая стратегическая диаграмма сравнения проектов: «Бизнес взгляд * Проектный взгляд» (см. Рис. 3).

Из всех областей диаграммы сравнения проектов хорошие проекты находятся только в правой верхней области, то есть это проекты, хорошие для бизнеса (высокая оценка по шкале «Бизнес взгляд») и сами хороши как проекты (высокая оценка по шкале «Проектный взгляд»). Проекты из всех остальных областей целесообразно или вообще не выполнить, или же существенно улучшить до выполнения:

Рис.3. Диаграмма сравнения проектов, рекомендуемая в портфельном управлении проектами

4. Выбор проектов и разработка плана проектов

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

Рис.4. Сравнение и выбор проектов

Пример выбора проектов по ИТ в соответствии с портфельным управлением проектами рассмотрен на Рис. 5:

Рис. 5. Пример выбора проектов по ИТ

Стоит отметить, что эта диаграмма отличается от очень похожей на Рис. 2 тем, что проект по CRM на Рис. 5 показан существенно ниже по шкале «Бизнес взгляд», так как на этом рисунке нет оценки «Must projects», которая есть на Рис. 2.

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

Портфельное управление проектами: управление портфелем

Этап «Управление» включает в себя управление выполнением проектов по ИТ:

• Регулярный контроль выполнения проектов;
• Регулярные корректировки выполнения отдельных проектов.

На этом этапе предполагается выполнение проектов, включенных в портфель проектов. На уровне конкретных проектов надо использовать методы управления проектами, например, отслеживая на MS Project ход выполнения каждого из них.

На этом этапе предполагаются корректировки отдельных проектов, но не добавление новых проектов и прекращение совсем неуспешных проектов.

Портфельное управление проектами: периодическая оценка и корректировка портфеля проектов

Этап «Оценка» включает в себя:

• Сравнение результатов выполнения портфеля проектов с поставленными целями;
• Определение требуемых корректировок портфеля проектов.

На этапе периодической оценки и корректировки портфеля проектов предполагается определить, успешно ли идет выполнение портфеля проектов в целом. Пример направлений сбалансированной системы показателей оценки эффективности выполнения портфеля проектов приведен на Рис. 6:

Рис. 6. Возможные направления оценки эффективного выполнения портфеля проектов

По результатам оценки, ряд проектов можно будет просто прекратить, а некоторые проекты существенно скорректировать. Также возможно добавление новых проектов. Оценки и корректировки портфеля проектов также обязательно планировать заранее, и проводить их раз в 3-6 месяцев, как впрочем и при возникновении существенных изменений, например, кризисов.

Этапы работы с проектами по ИТ

Далее рассмотрено, как быстро и достаточно точно провести сравнение проектов. Я разработал эту методику только после десяти лет попыток выбора проектов при разработке ИТ-стратегий.

На этапе планирования надо провести сравнение (приоритизацию) проектов по ИТ. Для отобранных проектов надо разработать примерный план их выполнения, а также описание каждого из проектов (см. Рис. 1):

Рис. 1. Выбор проектов при разработке ИТ-стратегии

Далее рассмотрены основные этапы выбора проектов при разработке ИТ-стратегии:

• Сбор информации по ИТ-проектам и источники этой информации;
• Сравнение и выбор проектов;
• План проектов, ИТ-бюджет, описание проектов по ИТ.

Этап 1 работы с проектами при разработке стратегии: Сбор информации по ИТ-проектам

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

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

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

Работа с проектами проводится на каждом из этапов проекта по разработке ИТ-стратегии (см. Табл. 1):

Табл. 1. Группы проектов по ИТ

Этап 2 работы с проектами при разработке стратегии: Сравнение и выбор проектов

Основные характеристики проектов

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

Я бы выделил три самые важные характеристики каждого из потенциальных проектов по ИТ:

1. Выгоды для бизнеса (хотя и выгоды для ИТ тоже стоит учитывать).

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

2. Ресурсы, требуемые для выполнения проекта (внешние выплаты и время своего персонала). Ресурсы по проектам может оценить ИТ-директор;

3. Риски невыполнения проекта (риски того, что уже начатый проект не будет завершен в планируемые сроки, с планируемым бюджетом и качеством).

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

В принципе, критериев для сравнения проектов, конечно, больше. Например, я использую еще плановость и срочность проектов.

Возможные дополнительные характеристики проектов

4. Финансовые показатели проектов (ROI, ТЭО, NPU и др.);
5. Срочность проектов. Действительно срочные проекты вы или будете выполнять, невзирая на их плохие показатели, или совсем отмените. На мой взгляд, выигрыш от стратегий и планирования в существенной мере заключается в уменьшении неожиданных и срочных проектов, очень часто крайне дорогих и неэффективных;
6. Плановость проектов. Если один из нескольких альтернативных проектов вы уже и рассматривали и планировали его выполнение, то это небольшой, но плюс в сравнении с проектами, которые ранее не планировали;
7. Риски отказа от выполнения проекта. Для ряда проектов велики именно такие риски. Например, вовремя не написать несложный, но трудоемкий отчет для налоговой службы или совета директоров. К таким же рискам можно отнести и упущенную прибыль (выгоды), которые не удастся получить, если проект не будет выполнен;
8. И т.д. и т.п., в том числе и детальное рассмотрение и основных характеристик проектов:

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

Пример сравнения и выбора проектов: основные исходные данные по проектам

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

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

В Табл. 2 рассмотрен пример потенциальных проектов, а также кому и зачем они нужны:

Табл. 2. Пример сравнения проектов по ИТ: кому и зачем нужны проекты

Далее рассмотрены примеры сравнения проектов из Табл. 2.

Сравнение выгод и затрат по проектам

На основании сведенных в Табл. 2 данных, ИТ-директор собрал подробную информацию по оценке возможных выгод от проектов (Табл. 3) и по затратам на проекты (Табл. 4).

В Табл. 3 сведены оценки выгод по рассматриваемым в качестве примера проектов, как они видятся для бизнеса и для ИТ:

Табл. 3. Пример сравнения проектов по ИТ: оценки выгоды

Обозначения: «L»: низкие; «M»: средние; «H»: высокие

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

Судя по Табл. 3:

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

Оценки затрат по рассматриваемым в качестве примера проектам см. в Табл. 4:

Табл. 4. Пример сравнения проектов по ИТ: оценки затрат

Обозначения: «L»: низкие; «M»: средние; «H»: высокие

Приведенные в Таб. 3 и Табл. 4 примеры оценок проектов рассмотрены далее на диаграммах.

Вот диаграмма сравнения выгод и затрат по проектам (см. Рис. 2):

​

Рис. 2. Пример сравнения проектов по соотношению выгод и затрат

Вот комментарии по сравнению ожидаемых выгод от проектов и затрат на них:

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

Требуемые для внедрения CRM ресурсы весьма высоки и вряд ли стоит их существенно уменьшать, тут уж или внедрять, или вообще не делать этого;

• ERP: выгоды для бизнеса есть, хотя и меньше, чем от CRM. А ресурсов может потребоваться много, так как предполагается и интеграция с АСУТП (но ее можно и отложить);
• свой ЦОД: выгоды не так велики (это скорее только сотрудникам ИТ интересно), а вот ресурсы нужны очень большие, даже больше, чем на внедрение CRM;
• аренда ЦОД: выгоды средние, как и от своего ЦОДа. А вот затраты невелики, особенно в сравнении со строительством своего ЦОДа;
• ИТ-стратегия: выгоды выглядят как достаточно высокие (10-15% повышения эффективности ИТ), а затраты сравнительно невелики;
• SLA: выгоды достаточно высокие, а затраты совсем низкие (в сравнении с другими проектами).

Сравнение рисков проектов

В Табл. 5 сведены оценки рисков по рассматриваемым в качестве примера проектам:

Табл. 5. Пример сравнения проектов по ИТ: оценки рисков

Обозначения: «L»: низкие; «M»: средние; «H»: высокие

На Рис. 3 рассмотрен пример диаграмма сравнения рисков проектов:

Рис.3. Пример сравнения рисков проектов

Вот комментарии по оценкам рисков проектов по ИТ:

• CRM: если не начать этот проект в ближайшие полгода, то для ИТ в целом ничего не случится. Однако, генеральный директор будет в шоке от прямого невыполнения его указания, и, скорее всего, уволит руководителя ИТ-службы;
• ERP: возможно как уменьшение масштаба проекта, так и его отодвигание где-то на 2-4 месяца;
• свой ЦОД: для сотрудников ИТ отказ от своего ЦОДа будет досаден, но не смертелен. А со стороны бизнеса потребуется увеличение вычислительных мощностей (под CRM и ERP), а также более надежная работа инженерного оборудования имеющихся серверных. Всего этого, и гораздо дешевле, можно достичь в рамках проекта по аренде «кусочка» чужого ЦОДа. А риски не завершить вовремя и не вписаться в бюджет проекта по созданию своего ЦОДа весьма высоки, особенно, если вы делаете это в первый раз;
• аренда ЦОД: риски не выполнить данный проект в срок и в рамках бюджета скорее невелики, т.к. большинство работ являются типовыми и выполняются другими организациями, которые только этим, вроде бы, и занимаются. Однако, неувеличение серверных мощностей к моменту ввода CRM в промышленную эксплуатацию закончится большими проблемами;
• ИТ-стратегия: бизнесу не особенно нужна, однако для ИТ это чуть ли не единственная реальная возможность как разработать реальный план проектов по ИТ на несколько лет вперед, так и согласовать его с бизнес-руководством.

Риски незавершения разработки ИТ-стратегии в срок – средние или даже высокие, большинство российских компаний таких работ не делали;

• SLA: риски не выполнить проект в срок скорее невысоки (это в сравнении с внедрением CRM, хотя почти все ИТ и бизнес-проекты в плановые сроки в России не завершаются). Если SLA и Каталог ИТ сервисов не разработать, то от CRM и ERP пользователи будут ожидать совсем уж нереального, в т.ч. доступа к CRM в любое время дня и ночи, а также с любого телефона любого из продавцов. Ну и автоматических продаж, если все другие требования удастся реализовать.

Выбор проектов при разработке стратегий: «светофор Михайлова»

Итоговое сравнение выгод, затрат, рисков проектов

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

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

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

На Рис. 1 приведена разработанная мной диаграмма для сравнения между собой потенциальных проектов (кстати, диаграмма работает как для проектов по ИТ, так и по любым другим областям):

Рис. 1. Стратегическая диаграмма сравнения проектов

Более подробная информация по квадратам на Рис. 1, приведена в Табл. 1:

Табл. 1. Шкала оценки приоритетов проектов

Еще раз уточним, что на Рис. 1 и в Табл. 1 предложены рекомендации без учета связей проектов между собой, а также дополнительных факторов типа «требования начальства», «срочность», «плановость» и др. Эти факторы надо учитывать индивидуально для каждого проекта.

Вот комментарии по сравнению выгод, затрат, рисков проектов:

• ERP: снижены и затраты, и риски за счет отказа от интеграции с АСУПТ;
• CRM: снижены риски за счет разработки подробного ТЗ, снижения требований к CRM, взятия в штат ИТ-службы специалиста по CRM;
• ЦОД: отказаться от этого проекта, заменив на проект «Аренда ЦОД».

Рассмотренные рекомендации изображены на Рис. 2, как стрелочки по изменению характеристик проектов по ERP, CRM, ЦОД:

Рис.2. Пример сравнения проектов по ИТ (вид стратегической диаграммы): желательные корректировки проектов

Объединение стратегических рекомендаций и практического опыта сравнения и выбора проектов: «Светофор Михайлова»

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

Обозначения: размер кружков пропорционален затратам на проекты.

Рис. 3. Пример сравнения проектов по ИТ: «светофор Михайлова»

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

Желтым обозначены проекты со средней привлекательностью. Затраты на эти проекты примерно равны выгодам.

Зеленым обозначены проекты с высокой привлекательностью. У них хорошее соотношение выгод к ресурсам: выгоды больше, чем ресурсы. И низкие риски.

Табл.2. Шкала оценки привлекательности проектов (по «светофору Михайлова»)

Исходя из приведенного примера сравнения проектов по ИТ на диаграмме (Рис. 3) можно предложить возможные рекомендации по улучшению этих проектов, которые сведены в Табл. 3:

Табл. 3. Пример сравнения проектов: результаты сравнения и возможные рекомендации

Если проектов больше чем 10-15 и они не помещаются на диаграмму, то ИТ-руководители, которые проходят у меня обучение, используют также калькулятор на Excel. Вот оценки привлекательности проектов, сделанные в калькуляторе, собственно приоритеты проектов те же, что и при сравнении проектов в диаграмме на Рис. 3 (Табл. 4):

Табл.4. Пример оценки привлекательности проектов

Используемые в этом калькуляторе формулы здесь не приведены, с одной стороны – они сложные (в том числе вложенные друг в друга функции VLOOKUP), а с другой стороны – проводится поиск по уже имеющимся эмпирическим данным, которые визуализированы на Рис. 3.

Разработка плана проектов и проектов по ИТ
Этап 3 работы с проектами при разработке стратегии: разработка плана проектов и проектов по ИТ

Разработка плана проектов

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

Табл.1. Пример сравнения проектов по ИТ: основные параметры проектов

А вот план проектов, разработанный с учетом как привлекательности (или приоритетов проектов, они выделены цветом) проектов, так резервов времени (они выделены пунктиром), см. Рис. 1:

Рис. 1. Пример плана проектов с учетом их привлекательности и резервами времени

Надо отметить, что предлагаемая методика сравнения дает не точное решение по одному конкретному проекту, а рекомендации по выбору наиболее быстрых в отдаче проектов (по-английски «quick wins»), то есть приоритеты проектов без учетов связей с другими проектами. Кроме приоритетов отдельных проектов, надо дополнительно учитывать связи между ними, а также проекты, которые обязательно должны быть выполнены (например, требования государства или акционеров).

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

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

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

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

Готовность вашей ИТ-службы и других сотрудников выполнить эти проекты (например, у вас может не быть нужных специалистов);

• совместимость с другими проектами и т.д.

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

Можно снизить риски невыполнения проекта, увеличив время, требуемое на выполнение проекта. Например, можно внедрять не все модули ERP сразу, а поочередно, а также не во всех филиалах, а по частям.

Мой опыт показывает, что увеличить выгоды от проекта на 20-30% или сократить затраты на него, как правило, совершенно реально. Хотя придется потратить на это некоторое время.

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

Разработка проектов по ИТ

Совсем по минимуму, даже в простой ИТ-стратегии, для каждого проекта по ИТ надо «написать и согласовать с заинтересованными лицами» основные характеристики проекта:

1. Цели проекта;

2. Основные этапы выполнения проекта;

3. Оценки проекта:

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

4. Зависимости от других проектов;

5. Сроки выполнения проекта;

6. Ответственные за данный проект.

Пример описания конкретного проекта по внедрению документооборота приведен на Рис. 2:

Рис.2. Пример описания проекта по ИТ

Сколько проектов стоит планировать?

Какими бы большими (или маленькими) ни были проекты, вряд ли целесообразно рассматривать портфель из более чем 50 проектов, по максимуму, до 70-100.

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

Однако, в силу ограниченности людей, вряд ли стоит планировать портфель на 150 проектов. Более целесообразным выглядит объединение проектов в группы так, чтобы все группы помещались на одном слайде или странице текста.

Вот мои оценки типового числа проектов по ИТ, рассматриваемых при разработке ИТ-стратегии средней или крупно-средней по размеру компании (от 1 до 20 тысячи пользователей ИТ):

• 20-50 уже выполняемых проектов;
• 30-70 проектов по «затыканию дыр» в текущем состоянии ИТ (с учетом различных вариантов проектов);
• 30-70 проектов по переходу в требуемое состояние ИТ (с учетом вариантов).

Итого получилось 80-200 возможных проектов.

На этапе выбора проектов целесообразно:

1. Выявить необязательные проекты с низкими выгодами, высокими затратами и/или высокими рисками. Эти проекты можно не учитывать в дальнейшем выборе проектов на год вперед. Так стоит отсеять минимум треть проектов;
2. Еще треть проектов со средненькими характеристиками и низкими затратами можно попробовать учесть в проектах с высокими выгодами;
3. Далее стоит оставить 15-40 проектов, пытаясь увязать их с этапами развития ИТ в вашей компании.

Бюджет ИТ

Что рассматривается в ИТ-стратегии

Бюджет ИТ обычно является наиболее дискутируемой частью ИТ-стратегии. Мой опыт работы с сотней генеральных директоров говорит, что руководители компании могут тратить на ИТ существенно больше (как на 10%, так и на 100%), однако, сотрудники ИТ не могут предложить понятных и выгодных для бизнеса проектов.

То есть абсолютные затраты на ИТ обычно высоки, экономия их на 5-10% может составлять стоимость хорошей легковой машины (для средней по размеру компании и за один год. Для крупных компаний – за месяц, или даже неделю). Однако, все затраты на ИТ обычно не превышают 1-2% от оборота компании, поэтому для генерального директора есть и множество других направлений сокращения затрат.

В ИТ-стратегии желательно рассмотреть несколько бюджетов ИТ:

• Бюджет ИТ на год;
• Бюджет ИТ на 2-5 лет вперед;
• Бюджет отдельных проектов.

Бюджет ИТ на год

Бюджет на год вперед, по-хорошему, и должен представлять собой реальный план всех расходов на ИТ на год. Многие компании разрабатывают ИТ-стратегии, чтобы обосновать бюджет ИТ. В большинстве организаций обсуждение бюджетов на следующий год заканчивается не 31 декабря, а осенью, а то и в августе. Соответственно, и разработку ИТ-стратегии целесообразно планировать за 4, а лучше за 6 месяцев до крайнего срока согласования бюджетов.

В бюджете на год целесообразно рассмотреть расходы по ИТ на каждый месяц.

Бюджет ИТ на 2-5 лет вперед

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

Бюджет отдельных проектов по ИТ

Такие бюджеты можно рассматривать для нескольких самых крупных проектов по ИТ, особенно если эти проекты занимают более одного года. Примерами таких проектов могут быть внедрения CRM или ERP для крупных предприятий со множеством филиалов и партнеров. Также обязательно стоит разрабатывать бюджеты самых дорогих проектов, например, создания своего ЦОДа.

Бюджет ИТ на год

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

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

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

Рис. 1 План проектов на год и требуемые ресурсы: первая прикидка

Видно, что имеющиеся ресурсы или недоиспользуются, или же их недостаточно (например, загрузка своего персонала в месяцы 4 и 5 превышает потенциально имеющиеся 100%). Работа по планированию проектов с учетом имеющихся ресурсов не является простой и требует скорее опыта, чем использования какого-то программного обеспечения.

Из программ, в которых я бы рекомендовал проводить планирование ИТ-бюджета, можно отметить:

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

На Рис. 2 представлен пример плана проектов, лучше оптимизированный под имеющиеся ресурсы:

Рис. 2 План проектов на год и требуемые ресурсы: вторая прикидка

Видно, что проведенной на Рис. 2 оптимизации внешних выплат и загрузки своего персонала недостаточно, но этот вариант лучше первой прикидки на Рис. 1.

Бюджет ИТ на 2-5 лет

В ИТ-бюджете на несколько лет вперед надо запланировать, сколько денег в ближайшие годы планируется потратить на:

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

Пример итогового слайда по ИТ-бюджету на несколько лет вперед приведен на Рис. 3:

Рис. 3 Пример бюджета ИТ на несколько лет вперед

При планировании ИТ-бюджета на Рис. 3 предполагалось, что затраты на ИТ будут расти примерно вполовину от роста бизнеса. То есть, если бизнес за год планирует вырасти на 10%, то расходы на ИТ целесообразно планировать на 5% больше, чем в прошлом году.

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

Бюджет отдельных проектов по ИТ

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

Конечно, желательно по каждому из рассматриваемых проектов по ИТ иметь как Техническое задание страничек на 20-30, так и подробный бюджет. Но если проектов по ИТ не один, не два, а полсотни, а расчетов ROI, ТЭО или других финансовых обоснований проектов по ИТ в вашей компании никто пока почему-то не делал, стоит начать с постепенной оценки затрат и возможных выгод от наиболее крупных и/или важных проектов по ИТ.

Варианты развития ИТ: а вы их рассматриваете?

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

• существенные решения по инфраструктуре ИТ, например, строительство своего ЦОДа. Или, вместо ЦОДа, аренда места в чужом ЦОДе под свои сервера. Или вообще отказ от собственных серверов и ЦОДов (за счет аренды вычислительных мощностей у ИТ-компаний);
• существенные изменения в информационных системах, например, внедрение единой интегрированной информационной системы. Или переход от ERP собственной разработки к типовому решению;
• существенные изменения в управлении ИТ, например, передача сотрудников службы поддержки ИТ (вместе с самой поддержкой) на аутсорсинг;
• существенные изменения в бизнесе, например, объединение с крупным конкурентом или быстрый рост (или падение) числа своих филиалов. Или требование бизнеса по сокращению затрат на ИТ на 5%. Или на 10%. Или на 20%…;
• существенные изменения во внешней среде. Простой пример – кризис 2014 года, во время которого курс рубля упал в два раза по отношению к доллару (печаль в том, что цены почти на все технические средства, а также на многие программы, установлены в долларах).

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

Конечно, при сравнении вариантов развития ИТ для конкретной компании в конкретный момент времени надо учитывать разные критерии, но есть и типовые: соответствие бизнесу; соответствие ИТ; затраты (см. Табл. 1):

Табл.1. Сравнение вариантов развития ИТ

Возможная детализация критериев рассмотрена ниже.

Соответствие бизнесу можно поделить на:

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

Соответствие целям ИТ можно поделить на:

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

Затраты можно поделить на:

• начальные затраты на переход к каждому варианту;
• затраты на ежегодную поддержку каждого варианта.

Для каждого из вариантов развития ИТ надо определить, какая должна быть инфраструктура ИТ, справятся ли сотрудники, что нужно будет делать с информационными системами, сколько денег на это потребуется. Более того, могут быть и разные подварианты: например, оргструктуры — можно или выполнять работы силами своих сотрудников, или кому-то передать на аутсорсинг. То есть, получается дерево вариантов. При этом как в шахматах: чем больше вариантов просчитать, тем больше вероятность выбора оптимального в данном случае варианта. Хотя вряд ли серьезно рассмотреть более 2-5 вариантов развития ИТ.

При рассмотрении вариантов очень желательно иметь как опыт разработки вариантов развития ИТ, так и знать планы развития конкурентов вашей компании.

Портфель проектов по ИТ

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

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

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

Рис. 1 Пирамида групп проектов в портфеле проектов по ИТ

Рассмотрим основные группы проектов в возможном портфеле проектов по ИТ на несколько лет вперед. Предложенная классификация является точкой зрения автора этой книги.

Обязательные к выполнению проекты:

• требования государства;
• требования акционеров и гендиректора;
• обязательные для ИТ проекты.

Базовый портфель проектов (очень желательные проекты):

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

Расширенный портфель проектов (хорошо бы сделать, если будет хватать времени и денег): проекты с плохим (пока) соотношением выгод к затратам, а также проекты с высокими рисками.

Портфель потенциальных проектов (пока не актуальные проекты): проекты, не соответствующие пока текущим целям ИТ и бизнеса.

Рассмотренные выше предложения соответственно групп проектов конкретным критериям сведены в Табл. 1:

Табл.1. Группы проектов по ИТ в портфеле проектов

Этапы развития ИТ

На практике непросто составлять оптимальный план даже на несколько десятков проектов, а на пару сотен проектов – почти нереально. Имеется в виду, что сложно составить реально выполнимый и достаточно экономный с точки зрения ресурсов план, хотя просто связать между собой в заранее заданную последовательность несложно и несколько сотен проектов.

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

Планы проектов разрабатывают люди, потому надо учитывать, что человек способен одновременно удерживать внимание на не более чем 7 объектах. Даже если план проектов составляет гений, способный оперировать одновременно и 9 объектами, то план будет смотреть и множество других людей. Соответственно, получается, что оптимально спланировать можно до 7 проектов, хотя в плане проектов по ИТ почти любой компании, проектов – десятки, а то и сотни.

Один из вариантов решения этой дилеммы – разбить план проектов на отдельные блоки, в каждом из которых будет не более 7 проектов. И самих блоков – не более 7 (ну или матрица, например, 3*3). Эти предложения соответствуют рекомендациям, принятым в разных областях, в том числе в описании бизнес- и ИТ-процессов.

Можно вначале выделить 2-5 четких этапов развития ИТ (каждый длительностью в полгода-год), а потом привязать проекты к этим этапам (см. Табл. 1):

Табл.1. Привязка проектов к этапам развития ИТ