Главная » Недвижимость » Ит-процессы в действии. Методология PRM IT

Ит-процессы в действии. Методология PRM IT

В определенный момент развития компании руководство ИТ-подразделения может столкнуться с ситуацией, когда решение инцидентов занимает слишком много времени, пользователи оказываются недовольны предоставляемыми услугами, а внутренняя организация работы представляет собой полный хаос. Одним из вариантов решения этих проблем является внедрение ITSM (Information Technology Service Management). В рамках этого поста, которым мы решили открыть свой блог на Хабре, мы поговорим о том, что такое ITSM, и рассмотрим некоторые возможности платформы ServiceNow.

Что такое ITSM?

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

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

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

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

Реализация ITSM - ServiceNow

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

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

Это позволяет применить модель ITSM для финансовой службы, HR, службы кадров, маркетинга, а также с помощью единой платформы управлять аналитикой, разработкой, ресурсами, проектами и прочими направлениями бизнеса. А также для типовых ITSM-практик, например, обработки запросов пользователей. Далее, мы рассмотрим несколько решений, которые позволяет применить SaaS-платформа ServiceNow.

Управление ИТ и управление рисками (GRC)

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

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

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

Второе приложение - это Policy and Compliance Management, и оно обеспечивает централизованный процесс создания и управления политиками, стандартами и процедурами внутреннего контроля. Например, модуль Compliance содержит обзорную информацию о соответствиях, а также списки официальных документов и ссылок компании.

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

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

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

Управление разработкой ПО (Agile Development)

Платформа ServiceNow также включает в себя приложения для гибкой разработки. Решение ServiceNow Agile Development (SDLC) позволяет управлять методами гибкой разработки Scrum при работе над программным обеспечением и его сопровождением на протяжении всего жизненного цикла. Приложение Agile Development представляет собой последовательный процесс для среды разработки программного обеспечения.

Платформа дает возможность проводить ежедневные совещания (Daily Scrum) с членами команды с целью обсуждения текущих проектов, запланированных работ и затруднений. Здесь также имеется возможность вести бэклог продукта, представляющий собой список пользовательских историй, упорядоченных по степени важности. Product Backlog можно регулярно просматривать и дополнять по мере появления новых требований и пересмотра приоритетов.

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

Управление ИТ-инфраструктурой (IT Operations Management)

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

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

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

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

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

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

В последние годы появляется множество публикаций о подходах к управлению ИТ-сферой, рекомендациях 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, нулевой уровень зрелости процессов – это когда компания понимает, что в ее хозяйстве не все в порядке. Вот с этого момента начинается работа по повышению «зрелости» системы управления и управления ИТ, в частности. И задача руководителя по ИТ – понимать бизнес-стратегию и требования, предлагать ИТ-стратегию для эффективной реализации бизнес-стратегии, работать над совершенством процессов, как бизнеса так и ИТ, стать Директором не по названию, а по сути – драйвером процессов преобразования в компании.

Наверное, большинство консультантов по ИТ занимается улучшением ИТ-процессов. Только в Москве таких консультантов тысячи [по России, наверное, и десять тысяч специалистов по ИТ-процессам можно насчитать. А людей, способных разработать осмысленную ИТ-стратегию, хорошо если сотни. А на заказ и для крупных предприятий ИТ-стратегии, на мой взгляд, могут разработать человек десять по всей России]. Но, несмотря на все это, в ИТ-стратегии ИТ-процессам обычно отводится достаточно скромное место – от одного слайда до пары страниц текста детального проектирования процессов.

ИТ-процессы в рамках ИТ-стратегии

Вот составляющие ИТ-процессов, обычно рассматриваемые в рамках ИТ-стратегии:

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

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

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

Методологии проектирования и контроля ИТ-процессов

Методологий для анализа и проектирования ИТ-процессов достаточно много, на Рис. 1 представлены только основные из них:

Рис. 1. История развития методологий по ИТ-процессам

Конец 1970-х годов: Information Systems Management Architecture (ISMA), IBM;
Конец 1980-х: IT Infrastructure Library V1 (ITIL), OGC;
1995: IT Process Model (ITPM), IBM;
1996: COBIT (Control Objectives for Information and Related Technology);
2000: IT Service Management Reference Model (ITSM), HP;
2000: Microsoft Operations Framework (MOF), Microsoft;
2001: IT Infrastructure Library V2 (ITIL), OGC;
2005: Process Reference Model for IT, IBM;
2005: COBIT V4;
2007: ITIL 3.0.

Первые методологии по ИТ-процессам разработала компания IBM. Не все знают, что IBM не поддерживала ITIL v1 и v2, но в разработке третьей версии ITIL участвовали как специалисты IBM, так и HP, и Microsoft (можно проверить, посмотрев список авторов книг по ITIL v3).

Я изучал все рассмотренные на Рис. 109 методологии, кроме ISMA, эта методология уже лет двадцать как устарела. На мой взгляд, методология PRM IT разработки IBM сейчас лучшая. Как для проектирования ИТ-процессов, так и для разработки ИТ-стратегий. Проблема в том, что эта методология отсутствует в открытом доступе. Кроме того, ITIL v3 стал уже стандартом де-факто в России, да и во многих других странах.

Рассмотрим процессные методологии более подробно.

Методология COBIT

Методология Control Objectives for Information and Relates Technology (COBIT) была разработана для контроля ИТ-процессов. Международные финансовые корпорации строили на базе COBIT системы контроля работ по ИТ. Хотя эти финансовые корпорации обанкротились во время кризиса 2007 года из-за того, что неправильно вели бизнес, а также плохо контролировали действия своих брокеров, вряд ли причиной этого была методология COBIT.

Сейчас COBIT развивает Ассоциация Аудита и Контроля Информационных Систем (ISACA). В COBIT (версия 5) выделены процессы как поддержки, так и планирования развития ИТ (см. Рис. 2):

Рис. 2. Типовые процессы ИТ в COBIT

В COBIT есть множество показателей по каждому из ИТ-процессов:

Модель зрелости (Maturity model);
Критические факторы успеха (KSF);
Показатели достижения результата (KGI);
Показатели исполнения (KPI).

COBIT: модель зрелости процессов ИТ

Для оценки текущих и требуемых через 1-2 года уровней зрелости ИТ-процессов я рекомендовал бы использовать модель зрелости на базе COBIT v4 (см. Табл. 1):

Табл. 1. Шкала оценки уровней зрелости ИТ-процессов

Уровень зрелости		Описание
	Не существует (Non-Existent)	Полное отсутствие каких-либо процессов. Организация не понимает, о чем идет речь.
	Начальный (Initial)	Организация понимает, о чем идет речь, и что это необходимо. Не существует стандартизованного процесса. Присутствуют определенные подходы, применяемые от случая к случаю. Управление не организовано.
	Повторяемый (Repeatable)	Процессы разработаны до степени, когда люди, выполняющие одну задачу, используют похожие процедуры. Ответственность не прописана, отсутствует обучение. Высокая степень зависимости от знаний конкретных людей.
	Определенный (Defined)	Процессы стандартизованы и документированы, проводится обучение. Отклонения маловероятны, хотя их соблюдение оставлено на усмотрение персонала. Процессы являются формализацией существующей практики и не оптимизированы.
	Управляемый (Managed)	Возможность контролировать и измерять выполнение процессов и применять меры там, где процессы не эффективны. Процессы постоянно улучшаются и могут быть автоматизированы.
	Оптимизованный (Optimized)	Процессы доведены до соответствия лучшим практикам и основаны на результатах сравнения с другими организациями. Обеспечивается быстрая адаптация к изменяющимся условиям. Процессы автоматизированы и согласованы с другими процессами.

Данная шкала удобна своей простотой и тем, что похожа на оценки в российской школе. Шкала достаточно согласована [при оценке уровня зрелости в шкале COBIT версии 4 не было консалтинговых подколок, типа «если у вас нет миссии ведения процесса», то уровень зрелости уже будет не более троечки. Однако, в версии 5 все поменялось, уровень зрелости ИТ-процессов очень многих российских организаций может быть оценен как чрезвычайно низкий] .

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

Рис. 3. Модель зрелости процессов ИТ

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

COBIT: использование в ИТ-стратегии

Вот мои оценки применимости COBIT при разработки ИТ-стратегий:

В России COBIT используется весьма редко, особенно для проектирования ИТ-процессов. Полнота покрытия выделенными в COBIT процессами, всех работ по ИТ не выше, чем в ITIL. Однако, ITIL более распространен в России, соответственно саму модель процессов COBIT в ИТ-стратегии, полагаю, использовать нет смысла;
Шкала оценок уровней зрелости ИТ-процессов в COBIT удобна для использования в ИТ-стратегиях [на мой взгляд, в COBIT v4 шкала понятнее, чем в v5. А также существенно меньше и «разводит» на заказы консалтинга по увеличению уровней зрелости ИТ-процессов в случаях, когда у вас всего-то не написаны «видение» и «миссия» процесса] . Важным достоинством шкалы оценки зрелости ИТ-процессов является ее простота, понятность, а также интуитивное соответствие российской школьной шкале оценок. Соответственно, я бы рекомендовал в ИТ-стратегии, при оценках текущего и требуемых уровней зрелости ИТ-процессов, использовать шкалу COBIT.

Третья версия методологии Information Technology Infrastructure Library (ITIL v3) сейчас является стандартом де-факто как в России, так и во многих других странах мира. По ITIL есть как доступная литература, так и обучение, и консалтинг.

Методология создана по инициативе правительства Великобритании в 1989 году (во времена Маргарет Тэтчер). Толчком для ее создания послужила приватизация и оптимизация госслужб. На этой волне была предпринята попытка оптимизации госучреждений и осуществлено их сравнение с компаниями, успешно работающими в рыночных условиях. 20 лет назад это был достаточно революционный подход.

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

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

Для начала 90-х годов эта идея была достаточно нова. Для российского бизнеса идея оказания услуг как внешним заказчикам, так и другим подразделениям подразделениями компании, нова и сейчас. Попробуйте в вашей бухгалтерии и отделе кадров проверить качество и своевременность их услуг. Или про SLA их спросите.

Недавно появилась и новая область использования в методологии ITIL — для бизнеса, например, для оптимизации работ строительных бригад РЖД по ремонту железных дорог. Планирование этих работ было оптимизировано с использованием ITIL.

На Рис. 4 представлен перечень процессов ITIL v3, с разбивкой по фазам жизненного цикла:

Рис. 4. Процессы ITIL v3

ITIL: использование в ИТ-стратегии

Применимость ITIL при разработке ИТ-стратегий я оценил бы следующим образом:

ITIL в России, да и в других странах, используется очень часто, особенно при проектировании ИТ-процессов. Однако полнота покрытия выделенными в ITIL ИТ-процессами реальных работ по ИТ не особенно велика. Процессы поддержки ИТ рассмотрены подробно, но вот с развитием ИТ плоховато. Например, процесс по разработке и поддержке ИТ-стратегии в ITIL просто отсутствует. А группы процессов в ITIL выделены, на мой взгляд, неполно.
Соответственно, если у вас при автоматизации Help Desk использована методология ITIL (а это встречается очень часто), то вроде бы и в ИТ-стратегии использовать ITIL целесообразно, чтобы спланировать развитие ИТ-процессов на год-два. Однако, если рассмотреть в ИТ-стратегии все процессы ITIL, то времени это займет много, да и в глазах будет рябить. То есть в стратегиях, которые вы сами хотите разработать за месяц другой, все процессы рассматривать вряд ли имеет смысл. А группы процессов в ITIL не покрывают весь спектр работ по ИТ, то есть только группы ИТ-процессов рассматривать тоже смысла нет;
Есть разные шкалы в ITIL, используемые для оценки уровней зрелости ИТ-процессов, в т.ч. совсем подробные или не совсем корректные. Например, по некоторым рекомендуемым на сайтах по ITIL опросникам выходит, что если у вас нет видения и миссии конкретного ИТ-процесса, то и уровень зрелости этого процесса будет ниже плинтуса. Собственно, я бы не рекомендовал при разработке ИТ-стратегии использовать рекомендации ITIL для оценок уровней зрелости ИТ-процессов.

Методология PRM IT

Методология Process Reference Model for IT (PRM IT) является весьма полной и внутренне согласованной методологией компании IBM. Перечень процессов PRM IT приведен на Рис. 5:

Рис. 5. Процессы PRM IT

Работая в IBM, я разработал ряд ИТ-стратегий, где была использована методология PRM IT. На мой взгляд, методология PRM IT удобней и лучше как для разработки ИТ-стратегий, так и для проектирования ИТ-процессов — она самая полная. В методологии есть ряд процессов, и она существенно больше покрывает работы по ИТ, чем ITIL и COBIT. Однако это перечеркивается тем, что компания IBM не предоставляет эту методологию в открытом доступе.

PRM IT: использование в ИТ-стратегии

Применимость PRM IT при разработке ИТ-стратегий я бы оценил так:

Модель PRM IT очень полная: 30 лет на разработку и отсутствие совместимости с предшествующими методологиями все-таки позволили разработать полную и понятную процессную методологию. Но, учитывая, что IBM не распространяет описание процессов PRM IT, на мой взгляд, в ИТ-стратегии стоит планировать только группы процессов PRM IT.
Шкалы оценок уровней зрелости ИТ-процессов в PRM IT широкой публике скорее не известны, и COBIT скорее проигрывают.

В 1999 году корпорация Microsoft начала собственные разработки по адаптации ITIL к особенностям эксплуатации информационных систем на базе собственных технологий. В результате на свет появились рекомендации, изложенные в библиотеке документов Microsoft Operations Framework (MOF).

Если у вас все построено на Microsoft, и вы уже внедрили MOF, то ИТ-процессы можно планировать и на базе методологии MOF.

Модель процессов MOF включает в себя 21 функцию управления услугами, сгруппированную по четырем квадрантам:

Поддержка (supporting);
Эксплуатация (operating);
Изменения (changing);
Оптимизация (optimizing).

Рис. 6. Методология MOF

На мой взгляд, сейчас в России проектирование процессов на 90% проводится на базе ITIL, а MOF почти не используется.

MOF: использование в ИТ-стратегии

Полнота покрытия ИТ-процессами MOF всех работ по ИТ невелика. Соответственно, и в ИТ-стратегиях MOF имеет смысл использовать, только если ваша организация уже давно и существенно использует MOF, а не ITIL или COBIT.

Сравнение процессных методологий

MOF ориентирована на поддержку продуктов Microsoft, вряд ли целесообразно использовать эту методологию для разработки ИТ-стратегии;
COBIT скорее ориентирован на контроль, а не на планирование развития ИТ-процессов. В России COBIT распространен существенно меньше, чем ITIL. Соответственно, вряд стоит использовать COBIT для разработки ИТ-стратегий;
ITIL сейчас де-факто является стандартом ИТ-процессов. Соответственно, и в ИТ-стратегиях появляется желание использовать ITIL. Однако, при этом надо каким-то образом выделить рассматриваемые в ИТ-стратегии процессы (или их группы), запланировать развитие всех 20-30 процессов будет сложно;
PRM IT, на мой взгляд, лучше других подходит для долгосрочного планирования ИТ в рамках ИТ-стратегий. Однако, в отличие от ITIL, PRM IT используется только внутри IBM и для клиентов этой компании.

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

шкалу для оценки уровней зрелости ИТ-процессов – из COBIT v4;
группы ИТ-процессов, требования к уровням зрелости которых вы будете согласовывать с бизнес-руководством вашего предприятия – из PRM IT;
перечень ИТ-процессов, если вы собираетесь все их спланировать, лучше взять из ITIL v3. Однако, если вы и ИТ-стратегию и планирование ИТ-процессов делаете в первый раз, то я не рекомендовал бы пробовать рассматривать сразу все ИТ-процессы, так как на обе работы вас не хватит.

С чего начинать улучшение ИТ-процессов: с выбора программы их автоматизации?

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

Рис. 7. Последовательность проектирования и автоматизации ИТ-процессов

Анализ и проектирование ИТ-процессов в рамках ИТ-стратегий

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

Весьма распространенная форма оценки имеющегося и требуемого уровней зрелости ИТ-процессов (по ITIL) приведена на Рис. 8:

Рис. 8. Оценки текущего и требуемого через 1-2 года уровней зрелости ИТ-процессов (по ITIL)

Однако по рисунку совершенно непонятно, почему должны быть именно такие требуемые уровни зрелости, а не больше или меньше.

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

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

Эта сотрудница провела оценку уровней зрелости ИТ-процессов центрального офиса и десятка филиалов заказчика. У всех получились оценки от 1,5 до 2,5 по пятибалльной шкале.

Я эту организацию знал много лет, и такие оценки мне показались крайне низкими. Когда начали выяснять, как же такая ерунда получилась, эта сотрудница уверенно сказала, что опросник она “скачала с официального сайта ITIL”, после чего быстро перевела на русский язык и отослала заказчику.

Первый вопрос опросника по каждому процессу был: «Есть ли у вас в письменном виде видение процесса»? Все представители заказчика отметили ответ “Нет”.

Второй вопрос: «Есть ли у вас миссия процесса»? Ответы были тоже «Нет». После этих двух ответов троечка – это максимум, что они могли заслужить.

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

Вот еще пример графика оценки зрелости процессов (это по COBIT), сколь красиво, столь и непонятно, откуда появились все оценки, кроме текущего состояния (см. Рис. 9, кодами обозначены названия процессов COBIT, соответствие между кодами и названиями процессов приведено на Рис. 2):

Рис. 9. Оценка текущего и требуемых уровней зрелости ИТ-процессов (по COBIT)

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

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

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

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

Вот мои предложения по конкретным работам детализации групп работ по ИТ и входящим в эти группы ИТ-процессам [ИТ-процессы взяты из методологии PRM IT, в методологии ITIL ряда процессов не хватает, особенно относящихся к управлению ИТ-службой и планированию ИТ] (см. Табл. 2):

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

Направления работ по ИТ	Поднаправления работ по ИТ (группы ИТ-процессов)	Основные выполняемые работы
Управление и развитие ИТ	Управление ИТ-службой	Управление финансами Управление активами Управление поставщиками Управление контрактами Управление персоналом Управление знаниями персонала
	Планирование и развитие ИТ	ИТ-стратегия Управление архитектурой информационных систем Управление архитектурой инфраструктуры ИТ Управление рисками ИТ Управление портфелем проектов по ИТ Управление проектами по ИТ
	Анализ потребностей и удовлетворения пользователей	Управление требованиями пользователей ИТ Управление Каталогом ИТ сервисов Управление уровнем услуг (SLA) Оценка удовлетворенности пользователей
Разработка и внедрение	Разработка решений	Разработка требований (ТЗ) Разработка концепции решения Разработка решения Тестирование решения
	Внедрение решений	Управление изменениями Управление релизами Управление конфигурациями
	Непрерывность ИТ	Управление непрерывностью Управление доступностью Управление мощностями Управление требованиями со стороны государства, акционеров и руководства компании
Поддержка ИТ	Поддержка техни- ческих средств и сетей	Выполнение операций Управление событиями Управление серверами и сетями Управление инженерной инфраструктурой
Поддержка ИТ	Поддержка пользова- телей (Help Desk)	Управление инцидентами Управление проблемами Управление доступом пользователей
Информационная безопасность		Управление безопасностью

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

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

Рис. 10 Планирование требуемых уровней зрелости ИТ-процессов, исходя из их важности для бизнеса

Другой вид стратегической диаграммы по планированию ИТ-процессов приведен на Рис. 11.

У генерального директора вашей компании стоит спросить текущую и ожидаемую через 1-2 года важность каждого из направлений ИТ для бизнеса, а также степень удовлетворенности бизнеса текущим состоянием ИТ для каждой области (см. Рис. 11):

Рис. 11. Текущее и требуемое через 1-2 года состояние направлений ИТ

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

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

Тенденции по ИТ-процессам

Улучшение ИТ-процессов сейчас является, пожалуй, самым популярным направлением улучшения управления ИТ. Вот ряд современных тенденций по ИТ-процессам:

Массовое внимание к улучшению ИТ-процессов;
Широкое использование ITIL;
Централизация ИТ-процессов.

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

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

Вконтакте

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

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

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

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

Кроме того, классификация позволяет построить системную модель предметной области, что дает возможность взглянуть на предмет исследования и более точно и более широко. Именно поэтому мы рассмотрим возможности классификации процессов ИТ и попробуем разглядеть ряд особенностей, которые помогут нам их лучше понять и управлять ими более эффективно. Конечно, самые известные классификации процессов ИТ связаны с двумя столпами – с сервисным подходом, представленным 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, например). Такая классификация подойдет для выбора стратегии развития процессов и построения сбалансированных ИТ.

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

Вконтакте

МИНИСТЕРСТВО СПОРТА, ТУРИЗМА И МОЛОДЕЖНОЙ ПОЛИТИКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования «Волгоградская государственная академия физической культуры»

Орлова Ю.А.

Часть 2. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМИ ТЕХНОЛОГИЯМИ

ЛЕКЦИЯ №2.3

«Процессы управления информационными технологиями»

Волгоград

	ПЛАН ЛЕКЦИИ
	ТЕКУЩЕЕ УПРАВЛЕНИЕ ИТ...........................................................................
	ПЛАНИРОВАНИЕ ИТ.........................................................................................
	АУДИТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ...........................................

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

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

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

1. ТЕКУЩЕЕ УПРАВЛЕНИЕ ИТ

Текущее управление ИТ осуществляется на базе годового плана, в

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

определены мощности ИТ и численность обслуживающего персонала.

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

Обеспечить мотивацию и условия для совместной работы пользователей и специалистов в области ИТ.

Предусмотреть эффективное использование ресурсов ИТ в подразделениях и подготовить пользователей к реализации потенциала существующих и новых технологий.

Создать условия для распространения технологий,

соответствующих стратегическим потребностям предприятия.

Разработать нормативы эффективности использования информационных технологий.

Подготовить необходимую информацию для принятия решений об инвестициях в ИТ.

При создании системы текущего управления ИТ нужно учитывать следующие факторы:

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

Текущее управление должно различать ИТ, находящиеся на различных фазах развития. «Зрелые» технологии следует контролировать,

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

Работоспособность системы текущего управления ИТ определяется конкретными внешними и внутренними факторами деятельности предприятия. К таким факторам относятся:

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

мер и структура предприятия, отношения между различными подразделениями.

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

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

Операционные вопросы

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

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

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

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

проводником изменений.

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

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

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

Неформальный надзор и контроль персонала, свойственный небольшим предприятиям, обычно не подходит для более крупных предприятий,

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

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

наоборот, децентрализованное предприятие, учитывающее прибыль,

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

Увязка с системой текущего управления предприятия

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

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

Насколько структура текущего управления ИТ должна быть подобна структуре текущего управления в других подразделениях предприятия? Как осуществлять управление ИТ, если эти структуры различны? Может ли такое положение сохраняться долго?

Как установить баланс между решением задач текущего управления ИТ и своевременными инновациями?

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

Учет характеристик внедряемых ИТ

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

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

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

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

Система текущего управления предприятием решает три категории задач

Управление результатами, персоналом и процессами.

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

Управление персоналом концентрируется на практике найма,

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

Управление процессами, протекающими на предприятии,

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

Все это нужно учитывать и обсуждать при формировании системы текущего управления ИТ.

2. ПЛАНИРОВАНИЕ ИТ

Факторы, вызывающие потребность в планировании ИТ

По мере того, как в последние десятилетия сложность ИТ возрастала, а

масштаб их применения расширялся, все более важной становилась роль планирования информационных технологий.

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

технологические изменения, существенные для разработки планов и пилотных проектов.

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

вследствие чего необходимо устанавливать приоритеты в их использовании, а

также привлекать внешние источники разработки и поддержки ИТ.

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

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

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

Зависимость различных направлений деятельности предприятия от ИТ.

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

Требования к планированию на различных этапах внедрения ИТ

В п. 1.2 выделены четыре этапа внедрения ИТ, каждый из которых характеризуется своими требованиями к планированию.

1. На первом этапе (выявление нужной технологии и планирование инвестиций) определяются затраты на изучение новых технологий и инвестиции в перспективные ИТ.

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

3. На третьем этапе (рационализация/управленческий контроль) цель планирования ИТ состоит в определении оптимальных границ развертывания приложений с точки зрения наилучшего соотношения эффективности и издержек.

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

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

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

разной степени знакомо с той или иной технологией.

Факторы, влияющие на результативность планирования ИТ

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

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

Затраты ресурсов на планирование. Финансовые и людские ресурсы,

вовлеченные в планирование ИТ, отвлекаются от других видов деятельности, в

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

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

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

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

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

будущей деятельности предприятия. В этом случае важна роль высшего руководства для обоснованного принятия стратегических решений.

Часто возникают две проблемы:

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

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

Напечатать