Типовые российские подходы к планированию проектов по ИТ - ИТ-стратегии: публикации, обучение, консалтинг

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

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

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

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

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

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

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

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

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

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

Пример плана проектов по ИТ: вариант 1, факт рис. 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.

Пример плана проектов по ИТ: вариант 2, план Рис.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.

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

Результаты третьей попытки планирования:

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

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

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

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

Вот основные изменения:

а) Почти для всех проектов добавлены резервы времени, из расчета 30% на каждый проект. На аренду ЦОД и перенос в него серверов решили выделить еще больше резервов времени, учитывая, что в этом проекте должно участвовать несколько внешних организаций (как владелец ЦОДа, так и компания, которая будет прокладывать выделенные линии связи к ЦОДу);

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

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

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

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

Результаты четвертой попытки планирования:

На выполнение проекта по ERP времени ушло на 20% больше. Однако резерв времени был запланирован. А в разработанной до этого ИТ-стратегии удалось четко определить требуемые доработки ERP и согласовать их со всеми подразделениями;
Разработку SLA начали на три недели позже. Однако часть SLA удалось разработать в ИТ-стратегии;
Аренду ЦОДа решили выполнить раньше планового срока, так как предыдущие проекты уже были выполнены;
Внедрение CRM завершилось на месяц позже. Но резервы под это были запланированы.

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

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

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

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

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

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

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

Вот сравнение рассмотренных вариантов планирования проектов (см. таблицу 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
Х	√	√	√	√	√	√	8 / 9	4

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

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

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