Управление и аудит инвестиций в ИТ

Разбить на страницы

Показывать лекцию целиком

Когда отсутствуют процессы, то заменой им может быть опыт.

Когда нет опыта, то его могут заменить правила.

Когда отсутствуют правила, то есть только ритуалы.

Ритуалы – это начало хаоса.

Вольный перевод из сочинения "Дао Дэ Цзин" китайского философа Лао Цзы

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

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

Если говорить про управление информационными технологиями и ИТ-услугами, то наиболее известными в этой области являются ITIL и COBIT, хотя в последнее время для этих целей стала применяться и методика "Шесть сигм", корни которой связаны с управлением качеством. Мы кратко рассмотрим наиболее важные методики в этой лекции.

Архитектура операций (управления ИТ)

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

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

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

(рис 4.1) Роль архитектуры операций и решаемые ею задачи

Понятие "Архитектуры операций" очень близко по смыслу к описанию реализации процессов управления и обслуживания ИТ в соответствии с принципами ITSM (IT Service Management – Управление ИТ-сервисами). В рамках этой архитектуры рассматриваются три элемента:

организационные структуры: модели управления ИТ и персонал;

операционные процессы: процессы управления, обслуживания и разработки ИТ-инфраструктуры;

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

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

Внедрение принципов управления ИТ-сервисами ITSM, как правило, требует реинжиниринга ключевых процессов, связанных с эксплуатацией информационных технологий: управление изменениями, управление проблемами, управление ИТ-активами, создание общекорпоративной системы обслуживания пользователей (Service Desk). Этот процесс изменений должен носить постоянный характер, для того чтобы достичь должного уровня развития и улучшений. В данной области существуют некоторые де-факто стандарты, описывающие лучшие практики. Многие из них основаны на Information Technology Infrastructure Library (ITIL), которая является публично доступной библиотекой лучших практик управления ИТ-инфраструктурой и операциями как единым набором интегрированных процессов.

(рис 4.2) Архитектура ИТ-операций

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

Организация управления ИТ-системами и ITIL

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

Одним из важных концептуальных источников для реализации ITSM является ITIL – IT Infrastructure Library, которая стала, пожалуй, первым достаточно полным описанием лучшей практики организации процессов управления информационными технологиями в организации. Данная библиотека была разработана в конце 1980-х годов в Великобритании Правительственным агентством по коммерции и достаточно долгое время была распространена только в Европе. ITIL представляет собой обобщение лучшего международного опыта в области организации и управления информационными технологиями.

Главный акцент ITIL делается прежде всего на описании сервисов и поддержки. Основные процессы, рассматриваемые в ITIL:

управление инцидентами (Incident management);

управление проблемами (Problem management);

управление конфигурациями (Configuration management);

управление изменениями (Change management);

управление версиями (Release management);

управление мощностями (Capacity management);

управление доступностью (Availability management);

управление уровнями обслуживания (Service-level management).

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

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

Более подробная информация об ITIL доступна на сайте http://www.ogc.gov.uk, а ограничения модели обсуждаются, в частности, в публикациях Gartner [8.1], [8.2]. Идеи, заложенные в ITIL, были конкретизированы ведущими производителями решений и систем в своих фирменных методиках, поддержанных соответствующими специализированными программными средствами. Поэтому за последние несколько лет ITIL значительно расширила свое распространение во всем мире, особенно после того как многие ведущие производители программных и аппаратных средств использовали ее для разработки и популяризации своих эталонных моделей. Такие модели, с одной стороны, включают необходимые рекомендации по совершенствованию процессов управления ИТ, с другой – содержат полезные расширения. К числу этих моделей относятся, прежде всего, ITSM RM (Information Technology Service Management Reference Model) от HP и модель MOF (Microsoft Operations Framework) от Microsoft, которую мы рассмотрим более подробно в следующем разделе.

Методики Microsoft для управления

ИТ-системами и операциями

Помимо методики MSF, ориентированной на обеспечение процесса разработки прикладных систем, Microsoft разработала методику, содержащую специализированные компоненты для управления ИТ – MOF (Microsoft Operations Framework). Эта методика представляет интерес для специалистов, поскольку она, с одной стороны, учитывает весь опыт ITIL, а с другой стороны – в большей степени ориентирована на продукты и технологии Microsoft, которые де-факто лежат в основе ИТ-инфраструктуры большого количества организаций. Кроме того, MOF в определенных областях расширяет область применимости ITIL, например, в управлении распределенной ИТ-инфраструктурой или в таких новых для индустрии направлениях, как хостинг приложений, web-транзакции и системы электронной коммерции.

MOF предоставляет организациям, создающим критически важные (mission-critical) ИТ-решения на базе продуктов и технологий Microsoft, технические руководства по достижению надежности, доступности, удобства сопровождения и управляемости систем. MOF затрагивает вопросы, связанные с организацией персонала, процессов, технологиями и менеджментом в условиях сложных, распределенных и разнородных ИТ-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL).

MOF состоит из следующих трех моделей:

модель процессов;

модель команд;

модель рисков.

Подробная информация по MOF доступна в Интернет по адресу http://www.microsoft.com/mof/.

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

ясно понимать текущие потребности в сервисах и услугах и создавать адекватные решения;

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

За решение первой задачи (анализ потребностей и создание удовлетворяющих их решений) отвечает MSF, в то время как MOF адресуется второй задаче (эксплуатация решений в повседневной деятельности предприятия).

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

Создание и эксплуатация новых решений, согласно MOF и MSF, состоят из четырех базовых этапов:

Определить новые потребности бизнеса.

Построить и внедрить решение с помощью MSF и MOF.

Обеспечить эксплуатацию и использование решений, руководствуясь MOF.

Обеспечить итерационные усовершенствования.

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

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

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

Модель процессов MSF сочетает в себе лучшие черты традиционного, последовательного ("водопадного") подхода к проектированию системы и спиральной, итерационной модели. Модель процессов MSF основана на таких понятиях, как фазы и вехи (контрольные точки). Всего выделяется пять фаз (см. рис. 4.3), каждая из которых завершается своей вехой:

фаза выработки концепции (Envisioning);

фаза планирования (Planning);

фаза разработки (Developing);

фаза стабилизации (Stabilizing);

фаза внедрения (Deploying). Фазы могут содержать также промежуточные вехи.

(рис 4.3) Модель процессов MSF

Модель процессов MOF описывает процессы, связанные с эксплуатацией ИТ-систем и включает четыре квадранта и соответствующие каждому квадранту четыре контрольных процесса (review):

квадрант изменений – управление изменениями, версиями и конфигурацией;

квадрант эксплуатации – мониторинг услуг, сетевое и системное администрирование, управление хранением данных и каталогами и т.д.;

квадрант поддержки – управление событиями и проблемами;

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

(рис 4.4) Модель процессов MOF

Методика Microsoft Solutions for Management (MSM) в какой-то степени дополняет MOF. MSM ставит во главу угла не технические детали реализации информационной системы, а составляющие ее логическую схему процессы, что позволяет добиться универсальности рецептов, содержащихся в ее решениях. Однако даже при современном уровне техники процессы автоматизации остаются лишь инструментами в руках использующих их людей. Поэтому MSM рассматривает ИТ-кадры предприятия как еще один важный фактор в системе управления. Третья составляющая цепочки управления – технологии, задействованные в ИТ-инфраструктуре компании. Для того чтобы объединить эти три фактора в эффективную структуру управления, MSM предлагает прибегать к помощи комплекса специально разработанного программного обеспечения.

MSM включает в себя теоретическую базу, а также лучшие практические примеры внедрения и автоматизации. MSM опирается на модель Microsoft Operations Framework (MOF) – набор шаблонов и методических инструкций по планированию, внедрению и дальнейшей поддержке информационных процессов.

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

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

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

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

Сценарии, в отличие от моделей, представляют собой примеры решений в области управления ИТ-инфраструктурой, связанные с конкретными программными продуктами Microsoft. MSM включает в себя, в частности, такие сценарии, как: распространение обновлений (позволяет быстро, эффективно и управляемо внедрять выпущенные Microsoft обновления программных продуктов, используя Systems Management Server); мониторинг и управление службами (автоматизирует мониторинг доступности каталога Active Directory, Exchange и SQL Server на Windows Server); оценка функционирования (дает возможность пользователям идентифицировать точки главных проблем и разработать план, адресуемый им); установка Microsoft Office (позволяет быстро, эффективно и управляемо внедрять Microsoft Office).

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

Оценки зрелости процессов

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

Уровни зрелости обычно определяются в соответствии с заданной моделью, которая описывает их иерархию и правила измерения (оценки), по которым можно, на основе изучения соответствия определенных характеристик процесса, отнести его к определенному уровню. Общепризнанное распространение получила модель уровня зрелости (Capability Maturity Model – CMM), предложенная Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона, прежде всего для оценки процесса разработки программного обеспечения. Все такие модели базируются на работах Кросби.

Предпосылками для создания этой модели явились прежде всего глобальные проблемы качества информационных систем, связанные с наличием большого числа дефектов программного кода, которые приводили к возникновению ошибок, сбоев и непредсказуемости работы приложений. Понятно, что наиболее критичным образом эти проблемы проявлялись в специализированных областях, прежде всего в военных системах и в научных расчетах, большая часть которых, опять же, была прямо или косвенно связана с решением военных задач. Однако бурное развитие информационных технологий с середины 50-х годов прошлого столетия привело к тому, что сейчас практически все аспекты жизни современной цивилизации немыслимы без применения компьютеров. Очередной скачок в понимании актуальности качества работы информационных систем был вызван появлением персональных компьютеров в начале 1980-х и резким увеличением числа разработчиков и пользователей. Другой аспект проблемы оказался связан с неудовлетворительной организацией управления проектами разработки программного обеспечения и с вытекающими последствиями в виде срыва сроков, превышения бюджета или даже отмены проектов. Хорошее описание возникающих проблем приведено в известных книгах Брукса [8.3] и Йордана [8.4]. Так что начало работы института SEI в данном направлении в 1986 году оказалось очень своевременным, а возможно даже слегка запоздалым.

Результатом работы SEI стало появление модели CMM для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году). Для отнесения компании-разработчика программных систем к определенному уровню была предложена специальная система сертификации. По многим независимым оценкам, внедрение (подтвержденное соответствующей сертификацией) в организации практик, соответствующих высшим уровням модели, позволяет значительно повысить шансы на успешное завершение проекта – с типовых 30% до 85%.

Пожалуй, основной идеей CMM явилось понятие системы определенных Уровней Зрелости (Maturity Levels) процесса, которые охватывают набор так называемых ключевых областей (Key Process). В рамках CMM были определены 5 таких уровней, которые позволяют свести все многообразие вариантов организации процесса разработки к небольшому диапазону номеров уровней. Это позволяет решить первую задачу: обеспечить измеримость процесса в целом. Контролируемость и управляемость процесса определяются возможностями последовательного перехода с уровня на уровень при выполнении определенных условий.

Далее развитие стандарта в соответствии с пожеланиями основного заказчика проекта, Министерства Обороны США, продолжилось в рамках новой модели CMMI – CMM Integration. Обе эти модели очень схожи между собой по целям и подходам – обеспечение измеримости, контролируемости и управляемости процессов организации, но несколько отличаются в терминологии и структуре модели. При разработке CMMI использовались модели CMM для разработки не только программного обеспечения, но и других областей, так что CMMI служит, в определенном смысле, универсальным стандартом, который может применяться для управления качеством. Версия CMMI 1.1 была опубликована в 2002 году. CMMI, собственно говоря, является не описанием процессов, а скорее руководством по их разработке.

В рамках CMMI вводится дополнительная классификация более высокого уровня – разделение на непрерывную и поэтапную реализацию. Для непрерывной реализации вместо 5 уровней определяется 6, которые слегка отличаются по названию и содержанию от соответствующих уровней CMM – здесь вместо понятия уровня зрелости используется понятие уровня устойчивости. Вместо ключевых областей, определенных в CMM, в CMMI используется понятие областей процесса (process areas), которые направлены на достижение целей двух типов – общих (generic) и специфичных для данной системы.

В таблице 4.1 приведены сравнительные характеристики уровней зрелости для разработки программного обеспечения (в соответствии с моделью CMM) и поэтапной реализации в рамках CMMI.

Уровни зрелости процесса разработки программного обеспечения в соответствии с моделями CMM и CMMI
	Название в CMM	Название в CMMI	Характеристики
1	Начальный	Начальный (этот уровень присваивается по умолчанию)	Процесс разработки программного обеспечения спонтанен и во многом хаотичен. Успех зависит от индивидуальных способностей участников и не может быть повторен без их привлечения. Даже если созданные продукты работоспособны, проекты чаще всего существенно превышают заданные сроки и бюджеты
2	Повторяемый	Управляемый	Организация применяет методы лучшей практики для управления функциональностью, сроками и бюджетом проекта. Возможно повторное использование успешных решений
3	Определенный	Определенный	Процесс разработки документирован, стандартизован и утвержден. Процессы последовательно применяются в рамках всей организации
4	Управляемый	Управляемый количественно	Для процессов определены специальные метрики, которые позволяют количественно определить уровни организации и определить степень готовности продукта
5	Оптимизированный	Оптимизированный	Существует возможность предсказания результатов процесса и работоспособности продукта Производится постоянное усовершенствование процессов на основе анализа измеряемых результатов. Процессы направленным образом изменяются для достижения новых целей

Достаточно содержательное введение в проблематику CMMI можно найти, например, в публикации [8.5].

Сама по себе CMMI не рассматривает многие домены архитектуры (данные, интеграция, безопасность, архитектуру ИТ-операций и т.п.). Кроме того, она приводит основные задачи (например, определить метрики для процессов), но не описывает, как именно нужно это делать, т.е. не содержит рекомендаций. Тем не менее, предложенный в рамках моделей CMM/CMMI подход оказался настолько удачным, что аналогичные шкалы уровней зрелости стали широко применяться и в смежных областях, которые не ограничиваются только разработкой программного обеспечения, – в том числе, управления поставками, кадровыми ресурсами или бизнес-процессами предприятия в целом (cм., например, http://www.bptrends.com).

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

Шкала уровней обычно использует обозначения от 0 (отсутствие процесса) до 5 (оптимизированный процесс). На рисунке 8.5 показано, как эти уровни схематично могут быть отражены в координатах "понимания ситуации" и "способности к осуществлению" – по аналогии с магическими квадрантами Gartner.

(рис 4.5) Иллюстративное позиционирование уровней модели СMMI

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

0. Несуществующий

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

1. Начальный/Cпонтанный

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

2. Повторяемый, но интуитивный

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

3. Определенный

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

4. Управляемый и измеримый

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

5. Оптимизированный

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

COBIT как методика аудита процессов управления ИТ

СOBIT (Control Objectives for Information and related Technology) представляет собой систематизированный набор принципов и рекомендаций по проведению аудита процессов управления ИТ. Данная модель была впервые предложена профессиональной ассоциацией ISACA (The Information Systems Audit and Control Association) в 1996 году. Эта ассоциация позиционирует себя как международная организация, специализирующаяся на разработке общих стандартов в области аудита информационных систем. В 2000 году ее орган – Институт Управления ИТ, выпустил третье издание своих материалов. В случае с COBIT речь идет о позиционировании этой методологии как потенциального стандарта со стороны ее разработчиков.

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

Модель COBIT определяет 34 ключевых процесса управления ИТ в организации, которые сгруппированы в 4 основные области (домены). Список этих доменов включает:

Планирование и Организация (Planning and Organisation – PO).

Приобретение и Реализация (Acquisition and Implementation – AI).

Предоставление (реализация) и поддержка (Delivery and Support – DS).

Мониторинг (Monitoring – M).

На следующем уровне в рамках этих 4-х доменов в стандарте определены 34 процесса, которые, в свою очередь, включают 318 различных задач. Список этих процессов верхнего уровня приведен в табл. 4.2.

Cписок процессов верхнего уровня модели COBIT
			Информационные критерии							ИТ-ресурсы
Домен		Процесс	Эффектив- ность (результат)	Эффектив- ность (усилия)	Конфиден- циальность	Целост- ность	Доступ- ность	Соответ- ствие	Надеж- ность	Лю- ди	Прило- жения	Техно- логии	Средства (facilities)	Дан- ные
Планирование и Организация	PO1	Разработка ИТ-стратегии	P	S						+	+	+	+	+
	PO2	Разработка ИТ-архитектуры	P	S	S	S					+			+
	PO3	Мониторинг технологического развития	P	S								+	+
	PO4	Формирование ИТ-службы и определение взаимосвязей	P	S						+
	PO5	Управление инвестициями в ИТ	P	P					S	+	+	+	+
	PO6	Распространение корпоративной информации	P					S		+
	PO7	Управление персоналом	P	P						+
	PO8	Обеспечение соответствия внешним требованиям	P					P	S	+	+			+
	PO9	Управление рисками	P	S	P	P	P	S	S	+	+	+	+	+
	PO10	Управление проектами	P	P						+	+	+	+
	PO11	Управление качеством	P	P		P			S	+	+	+	+
Приобретение и Реализация	AI1	Идентификация автоматизируемых решений	P	S							+	+	+
	AI2	Приобретение и поддержка прикладного программного обеспечения	P	P		S		S	S		+
	AI3	Приобретение и поддержка технологической инфраструктуры	P	P		S						+
	AI4	Разработка и поддержка процедур	P	P		S		S	S	+	+	+	+
	AI5	Установка и прием в эксплуатацию систем	P			S	S			+	+	+	+	+
	AI6	Управление изменениями	P	P		P	P		S	+	+	+	+	+
Предоставле- ние и поддержка	DS1	Определение и управление уровнями обслуживания	P	P	S	S	S	S	S	+	+	+	+	+
	DS2	Управление услугами третьих сторон	P	P	S	S	S	S	S	+	+	+	+	+
	DS3	Управление производительностью и мощностью	P	P			S				+	+	+
	DS4	Обеспечение непрерывности обслуживания	P	S			P			+	+	+	+	+
	DS5	Обеспечение безопасности			P	P	S	S	S	+	+	+	+	+
	DS6	Идентификация и управление стоимостью		P					P	+	+	+	+	+
	DS7	Обучение пользователей	P	S						+
	DS8	Помощь клиентам	P	P						+	+
	DS9	Управление конфигурациями	P				S		S		+	+	+
	DS10	Управление проблемами и инцидентами	P	P			S			+	+	+	+	+
	DS11	Управление данными				P			P					+
	DS12	Управление средствами				P	P						+
	DS13	Управление операциями	P	P		S	S			+	+		+	+
Мониторинг	M1	Мониторинг процессов	P	P	S	S	S	S	S	+	+	+	+	+
	M2	Обеспечение адекватности внутреннего контроля	P	P	S	S	S	P	S	+	+	+	+
	M3	Организация независимого контроля	P	P	S	S	S	P	S	+	+	+	+	+
	M4	Обеспечение независимого аудита	P	P	S	S	S	P	P	+	+	+	+	+

В таблице буква "P" означает основной (primary) критерий, буква "S" – дополнительный (secondary), знак "+" отмечает применимость процесса для данного типа ресурсов.

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

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

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

Более подробная информация о COBIT доступна в Интернет на сайтах www.isaca.org, www.ITgovernance.org.

Набор показателей COBIT для процессов "Разработки стратегического плана развития" и "Разработки ИТ-архитектуры"
	P01 Разработка стратегического плана развития ИТ	P02 Разработка ИТ-архитектуры
Ключевые Целевые Показатели	Относительная доля скоординированных ИТ- и бизнес- стратегических планов, отраженных в долгосрочных и краткосрочных планах конкретных исполнителей Доля бизнес-подразделений, имеющих четкие, понятные и актуальные планы по ИТ Наличие явной связи между ответственностью руководителей и стратегическими планами Доля бизнес-подразделений, использующих стратегические информационные технологии Доля ИТ-бюджета, управляемая бизнес-подразделениями	Ускорение разработки приложений Сокращение времени внедрения основных информационных систем Реализация требований по целостности, доступности и защищенности информации Сокращение избыточности данных Увеличение взаимодействия между системами и приложениями Доля данных в корпоративных справочниках, доступных для пользователей в автоматизированном режиме
Ключевые Показатели Производительности	Приемлемое и разумное число текущих ИТ-проектов Актуальность оценки текущего состояния ИТ (число прошедших месяцев с момента проведения) Актуальность ИТ-стратегии (число прошедших месяцев с момента изменений) Доля участников процесса разработки стратегии, удовлетворенных его организацией Временная задержка между изменениями в стратегическом плане и оперативными планами Индекс участников процесса разработки, определяемый по отношению вкладов (времени, усилий, числа) бизнес-подразделений и ИТ-службы Индекс качества планирования, основанный на соблюдении сроков, приверженности структурному подходу и полноте реализации	Доля ИТ-бюджета, выделенного на разработку и поддержку ИТ-архитектуры Число изменений в приложениях для обеспечения соответствия принятой модели данных Доля требований по обеспечению целостности данных, документированных в модели данных Число инцидентов, вызванных противоречиями в модели данных Объем переработок, вызванных противоречиями в модели данных Число ошибок, связанных с недостаточной оперативностью при внесении изменений в описание архитектуры Временная задержка между изменениями в описании архитектуры и изменениями в приложениях

Для всех указанных процессов в модели, в соответствии с принципами CMM, определен набор уровней зрелости – от 0 до 5, характеризующих уровень реализации этого процесса в организации.

Для выбранных нами процессов PO1 и PO2, в СobIT используются следующие критерии отнесения процесса к определенному уровню зрелости.

Критерии зрелости для процессов "Разработка стратегического плана развития ИТ" и "Разработка ИТ-архитектуры"
	P01 Разработка стратегического плана развития ИТ	P02 Разработка ИТ-архитектуры
0. Несуществующий	В организации отсутствует понимание необходимости разработки ИТ-стратегии для решения задач бизнеса. Какая-либо активность отсутствует	В организации отсутствует понимание важности разработки ИТ-архитектуры вообще. Соответственно, у персонала отсутствует необходимый опыт и квалификация. Какая-либо ответственность не определена
1. Начальный / Cпонтанный	Руководство признает необходимость разработки стратегии, однако процесс разработки не определен. Отдельные элементы планирования осуществляются по мере необходимости, поэтому результаты являются непоследовательными и спонтанными. Вопросы ИТ-стратегии обсуждаются иногда только в ИТ-службе, но не бизнес-руководством. Выбор решений осуществляется не на основе стратегии организации, а диктуется предложениями вендоров. Риски определяются неформально и привязываются к отдельным проектам	Руководство признает необходимость разработки архитектуры, однако не определило ни плана, ни процесса разработки. Отдельные мероприятия осуществляются не систематически и зависят от конкретного случая и инициативы исполнителя. Существует некоторое количество диаграмм и описаний процессов, обсуждение ведется спонтанно и непоследовательно. Предпочтение отдается не описанию требуемой для бизнеса информации, а описанию доступных де-факто данных, определенных существующими приложениями ИС
2. Повторяемый, но интуитивный	Разработка ИТ-стратегии понятна руководству, но не документирована. Она ведется ИТ-службой с привлечением бизнес-подразделений по необходимости. Изменения стратегии происходят только по запросу руководства, вне рамок формального процесса определения изменений бизнес-требований. Решения принимаются отдельно для каждого проекта. Преимущества стратегии, а также основные риски находят понимание на интуитивном уровне	В организации существует общая осведомленность по вопросам ИТ-архитектуры. Проводятся отдельные интуитивные мероприятия по разработке элементов архитектуры, которые могут быть частично скоординированы в рамках возникающего процесса и повторяться впоследствии. В то же время формальное обучение не проводится, а существенная часть опыта приобретается каждым участником самостоятельно. Решение вопросов ориентировано на краткосрочные тактические цели
3. Определенный	Порядок, процедуры и ответственность за разработку ИТ-стратегии понятны, документированы и доступны всем. Процесс хорошо определен, и вероятность успешного планирования высока. Реализация этого процесса все еще во многом зависит от индивидуальных исполнителей, регулярных проверок качества процесса нет. ИТ-стратегия включает последовательную оценку рисков, а также учитывает финансовые, технические и кадровые возможности при выборе новых продуктов и технологий	Необходимость разработки ИТ-архитектуры хорошо понятна и принята всей организацией, ответственность за отдельные работы четко определена. Процедуры, приемы и применяемые средства определены, документированы и внедрены. На основе стратегических бизнес-целей определены наиболее общие архитектурные принципы и стандарты, хотя соответствие им не всегда последовательно соблюдается и проверяется. Реализована на практике функция администрирования, ответственная за распространение стандартов, и отчетность по их использованию
4. Управляемый и измеримый	Стратегическое планирование ИТ является стандартным процессом, отклонения от которого будут заметны для руководства. Для процесса определена ответственность на высшем уровне, а также обеспечивается его мониторинг и оценка эффективности. Ведется как краткосрочное, так и долгосрочное планирование. ИТ-стратегия совместно с бизнес-стратегией направлены на получение преимуществ для бизнеса за счет внедрения новых приложений и проведения реинжиниринга бизнес-процессов. Существует хорошо определенный процесс оптимизации использования внутренних и внешних ресурсов. Проводится формализованное количественное сравнение показателей ИТ-системы с данными конкурентов и отраслевыми нормами	Разработка и внедрение ИТ-архитектуры полностью поддержана формальными методиками и процедурами. Обеспечивается возможность количественного измерения производительности процесса разработки и успешности применения его результатов на практике. Обучение определено, документировано и последовательно применяется в рамках всей организации. Процесс разработки поддержан соответствующими автоматизированными средствами, хотя они могут быть и не полностью интегрированы. Определены и применяются внутренние "лучшие практики". Базовые метрики процесса определены и объединены в целостную измерительную систему. Сам процесс учитывает изменения требований бизнеса и ориентирован на достижение стратегических целей. Реализован автоматизированный репозитарий ресурсов описания архитектуры, позволяющий использовать эту информацию в системах принятия решений и информирования руководства
5. Оптимизированный	Стратегическое планирование обеспечивает ощутимые бизнес-преимущества за счет инвестиций в информационные технологии. Планирование ИТ неразрывно связано с планированием бизнеса. Существует долгосрочная реалистичная ИТ-стратегия, которая постоянно обновляется с учетом технологических инноваций и изменений требований бизнеса. Краткосрочные планы содержат определенные этапы, выполнение которых постоянно отслеживается, а параметры корректируются в зависимости от изменений. Формализованное количественное сравнение ИТ-показателей с лучшими отраслевыми практиками интегрировано в процесс разработки стратегии. Инновации в ИТ-технологиях отслеживаются и используются для развития бизнеса	Архитектура ИТ-системы последовательно внедряется на всех уровнях, и ее важность для бизнеса постоянно подчеркивается. Персонал ИТ-службы обладает необходимым опытом и квалификацией, позволяющей строить и модифицировать архитектурные решения в соответствии с изменяющимися требованиями бизнеса. Организация широко применяет доступные лучшие практики, в частности, использование хранилищ данных и средства анализа данных. Ведется постоянное развитие и совершенствование ИТ-архитектуры

В курсе Архитектура предприятия, посвященном практической реализации проекта разработки архитектуры в организации, мы рассмотрели "близкую задачу" – как оценить существующий уровень реализации архитектуры по характерным признакам. А особенностям оценки состояния процесса разработки архитектуры для государственных организаций посвящен лекции 8.

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

По сравнению с ITIL, COBIT охватывает гораздо более широкий круг задач. В то же время уровень детализации ITIL существенно выше в своей предметной области, связанной с сервисами. Поэтому они достаточно эффективно могут дополнять друг друга. В частности, аудиторы информационных систем часто используют опросники ITIL при анализе состояния соответствующих процессов, относящихся в COBIT, в основном, к домену "Предоставление и поддержка". Более подробно о совместном использовании этих моделей см. в статье [8.7].

Страницы:

Когда отсутствуют процессы, то заменой им может быть опыт.

Когда нет опыта, то его могут заменить правила.

Когда отсутствуют правила, то есть только ритуалы.

Ритуалы – это начало хаоса.

Вольный перевод из сочинения "Дао Дэ Цзин" китайского философа Лао Цзы