Как встроить процессы управления ИТ в систему управления компанией или Почему не удается «жить по COBIT и ITIL. Измерение и оценка ИТ-процессов

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

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

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

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

Большой объем требуемой информации и специфичность задачи анализа процессов для их дальнейшей оптимизации требуют применения специальных информационных систем для процессного анализа - Process Intelligence. По мнению Gartner, появление систем класса Process Intelligence является тенденцией, которая объясняется большой востребованностью инструментов бизнес-анализа, касающихся именно совершенствования деятельности. Особенность данного инструментария заключается в том, что в его основу положена структура процесса и весь сбор данных идет с ее учетом, что позволяет максимально быстро перейти от анализа данных к совершенствованию процесса.

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

Рис. 1. Process Intelligence - портал руководителя ИТ-подразделения

Совершенствование процессов ИТ-подразделения

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

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

Для организации сбора аналитики по «фактическому» процессу необходимо определить в нем основные контрольные точки, процессные показатели и аналитические разрезы (рис. 2).

Рис. 2. Показатели и аналитические разрезы для ИТ-процессов

При этом число точек контроля зависит от уровня автоматизации процесса - чем он выше, тем больше информации о процессе можно использовать для дальнейшего анализа. С показателями по процессам все гораздо проще, ведь большинство из них сформулировано в библиотеке ITIL. Число процессов, время реакции на инцидент, среднее время обработки инцидента, загрузка сотрудников Service Desk - все эти показатели нужно и можно контролировать с помощью инструментария Process Intelligence. Что касается аналитических разрезов, то тут основными являются следующие:

приоритет инцидента/изменения;
название сервиса;
срочность инцидента/изменения;
участник процесса;
категория инцидента/изменения;
отчетный период.

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

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

Рис. 3. Анализ процесса по различным разрезам

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

Особенность инструментария процессного анализа как раз заключается в том, что он дает возможность «увидеть» те процессы, которые выполняются в информационных системах. Например, инструмент ARIS Process Performance Manager (ARIS PPM) компании IDS Scheer может сформировать модели на основе информации о процессах, содержащейся в информационных системах, что позволяет скорректировать регламенты и определить различия между целевой моделью и фактической ситуацией (рис. 4). Возможность «восстановления» процесса в ARIS PPM помогает найти лучшие и худшие его варианты, осуществить бенчмаркинг процессов в различных подразделениях, найти «зависшие» экземпляры процессов.

Рис. 4. ARIS PPM - восстановление процесса

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

Организационный анализ

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

Рис. 5. Результаты организационного анализа в ARIS PPM

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

Заключение

Инструментарий Process Intelligence позволяет увидеть узкие места процессов и обеспечить оптимизацию процессов без снижения их качества, что может стать основой для сокращения затрат.

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

управление инцидентами;
управление проблемами;
управление изменениями;
управление запросами на предоставление сервисов;
управление уровнем сервиса.

Практика выполненных проектов показывает, что применение инструментария Process Intelligence дает возможность сократить время выполнения процессов на 15-20% при одновременном уменьшении стоимости на 10-12%.

/ Классификация процессов ИТ

Одноклассники

Марина Аншина , президент фонда ФОСТАС, председатель Комитета по стандартам Российского Союза ИТ-директоров

Классификация процессов ИТ

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

Кроме того, классификация позволяет построить системную модель предметной области, что дает возможность взглянуть на предмет исследования и более точно и более широко. Именно поэтому мы рассмотрим возможности классификации процессов ИТ и попробуем разглядеть ряд особенностей, которые помогут нам их лучше понять и управлять ими более эффективно. Конечно, самые известные классификации процессов ИТ связаны с двумя столпами – с сервисным подходом, представленным ITSM и ITIL, и методикой руководства и управления ИТ COBIT, о которых уже говорилось в первой статье этого цикла.

Классификация процессов в ITSM и ITIL

ITSM предлагает выделить пять групп процессов ИТ:

Выравнивание ИТ и бизнеса. Стратегические вопросы и взаимодействие с пользователями. Управление этими процессами осуществляется в тесном контакте с бизнес-руководством и обычно находится под непосредственным руководством или хотя бы пристальным контролем CIO.
Операционная деятельность. Ликвидация сбоев и управление операциями. Эта группа процессов посвящена организации безаварийного предоставления сервисов, причем управление инцидентами и управление проблемами – к реактивным методам, а операционное управление включает и проактивные компоненты.
Обеспечение предоставления сервисов. Управление конфигурациями, изменениями и уровнем сервиса. Что есть, как это изменяем, и как с контролируем то, что предоставляем пользователям.
Управление и проектирование сервисов – безопасность, непрерывность, доступность, производительность и финансирование. Обеспечение необходимого качества сервисов в соответствии с потребностями бизнеса.
Разработка и внедрение сервисов – создание и тестирование, установка релизов сервисов в продуктивную среду. Название говорит само за себя, эти процессы позволяют развивать ИТ-сервисы в соответствии с потребностями бизнеса и изменениями внешней среды.

Соответствующая картинка ITSM была приведена в первой статье, но вдруг вы ее не видели или забыли. Поэтому распределение процессов по группам приведено ниже на рис. 1.

ITIL версии 2, структура которой приведена на рис. 2, сосредоточилась на двух группах процессов:

Поддержка сервисов (Service Support):

Сервис-деск.
Управление инцидентами.
Управление проблемами.
Управление конфигурациями.
Управление изменениями.
Управление релизами.

Предоставление сервисов (Service Delivery):

Управление финансами для ИТ-сервисов.
Управление доступностью.
Управление уровнем сервиса.
Управление непрерывностью ИТ-сервисов.
Управление взаимоотношениями с клиентами.

Кроме того, в ней выделяются следующие группы:

Перспектива бизнеса (уже никто апостериори ничего не выравнивает):

Управление непрерывностью бизнеса.
Партнерство и аутсорсинг.
Трансформация бизнеса с помощью изменений.

Управление программными приложениями:

Управление жизненным циклом разработки ПО.
Тестирование ИТ-сервисов.

Управление инфраструктурой информационно-коммуникационных технологий:

Процессы проектирования и планирования.
Процессы внедрения.
Операционные процессы.
Процессы технической поддержки.

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

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

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

ITIL версии 3 выделяет пять групп процессов, приведенных на рис. 3.

Стратегия сервисов

Обеспечивает руководство проектированием, разработкой и внедрением управления ИТ-сервисами не только в рамках операционной деятельности, но также рассматривая их как стратегический актив. Эта группа процессов отвечает на вопрос «зачем?» и является определяющей для остальных групп, которые в большей степени отвечают на вопрос «как?». Во время создания ITIL версии 3 такая постановка вопроса и выделение этой группы процессов, несомненно, расширяло традиционной подход к ИТ как к сугубо вспомогательному направлению деятельности. Как быстро меняются нравы и привычки, особенно связанные с ИТ! Сейчас это уже несколько устаревшие взгляды, ведь ИТ достаточно быстро становится основой развития самых разных организаций. В эту группу входят следующие процессы:

Управление финансами.
Управление спросом.
Управление портфелем сервисов.

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

Проектирование сервисов

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

Управление уровнем предоставления сервисов.
Управление каталогом услуг.
Управление производительностью.
Управление доступностью.
Управление непрерывностью.
Управление безопасностью.
Управление поставщиками.

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

Развитие сервисов

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

Управление изменениями.
Управление конфигурациями.
Управление релизами.
Управление знаниями.

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

Эксплуатация сервисов

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

Управление инцидентами.
Управление проблемами.
Сервис-деск.
Управление доступом.

Хочу обратить ваше внимание, что классификация ITIL v3 помещает процессы управления доступом и доступностью в разные группы и, соответственно, в разные книги.

Непрерывное улучшение сервисов

В соответствии с классическими практиками процессного управления в третьей версии появилась эта группа процессов управления качеством. Общеизвестно, что даже самым лучшим образом спроектированные процессы теряют качество по мере использования, если не заниматься их качеством специально. Основой для этой деятельности служит цикл Деминга Plan-Do-Check-Act (PDCA), описанный в предыдущей статье. Это следующие процессы:

Улучшение сервисов.
Отчетность.
Измерение сервисов.
Управление уровнем сервиса.

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

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

Классификация процессов в COBIT

Особенностью COBIT является четкое разграничение процессов руководства (governance) и управления (management). В соответствии с COBIT версии 5 «руководство заключается в обеспечении: определения баланса и согласованности потребностей заинтересованных сторон, условий и возможностей при достижении целей предприятия; задания направления развития через приоритизацию и принятие решений; а также отслеживания результативности и соответствия согласованному направлению и целям». В свою очередь, «управление планирует, создает, использует и отслеживает деятельность в соответствии с направлением, установленным руководством для достижения целей предприятия».

Пресловутые трудности перевода заключаются в том, что оба термина (governance и management) часто переводятся одинаково, и понять, что имелось в виду, можно только поконтексту. Что в данном случае по вполне понятным причинам не так просто.

Ключевые области руководства и управления согласно COBIT 5 приведены на рис. 4. В процессы руководства, а именно оценки, задания направления и мониторинга входит пять процессов, а в процессы управления, разделенные на четыре подгруппы (координация, планирование и организация; мониторинг, оценка и анализ; разработка, приобретение ивнедрение; предоставление, обслуживание и поддержка), соответствующие областям ответственности подразделений ИТ, – 32.

На рис. 5 приведена классификация процессов ИТ по COBIT 5. Да простят меня апологеты ITIL, но с моей точки зрения эта классификация более системна и логична. Хотя и тут есть очевидные пересечения. В частности, обеспечение прозрачности тесто связано с процессом мониторинга, а оптимизация рисков – с безопасностью.

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

Классификация по ISO/IEC 38500-2008 «Корпоративное руководство информационными технологиями»

Стандарт основан на ряде принципов, из которых можно вывести классификацию, приведенную на рис. 6.

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

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

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

Некоторые полезные варианты классификации

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

Архитектурная классификация. Это самый простой и очевидный вариант классификации, компоненты которого мы видели выше. В зависимости от архитектурной модели, вы делите процессы на группы по областям избранной модели, не забывая о связи между этими слоями, которые в хороших архитектурных моделях всегда формализованы.
Классификация по типу управления: стратегическая и операционная; аутсорсинг и инсорсинг; проектная и процессная деятельность, основные и обеспечивающие процессы, специфические для отрасли бизнеса и общие. Такая классификация присутствует практически во всех описанных выше видах. Существующая тут опасность состоит в отрыве отдельных областей группировки друг от друга, поэтому ее лучше использовать вместе с другими видами при построении матричной или многомерной классификации.
По типу жизненного цикла: например, стабильные, нестабильные и средние процессы. Такая классификация полезна при формировании методики управления изменениями.
По типу финансирования, способу распределения затрат. Такая классификация весьма полезна в финансовом управлении процессами ИТ.
По уровню зрелости (после оценки по COBIT, например). Такая классификация подойдет для выбора стратегии развития процессов и построения сбалансированных ИТ.

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

03.05.2012 23:40 Роман Журавлев

16039 прочтений

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

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

— Затраты на информационные технологии рациональны и контролируются.

— Риски, связанные с использованием информационных технологий, контролируются и сведены к приемлемому уровню.

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

Эти виды деятельности объединены и направляются с помощью системы управления, подразумевающей:

— определенные цели и задачи;

— закрепление за определенным лицом ответственности за функционирование процесса;

— документированные политики, планы и процедуры, обеспечивающие повторяемость процесса;

— ясно распределенные роли и ответственность;

— системную деятельность по повышению эффективности процесса.

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

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

Зачем измерять и оценивать процессы

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

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

— Обеспечивает ли система управления необходимые возможности управления информационными технологиями?

— Обеспечивают ли ИТ-менеджеры соответствие системы управления текущим требованиям заказчиков и условиям деятельности?

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

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

Что и как измерять и оценивать?

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

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

Под назначением процесса здесь понимается роль процесса в системе управления, то есть ответ на вопрос «зачем нужен этот процесс, за что он отвечает?». Приведем несколько примеров.

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

Назначение процесса управления проблемами - повышение надежности ИТ-сервисов за счет предотвращения повторов инцидентов посредством определения и устранения корневых причин их возникновения.

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

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

Эти формулировки универсальны, мало меняются от компании к компании, и их можно найти - как правило, под заголовком «цель процесса» - в стандартах и сводах знаний, предлагающих процессные модели управления ИТ. В первую очередь это COBIT, ITIL, ISO 20000.

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

Оценка уровня зрелости обычно выполняется с использованием так называемых «моделей зрелости» (maturity models). Модели зрелости могут быть самостоятельными сводами знаний или входить в состав других сводов знаний и стандартов. Наиболее известной является модель CMM. Она же была принята за основу при разработке модели зрелости процессов управления ИТ, вошедшей в состав COBIT (до версии 4.1 включительно).

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

В свою очередь, гарантия сервиса - это «гарантия того, что продукт или сервис будут соответствовать согласованным требованиям. (…) Гарантия характеризует возможность сервиса быть доступным тогда, когда он нужен, иметь необходимую мощность и надежность (в части безопасности и непрерывности). Гарантия - это то, "как сервис предоставляется", она может использоваться для определения соответствия условиям использования сервиса».

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

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

Цель определяет, что должен обеспечить процесс в некоторый фиксированный отрезок времени. Например,

— для управления инцидентами это может быть «обеспечить увеличение доли своевременно решённых инцидентов до 95%» или «довести долю обращений, обработанных на первой линии, до 30%» и так далее;

— для управления проблемами - «обеспечить долю проблем, диагностика которых выполнена в срок, до 100%», «свести к нулю число известных ошибок, описания которых потребовали доработки в связи с выявленными неточностями»;

— для управления уровнем обслуживания - «обеспечить 100-процентную полноту и актуальность каталога ИТ-сервисов, предоставляемых заказчикам», «организовать систематическую оценку критических ИТ-сервисов», «обеспечить исполнение плана улучшения сервисов на уровне не менее 95%»;

— для процесса управления конфигурациями - «взять под контроль процесса 100% новых устройств в соответствии с утвержденным планом идентификации», «обеспечить корректность данных в CMDB на уровне не менее 90%», «обеспечить предоставление информации о конфигурациях по запросу в сроки, определенные регламентом процесса» и т.д.

Цели должны соответствовать критериям SMART (specific — конкретность, measurable — измеримость, achievable — достижимость, realistic — реалистичность, time-bound — ограниченность во времени). Цели удобно формулировать с использованием глаголов совершенного вида. Цели не только могут, но и должны пересматриваться; актуальность целей процесса - один из признаков высокого уровня его зрелости.

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

Оценка результативности выполняется на основе значений показателей результативности (в некоторых версиях COBIT они так и назывались - Key Goal Indicators, ключевые показатели достижения целей). Эти показатели формируются на базе метрик, собираемых во время работы процесса. Если цели процесса определены верно и соответствуют принципу SMART, а потенциал процесса обеспечивает возможность их достижения, то вероятно, что сбор метрик и расчет значений показателей не станут для менеджера процесса нерешаемой задачей. Результативность может измеряться и оцениваться на уровне отдельных видов деятельности, процессов и системы управления в целом.

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

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

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

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

— стоимость владения системой автоматизации процессов управления ИТ;

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

— затраты на услуги консультантов и других внешних специалистов по управлению ИТ;

— затраты на обучение участников процессов, информирование и мотивацию.

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

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

— потенциал - функциональные возможности системы;

— зрелость - способность системы к стабильной реализации возможностей и развитию при изменении требований и условий;

— результативность - фактические достижения системы за период;

— рациональность - фактическая себестоимость системы управления в сравнении с формируемой ею

ценностью.

В оценке потенциала и зрелости заинтересованы владельцы системы управления и потребители результатов её работы; в оценке результативности и рациональности - менеджеры, ответственные за функционирование системы и формирование результатов.

Что такое «хорошо» и что такое «плохо»?

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

Потенциал системы управления ИТ . Должен обеспечивать реализацию ИТ-стратегии, поэтому основным источником критериев для оценки выступает именно стратегический план ИТ. Но для его составления, а также для определения требований к потенциалу отдельных процессов полезно использовать авторитетные своды знаний и стандарты. Для ИТ-процессов это прежде всего COBIT и ISO 20000. Цели контроля, приведенные в COBIT для каждого процесса (всего более 300), как и требования стандарта к процессам управления ИТ-сервисами - прекрасный ориентир для того, кто решает задачу планирования процессов управления ИТ. А своды знаний по управлению ИТ, в первую очередь - ITIL, содержат огромный объем информации о возможностях процессов управления ИТ, бесценной для тех, кто уже знает, что должны уметь делать его процессы, и хочет узнать подробности.

Зрелость системы управления ИТ и отдельных процессов . Также детально охарактеризована в COBIT. Кроме того, не следует пренебрегать рекомендациями собственно CMMI - специализированные модели CMMI for services, CMMI for development, CMMI for Acquisition и People CMMI могут послужить источником полезной информации о критериях - и не только зрелости, но и потенциала. Разработчик моделей зрелости, Институт программной инженерии Университета Карнеги-Меллон, также периодически собирает информацию о значениях зрелости процессов, действующих в различных отраслях. Эти данные можно найти на сайте института (http://www.sei.cmu.edu/cmmi/solutions/appraisals/). Однако основным источником требований к зрелости системы управления ИТ, как и к ее потенциалу, должна стать ИТ-стратегия. Кроме рекомендаций названных авторитетных источников, при её формировании следует принимать во внимание требования законов и других регуляторов.

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

Критерии для оценки рациональности . Также определяются ИТ-директором. Цели в области рациональности системы управления ИТ должны поддерживать политики и планы компании.

Подведем итоги

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

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

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

Возможности

Достижения

Рис. Области измерения и оценки процессов управления ИТ

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

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

Оценка потенциала и результативности дает ответ на вопросы «Что процесс может?» и «Что процесс сделал?» Оценка зрелости и рациональности — на вопросы «Как процессы управляется?» и «Как они поработали?»

Получившаяся структура помогает ответить на множество вопросов: кому, что и зачем оценивать? Откуда брать критерии оценки? Чем потенциал процессов отличается от их зрелости? Для чего применять ISO 20000, для чего — COBIT, а для чего ITIL? И в результате - спланировать и реализовать эффективную систему управления ИТ.

Роман Журавлев ([email protected]) — директор по развитию персонала компании Cleverics.

Измерение и оценка ИТ-процессов. Стройная теория и проектная практика

Подробности 05 февраля 2013

Как обеспечить комплексную систему измерения процессов управления информационными технологиями? Кто является потребителем результатов измерения и для чего они используются? Попробуем найти ответы на эти вопросы, объединяя стройную теорию с передовой проектной практикой.

ИТ-процессы

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

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

Зачем и для кого выполняются измерение и оценка

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

Таким образом, измерение и оценка ИТ-процессов выполняются в интересах двух основных групп заинтересованных лиц (stakeholders):

инвесторов, заказчиков, высшее ИТ-руководство, внешних регуляторов интересует:
- в какой степени система управления ИТ решает поставленные задачи (результативность / effectiveness );
- предусмотрены ли и как действуют управленческие механизмы, обеспечивающие должный уровень контроля и изменения системы в ответ на новые требования (соответствие / compliance );
ИТ-менеджеров интересует текущее состояние процессов с точки зрения:
- содержания и результатов деятельности, а также объёма работ (продуктивность / productivity );
- рациональности использования ресурсов (рациональность / efficiency ).

Что и как измерять и оценивать

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

Результативность ИТ-процессов (effectiveness)

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

назначение определяет роль процесса в системе управления, то есть ответ на вопрос «зачем нужен этот процесс, за что он отвечает ». Назначение процесса, как правило, более-менее универсально, то есть мало меняется от компании к компании. Формулировки назначений для ИТ-процессов можно найти в стандартах и сводах знаний, предлагающих процессные модели (COBIT , ITIL® , ISO/IEC 20000);
цель процесса определяет, что должен обеспечить процесс в некоторый фиксированный отрезок времени. Цели должны соответствовать критериям SMART (specific, measurable, achievable, relevant, time-bound). В отличие от назначения, цели процесса не только могут, но и должны регулярно верифицироваться и пересматриваться, что является ответственностью владельца процесса.

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

Пример 1. Управление инцидентами и запросами пользователей:
Назначение: обеспечение качества ИТ-услуг за счёт скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание.
Примеры целей:

увеличение доли своевременно решённых инцидентов до 95%
увеличение доли обращений, решённых на первой линии, до 50%

доля инцидентов и запросов, решённых в срок [%]
среднее время решения инцидентов в разбивке по уровню влияния [час]

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

довести уровень удовлетворён¬ности заказчиков качеством ИТ-услуг до 90%
обеспечить своевременность формирования отчётов по ИТ услугам на уровне 100%

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

интегральный показатель качества ИТ-услуг (рассчитывается по отчётам о предоставлении ИТ-услуг за период) [%]
уровень удовлетворённости заказчиков качеством ИТ-услуг (рассчитывается по результатам опроса заказчиков за период) [%]

Степень соответствия ИТ-процессов требованиям (compliance)

зрелость процесса – характеристика, позволяющая оценить насколько тщательно и формально в рамках процесса контролируются входящие в его состав виды деятельности;
зрелость системы управления или зрелость организации характеризует практику контроля, действующую в организации в отношении процессов.

Capability Maturity Model (CMM) , разработанная Software Engineering Institute of Carnegie Mellon University. Эта модель была принята за основу при разработке модели зрелости процессов в составе COBIT (до версии 4.1 включительно);
ISO/IEC 15504 «Information technology – Process assessment» . Эта модель была принята за основу при разработке модели зрелости процессов управления ИТ, вошедшей в состав новой – пятой – версии COBIT.

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

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

Рациональность использования ресурсов (efficiency)

Результативность процессов обеспечивается за счёт использования ресурсов организации, расходуемых на исполнение процессов и обеспечение их зрелости. Контроли – как специализированные, так и универсальные – используют информацию, приложения, инфраструктуру и персонал. Метрики рациональности характеризуют количество ошибок, возникающих при исполнении процесса, а также использование тех или иных механизмов сокращения трудозатрат.

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

Продуктивность процесса (productivity)

Метрики продуктивности характеризуют объём работ по исполнению и контролю процесса. Это очень важный фактор и на этапе проектирования, и на этапе исполнения процесса. Например, при проектировании процесса управления изменениями важно понимать, какой поток изменений ожидается, прежде чем записать в регламент процесса «Все изменения рассматриваются на CAB (Change Advisory Board, комитет по управлению изменениями) ». На этапе исполнения изменение входного потока процесса может влиять на показатели его результативности, степени соответствия и рациональности. Например, увеличение потока инцидентов с 8 000 до 15 000 в месяц (за счёт неудачного внедрения новой ИТ-системы) может существенно снизить значение метрики результативности «Доля инцидентов и запросов пользователей, решённых в срок ». Поэтому показатели продуктивности также должны включаться в рассмотрение при выполнении оперативного контроля и оценки процессов.

Структура и принципы реализации системы измерения и оценки

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

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

На практике при реализации системы измерения и оценки важно соблюдать ряд правил:

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

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

Виктор Голубев

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

Компании ведущих стран мира, действительно, сегодня выделяют управление ИТ в отдельную область знаний (IT Governance). Разработан международный стандарт управления ИТ-процессами: Control Objectives for IT and reated Technology (COBIT). При этом в COBIT акцентируется, что управление ИТ – это ответственность совета директоров компании, а не отдельных менеджеров или директора по ИТ. Откуда на западе такое внимание к ИТ-процессам? Главная причина в том, что большинство компаний там публичные. А значит, акционеры хотят понимать, как предприятие работает и расходует средства. Всплеск интереса к IT Governance, как направлению, не случайно произошел именно после принятия в США закона SOX (Sarbanes-Oxley), определяющего необходимость для публичной компании иметь систему внутреннего контроля, за которую несут персональную ответственность генеральный и финансовый директора. Аналогичные законы приняты в Японии, Швейцарии, готовится «европейский SOX». Другими словами, перед руководителями бизнеса встала угроза штрафов и даже тюремного заключения за искажение информации, и с этого момента они начали проявлять интерес к тому, как организованы в их компаниях процессы внутреннего контроля. Конечно, в том или ином виде система контроля существовала во всех публичных компаниях и до SOX, но аудиторы SOX стали требовать не просто наличия инструкции, а формализованных, утвержденных и подписанных процедур внутреннего контроля, прозрачных и понятных процессов, документированных результатов деятельности и документальных подтверждений «правильной» работы. Как говорится, «все ходы должны быть записаны», и тут оказалось, что 85 % процессов внутреннего контроля прямо или косвенно связаны с ИТ. Даже если контролируется не ИТ, а бизнес-область, то либо процессы реализуются с помощью ИТ-систем, либо используют их информацию.

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

Почему в России вопросы управления ИТ по-прежнему «выпадают» из системы корпоративного управления?

Причина, прежде всего, в низкой зрелости систем управления (как в области ИТ, так и компании в целом). Если говорить о сфере ИТ, то первым показателем степени «зрелости» выступает схема подчинения ИТ-директора в структуре управления компанией. В «зрелой» структуре он подчиняется первым лицам организации. А в России нередко руководитель ИТ-службы подчинен или финансовому директору (когда роль ИТ воспринимается, как автоматизация бухгалтерии), или главному инженеру (поскольку в ведении ИТ – широкий парк оборудования), или даже директору по персоналу… Такое подчинение отражает позицию ИТ-директора: это, по сути, главный системный администратор, который не участвует ни в разработке бизнес-стратегии, ни в принятии принципиальных для бизнеса решений, а возможности и ограничения ИТ не рассматриваются топ-менеджерами компании с точки зрения развития ее деятельности.

Такая недооценка ИТ – объективно существующая на нашем рынке ситуация, и все проблемы развития ИТ-сферы обусловлены именно этой причиной. В том числе, и восприятие директора ИТ-службы как технического специалиста, который должен лучше всех разбираться в базах данных, сетевых решениях, мобильных технологиях, уметь настраивать 1С, поддерживать Web-сайт, «и прочая и прочая»… Но ИТ-директор – это в первую очередь стратег, определяющий направление развития («дирекция» = направление!). А ИТ-стратегия – это проекция бизнес-стратегии на область ИТ, точно так же, как маркетинговая стратегия или стратегия продаж. И если ИТ-директор не имеет возможности донести до первого лица компании свои идеи, и его информация проходит через других менеджеров (как правило, в искаженном виде – каждый из топ-менеджеров имеет свои представления об ИТ и решает свои политические задачи) – в результате ИТ-сфера так и остается для руководителя компании «черным ящиком», в который уходят, непонятно зачем, немалые средства.

Еще один показатель зрелости системы управления – принцип принятия решений. В западной публичной компании системный администратор не может заказать новый сервер просто потому, что «тот мощнее и вообще крутой». На все должно быть бизнес-обоснование. Правило, что «ИТ-проектов не существует, существуют бизнес-проекты с ИТ-составляющей», – известно уже много лет, но ни руководители российских компаний, ни директора по ИТ его не применяют. Вообще, до тех пор пока бизнес не видит, как на него могут повлиять информационные технологии, и, соответственно, ИТ не влияют на бизнес, – в принятии решений по ИТ главной останется «царева воля», а ИТ-подразделение будет восприниматься как «обслуживающее», причем вызывающее по большей части раздражение у функциональных бизнес-руководителей. Потому что все дороже, все сложнее, все менее гибко. На вопрос «Можно?», ИТ-директор говорит: «Нет, нельзя». На вопрос «Сколько?» – «Не знаю, дорого!». На вопрос «Когда?» – «Не сейчас». И ни о каком взаимном понимании между бизнесом и ИТ речь не идет.

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

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

Как начать изменения к лучшему?

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

Объективно в большинстве российских компаний сейчас нет потребности в таком управлении ИТ. Она появится только тогда, когда бизнес станет реально публичным. Тогда возникнет и необходимость выполнять требования стандартов. Например, если компания хочет котироваться на американском фондовом рынке, у нее должен быть сертификат SOX, а, в отличие от других сертификатов, которые нередко у нас, по сути, покупаются, попытка купить сертификат SOX бесперспективна. Есть примеры, когда российская компания выходила на американский рынок, а через полгода уходила – очень дорого поддерживать процедуры контроля. Это известный факт: для того чтобы поддерживать искусственным образом процедуры внутреннего контроля в компании, штат нужно даже не удвоить, а утроить. Есть только один путь – выстраивание работы в соответствии с этими правилами и стандартами. Не случайно сейчас на западе очень популярны три взаимосвязанных направления – IT Governance (управление ИТ как таковое), Enterprise Architecture (архитектура предприятия, обеспечивающая сквозную взаимосвязь от бизнес-стратегии, через бизнес-процессы, ИТ-приложения до ИТ-инфраструктуры) и Governance Risk & Compliance (управление рисками и соответствиями).

Однако применение всех этих методик бессмысленно, если роль ИТ не считается значимой. Поэтому сейчас единственно возможный путь для руководителя ИТ-службы – начинать доказывать свою полезность бизнесу. Работать на удовлетворение задач локальных заказчиков. И стараться постепенно «воспитывать» бизнес-заказчика. Какова вообще роль ИТ-директора, кроме того, что он Менеджер, и его задача – набрать нужный персонал и не мешать ему работать? Его вторая важная роль – он Переговорщик между ИТ и бизнесом. Он «еще помнит» проблемы ИТ, их ограничения, и уже знает, что нужно бизнесу.

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

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

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

Так что же делать? Ждать и кропотливо работать на достижение зрелости компании и зрелости ИТ. Это совместный процесс. Тут как в медицине – исцеление начинается с того момента, когда больной понимает, что он болен. По Gartner, нулевой уровень зрелости процессов – это когда компания понимает, что в ее хозяйстве не все в порядке. Вот с этого момента начинается работа по повышению «зрелости» системы управления и управления ИТ, в частности. И задача руководителя по ИТ – понимать бизнес-стратегию и требования, предлагать ИТ-стратегию для эффективной реализации бизнес-стратегии, работать над совершенством процессов, как бизнеса так и ИТ, стать Директором не по названию, а по сути – драйвером процессов преобразования в компании.