Автор: Александр Михайлов, эксперт по ИТ стратегиям и управлению ИТ, MBA, генеральный директор компании «Консалтинг по управлению ИТ», editor@info-strategy.ru
Материал статьи построен на базе лучшего международного опыта разработки ИТ-стратегий и практического опыта автора:
- 15 лет консалтинга по управлению ИТ (из них 7 лет в IBM);
- 10 лет работы руководителем ИТ службы в российских и зарубежных компаниях;
- 12 лет преподавания ИТ-стратегий в ведущих российских бизнес школах;
- разработка ИТ-стратегий десятков крупных российских предприятий, помощь в разработке более трех сотен ИТ-стратегий.
Текст написан на базе главы книги «ИТ-стратегия: лучшие международные и российские практики».
Оглавление:
Введение
- Зарубежные реалии управления проектами
- Типовые российские подходы к планированию проектов по ИТ
- Портфельное управление проектами
- Этапы работы с проектами по ИТ
- Выбор проектов при разработке стратегий: «светофор Михайлова»
- Разработка плана проектов и проектов по ИТ
- Бюджет ИТ
- Варианты развития ИТ: а вы их рассматриваете?
- Портфель проектов по ИТ
- Этапы развития ИТ
- Определение плана проектов по ИТ в рамках разработки ИТ-стратегии или стратегии цифровой трансформации бизнеса
- Типовые варианты выявления плана проектов ИТ на 1 год и более
Введение
Управлением проектами занимаются в большинстве ИТ-службы. В России есть тысячи «проджект-менеджеров», которые, казалось бы, только и должны управлять проектами. Есть и книги по управлению проектами (каждым из них по отдельности). Сейчас большинство ИТ-служб может управлять конкретными проектами, но не всеми ими сразу. Практически у всех предприятий, которые я видел, управление портфелем проектов можно существенно улучшить.
Пример 1: ИТ-стратегия в шкафчике
В одной крупной компании внешние консультанты разработали подробную ИТ-стратегию на несколько сотен страниц. Уже через несколько месяцев после ухода консультантов ИТ-директор понял, что своими силами обновлять эту стратегию нереально, хотя бизнес ждет от него именно этого.
После этого ИТ-директор взял план проектов на год (что занимало всего пару страниц текста), и начал править его в отрыве от двухсот страниц ИТ-стратегии, где обосновывался выбор проектов, каким приоритетам бизнеса они соответствуют, какие бизнес-процессы надо автоматизировать и т.д. и т.п.
Теперь ИТ-директор говорит, что его пара страниц с названиями проектов соответствуют ИТ-стратегии, которая стоит в шкафчике. Ключевой фактор успеха такого подхода — чтобы в этот шкафчик никто не заглядывал.
Пример 2: Государственные программы информатизации – это стратегии?
Я когда-то участвовал в разработке и выполнении государственных программ информатизации. Государственные программы, которые я видел тогда и потом, на ¾ содержали описание ряда задач, для каждой из которых указаны объемы и источники финансирования.
К сожалению, я пока ни разу не видел какого-либо существенного обоснования, почему именно эти задачи надо выполнить. Люди, которые разрабатывают и согласовывают государственные программы, как правило, являются чиновниками разных министерств. Квалификация этих чиновников может быть совсем невелика, а за государство в целом они не думают, им бы «свою задницу прикрыть».
Также в государственных программах пытаются участвовать как государственные, так и частные компании. Они делегируют на лоббирование своих интересов самых энергичных, умных и беспринципных сотрудников. Однако интересы компаний и их представителей, скорее всего, узкокорыстны. Про благо всех людей и России в целом они, возможно, и вспоминают, но скорее для того, чтобы под этот лозунг какие-нибудь свои услуги продать.
Общего и позитивного в рассмотренных во врезке ситуаций только огромный потенциал улучшения, минимум процентов 20 от всех расходов на проекты. Думаю, здесь могли бы помочь и методы стратегического планирования, и методики разработки планов проектов на несколько лет. Что собственно и рассматривается в этой главе.
В качестве источников информации по разработке плана проектов по ИТ на 1 год и более, а также бюджету ИТ можно предложить отнюдь не изучение методов управления проектами и MS Project, а другие подходы:
- Методики и книги по портфельному управлению проектами;
- Лучшие практики по ИТ-бюджетам (Gartner, Meta Group, Союз ИТ-директоров России).
1. Зарубежные реалии управления проектами
Ряд международных исследований, проведенных компаниями IBM, MetaGroup, McKinsey, показывает, что около 50% проектов по ИТ являются неэффективными, что означает нерациональное использование примерно 20% ИТ-бюджетов.
Вот результаты исследований:
- Около 40% бюджетов ИТ расходуется на проекты;
- Более 35% проектов по ИТ приносят незначительные выгоды компании;
- От 15% до 20% от всех ИТ-проектов типичной компании могут быть остановлены, поскольку они почти не способствуют ее успеху;
- 25% проектов по ИТ слишком велики и могут быть уменьшены;
- 70% всех проектов по ИТ не дали ожидаемых результатов (оценка Gartner).
В исследованиях были выделены причины неэффективного управления проектами:
- Большое количество проектов по ИТ, которое продолжает расти;
- Много проектов по ИТ утверждается без экономического обоснования;
- Слишком много активных проектов по ИТ, что приводит к дефициту ресурсов;
- Задержки с комплектованием проектной команды, сдерживающие выполнение проектов;
- Проекты по ИТ запускаются в момент заявки;
- Эскалация как инструмент расстановки приоритетов.
Пожалуй, управление ИТ-проектами недостаточно хорошо поставлено в большинстве стран мира. В России управление ИТ-проектами, особенно выбор проектов, пока хуже, чем в США и ЕС. Соответственно, улучшение управления проектами может повысить конкурентоспособность российских компаний. Надеюсь, усилия читателей этого сайта внесут позитивный вклад в процветание России.
2. Типовые российские подходы к планированию проектов по ИТ
Далее рассмотрено несколько типовых примеров планирования проектов по ИТ для российских компаний. Эти примеры я разработал после многолетних попыток обучить генеральных директоров тому, что же можно получить от ИТ, и как генеральному директору формировать требования бизнеса к ИТ и контролировать работу ИТ.
То есть приведенные ниже примеры — не мои придумки, а реальность российских предприятий. И есть опасение, что ситуация немного приукрашена.
Первая попытка: все и сразу
Вот такой план появился в голове генерального директора где-то на новый год:
надо с начала января загрузить сотрудников ИТ работой, чтобы хоть что-то полезное от них было. Для этого надо сразу начать два проекта, выгодных для бизнеса (а не для ИТ, как это было все последнее время): расширить функциональность уже работающей ERP и внедрить CRM (у конкурентов CRM уже есть);
слушать сотрудников ИТ не стоит, а то опять какими-то внутренними работами займутся, вроде все бегают, а выгод для бизнеса нет, одни затраты. А если затраты на ИТ сократить на 10%, то можно наконец-то новую машину купить;
CRM позволит продавать хотя бы на 20-30 процентов больше, а заодно и всех продавцов контролировать (об этом подробно рассказал разработчик CRM). А то продавцы расслабились, а времена непростые.
С учетом вот таких задумок генеральный директор объявил следующий план проектов по ИТ — что-то вроде «блицкрига экспромтом» (см. рисунок):
Рис. 1. Пример плана проектов по ИТ: вариант 1, план
Однако на деле попытка гендиректора получить от ИТ все и сразу не удалась, блицкриг провалился. Внедрение CRM и расширение ERP все-таки удалось реализовать, хотя и раза в четыре медленнее, и в два раза дороже (см. рисунок 2):
Рис. 2 Пример плана проектов по ИТ: вариант 1, факт
Далее во врезке перечислены только основные ошибки, да и то, скорее, только первые десять из них, совершенные при планировании этих работ. Видно, что отсутствие планирования серьезных проектов приведет к увеличению времени и ресурсов в два-три раза, а то и более.
Основные ошибки при планировании проектов
(номера соответствуют выделенным на Рис. 2 областям)
- Не сразу удалось приступить к выполнению запланированных проектов: была задумка начать прямо с начала января, однако, по факту, первый месяц ушел на новогодние праздники и восстановление после них;
- Выяснилось, что сил на одновременное выполнение проектов по расширению ERP и внедрению CRM не хватает. Ранее, при планировании проектов руководитель ИТ-службы предупреждал генерального директора, что на одновременное выполнение двух больших проектов сил не хватит. Однако генеральный настоял, сказав, что «как-нибудь справитесь или других ИТ-шников найдем, более успешных»;
- На запланированный проект по доработке ERP времени не хватило: вместо за-планированных полутора месяцев ушло вдвое больше. Однако и этого не хватило;
- Не удалось вместить на имеющиеся технические средства расширенную ERP и новую CRM: не хватило ни производительности серверов, ни надежности их работы. Периодически начали возникать ситуации, когда минут по десять ERP ни на что не реагировала (потом оказалось, что причиной этого были запросы пользователей, которые выполняли слишком много обращений к базе данных. Сами пользователи об этом не знали и, не дождавшись ответа, пытались сразу еще несколько раз запустить эти же запросы). Было принято решение приостановить доработки ERP;
- В плановые сроки (2,5 месяца) проект по внедрению CRM выполнить не удалось. Компания, которая выполняла внедрение CRM предупреждала, что за такое время нереально учесть имеющиеся бизнес-процессы. Однако, после начала проекта коммерческий директор неожиданно стал настаивать на автоматизации почти всех уже сложившихся процессов продаж. Соответственно, проект по внедрению CRM превысил плановые сроки раза в два;
- Проект по внедрению CRM пришлось приостановить, т.к. производительности имеющихся технических средств просто не хватило;
- На расширение ERP и внедрение CRM не хватило как мощностей серверов, так и надежности инженерного оборудования серверных: источников бесперебойного питания, а также кондиционирования. Соответственно, руководитель ИТ-службы решил, с учетом важности внедрений ERP и CRM для руководства компании, не только докупить пару серверов, но и перенести все серверы в стойки, арендованные в уже построенном коммерческом ЦОДе. Однако, так как заранее этот проект не планировали, все работы затянулись почти на два месяца. Почти все это время ушло на проведение выделенной линии связи в этот ЦОД. Ограничились одной линией связи, на резервную времени и сил не хватило;
- После увеличения мощности серверов, установленных в арендованном ЦОДе, внедрение CRM удалось продолжить. Однако, через месяц пользователи выставили требование по доступу ко всей информации через мобильные телефоны продавцов.
Разработчик подозревал, что подобные запросы могут возникнуть. Удалось ограничиться лишь повышением стоимости работ по внедрению.
Но еще одно требование об обеспечении работоспособности CRM в вечернее и ночное время имеющимися ресурсами выполнить не удалось. Это требовало увеличения в 2 раза персонала, поддерживающего как CRM, так и технические средства;
- Работы по внедрению CRM пришлось опять тормознуть, чтобы собрать и согласовать новые требования как к функциональности, так и времени поддержки CRM;
- Руководитель ИТ-службы решил запустить новый проект по разработке Каталога ИТ сервисов и требований к этим сервисам (SLA: Service Level Agreement). Эти работы потребовались для того, чтобы согласовать требования к поддержке как CRM, так и ERP, а также технических средств и связи. В результате работ была спроектирована централизованная круглосуточная служба поддержки ИТ, что потребовало как доработки ПО, так и увеличения численности персонала ИТ.
Далее рассмотрено еще несколько вариантов планов, разработанных с учетом опыта, полученного при выполнении рассмотренного выше варианта 1.
Вторая попытка: немного попланировали связи между проектами и имеющиеся ресурсы
В варианте 2 предполагается, что опыт выполнения варианта 1 не прошел даром. Допустим, предыдущая попытка планирования (точнее его отсутствия) проектов по ИТ была проведена в соседней компании, и ее неутешительные результаты известны и бизнес-руководству и ИТ-менеджерам вашей компании. Хотя в реальности, чужой неудачный опыт никого не учит, да и свой учит не всегда.
Вот что поменялось:
а) решили планировать проекты не с самого начала года, а ближе к концу января;
б) запланировали все проекты не на 3, а на 6 месяцев;
в) сразу запланировали проект по разработке SLA (включив туда и расчеты роста вычислительных мощностей);
г) руководителю ИТ-службы удалось уговорить гендиректора не арендовать стойки в чужом ЦОДе, а создать свой собственный ЦОД, соответствующий требованиям Tier З.
Генеральному директору большие затраты на свой ЦОД не понравились, но проблемы с явным недостатком вычислительных мощностей в варианте 1 были свежи в памяти. Кроме того, генеральный директор считал, что свой ЦОД — это «круто». Опыта по созданию своего ЦОДа ни у кого не было, поэтому на этот проект запланировали 2,5 месяца, с учетом того, что помещение для ЦОДа уже было.
Планируемая последовательность второй попытки выполнения проектов по ИТ рассмотрена на рисунке 3, а пример того, что получилось на самом деле – на рисунке 4.
Рис.3. Пример плана проектов по ИТ: вариант 2, план
Рис 4. Пример плана проектов по ИТ: вариант 2, факт
Во врезке ниже перечислены основные ошибки, допущенные во время второй попытки планирования.
Результаты второй попытки планирования:
- Расширение ERP не удалось завершить в запланированные сроки. Зато стало непонятно, будут ли новые подсистемы ERP нормально работать на уже имеющихся серверах;
- Так как началось плановое внедрение CRM, параллельную доработку ERP решили приостановить, не хватило ресурсов (сил своих сотрудников ИТ) на два проекта одновременно;
- Вовремя проект по разработке SLA начать не удалось: выполнять его собирались сами, а сотрудник, у которого был опыт разработки SLA, не вовремя уволился;
- В срок проект по созданию своего ЦОДа начать не удалось, так как помещение под ЦОД вовремя получить не удалось. А потом выяснилось, что входная дверь слишком мала для уже купленного инженерного оборудования. Неделя ушла только на решение вопроса с заносом оборудования;
- Вовремя внедрение CRM завершить не удалось: возникли как новые требования пользователей, так и у компании, которая внедряла CRM, часть сотрудников ушла в отпуск, а часть — на другие проекты;
- Проект по внедрению CRM пришлось приостановить, так как ЦОД не был готов, а мощностей имеющихся серверов не хватало;
- Так как опыта создания своего ЦОДа не было, это заняло раза в два больше за-планированного времени. На уровень требований Tier 3 тоже не удалось выйти: выяснилось, что подвести два независимых источника питания просто нереально.
Третья попытка: спланировали получше, учли требуемые ресурсы
Третий вариант плана проектов разрабатывали с учетом неуспешного опыта планирования вариантов 1 и 2. Соответственно, ошибки предыдущих вариантов постарались учесть, что однако не избавило от новых проблем.
Вот основные изменения:
а) Решили вначале разработать требования к поддержке CRM и ERP, запланировав их разработку в проекте по SLA, который поставили самым первым;
б) Свой ЦОД решили не делать, а ограничиться арендой нескольких стоек в ЦОДе знакомой ИТ-компании;
в) На все проекты запланировали 9 месяцев (а не 3 или 6, как было в вариантах 1 и 2).
Планируемая последовательность третьей попытки выполнения проектов по ИТ рассмотрена на рисунке 5, а пример того, что получилось на самом деле – на рисунке 6.
Рис. 5. Пример плана проектов по ИТ: вариант 3, план
Результаты третьей попытки планирования:
- Вовремя проект по расширению функциональности ERP завершить не удалось. Однако было выполнено более половины работ;
- Проект по ERP тормознули, так как надо было переносить сервера в арендованный ЦОД. С переносом тоже возникли проблемы из-за резкого падения курса рубля (владелец ЦОД предлагал контракт в долларах);
- После переноса серверов в ЦОД в течение месяца проект по ERP удалось завершить;
- Проект по CRM в плановые 2,5 месяца не уложился, потребовался еще месяц. Пожелания пользователей по доступу к CRM «в любое время и с любого устройства» решили отложить на будущее, может это уже и не нужно будет.
Рис. 6. Пример плана проектов по ИТ: вариант 3, факт
Четвертая попытка: учли связи между проектами, требуемые ресурсы, резервы времени
Четвертый вариант плана проектов был разработан с учетом первых трех неуспешных вариантов.
Вот основные изменения:
а) Почти для всех проектов добавлены резервы времени, из расчета 30% на каждый проект. На аренду ЦОД и перенос в него серверов решили выделить еще больше резервов времени, учитывая, что в этом проекте должно участвовать несколько внешних организаций (как владелец ЦОДа, так и компания, которая будет прокладывать выделенные линии связи к ЦОДу);
б) До выполнения всех проектов решили разработать ИТ-стратегию, в которой уточнить требования к ERP и CRM и приоритеты автоматизации всех бизнес-процессов компании. Также в ИТ-стратегии предполагалось доработать и сам план проектов.
Планируемая последовательность четвертой попытки выполнения проектов по ИТ рассмотрена на рисунке 7, а пример того, что получилось на самом деле – на рисунке 8.
Рис.7. Пример плана проектов по ИТ: вариант 4, план
Рис.7. Пример плана проектов по ИТ: вариант 4, факт
Результаты четвертой попытки планирования:
- На выполнение проекта по ERP времени ушло на 20% больше. Однако резерв времени был запланирован. А в разработанной до этого ИТ-стратегии удалось четко определить требуемые доработки ERP и согласовать их со всеми подразделениями;
- Разработку SLA начали на три недели позже. Однако часть SLA удалось разработать в ИТ-стратегии;
- Аренду ЦОДа решили выполнить раньше планового срока, так как предыдущие проекты уже были выполнены;
- Внедрение CRM завершилось на месяц позже. Но резервы под это были запланированы.
Вариант Х: если бы вначале оценили приоритеты проектов
Выше мы рассмотрели аж четыре итерации планирования проектов, предположив, что и проекты планируются одни и те же, и учитывается опыт предыдущих потуг с планированием. В реалиях современного бизнеса вряд ли можно рассчитывать, что три-четыре раза можно будет потренироваться. Уже после провала одного, ну или двух вариантов, отвечать за ИТ будет другой человек.
Даже если планировал проекты не руководитель ИТ-службы, а генеральный директор, вряд ли это будет существенным оправданием для руководителя ИТ-службы. Генеральный директор потом заявит, что ИТ-руководитель на то и поставлен, чтобы «руководить ИТ», и надо было квалифицированно объяснить, что надо было подправить в плане проектов.
В теме «Этапы работы с проектами по ИТ при разработке стратегий» рассмотрена методика определения приоритетов, которую я разработал для планирования проектов. В результате несложных действий можно для каждого из потенциальных проектов по ИТ оценить его приоритет. Для более легкого восприятия проекты, выглядящие хорошо, можно выделить зеленым цветом. Плохие проекты – красным цветом. Ну и средненькие проекты – желтым цветом. Пример оценки приоритетов для уже рассмотренных проектов приведен на рисунке 8:
Рис. 8. Пример плана проектов по ИТ: вариант Х (если заранее оценить приоритеты проектов)
На рисунке 8 также учтены и взаимосвязи между проектами.
Сравнение примеров вариантов планирования
Вот сравнение рассмотренных вариантов планирования проектов (см. таблицу 1):
- в варианте 1 учли только ожидаемые выгоды от проектов;
- в варианте 2 учли также и зависимости между проектами;
- в варианте 3 учли также и затраты на проекты;
- в варианте 4 учли также и резервы времени на выполнение проектов;
- в варианте Х учли также и приоритеты проектов (как их определять, рассмотрено здесь).
Табл. 1. Сравнение рассмотренных примеров планирования проектов по ИТ
| Варианты | Выгоды для бизнеса | Связи между проектами | Требуемые ресурсы | Резервы времени | Риски проектов | Приоритеты проектов | Время выполнения проектов, месяцев, план/факт | Затраты времени на планиро-вание проектов, человеко-дней |
| 1 | √ | — | — | — | — | — | 2,5 / 13 | 0 |
| 2 | √ | √ | ~ | — | — | — | 6 / 12 | 1 |
| 3 | √ | √ | √ | — | ~ | — | 9 / 10,5 | 2 |
| 4 | √ | √ | √ | √ | √ | — | 9-10 / 9 | 3 |
| X | √ | √ | √ | √ | √ | √ | 8 / 9 | 4 |
Обозначения: «√»: да; «~»: частично; «-»: нет.
Из сравнения вариантов планирования проектов (таблица) видно, что совсем небольшие затраты на планирование проектов (всего несколько дней) могут позволить в разы более точно планировать проекты. Если в варианте совсем без планирования (вариант 1) реальное время выполнения составило 13 месяцев (а мечтали о сроке в 2,5 месяца), то в вариантах 4 и Х реальное время сократилось до 9-9,5 месяцев и почти совпало с плановым.
Эффект от планирования в десятки раз может превосходит затраты.
3. Портфельное управление проектами
Для разработки в ИТ-стратегии плана проектов по ИТ можно использовать методологию портфельного управления проектами. Эта методика специально разработана для выбора лучших проектов, разработки плана проектов и управления его выполнением. Методика портфельного управления проектами сильно отличаются от планирования одного или нескольких проектов, в том числе от того, что реализовано в MS Project.
Отличия портфеля проектов от отдельных проектов:
- для портфеля проектов указывается, что надо сделать, а не как конкретно. А для конкретного проекта — что и как конкретно надо сделать;
- очень часто большие проекты можно рассматривать как отдельный портфель проектов, в который входит множество более мелких проектов.
Табл. 2. Примеры отличий портфеля проектов от отдельных проектов
| Примеры портфелей проектов | Примеры проектов для этих портфелей |
| а) Увеличить продажи товаров Х на Y процентов. | Внедрить CRM. |
| б) Наладить грузовое и пассажирское сообщение с полуостровом Крым. | Провести исследование дна Керченского пролива для определения стоимости 4-х полосного моста. |
Портфельное управление проектами: основные этапы
Портфельное управление проектами состоит из трех этапов: планирование, управление и оценка (см. Рис. 9):
- Планирование: выбор проектов и разработка плана проектов;
- Управление: управление портфелем проектов;
- Оценка: периодическая оценка и корректировка плана проектов.
Рис. 9. Этапы портфельного управления проектами
Все эти этапы выглядят просто, но организации, где все это выполняется, вряд ли превышают 1% от всех российских компаний. Хотя, по моим оценкам, и в странах ЕС только процентов десять от всех компаний используют портфельное управление проектами. Но, все равно это пока больше, чем в России.
Портфельное управление проектами: выбор проектов и разработка плана проектов
Большинство российских ИТ-менеджеров (точнее те, с кем я знаком) знают об управлении отдельными проектами, и, иногда даже используют это знание, например, рисуя этапы проекта в MS Project.
В методиках управления отдельными проектами упоминается, что надо управлять и всеми проектами (или «портфелем проектов»). Многие ИТ-менеджеры про это слышали. Слышали они и о том, что надо как-то приоритизировать потенциальные проекты по ИТ, а не сразу бросаться их выполнять. Хотя обычно, выбор проектов ограничивается лишь личными предпочтениями и давлением лиц, заинтересованных в конкретных проектах, особенно генеральным директором.
Однако, есть и лучшие практики выбора проектов: какие из них включить в план, а какие сразу убить. Вот рекомендуемая портфельным управлением проектами последовательность выбора проектов:
- Определение целей портфельного управления, а также основные этапы (сроки) выполнения проектов;
- Определение критериев выбора проектов. Примеры возможных критериев: соответствие целям бизнеса, финансовые показатели, риски и т.д.;
- Оценка приоритетов проектов;
- Выбор проектов и разработка плана проектов.
1. Определение целей портфельного управления
На этом этапе надо определиться, зачем вообще вам нужно портфельное управление проектами, в том числе, проектами по ИТ. Может оно и вовсе не нужно? Возможными целями могут быть независимые от конкретных проектов цели, такие как «объединение информационных систем нескольких компаний, как обязательная часть объединения их бизнесов».
Также важно учесть основные этапы выполнения портфеля проектов, а точнее – время, когда должны быть выполнены конкретные проекты. Обычно такие сроки задаются со стороны бизнеса или же это какие-то внешние события. Например:
при объединении двух крупнейших российских бирж (ММВБ и РТС) точная дата начала объединения информационных систем заранее задана не была. Представители бизнеса до самого последнего момента тянули с объявлением этого срока Однако требование завершить интеграцию информационных систем в очень сжатые сроки было выставлено с самого начала;
проекты, связанные с Олимпиадой-2014 в Сочи, явно имели жесткий срок завершения – непосредственно к самой Олимпиаде. А вот сроки выполнения конкретных проектов иногда можно было менять, а от некоторых проектов вовсе отказаться, например, были выведены из плана работ к Олимпиаде, проекты по улучшению портов на побережье Черного моря (собственно, они не были обязательны именно для проведения Олимпиады).
Соответственно, выбор конкретных проектов, связи между ними и требуемые ресурсы должны четко соответствовать поставленным целям и сроку завершения. Хотя, можно было пробовать торговаться по требуемым ресурсам и качеству работ.
2. Определение критериев выбора проектов
На Рис. 10 приведен типовой для портфельного управления проектами пример сравнения проектов в соответствии с выбранными критериями:
Рис. 10. Пример оценки проектов по методике портфельного управления проектами
В левой части рисунка перечислены рекомендуемые в портфельном управлении проектами критерии выбора проектов, в правой части – диаграмма со сравнением проектов в соответствии с критериями их выбора.
Рассмотрим группы критериев выбора проектов:
«Внешние условия (must-projects)»
Это обязательные для выполнения требования со стороны вышестоящих организаций или государства, возможно также и требования генерального директора.
Проекты, по которым есть подобные требования, все равно придется выполнять вне зависимости от того, окупаются ли эти проекты, есть ли у ИТ-службы требуемые квалификации или нет.
В качестве типового примера таких проектов можно рассмотреть подготовку нового отчета для налоговой службы. Этот проект может потребовать существенной доработки отчетов, но сотрудникам ИТ удастся уклониться от этой работы.
«Бизнес взгляд»
В этой группе рассматриваются критерии, позволяющие оценить, насколько проекты хороши для бизнеса и насколько они окупаемы. Рекомендуется для всех потенциальных проектов оценивать их соответствие целям бизнеса, а также рассчитывать окупаемость проектов, например ROI (Return of Investments).
Однако, расчет ROI только по одному проекту может занять пару недель.
«Проектный взгляд»
Здесь должны быть рассмотрены критерии, позволяющие оценить, насколько потенциальные проекты хороши как проекты (то есть для них нужны небольшие ресурсы и т.д.).
Я несколько раз пробовал составлять подобные списки критериев сравнения проектов, назначать веса критериев (на рисунке их нет, но учитывать веса надо обязательно) и рисовать итоговые диаграммы сравнения проектов. Если не рассчитывать финансовые показатели проектов, типа ROI, то за неделю можно сравнить все потенциальные проекты (но если рассчитывать и финансовые показатели, то эта задача на много месяцев).
Мой опыт использования методики портфельного управления при выборе проектов в ИТ-стратегии был неуспешным. Вроде бы и критерии были выбраны верные, и веса критериев похожи на правду, а результаты сравнения не совпадали с интуитивной оценкой ИТ-директоров, для которых я проводил работы.
Возможно, проблема кроется в том, что делается попытка учесть пять и более физически разных критериев. В то время как люди способны одновременно учесть два или три разных критерия: если показывать результаты на бумаге или компьютере, то люди легко различают две оси (вертикальная и горизонтальная), ну и может еще размер или цвет кружков. И все! В 3D-изображениях можно воспринимать уже четыре критерия. Но не десять и более, как рекомендуется в портфельном управлении проектами.
Тем не менее, если вы все-таки соберетесь использовать методику выбора проектов в соответствии с портфельным методом управления, то кроме выбора критериев и назначения им весовых коэффициентов надо сделать и оценки для каждого проекта, что не слишком просто.
В качестве резюме можно отметить, что методы портфельного управления проектами надо иметь в виду, но для выбора проектов в ИТ-стратегии можно использовать и более упрощенные подходы. Здесь рассмотрены мои наработки по сравнению проектов в ИТ-стратегии.
Оценка приоритетов проектов
Для оценки и визуализации приоритетов проектов, в портфельном управлении проектами используется следующая стратегическая диаграмма сравнения проектов: «Бизнес взгляд * Проектный взгляд» (см. Рис. 11).
Из всех областей диаграммы сравнения проектов хорошие проекты находятся только в правой верхней области, то есть это проекты, хорошие для бизнеса (высокая оценка по шкале «Бизнес взгляд») и сами хороши как проекты (высокая оценка по шкале «Проектный взгляд»). Проекты из всех остальных областей целесообразно или вообще не выполнить, или же существенно улучшить до выполнения:
Рис.11. Диаграмма сравнения проектов, рекомендуемая в портфельном управлении проектами
Выбор проектов и разработка плана проектов
Для выбора проектов надо всего-то сравнить все потенциальные проекты в соответствии с заранее выбранными критериями и принять решение, что с каждым конкретным проектом делать: включить в портфель проектов, убить или далее раздумывать над его судьбой (см. Рис. 12):
Рис.12. Сравнение и выбор проектов
Пример выбора проектов по ИТ в соответствии с портфельным управлением проектами рассмотрен на Рис. 13:
Рис. 13. Пример выбора проектов по ИТ
Стоит отметить, что эта диаграмма отличается от очень похожей на Рис. 12 тем, что проект по CRM на Рис. 13 показан существенно ниже по шкале «Бизнес взгляд», так как на этом рисунке нет оценки «Must projects», которая есть на Рис. 12.
Зарубежные исследования оценивают эффект от улучшения управления проектами, включая их сравнение и приоритизацию, в 15-30% снижения расходов на все проекты. Мой опыт попыток улучшения выбора проектов по ИТ для сотен российских средних предприятий позволяет оценить эффект от сравнения и приоритизации проектов в 10-15% сокращения затрат на ИТ в целом (или такое же увеличение выгод бизнеса от использования ИТ).
Портфельное управление проектами: управление портфелем
Этап «Управление» включает в себя управление выполнением проектов по ИТ:
- Регулярный контроль выполнения проектов;
- Регулярные корректировки выполнения отдельных проектов.
На этом этапе предполагается выполнение проектов, включенных в портфель проектов. На уровне конкретных проектов надо использовать методы управления проектами, например, отслеживая на MS Project ход выполнения каждого из них.
На этом этапе предполагаются корректировки отдельных проектов, но не добавление новых проектов и прекращение совсем неуспешных проектов.
Портфельное управление проектами: периодическая оценка и корректировка портфеля проектов
Этап «Оценка» включает в себя:
- Сравнение результатов выполнения портфеля проектов с поставленными целями;
- Определение требуемых корректировок портфеля проектов.
На этапе периодической оценки и корректировки портфеля проектов предполагается определить, успешно ли идет выполнение портфеля проектов в целом. Пример направлений сбалансированной системы показателей оценки эффективности выполнения портфеля проектов приведен на Рис. 14:
Рис. 14. Возможные направления оценки эффективного выполнения портфеля проектов
По результатам оценки, ряд проектов можно будет просто прекратить, а некоторые проекты существенно скорректировать. Также возможно добавление новых проектов. Оценки и корректировки портфеля проектов также обязательно планировать заранее, и проводить их раз в 3-6 месяцев, как впрочем и при возникновении существенных изменений, например, кризисов.
4. Этапы работы с проектами по ИТ
Далее рассмотрено, как быстро и достаточно точно провести сравнение проектов. Я разработал эту методику только после десяти лет попыток выбора проектов при разработке ИТ-стратегий.
На этапе планирования надо провести сравнение (приоритизацию) проектов по ИТ. Для отобранных проектов надо разработать примерный план их выполнения, а также описание каждого из проектов (см. Рис. 15):
Рис. 15. Выбор проектов при разработке ИТ-стратегии
Далее рассмотрены основные этапы выбора проектов при разработке ИТ-стратегии:
- Сбор информации по ИТ-проектам и источники этой информации;
- Сравнение и выбор проектов;
- План проектов, ИТ-бюджет, описание проектов по ИТ.
Этап 1 работы с проектами при разработке стратегии: Сбор информации по ИТ-проектам
Вначале надо собрать описания уже выполняемых проектов. Как правило, еще до разработки ИТ-стратегии, две трети проектов уже известны и обсуждались.
Второй источник возможных проектов по ИТ – это анализ текущего состояния ИТ. После этого анализа надо прикинуть возможные проекты по устранению выявленных проблем. Но, возможно, существенную часть этих проектов выполнять и не надо. Например, если у вас никто сейчас не читает лог-файлы с серверов, то не факт, что надо этого делать, если вы собираетесь через несколько месяцев передать поддержку серверов другой компании.
Третий источник проектов по ИТ – это проекты по переходу в требуемое состояние ИТ через 1-3 года: внедрить конкретные информационные системы, изменить инфраструктуру ИТ, улучшить управление ИТ.
Работа с проектами проводится на каждом из этапов проекта по разработке ИТ-стратегии (см. Табл. 2):
| Области ИТ | Уже выполняемые проекты | Проекты по устранению найденных проблем | Проекты по переходу в требуемое состояние ИТ |
| Информационные системы | — … | — … | — … |
| Инфраструктура ИТ | — … | — … | — … |
| Управление ИТ | — … | — … | — … |
В одном из проектов по разработке ИТ-стратегии было выявлено, что просто забыли, что надо и сотрудников ИТ-службы научить, как работать с новой инфраструктурой ИТ и приложениями.
То есть уже были запланированы большие проекты по внедрению Oracle, централизации инфраструктуры ИТ, обучению пользователей. А про сотрудников ИТ-службы забыли.
Этап 2 работы с проектами при разработке стратегии: Сравнение и выбор проектов
Основные характеристики проектов
Как ни странно, но среди сотен ИТ-стратегий, которые я видел, практически не было примеров использования сложных методик оценки финансовой отдачи от проектов: ROI, ТЭО, NPV и др. То есть, как правило, все ограничиваются интуитивной оценкой финансовой отдачи от проектов.
Я бы выделил три самые важные характеристики каждого из потенциальных проектов по ИТ:
1. Выгоды для бизнеса (хотя и выгоды для ИТ тоже стоит учитывать).
Выгоды для бизнеса от конкретных проектов должны оценивать представители бизнеса, очень желательно – генеральный директор или куратор ИТ;
2. Ресурсы, требуемые для выполнения проекта (внешние выплаты и время своего персонала). Ресурсы по проектам может оценить ИТ-директор;
3. Риски невыполнения проекта (риски того, что уже начатый проект не будет завершен в планируемые сроки, с планируемым бюджетом и качеством).
Конечно, рисков гораздо больше, надо учитывать еще, как минимум, риски, которые возникнут если вообще не выполнить конкретный проект, например, требование по информационной безопасности от вышестоящих организаций (попробуй его не выполнить).
В принципе, критериев для сравнения проектов, конечно, больше. Например, я использую еще плановость и срочность проектов.
В рамках ИТ-стратегии ИТ-проекты обычно рассматриваются на уровне кратких описаний проектов с оценкой затрат на них и ожидаемых выгод.
Возможные дополнительные характеристики проектов
4. Финансовые показатели проектов (ROI, ТЭО, NPU и др.);
5. Срочность проектов. Действительно срочные проекты вы или будете выполнять, невзирая на их плохие показатели, или совсем отмените. На мой взгляд, выигрыш от стратегий и планирования в существенной мере заключается в уменьшении неожиданных и срочных проектов, очень часто крайне дорогих и неэффективных;
6. Плановость проектов. Если один из нескольких альтернативных проектов вы уже и рассматривали и планировали его выполнение, то это небольшой, но плюс в сравнении с проектами, которые ранее не планировали;
7. Риски отказа от выполнения проекта. Для ряда проектов велики именно такие риски. Например, вовремя не написать несложный, но трудоемкий отчет для налоговой службы или совета директоров. К таким же рискам можно отнести и упущенную прибыль (выгоды), которые не удастся получить, если проект не будет выполнен;
8. И т.д. и т.п., в том числе и детальное рассмотрение и основных характеристик проектов:
- выгоды для бизнеса (да и для ИТ);
- требуемые ресурсы (деньги, люди, прочие ресурсы);
- риски (не выполнить проект в заданные сроки; бюджет; риски неполного выполнения проекта и т.д.).
Пример сравнения и выбора проектов: основные исходные данные по проектам
Я пробовал рассмотреть достаточно типичный для многих российских предприятий пример сравнения и выбора проектов по ИТ на ближайший год. Лучше подобные работы делать в рамках разработки ИТ-стратегии.
Скорее всего, многие или даже большинство читателей этой книги смогут отметить ряд используемых в примерах решений, не совсем соответствующих лучшим международным практикам. Это так, упор сделан на реальные решения, совершенно определенно не идеальные, особенно с точки зрения тех, кто имеет опыт и руководства и разработки стратегий.
В Табл. 3 рассмотрен пример потенциальных проектов, а также кому и зачем они нужны:
Табл. 3. Пример сравнения проектов по ИТ: кому и зачем нужны проекты
| Проекты | Кому и зачем нужны проекты |
| Информационные системы | |
| CRM: внедрение | Гендиректор хочет с помощью CRM увеличить продажи на 20-30%. Представители компании-продавца CRM обещали гендиректору, что после внедрения CRM (которое пройдет быстро и легко) продажи сами собой вырастут. Гендиректор загорелся этой идеей и твердо решил срочно внедрить CRM. Сотрудники компании, однако, этими планами не довольны и не хотели бы делиться данными о своих клиентах. |
| ERP: расширение | Замдиректор по производству хотел улучшить контроль и планирование управления выполнением заказов, расширив для этого функциональность уже используемой системы ERP. Предполагается довнедрить один из уже работающих несколько лет модулей ERP; внедрить один новый модуль; обеспечить обмен информацией с системой автоматизации производства (АСУТП). |
| Инфраструктура ИТ | |
| Свой ЦОД | ИТ-директор и другие сотрудники ИТ давно хотели свой ЦОД, т.к. это круто, да и имеющиеся сервера загружены более 80% (2-3 часа в сутки, остальное время – меньше). |
| Аренда ЦОД | Дешевая альтернатива своему ЦОДу — не круто, но позволит решить имеющиеся проблемы с инженерным оборудованием и отсутствием резерва серверных мощностей. |
| Управление ИТ | |
| ИТ-стратегия | ИТ-директор учился недавно по программе MBA и узнал, что стратегии могут позволить и спланировать проекты по ИТ, и обосновать их бизнес-руководству. |
| SLA: разработка | Сотрудники ИТ давно хотели доработать и согласовать с пользователями Каталог ИТ серверов и SLA, а то звонят всякие пользователи по ночам и жалуются, что что-то там не работает (а правильный ответ – и не должно работать и звонить по ночам не надо). |
Далее рассмотрены примеры сравнения проектов из Табл. 3.
Сравнение выгод и затрат по проектам
На основании сведенных в Табл. 2 данных, ИТ-директор собрал подробную информацию по оценке возможных выгод от проектов (Табл. 4) и по затратам на проекты (Табл. 5).
В Табл. 4 сведены оценки выгод по рассматриваемым в качестве примера проектов, как они видятся для бизнеса и для ИТ:
Табл. 4. Пример сравнения проектов по ИТ: оценки выгоды
| Проекты | Выгоды для бизнеса | Выгоды для ИТ | Итого |
| Информационные системы | |||
| CRM: внедрение | H | L | H |
| ERP: расширение | M | L | M |
| Инфраструктура ИТ | |||
| Свой ЦОД | H | L/M | M |
| Аренда ЦОД | M | M | M |
| Управление ИТ | |||
| ИТ-стратегия | M/H | M/H | M/H |
| SLA: разработка | H | M | M/H |
Обозначения: «L»: низкие; «M»: средние; «H»: высокие
Итоговая оценка выгод взята как выгоды для бизнеса с учетом также ИТ. Еще раз уточним, что все данные взяты для примера, на котором будет показано сравнение проектов между собой и построение планов проектов.
Судя по Табл. 4:
- самые высокие выгоды видятся от внедрения CRM (за счет того, что это очень нужно бизнесу);
- достаточно важными для бизнеса видятся такие проекты как ИТ-стратегия, так и SLA (за счет высоких выгод и для бизнеса, и для ИТ).
Табл. 5. Пример сравнения проектов по ИТ: оценки затрат
| Проекты | Внешние выплаты, млн.руб. | Внешние выплаты: пересчет в L/M/H | Свой персонал: чел-дней своих сотрудников | Свой персонал: пересчет в L/M/H | Итого | Можно ли уменьшить затраты на 30% и более |
| Информационные системы | ||||||
| CRM: внедрение | 1-2 | M/H | 50-100 | M | M/H | нет |
| ERP: расширение | 0,5-1 | M | 100-200 | H | M/H | да, можно пока не делать интеграцию с АСУТП |
| Инфраструктура ИТ | ||||||
| Свой ЦОД | 3-10 и 0,5-1 (за год) | H | 100-150 и 50-150 (за год) | H | H | да, за счет аренды ЦОДа |
| Аренда ЦОД | 0,1-0,3 (за год) | L/M | 20-30 и 10-50 (за год) | L | L/M | нет |
| Управление ИТ | ||||||
| ИТ-стратегия | 0-30 | L/M | 30-90 | M | L/M | разработать самим после обучения |
| SLA: разработка | 0 | L | 20-30 | L | L | нет |
Обозначения: «L»: низкие; «M»: средние; «H»: высокие
Приведенные в Таб. 4 и Табл. 5 примеры оценок проектов рассмотрены далее на диаграммах.
Вот диаграмма сравнения выгод и затрат по проектам (см. Рис. 16):
Рис. 16. Пример сравнения проектов по соотношению выгод и затрат
Вот комментарии по сравнению ожидаемых выгод от проектов и затрат на них:
- CRM: выгоды от этого проекта самые высокие, генеральный директор ожидает серьезнейшего увеличения продаж; и, если проект по CRM будет завален, то ИТ-руководителю явно надо будет искать новое место работы. Причем для гендиректора может быть не важно, что информационная система сотрудниками ИТ запущена в работу, а не стали с ней работать продавцы. Уволить могут всех.
Требуемые для внедрения CRM ресурсы весьма высоки и вряд ли стоит их существенно уменьшать, тут уж или внедрять, или вообще не делать этого;
- ERP: выгоды для бизнеса есть, хотя и меньше, чем от CRM. А ресурсов может потребоваться много, так как предполагается и интеграция с АСУТП (но ее можно и отложить);
- свой ЦОД: выгоды не так велики (это скорее только сотрудникам ИТ интересно), а вот ресурсы нужны очень большие, даже больше, чем на внедрение CRM;
- аренда ЦОД: выгоды средние, как и от своего ЦОДа. А вот затраты невелики, особенно в сравнении со строительством своего ЦОДа;
- ИТ-стратегия: выгоды выглядят как достаточно высокие (10-15% повышения эффективности ИТ), а затраты сравнительно невелики;
- SLA: выгоды достаточно высокие, а затраты совсем низкие (в сравнении с другими проектами).
Комментарии ИТ-директоров
- «На мой взгляд, CRM внедрить сравнительно легко. И продажи, может быть и вырастут. Вопрос – а что будете продавать? Если у вас производство свое, надо же увеличивать объемы производства. А то и продавать будет нечего. Если к увеличению объемов необходимо оптимизировать ERP, как заявлено, то надо сначала это сделать, а уж потом к CRM приступать. Или как-то параллельно».
Федько Виктор, ИТ-директор, «МПО им.И. Румянцева»
Сравнение рисков проектов
В Табл. 6 сведены оценки рисков по рассматриваемым в качестве примера проектам:
Табл. 6. Пример сравнения проектов по ИТ: оценки рисков
| Проекты | Риски выполнения проекта (не уложиться в сроки и/или бюджет) | Риски, если не начать выполнение проекта: для бизнеса | Риски, если не начать выполнение проекта: для ИТ | Риски, если не начать выполнение проекта: итого |
| Информационные системы | ||||
| CRM: внедрение | H | H | L | H |
| ERP: расширение | M | M | L | M |
| Инфраструктура ИТ | ||||
| Свой ЦОД | H | M/H | M/H | M/H |
| Аренда ЦОД | L/M | M/H | M/H | M/H |
| Управление ИТ | ||||
| ИТ-стратегия | M | L/M | M/H | M/H |
| SLA: разработка | L/M | M | M/H | M/H |
Обозначения: «L»: низкие; «M»: средние; «H»: высокие
На Рис. 17 рассмотрен пример диаграмма сравнения рисков проектов:
Рис.17. Пример сравнения рисков проектов
Вот комментарии по оценкам рисков проектов по ИТ:
- CRM: если не начать этот проект в ближайшие полгода, то для ИТ в целом ничего не случится. Однако, генеральный директор будет в шоке от прямого невыполнения его указания, и, скорее всего, уволит руководителя ИТ-службы;
- ERP: возможно как уменьшение масштаба проекта, так и его отодвигание где-то на 2-4 месяца;
- свой ЦОД: для сотрудников ИТ отказ от своего ЦОДа будет досаден, но не смертелен. А со стороны бизнеса потребуется увеличение вычислительных мощностей (под CRM и ERP), а также более надежная работа инженерного оборудования имеющихся серверных. Всего этого, и гораздо дешевле, можно достичь в рамках проекта по аренде «кусочка» чужого ЦОДа. А риски не завершить вовремя и не вписаться в бюджет проекта по созданию своего ЦОДа весьма высоки, особенно, если вы делаете это в первый раз;
- аренда ЦОД: риски не выполнить данный проект в срок и в рамках бюджета скорее невелики, т.к. большинство работ являются типовыми и выполняются другими организациями, которые только этим, вроде бы, и занимаются. Однако, неувеличение серверных мощностей к моменту ввода CRM в промышленную эксплуатацию закончится большими проблемами;
- ИТ-стратегия: бизнесу не особенно нужна, однако для ИТ это чуть ли не единственная реальная возможность как разработать реальный план проектов по ИТ на несколько лет вперед, так и согласовать его с бизнес-руководством.
Риски незавершения разработки ИТ-стратегии в срок – средние или даже высокие, большинство российских компаний таких работ не делали;
- SLA: риски не выполнить проект в срок скорее невысоки (это в сравнении с внедрением CRM, хотя почти все ИТ и бизнес-проекты в плановые сроки в России не завершаются). Если SLA и Каталог ИТ сервисов не разработать, то от CRM и ERP пользователи будут ожидать совсем уж нереального, в т.ч. доступа к CRM в любое время дня и ночи, а также с любого телефона любого из продавцов. Ну и автоматических продаж, если все другие требования удастся реализовать.
5. Выбор проектов при разработке стратегий: «светофор Михайлова»
Итоговое сравнение выгод, затрат, рисков проектов
Для быстрого сравнения всех потенциальных проектов, в том числе ИТ-проектов на следующий год, целесообразно использовать стратегическую диаграмму, где есть все три наиболее важные характеристики проектов: выгоды, ресурсы, риски.
Для того, чтобы показать все эти характеристики на двумерной диаграмме, я предлагаю в качестве одной из осей использовать соотношение выгод к затратам. Кроме «свертывания» двух показателей в один, соотношение выгод к затратам имеет и физический смысл: проекты, у которых затраты больше выгод, теоретически вообще не стоит рассматривать. Это примерно как посадить два мешка картошки, все лето ухаживать за ней, а потом собрать только один мешок.
Однако, на практике, многие проекты, для которых затраты больше выгод, все-таки приходится выполнять, как минимум, если это требования вышестоящего начальства, или проекты, которые являются обязательными предшественниками перед другими проектами, для которых выгоды существенно больше затрат.
На Рис. 18 приведена разработанная мной диаграмма для сравнения между собой потенциальных проектов (кстати, диаграмма работает как для проектов по ИТ, так и по любым другим областям):
Рис. 18. Стратегическая диаграмма сравнения проектов
Более подробная информация по квадратам на Рис. 18, приведена в Табл. 7:
Табл. 7. Шкала оценки приоритетов проектов
| N квадрата | Оценки проектов: выгоды и затраты | Оценки проектов: риски | Рекомендации | Примечания |
| 1 | Выгоды < Затрат | Низкие | увеличить выгоды и/или снизить затраты | Проекты с плохим соотношением выгод к затратам, но низкими рисками. Для таких проектов целесообразно увеличить выгоды и/или снизить затраты. |
| 2 | Выгоды < Затрат | Высокие | убить или существенно улучшить | Проекты с плохим соотношением выгод к затратам и высокими рисками. Такие проекты целесообразно совсем не выполнять или существенно улучшить перед выполнением. |
| 3 | Выгоды > Затрат | Высокие | снизить риски | Проекты с хорошим соотношением выгод к затратам, но высокими рисками. Для таких проектов надо снизить риски. |
| 4 | Выгоды > Затрат | Низкие | хорошие проекты | Проекты с хорошим соотношением выгод к ресурсам и низкими рисками. Такие проекты целесообразно выполнить как можно раньше. |
Еще раз уточним, что на Рис. 18 и в Табл. 7 предложены рекомендации без учета связей проектов между собой, а также дополнительных факторов типа «требования начальства», «срочность», «плановость» и др. Эти факторы надо учитывать индивидуально для каждого проекта.
Вот комментарии по сравнению выгод, затрат, рисков проектов:
- ERP: снижены и затраты, и риски за счет отказа от интеграции с АСУПТ;
- CRM: снижены риски за счет разработки подробного ТЗ, снижения требований к CRM, взятия в штат ИТ-службы специалиста по CRM;
- ЦОД: отказаться от этого проекта, заменив на проект «Аренда ЦОД».
Рассмотренные рекомендации изображены на Рис. 19, как стрелочки по изменению характеристик проектов по ERP, CRM, ЦОД:
Рис. 19. Пример сравнения проектов по ИТ (вид стратегической диаграммы): желательные корректировки проектов
Объединение стратегических рекомендаций и практического опыта сравнения и выбора проектов: «Светофор Михайлова»
Только после десятка лет работы по выбору проектов, мне удалось разработать форму для сравнения проектов, как хорошо понятную, так и достаточно корректно визуализирующую основные оценки проектов. Форма основана на эмпирических данных уже проведенных сравнений проектов, которые я выполнял и для ИТ-стратегий, и для бизнес-проектов, и в проектах для своей семьи. Поначалу это был калькулятор проектов на Excel, только в 2014 году удалось разработать форму, как она нарисована на Рис. 20:
Обозначения: размер кружков пропорционален затратам на проекты.
Рис. 20. Пример сравнения проектов по ИТ: «светофор Михайлова»
Красным цветом обозначены проекты с низкой привлекательностью. На них затрачивается больше ресурсов, чем получается выгод. Выполнение таких проектов можно запланировать через 2-3 года, что практически эквивалентно их вычеркиванию из списка реальных проектов. Однако, через полгода-год привлекательность может сильно измениться и, может быть, дело дойдет до проектов, которые сейчас выглядят совершенно непривлекательными.
Желтым обозначены проекты со средней привлекательностью. Затраты на эти проекты примерно равны выгодам.
Зеленым обозначены проекты с высокой привлекательностью. У них хорошее соотношение выгод к ресурсам: выгоды больше, чем ресурсы. И низкие риски.
Табл. 8. Шкала оценки привлекательности проектов (по «светофору Михайлова»)
| Оценки проектов: выгоды и затраты | Оценки проектов: риски | Рекомендации | Примечания | Привлекательность проектов |
| Выгоды << Затрат | любые | Красный | Проекты с очень плохим соотношением выгод к затратам, выгоды существенно меньше затрат. Такие проекты лучше отложить (в идеале убить) или существенно увеличить выгоды, снизить затраты и риски. | Низкая |
| Выгоды < Затрат | любые | Темно-желтый | Проекты с плохим соотношением выгод к затратам, выгоды меньше затрат. Такие проекты лучше отложить или же увеличить выгоды, снизить затраты и риски. | Низкая или средняя |
| Выгоды = Затрат | любые | Желтый | Проекты со средним соотношением выгод к затратам, выгоды примерно равны затратам. Для таких проектов надо увеличить выгоды и/или снизить затраты и/или риски. | Средняя |
| Выгоды > Затрат | низкие или средние | Светло-зеленый | Проекты с хорошим соотношением выгод к затратам и низкими или средними рисками. Такие проекты можно выполнять сразу, или вначале попробовать немного снизить риски и/или снизить затраты и/или увеличить выгоды. | Высокая |
| Выгоды >> Затрат | низкие | Зеленый | Проекты с очень хорошим соотношением выгод к затратам и низкими рисками. Такие проекты целесообразно выполнить, ничего не меняя, все и так хорошо. | Очень высокая |
Исходя из приведенного примера сравнения проектов по ИТ на диаграмме (Рис. 20) можно предложить возможные рекомендации по улучшению этих проектов, которые сведены в Табл. 9:
Табл. 9. Пример сравнения проектов: результаты сравнения и возможные рекомендации
| Проекты | Выгоды и затраты | Риски | Результат оценки | Возможные рекомендации |
| Информационные системы | ||||
| CRM: внедрение | Выгоды > Затрат | Высокие | Плохой проект, надо снизить риски | Снизить риски. Вот что можно сделать: а) взять на работу специалиста по CRM б) разработать подробное ТЗ в) разработать вначале макет г) внедрять постепенно, по отделам. |
| ERP: расширение | Выгоды < Затрат | Средние | Плохой проект, надо увеличить выгоды или снизить затраты | Раза в два сократить внедряемую в этот раз функциональность, что позволит снизить и риски. Например, отложить интеграцию с АСУТП, что снизит и риски проекта в целом. |
| Инфраструктура ИТ | ||||
| Свой ЦОД | Выгоды < Затрат | Высокие | Очень плохой проект, лучше его убить | Если не удастся сократить затраты на 30% (а лучше 50%), то не стоит выполнять этот проект, выполнив вместо него проект «Аренда ЦОД». |
| Аренда ЦОД | Выгоды > Затрат | Низкие | Хороший проект | Найти 2-5 подходящих предложений на аренду стоек в ЦОДах провайдеров. |
| Управление ИТ | ||||
| ИТ-стратегия | Выгоды > Затрат | Средние | Достаточно хороший проект, хорошо бы снизить риски | Надо поучиться разработке ИТ-стратегий и/или привлечь к этой работе тех, кто уже это успешно делал. |
| SLA: разработка | Выгоды > Затрат | Низкие | Хороший проект | Надо пользователям в план поставить согласование SLA. Со стороны ИТ вроде все понятно как разработать SLA. |
Если проектов больше чем 10-15 и они не помещаются на диаграмму, то ИТ-руководители, которые проходят у меня обучение, используют также калькулятор на Excel. Вот оценки привлекательности проектов, сделанные в калькуляторе, собственно приоритеты проектов те же, что и при сравнении проектов в диаграмме на Рис. 20 (Табл. 10):
Табл. 10. Пример оценки привлекательности проектов
| Проекты | Выгоды | Затраты | Риски | Приоритет (Выгоды — Затраты) / Риски |
| Информационные системы | ||||
| CRM: внедрение | H | M/H | M | M/H |
| ERP: расширение | M | L/M | L/M | M/H |
| Инфраструктура ИТ | ||||
| Свой ЦОД | M | H | H | L |
| Аренда ЦОД | M | L/M | L/M | M/H |
| Управление ИТ | ||||
| ИТ-стратегия | M/H | L/M | M | M/H |
| SLA: разработка | M/H | L | L/M | H |
Используемые в этом калькуляторе формулы здесь не приведены, с одной стороны – они сложные (в том числе вложенные друг в друга функции VLOOKUP), а с другой стороны – проводится поиск по уже имеющимся эмпирическим данным, которые визуализированы на Рис. 20.
6. Разработка плана проектов и проектов по ИТ
Этап 3 работы с проектами при разработке стратегии: разработка плана проектов и проектов по ИТ
Разработка плана проектов
ИТ-директор собрал и дополнительную информацию по проектам: их зависимостям между собой, длительностью и требуемыми ресурсами, см. Табл. 11:
Табл. 11. Пример сравнения проектов по ИТ: основные параметры проектов
| Проекты | Обязательность проекта | Длитель-ность, месяцев | Зависимости от других проектов | Желательное время завершения проекта |
| Информационные системы | ||||
| CRM: внедрение | обязательно | 2-12 | могут потребоваться дополнительные вычислительные мощности | прямо сейчас |
| ERP: расширение | очень желательно | 2-6 | — // — | до конца года |
| Инфраструктура ИТ | ||||
| Свой ЦОД | обязательно | 3-6 | желательно вначале оценить вычислительные ресурсы под CRM и расширение ERP | один из этих проектов надо выполнить до завершения внедрения CRM |
| Аренда ЦОД | обязательно | 1-3 | — // — | — // — |
| Управление ИТ | ||||
| ИТ-стратегия | желательно | 2-3 | лучше выполнить до на-чала всех проектов, или вообще не выполнять | |
| SLA: разработка | желательно | 1-2 | лучше до или совместно с CRM и ERP |
А вот план проектов, разработанный с учетом как привлекательности (или приоритетов проектов, они выделены цветом) проектов, так резервов времени (они выделены пунктиром), см. Рис. 21:
Рис. 21. Пример плана проектов с учетом их привлекательности и резервами времени
Надо отметить, что предлагаемая методика сравнения дает не точное решение по одному конкретному проекту, а рекомендации по выбору наиболее быстрых в отдаче проектов (по-английски «quick wins»), то есть приоритеты проектов без учетов связей с другими проектами. Кроме приоритетов отдельных проектов, надо дополнительно учитывать связи между ними, а также проекты, которые обязательно должны быть выполнены (например, требования государства или акционеров).
То есть, полученные оценки привлекательности проектов являются лишь информацией к размышлению при построении плана проектов. Также надо учитывать:
- взаимосвязи между проектами: очень часто проекты с высокой привлекательностью требуют, чтобы до них был выполнен ряд проектов с низкой привлекательностью. Например, внедрение больших информационных систем типа SAP или BI, может потребовать как серьезных затрат на инфраструктуру ИТ, так и улучшения ИТ-процессов и обучения персонала ИТ-службы (о чем часто забывают);
- проекты, которые обязательно надо выполнить: к таким проектам можно отнести требования государства, реализовать которые может быть сложно и дорого, а выгод для бизнеса вроде и не видно. Однако, при невыполнении подобных требований ваше предприятие могут закрыть, причем быстро.
Проекты с плохими оценками, но обязательные к выполнению, могут исходить от генерального директора. Хотя его иногда можно уговорить отказаться от проекта, показав его низкие оценки;
- другие индивидуальные оценки проектов: приведенная выше система расчета привлекательности проектов является быстрой и простой, в силу этого не учитываются ряд факторов, их надо рассматривать для каждого проекта:
- экономическая эффективность проектов;
- риски, если не выполнить конкретный проект;
- срочности проектов (срочные проекты надо или сразу выполнять даже при их невысокой привлекательности, или же совсем не выполнять).
Готовность вашей ИТ-службы и других сотрудников выполнить эти проекты (например, у вас может не быть нужных специалистов);
- совместимость с другими проектами и т.д.
Для уточнения привлекательности проектов целесообразно сделать таблицу соответствия между проектами и целями ИТ и бизнеса. В рамках более сложных ИТ-стратегий для всех проектов по ИТ надо пересчитывать их соответствие целям ИТ, сокращая проекты, которые хуже других позволяют достичь целей бизнеса и ИТ.
Рассмотренная методика оценки привлекательности проектов является простой и быстрой, за счет отказа от расчета финансовых характеристик окупаемости проекта (ROI, ТЭО и др.).
Соответственно, эту методику можно использовать для сравнения и выбора проектов из множества возможных, но не обязательных.
Можно снизить риски невыполнения проекта, увеличив время, требуемое на выполнение проекта. Например, можно внедрять не все модули ERP сразу, а поочередно, а также не во всех филиалах, а по частям.
Мой опыт показывает, что увеличить выгоды от проекта на 20-30% или сократить затраты на него, как правило, совершенно реально. Хотя придется потратить на это некоторое время.
Практика планирования проектов в России и других странах показывает, что сроки выполнения большинства (или всех) проектов затягиваются. А вот связи между проектами остаются неизменными.
Разработка проектов по ИТ
Совсем по минимуму, даже в простой ИТ-стратегии, для каждого проекта по ИТ надо «написать и согласовать с заинтересованными лицами» основные характеристики проекта:
1. Цели проекта;
2. Основные этапы выполнения проекта;
3. Оценки проекта:
- выгоды для бизнеса и ИТ;
- затраты (человеко-дней работы своих сотрудников и выплаты другим компаниям);
- риски выполнения проекта;
- длительность проекта;
- итоговой приоритет (привлекательность) проекта.
4. Зависимости от других проектов;
5. Сроки выполнения проекта;
6. Ответственные за данный проект.
Пример описания конкретного проекта по внедрению документооборота приведен на Табл. 12:
Табл. 12. Пример описания проекта по ИТ. Проект №1 Внедрение системы электронного документооборота на базе 1С: Документооборот
| Текущая ситуация: Приказы, распоряжения, протоколы готовятся в офисных программах; подписываются, регистрируются канцелярией; сканируются и рассылаются по электронной почте или размножаются в бумажном виде. Цели: упорядочить работу сотрудников с документами, исключить возможность утери версий или пересечения фрагментов при одновременной работе; повысить контроль исполнения приказов, распоряжений и протоколов; сократить время поиска нужной информации и суммарное время коллективной обработки документов; повысить качество готового материала (проектов, документации и пр.) за счет решения большого количества спорных вопросов и упорядочивания работы пользователей. Предполагаемые выгоды: «1С:Документооборот» решает задачи автоматизации учета документов, взаимодействия сотрудников; централизованного безопасного хранение документов; оперативного доступа к документам с учетом прав пользователей; контроль версий документов, работа с документами любых типов. Планируемые сроки: Начало проекта: 2 квартал Продолжительность: 3 – 4 месяца | Этапы работ: — Покупка программы и сервера — Настройка ПО и рабочих станций — Обучение персонала 300 чел. — Настройка программы — Сопровождение и доработка по результатам эксплуатации Приоритет: — Средний Требуемые ресурсы: 100 тыс.руб. и 4 человеко-месяца своего программиста Зависимость от других проектов: — Нет |
Сколько проектов стоит планировать?
Какими бы большими (или маленькими) ни были проекты, вряд ли целесообразно рассматривать портфель из более чем 50 проектов, по максимуму, до 70-100.
ИТ-службы больших предприятий одновременно могут выполнять десятки и сотни работ, которые можно рассматривать как самостоятельные проекты.
Однако, в силу ограниченности людей, вряд ли стоит планировать портфель на 150 проектов. Более целесообразным выглядит объединение проектов в группы так, чтобы все группы помещались на одном слайде или странице текста.
Вот мои оценки типового числа проектов по ИТ, рассматриваемых при разработке ИТ-стратегии средней или крупно-средней по размеру компании (от 1 до 20 тысячи пользователей ИТ):
- 20-50 уже выполняемых проектов;
- 30-70 проектов по «затыканию дыр» в текущем состоянии ИТ (с учетом различных вариантов проектов);
- 30-70 проектов по переходу в требуемое состояние ИТ (с учетом вариантов).
Итого получилось 80-200 возможных проектов.
На этапе выбора проектов целесообразно:
- Выявить необязательные проекты с низкими выгодами, высокими затратами и/или высокими рисками. Эти проекты можно не учитывать в дальнейшем выборе проектов на год вперед. Так стоит отсеять минимум треть проектов;
- Еще треть проектов со средненькими характеристиками и низкими затратами можно попробовать учесть в проектах с высокими выгодами;
- Далее стоит оставить 15-40 проектов, пытаясь увязать их с этапами развития ИТ в вашей компании.
7. Бюджет ИТ
Что рассматривается в ИТ-стратегии
Бюджет ИТ обычно является наиболее дискутируемой частью ИТ-стратегии. Мой опыт работы с сотней генеральных директоров говорит, что руководители компании могут тратить на ИТ существенно больше (как на 10%, так и на 100%), однако, сотрудники ИТ не могут предложить понятных и выгодных для бизнеса проектов.
То есть абсолютные затраты на ИТ обычно высоки, экономия их на 5-10% может составлять стоимость хорошей легковой машины (для средней по размеру компании и за один год. Для крупных компаний – за месяц, или даже неделю). Однако, все затраты на ИТ обычно не превышают 1-2% от оборота компании, поэтому для генерального директора есть и множество других направлений сокращения затрат.
Директора компаний, которые учатся у меня в Академии Народного Хозяйства, в качестве зачета по курсу «ИТ для бизнеса» проводят диагностику текущего состояния и планирование ИТ для своих компаний. Удивительно, но после такой работы, две трети гендиректоров приходят к выводу, что затраты на ИТ надо увеличивать.
При этом для каждого приоритета бизнеса (повышение доходов, снижение затрат, снижение рисков, рост бизнеса и т.д.) надо было определить проекты по ИТ, поддерживающие эти цели бизнеса. Почти у всех генеральных директоров получалось, что текущие проекты по ИТ слабовато поддерживают реальные цели бизнеса. Это и неудивительно, так как часто цели бизнеса или отсутствуют, или непонятны для ИТ (например, «улучшить рентабельность на 3%» или даже «Достичь целевого показателя по EBITDA»).
В ИТ-стратегии желательно рассмотреть несколько бюджетов ИТ:
- Бюджет ИТ на год;
- Бюджет ИТ на 2-5 лет вперед;
- Бюджет отдельных проектов.
Бюджет ИТ на год
Бюджет на год вперед, по-хорошему, и должен представлять собой реальный план всех расходов на ИТ на год. Многие компании разрабатывают ИТ-стратегии, чтобы обосновать бюджет ИТ. В большинстве организаций обсуждение бюджетов на следующий год заканчивается не 31 декабря, а осенью, а то и в августе. Соответственно, и разработку ИТ-стратегии целесообразно планировать за 4, а лучше за 6 месяцев до крайнего срока согласования бюджетов.
В бюджете на год целесообразно рассмотреть расходы по ИТ на каждый месяц.
Бюджет ИТ на 2-5 лет вперед
Это, скорее, декларация о намерениях, чем реальный бюджет. План расходов на 2-5 лет нужен, чтобы согласовать с бизнес-руководством размер затрат на ИТ в целом, учтя при этом российскую и международную статистику по предприятиям вашей отрасли, а также планируемый рост бизнеса (или прогноз его отсутствия). В бюджете надо учесть наиболее крупные проекты по ИТ. Расходы целесообразно рассматривать поквартально, ну или хотя бы по годам.
Бюджет отдельных проектов по ИТ
Такие бюджеты можно рассматривать для нескольких самых крупных проектов по ИТ, особенно если эти проекты занимают более одного года. Примерами таких проектов могут быть внедрения CRM или ERP для крупных предприятий со множеством филиалов и партнеров. Также обязательно стоит разрабатывать бюджеты самых дорогих проектов, например, создания своего ЦОДа.
Бюджет ИТ на год
В бюджете ИТ на год вперед (обычно это следующий календарный год), целесообразно по месяцам расписать затраты как на проекты по ИТ (переменные затраты), так и на постоянные (операционные) расходы (зарплату сотрудников ИТ, оплату электричества, расходы на помещения и т.д.). Хотя постоянные затраты обычно больше затрат на проекты, основное время при разработке ИТ-стратегии уходит на разработку плана проектов по ИТ и его привязки к имеющимся людским и финансовым ресурсам.
Эта задача является простой, с точки зрения ее постановки, но очень непроста с точки зрения нахождения оптимальных решений для конкретной компании в конкретный период времени. Также сильна зависимость от конкретных людей, особенно ИТ-директора (который обычно разрабатывает план проектов по ИТ и ИТ-бюджет) и гендиректора (и/или финансового директора), которые утверждают ИТ-бюджет, часто не с первого раза.
Разработка и плана проектов по ИТ, и ИТ-бюджета требуют большого опыта, который может позволить сильно повысить качество и/или снизить затраты. Пример оптимизации плана проектов по ИТ, с точки зрения оптимизации под имеющиеся финансовые и человеческие ресурсы, приведен на Рис. 22:
Рис. 22 План проектов на год и требуемые ресурсы: первая прикидка
Видно, что имеющиеся ресурсы или недоиспользуются, или же их недостаточно (например, загрузка своего персонала в месяцы 4 и 5 превышает потенциально имеющиеся 100%). Работа по планированию проектов с учетом имеющихся ресурсов не является простой и требует скорее опыта, чем использования какого-то программного обеспечения.
Из программ, в которых я бы рекомендовал проводить планирование ИТ-бюджета, можно отметить:
- Visio или MS Project для составления графика проектов;
- Excel или любые другие электронные таблицы для оценки затрат ресурсов (надо бы загрузку всех основных групп специалистов выполнить, на Рис. 163 совсем упрощенный пример). В программах типа MS Project планировать ресурсы, в принципе, можно, но вряд ли целесообразно составить там ИТ-бюджет на год, как минимум у меня это получалось плохо.
На Рис. 23 представлен пример плана проектов, лучше оптимизированный под имеющиеся ресурсы:
Рис. 23 План проектов на год и требуемые ресурсы: вторая прикидка
Видно, что проведенной на Рис. 23 оптимизации внешних выплат и загрузки своего персонала недостаточно, но этот вариант лучше первой прикидки на Рис. 22.
В среднем, по небольшим российским предприятиям, которые я видел, выполняется только треть проектов из запланированных на следующий год. Треть проектов вообще «убивается», а треть отодвигается на неопределенный срок. Это говорит об очень высоком потенциале улучшения планирования ИТ.
Бюджет ИТ на 2-5 лет
В ИТ-бюджете на несколько лет вперед надо запланировать, сколько денег в ближайшие годы планируется потратить на:
- проекты (или переменные затраты, то есть то что вы можете сдвинуть по времени или вообще отменить);
- операционные затраты по ИТ (то есть то, что вы не можете не платить, например, зарплата и аренда помещений. Хотя, постепенно можно менять и эти затраты);
- плановые обновления технических средств, а также и другие заранее понятные (и существенные) расходы по ИТ.
Пример итогового слайда по ИТ-бюджету на несколько лет вперед приведен на Рис. 24:
Рис. 24 Пример бюджета ИТ на несколько лет вперед
При планировании ИТ-бюджета на Рис. 24 предполагалось, что затраты на ИТ будут расти примерно вполовину от роста бизнеса. То есть, если бизнес за год планирует вырасти на 10%, то расходы на ИТ целесообразно планировать на 5% больше, чем в прошлом году.
Конечно, при планировании ИТ-бюджета может быть множество тонких моментов, в том числе связанных с тем, какой именно процент бюджета отводить на проекты, какой на текущую поддержку. В соответствии с лучшими международными практиками, считается, что если на проекты по ИТ уходит менее 20% ИТ-бюджета, то это не очень хорошо. Лучше, когда на ИТ-проекты идет 40-50% бюджета, при этом можно более гибко приспосабливать ИТ-бюджет к быстроменяющимся потребностям компании и рыночным условиям.
Бюджет отдельных проектов по ИТ
Единого понимания, что такое «бюджет проектов по ИТ» нет. Под этим могут понимать как просто сумму внешних выплат, так и десятки страниц расходов и финансового обоснования целесообразности каждого из проектов по ИТ.
Конечно, желательно по каждому из рассматриваемых проектов по ИТ иметь как Техническое задание страничек на 20-30, так и подробный бюджет. Но если проектов по ИТ не один, не два, а полсотни, а расчетов ROI, ТЭО или других финансовых обоснований проектов по ИТ в вашей компании никто пока почему-то не делал, стоит начать с постепенной оценки затрат и возможных выгод от наиболее крупных и/или важных проектов по ИТ.
8. Варианты развития ИТ: а вы их рассматриваете?
В рамках ИТ-стратегии могут быть проведены сравнения различных вариантов развития ИТ. На мой взгляд, целесообразно рассмотреть 2-4 варианта развития ИТ. Вот примеры вариантов возможных изменений, которые потом несколько лет вперед сильно влияют на ИТ в целом:
- существенные решения по инфраструктуре ИТ, например, строительство своего ЦОДа. Или, вместо ЦОДа, аренда места в чужом ЦОДе под свои сервера. Или вообще отказ от собственных серверов и ЦОДов (за счет аренды вычислительных мощностей у ИТ-компаний);
- существенные изменения в информационных системах, например, внедрение единой интегрированной информационной системы. Или переход от ERP собственной разработки к типовому решению;
- существенные изменения в управлении ИТ, например, передача сотрудников службы поддержки ИТ (вместе с самой поддержкой) на аутсорсинг;
- существенные изменения в бизнесе, например, объединение с крупным конкурентом или быстрый рост (или падение) числа своих филиалов. Или требование бизнеса по сокращению затрат на ИТ на 5%. Или на 10%. Или на 20%…;
- существенные изменения во внешней среде. Простой пример – кризис 2014 года, во время которого курс рубля упал в два раза по отношению к доллару (печаль в том, что цены почти на все технические средства, а также на многие программы, установлены в долларах).
Принятие альтернативных решений по развитию ИТ, например, из перечисленных выше, может существенно влиять на все элементы ИТ. Целесообразно просчитывать возможные последствия принятия подобных серьезных решений, которые могут приводить к разным вариантам развития ИТ.
«Изначально, когда мы делали проект по ИТ-стратегии, у меня был определенный скепсис по поводу необходимости разработки различных сценариев развития. Мне казалось, что нам и так все понятно и мы однозначно понимаем, куда двигаться. И это несмотря на то (а может быть, как раз, именно поэтому), что требования бизнеса к ИТ мы сформулировали практически самостоятельно, бизнес в этом участвовал неактивно. Однако на защите на стратегическом комитете неожиданно выяснилось, что генерального директора очень интересуют разные сценарии развития (прежде всего, с точки зрения затрат). И нам пришлось срочно придумывать три сценария (минимальный, оптимальный и максимальный), один из которых (угадайте, какой) в итоге и был одобрен. Так что разработка различных сценариев лишней не будет».
Гордеев Станислав, зам.директора, начальник отдела связи и инфраструктуры ООО «ММК-Информсервис» (Группа «Магнитогорский металлургический комбинат»)
Конечно, при сравнении вариантов развития ИТ для конкретной компании в конкретный момент времени надо учитывать разные критерии, но есть и типовые: соответствие бизнесу; соответствие ИТ; затраты (см. Табл. 13):
Табл.13. Сравнение вариантов развития ИТ
| Критерии сравнения | Вариант 1 | Вариант 2 | … | Вариант N |
| Соответствие бизнесу | ||||
| Соответствие ИТ | ||||
| Затраты |
Возможная детализация критериев рассмотрена ниже.
Соответствие бизнесу можно поделить на:
- соответствие стратегии развития бизнеса;
- соответствие организационной структуре компании и пользователям ИТ (в т.ч. их квалификации по работе с ИТ);
- соответствие бизнес-процессам;
- и т.д.
Соответствие целям ИТ можно поделить на:
- соответствие целям ИТ на несколько лет вперед (или ИТ-стратегии, если она уже есть. В данном случае предполагается, что варианты развития ИТ сравниваются в рамках работ по разработке ИТ-стратегии, т.е. готовой ИТ-стратегии нет);
- соответствие информационным системам;
- соответствие инфраструктуре ИТ;
- соответствие оргструктуре ИТ-службы и персоналу ИТ (в т.ч. их квалификации);
- соответствие ИТ-процессам;
- и т.д.
Затраты можно поделить на:
- начальные затраты на переход к каждому варианту;
- затраты на ежегодную поддержку каждого варианта.
Для каждого из вариантов развития ИТ надо определить, какая должна быть инфраструктура ИТ, справятся ли сотрудники, что нужно будет делать с информационными системами, сколько денег на это потребуется. Более того, могут быть и разные подварианты: например, оргструктуры — можно или выполнять работы силами своих сотрудников, или кому-то передать на аутсорсинг. То есть, получается дерево вариантов. При этом как в шахматах: чем больше вариантов просчитать, тем больше вероятность выбора оптимального в данном случае варианта. Хотя вряд ли серьезно рассмотреть более 2-5 вариантов развития ИТ.
При рассмотрении вариантов очень желательно иметь как опыт разработки вариантов развития ИТ, так и знать планы развития конкурентов вашей компании.
«В процессе долгосрочного обучения по ИТ-стратегии, в котором приняли участие все руководители структурных подразделений службы ИТ были пересмотрены стратегические цели ИТ на среднесрочную перспективу. Учитывая, что в предыдущие годы акцент был на внедрение новых ИТ-процессов и информационных систем, в следствие чего у конечных пользователей наступил процесс «насыщения и усталости» от изменений в их бизнес-процессах, было решено пересмотреть цели в сторону повышения надежности и непрерывности ИТ-сервисов, сокращения времени реакции на обращение в службу ИТ как по поводу доработок, так и по поводу устранения инцидентов.
В результате удалось сформировать и реализовать за год пул из 14 проектов по ИТ. В части повышения надежности ИТ-инфраструктуры был реализован проект обеспечивающий дублирование ЦОДа, что позволило обеспечить наличие кластерной реализации всех ИТ-сервисов и приложений, которые используются на предприятии. Разработан и внедрён стандарт по разработке ПО как собственными силами, так и с привлечением аутсорсеров. Используя в работе данный стандарт удалось сформировать программу ИТ-проектов на 3-5 лет, по доработке используемых ИТ-сервисов и внедрением новых с учетом потребностей бизнеса.
В части управления персоналом ИТ-службы были реализованы проекты по стандартизации процессов управления ИТ. Это в свою очередь повлекло изменение в структуре службы, распределении компетенций и ответственности каждого из подразделений».
Чернов Виталий, ИТ-директор компании «КНГФ»
Пример сравнения вариантов развития ИТ
Табл. 14. Пример сравнения вариантов развития ИТ: соответствие критериям
| Критерии сравнения | Вариант 1 (старая банковская система) | Вариант 2 (новая российская банковская система) | Вариант 3 (зарубежная банковская система) |
| Соответствие бизнесу | |||
| Стратегии бизнеса | M | H | H |
| … | |||
| Соответствие ИТ | |||
| Целям ИТ | M | H | M |
| Информационным системам | M | M | L |
| Инфраструктуре ИТ | H | H | L |
| Оргструктуре ИТ-службы | H | H | M |
| ИТ-процессам | H | M | L |
| … | |||
| Затраты | |||
| Начальные затраты | низкие | средние | высокие |
| Ежегодная поддержка | высокие | средние | высокие |
Обозначение: «L»: низкий уровень соответствия «M»: средний уровень; «H»: высокий уровень
Табл.15. Пример сравнения вариантов развития ИТ: итоговые оценки
| Критерии сравнения информационных систем | Вариант 1: (старая банковская система) | Вариант 2 (новая российская банковская система) | Вариант 3 (зарубежная банковская система) |
| Cоответствие бизнесу | M | H | H |
| Соответствие ИТ | M/H | M/H | L/M |
| Затраты | средние | средние | высокие |
Судя по Табл. 14 и Табл. 15, более выигрышным выглядит вариант 2.
Хотя если смотреть только с точки зрения гендиректора (критерий «Соответствие бизнесу»), то вариант 3 тоже выглядит хорошо.
А с точки зрения ИТ-директора, хороши варианты 1 и 2.
9. Портфель проектов по ИТ
Хорошие характеристики проектов (например, выгоды больше затрат и низкие риски) — не единственная причина включения проектов в план проектов по ИТ. Уже было рассмотрено, что может быть ряд проектов, обязательных для выполнения, несмотря на их характеристики, возможно и очень плохие. К таким проектам можно отнести требования вышестоящих организаций, налоговых органов, гендиректора и т.д.
Также надо учитывать, что проекты, характеристики которых сейчас выглядят плохо, через год-другой, а то и ранее, могут быть весьма выигрышными. Могут постепенно расти как выгоды от проектов, так и снижаться и затраты, и риски их выполнения. Хотя, улучшения сами по себе могут не произойти, надо не забрасывать плохие на текущий момент времени проекты, чтобы вовремя идентифицировать благоприятные для их осуществления факторы. Например, не исключено, что подвернется хорошее помещение для своего ЦОДа, или ИТ-компании предложат в конце года серьезные скидки на технические и программные средства.
На мой взгляд, при планировании проектов по ИТ, особенно в рамках ИТ-стратегий хотя бы на сотню страниц, целесообразно не только выявить проекты, которые попадут в план на следующий год, но и целую иерархию групп проектов, которые можно назвать портфелем проектов по ИТ, см. Рис. 25:
Рис. 25. Пирамида групп проектов в портфеле проектов по ИТ
Рассмотрим основные группы проектов в возможном портфеле проектов по ИТ на несколько лет вперед. Предложенная классификация является точкой зрения автора этой книги.
Обязательные к выполнению проекты:
- требования государства;
- требования акционеров и гендиректора;
- обязательные для ИТ проекты.
Базовый портфель проектов (очень желательные проекты):
- проекты с хорошим соотношением выгод к затратам и низкими рисками;
- соответствующие целям ИТ и бизнеса;
- укладывающиеся в бюджет ИТ (и свои силы).
Расширенный портфель проектов (хорошо бы сделать, если будет хватать времени и денег): проекты с плохим (пока) соотношением выгод к затратам, а также проекты с высокими рисками.
Портфель потенциальных проектов (пока не актуальные проекты): проекты, не соответствующие пока текущим целям ИТ и бизнеса.
Рассмотренные выше предложения соответственно групп проектов конкретным критериям сведены в Табл. 16:
Табл. 16. Группы проектов по ИТ в портфеле проектов
| Группы проектов | Соответствие требованиям государства и акционеров | Соответствие целям бизнеса и ИТ | Выгоды от проекта больше затрат на него, низкие риски | Затраты на проект укладываются в бюджет ИТ |
| 1. Обязательные проекты | √ | |||
| 2. Базовый портфель проектов | √ | √ | √ | |
| 3. Расширенный портфель проектов | √ | ∼ | – | |
| 4. Портфель потенциальных проектов | ∼ | ∼ | – |
10. Этапы развития ИТ
На практике непросто составлять оптимальный план даже на несколько десятков проектов, а на пару сотен проектов – почти нереально. Имеется в виду, что сложно составить реально выполнимый и достаточно экономный с точки зрения ресурсов план, хотя просто связать между собой в заранее заданную последовательность несложно и несколько сотен проектов.
Опыт разработки планов на год и более показывает, что планировать лучше одновременно как с начала периода планирования, так и с конца, чтобы успеть выполнить все обязательные проекты.
Планы проектов разрабатывают люди, потому надо учитывать, что человек способен одновременно удерживать внимание на не более чем 7 объектах. Даже если план проектов составляет гений, способный оперировать одновременно и 9 объектами, то план будет смотреть и множество других людей. Соответственно, получается, что оптимально спланировать можно до 7 проектов, хотя в плане проектов по ИТ почти любой компании, проектов – десятки, а то и сотни.
Один из вариантов решения этой дилеммы – разбить план проектов на отдельные блоки, в каждом из которых будет не более 7 проектов. И самих блоков – не более 7 (ну или матрица, например, 3*3). Эти предложения соответствуют рекомендациям, принятым в разных областях, в том числе в описании бизнес- и ИТ-процессов.
Можно вначале выделить 2-5 четких этапов развития ИТ (каждый длительностью в полгода-год), а потом привязать проекты к этим этапам (см. Табл. 17):
| Этап 1 (например, частичная централизация ИТ) | Этап 2 (например, полная централизация ИТ) | Этап 3 (например, оказание информационных услуг другим компаниям) | |
| Информационные системы | – 2-5 проектов | – 2-5 проектов | – 2-5 проектов |
| Инфраструктура ИТ | – 2-5 проектов | – … | – … |
| Управление ИТ |
11. Планирование проектов по ИТ
Определение планов проектов по ИТ является самым первым этапом разработки ИТ-стратегии:
Рис. 26. Место проектов по ИТ в ИТ-стратегии
Разработка ИТ-стратегии подробно рассмотрена в моей 450-страничной книге «ИТ-стратегия: лучший международный и российский опыт«.
План проектов по ИТ также являются и последним этапом этапом разработки стратегии цифровой трансформации бизнеса:
Рис. 27. Место проектов по ИТ в стратегии цифровой трансформации бизнеса
Разработку ИТ-стратегии (а также стратегии цифровой трансформации бизнеса) лучше делать в несколько этапов: сначала разработать основу ИТ-стратегии (параллельно с аудитом ИТ), а потом доработать что получилось до полноценной ИТ-стратегии или стратегии цифровой трансформации бизнеса.
Рис. 28. Этапы разработки ИТ-стратегии развития (вариант а)
Также ИТ-стратегию (и стратегию цифровой трансформации бизнеса) можно разработать как традиционный консалтинговый проект, в три этапа:
- Анализ текущего состояния ИТ
- Разработка требуемого через несколько лет состояния ИТ
- Планирование проектов по ИТ
Рис. 29. Этапы разработки ИТ-стратегии (вариант б)
12. Типовые варианты планирования проектов по ИТ на 1 год и более
Рекомендации в зависимости от того, что надо улучшать:
- если план проектов по ИТ уже есть, лучше провести аудит выполнения требований к ИТ.
Аудит должен дать независимую оценку, адекватен ли план проектов по ИТ в вашей компании. Вряд ли вашей компании надо работать также четко как Google, IBM и другие ИТ-компании, но надо быть не хуже ваших основных конкурентов. - если есть возможность, лучше также спланировав развитие на 1-3 года всех остальные элементов ИТ (информационные системы, инфраструктура, управление ИТ) в рамках совместной с консультантами разработки ИТ-стратегии.
- если гендиректор вашей компании обеспокоен (или наоборот, воодушевлен) цифровой трансформацией бизнеса, то запланировать развитие оргструктуры ИТ-службы (да и всех основных элементов ИТ) можно в рамках разработки стратегии цифровой трансформации бизнеса (или его первого шага — стратегии создания единой цифровой платформы бизнеса).
А вот рекомендации в зависимости от размеров компаний:
- для малых компаний вряд ли уместен консалтинг по разработке планов проектов по ИТ. Однако, может быть уместен вариант обучения по ИТ-стратегии с параллельной разработкой ИТ-стратегии, все работы могут быть уместны и по стоимости и по количеству;
- для средних компании уместен аудит выполнения требований к ИТ, а также совместной с консультантами разработки ИТ-стратегии.
- для крупных компаний уместен любой консалтинг, с учетом всех особенностей компании.
|
||||||||||||||||||
