PO1.6. Управление ИТ-портфелем

⇐ ПредыдущаяСтр 3 из 3

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

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

Следующий раздел называется " Указания для менеджмента" и содержит три атрибута процесса:

· таблицу входов и таблицу выходов;

· ролевую таблицу (RACI-таблицу);

· диаграмму целей и метрик (т. е. местоположение процесса в иерархии целей).

Таблицы входов и выходов процесса представлены на рис. 4. В таблице входов звездочками обозначены входы извне процессов COBIT. Обозначения процессов состоят из первых букв английского названия процессной области и порядкового номера процесса. Таким образом, ME4 обозначает четвертый процесс в области " Мониторинг и оценка" (а именно процесс " Обеспечение

Рис. 4. Входы и выходы процесса " Разработка стратегического плана развития ИТ"

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

Рис. 5. Ролевая таблица процесса " Разработка стратегического плана развития ИТ"

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

Рис. 6. Цели и метрики процесса " Разработка стратегического плана развития ИТ"

О выборе набора метрик в COBIT говорится следующее:

" Метрики разрабатывались исходя из следующих соображений:

· высокая полезность (например, полезность метрик при оценке эффективности или степени достижения цели должна значительно превышать сложность их расчета);

· внутренняя сравнимость (например, процент от некоторого базового значения или величина, привязанная к моментам времени);

· внешняя сравнимость, не зависящая от конкретной индустрии или размера предприятия;

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

· простые в измерении, в отличие от целей".

Несмотря на то, что приведенный на рис. 6 перечень метрик процесса и его активностей является только иллюстративным (как и все перечни метрик в COBIT), он, безусловно, может оказаться полезным и на практике. Тем не менее, принципы его построения остаются не вполне понятными. Например, у процесса есть два выхода - стратегия ИТ-сорсинга и стратегия ИТ-закупок, для которых, во-первых, нет активностей, а во-вторых, отсутствуют метрики, характеризующие соответствие этих выходов требованиям бизнеса. Более того, рис. 6 демонстрирует, что существуют две параллельные системы целей: цели управления процессом (control objectives) и цели процесса (process goals), причем метрики определены только для целей процесса. Для целей управления процессом никаких метрик не вводится, что еще раз подтверждает тезис о декларативности этих целей. Если сюда добавить еще и набор требований к процессам, приведенный в предыдущем разделе, получится довольно громоздкая и разнородная система утверждений разной степени общности с непрозрачными взаимосвязями, и, главное, имеющая непонятное назначение, потому что никаких рекомендаций по практическому использованию этих утверждений (за исключением целей процессов) COBIT не предлагает.

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

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

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

1. Начальный/Подходящий к случаю. Есть уверенность, что организация осознает наличие проблемы. Стандартных процессов тем не менее не существует; вместо этого применяются подходящие к случаю приемы, которые могут и повторяться. Общий подход к управлению не организован.

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

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

4. Управляемый и измеримый. Менеджмент следит и замеряет, насколько строго управление следует установленным процедурам и предпринимает определенные действия, если процессы работают с низкой результативностью. Процессы постоянно улучшаются, воплощая в себе признанные практики. Автоматизированные средства управления используются ограниченно или фрагментарно.

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

COBIT использует шаблонную модель не для описания зрелости организации, как это делается в СММ, а для характеристики отдельного процесса. При построении модели зрелости процесса рекомендуется добавить к шаблонной модели следующие дополнительные свойства, характеризующие процесс:

· ознакомленность и коммуникации;

· политики, планы, процедуры;

· инструменты и средства автоматизации;

· навыки и экспертиза;

· ответственность и подотчетность;

· постановка целей и измерения.

То, насколько полно реализовано каждое свойство, определяет уровень зрелости процесса.

Этот подход радикально отличается от подходов СММ/CMMI и методологии. Использование " лесенки уровней" для отдельного процесса делает принципиально невозможным переход от оценки процесса к оценке организации: единственным объектом оценки является изолированный процесс.

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

Рис. 7. Три измерения зрелости процесса

Взгляд на зрелость процесса, когда рассматриваются не просто управленческие характеристики процесса (" общие практики" в терминологии CMMI), а разные содержательные аспекты этих характеристик, является оригинальным и перспективным, хотя никаких конструктивных способов построения модели зрелости процесса COBIT не дает. Модель зрелости процесса " Разработка стратегического плана развития ИТ" выглядит так.

PO1. Разработать стратегический ИТ-план

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

0. Несуществующий, когда

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

1. Начальный/Подходящий к случаю, когда

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

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

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

3. Определенный, когда

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

4. Управляемый и измеримый, когда

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

5. Оптимизируемый, когда

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

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

Шаблонная модель зрелости COBIT на самом деле лишь внешне напоминает модели зрелости и развитости процессов, рассмотренные ранее. Прежде всего, в ней нет " производственного процесса организации" (CMM) или " множества стандартных процессов" (CMMI). " Определенный" уровень COBIT не предполагает, что процесс проекта " выкраивается" из стандартного процесса. Вместо стандартного процесса появились общие " процедуры", применение которых обязательно, но не контролируется. Смысл такой замены непонятен.

Но самое главное отличие состоит в том, что из-за локальности моделей зрелости, каждая из которых относится к одному-единственному процессу, и отсутствия общих практик, т. е. характеристик управления, не зависящих от процессов, а характеризующих организацию в целом, нельзя утверждать, что, скажем, уровень " Определенный" одного процесса сопоставим с таким же уровнем другого. Поскольку определение уровня процесса локально, ничто не мешает у разных процессов одинаково назвать уровни с совершенно разными требованиями к системе управления. Другими словами, уровни разных процессов принципиально несравнимы, т. е. понятие уровня как характеристики системы управления организации отсутствует. Это полностью меняет концепцию, заложенную в CMM/CMMI/SPICE, не давая при этом никаких видимых преимуществ.

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

Заключение

Если собрать воедино все соображения, приведенные выше, получается следующая картина. Вся методология COBIT в том виде, как она изложена в (COBIT, 2007), представляет собой набор достаточно абстрактных правдоподобных рассуждений и положений, не содержащий практически ничего оригинального (с небольшими исключениями) и изложенный в непривычной и неоправданно усложненной системе понятий. Этот набор понятий иллюстрируется достаточно объемным формальным описанием модели процессов, которая служит не для непосредственного практического применения, а только как образец того, как следует строить подобную модель на практике. Связь между набором абстрактных понятий и приведенной моделью описана неформально, на интуитивном уровне. При разработке конкретной модели процессов решение вопроса о том, соответствует конкретный процесс приведенным в COBIT общим соображениям или нет, остается на усмотрение автора модели.

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

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

Библиотека ITIL

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

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

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

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

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

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

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

Библиотека ITIL

Попытки регламентировать управление ИТ-услугами начались в 80-е годы прошлого века в Великобритании по инициативе правительственного Центрального Агентства по вычислительной технике. В результате была создана, вероятно, самая известная и широко распространенная эталонная модель процессов управления ИТ-услугами, получившая впоследствии название Управление ИТ-услугами ( ITSM1англ. IT Service Management ) и изложенная в нескольких книгах, составивших так называемую библиотеку ITIL2от англ. IT Infrastructure Library. После ряда доработок в 2001 году была опубликована вторая версия ITIL, которая стала де-факто стандартом в области управления ИТ-услугами и послужила теоретической основой ряда программных продуктов, предназначенных для автоматизации управления ИТ-услугами. В качестве примеров можно назвать HP ITSM компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft. Появление и распространение второй версии ITIL (для краткости - ITIL v.2) привело к созданию некоммерческой организации itSMF (от англ. IT Service Management Forum), которая имеет целью распространение идей ITIL, проведение конференций и форумов, организацию обучения ITIL. Книга (itSMF, 2003) стала фактически общепринятым введением в ITIL для начинающих. Дальнейшее изложение ITIL v.2 опирается на эту книгу.

ITIL v.2

Рис. 8. Процессы управления услугами ITIL v.2

Процессная модель ITIL v.2 (рис. 8) отличается конкретностью и прагматичностью. Процессы подробно описаны в едином шаблоне, включающем не только перечень активностей, но и блок-схемы, описания ролей и ответственностей, критические факторы успеха, метрики и многое другое. Все описания предельно конкретны и не допускают никаких двусмысленных толкований. Вот, например, как выглядит в (itSMF, 2003) описание задачи процесса " Управление инцидентами" (русский перевод, к сожалению, оставляет желать лучшего):

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

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

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

" Инцидент - это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги. В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание ( SR3от англ. Service Request ).

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

Примеры Запросов на Обслуживание:

· вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;

· запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;

· запрос о замене пароля;

· запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;

· получение информации из базы данных.

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

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

Запрос на Изменение считается завершенным после проведения изменения в инфраструктуре, например замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения".

Приведенные фрагменты типичны для книги (itSMF, 2003), где описаны основные процессы ITIL v.2. Они демонстрируют, что ИТ-услуги в ITIL v.2 имеют строго инфраструктурный смысл.

Обобщенная модель процессов ITIL v.2 (из (itSMF, 2003)) показана на рис. 9.

Рис. 9. Обобщенная модель процесса в ITIL v.2

Процессы описаны словесно, но в полном соответствии с приведенной моделью. Для всех процессов имеются блок-схемы, показывающие порядок выполнения работ и интерфейсы с остальными процессами. Что особенно важно с практической точки зрения, точно определены роли участников процесса. Никаких характеристик зрелости или развитости процессов не приводится, но в главе 2 книги (itSMF, 2003) явно говорится о том, что, используя систему качества, основанную на стандарте ISO 9000-2000, и предложенную эталонную модель процессов ITSM, организация может достичь четвертого уровня зрелости CMM.

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

Помимо эталонной процессной модели из ITIL v.2 в управленческую практику пришло несколько фундаментальных принципов, важность которых полностью подтвердилась со временем:

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

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

· корпоративная оценка ИТ-организации базируется на показателях эффективности процессов оказания услуг. Кроме того, в ITIL v.2 входит процесс Управления финансами, который включает, в частности, деятельность по выставлению счетов за оказанные услуги; это означает, что ITSM позволяет рассматривать деятельность ИТ-организации как бизнес по оказанию ИТ-услуг.

Фактически ITIL v.2 сформировал основы взаимоотношений ИТ-организации и бизнеса. Естественное развитие подхода ITSM состояло в том, чтобы распространить эти принципы с взаимоотношений, связанных с оказанием инфраструктурных услуг, на все взаимодействия ИТ-организации и бизнеса. Шаг в этом направлении был сделан в ITIL v.3.

ITIL v.3

В 2007 г. правительственная британская организация The Office of Government Commerce (http: //www.ogc.gov.uk), издающая ITIL, опубликовала третью версию библиотеки (далее - ITIL v.3), значительно отличающуюся от предыдущих и состоящую из пяти книг ( (OGC, 2007a), (OGC, 2007b), (OGC, 2007c), (OGC, 2007d), (OGC, 2007e)).

Как и ITIL v.2, версия ITIL v.3 представляет собой эталонную модель процессов управления услугами, но система понятий, лежащая в основе модели, претерпела принципиальные изменения. Изменились не процессы и методы, а цели и философия ITIL.

Основным объектом управления в ITIL v.2 была сложившаяся ИТ-инфраструктура. ИТ-организация, управляющая ИТ-инфраструктурой, предоставляла пользователям со стороны бизнеса ИТ-услуги, реализованные на базе этой инфраструктуры. Процессы, связанные с поддержкой и предоставлением услуг, а также бизнес-функция взаимодействия с пользователями (Service Desk) и составляли содержание ITIL v.2.

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

ITIL v.3 представляет собой попытку теоретически переосмыслить и максимально обобщить как процессную модель, базирующуюся на понятии услуги, так и область ее применения. Как следствие, на первый план вышли такие вопросы, как природа услуг, связь услуг с целями и стратегией бизнеса, экономика услуг. ITIL v.3 не ограничивается услугами, связанными с управлением существующей инфраструктурой, хотя и включает процессы из ITIL v.2. С точки зрения ITIL v.3, к услугам можно отнести, например, проектирование и разработку приложений, внедрение эффективных процессов управления ИТ, закупку лицензий ПО. Иллюстрацией может служить слегка упрощенный рисунок из (OGC, 2007a) ( рис. 10), где показана связь между линейками услуг провайдера, архетипами (т. е. шаблонами услуг) и активами пользователя. Услуга - это комбинация архетипа и определенных активов пользователя.

Рис. 10. Связь между услугами и активами пользователя

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

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

Кроме того, ITIL v.3 декларирует принципиальную непрерывность спектра услуг. На одном полюсе стоят услуги, которые бизнес предоставляет, используя только свои собственные ресурсы (бизнес-процессы, персонал, знания и т. п.). На другом - ИТ-услуги, связанные только с использованием ИТ-ресурсов (процессов управления ИТ, персонала, приложений и т. п.). Эти услуги ИТ-организация предоставляет бизнесу. Между этими крайностями расположены услуги, которые используют как те, так и другие ресурсы. Такие услуги планируются и реализуются совместно ИТ-организацией и бизнесом и именно они представляют основной интерес с точки зрения ITIL v.3. Эта ситуация иллюстрируется рис. 11, где показаны структуры бизнес- и ИТ-услуг и их взаимодействие.

Буквы в кружках обозначают следующее.

A - процесс построения услуг. Бизнес-услуги строятся на базе бизнес-процессов, ИТ-услуги на базе ИТ-приложений.

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

Процессы А и В входят в ITIL v.3.

C - деятельность по совершенствованию бизнес-процесса для увеличения полезности бизнес-услуги.

Процесс С выполняется с использованием методологии Six О методологии Six Sigma см., например, Sigma.

D - деятельность по совершенствованию приложений для увеличения полезности ИТ-услуги.

Для разработки и сопровождения приложений (процесс D) применяется методология CMMI.

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

Рис. 11. Бизнес-услуги и ИТ-услуги

Структурно ITIL v.3 состоит из ядра англ. ITIL Core и дополнительных руководств англ. ITIL Complementary Guidance. Ядро включает теоретическое обоснование подхода и модель процессов жизненного цикла услуг, представленные на рис. 12. Дополнительные руководства включают специфические отраслевые, организационные, технологические документы, помогающие адаптировать ядро к специфическим условиям.

Рис. 12. Ядро ITIL

Как видно из рисунка, центральным элементом модели является деятельность по разработке Стратегии оказания услугService Strategy. Стратегия наполняет содержанием три последовательных этапа жизненного цикла: Проектирование услугService Design, Развертывание услуг Service Transition и Предоставление услугService Operation. Параллельно с этим на всех этапах выполняются процессы Непрерывного улучшения услугContinual Service Improvement. Далее мы рассмотрим содержание пяти книг ITIL.

⇐ Предыдущая 1 23