Звоните: +7 (495) 517-57-25

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

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

1. Издержки на ИТ-усовершенствования часто не соизмеримы с результатами.

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

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

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

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

2. Проекты часто оказываются слишком громоздкими и долгими ещё из-за того, что ПО дополняется ненужными функциями.

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

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

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

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

3. Приобретённые ранее приложения и инфраструктура часто не используются в полной мере.

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

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

4. Вероятность неудачи слишком высока.

  • Сократите длительность каждой стадии проекта. Разбейте проект на мелкие этапы — чем меньше задача каждого, тем меньше риск и выше вероятность успеха.
  • Установите «критерии остановки» проектов (например, проект следует остановить, если первоначальный бюджет изменялся дважды, а до пилотной версии дело так и не дошло).

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

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

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

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

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

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

  • Возьмите пример с Intuit — введите штрафы за «беспомощные» звонки в службу поддержки.

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

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

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

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

7. ИТ-менеджеры слишком боятся рисковать: «Никого ещё не увольняли за покупку продуктов IBM или Microsoft».

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

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

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

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

Олег Скрынник

Эту и другие статьи вы можете загрузить в формате Acrobat Reader PDF в файловом архиве.