Майский номер ежемесячника Harvard Business Review за 2009 год содержит довольно любопытную заметку, озаглавленную «Правда об ИТ-бюджете». Автор, Сюзан Крамм, основатель и президент компании Valuedance, приводит рекомендации по управлению ИТ-бюджетом в кризисных условиях. Многие из этих советов выглядят достаточно интересно, и их анализ может быть полезен лицам, принимающим решения о составе и размере бюджета ИТ-подразделения.

Кратко рассмотрим тезисы Сюзан, сравнивая их с реальностью российского рынка.

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

Второй совет, про фиксирование размера ИТ-бюджета, звучит слишком жёстко. Можно допустить, что в некоторых компаниях такие меры будут оправданы. С другой стороны, идеального планирования не бывает, и точность порядка ±10% может быть вполне допустимой. Представляется более разумным не отсекать все попытки пересмотра бюджета, но рассматривать каждый случай в отдельности, анализируя причины и размер запрашиваемой к пересмотру суммы, а также последствия и риски, связанные с остановкой или замедлением работ.

Есть и ещё одна опасность, встречающаяся на практике — некоторые руководители декларируют жёсткие правила, но на практике регулярно позволяют себе от них отступать. В этом случае их подчинённые довольно быстро понимают реальные «правила игры», и декларируемые ограничения перестают кого-то смущать. Лучше уж иметь правила, которые работают.

Включение бизнес-заказчиками в проект каждой функции, которую только можно себе представить, долго было нормой жизни. «Если уж делать, то делать хорошо/надолго/полностью/…». В то же время есть исследования, показывающие, что во многих случаях используется лишь небольшая, до 30-40%, часть функционала.

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

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

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

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

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

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

Ещё более странная рекомендация, которая могла придти в голову только тому, кто не знаком с общепринятыми источниками передового опыта — ITIL, ITSM, COBIT и аналогичными. Во-первых, менеджеры должны разбираться в бизнес-процессах, а не в программном обеспечении; в то время как ПО должно помогать их работе, а не возводить новые барьеры и доставлять сложности.

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

В тех же случаях, когда обращение в Service Desk неизбежно, любая заявка будет классифицироваться как инцидент, в то время как во многих случаях можно было бы обойтись категорией «запрос на консультацию» — обычно такие запросы обрабатываются быстрее и дешевле, чем инциденты.

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

Очень здравый совет, однако не стоит забывать про риски. Бесплатного сыра не бывает, и у каждого из приведённых решений есть своя цена. Не всегда её можно определить сразу же, зачастую последствия изменений будут видны позже. И когда в середине года ИТ-менеджер поймёт, что погорячился, продлив срок службы сервера до 10 лет и расторгнув контракт на его поддержку, он может запросто встретиться с рекомендацией № 1 — «Бюджет израсходован — значит, израсходован».

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

Автор: Олег Скрынник.