Модель Захмана. Стандарт ISO 14258 – «Промышленные автоматизированные системы предприятия». Концепции и правила для моделей. Инструменты построения архитектурной модели. Сервисно-ориентированная архитектура (Service Oriented Architecture, SOA). Взгляд бизнеса и ИТ на архитектуру. Введение в ITSM. ITIL

Приложение 1 Модель Захмана Первый вариант своей модели Джон Захман создал в 1987 г. для использования, прежде всего, при внедрении крупных бизнес-приложений. Он предложил отображать архитектуру предприятия в виде матрицы, строки которой отражают взгляд на предприятие различных групп сотрудников предприятия и тех, кто используют результаты его деятельности: от инвесторов и высшего руководства до рядовых сотрудников. В модели Захмана выделяются следующие перспективы: 1. Хозяин или планировщик (Planner) – тот, кто устанавливает направление развития организации: прогнозирует изменения внешней среды, область функционирования организации, цели ее деятельности. 2. Руководитель (Owner) – тот, кто отвечает за функционирование предприятия: производство продуктов и/ или предоставление услуг, управление затратами, выполнение персоналом своих обязанностей. Это топменеджер компании и владелец процессов. 3. Проектировщик (Designer) – конструктор или системный архитектор, который является промежуточным звеном между желаемым состоянием организации (с точки зрения «владельца») и технически/физически возможным. 4. Подрядчик (Builder) – генеральный подрядчик, который обеспечивает производство конечного продукта или услуги. В рамках проекта – это руководитель проекта. 5. Субподрядчик (Subconstructor) – тот, кто отвечает за построение и компоновку части конечного продукта или услуги, проектировщик и разработчик части конечного продукта или услуги. 6. Пользователь – тот, кто использует продукты или услуги работающего предприятия. Применительно к ИТ – это рядовые сотрудники компании. 1 Столбцы же матрицы отражают различные стороны (или аспекты) деятельности предприятия, которые сгруппированы по ответам на вопросы: Кто, Что, Где, Когда, Как и Почему. Для пояснения приведем примеры того, что относится к разным столбцам модели Захмана. Кто — это участники функционирования предприятия, люди и организации, в этом столбце отражаются организационная структура, потоки работ, участники и роли, инструкции; Что — это предметы предприятия, включая используемые данные Где — это места выполнения процессов и функций предприятия, то есть пространственное расположение компонент системы Когда — это временные характеристики работы предприятия Как — это процессы и функции предприятия, от общего перечня основных бизнес-процессов до конкретных программных модулей Почему (или Зачем) — это мотивация и порядок трансляции миссии и стратегии на нижние уровни Пример матрицы Захмана показан в таблице 1. 2 Таблица 1.Модель Захмана Каждая клетка матрицы содержит соответствующее описание конкретной стороны деятельности предприятия (аспекта) на конкретном уровне (в конкретной перспективе) в виде определенной модели или, возможно, простого описания (текстового документа). Клетки каждой строки вместе образуют полное описание системы на выбранном уровне (с выбранной перспективы). несущественен. А вот При этом заполнение порядок следования клеток должно столбцов проводиться последовательно «сверху вниз», попытка пропуска одной из строк почти всегда приводит к ошибкам. 3 Приложение 2 Стандарт ISO 14258 – «Промышленные автоматизированные системы. Концепции и правила для моделей предприятия» (Industrial automation systems— Concepts and rules for enterprise models) появился в 1999 г., а в 2008 г. его перевод был принят как ГОСТ Р. В стандарте содержатся концепции и правила для моделирования производственных предприятий с целью обеспечения более эффективной интеграции элементов предприятия, в частности, производственных процессов. Данный стандарт предлагает выполнить три действия на каждой фазе жизненного цикла стандарт: 1. Ответить на вопрос, что надо сделать. 2. Ответить на вопрос, как надо сделать. 3. После этого сделать то, что надо. Стандарт ISO 15704 «Промышленные системы. Требования к стандартным архитектурам и методологиям предприятия» Стандарт ISO 15704 появился в 2000 году и закрепил основные положения современного подхода к архитектуре предприятия. В 2008 г. перевод этого стандарта был принят как ГОСТ Р. Проблемы интеграции могут быть связаны с определением миссии компании, производственной деятельностью, производством продукции и оказанием услуг, человеческим фактором и организационной структурой. В соответствии со стандартом ISO 15704 архитектура предприятия в первую очередь метамоделях и основана др.), на обобщенных обеспечивающих элементах целостность (глоссариях, представлений предприятия, а также на общих принципах и процедурах. 4 Приложение 3 Инструменты построения архитектурной модели Язык, использованный в инструментах линейки ARIS (Architecture of Integrated Information Systems) позволяет описывать те же архитектуры, что и IDEF. Кроме того, в эту линейку входит отдельное решение, которое называется Enterprise Architecture Management (Управление архитектурой предприятия) и предназначено для создания архитектурных моделей предприятия и поддержки их в актуальном состоянии. BPML (Business Process Modeling Language) – язык моделирования бизнес-процессов был разработан для описания архитектуры Бизнеса. BPML представляет бизнес- процессы как комплекс взаимодействий управляющих потоков, потоков данных и потоков событий и средств моделирования бизнес-правил, ролей их взаимодействий. Существует много программных систем, которые предоставляют возможность описания архитектуры бизнеса на этом языке, в частности, Popkin System Architect. 5 Рис. 8. Пример описания архитектуры бизнеса и архитектуры приложений на уровнях корпоративного центра, филиалов или территориальных объединений и отдельных предприятий. Язык UML подходит для описания всех слоев архитектуры предприятия. Эту нотацию поддерживают многие инструментальные средства от ARIS до Microsoft Visio и Rational Rose. 6 Приложение 4 Сервисно-ориентированная архитектура (Service Oriented Architecture, SOA) SOA — это стандарт архитектуры предприятия, прежде всего, архитектуры приложений. Он направлен на решение проблем интеграции разнообразных программных систем в единую программную среду предприятия. Стандарт основан на понятии сервиса, т.е удовлетворения потребностей одного объекта другим. Согласно Gartner, под сервисноориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами: • явное отделение бизнес-логики прикладной системы от логики презентации информации; • реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны потребителям в режиме «запрос-ответ» через четко определенные формальные интерфейсы доступа; • потребитель сервиса может быть прикладной системой или другим сервисом и вызывает сервис, используя соответствующие коммуникационные механизмы. То есть в сервисно-ориентированной архитектуре любой компонент предоставляет свою функциональность другим компонентам на основании простых правил, иллюстрацией которых служит Рис. 9. На рисунке представлены три основные роли этого процесса: заказчик сервиса, который хочет получить определенный функционал, не зная, кто может его предоставить, поставщик, который может предоставить запрошенный функционал и брокер (посредник), который связывает заказчика и поставщика, на основании запроса от заказчика и информации о доступных сервисах, которые ему предоставляет поставщик. 7 Рис. 9. Компоненты сервисной архитектуры. Заметим, что интерфейсы, по которым происходит взаимодействие этих трех объектов, не должны зависеть от используемых аппаратных платформ, операционных систем или языков программирования используемых для разработки самих сервисов. Это позволяет сервисам взаимодействовать единым стандартным и универсальным способом. Такое взаимодействие получило название «слабосвязанное» взаимодействие. Его очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. В отличие от так называемого «сильносвязанного» взаимодействия, при котором компоненты приложений взаимодействуют между собой по уникальным, написанным специально для конкретного случая интерфейсам. В этом случае модернизация одной компоненты потребует изменения всех компонент системы, которые с ней взаимодействуют. То есть сервис-ориентированный подход к архитектуре приложений позволяет перейти от замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности 8 создания новых систем из набора доступных сервисов, т.е. более гибкой и динамичной. Отметим, что подход сервисно-ориентированной архитектуры не является принципиально новым, сходные возможности реализовались и ранее, например, с помощью технологий обмена сообщениями. Однако современные концепции сервисно-ориентированной архитектуры охватывают не только уровни данных и приложений, но и уровень бизнеспроцессов. Кроме того, справочные (референсные) модели сервисно ориентированной архитектуры выделяют следующие основные компоненты: • презентационный уровень – сервисы, предназначенные для взаимодействия с системой пользователей, а также соответствующие механизмы преобразования информации; • уровень бизнес-логики прикладной системы – сервисы, отвечающие за реализацию функционала системы, на этом уровне происходит управление выполнением бизнес- процессов согласно модели процессов и бизнес правилам; • уровень данных — информационные сервисы, которые отвечают за взаимодействие с системами хранения данных; • собственно интеграционный уровень – сервисы и технологии, которые обеспечивают взаимодействие остальных сервисов в системе, поскольку взаимодействие вышеприведенных сервисов происходит не напрямую, а через специальные интеграционные сервисы и технологии, в частности, брокер сервисов (этот уровень еще называют уровнем обработки событий). В случае архитектуры приложений, когда компонентами выступают программные сис темы и их модули, а взаимодействие участников модели осуществляется через Интернет, сервисная архитектура называется SOA – Service Oriented Architecture, сервисно – ориентированная архитектура. Один из вариантов SOA – стандарт Web- сервисов, предложенный в 2004 г. 9 компаниями Microsoft и IBM. Этот стандарт, в свою очередь, опирается на 3 стандарта: • SOAP (Simple Object Access Protocol или «простой протокол доступа к объектам» — протокол обмена сообщениями, основанный на XML, используемый для взаимодействия между участниками предоставления и получения сервиса; • WSDL (Web Services Description Language) — язык описания вебсервиса и доступа к ним, также основанный на XML; • UDDI (Universal Discovery, Description and Integration, «универсальный интерфейс распознавания, описания и интеграции») — каталог веб-сервисов и сведений о компонентах, предоставляющих вебсервисы, описанные на WSDL. Рис. 10 поясняет роль этих понятий в архитектуре Web- сервисов. Важно отметить, что Web-сервисы являются технологическими стандартами, в то время как сервисно- ориентированная архитектура является принципом проектирования программных систем. Отметим, что SOA лежит в основе таких модных технологий как SAAS (Software as a Service – программное обеспечение как сервис) и Cloud Computing (облачные вычисления). Рис. 10. Схема SOA, основанной на Web-сервисах. 10 Архитектура, управляемая моделями (Model Driven Architecture, MDA) Архитектура, управляемая моделями, так же, как и сервисно ориентированная приложений. архитектура, Она не является противоречит SOA, стандартом эти архитектуры архитектуры могут использоваться одновременно на одном предприятии для построения его единой информационной среды. Архитектуру, управляемую моделями с 2001 г., развивает международный консорциум OMG (Object Management Group). Прежде всего, архитектура MDA предназначена для проектирования программных систем и состоит из спецификаций, написанных в основном на UML, и руководств по их использованию. Идея MDA состоит в том, что система может строиться как последовательность последовательно взаимосвязанных детализировать моделей, систему, которые начиная с должны бизнес-логики проектируемого приложения и заканчивая его конкретной реализацией. Этот процесс показан на рис. 11. Рис.11. Model Driven Architecture 11 Приложение 5 Взгляд бизнеса и ИТ на архитектуру Взаимодействие бизнес-приложений осуществляется через корпоративную шину данных, которая берет на себя управление всей логикой автоматического взаимодействия приложений на основе процессов и правил. В этом случае координируется взаимодействие не бизнеспользователей, а бизнес-приложений. Интересно, что такую архитектуру бизнес-пользователи могут снаружи продолжать видеть, как «лоскутное одеяло», а системные архитекторы, разработчики и администраторы «изнутри» – как «слабую интеграцию». Практически все крупные производители ERP-систем уже давно внутри перевели системную архитектуру своих продуктов на сервисориентированную архитектуру, в то время как их конечные потребители снаружи продолжают видеть их продукты как «сильную интеграцию». Тем самым производители сохраняют преемственность функционального класса своих продуктов и повышают их гибкость в области интеграции и доработок. Гибкость «слабой интеграции» покупается ценой ее избыточности. Если гибкость не востребована, например, при автоматизации стабильных бизнес-процессов, то решение получается дорогим и громоздким. Это стрельба «из пушки по воробьям». Нет плохих стилей - есть их неадекватное применение. Таким образом, сознательный выбор механизмов интеграции данных и границ их применения имеет самые долгосрочные последствия для ИТархитектуры всего корпоративного ландшафта ИТ. Формирование стиля зависит не от того, есть ли у бизнеса своя стратегия развития, а от того, насколько и в каких областях бизнес изменчив. Интересно, что изменчивость бизнеса больше зависит от его природы и внешних условий. Поэтому, если ИТ-директор хорошо их понимает, то он все-таки может принимать долгосрочные архитектурные решения. Это подтверждает и практика: информационные системы с адекватным стилем архитектуры переживают и 12 кризис и стратегические изменения бизнеса, а информационные системы с неадекватным стилем архитектуры - даже в стабильных условиях вызывают общую «головную боль» и бизнеса и ИТ. Рассмотренные в данном разделе три стиля не исчерпывают всего стилевого разнообразия ИТ-архитектур. Это на сегодняшний день всего лишь три наиболее часто встречающихся стиля ИТ-архитектуры информационных систем управления бизнесом. К тому же это - всего лишь первое грубое приближение. В каждом из описанных стилей могут выделяться свои модификации. Также могут формироваться принципиально новые архитектурные стили. Новые механизмы интеграции данных (а значит и архитектурные стили) рождаются в задачах управления, которые пока для современного бизнеса являются экзотическими. К таким задачам, например, можно отнести задачи диагностики в телемедицине, оперативное управление объектами большой сложности, коллективный анализ данных очень больших объемов и пр. Помимо этого, в области самих ИТ наработано большое разнообразие моделей интеграции данных, которые еще ждут своего применения. 13 Приложение 6 Введение в ITSM Проблема управления ИТ-ресурсами и повышения эффективности ИТуслуг стара, как и само применение этих ресурсов и услуг. Поэтому сейчас, говоря об ITSM, мы имеем в виду новые концептуальные подходы к решению тех вопросов, которые были на теоретическом уровне сформулированы 20 лет назад и оказались реально востребованы фактически только сейчас, в начале нового столетия. Ключевая идея ITSM в современном ее понимании заключается в необходимости перехода от традиционной модели, где главная цель - это собственно поддержка ИТ-инфраструктуры, к схеме, ориентированной на обслуживание основного бизнеса компании. Решение такой задачи осложняется тем, что для этого потребуется довольно радикально пересмотреть общее позиционирование сервисных ИТ-подразделений в структуре компаний. И тут нужно обратить внимание на две стороны данного вопроса. Во-первых, ИТ-инфраструктура предприятий зачастую формировалась весьма хаотичным образом, оперативно отвечая на те или иные запросы со стороны основного бизнеса. В результате ИТ-службы обычно представляют собой весьма запутанную структуру, как с технической, так и экономической точки зрения. Во-вторых, ИТ-департаменты исторически рассматриваются как вспомогательные, сугубо бюджетные подразделения. А это означает (точнее, из этого следует), что руководство компаний не может четко выявить взаимосвязь между инвестициями в развитие и поддержку ИС и повышением эффективности основного бизнеса. Повышение интереса к концепции ITSM в значительной степени определялось также экономическим кризисом начала нынешнего века, когда во многих компаниях - довольно неожиданно для себя - наряду с дефицитом выделяемых им бюджетов стали ощущать новые требования со стороны 14 руководства в виде необходимости предоставления отчетов по расходам и сведений об ожидаемой прибыли от инвестиций в ИТ-ресурсы. Это подтверждается целым рядом исследований по всему миру. Их результаты говорят также о том, что ИТ-менеджеры не всегда могут четко определить, какие преимущества получают внутренние или внешние клиенты ИТподразделений от той или иной услуги. По оценкам Meta Group, ситуация на рынке такова, что около 75% ИТподразделений сегодня выступает в роли не более чем поставщиков инфраструктуры, ориентированных исключительно на ее технологическое развитие вне связи с деятельностью предприятий в целом. В то же время компании хотят пользоваться экономически эффективными ИТ-услугами, отвечающими их индивидуальным потребностям и способными помочь им в решении ключевых бизнес-задач. Поэтому ИТ-департаменты должны предпринять усилия и сделать шаг вперед, который позволит им стать не просто поставщиками ИТ-инфраструктуры, а настоящими сервис- провайдерами, а затем и стратегическими партнерами руководства компаний, предоставляющими широкий спектр услуг, эффективность которых поддается достаточно простой оценке со стороны их потребителей. Meta Group считает, что во всем мире только 25% компаний приступило к внедрению сервисной модели обслуживания и лишь 5% из них удалось вырасти до того уровня (по состоянию на 2003 г.), когда ИТподразделение становится для своей компании ценным стратегическим ресурсом. Однако по прогнозам, приведенным в том же отчете, в ближайшие три года такой переход сможет осуществить подавляющее большинство ИТподразделений крупных и даже средних компаний. По сути дела, концепция ITSM полностью соответствует общей нацеленности заказчиков на более широкое использование ИТ-аутсорсинга, в том числе и в сфере услуг. Таким образом, задачей ИТ-подразделений становится применение модели аутсорсинга на внутреннем уровне своей организации. И в этой связи аналитики предупреждают: тех, кому не удастся 15 успешно реализовать расформирование, а новые их принципы функции работы, будут скорее возложены всего на ждет внешние специализированные организации. ITSM – относительно новая концепция управления ИТ- подразделениями. Её сущность очень хорошо характеризуется следующим выражением: «Провайдеры ИТ сервисов более не могут позволить себе концентрироваться на технологиях и своей внутренней организации. Теперь им нужно принять во внимание качество сервисов, которые они предоставляют, и сфокусироваться на отношениях с заказчиками». Или другими словами, суть ITSM в современном её понимании заключается в необходимости перехода от традиционной модели, где главная цель - это собственно поддержка ИТ инфраструктуры, к схеме, ориентированной на обслуживание основного бизнеса компании. Решение такой задачи осложняется тем, что для этого потребуется довольно радикально пересмотреть общее позиционирование сервисных ИТ-подразделений в структуре компаний. То есть, основная идея ITSM заключается в том, чтобы ИТ отдел перестал быть вспомогательным элементом для основного бизнеса компании, ответственным только за работу отдельных серверов, сетей и приложений. ИТ отдел должен стать полноправным участником бизнеса, выступая в роли поставщика сервисов для бизнес-подразделений, а отношения между ними формализуются сервисов». как отношения Бизнес-подразделение «поставщик формулирует сервисов– свои потребитель требования к необходимому спектру сервисов и их качеству, а ИТ подразделения поддерживают и развивают информационную инфраструктуру компании таким образом, чтобы она была в состоянии обеспечить запрошенный сервис с заданным качеством. Полный переход на сервисную основу позволит ИТ-подразделениям любой компании не только превратиться из затратного подразделения в центр получения прибыли, но и предлагать свои ИТ-услуги за пределами 16 собственной организации, перейдя тем самым к статусу департамента с независимым бюджетом. Единого мнения о том, с чего следует начинать при переводе ИТподразделения на сервисную основу работы нет. Право на выбор собственного, уникального способа построения процессов ITSM всегда остаётся за компанией. Важнейшая составляющая реализации ITSM – разработка формализованных процессов ИТ отдела. Для каждого процесса определяется последовательность выполнения работ, необходимые ресурсы и затраты времени, средства автоматизации и контроля качества. Кроме того, если процесс чётко определен и документирован, включая входные параметры и результаты выполнения, можно измерить его производительность. Это особенно важно, когда перед ИТ отделом стоит задача реализации сервиса заданного качества совершенствовать за определённую процесс и вносить стоимость. А это необходимые позволит изменения в упреждающем режиме – ещё до того, как произошёл сбой в реализации сервиса. ITSM не касается подробностей и деталей технического управления процессами, управление ИТ реализации бизнес-процессов сервисами и на направлено на обеспечение структурирование внутренней организация работы и деятельности ИТ-подразделения. Реализация ITSM также включает в себя формализацию регламентов работы сотрудников и подразделений ИТ, определение зон ответственности и полномочий персонала, критерии качества работы и формирование механизмов контроля и мониторинга состояния процессов. Концепция ITSM находит своё отражение во многих подходах и методологиях, включая: • ITIL (The Information Technology Infrastructure Library) - библиотеку передового опыта в области управления ИТ; 17 • COBIT (Control Objectives for Information and Related Technology) – стандарт в области контроля за информационными технологиями; • S3M (The Software Maintenance Maturity Model) - модели зрелости обслуживания ПО; • ASL (Application Services Library) - библиотека сервис- приложений; • MOF (Microsoft Operations Framework) - техническое руководство для поддержки и управления решениями и сервисами производственных систем, построенных на продуктах и технологиях Microsoft и другие. Функции ITSM Управление ИТ-услугами (Information Technology Service Management, ITSM) реализует сервисный процессный подход к организации работы ИТслужбы. Суть его в том, что вся деятельность ИТ департамента рассматривается как совокупность услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. В библиотеке ITIL (Information Techno-logy Infrastructure Library) разъясняется, что надо сделать для организации такого подхода. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL разрабатывают специализированные консалтинговые компании. IT Service Management (ITSM) - совокупность 10 процессов, описанных в ядре ITIL: томах Service Support и Service Delivery: 1. Управление инцидентами (Incident management). Цель процесса скорейшее устранение инцидентов, под которыми понимаются любые события, требующие ответной реакции: сбои, запросы на консультации и т.п. В тесной связи с данным процессом рассматриваются вопросы создания и управления подразделением, которое является единой точкой контакта с 18 пользователями и координирует устранение инцидентов, диспетчерской службой (Service desk). 2. Управление проблемами (Problem management). Цель - сделать так, чтобы инцидентов стало меньше. Это достигается за счет выявления и устранения причин инцидентов. 3. Управление конфигурациями (Configuration management). Цель создать и поддерживать в актуальном состоянии логическую модель инфраструктуры. 4. Управление изменениями (Change management). Каждое изменение делается из благих намерений, но каждое изменение потенциально опасно для инфраструктуры. Цель процесса - допускать только разумные изменения, а также координировать проведение изменений. 5. Управление релизами (Release management). Если считать управление изменениями головой, то этот процесс - руки, которые производят изменения в инфраструктуре. Цель процесса - сохранить работоспособность производственной среды при проведении изменений. 6. Управление уровнем сервиса (Service level management). Зачастую поставщик и потребитель ИТ сервисов по-разному представляют себе, в чем эти сервисы состоят, какие операции и как быстро должны проводиться. Цель процесса - выявить требуемый состав и уровень сервиса, следить за его достижением, а при необходимости - инициировать действия по устранению некачественного сервиса. 7. Управление финансами (Financial management for IT services). Цель процесса - обеспечить надежную финансовую базу для всех прочих процессов. 8. Управление мощностью (Capacity management). Недостаточная мощность инфраструктуры приводит к появлению жалоб на скорость работы, или, хуже того, к невозможности продолжать работу. С другой стороны, излишняя, неиспользуемая, мощность - это впустую потраченные деньги. 19 Цель это ITIL процесса - найти разумный компромисс между затратами и потребностями. 9. Управление непрерывностью (IT service continuity management). Цель процесса - обеспечить гарантированное восстановление инфраструктуры, необходимой для продолжения бизнес-операций , в случае чрезвычайной ситуации: пожара, наводнения, отключения электроэнергии. В последнее время к эти классическим угрозам добавился терроризм. 10. Управление доступностью (Availability management). Доступность очень часто используемый показатель уровня сервиса. Однако не только обеспечение заданного уровня доступности, но даже определение и измерение доступности настолько сложны, что для всех связанных с доступностью задач организуется отдельный процесс. Рисунок 1 – Жизненный цикл ITSM Процесс управления инцидентами предназначен для обеспечения быстрого восстановления ИТ-сервиса. При этом инцидентом считается любое событие не являющееся частью нормального функционирования ИТсервиса. К инцидентам относятся, например, невозможность загрузить 20 операционную систему, сбой электропитания, сбой жесткого диска на рабочей станции пользователя, появление компьютерного вируса в локальной сети офиса, отсутствие тонера или бумаги для печатающего устройства и т.д. Показателями качества реализации процесса являются: • временная продолжительность инцидентов; • число зарегистрированных инцидентов. • При реализации процесса должны выполняться следующие функции: • прием запросов пользователей; • регистрация инцидентов; • категоризация инцидентов; • приоритизация инцидентов; • изоляция инцидентов; • эскалация инцидентов; • отслеживание развития инцидента; • разрешение инцидентов; • уведомление клиентов; • закрытие инцидентов. Необходимым функционирования элементом процесса обеспечения является создание эффективного службы поддержки пользователей (Help Desk), единой точки обращения по поводу различных ситуаций в ИТ-инфраструктуре, обработки и разрешении пользовательских запросов. Следует отметить, что роль службы поддержки пользователей в последнее время возрастает, что отражается в её модифицированном названии – Service Desk. Это говорит о том, что современные службы поддержки переориентируются с реактивного принципа работы, на проактивный, позволяющий анализировать ситуацию и предотвращать инциденты еще до их возникновения. 21 Для управления качеством процесса необходимо определить систему управления инцидентами, разработать управленческие отчеты и обеспечивать непрерывное улучшение процесса. На рис. 2 приведена диаграмма активности для процесса Управление инцидентами. Пользователь ИТ-сервиса обнаруживает нарушение режима предоставления сервиса и обращается Сотрудник подразделения Service Desk в Service Desk фиксирует в ИТ-службы. регистрационном журнале инцидент, классифицирует его, определяет приоритет и при возможности осуществляет невозможности для начальную пользователя поддержку. корректно Например, завершить при транзакцию предлагается перезагрузить операционную систему и повторно провести транзакцию. Если начальной поддержки пользователю достаточно и не требуется специализированная поддержка, то осуществляется закрытие инцидента. Если необходимо специализированное обслуживание, то информация по инциденту передается в подразделение сопровождения ИТ-сервисов. В этом подразделении на основе базы знаний выясняется возможность устранения инцидента оперативным персоналом, т.е. нет необходимости эскалации инцидента на более высокий уровень обслуживания. В этом случае оперативный персонал реализует ранее документированную процедуру восстановления ИТ-сервиса. 22 Рисунок 2 - Диаграмма активности процесса управления инцидентами Если для устранения инцидента отсутствует решение в базе знаний, то осуществляется эскалация на следующий уровень обслуживания, где специалисты высокого класса проводят изучение и диагностику инцидента, разрабатывают методы его устранения, восстановления заданной работоспособности ИТ-сервиса и пополняют базу знаний по инцидентам. После закрытия инцидента для пользователя предоставляется возможность доступа к ИТ-сервису с требуемыми показателями качества. Момент закрытия инцидента фиксируется в журнале службы Service Desk. Процесс управления проблемами предназначен для минимизации негативного влияния инцидентов на бизнес и уменьшения количества инцидентов, за счет предотвращения возможных причин инцидентов. В данном контексте под проблемой понимают инцидент или группу инцидентов, имеющих общую неизвестную причину. 23 При реализации процесса должны выполняться следующие функции: • анализ тенденций инцидентов; • регистрация проблем; • идентификация корневых причин инцидентов; • отслеживание изменений проблем; • выявление известных ошибок; • управление известными ошибками; • решение проблем; • закрытие проблем. Для управления качеством процесса необходима организация системы управления проблемами/известными ошибками, организация превентивных процедур поддержки, организация способов верификации известных ошибок, организация интерфейса поддержки поставщиком, разработка отчетов для управления, постоянное усовершенствование процесса. На рис. 3 приведена диаграмма активности для процесса Управление проблемами. 24 Рисунок 3 - Диаграмма активности процесса управления проблемами Процесс управления конфигурациями предназначен для оказания помощи в управлении экономическими характеристиками ИТ-сервисов (комбинация требований клиентов, качества и затрат) за счет поддержания логической модели предоставление реализуется инфраструктуры информации путем о них идентификации, ИТ и другим ИТ-сервисов, а также бизнес-процессам. мониторинга, контроллинга Это и обеспечения информации о конфигурационных единицах (CI – Configuration Item) и их версиях. Конфигурационные единицы описывают системные компоненты с их конфигурационными атрибутами. Элементы конфигурации представляют информационные компоненты, являющиеся объектами или субъектами процесса управления конфигурациями: 25 • материальными сущностями (серверная стойка, компьютер, маршрутизатор, модем, сегмент линии связи); • системными или прикладными программными продуктами и компонентами; • реализациями баз данных; • файлами; • потоками данных; • нормативными или техническими документами; • логическими или виртуальными сущностями (виртуальный сервер, серверный кластер, пул дисковой памяти, группа устройств). 26 Приложение 7 ITIL Модель ITSM является открытой для изменения со стороны пользователей и описывает совокупность процессов службы ИС. Это позволяет настраивать процессы ITSM для конкретного применения. Существует большое количество инструментальных средств, реализующих модели процессов ITSM, разработанных компаниями-консультантами и производителями программного обеспечения управления инфраструктурой ИТ. Модель ITSM не дает ИТ-менеджеру службы ИС однозначных рекомендаций как конкретно строить систему управления информационной инфраструктурой предприятия. В то же время концепция ITSM содержит модель типовых процессов службы ИС, понятийный аппарат, на основе которых целесообразно строить модели процессов для ИТ-службы. Модель ITSM, разработанная проекта ITIL (IT Infrastructure Library информационных технологий, в библиотека произносится рамках инфраструктуры " айтил "), как описывает процессный подход к предоставлению и поддержке ИТ-услуг. Данная модель получила наибольшую известность в силу того, что предоставление и поддержка ИТ-услуг является первичной задачей ИТслужбы предприятия. В отличие от более традиционного функционального подхода к организации ИТ-службы, ITSM рекомендует сосредоточиться на клиенте и его потребностях, на ИТ-услугах, предоставляемых пользователю информационными технологиями, а не на них самих. При этом процессная организация предоставления услуг и наличие заранее оговоренных уровней параметров эффективности позволяет ИТ-службе предоставлять качественные ИТ-услуги, измерять и улучшать их качество. По проекту ITIL была разработана библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области 27 информационных технологий. Множество частных и государственных компаний в разных странах мира, включая и Россию, добились значительных успехов в повышении качества ИТ-сервисов, следуя изложенным в ITIL рекомендациям и принципам. В настоящее время ITIL становится стандартом де-факто для ИТ. Библиотека ITIL создавалась по заказу британского правительства. В настоящее время она издается британским правительственным агентством Office of Government Commerce и не является собственностью ни одной коммерческой организации. В семи томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Следует отметить, что все эти процессы нацелены не просто на обеспечение бесперебойной работы компонент ИТ-инфраструктуры. В гораздо большей степени они нацелены на выполнение требований пользователя и заказчика. Особенностью проекта является свобода использования его результатов: • ограничений на использование нет; • материалы модели могут быть использованы полностью или частично; • модель может быть использована в точном соответствии с текстом книг ITIL либо адаптирована пользователем. При этом модель сегодня является наиболее широко распространенным в мире подходом к управлению ИТ-сервисами. Она применима к организациям любого размера и любой отраслевой принадлежности. Текущая версия библиотеки ITIL включает 7 книг по основным разделам управления ИТ-сервисами: • Service Delivery (предоставление услуг) – содержит описание типов ИТ-услуг, предоставляемых предприятием; 28 Service Support (поддержка услуг) – представляет собой описание • процессов, позволяющих обеспечить пользователям доступ к ИТ-услугам, необходимым для выполнения бизнес-задач; • Information & Computing Technology Infrastructure Management (управление ИТ-инфраструктурой). В книге представлено общее описание методики организации работы ИТ-службы по управлению ИТ- инфраструктурой компании; • Application Management (управление приложениями) указывает, как обеспечить соответствие программных приложений изменениям в потребностях бизнеса, а также рассматривает общий жизненный цикл приложений, включающий разработку, внедрение и сопровождение; • The Business Perspective (бизнес-перспектива) – рассматривается, как работа ИТ-инфраструктуры может влиять на бизнес компании в целом; • to Planning Implement Service Management (планирование внедрения управления услугами) – посвящена проблемам и задачам планирования, реализации и развития ITSM, необходимым для реализации поставленных целей; • Security Management (управление безопасностью) – посвящена проблемам безопасности. В ней рассматриваются проблемы разграничения доступа к информации и ИТ-сервисам, особенности оценки, управления и противодействия рискам, инциденты, связанные с нарушением безопасности и способы реагирования на них. В третьей, разрабатываемой версии библиотеки ITIL (проект ITIL Refresh), представлено пять книг, названия которых отражают жизненный цикл ИТ-услуг: • "Стратегии обслуживания" (Service Strategies); • "Проектирование услуг" (Service Design); • "Внедрение услуг" (Service Introduction); • "Оказание услуг" (Service Operation); 29 • "Непрерывное совершенствование услуг" (Continuous Service Improvement). Модель ITIL/ITSM поддерживается более чем десятком программных продуктов и пакетов. Лидерами разработки программных инструментов управления ИТ-инфраструктурой являются: Packard, Computer Associated, IBM, BMC Software и Hewlett- Microsoft. Среди российских компаний, поставщиков программных систем автоматизации управления ИТ-услугами следует отметить компании СофтИнтегро и Итилиум. Внедрение методики управления ITSM – поэтапный процесс. Как показывает практика, решение первоочередных задач связано с рекомендациями, приведенными в первых книгах "Поддержка сервисов" и "Предоставление сервисов". Процессы группы предоставления сервисов считаются оперативными процессами, поскольку включают в себя повседневные функции ИТ-службы. Процессы группы поддержки сервисов относятся к тактическим, которые предназначены для обеспечения предоставления сервисов заданного качества. 30