Бесплатный фрагмент - ИТ-архитектура от А до Я: Шаблоны документов

ПРЕДИСЛОВИЕ

Об авторе

Вадим Алджанов (англ. Vadim Aldzhanov) [Microsoft MCP, MCSA Security, MCSE Security, MCTS, MCITP, MCITP SQL Database Administrator, Cisco CCNA, VMware VCP4, CompTIA A+, Network+, Security+, EC-Council CEH и ECSA, SNIA Certified Storage Professional SCSP, Wireless Technology CWTS, CWNA, CWSP, IT Management ITILv3, Apple Certified Associate – Integration | Management].

В серии книг «ИТ Архитектура от А до Я» собраны и обобщены знания и опыт за более чем 17+ лет работы в ИТ. В течении 14 лет проработал в банковской сфере, большую часть времени на позиции руководителя ИТ департамента. На данный момент являюсь ИТ Архитектором в одном из крупных холдингов страны. Имею степень бакалавра по специальности «Радиотехника» и степень магистра по направлению «Компьютерные Информационные Системы (CIS)». На данный момент продолжаю образование на получение докторской степени по направлению «Менеджмент Информационных Систем (MIS)». Кроме этого имеется порядка тысячи часов обучения на специализированных курсах по направлениям системное администрирование, компьютерные сети, беспроводные сети, системы хранения, системы виртуализации, информационная безопасность, управление ИТ сервисами, управление проектами, банковское дело, пластиковые карты, стратегическое планирование, проведение аудита и прочие. Профиль в LinkedIn: https://www.linkedin.com/in/vadim-aldzhanov-623a7b44/

Введение

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

Серия книг «ИТ Архитектура от А до Я» - Зеленая книга

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

Серия книг «ИТ Архитектура от А до Я» - Синяя книга

Издание «ИТ Архитектура от А до Я: Комплексное решение». Вторая книга серии «ИТ Архитектура от А до Я» содержит детальную техническую информацию и практические примеры реализации ИТ решений на основе основ теории, описанной в первой книге. В качестве примеров рассмотрены решения, на базе Windows 10/2016, комплексного решения по мониторингу, управлению и конфигурированию Microsoft System Center 2016, портал Microsoft SharePoint Server 2016, решения по управлению проектами Microsoft Project Server 2016, почтовый сервер Exchange 2016, решение Skype for Business 2015, функциональные возможности Direct Access 2016, Hyper-V, DFS и File Server, RDS и т п. Представлены детальные требования и примеры расчетов по системам обеспечения. Приведены расчёты мощности и стоимости решений. В качестве примеров используются решения, которые выбраны автором как наиболее подходящие для выполнения поставленных задач, популярные или с которыми автор знаком на практике. Является переработанным, исправленным и дополненным издания «ИТ Архитектура: практическое руководство от А до Я».

Серия книг «ИТ Архитектура от А до Я» - Серая книга

Издание «ИТ Архитектура от А до Я: Шаблоны документов». Сборник содержит набор шаблонов и примеров документации, необходимой в повседневной деятельности ИТ. В качестве источника используются как проверенные на практике материалы, так и рекомендации стандартов и практик.

Серия книг «ИТ Архитектура от А до Я» - Желтая книга

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

Серия книг «ИТ Архитектура от А до Я» - Красная книга

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

Серия книг «ИТ Архитектура от А до Я» - Черная книга

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

Цели книги

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

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

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

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

Сферы, охваченные книгой

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

Книга предназначена для широкого круга читателей и будет полезна:

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

Руководителям ИТ подразделений, ИТ архитекторам, менеджеров среднего звена ИТ департамента, а также менеджерам проектов книга предоставляет теоретические основы управления ИТ сервисами (ITSM) с применением рекомендаций практик ITIL, интеграцию методики Управление Проектами (PMI) в ИТ, вопросы аудита ИТ (CobiT) и Информационной Безопасности.

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

Благодарность

Выражаю благодарность друзьям, учителям, руководителям и коллегам за помощь в написании книги, а также бесценный опыт и знания полученный от общения с такими людьми как Александр Буслаев («AIG Group»), Иршад Гулиев («SINAM»), Фазиль Маммедов («ROTABANK»), Яна Хмельницкая и Karsten Stellner («LFS Financial Systems GmbH»), Thomas Engelhardt («Microfinance Bank of Azerbaijan»), Andrew Pospielovsky («ACCESSBANK») и Alan Crompton («Baku European Games Operation Committee BEGOC 2015»).

Юридическое уведомление

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

Авторские права

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

Отказ от ответственности

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

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

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

ГЛАВЫ КНИГИ

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

Раздел I: Управление ИТ Сервисами;

•Глава 1: Стратегические ИТ документы;

•Глава 2: Политики и Положения ИТ;

•Глава 3: ИТ Стандарты;

•Глава 4: ИТ Процедуры;

•Глава 5: Должностные Инструкции;

•Глава 6: Сервисные Соглашения;

•Глава 7: Прочие документы ИТ;

Раздел II: Информационная Безопасность;

•Глава 1: Стратегические документы ИБ;

•Глава 2: Политики и Положения ИБ;

•Глава 3: Стандарты ИБ;

•Глава 4: Процедуры ИБ;

•Глава 5: Должностные Инструкции;

•Глава 6: Прочие документы ИБ;

Раздел III: Управление Проектами;

УПРАВЛЕНИЕ ИТ СЕРВИСАМИ

ОБЩАЯ ИНФОРМАЦИЯ

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

•Политики и положения — высокоуровневые документы, определяющие общие положения, методы достижения целей, задачи и т п. Определяют высокоуровневые значения (например, … длинна пароля должна быть регламентирована …) Как правило содержит общее описание процедур и принципов.

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

•Стандарт — документы промежуточного уровня, определяющие метрики для методов, определённых в политиках (например, … длина пароля восемь символов…). Наиболее часто изменяемый документ ввиду непрерывности и изменчевости бизнес требований и возможностей организации.

•Процедуры — документы промежуточного уровня, определяющие пошаговый регламент работ для применения политик с использованием метрик стандартов, инструменты, исполнителей, инструкций и т п. как правило глубоко детализированный документ с блок схемами, примерами выполнения действий с конкретной информационной системой. Например, «Процедура Управления Инцидентами» построенная на базе решения Microsoft System Center 2016 Service Manager.

•Стандартные Операционные Процедуры (СОП) — документы промежуточного уровня, определяющие пошаговые действия для рутинных работ, указанных в регламенте работ по сервису. К таким работам можно отнести установку сервиса, создание резервной копии, восстановление и т п.

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

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

Кроме этого, в зависимости от структуры организации некоторые документы могут быть сгруппированы по ролевому принципу. Так для примера, если в организации имеется выделенная роль «Оператора Резервного Копирования», чья задача состоит в создании резервных копий всех ИТ сервисов, то есть смысл сгруппировать процедуры резервного копирования всех ИТ сервисов в одном документе. Это позволит сотруднику поддерживать актуальность информации, и избавит от необходимости просматривания документы «Детальной Архитектуры сервиса» всех сервисов.

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

•Архитектура сервиса — описывает назначение, сервиса компоненты, требования, стоимость и т п;

•Руководство по внедрению и сопровождению — описывает последовательность развертывания, стандартные операции по сопровождению и т п;

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

Рекомендации по разработке ИТ документации

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

•Какие документы нужны для вашей организации сейчас?

•Насколько детально нужно их прорабатывать?

•Стоимость времени, потраченного на создание документа по отношению к ценности документа?

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

По степени важности (Устав, планы, бюджет, политики, стандарты, процедуры, прочие документы).

По уровню взаимодействия:

•Взаимодействие ИТ с внешними организациями;

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

•Взаимодействие внутри ИТ департамента;

Методы и техники

Можно руководствоваться различными методами внедрения:

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

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

•«Техника постепенного улучшения» представляет из себя следующую последовательность действий:

•Выбираете минимальный набор документов;

•Заполняете документ на основе здравого смысла;

•Если что-то кажется лишним, отбрасывайте;

•Оцениваете, сможете ли достичь нужных результатов;

•Если нет, то включите недостающие разделы;

•Заполните их и снова проведите оценку;

•И так далее до достижения результатов.

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

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

•Разрешение конфликта интересов происходит согласно процедуре в два этапа: инициатор и ИТ директор привлекают департамент внутреннего аудита. Если конфликт не разрешен, то запрос эскалируется на ИТ комитет.

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

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

•ИТ ссылается на документ, разработанный в соответственном функциональном департаменте (документы по кадрам, закупкам и т п).

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

•При разрешении конфликтов в различных документах можно руководствоваться принципами наследования «Сверху вниз» и приоритета «Устав — политика — процедура — инструкция».

процессы управления ИТ сервисами

Полноценное управление ИТ сервисами описывается в рекомендациях ITILv3 и CobiT. Основываясь на рекомендациях в книги рассмотрим следующие процессы:

Перечень вопросов, регламентирующих ИТ процессы

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

•Назначение — Определение процесса, под-процесса или вид деятельности, и отвечает на вопрос ЧТО (WHAT);

•Цели — Определяет цели и задачи процесса, отвечает на вопрос ЗАЧЕМ (WHY) необходима та или иная деятельность;

•Область применения — Определяет зону применения данного процесса, отвечает на вопрос КОГДА (WHEN). Определяет триггеры для срабатывания того или иного под-процесса или временные рамки;

•Зона ответственности — Определяет зоны ответственности для позиций или группы, отвечает на вопрос КТО (WHO);

•Процедуры- Процедуры, связанные с процессом, отвечает на вопрос КАК (HOW). Определяет перечень активности и механизмы для выполнения процесса;

•Критические Факторы Успеха (Critical Success Factors CSF) — Определяют, что должно произойти если процесс, сервис или проект будет успешным. Формируются критериями результативности (KGI).

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

•Критерии эффективности (KPI) — Определяют критерии и метрики эффективности процессов или деятельности, используемых для достижения целей. Как правило формируются из метрик и показателей, которые можно объективно измерить. Как пример, снижение количества инцидентов, ошибок и т п.

•Карта процесса — Представляет из себя визуальное описание процесса и деятельности в его рамках.

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

Cтандарт ISO/IEC 20000—1: 2011 рекомендует наличие следующих документов:

•Procedure for Communication

•Procedure for Document Control

•Procedure for Control of Records

•Procedure for Internal Audit

•Procedure for Improvements

•Policy & Procedure for Service Management

•Procedure for Delivery of New Changes

•Policy & Procedure for Management Review

•Procedure for Service Continuity

•Procedure for Budgeting & Accounting Services

•Policy & Procedure for Capacity Management

•Policy & Procedure for Incident Management

•Procedure to Manage Service Compliance

•Policy & Procedure for Supplier Management

•Policy & Procedure for Problem Management

•Policy & Procedure for Configuration Management

•Procedure for Organization Security

•Procedure for Training

•Policy & Procedure for Availability Management

•Visitor Policy

•Policy for Business Relationship Management

•Change Management Policy

•Information Security Policy

•Internet Policy

•Release Management Policy

•Standard Operation Procedures (SOP) for Group Internet & IT Resource Use Procedure

•SOP for E-Mail & Messenger Use

•SOP for Service Continuity Testing

•SOP for Personnel Recruitment

•SOP for Service Reporting

•SOP for Risk Management

•SOP for Business Relationship Management

•SOP for Change Control Management

•SOP for Release & Deployment

•Job Descriptions

Структура документа «ИТ Стратегия»

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

Введение

•Цели работы, ограничения и подход — Здесь кратко формулируется назначение документа, определяется его позиционирование для работы ИТ-службы и бизнес-подразделений, приводятся ссылки на другие документы (описание архитектуры, план проектов).

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

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

Целевое состояние информационных систем

•Целевая архитектура предприятия (позиционирование/ оценка/ важность) — Для основных направлений бизнеса приводится резюме по развитию, сохранению или замене соответствующих прикладных систем. Этот раздел не предназначен для описания технических деталей.

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

•Инфраструктура — При необходимости развития инфраструктуры приводится краткая характеристика направлений развития (модернизация серверов, создание глобальных сетей и т.п.)

Целевая система управления ИТ-ресурсами

•Целевая система управления ИТ ресурсами — Основные направления совершенствования процессов управления ИТ, оценки качества и целевые показатели работы ИТ.

•Организационные изменения — Возможные изменения в структуре управления ИТ, роль CIO. Организация стратегического управления ИТ.

•Взаимодействие — Реализация модели взаимодействия между ИТ- и бизнес подразделениями.

•Сорсинг — Стратегия выбора исполнителей и поставщиков услуг. Развитие персонала внутренней ИТ службы.

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

План перехода

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

•Варианты и риски — Возможные варианты стратегии в зависимости от объемов финансирования и вариантов развития бизнеса, анализ рисков. Оценка готовности организации к реализации данной стратегии.

•Выбор проектов — Классификация и список важнейших проектов на ближайшие 1—3 года, сгруппированных по категориям. Цель — дать краткое неформальное описание в рамках одного сводного документа (цели, задачи, сроки), а также подчеркнуть вопросы взаимозависимости проектов.

Структура документа «Устав ИТ»

Структура ИТ устава может содержать следующие пункты:

•Общие положения

•Цели документа

•Принятые сокращения и определения

•Сфера действия документа

•Аудитория

•Организация работы с документом

•Цели ИТ департамента

•Задачи ИТ департамента

•Функции ИТ департамента

•Структура ИТ департамента

•Роли и ответственности

•Управление коммуникациями

•Порядок разрешения конфликтов

•Показатели эффективности и критерии оценки деятельности

•Контроль документа

•Контроль версии документа

Структура документов «Политики»

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

•Цели;

•Общие положения;

•Ответственность;

•Описание деятельности;

•Ссылки на документы;

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

•Общие положения

•Цели документа

•Принятые сокращения и определения

•Сфера действия документа

•Аудитория

•Организация работы с документом

•Цели политики (процесса)

•Задачи политики (процесса)

•Процессы и процедуры

Под-процесс 1 (процедура 1)

Под-процесс 2 (процедура 2)

Под-процесс N (процедура N)

•Метрики политики (процесса)

•Роли и ответственности

•Управление коммуникациями

•Порядок разрешения конфликтов

•Влияние при отсутствии документированной политики

•Риски при внедрении и сопровождении политики

•Ключевые факторы успеха внедрения и сопровождения

•Показатели эффективности и критерии оценки деятельности

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

•Контроль документа

•Контроль версии документа

Структура документа «Архитектура Сервиса»

Детальная Архитектура ИТ сервиса может содержат:

•Название

•Назначение

•Требования

•Ограничения

•Архитектура (физическая и логическая)

•Инфраструктура

•Зависимости и окружения

•Лицензирование

•Мощности

•Масштабирование

•Отказоустойчивость и восстановление

•Резервирование

•Архивирование

•Система обновления

•Роли и ответственности

•Оценка рисков

•Тестирование

•Внедрение

•Установка

•Конфигурирование

•Сопровождение

•Стандартные Операционные Процедуры

•Требования к сотрудникам

•Стоимость

•Индикаторы производительности

•Аудит и контроль логов

•Мониторинг и метрики сервиса

•Управление

•Отчетность

•Рекомендации

•Выводы и уроки

•Дополнения и замечания

СТРАТЕГИЧЕСКИЕ ДОКУМЕНТЫ ИТ

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

Устав ИТ Департамента

ОБЩИЕ ПОЛОЖЕНИЯ

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

•Действующим законодательством и иными правовыми актами;

•Нормативной документацией Контролирующих органов;

•Уставом организации;

•Уставом ИТ департамента;

•Внутренними документами организации;

•Рекомендациями практик и стандартов, принятых в отрасли;

•Рекомендациями практик и стандартов, принятых в сфере ИТ;

ЦЕЛИ ДОКУМЕНТА

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

ПРИНЯТЫЕ СОКРАЩЕНИЕ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•ИТ — Информационные Технологии

•ИБ — Информационная Безопасность

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

ЦЕЛИ ИТ ДЕПАРТАМЕНТА

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

•Организация ИТ инфраструктуры организации на уровне, обеспечивающим конкурентное преимущество организации

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

• Обеспечение прозрачности функционирования ИТ департамента

ЗАДАЧИ ИТ ДЕПАРТАМЕНТА

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

•Организация работы ИТ департамента;

•Разработка Стратегического плана и бюджета ИТ;

•Разработка Оперативных планов и бюджета ИТ;

•Разработка руководящей документации ИТ департамента;

•Соответствие ИТ архитектуры требованиям бизнеса;

•Выбор технологической платформы ИТ инфраструктуры;

•Обеспечение бесперебойного функционирования ИТ инфраструктуры и ее компонентов на требуемом уровне;

•Соблюдение требований Информационной Безопасности;

•Выполнение проектов, связанных с ИТ инфраструктурой;

•Обеспечение мониторинга ИТ инфраструктуры;

•Оптимизация ИТ инфраструктуры и процессов;

ФУНКЦИИ ИТ ДЕПАРТАМЕНТА

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

•Планирование, дизайн, внедрение, сопровождение, улучшение и вывод из эксплуатации компонентов ИТ инфраструктуры;

•Установка, настройка, техническое сопровождение и обслуживание компонентов ИТ инфраструктуры;

•Диагностика и устранение неисправностей компонентов ИТ инфраструктуры;

•Разработка политик, стандартов, процедур и инструкций связанных с функционированием компонентов ИТ инфраструктуры;

•Разработка и сопровождение Планов: Непрерывности Бизнеса, Восстановления после катастроф, Восстановления Бизнеса и т п;

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

•Координация работ с поставщиками и разработчиками;

•Координация работ с подрядчиками и субподрядчиками;

•Оказание содействия при проведении аудита;

•Контроль за соблюдением нормативных документов ИТ;

•Предоставление отчетности по функционированию ИТ;

СТРУКТУРА ИТ ДЕПАРТАМЕНТА

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

•Отдел ИНФРАСТРУКТУРЫ — отдел, отвечающий за функционирование компонентов ИТ инфраструктуры

•Отдел ПОДДЕРЖКИ ПОЛЬЗОВАТЕЛЕЙ — отдел, отвечающий за сопровождение компонентов ИТ инфраструктуры на уровне пользователей,

•Отдел РАЗРАБОТКИ И ПРОГРАММИРОВАНИЯ — отдел, отвечающий за разработку, внедрение и сопровождение специализированного программного обеспечения, бизнес приложений и их интеграцию.

•Отдел ИТ БЕЗОПАСНОСТИ — отдел, отвечающий за функционирование элементов Информационной Безопасности компонентов ИТ инфраструктуры.

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

•Отдел ИНФРАСТРУКТУРЫ

•Подразделение Системного Администрирования

•Подразделение Сетевого Администрирования

• Подразделение Администрирования Приложений и СУБД

Отдел ПОДДЕРЖКИ ПОЛЬЗОВАТЕЛЕЙ

Отдел РАЗРАБОТКИ И ПРОГРАММИРОВАНИЯ

•Подразделение разработчиков

•Подразделение дизайнеров

•Подразделение бизнес аналитиков

•Подразделение разработчиков СУБД

• Подразделение интеграции

Отдел ИТ БЕЗОПАСНОСТИ

•Подразделение защиты инфраструктуры

• Подразделение защиты приложений

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

•ИТ архитектор

• Менеджер управления проектами

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

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой определены следующие роли:

ИТ КОМИТЕТ — В состав ИТ комитета входит совет директоров (руководители) организации. Кроме этого в состав ИТ комитета входят директора департаментов ИТ и ИБ. Роль ИТ комитета:

•Постановка целей и задач перед ИТ департаментом;

•Утверждение стратегических и оперативных планов ИТ;

•Утверждение стратегических и оперативных бюджетов ИТ;

•Утверждение руководящих документов ИТ департамента;

• Контроль выполнения целей и задач;

Основные принципы в работе ИТ комитета:

•Принятие решения происходит на основе голосования;

•Состав участников голосования должен быть не четный;

•Принятие решения определяется большинством голосов;

•Генеральный директор имеет право блокировать принятие решения;

•Директор ИТ не участвует в голосовании. Он может рекомендовать возможные ИТ решения.

•Директор ИБ не участвует в голосовании.

•Все решения ИТ комитета должны быть документированы.

Директор ИТ — является непосредственным руководителем ИТ департамента. Непосредственно подчиняется генеральному директору организации. Роль и ответственность ИТ директора:

•Постановка задач внутри ИТ департамента;

•Управление ИТ департаментом;

•Предоставление отчетов для ИТ комитета;

•Взаимодействие м другими подразделениями организации;

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

•Обсуждение и анализ технических аспектов требований и задач;

•Формирование технического решения;

Основные принципы в работе экспертной группы:

•Решение группы носит рекомендательный характер;

•Участники голосования имеют равные права;

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

•Собрания экспертной группы носить нерегулярный характер, и собирается только по необходимости, или как часть проектной команды;

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

КОММУНИКАЦИЯ

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

•Департамент Информационной Безопасности — по вопросам информационной безопасности. Департамент Информационной Безопасности является владельцем сервисов (services owner), связанных с вопросами безопасности. ИТ департамент является управляющим сервисами (services manager).

•Финансовый департамент — по финансовым вопросам.

•Департамент Управления Кадрами — по вопросам управления персоналом, набор, обучение сотрудников и т п.

•Департамент закупок и снабжения — по вопросам закупки, поставки, гарантированного сопровождения ИТ активов.

•Административный департамент– по вопросам сопровождения систем обеспечения ИТ инфраструктуры.

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

РАЗРЕШЕНИЕ КОНФЛИКТОВ

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

•При возникновении конфликта директор ИТ департамента взаимодействует с главой соответствующего департамента. Если конфликт не удалость разрешить, то руководители обращаются к департаменту Внутреннего аудита (горизонтальная эскалация).

•Если и на этом этапе не удалось разрешить конфликт, то он эскалируется на ИТ комитет (вертикальная эскалация).

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности департамента являются:

•Надежная и безотказная работа всех составляющих ИТ инфраструктуры организации;

•Отсутствие претензий со стороны сотрудников подразделений организации;

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

•Удовлетворенность руководства организации;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

Стратегия Информационных Технологий

ОБЩИЕ ПОЛОЖЕНИЯ

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

ЦЕЛИ ДОКУМЕНТА

Внести ясность в концепцию ИТ департамента, формирование ИТ архитектуры. Цели документа:

•Формирование концепции и принципов организации ИТ;

•Своевременное реагирование на изменения бизнеса;

•Повышение эффективности взаимодействия ИТ и бизнеса;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

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

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

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

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

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

СТРАТЕГИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Стратегия ИТ представляет из себя следующие аспекты:

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

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

•Формирование единой ИТ архитектуры организации;

•Формирование единой ИБ архитектуры организации;

•Построение собственного дата центра;

•Консолидация вычислительных ресурсов;

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

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

• Обеспечение прозрачности деятельности ИТ;

СТРАТЕГИЧЕСКИЕ ЗАДАЧИ ИТ

Задачи ИТ департаменту со стороны бизнеса ставится ИТ комитетом. Основные стратегические задачи:

•Организация работы ИТ департамента;

•Сбор и анализ требований и ограничений бизнеса;

•Разработка Стратегического плана и бюджета ИТ;

•Разработка Оперативных планов и бюджетов ИТ;

•Разработка руководящей ИТ документации;

•Выбор технологической платформы для ИТ инфраструктуры;

•Разработка проекта ИТ Архитектуры Предприятия;

•Построение ИТ Архитектуры Предприятия;

•Сопровождение ИТ на требуемом уровне;

•Обеспечение требуемого уровня Информационной Безопасности;

•Сопровождение бизнес проектов, по вопросам ИТ;

•Оптимизация и модернизация ИТ процессов и инфраструктуры;

РОЛИ И ОТВЕТСТВЕННОСТИ

Определены следующие роли и ответственности:

•ИТ КОМИТЕТ — В состав комитета входит совет директоров организации или направлений бизнеса. Роль и ответственность:

•Постановка стратегических целей и задач перед ИТ;

•Утверждение стратегических целей и задач перед ИТ;

•Контроль выполнения стратегических целей и задач ИТ;

Директор ИТ департамента — является непосредственным руководителем ИТ департамента. Непосредственно подчиняется генеральному директору организации и ИТ комитету. Роль:

•Постановка задач перед ИТ департаментом;

•Управление ИТ департаментом;

•Контроль исполнения поставленных целей и задач;

•Предоставление отчетов;

•Взаимодействие с другими подразделениями организации;

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

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности департамента являются:

•Надежная и безотказная работа всех составляющих ИТ;

•Отсутствие претензий со стороны сотрудников организации;

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

• Удовлетворенность руководства организации;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

Архитектура Информационных Технологий

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

План Непрерывности Бизнеса

План/Политика Непрерывности Бизнеса (Business Contingency Plan), определяет порядок реагирования на непредвиденные обстоятельства, ведущие к частичному или полному отказу ИТ сервисов, и их влияние на бизнес. Фокусирует свое внимание на сервисах, отказах и сбоях компонентов инфраструктуры. План определяет шаги, необходимые для восстановления одной или нескольких услуг, события, которые являются основанием для его инициации, людей, которые должны быть задействованы, средства коммуникаций и т. п. Деятельность включает в себя взаимодействие ИТ и бизнеса.

ОБЩИЕ ПОЛОЖЕНИЯ

Данный документ определяет План Непрерывности Бизнеса (Business Contingency Plan BCP) в организации. Документ является стратегическим документом организации. Документ должен соответствовать следующим требованиям:

•Действующему законодательству и иными правовыми актам;

•Нормативной документацией Контролирующего органа;

•Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами;

•Рекомендациям практик и стандартов, принятых в отрасли;

•Рекомендациям практик и стандартов, принятых в ИТ сфере;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•Уровень воздействия (impact) — границы воздействия инцидента на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

•Уровень срочности (urgency) — степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) — определяет важность инцидента и порядок его разрешения.

•Обходное решение (work around) — действия, позволяющие временно или постоянно устранить инцидент или его причины.

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

•Анализ Бизнес Процессов (Business Environment Analysis, BEA) — анализ функционирования бизнес процессов и их связь с ИТ;

•Анализ Рисков (Risk Analysis, RA) — экспертная оценка возможных угроз, классификация рисков, вероятность их возникновения, уровень воздействия и механизмы реагирования;

•Оценка Воздействия на Бизнес (Business Impact Analysis, BIA) — анализ Информационной Системы или сервиса на предмет воздействия на бизнес процессы организации;

•Анализ Отказа Сервиса (Service Failure Analysis SFA) — Анализ Информационной Системы или услуги на предмет взаимосвязи с другими системами. Включает в себя анализ воздействия на сервис отказ других систем и воздействие на другие сервисы отказ данного;

•Анализ Отказа Компонентов (Component Failure Impact Analysis CFIA) — анализ сценариев отказа компонентов сервиса;

•Уровень состояния сервиса (Service Delivery Objective SDO) — показатель состояния сервиса на текущий момент. Для каждого сервиса имеется собственный набор атрибутов. В общем случае в качестве таких атрибутов выступает: Доступность, целостность и безопасность. Может характеризоваться как «Стандартный», «Приемлемый», «Неудовлетворительный», «Недоступный» и т п;

•Максимально допустимое время сбоя (Maximum Acceptable/Allowable Outage MAO) — Максимально допустимым отключением является время, в течение которого может пройти до того, как неблагоприятное воздействие станет неприемлемым
или невыносимо для предоставления бизнес услуг, продуктов или выполнение бизнес деятельности. Схожие термины: Максимально возможный простой (Maximum Allowable Downtime MAD) или (Maximum Tolerable Downtime MTD).

•Точка Восстановления (Recovery Point Objective RPO) — определяет допустимый уровень потерь;

•Время Восстановления (Recovery Time Objective RTO) — определяет допустимое время на востановление;

•Уровень Восстановления (Recovery Level Objective RLO) — определяет уровень восстановления. Как пример может быть на уровне виртуальной машины, приложения или данных.

ЦЕЛИ ДОКУМЕНТА

Внесения ясность в организацию процесса управления непрерывностью бизнеса. Цели документа:

•Формирование концепции, принципов и организации процесса управления непрерывностью бизнеса в организации;

•Гарантировать непрерывность бизнеса в установленных рамках;

•Повышение эффективности взаимодействия ИТ и бизнеса;

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

Основные цели политики управления непрерывностью бизнеса:

•Своевременное реагирование на инциденты и скорейшее восстановление работы бизнеса;

•Формирование процесса управления непрерывностью бизнеса;

•Разработка необходимых процедур, стандартов и метрик;

•Обеспечение прозрачности функционирования ИТ для бизнеса;

•Снижение негативного влияния сбоев на бизнес;

•Рациональное использование ИТ ресурсов;

•Повышения удовлетворенности бизнеса работой ИТ;

•Снижение убытков, связанных со сбоями ИТ;

•Сокращение времени простоя бизнеса;

•Сокращение времени работ по восстановлению бизнеса;

ЗАДАЧИ ПРОЦЕССА УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

Можно определить следующие задачи по управлению непрерывностью бизнеса:

•Организация процесса управления непрерывностью бизнеса;

•Классификация сбоев;

•Классификация воздействия, срочности и приоритета;

•Классификация метрик и показателей работы процесса;

•Определение ролей и уровня вовлеченности сотрудников;

•Организации деятельности по своевременному обнаружению;

•Своевременное информирование сотрудников организации;

•Формирование Плана Непрерывности Бизнеса;

•Формирование сценариев сбоев;

•Организации деятельности по устранению сбоев;

•Организация деятельности по восстановлению бизнеса;

•Организации деятельности по расследованию причин сбоя;

•Организации деятельности по коммуникации;

•Организации деятельности по регистрации сбоев;

•Организации взаимодействия с другими ИТ процессами;

•Оптимизация процесса управления непрерывностью бизнеса;

•Организация сценариев тестирования;

ПРОЦЕСС УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

Основные принципы можно охарактеризовать как:

•Для каждого ИТ сервиса на этапе проектирования должен быть определен механизм непрерывности сервиса;

•Для каждого ИТ сервиса на этапе сопровождения должен быть разработан план обеспечения непрерывности сервиса;

•Для каждого бизнес процесса по возможности должны быть разработаны «резервный» и «аварийный» планы;

•Процедуры восстановления должны быть прописаны в архитектуре сервиса;

•Метрики должны быть прописаны в архитектуре сервиса;

•Ответственные ИТ сотрудники обязаны незамедлительно реагировать для обеспечения непрерывности сервисов;

•Выборочно, не реже одного раза в год, должно проводиться тестирование плана непрерывности;

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

•Обнаружение и регистрация

•Классификация и первоначальный анализ

•Расследование и диагностика

•Устранение

•Закрытие

Для построения эффективного процесса управления непрерывностью бизнеса необходимо наличие следующих входных данных:

•Наличие каталога предоставляемых ИТ сервисов;

•Детальная архитектура ИТ сервисов;

•Процедуры по сопровождению ИТ Сервисов;

•Каналы поступления информации;

•Соглашения по уровню предоставлению услуг и метрики;

•Определены группы поддержки;

•Определены каналы обратной связи и коммуникации;

•Наличие компонентной базы ИТ инфраструктуры;

При функционировании процесса управления непрерывностью бизнеса формируются следующие выходных данные:

•Запросы на обслуживание;

•Запросы на изменения;

•Регистрация проблем;

•Записи по инцидентам;

•База знаний;

•Отчеты;

•Сообщения;

•«Резервные» и «Аварийные» планы;

•Инициализация проектов по оптимизации ИТ и бизнеса;

Необходимы следующие инструменты:

•Инструменты для диагностики;

•Инструменты по устранению;

•Инструменты для регистрации;

ИНИЦИАЛИЗАЦИЯ И РЕГИСТРАЦИЯ

Под-процесс обнаружения и регистрации является триггером для запуска процесса. В качестве источников поступления информации о сбое могут выступать:

•Процесс управления событиями;

•Процесс управления инцидентами;

•Автоматизированные средства мониторинга инфраструктуры;

•Информация от сотрудников организации;

•Информация от поставщиков услуг;

•Информация от партнеров;

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

•Анализ Бизнес Процессов (Business Environment Analysis, BEA);

•Анализ Рисков (Risk Analysis, RA);

•Оценка Воздействия на Бизнес (Business Impact Analysis, BIA);

•Анализ Отказа Сервиса (Service Failure Analysis SFA);

•Анализ Отказа Компонентов (Component Failure Impact Analysis CFIA);

•Оценка влияния на целевую систему;

•Уровень состояния сервиса (SDO);

•Максимально допустимое время сбоя (MAO, MAD или MTD);

•Точка Восстановления (RPO);

•Время Восстановления (RTO);

•Уровень Восстановления (RLO);

•Последовательность действий по восстановлению;

РАССЛЕДОВАНИЕ И ДИАГНОСТИКА

Расследование и диагностика может включать в себя расследование причин сбоя и определение наиболее оптимальных вариантов восстановления.

ОПРЕДИЛЕНИЕ ДЕЙСТВИЙ И МЕХАНИЗМОВ

Механизмы и план действий может быть следующий:

•Если не происходит деградация качества, восстановление выполняется в штатном режиме;

•Если деградация качества в пределах норм, восстановление выполняется в штатном режиме;

•Если деградация качества ниже норм, необходимо проинформировать владельца сервиса. Восстановление сервиса начать в как можно быстрее;

•в случае полного отказа, необходимо проинформировать владельцев текущего и зависимых сервисов. Восстановление начать немедленно. На время восстановления, перейти на «резервный» или «аварийный» план работы бизнеса;

УСТРАНЕНИЕ

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

•Перезапуск службы или сервиса;

•Перезагрузка сервера;

•Восстановление из резервной копии;

•Переустановка;

•Замена компонентов;

•Восстановление или переустановка может происходить:

•На уровне данных или конфигурации;

•На уровне приложения;

•На уровне операционной системы;

•На уровне виртуальной машины;

После устранения неисправностей необходимо:

•Проверить работоспособность сервиса;

•Проинформировать владельца сервиса;

•Перейти на «штатный» режим работы;

•Обновить информацию;

ЗАКРЫТИЕ

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

МЕТРИКИ ПРОЦЕССА

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

•Количество сбоев;

•Адекватность действий по восстановлению;

•Время восстановления в рамках регламента;

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли:

•Владелец сервиса. Принятие решений (А);

•Менеджер сервиса. Восстановление сервиса в рамках принятого соглашения. Взаимодействие с владельцем сервиса (R);

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПРОЦЕССА

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

•Хаотичный порядок реагирования ИТ при сбоях;

•Хаотичный порядок реагирования сотрудников при сбоях;

•Отсутствие прозрачности по функционированию сервисов;

•Не эффективное использование ИТ ресурсов;

•Финансовые и репутационные потери для бизнеса;

РИСКИ ПРИ ВНЕДРЕНИИ И СОПРОВОЖДЕНИИ ПРОЦЕССА

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

•Отсутствие поддержки со стороны руководства организации;

•Недостаточный уровень готовности организации и сотрудников;

•Отсутствие необходимых ресурсов, для внедрения процесса;

•Недостатки и ограничения бизнес процессов;

•Нехватка знаний и навыков у специалистов ИТ департамента;

•Недостатки и ограничения информационных системы;

•Недостатки и ограничения сопутствующей ИТ инфраструктуры;

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА ВНЕДРЕНИЯ ПРОЦЕССА

Ключевые факторы успеха при внедрении и сопровождении процесса управления непрерывностью бизнеса:

•Пристальное внимание к процессу;

•Реалистичные цели;

•Оптимальные бизнес процессы;

•Наличие измеряемых метрик и показателей;

•Высокий уровень квалификации сотрудников ИТ;

•Приемлемый уровень осведомленности сотрудников;

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности являются:

•Снижение времени недоступности ИТ для бизнеса;

•Снижение времени восстановления ИТ сервиса;

•Отсутствие претензий со стороны сотрудников;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•Политика, Стандарты и Процедура «Управления Инцидентами»;

•Политика, Стандарты и Процедура «Управления Проблемами»;

•Политика, Стандарты и Процедура «Управления Изменениями»;

•Политика, Стандарты и Процедура «Резервного Копирования»;

•Детальная Архитектура по всем ИТ сервисам;

•Рекомендации стандарта ISO 22301 «Business Continuity»;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

План Восстановления после сбоя

Плана Восстановления после Сбоя (Disaster Recovery Plan). Представляет из себя план восстановления инфраструктуры компании после возникновения аварии, частичной или полной потери ИТ сервиса или его компонентов. Фокусирует свое внимание на воздействиях и их влияние на комплексную ИТ инфраструктуру и бизнес процессы организации. План определяет порядок, сценарии и правила реагирования при возникновении чрезвычайных ситуаций, таких как пожар, наводнение, землетрясение и т п. Как правило, содержит наиболее возможные сценарии чрезвычайных ситуаций и реакцию на них. План должен состоять как минимум из четырех компонентов:

•Сценарии — перечень предполагаемых чрезвычайных ситуаций.

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

•Управление инцидентами — определяет методы, необходимые для смягчения или уменьшения размера происшествия.

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

ОБЩИЕ ПОЛОЖЕНИЯ

Данный документ определяет План Восстановления после Сбоев (Disaster Recovery Plan DRP) в организации. Документ является высокоуровневым, стратегическим руководящим документом. Документ должен соответствовать следующим требованиям:

•Действующему законодательству и иными правовыми актам;

•Требованиям контролирующих органов;

•Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами;

•Рекомендациям практик и стандартов принятых в отрасли;

•Рекомендациям практик и стандартов принятых в ИТ сфере;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•Уровень воздействия (impact) — границы воздействия инцидента на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

•Уровень срочности (urgency) — степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) — определяет важность инцидента и порядок его разрешения.

Обходное решение (work around) — действия, позволяющие временно или постоянно устранить инцидент или его причины.

ЦЕЛИ ДОКУМЕНТА

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

•Формирование концепции, принципов и организации процесса реагирования на сбой и аварии для обеспечения непрерывности бизнеса в организации;

•Повышение эффективности взаимодействия ИТ и бизнеса;

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

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА

Основные цели можно определить, как:

•Своевременное реагирование;

•Скорейшее восстановление;

•Формирование процесса реагирования на катастрофы;

•Определение процедур, стандартов и метрик;

•Обеспечение прозрачности функционирования ИТ;

•Снижение негативного влияния сбоев на бизнес;

•Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников;

•Снижение убытков, связанных со сбоями;

•Сокращение времени простоя бизнеса;

•Сокращение времени восстановления бизнеса;

ЗАДАЧИ ПРОЦЕССА

Можно определить следующие задачи :

•Организация процесса;

•Классификация воздействий и сбоев;

•Определение метрик и показателей;

•Определение обязанностей и уровня вовлеченности сотрудников;

•Организации деятельности по своевременному обнаружению;

•Формирование Плана Восстановления после сбоя;

•Формирование сценариев чрезвычайных ситуаций;

•Организации деятельности по устранению сбоев;

•Организации деятельности по устранению последствий;

•Организация деятельности по восстановлению бизнеса;

•Организации деятельности по расследованию причин сбоя;

•Организации деятельности по коммуникации;

•Организации деятельности по реагированию;

•Организации взаимодействия с другими процессами;

•Оптимизация процесса восстановления после сбоя;

•Организация сценариев тестирования;

ПРОЦЕСС ВОССТАНОВЛЕНИЯ ПОСЛЕ СБОЕВ

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

Основные принципы можно охарактеризовать как:

•Для каждого ИТ сервиса на этапе проектирования должен быть определен механизм непрерывности сервиса;

•Для каждого ИТ сервиса на этапе сопровождения должен быть разработан план обеспечения непрерывности сервиса;

•Для каждого бизнес процесса должны быть разработаны «резервный» и «аварийный» планы;

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

•Ответственные сотрудники обязаны незамедлительно реагировать для обеспечения непрерывности или восстановления;

•Должно проводиться тестирование плана;

СЦЕНАРИЙ №1 «Воздействие стихийных бедствий»

•Описание Риска: Потеря здания головного офиса;

•Вероятность события: Низкая;

•Вероятный причины: Пожар, землетрясение, наводнение и т п;

•Влияние: Очень высокое;

•Затронутые функции: Вся деятельность бизнеса;

•Оценка рисков: Высокая;

•Место сбора: Сотрудники головной офис собираются в филиале «Филиал №1»;

•Смягчение последствий: Предопределенные и испытанные политики, процедуры и план действий на местах;

•Команда восстановления: Комитет по реагированию на Чрезвычайные Ситуации (Кризисный Комитет), Группы реагирования от каждой бизнес функции, ИТ, Безопасности;

Цели команд восстановления:

•Этап восстановления №1 т.е. восстановить минимальный уровень обслуживания в течении 24 часов;

•Этап восстановления №2 — восстановление полного уровня обслуживание всех бизнес функций в течении 72 часов;

Функции и обязанности групп восстановления:

•Кризисный Комитет — Принятие решения по переходу на резервный план, выполнение плана восстановления, и принятие решений по дальнейшему управлению, в полоть до полного восстановления;

Группы реагирования от каждой бизнес функции — выполнение работ по переходу на резервный план и восстановлению операций.

План действий: <детальное описание>

Заключение и рекомендации: <детальное описание>

ПРОЦЕСС ТЕСТИРОВАНИЯ

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

•Получение подтверждений работоспособности планов;

•Проверка достаточности методического и технического обеспечения;

•Получение необходимых навыков и знаний;

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

•Настольная проверка (Tabletop);

•Имитация (Imitation);

•Полное тестирование (Full business continuity testing);

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

Обслуживание и обновление планов

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

•Изменение ИТ инфраструктуры;

•Изменение организационной структуры компании;

•Изменения в законодательстве;

•Обнаружение недостатков в планах при их тестировании;

Чтобы сохранить актуальность планов, необходимо выполнять следующие действия:

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

•Проводить регулярные теоретические и практические тренинги для сотрудников организации, по выполнению плана;

•Интегрировать вопросы непрерывности бизнеса в процесс управления изменениями компании;

МЕТРИКИ ПРОЦЕССА

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

•Адекватность действий по восстановлению;

•Время восстановления в рамках регламента;

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПЛАНА

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

•Хаотичный порядок реагирования ИТ;

•Хаотичный порядок реагирования сотрудников;

•Отсутствие прозрачности функционирования ИТ и бизнеса;

•Не эффективное использование ИТ ресурсов;

•Финансовые и репутационные потери для бизнеса;

РИСКИ ПРИ ВНЕДРЕНИИ И СОПРОВОЖДЕНИИ

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

•Отсутствие поддержки со стороны руководства организации;

•Недостаточный уровень готовности организации и сотрудников;

•Отсутствие необходимых ресурсов, для внедрения процесса;

•Недостатки и ограничения бизнес процессов;

•Нехватка знаний и навыков у специалистов ИТ департамента;

•Недостатки и ограничения информационных системы;

•Недостатки и ограничения сопутствующей ИТ инфраструктуры;

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА ВНЕДРЕНИЯ ПРОЦЕССА

Ключевые факторы успеха:

•Пристальное внимание к процессу;

•Реалистичные цели;

•Оптимальные бизнес процессы;

•Наличие измеряемых метрик и показателей;

•Высокий уровень квалификации сотрудников ИТ;

•Приемлемый уровень осведомленности сотрудников;

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности являются:

•Снижение времени недоступности ИТ для бизнеса;

•Снижение времени восстановления ИТ сервиса;

•Отсутствие претензий со стороны сотрудников;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•Политика, Стандарты и Процедура «Управления Инцидентами»;

•Политика, Стандарты и Процедура «Управления Проблемами»;

•Политика, Стандарты и Процедура «Управления Изменениями»;

•Политика, Стандарты и Процедура «Резервного Копирования»;

•Детальная Архитектура по всем ИТ сервисам;

•Политика и план «Управления Непрерывностью Бизнеса»;

•Рекомендации стандарта ISO 22301 «Business Continuity»;

•Рекомендации стандарта ISO 20000 «IT Service Management»;

•Рекомендации стандартов ISO 27000 «Information Security»;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

План Восстановления Бизнеса

Плана Восстановления Бизнеса (Business Continuity Plan) имеет схожее значение, что и План Непрерывности Бизнеса (Business Contingency Plan), но фокусируется на восстановлении предоставления ИТ сервисов вне зависимости от степени воздействия. Определяет восстановление бизнеса после значительного ущерба в следствии воздействия катастроф. Фактически, данный план является продолжением деятельности «Плана непрерывности Бизнеса» + «Плана Восстановления после сбоя». Но, в отличие от них, может включать в себя стратегические изменения в каталоге ИТ сервисов после воздействия чрезвычайной ситуации. Документ может быть разбит на два плана управления непрерывностью:

•План восстановления ИТ услуг (IT Service Continuity Plan) — план, определяющий шаги, необходимые для восстановления одной или нескольких услуг. План также должен определять события, которые являются основанием для его инициации, людей, которые должны быть задействованы, средства коммуникаций и т. п.

•План восстановления бизнеса (Business Continuity Plan BCP) — план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования, людях, которые должны быть задействованы в реализации плана, средствах коммуникаций и т. п.

Примерная структура плана восстановления бизнеса:

1. Введение;

1.1. Исходная информация;

1.2. Границы действия плана;

1.3. Предпосылки создания плана;

2.Концепция;

2.1.Описание системы обеспечения непрерывности;

2.2.Описание этапов восстановления непрерывности;

2.3.Роли и их обязанности;

3.Активация плана;

3.1.Критерии и порядок активации;

3.2.Порядок уведомления заинтересованных лиц;

3.3.Порядок оценки происшествия;

4.Контроль;

5.Восстановление;

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

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

•Формирование команды по оценки ущерба;

•Оценку ущерба;

•Формирование команды по восстановление;

•Выполнение плана восстановления;

Для формирования и выполнения плана может понадобится наличие следующих команд:

•Команда по восстановлению (Restoration Team)

•Команда по оценке ущерба (Damage Assessment Team)

•Команда по спасению активов (Salvage Team)

Стратегический План и бюджет ИТ

ОБЩИЕ ПОЛОЖЕНИЯ

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

ЦЕЛИ ДОКУМЕНТА

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

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

•Своевременное реагирование на изменения или отклонения между фактическими и утвержденными планами

•Повышение эффективности взаимодействия ИТ департамента и бизнеса.

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

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

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

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

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

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

СТРАТЕГИЧЕСКИЕ ЦЕЛИ

Цели ИТ департаменту со стороны бизнеса ставится ИТ комитетом организации. Формирование Плана Стратегического развития ИТ департамента основывается на Плане Стратегического развития организации. Основные стратегические цели ИТ департамента:

•Организация ИТ инфраструктуры организации на уровне, обеспечивающим конкурентное преимущество организации

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

• Обеспечение прозрачности функционирования ИТ департамента

СТРАТЕГИЧЕСКИЕ ЗАДАЧИ

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

•Организация работы ИТ департамента

•Разработка Стратегических и оперативных планов и бюджета ИТ департамента

•Разработка руководящей документации ИТ департамента

•Построение ИТ архитектуры организации в соответствии с требованиями бизнеса

•Выбор технологической платформы для ИТ инфраструктуры

•Обеспечение бесперебойного функционирования аппаратно-программных комплексов на требуемом уровне

•Обеспечение требуемого уровня Информационной Безопасности

•Планирование и внедрение проектов, связанных с ИТ инфраструктурой

•Сопровождение ИТ инфраструктуры организации на требуемом уровне

•Обеспечение мониторинга ИТ инфраструктуры

•Оптимизация и модернизация ИТ инфраструктуры и процессов

• Координация работ с другими структурными подразделениями организации

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

КОМИТЕТ СТРАТЕГИЧЕСКОГО ПЛАНИРОВАНИЯ — В состав комитета входят руководители «С-Level» организации:

•генеральный директор

•директор финансового департамента

•директор департамента по управлению кадрами

• директор операционного департамента

Роль и ответственность комитета:

•Постановка целей и задач перед ИТ департаментом.

•Утверждение стратегических и оперативных планов ИТ департамента

•Утверждение стратегических и оперативных бюджетов ИТ департамента

•Утверждение руководящих документов ИТ департамента

• Контроль выполнения целей и задач ИТ директором.

Основные принципы в работе ИТ комитета:

•Принятие решения происходит на основе голосования

•Состав участников голосования должен быть не четный

•Принятие решения определяется большинством голосов.

•Генеральный директор имеет право блокировать принятие решения

•Директор ИТ департамента не участвует в голосовании. Его функции предоставления

•Директор ИТ департамента может рекомендовать возможные ИТ решения

•Директор департамента Информационной Безопасности не участвует в голосовании.

•Директор департамента Информационной Безопасности выполняет консультирующие функции

• Все действия и решения ИТ комитета должны быть формально документированы.

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

Роль и ответственность ИТ директора:

•Постановка задач перед ИТ департаментом

•Управление ИТ департаментом

•Предоставление отчетов для ИТ комитета

•Координация с другими департаментами по вопросам обеспечения жизнедеятельности ИТ департамента.

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

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности департамента являются:

•Надежная и безотказная работа всех составляющих ИТ инфраструктуры организации

•Отсутствие претензий со стороны сотрудников подразделений организации,

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

•Удовлетворенность руководства организации.

Контроль документа:

•Номер документа:

•Наименование документа:

•Статус документа:

•Маркер безопасности:

•Дата утверждения:

•Дата вступления в силу:

•Протокол ИТ комитета:

•Заменяет документ:

•Документ разработан:

•Дата разработки:

•Документ одобрен:

•Дата одобрения:

•Утвержден:

•Дата утверждения:

Контроль версии документа:

•Версия документа:

•Дата внесения изменений:

•Автор:

•Содержание изменений

Оперативный План и Бюджет ИТ

ОБЩИЕ ПОЛОЖЕНИЯ

Документ определяет направление деятельности, цели и задачи ИТ на 2017 год. Документ определяет цели и задачи департамента Информационных Технологий (далее используем сокращение ИТ) в организации в краткосрочной перспективе. Как правило подразумевается годовой период и является детализацией стратегического плана за определенный период времени.

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

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

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

ЦЕЛИ

1. Организационные цели ИТ

1.1. Организация работы ИТ в соответствии с требованиями холдинга и рекомендациями стандартов и практик ISO 20000, ITIL, CobIT.

1.2. Повышение уровня квалификации и навыков сотрудников ИТ.

1.3. Повышение уровня компьютерной грамотности сотрудников.

1.4. Подготовка ИТ к прохождению внешнего ИТ аудита.

2. Технические цели ИТ

2.1. Автоматизация бизнес процессов организации;

2.2. Оптимизация ИТ инфраструктуры;

2.3. Предоставление удаленной работы сотрудникам организации;

2.4. Внедрение системы управления проектами;

2.5. Внедрение системы управления заявками;

2.6. Лицензирование программного обеспечения;

ЗАДАЧИ

3. Организационные задачи ИТ

3.1. Разработка и утверждение необходимой ИТ документации (политики, процедуры, и т п) в соответствии с требованиями холдинга и рекомендациями стандартов и практик ISO 20000, ITIL, CobIT.

3.2. Исполнения плана обучения сотрудников ИТ на 2017 год.

3.3. Проведение тренингов по ИТ для сотрудников организации.

3.4. Прохождение внутреннего ИТ аудита.

4. Технические задачи ИТ

4.1. Разработка и внедрение единой Автоматизированной Системы Управления Предприятием (АСУ).

4.2. Перенос ИТ инфраструктуры организации в дата центр холдинга в соответствии с утвержденной ИТ архитектурой холдинга.

4.3. Построение решения для удаленного и безопасного доступа мобильных работников к ИТ ресурсам организации. Проект включает в себя решения на базе Windows 2012R2/Windows 2016 Direct Access для доступа к ИТ ресурсам и сети, и решения  на базе Windows 2012R2/2016 RRAS для доступа к бизнес приложению.

4.4. Внедрение системы Управления Проектами и задачами (УП).

4.5. Внедрение системы Управления Заявками (УЗ).

4.6. Лицензирование программного обеспечения организации.

ПРОЕКТНЫЙ БЮДЖЕТ ИТ на 2017 ГОД.

Согласно оперативным планам бюджет по ИТ проектам на 2017 год (в манатах):

ОПЕРАТИВНЫЙ БЮДЖЕТ ИТ на 2017 год

Оперативный бюджет ИТ на 2017 год включает в себя операционные и проектные расходы (в манатах):

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки достижения цели и задач ИТ являются:

• Надежная и безотказная работа ИТ инфраструктуры;

• Отсутствие претензий со стороны сотрудников организации;

• Отсутствие претензий со стороны руководства организации;

• Отсутствие претензий со стороны руководства холдинга;

• Отсутствие претензий со стороны контролирующих органов;

• Выполнение задач и проектов в установленные сроки и бюджет;

ПОЛИТИКИ И ПОЛОЖЕНИЯ ИТ

Управление Отношениями с бизнесом

Процесс Управления Отношениями с Бизнесом (Business Relationship Management BRM) относится к стратегическому этапу управления ИТ сервисами по рекомендации ITILv3, а данная политика является рекомендацией стандарта ISO 20000—1:2011. Процесс Управление Отношениями с Бизнесом предназначен для организации взаимодействия ИТ и бизнеса, и отвечает на такие вопросы как: Организация процесса взаимодействия ИТ с бизнесом на различных этапах управления ИТ сервисами. В зависимости от размеров и уровня организации, описание процесса может представлять из себя составную часть политик и процедур, или же отдельный документ. К критериям результативности можно отнести удовлетворенность бизнеса. Пример политики указан ниже.

ПОЛИТИКА УПРАВЛЕНИЯ ДЕЛОВЫМИ ОТНОШЕНИЯМИ

ЦЕЛИ ДОКУМЕНТА

Определяет список документов и ключевые процессы организации относительно управления деловыми отношениями. Эти политики проектированы в соответствии с требованиями управления Стандарт ISO 20000 и соблюдение их обязательные.

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Поставщик Услуг — организация или подразделение предоставляющие определенный вид услуг.

•Потребитель Услуг (заказчик) — организация или подразделение использующие определенный вид услуг. В ряде случаев потребитель и заказчик могут быть разные компании или подразделения.

•Соглашение об Уровне Предоставления Услуг (Service level Agreement SLA). Формальное соглашение между поставщиком и потребителем или заказчиком услуги или услуг. Как правило заключается когда поставщик и потребитель являются представителями различных организаций.

•Операционное Соглашение об Уровне Предоставления Услуг (Operation Level Agreement OLA). Формальное соглашение между поставщиком и потребителем или заказчиком услуги или услуг. Как правило заключается, когда поставщик и потребитель являются представителями одной организации.

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ПОЛИТИКА

Следующие ключевые моменты определены в политике:

•Должен существовать список клиентов и заинтересованных сторон для каждой ИТ услуги.

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

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

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

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

•Поставщик услуг назначает сотрудников, отвечающих за удовлетворенность клиентов.

•Уровень удовлетворенности клиента должен быть измерим.

•Владелец и менеджер процесса должен совершать действия, направленные на улучшение обслуживания.

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

В качестве показателей эффективности можно выделить:

•Отсутствие претензий со стороны клиентов;

•Отсутствие претензий со стороны контролирующих органов;

• Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих документов:

•Стандарты и Процедура «Управления Деловыми Отношениями»;

•Рекомендации стандарта ISO 20000 «IT Service Management»;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения:]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

Управление Требованиями

Процесс Управления Требованиями (Demand Management) относится к стратегическому этапу управления ИТ сервисами по рекомендации ITILv3, а данная политика является рекомендацией стандарта ISO 20000—1:2011. Процесс Управление Требованиями фокусирует свое внимание на бизнесе, их запросах и требованиях, анализ бизнес процессов и оценка потенциала по потребностям в ИТ сервисах того или иного рода. В зависимости от размеров и уровня организации, описание процесса может представлять из себя составную часть политик и процедур, или же отдельный документ. К критериям результативности можно отнести удовлетворенность бизнеса.

Управление Персоналом

Управления Персоналом (Human Resource Management) определяет организацию процесса управления сотрудниками организации и ИТ департамента в частности, и относится к стратегическому этапу управления ИТ сервисами. Политики и процедуры являются рекомендациями стандарта ISO 20000—1:2011. Цель политики управления персоналом состоит в том, чтобы определить процедуры по всему циклу управления кадрами, начинающего с кадровое планирования, отбора и принятия сотрудника, до момента его ухода из организации.

Управление Финансами

Процесс Управления Финансами (Finance Management) относится к стратегическому этапу управления ИТ сервисами, а данная политика Бюджетирования и финансового учета (Budgeting and Accounting Policy) является рекомендацией стандарта ISO 20000—1:2011. Процесс фокусирует свое внимание на управлении финансами, стоимостью ИТ активов, контроль расходов, распределение расходов на стоимость ИТ сервисов, планирование бюджета сопровождения инфраструктуры и ИТ проектов.

ПОЛИТИКА БЮДЖЕТИРОВАНИЯ И ФИНАНСОВОГО УЧЕТА

ЦЕЛИ

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

ПОЛИТИКА

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

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

•Распределение прямых и косвенных затрат на ИТ сервисы;

•Формирование стратегических и оперативных бюджетов;

•Формирование проектных бюджетов;

•Эффективный финансовый контроль;

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

•Отслеживание и контроль фактических затрат по отношению к бюджету;

•Анализировать финансовые прогнозы и управлять затратами;

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

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

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

•Объем: носитель затрат, основанный на единицах работы (например, количество заказов).

•Время: носитель затрат, основанный на отрезке времени, потраченном на определенную деятельность. Стоимость деятельности увеличивается на основе отрезка времени, требуемого для завершения деятельности.

•Сборка или продукт: стоимость, применяется непосредственно к объекту затрат (например, все затраты, связанные с данным ИТ сервисом).

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

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

ВОЗМОЖНЫЕ РИСКИ

При реализации процесса управления финансами возможно возникновения следующих рисков:

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

• Могут присутствовать многочисленное количество скрытых затрат, которые трудно оценить и распределить;

• Повышение затрат в период выполнения;

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

• Отсутствие соответствующей финансовой и управленческой культуры в организации;

Разработка Стратегии

Процесс Разработки Стратегии (Strategy Generation) относится к стратегическому этапу управления ИТ сервисами. ИТ стратегия является одним из ключевых документов при построении и сопровождении ИТ в организации.

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

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

•Количество сервисов в портфеле;

•Количество сервисов по статусам;

•Количество сервисов по типам (Бизнес/Технические);

•Количество сервисов по подразделениям организации;

•Время перехода в каталог сервисов;

•Время перехода из каталога сервисов;

•Своевременность и полнота информации;

•Отношение сервисов каталога к сервисам портфеля;

Управление Деятельностью ИТ

Процесс Управления Деятельностью ИТ направление на организацию деятельности ИТ департамента в составе организации. Включает ряд процессов, политик и т п.

Координирование Дизайна Сервиса

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

Управление Рисками

Процесс Управления Рисками (Risk Management) относится к этапу дизайна управления ИТ сервисами. Владельцами процесса как правило являются департамент Управления Рисками или департамент Безопасности. Политика рассмотрена в разделе Информационная Безопасность.

Управление Архитектурой

Процесс Управления Архитектурой (Architecture Management) относится к этапу дизайна управления ИТ сервисами. Политика должна регулировать процессы создания и утверждения ИТ архитектуры, порядок внесения изменений и триггеры их влекущие, процессы оценки адекватности и т п. Процесс может являться отдельным документом или частью различных политик и процедур.

Управление Соответствия Требованиям

Процесс Управления Соответствия Требованиям (Compliance Management) относится к этапу дизайна управления ИТ сервисами, а данная политика является рекомендацией стандарта ISO 20000—1:2011. Политика должна регулировать процессы определения и классификации требований, их сбор и анализ, порядок внесения изменений и триггеры их влекущие, процессы оценки и т п. Процесс может являться отдельным документом или частью различных политик и процедур.

Управление Каталогом Сервисов

Процесс Управления Каталогом Сервисов (Service Catalog Management) относится к этапу дизайна управления ИТ сервисами, а данная политика является рекомендацией стандарта ISO 20000—1:2011. В отличие от процесса управления портфелем сервисов, в каталоге содержатся только те ИТ сервисы, которые находятся в эксплуатации. В организации как минимум должен существовать перечень используемых ИТ сервисов. В полном виде, должна существовать политика, регулирующая процессы перехода сервисов из портфеля в каталог принятых в эксплуатацию, выхода из каталога, порядок внесения изменений и триггеры их влекущие, процессы оценки и т п. Процесс может являться отдельным документом или частью различных политик и процедур.

Управление Уровнем Сервиса

Процесс Управления Уровнем Сервиса (Service Level Management) относится к этапу дизайна управления ИТ сервисами, а политика Управления Сервисами (Service Management Policy) является рекомендацией стандарта ISO 20000—1:2011.

ПОЛИТИКА УПРАВЛЕНИЯ СЕРВИСАМИ

ЦЕЛЬ

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

ПОЛИТИКА

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

1. Управление обслуживанием должно включать в себя:

•Планирование услуг;

•Контроль уровня предоставления ИТ сервисов;

•Операции по улучшению и вывода из эксплуатации;

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

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

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

5. Каждая предоставленная услуга должна быть определена, согласована и задокументирована в одном или нескольких соглашений об уровне обслуживания (SLAs).

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

7. Договоры с поставщиками и соответствующие процедуры должны быть согласованы всеми соответствующими сторонами и зарегистрированы.

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

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

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

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

12. На основе вышеупомянутых операций должны быть идентифицированы операции улучшения.

13. Определены и согласованы с клиентом формальные процедуры обработки запросов и заявок.

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

A. Процессы управления обслуживанием

Управление ИТ услугами включает в себя следующие значения:

•Ориентация на клиента, работа в тесном сотрудничестве с ним и предоставление эффективных решений;

•Конфиденциальность информации и данных о клиентах, защищенных формальными обязательствами в договорах;

B. Политика улучшения ИТ сервисов

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

C. Политика управления уровнем обслуживания

Миссия процесса включает в себя:

•Определение услуги;

•Определение ожиданий клиентов;

•Согласование соглашений об уровне обслуживания;

•Регистрация соглашений об уровне обслуживания;

•Контроль соблюдение соглашений об уровне обслуживания;

•Периодический пересмотр всеми участвующими сторонами;

•Управление и разрешение заявок;

•Измерение удовлетворенности клиентов;

D. Политика управления отчетностью

Миссия процесса:

•Гарантирование того, что отчеты предоставлены, и информация содержащаяся в них точна и надежна;

•Предоставление отчетности и прогнозирование поведения;

E. Политика управления непрерывностью

Миссия процесса:

•Формирование ответных мер на серьезные события или бедствия, которые могут оказать серьезное влияние на уровень сервиса;

•Гарантия восстановления предоставляемых сервисов в самое короткое возможное время;

•Достижение заявленного уровня предоставления сервиса в самое короткое, возможное время от минимального до полного восстановления;

F. Политика управления доступностью

Миссия процесса:

•Гарантия доступности услуг;

•Формирование и реализация планов, по повышению доступности предоставляемых сервисов;

•Контроль доступности услуг и прогнозирование деятельности по улучшению;

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПОЛИТИКИ

Отсутствие документированной политики может привести к таким рискам и проблемам как:

• Отсутствие хорошей коммуникации с заказчиками;

• Работа ИТ не удовлетворяет реальные потребности бизнеса;

•Услуги не согласовываются с бизнес процессами;

•Нехватка ресурсов;

•Неэффективное использование ресурсов;

•Несоответствующий или противоречивый контроль соответствия соглашениям, который может препятствовать повышению качеству представления ИТ сервисов;

•Отсутствие подлинных обязательств к качеству сервиса;

Управление Доступностью

Процесс Управления Доступностью (Availability Management) относится к этапу дизайна управления ИТ сервисами, а политика Управления Доступностью является рекомендацией стандарта ISO 20000—1:2011.

ПОЛИТИКА УПРАВЛЕНИЯ ДОСТУПНОСТЬЮ

ЦЕЛЬ

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

ПОЛИТИКА

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

•Требования к доступности должны быть идентифицированы на основе соглашения на обслуживание (SLA) и оценок степени риска;

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

•Планы по доступности должны быть разработаны и пересмотрены, по крайней мере, ежегодно, чтобы гарантировать, что требования удовлетворены согласно договоренности. Эти планы должны сохраняться, чтобы гарантировать, что они отразили согласованные изменения, требуемые бизнесом;

•Планы по доступности, должны быть повторно протестированы при каждом существенном изменении в бизнес процессе или среде;

•Процесс управления изменениями должен оценить влияние любого изменения на планы по доступности сервиса;

•Доступность должна быть измерена и зарегистрирована. Незапланированный воздействия должны быть исследованы и приняты соответствующие меры по их устранению.

Управление Мощностями

ПОЛИТИКА УПРАВЛЕНИЯ МОЩНОСТЯМИ

ЦЕЛЬ

Процесс Управления Мощностями (Capacity Management) относится к этапу дизайна управления ИТ сервисами, а политика является рекомендацией стандарта ISO 20000—1:2011. Цель политики является организация и реализация процессов управления производительностью ИТ инфраструктуры.

ПОЛИТИКА

Ключевые процессы включают в себя:

•Формирование и организация процесса управления мощностями;

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

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

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

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

c) оценку ожидаемого эффекта от обновления сервиса, запросы на изменения, новые технологии и методы повышения производительности;

d) прогнозы влияние внешних изменений, например, законодательных, технологических и т п;

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

•В отчетах должны быть отражены определенные и измеряемые метрики процесса;

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

Процесс Управления Непрерывностью

Процесс Управления Непрерывностью ИТ сервисов (IT Service Continuity Management) относится к этапу дизайна управления ИТ сервисами, а политика (Service Continuity Policy) является рекомендацией стандартов ISO 20000, 27001, 27017 и 27018. Как правило включает в себя ряд ключевых политик, процедур и планов, таких как Политика / План Непрерывности Бизнеса (Business Contingency Plan BCP), План Восстановления после Сбоя (Disaster Recovery plan DRP), Политика / План Восстановления Бизнеса (Business Continuity Plan) и т п.

Управление Информационной Безопасностью

Процесс Управления Информационной Безопасностью (Information Security Management) относится к этапу дизайна управления ИТ сервисами и является рекомендацией стандартов ISO 20000, 27001, 27017 и 27018. Владельцем процесса как правило является департамент Безопасности организации. Руководящие документы по процессу рассмотрены в разделе Информационной Безопасности.

Управление Поставщиками

Процесс Управления Поставщиками (Supplier Management) относится к этапу дизайна управления ИТ сервисами, а политика является рекомендацией стандарта ISO 20000—1:2011.

ПОЛИТИКА УПРАВЛЕНИЯ ПОСТАВЩИКАМИ

ЦЕЛЬ

Политика представляет из себя группу документов относительно процесса управления поставщиками, процедур организации тендеров и закупок. Политика разрабатывается в соответствии с требованиями стандарта ISO 20000, и соблюдение ее обязательно. Как правило данная политика формируется на уровне всей организации.

ПОЛИТИКА

Политика включает в себя следующие ключевые моменты:

•Процесс управления поставщиками должен быть задокументированным;

•Требования, объем, уровень обслуживания и коммуникационные процессы, должны быть задокументированы в соглашениях о предоставлении услуг или других документах и согласованы всеми сторонами;

•Должны быть учтены рекомендации ИТ департамента по техническим аспектам;

•Коммуникация между сторонами, должна быть прозрачной и по возможности максимально документирована;

•Все роли и отношения должны быть ясно задокументированы;

•Должна быть произведена классификация поставщиков и определены критерии их выбора и оценки;

•Должен существовать механизм гарантирования того, что потребности бизнеса и договорные обязательства исполняются надлежащим образом;

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

•Должен существовать механизм и процедуры по урегулированию споров по контракту или соглашению, преждевременного разрыва или передачи услуги и т п;

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

Должен быть разработан план относительно того, как улучшить обслуживание и взаимодействие с поставщиками;

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

Планирование Внедрения и Поддержки

Процесс Планирования Внедрения и Поддержки (Transition Planning & Support Management) относится к этапу внедрения управления ИТ сервисами.

Управление Изменениями

Процесс Управления Изменениями (Change Management) относится к этапу внедрения управления ИТ сервисами и является рекомендацией стандартов ISO 2000—1:2011, 27001 & 27017 и 27018. Процесс может быть внутренним документом ИТ, ИБ или же управляться на уровне организации. Процесс управления изменениями является одним из ключевых процессов организации.

ПОЛИТИКА УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ

ЦЕЛИ

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

ПОЛИТИКА

Ключевые аспекты включают в себя;

•Процесс внесения изменений должен быть ясно определен и максимально задокументирован;

•Все запросы на изменение должны быть зарегистрированы и классифицированы;

•Запросы на изменения должны быть проанализированы на предмет риска, влияния и на бизнес, стоимости и т п;

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

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

•Все изменения должны быть проанализированы после реализации и произведена их оценка;

•Должен быть определен и реализован механизм управления авторизацией;

•Должен быть определен и реализован механизм управления авторизацией на случай чрезвычайных изменений;

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

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

•Должен присутствовать механизм и план действий по улучшению, управления изменениями;

Управление Конфигурациями и Активами

Процесс Управления Конфигурациями и Активами (Service Assets & Configuration Management) относится к этапу внедрения управления ИТ сервисами, а политика является рекомендацией стандарта ISO 20000—1:2011.

ПОЛИТИКА УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ

ЦЕЛИ

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

ПОЛИТИКА

Основные критерии включают в себя:

•Управление конфигурациями является комплексным подходом по планированию и реализации управления изменениями и конфигурациями;

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

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

•Уровень детализирования должен быть достаточен для обеспечения надлежащего контроля и обеспечения удовлетворенности потребностей бизнеса, оценки рисков, критичности и отказа компонентов сервиса;

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

•Изменения в элементах конфигурации должны быть прослеживаемыми и проверяемыми, когда это необходимо;

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

•Должна быть разработана «Базовая Конфигурация» сервиса и соответствующих элементов, перед запуском в среду эксплуатации;

•Основные копии цифровых элементов конфигурации, используемых в «рабочей» среде, должны быть размещены в безопасных физических и электронных библиотеках;

Должен быть определен механизм переноса элементов конфигурации из «тестовой» среды в «рабочую» при соблюдении информационной безопасности и целостности инфраструктуры;

•Все элементы конфигурации должны быть идентифицируемыми и зарегистрированными в Базе Данных Управления Конфигурацией (CMDB), доступ к которой и ее обновление должно строго контролироваться;

• База Данных Управления Конфигурацией должна быть активно управляемой и проверенной, чтобы гарантировать его надежность и точность. Состояние элементов конфигурации, их версий, местоположения, связанных изменений и проблем должно быть задокументировано и видимо тем, кому это разрешено и требуется;

•Процедуры аудита конфигурации включают недостатки записи, инициирование корректирующих действий и отчетность о результате;

•Должны быть разработаны механизмы и планы по улучшению, точности базы данных Управления Конфигурацией.

Управление Релизами и Установкой

Процесс Управления Релизами и Установками (Release & Deployment Management) относится к этапу внедрения управления ИТ сервисами, а также является рекомендацией стандартов ISO 20000, 27001, 27017 и 27018.

ПОЛИТИКА УПРАВЛЕНИЯ ВЕРСИЯМИ И УСТАНОВКАМИ

ЦЕЛИ

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

ПОЛИТИКА

Ключевые моменты политики включают в себя:

•Организация процесса выпуска услуг, систем, обновлений, программного и аппаратного обеспечения;

•Планы по тому, как развернуть новый релиз или обновление, должны быть согласованы и авторизованы со всеми соответствующими сторонами;

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

•Процесс управления версиями должен передать необходимую информацию процессу управления инцидентами и службе поддержки пользователей;

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

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

•Запуску новых релизов, версий или обновлений должен предшествовать механизм тестирования, проведены «приемочные» испытания;

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

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

•Анализ должен включать оценку влияния на бизнес, операционный персонал и персонала службы поддержки;

Должен присутствовать механизм по улучшению процесса;

•Все релизы и обновления должны быть классифицированы с указанием сроков и планов внедрения. Категоризация помогает уменьшить риски воздействия на бизнес. Релизы могут включить как минимум три класса:

Главная версия — содержит новую функциональность и заменяет предыдущие Незначительные и Чрезвычайные Выпуски;

Незначительный Выпуск — содержит улучшения и исправления, и заменяет предыдущие Чрезвычайные Выпуски;

Чрезвычайные Выпуски — (или «исправления») содержат исправления, чтобы решить срочные вопросы (иначе проблемы);

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

•Проблемы и заявки Бизнеса. Управление версиями работает в тесном сотрудничестве с клиентами (через CAB или иначе), чтобы удостовериться, что любые запланированные выпуски не происходят в важные периоды. Например, приводя в нерабочее состояние систему печати для обслуживания в период, когда ключевыми требованиями клиента является формирование отчетов и их распечатка;

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

•Наличие механизма и плана возврата к исходному состоянию. Ключ к успешным изменениям — тестирование реализации выпуска, и при необходимости, план восстановления к их исходному состоянию при появлении проблем.

Оценка и Тестирование

Процесс Оценки и Тестирования (Service Validation & Test Management) относится к этапу внедрения управления ИТ сервисами. Включает в себя взаимодействие департамента ИТ, Безопасности, Внутреннего Аудита и бизнес подразделений, вовлеченных в процессы запросов, изменений и выпуска релизов.

Оценка Изменений

Процесс Оценки Изменений (Change Evaluation Management) относится к этапу внедрения управления ИТ сервисами. Включает в себя взаимодействие департамента ИТ, Безопасности, Внутреннего Аудита и бизнес подразделений, вовлеченных в процессы запросов, изменений и выпуска релизов. Является частью процесса управления изменениями или оценки качества. Политика может быть частью связанных политик и процедур или отдельным документом.

Управление Знаниями

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

Управление Событиями

Процесс Управления Событиями (Event Management) относится к этапу эксплуатации управления ИТ сервисами, а политика является рекомендацией стандарта ISO 20000—1:2011. Является одним из источников входных данных для процессов управления инцидентами, проблемами, релизами и т п.

Управление Инцидентами

ОБЩИЕ ПОЛОЖЕНИЯ

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

•Действующему законодательству и иными правовыми актам;

•Нормативной документацией Контролирующих органов;

•Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами организации;

•Рекомендациям практик и стандартов, принятых в отрасли;

•Рекомендациям практик и стандартов, принятых в и сфере ИТ;

ЦЕЛИ ДОКУМЕНТА

Внесения ясность в организацию Управления ИТ Инцидентами в организации. Цели документа:

•Формирование принципов организации процесса;

•Повышение эффективности взаимодействия ИТ и бизнеса;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•Инцидент — любое не запланированное снижение уровня предоставления сервиса.

•Значительный инцидент (major incident) — инцидент, имеющий высокий уровень воздействия (impact) на функционирование сервиса.

•Уровень воздействия (impact) — границы воздействия инцидента на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

•Уровень срочности (urgency) — степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) — определяет важность инцидента и порядок его разрешения.

•Обходное решение (work around) — действия, позволяющие временно или постоянно устранить инцидент или его причины.

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

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА

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

•Своевременное реагирование на инциденты и скорейшее восстановление работы сервиса

•Формирование процесса управления инцидентами, определение процедур, стандартов и метрик.

•Обеспечение прозрачности функционирования ИТ департамента для бизнеса

•Снижение негативного влияния инцидентов на бизнес, путем своевременного и грамотного их устранения

•Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников работой ИТ департамента

ЗАДАЧИ ПРОЦЕССА

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

•Организация процесса управления инцидентами

•Классификация инцидентов

•Классификация воздействия, срочности и приоритета

•Классификация метрик и показателей работы процесса

•Определение ролей и уровень вовлеченности сотрудников

•Организации деятельности по обнаружению и регистрации инцидента

•Организации деятельности по классификации и первоначальной поддержки

•Организации деятельности по расследованию и диагностики инцидента

•Организации деятельности по разрешению инцидента

•Организации деятельности по эскалации инцидента

•Организации деятельности по закрытию инцидента

•Организации деятельности по коммуникации в процессе управления инцидентами

•Организации деятельности по мониторингу и отчетности по работе процесса

•Организации деятельности по взаимодействию с другими процессами управления ИТ сервисами

•Оптимизация процесса управления инцидентами

ПРОЦЕСС УПРАВЛЕНИЯ ИНЦИДЕНТАМИ

Процесс управления инцидентами, представлен на диаграмме.

Процесс управления инцидентами может быть разделен на следующие под-процессы:

•Обнаружение и регистрация инцидента

•Классификация и первоначальная поддержка

•Расследование и диагностика

•Разрешение инцидента

•Эскалация инцидента

•Закрытие инцидента

Для построения эффективного процесса управления инцидентами необходимо наличие следующих входных данных:

•Наличие каталога сервисов, предоставляемых ИТ департаментом

•Определены каналы инициализации инцидента

•Наличие базовых и/или специфических соглашений по предоставлению услуг

•Определены группы поддержки

•Определены каналы обратной связи по информированию о статусе инцидента

•Определены ключевые атрибуты инцидента

•Определены метрики процесса

•Наличие компонентной базы ИТ инфраструктуры

При функционировании процесса управления инцидентами необходимы следующие инструменты:

•Процедуры управления инцидентами

•Инструменты для диагностики инцидентов

•Инструменты по разрешению инцидентов

•Инструменты для регистрации, мониторинга и управления инцидентами

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

•Запросы на обслуживание

•Запросы на изменения

•Регистрация проблем

•Записи по инцидентам

•База знаний по инцидентам

•Отчеты

•Сообщения

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

•Уровень L0 — «нулевой» уровень поддержки, предоставляемый со стороны контакт центра отдела «Поддержки Пользователей» или самостоятельное разрешение инцидента сотрудником на основе имеющейся информации.

•Уровень L1 — «начальный» уровень поддержки, предоставляемый со стороны сотрудников отдела «Поддержки Пользователей».

•Уровень L2 — уровень поддержки «специалистов», предоставляемый со стороны сотрудников различных функциональных подразделений ИТ департамента. Является основным компонентов разрешения инцидентов и уровнем эскалации для отдела «Поддержки Пользователей»

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

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

Дополнительно в процессе управления инцидентами необходимо обладать информацией или настройками:

•Календарь

•Рабочее время

Под-процесс обнаружения и регистрации инцидента

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

Кроме этого, на начальном этапе необходимо определить тип обращения: инцидент, запрос на обслуживание или изменения, или информация.

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

•Регистрация инцидента по звонку пользователя

•Регистрация инцидента при непосредственном контакте с сотрудником

•Регистрация инцидента с использованием электронной почты

•Регистрация инцидента по средствам электронного портала средств управления ИТ сервисами

•Регистрация инцидента с использованием средств мониторинга ИТ инфраструктуры

Входная информация включает, но не ограничена следующими данными:

•Канал инициализации инцидента

•Контактная информация по пользователю

•Краткое название инцидента

•Детальная информация по инциденту

Выходная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

В качестве триггера используется:

•Неудовлетворенность пользователя качеством предоставляемого сервиса

Под-процесс классификации и определение приоритета инцидента

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

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

В качестве классификации инцидента можно определить следующие типы и источники:

•Общие классы инцидентов (сеть, офисное оборудование, сервера и т п)

•Каталог ИТ сервисов и критичности сервисов

•Уровень соглашения по обслуживанию

Кроме этого необходимо определить дополнительные типы:

•Поддержка пользователей (End user support)

•Прочие и не классифицированные

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

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Как альтернатива, может использоваться атрибут уровень тяжести (Severity) с теми же типами.

В качестве срочности выполнения (urgency) инцидента можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Связанные компоненты ИТ инфраструктуры

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

В качестве триггера используется:

•Наличие уникальной записи по инциденту

Под-процесс начального расследования инцидента

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

•Опрос по списку симптомов для определения источника инцидента или классификации (check list)

•Поиск в имеющихся «Часто Задаваемых Вопросах FAQ»

•Поиск в имеющейся базе данных знаний инцидентов (Knowledge Base)

•Предоставление решения или обходного действия пользователю для самостоятельного разрешения

•Применение решения оператором

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

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

•Информация по разрешению инцидента

В качестве триггера используется:

•Наличие уникальной записи по инциденту

Под-процесс расследования и поиска решения по инциденту

Под-процесс полноценного расследования и поиска решения по инциденту является следующим этапом жизненного цикла управления инцидентами. На данном этапе инцидент переходит на технические уровни поддержки (L2-L3) организации или же передается внешней стороне (L4). Данный этап содержит такие действия, как:

•Назначение «Assign to ME» инцидента на конкретного исполнителя (Incident Resolver)

•Поиск и устранение инцидента

•Обращение за дополнительной информацией

•Эскалация инцидента как горизонтальная, так и вертикальная с привлечением внешней стороны (L4)

•Документирование

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Определённая группа поддержки

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Информация по разрешению инцидента

В качестве триггера используется:

•Наличие уникальной записи по инциденту

•Счетчик времени по устранению инцидента в соответствии с соглашением об уровне предоставления услуг

Под-процесс разрешения и закрытия инцидента

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

•разрешение инцидента — устранение инцидента сотрудником группы поддержки,

•закрытие инцидента — формальное подтверждение разрешения инцидента со стороны инициатора (пользователя или владельца сервиса).

•Реактивация инцидента — повторное активирование инцидента

Данный этап содержит такие действия, как:

•Разрешение инцидента

•Обновление информации по инциденту

•Документирование

•Закрытие инцидента

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

•Реактивация инцидента

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Категория разрешения инцидента

•Статус инцидента

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

•Информация по разрешению инцидента (категория, время разрешения и т п)

В качестве триггера используется:

•Наличие уникальной записи по инциденту

•Счетчик времени по устранению инцидента в соответствии с соглашением об уровне предоставления услуг

Процесс управления инцидентами для уровня поддержки «Уровень L0»

Процесс управления инцидентами для уровня поддержки «Уровень L0» представлен на диаграмме.

Данный уровне поддержки характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Низким уровнем ИТ знаний

•Ориентирован на сбор информации по инциденту, определению симптомов, проверка первичных возможных решений и т п

•Разрешение инцидентов по средствам опросников, базы знаний и т п,

•Консультация сотрудников по процессу управления инцидентами, последовательности действий и т п

•Предоставление сотрудникам информации по разрешению инцидентов

•Мониторинг состояния инцидента, полноты информации, соответствия соглашению и т п

•Правильная классификация инцидента

•Назначение на правильную группу поддержки

Процесс управления инцидентами для уровня поддержки «Уровень L1/L2»

Процесс управления инцидентами для уровня поддержки «Уровень L1/L2» представлен на диаграмме:

Данный уровне поддержки характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Определённый уровень ИТ знаний

•Ориентирован на разрешение инцидента

Процесс управления инцидентами для уровня поддержки «Уровень L3/L4»

Процесс управления инцидентами для уровня поддержки «Уровень L3/L4» представлен на диаграмме:

Данный уровне поддержки характеризуется следующими характеристиками:

•Реагирование на инциденты, уже зарегистрированные в системе

•Реагирование на инциденты, сгенерированные со стороны систем мониторинга сервиса

•Реагирование на инциденты, с признаком эскалация

•Ориентирован на разрешение инцидента

•Эскалация инцидента на высший (L4) уровень поддержки

•Разработка и обновление базы знаний и т п

МЕТРИКИ ПРОЦЕССА

Для обеспечения высокого уровня функционирования процесса управления инцидентами необходимо обеспечить мониторинг состояния следующих метрик и активности процесса:

•Количество инцидентов

•Разрешение инцидента при первом контакте

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

Владелец сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по улучшению сопровождения

•Получение информации по инцидентам, относящимся к функционированию его сервиса

Менеджер сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по вопросам улучшения сопровождения сервиса

•Взаимодействие с владельцем сервиса по вопросам улучшения сопровождения сервиса

•Получение информации по инцидентам, относящимся к функционированию его сервиса

•Предоставление информации по инцидентам, относящимся к функционированию его сервиса

Оператор отдела «Поддержки Пользователей»

Отдел «Поддержки Пользователей»

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Обновление информации по инциденту

•Назначение или эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

Специалист поддержки (Incident Resolver)

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Назначение инцидента «на себя» из группы поддержки

•Обновление информации по инциденту

•Эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

•Инициирование запроса на изменения

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

•Написание и обновление базы знаний

Менеджер процесса управления инцидентами (Incident Manager)

Цели:

•Эффективное и результативное функционирование процесса управления инцидентами

•Обеспечение соответствия процесса требованиям ИТ архитектуры

•Повышение полноты и точности информации, вовлеченной в процесс

•Снижение количества инцидентов и времени их разрешения

Ответственность:

•Улучшение и оптимизация процесса

•Точное и оптимальное распределение ролей сотрудников, вовлеченных в процесс

•Инициативы по продвижение процесса и вовлечения сотрудников организации

•Оперативное вмешательство в процесс для обеспечения соответствия требованиям

•Разработка и применение метрик и показателей процесса

•Анализ процесса и под-процессов

•Мониторинг и предоставление отчетности по работе процесса

•Предоставление отчетности по сервисам и связанными с ними инцидентам

•Оценка и предоставление отчетности по эффективности сотрудников, задействованных в процессе

•Взаимодействие с другими отделами и подразделениями по вопросам, связанным с процессом

Роли и ответственности сотрудников указаны в соответствующих должностных инструкциях.

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

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

•Владелец процесса отвечает за организацию процесса, внесения изменений и дополнений.

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

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПРОЦЕССА

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

•Нехватка управленческой информации для принятия решений;

•Хаотичный порядок реагирования сотрудников на инциденты;

•Отсутствие достоверной информации по функционированию ИТ;

•Не эффективное использование ИТ ресурсов;

РИСКИ ПРИ ВНЕДРЕНИИ И СОПРОВОЖДЕНИИ

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

•Отсутствие поддержки со стороны руководства организации;

•Отсутствие необходимого уровня культуры в организации;

•Отсутствие необходимых ресурсов;

•Нехватка знаний и навыков у сотрудников;

•Нехватка знаний и навыков у сотрудников ИТ департамента;

•Недостатки системы автоматизации процесса управления;

•Недостатки сопутствующей ИТ инфраструктуры;

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

Ключевые факторы успеха при внедрении и сопровождении процесса управления инцидентами можно определить, как:

•Пристальное внимание к процессу;

•Реалистичные цели;

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

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

•Измеряемые показатели;

•Наличие актуальной и полной компонентной базы;

•Наличие актуальной и постоянно обновляемой базы знаний;

•Высокий уровень квалификации сотрудников ИТ департамента;

•Приемлемый уровень осведомленности сотрудников;

•Наличие инструментов диагностики и устранения инцидентов;

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности являются:

•Снижение количества ИТ инцидентов в организации;

•Повышение уровня доступности ИТ сервиса;

•Отсутствие претензий со стороны сотрудников организации;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•«Процедура управления инцидентами»;

•«Стандарты и метрики процесса управления инцидентами»;

•«Процедура регистрации пользователей»;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: •Содержание изменений: ]

Управление Запросами

Общие положения

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

•Действующему законодательству и иными правовыми актам Азербайджанской Республики,

•Нормативной документацией Контролирующего органа Азербайджанской Республики,

•Уставу организации

•Уставу ИТ департамента

•Внутренним регламентирующими документами (приказы, распоряжения и т п) организации.

•Рекомендациям лучших практик и стандартов, принятых в отрасли и сфере информационных технологий

Цели документа

Внесения ясность в организацию Управления ИТ запросами в организации. Цели документа:

•Формирование концепции и принципов и организации процесса управления ИТ запросами в организации.

•Повышение эффективности взаимодействия ИТ департамента и бизнеса.

Принятые сокращения и определения

Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

Инцидент — любое не запланированное снижение уровня предоставления сервиса.

Значительный инцидент (major incident) — инцидент, имеющий высокий уровень воздействия (impact) на функционирование сервиса.

Запрос — любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов.

Запрос на изменения — запрос, выполнение которого связанно с необходимостью внести изменения в любой из компонентов ИТ сервиса.

Стандартный Запрос — любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Запрос на предоставление сервиса — тип запроса, связанный с предоставлением сервиса, не имеющегося в списке каталога сервисов. Как правило новый сервис.

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

Запрос на предоставление информации — тип запроса, связанный с предоставлением информации.

Запрос на предоставление доступа — тип запроса, связанный с предоставлением / изменением доступа к сервису.

Уровень воздействия (impact) — границы воздействия запроса на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

Уровень срочности (urgency) — степень, определяющая срочность исполнения запроса. Является составляющей, определяющей приоритет инцидента.

Приоритет (priority) — определяет важность запроса и порядок его разрешения.

Обходное решение (work around) — действия, позволяющие временно или выполнить запрос.

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

Комитет по изменениям — комитет, разрешающий внесение изменений

Стандартный запрос на изменения– любой запрос в ИТ департамент на изменения, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Сфера действия документа

Действия данного документа распространяется на все аспекты деятельности ИТ департамента связанные с управлением запросами.

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

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

Процедура принятия документа, внесения изменений определены в процедуре «Процедура организации, руководящей ИТ документации».

Связанные документы

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•«Процедура управления запросами»

•«Стандарты и метрики процесса управления запросами»

•«Процедура регистрации пользователей»

•«Политика управления инцидентами»

•«Стандарты и метрики процесса управления инцидентами»

•«Политика управления изменениями»

•«Стандарты и метрики процесса управления изменениями»

Влияние при отсутствии процесса Управления Запросами

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

•Нехватка управленческой информации для принятия решений

•Хаотичный порядок реагирования ИТ сотрудников на запросы

•Отсутствие фактической и точной информации по функционированию сервисов

• Не эффективное использование ИТ ресурсов при исполнении запросов

Цели процесса Управления Запросами

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

•Своевременное реагирование на запросы и скорейшее их исполнение

•Формирование процесса управления запросами, определение процедур, стандартов и метрик.

•Обеспечение прозрачности функционирования ИТ департамента для бизнеса

•Снижение негативного влияния на бизнес, при неэффективном исполнении запросов

•Рациональное использование ИТ ресурсов

• Повышения удовлетворенности бизнеса и сотрудников работой ИТ департамента

Задачи процесса Управления Запросами

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

•Организация процесса управления запросами

•Классификация и категоризация запросов

•Классификация воздействия, срочности и приоритета

•Классификация метрик и показателей работы процесса

•Определение ролей и уровень вовлеченности сотрудников

•Определение под-процессов по выполнению типовых запросов

•Организации деятельности по регистрации запроса

•Организации деятельности по классификации и оценке запросов

•Организации деятельности по одобрению запросов

•Организации деятельности по выполнению запросов

•Организации деятельности по эскалации запросов

•Организации деятельности по закрытию запросов

•Организации деятельности по коммуникации в процессе управления запросами

•Организации деятельности по мониторингу и отчетности по работе процесса

•Организации деятельности по взаимодействию с другими процессами управления ИТ сервисами

•Оптимизация процесса управления запросами

Процесс управления инцидентами может быть разделен на следующие под-процессы:

•Регистрация запроса

•Классификация и обработка

•Одобрение запроса

•Выполнение запроса

•Эскалация запроса

• Закрытие запроса

Процесс управления запросами в организации, представлен на диаграмме.

Для построения эффективного процесса управления запросами необходимо наличие следующих входных данных:

•Наличие каталога сервисов, предоставляемых ИТ департаментом

•Определены каналы инициализации запроса

•Наличие базовых и/или специфических соглашений по предоставлению услуг

•Определены шаблоны обработки запросов по типам

•Определены группы подтверждающих запросы

•Определены группы исполнителей

•Определены каналы обратной связи по информированию о статусе запроса

•Определены ключевые атрибуты запроса

•Определены метрики процесса

•Наличие компонентной базы ИТ инфраструктуры

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

•Процедуры управления запросами

•Инструменты по выполнению запросов

• Инструменты для регистрации, мониторинга и управления запросами

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

•Запросы на сервис

•Запросы на обслуживание

•Запросы на изменения (часть процесса управления изменениями)

•Запросы на информацию

•Запросы на доступ

•Регистрация проблем

•Отчеты

• Сообщения

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

•Уровень L0 — «нулевой» уровень поддержки, предоставляемый со стороны контакт центра отдела «Поддержки Пользователей» или самостоятельное разрешение запроса сотрудником на основе имеющейся информации.

•Группа выполнения запросов –группы поддержки, непосредственно выполняющие запросы.

•Группа одобрения запросов –группы, отвечающие за одобрение запросов, относящихся к их сфере ответственности.

Дополнительно в процессе управления запросами необходимо обладать информацией или настройками:

•Календарь

•Рабочее время

•Тип запроса и порядок выполнения

Под-процесс регистрации запроса

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

Кроме этого, на начальном этапе необходимо определить тип обращения: инцидент, запрос на обслуживание или изменения, или информация.

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

•Регистрация запроса по звонку пользователя

•Регистрация запроса при непосредственном контакте с сотрудником

•Регистрация запроса с использованием электронной почты

• Регистрация запроса по средствам электронного портала средств управления ИТ сервисами

Входная информация включает, но не ограничена следующими данными:

•Канал инициализации запроса

•Контактная информация по пользователю

•Краткое название запроса

•Классификация и категоризация запроса

• Детальная информация по запросу

Выходная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

В качестве триггера используется:

•Неудовлетворенность пользователя качеством предоставляемого сервиса

Под-процесс классификации и определение приоритета инцидента

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

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

В качестве классификации запроса можно определить следующие типы и источники:

•Общие классы запросов (сеть, офисное оборудование, сервера и т п)

•Каталог ИТ сервисов и критичности сервисов

•Уровень соглашения по обслуживанию

Кроме этого необходимо определить дополнительные типы:

•Запросы пользователей (End user requests)

• Прочие и неклассифицированные (Other requests)

Для определения приоритета необходимо определить воздействие и срочность запроса.

В качестве воздействия (impact) запроса можно определить, как минимум следующие типы:

Минимальное (Low)

••Среднее (Medium)

• Высокое (High)

В качестве срочности выполнения (urgency) запроса можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

• Высокое (High)

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

• Связанный шаблон активности по запросу

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Определенный шаблон действий по запросу

•Определенная группа одобрения запроса

В качестве триггера используется:

• Наличие уникальной записи по запросу

Под-процесс одобрения запроса

Под-процесс одобрения запроса является следующим этапом жизненного цикла управления запросами. На данном этапе происходит одобрение действий по запросу.

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Установленное время выполнения запроса

•Информация по разрешению запроса

В качестве триггера используется:

• Наличие уникальной записи по запросу

Под-процесс выполнения запроса

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

• Назначение «Assign to ME» запроса на конкретного исполнителя (Request Resolver)

• Выполнение действий по выполнению запроса

• Обращение за дополнительной информацией

Эскалация инцидента как горизонтальная, так и вертикальная с привлечением внешней стороны (L4)

• Документирование

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

• Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Определённая группа поддержки

•Связанные компоненты ИТ инфраструктуры

• База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Информация по выполнению запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

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

Под-процесс закрытия запроса

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

•Выполнение запроса –полное выполнение запроса сотрудником группы поддержки и подтверждения со стороны инициатора запроса,

•Выполнение запроса с незначительными проблемами — выполнение запроса с наличием незначительных замечаний,

•Частичное выполнение запроса –запрос выполнен не полностью,

•Реактивация запроса — повторное активирование запроса

Данный этап содержит такие действия, как:

•Обновление информации по запросу

•Документирование

•Закрытие запроса

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

• Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Категория разрешения запроса

•Статус запроса

•Связанные компоненты ИТ инфраструктуры

• База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

• Информация по выполнению запроса (категория, время разрешения и т п)

В качестве триггера используется:

•Наличие уникальной записи по запросу

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

Процесс управления запросами для уровня поддержки «Уровень L0»

Процесс управления запросами для уровня поддержки «Уровень L0» характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Низким уровнем ИТ знаний

•Ориентирован на сбор информации по инциденту, определению симптомов, проверка первичных возможных решений и т п

•Разрешение инцидентов по средствам опросников, базы знаний и т п,

•Консультация сотрудников по процессу управления инцидентами, последовательности действий и т п

•Предоставление сотрудникам информации по разрешению инцидентов

•Мониторинг состояния инцидента, полноты информации, соответствия соглашению и т п

•Правильная классификация инцидента

•Назначение на правильную группу поддержки

Процесс управления запросами для группы одобрения запросов

Процесс управления запросами для уровня поддержки «Уровень L1/L2» характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Определённый уровень ИТ знаний

•Ориентирован на разрешение инцидента

•Процесс управления запросами для группы выполнения запросов

Процесс управления запросами для уровня поддержки «Уровень L3/L4» характеризуется следующими характеристиками:

•Реагирование на инциденты, уже зарегистрированные в системе

•Реагирование на инциденты, сгенерированные со стороны систем мониторинга сервиса

•Реагирование на инциденты, с признаком эскалация

•Ориентирован на разрешение инцидента

•Эскалация инцидента на высший (L4) уровень поддержки

•Разработка и обновление базы знаний и т п

Метрики процесса Управления Запросами

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

•Количество запросов

•Выполнение запросов при первом контакте

Роли и ответственности

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

Владелец сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по улучшению сопровождения

• Получение информации по инцидентам, относящимся к функционированию его сервиса

Менеджер сервиса

Цели:

• Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по вопросам улучшения сопровождения сервиса

•Взаимодействие с владельцем сервиса по вопросам улучшения сопровождения сервиса

• Получение информации по инцидентам, относящимся к функционированию его сервиса

• Предоставление информации по инцидентам, относящимся к функционированию его сервиса

Оператор отдела «Поддержки Пользователей»

Отдел «Поддержки Пользователей»

Цели:

• Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Обновление информации по инциденту

• Назначение или эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

• Предложения по улучшению функционирования сервиса

Специалист поддержки (Incident Resolver)

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Назначение инцидента «на себя» из группы поддержки

•Обновление информации по инциденту

•Эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

•Инициирование запроса на изменения

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

•Написание и обновление базы знаний

Менеджер процесса управления инцидентами (Incident Manager)

Цели:

•Эффективное и результативное функционирование процесса управления инцидентами

•Обеспечение соответствия процесса требованиям ИТ архитектуры

•Повышение полноты и точности информации, вовлеченной в процесс

• Снижение количества инцидентов и времени их разрешения

Ответственность:

•Улучшение и оптимизация процесса

•Точное и оптимальное распределение ролей сотрудников, вовлеченных в процесс

•Инициативы по продвижение процесса и вовлечения сотрудников организации

•Оперативное вмешательство в процесс для обеспечения соответствия требованиям

•Разработка и применение метрик и показателей процесса

•Анализ процесса и под-процессов

•Мониторинг и предоставление отчетности по работе процесса

•Предоставление отчетности по сервисам и связанными с ними инцидентам

•Оценка и предоставление отчетности по эффективности сотрудников, задействованных в процессе

• Взаимодействие с другими отделами и подразделениями по вопросам, связанным с процессом

Роли и ответственности сотрудников указаны в соответствующих должностных инструкциях.

Порядок взаимодействия процесса Управления Запросами

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

•Владелец процесса отвечает за организацию процесса, внесения изменений и дополнений.

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

Риски при внедрении и сопровождении процесса Управления Запросами

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

•Отсутствие поддержки со стороны руководства организации

•Отсутствие достаточного уровня культуры в организации в целом, так и сотрудников в частности

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

•Отсутствие необходимых ресурсов, для внедрения и сопровождения процесса

•Нехватка знаний и навыков у специалистов ИТ департамента

•Недостатки системы автоматизации процесса управления запросами

• Недостатки сопутствующей ИТ инфраструктуры

Ключевые факторы успеха внедрения и сопровождения процесса Управления Запросами

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

•Пристальное внимание к процессу

•Реалистичные цели

•Соответствие бизнес процессов и процесса управления запросами

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

•Измеряемые показатели

•Наличие актуальной и полной компонентной базы

•Наличие актуальной и постоянно обновляемой базы знаний по запросам

•Высокий уровень квалификации сотрудников ИТ департамента

•Приемлемый уровень осведомленности сотрудников организации

•Наличие инструментов диагностики и выполнения запросов

Показатели эффективности и критерии оценки деятельности

Критериями оценки деятельности, связанной с информационной безопасностью являются:

•Снижение количества ИТ запросов в организации

•Повышение уровня доступности ИТ сервиса

•Отсутствие претензий со стороны сотрудников подразделений организации,

•Отсутствие претензий со стороны контролирующих органов по вопросам, связанным с управлением запросами

•Удовлетворенность руководства организации.

Контроль документа:

•Номер документа:

•Наименование документа:

•Статус документа:

•Маркер безопасности:

•Дата утверждения:

•Дата вступления в силу:

•Протокол ИТ комитета:

•Заменяет документ:

•Документ разработан:

•Дата разработки:

•Документ одобрен:

•Дата одобрения:

•Утвержден:

•Дата утверждения:

Контроль версии документа:

•Версия документа:

•Дата внесения изменений:

•Автор:

•Содержание изменений:

Управление Проблемами

Общие положения

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

•Действующему законодательству и иными правовыми актам Азербайджанской Республики,

•Нормативной документацией Контролирующего органа Азербайджанской Республики,

•Уставу организации

•Уставу ИТ департамента

•Внутренним регламентирующими документами (приказы, распоряжения и т п) организации.

•Рекомендациям лучших практик и стандартов, принятых в отрасли и сфере информационных технологий

Цели документа

Внесения ясность в организацию Управления ИТ проблемами в организации. Цели документа:

•Формирование концепции и принципов и организации процесса управления ИТ проблемами в организации.

•Повышение эффективности взаимодействия ИТ департамента и бизнеса.

Принятые сокращения и определения

Владелец сервиса (service owner) — роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

Менеджер сервиса (service manager) — роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

Инцидент — любое не запланированное снижение уровня предоставления сервиса.

Значительный инцидент (major incident) — инцидент, имеющий высокий уровень воздействия (impact) на функционирование сервиса.

Запрос — любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов.

Запрос на изменения — запрос, выполнение которого связанно с необходимостью внести изменения в любой из компонентов ИТ сервиса.

Стандартный Запрос — любой запрос в ИТ департамент, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Запрос на предоставление сервиса — тип запроса, связанный с предоставлением сервиса, не имеющегося в списке каталога сервисов. Как правило новый сервис.

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

Запрос на предоставление информации — тип запроса, связанный с предоставлением информации.

Запрос на предоставление доступа — тип запроса, связанный с предоставлением / изменением доступа к сервису.

Уровень воздействия (impact) — границы воздействия запроса на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

Уровень срочности (urgency) — степень, определяющая срочность исполнения запроса. Является составляющей, определяющей приоритет инцидента.

Приоритет (priority) — определяет важность запроса и порядок его разрешения.

Обходное решение (work around) — действия, позволяющие временно или выполнить запрос.

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

Комитет по изменениям — комитет, разрешающий внесение изменений

Стандартный запрос на изменения– любой запрос в ИТ департамент на изменения, связанный с функционированием ИТ сервисов заранее авторизирован и с предопределенным порядком исполнения.

Проблема — причина появления инцидентов.

Известная проблема — причина появления инцидентов, известная производителю.

Сфера действия документа

Действия данного документа распространяется на все аспекты деятельности ИТ департамента связанные с управлением проблемами.

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

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

Процедура принятия документа, внесения изменений определены в документе «Процедура организации, руководящей ИТ документации».

Связанные документы

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•«Политика управления запросами»

•«Процедура управления запросами»

•«Стандарты и метрики процесса управления запросами»

•«Процедура регистрации пользователей»

•«Политика управления инцидентами»

•«Стандарты и метрики процесса управления инцидентами»

•«Процедура управления инцидентами»

•«Политика управления изменениями»

•«Стандарты и метрики процесса управления изменениями»

•«Процедура управления изменениями»

•«Процедура управления проблемами»

•«Стандарты и метрики процесса управления проблемами»

•«Политика управления релизами»

•«Стандарты и метрики процесса управления релизами»

•«Процедура управления релизами»

Влияние при отсутствии процесса Управления Проблемами

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

•Нехватка управленческой информации для принятия решений

•Хаотичный порядок реагирования ИТ сотрудников на запросы, инциденты, изменения

•Отсутствие фактической и точной информации по функционированию сервисов

•Не эффективное использование ИТ ресурсов при решении проблем

Цели процесса Управления Проблемами

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

•Своевременное реагирование на проблемы и скорейшее их исполнение

•Формирование процесса управления проблемами, определение процедур, стандартов и метрик.

•Обеспечение прозрачности функционирования ИТ департамента для бизнеса

•Снижение негативного влияния на бизнес, при неэффективном решении проблем

Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников работой ИТ департамента

Задачи процесса Управления Проблемами

Задачи ИТ департамента по управлению проблемами можно определить, как следующие:

•Организация процесса управления проблемами

•Классификация и категоризация проблем

•Классификация воздействия, срочности и приоритета

•Классификация метрик и показателей работы процесса

•Определение ролей и уровень вовлеченности сотрудников

•Организации деятельности по регистрации проблем

•Организации деятельности по классификации и оценке проблем

•Организации деятельности по решению проблем

•Организации деятельности по закрытию проблем

•Организации деятельности по коммуникации в процессе управления проблемами

•Организации деятельности по мониторингу и отчетности по работе процесса

•Организации деятельности по взаимодействию с другими процессами управления ИТ сервисами

•Оптимизация процесса управления проблемами

Процесс Управления Проблемами

Процесс управления проблемами может быть разделен на следующие под-процессы:

•Определение проблемы

•Оценка проблемы

•Диагностика проблемы

•Решение проблемы

•Закрытие проблемы

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

Для построения эффективного процесса управления проблемами необходимо наличие следующих входных данных:

•Наличие каталога сервисов, предоставляемых ИТ департаментом

•Определены каналы инициализации проблем

•Наличие базовых и/или специфических соглашений по предоставлению услуг

•Определены группы решения проблем

•Определены каналы обратной связи по информированию о статусе проблемы

•Определены ключевые атрибуты проблемы

•Определены метрики процесса

•Наличие компонентной базы ИТ инфраструктуры

При функционировании процесса управления проблемами необходимы следующие инструменты:

•Процедуры управления проблемами

•Инструменты по решению проблем

•Инструменты для регистрации, мониторинга и управления проблемами

•База знаний по известным проблемам

•Статистика и аналитика по управлению инцидентами

При функционировании процесса управления проблемами формируются следующие выходных данные:

•Запросы на изменения (часть процесса управления изменениями)

•Регистрация проблем

•Отчеты

•Сообщения

В процессе управления проблемами определены следующие группы:

•Группа решения проблем –группы поддержки, непосредственно выполняющие проблемы.

Под-процесс определения проблемы

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

•Регистрация запроса по звонку пользователя

•Регистрация запроса при непосредственном контакте с сотрудником

•Регистрация запроса с использованием электронной почты

•Регистрация запроса по средствам электронного портала средств управления ИТ сервисами

Входная информация включает, но не ограничена следующими данными:

•Канал инициализации запроса

•Контактная информация по пользователю

•Краткое название запроса

•Классификация и категоризация запроса

•Детальная информация по запросу

Выходная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

В качестве триггера используется:

•Неудовлетворенность пользователя качеством предоставляемого сервиса

Под-процесс оценки проблемы

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

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

В качестве классификации запроса можно определить следующие типы и источники:

•Общие классы запросов (сеть, оборудование, сервера и т п)

•Каталог ИТ сервисов и критичности сервисов

•Уровень соглашения по обслуживанию

Кроме этого необходимо определить дополнительные типы:

•Запросы пользователей (End user requests)

•Прочие и неклассифицированные (Other requests)

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

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

В качестве срочности выполнения (urgency) запроса можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

•Связанный шаблон активности по запросу

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Определенный шаблон действий по запросу

•Определенная группа одобрения запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

Под-процесс диагностики и расследования проблемы

Под-процесс одобрения запроса является следующим этапом жизненного цикла управления запросами. На данном этапе происходит одобрение действий по запросу.

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация и категоризация

•Приоритет запроса

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Установленное время выполнения запроса

•Информация по разрешению запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

Под-процесс решения проблемы

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

•Назначение «Assign to ME» запроса на конкретного исполнителя (Request Resolver)

•Выполнение действий по выполнению запроса

•Обращение за дополнительной информацией

•Эскалация инцидента как горизонтальная, так и вертикальная с привлечением внешней стороны (L4)

•Документирование

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Определённая группа поддержки

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Информация по выполнению запроса

В качестве триггера используется:

•Наличие уникальной записи по запросу

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

Под-процесс закрытия проблемы

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

•Выполнение запроса –полное выполнение запроса сотрудником группы поддержки и подтверждения со стороны инициатора запроса,

•Выполнение запроса с незначительными проблемами — выполнение запроса с наличием незначительных замечаний,

•Частичное выполнение запроса –запрос выполнен не полностью,

•Реактивация запроса — повторное активирование запроса

Данный этап содержит такие действия, как:

•Обновление информации по запросу

•Документирование

•Закрытие запроса

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по запросу

•Классификация

•Приоритет запроса

•Категория разрешения запроса

•Статус запроса

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по запросу

•Определённая группа поддержки

•Информация по выполнению запроса (категория, время разрешения и т п)

В качестве триггера используется:

•Наличие уникальной записи по запросу

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

Метрики процесса Управления Проблемами

Для обеспечения высокого уровня функционирования процесса управления проблемами необходимо обеспечить мониторинг состояния следующих метрик и активности процесса:

•Количество запросов

•Выполнение запросов при первом контакте

Роли и ответственности

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

Владелец сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по улучшению сопровождения

•Получение информации по инцидентам, относящимся к функционированию его сервиса

Менеджер сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по вопросам улучшения сопровождения сервиса

•Взаимодействие с владельцем сервиса по вопросам улучшения сопровождения сервиса

•Получение информации по инцидентам, относящимся к функционированию его сервиса

•Предоставление информации по инцидентам, относящимся к функционированию его сервиса

Оператор отдела «Поддержки Пользователей»

Отдел «Поддержки Пользователей»

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Обновление информации по инциденту

•Назначение или эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

Специалист поддержки (Problem Resolver)

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Назначение инцидента «на себя» из группы поддержки

•Обновление информации по инциденту

•Эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

•Инициирование запроса на изменения

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

•Написание и обновление базы знаний

Менеджер процесса управления проблемами (Problem Manager)

Цели:

•Эффективное и результативное функционирование процесса управления инцидентами

•Обеспечение соответствия процесса требованиям ИТ архитектуры

•Повышение полноты и точности информации, вовлеченной в процесс

•Снижение количества инцидентов и времени их разрешения

Ответственность:

•Улучшение и оптимизация процесса

•Точное и оптимальное распределение ролей сотрудников, вовлеченных в процесс

•Инициативы по продвижение процесса и вовлечения сотрудников организации

•Оперативное вмешательство в процесс для обеспечения соответствия требованиям

•Разработка и применение метрик и показателей процесса

•Анализ процесса и под-процессов

•Мониторинг и предоставление отчетности по работе процесса

•Предоставление отчетности по сервисам и связанными с ними инцидентам

•Оценка и предоставление отчетности по эффективности сотрудников, задействованных в процессе

•Взаимодействие с другими отделами и подразделениями по вопросам, связанным с процессом

Роли и ответственности сотрудников указаны в соответствующих должностных инструкциях.

Порядок взаимодействия процесса Управления Проблемами

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

•Владелец процесса отвечает за организацию процесса, внесения изменений и дополнений.

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

Риски при внедрении и сопровождении процесса Управления Проблемами

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

•Отсутствие поддержки со стороны руководства организации

•Отсутствие достаточного уровня культуры в организации в целом, так и сотрудников в частности

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

•Отсутствие необходимых ресурсов, для внедрения и сопровождения процесса

•Нехватка знаний и навыков у специалистов ИТ департамента

•Недостатки системы автоматизации процесса управления запросами

•Недостатки сопутствующей ИТ инфраструктуры

Ключевые факторы успеха внедрения и сопровождения процесса Управления Проблемами

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

•Пристальное внимание к процессу

•Реалистичные цели

•Соответствие бизнес процессов и процесса управления запросами

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

•Измеряемые показатели

•Наличие актуальной и полной компонентной базы

•Наличие актуальной и постоянно обновляемой базы знаний по запросам

•Высокий уровень квалификации сотрудников ИТ департамента

•Приемлемый уровень осведомленности сотрудников организации

•Наличие инструментов диагностики и выполнения запросов

Показатели эффективности и критерии оценки деятельности

•Критериями оценки деятельности, связанной с информационной безопасностью являются:

•Снижение количества ИТ запросов в организации

•Повышение уровня доступности ИТ сервиса

•Отсутствие претензий со стороны сотрудников подразделений организации,

•Отсутствие претензий со стороны контролирующих органов по вопросам, связанным с управлением запросами

•Удовлетворенность руководства организации.

Контроль документа:

•Номер документа:

•Наименование документа:

•Статус документа:

•Маркер безопасности:

•Дата утверждения:

•Дата вступления в силу:

•Протокол ИТ комитета:

•Заменяет документ:

•Документ разработан:

•Дата разработки:

•Документ одобрен:

•Дата одобрения:

•Утвержден:

•Дата утверждения:

Контроль версии документа:

•Версия документа:

•Дата внесения изменений:

•Автор:

•Содержание изменений:

Управление Доступами

Процесс Управления Доступами (Access Management) относится к этапу сопровождения управления ИТ сервисами и является рекомендацией стандарта ISO 27001 & 27017 и 27018. Владельцем процесса как правило является департамент Безопасности организации. Руководящие документы по процессу рассмотрены в разделе Информационной Безопасности.

Организации работы с ИТ активами

Общие положения

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

•Действующему законодательству и иными правовыми актам Азербайджанской Республики,

•Нормативной документацией Контролирующего органа Азербайджанской Республики,

•Внутренним регламентирующими документами (приказы, распоряжения и т п) организации.

• Рекомендациям лучших практик и стандартов, принятых в отрасли и сфере информационных технологий

Цели документа

Цели данного документа:

•Внесения ясность в организацию работы с ИТ активами,

•Повышение эффективности использования ИТ активов

•Повышение эффективности взаимодействия ИТ департамента и бизнеса.

Задачи документа

Задачи данного документа:

•Классификация ИТ активов

•Определение атрибутов при организации работы с ИТ активами

•Регламентирует порядок приобретения ИТ активов

•Регламентирует порядок внедрения ИТ активов

•Регламентирует порядок сопровождения ИТ активов

•Регламентирует порядок устаревания ИТ активов

•Регламентирует порядок списания ИТ активов

•Определение коэффициентов достижения целей по организации работы с ИТ активами

•Регламентирует порядок взаимодействия подразделений организации по работе с ИТ активами

Принятые сокращения и определения

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

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

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

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

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

Сфера действия документа

Документ является дополнением к регламентирующим документам департамента Закупки и снабжения.

Документ регламентирует действия с ИТ активами, только на уровне взаимодействия с ИТ департаментом.

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

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

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

Базовые принципы

Основные базовые принципы при организации работы с ИТ активами можно определить, как:

•Все ИТ активы должны быть приобретены в соответствии с регламентом, принятом в организации

Все ИТ активы должны быть должным образом классифицированы

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

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

•Политика формирования требований к ИТ активам

•Политика приобретения ИТ активов

•Политика внедрения ИТ активов

•Политика сопровождения ИТ активов

•Политика устаревания ИТ активов

•Политика списания ИТ активов

• Политика передачи ИТ активов

Роли и ответственности

Бизнес отвечает за:

•Формирование бизнес требований к ИТ активам,

• Работать с ИТ активами в соответствии с регламентом, принятом в организации

Департамент закупки и снабжения отвечает за:

•Проведение тендера по ИТ активам, в соответствии с техническими требованиями

•Формирование регламента по организации работы с ИТ активом

•Согласование ИТ департаментом вопросов, по техническим требованиям, предъявляемым к ИТ активам

ИТ департамент отвечает за:

•Классификацию ИТ активов

•Предоставление в департамент закупки и снабжения технической спецификации, предъявляемой к ИТ активам

•Формирования требований по надлежащей работе с ИТ активами

•Контроль за исполнением требований по надлежащей работе с ИТ активами

•Поддержание ИТ активов в надлежащем состоянии

• Внедрение и сопровождение ИТ активов

Департамент Безопасности отвечает за:

• Формирование требований, предъявляемых к ИТ активам, для обеспечения информационной безопасности

Показатели эффективности и критерии оценки деятельности

Критериями оценки достижения целей, определённых в данной политике являются:

•Отсутствие претензий со стороны сотрудников подразделений организации,

•Отсутствие претензий со стороны контролирующих органов

•Удовлетворенность руководства организации.

Связанные документы

Данный документ имеет непосредственное отношение к следующим документам:

• «Стандарт организации работы с документами и нумерации руководящих документов ИТ департамента».

• «Процедура организации работы с документами и нумерации руководящих документов ИТ департамента».

Контроль документа:

•Номер документа:

•Наименование документа:

•Статус документа:

•Маркер безопасности:

•Дата утверждения:

•Дата вступления в силу:

•Протокол ИТ комитета:

•Заменяет документ:

•Документ разработан:

•Дата разработки:

•Документ одобрен:

•Дата одобрения:

•Утвержден:

•Дата утверждения:

Контроль версии документа:

•Версия документа:

•Дата внесения изменений:

•Автор:

•Содержание изменений:

Управление Системами Обеспечения

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

Управление Измерениями

Процесс Управления Измерениями (Service Measurement) относится к этапу непрерывного улучшения управления ИТ сервисами.

Политика Управление Отчетностью по Сервису

ВВЕДЕНИЕ

Процесс Управления Отчетностью по Сервисам (Service Reporting) относится к этапу непрерывного улучшения управления ИТ сервисами.

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

ЦЕЛИ

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

• Каждый отчет упрощает контроль качества обслуживания;

• Отчеты упрощают улучшение услуг и процессы;

• Отчеты гарантируют соответствие законным требованиям;

• Каждая реализованная отчетность задокументирована;

ОПИСАНИЕ ДЕЯТЕЛЬНОСТИ

Деятельность по управлению отчетностью по сервису включает в себя следующие шаги:

• Сбор данных из различных источников;

• Анализ данных;

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

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

•Техническое состояние ИТ сервиса;

•Приобретение ресурса;

•Административные службы;

•Составление бюджета и Учет;

•Проекты в сфере ИТ;

Как пример, Менеджер инженерно-технической службы должен сообщить следующие метрики:

• Производительность сервиса;

• Тенденция и анализ функционирования сервиса;

• Деятельность, связанная с работой сервиса;

• Несоблюдение и проблемы, нарушения соглашений и т. д.

• Характеристики рабочих нагрузок, (объем, ресурс, и т п);

• Производительность существенных изменений и инцидентов;

• Время, потраченное, чтобы решить вопросы;

• Риски и реагирование на них;

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

Управление Улучшениями

Процесс Управления Улучшения Сервиса (Service Improvement) относится к этапу непрерывного улучшения управления ИТ сервисами.

Политика Стандартизации

ОБЩИЕ ПОЛОЖЕНИЯ

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

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

ЗАДАЧИ И ОСНОВНЫЕ ФУНКЦИИ ДОКУМЕНТА

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

•Стандартизация процесса оснащения техническими средствами ИТ — происходит в следствии того, что типы технических средств для каждого департамента четко определены;

•Снижение времени принятия решения — происходит в следствии того, что имеется стандартизация процесса оснащения техническими средствами ИТ.

•Определение степени ответственности вовлеченных сотрудников банка — происходит в следствии того, что каждый отдел знает за какой участок процесса он отвечает и в каких вопросах он наиболее компетентен. Кроме того, правление банка всегда может правильно и адекватно оценивать эффективность работы департаментов, т.к. их задачи и степеней ответственности заранее определены.

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

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

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

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

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

•надежная и безотказная работа;

•быстрая доставка и установка

•быстрое время реагирование и высокая координация действий

•быстрое и качественное восстановление или замена

•закупочная стоимость устройств и расходных материалов

•отсутствие претензий со стороны сотрудников

•отсутствие претензий со стороны руководства

Политика Премирование сотрудников ИТ

ОБЩИЕ ПОЛОЖЕНИЯ

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

ВВЕДЕНИЕ

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

ПЕРЕЧЕНЬ ДЕЙСТВИЙ И РАБОТ, ПОДЛЕЖАЩИХ ПРЕМИРОВАНИЮ

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

• 1. Создание ИТ инфраструктуры нового филиала;

• 2. Ремонт и модернизация ИТ инфраструктуры филиала;

• 3. Получение международного статуса и/или сертификации;

• 4. Успешное внедрение проектов и решений;

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

• А. Благодарственное письмо со стороны правления Банка;

• Б. Дополнительные выходные дни, добавленные к отпуску;

• В. Единовременная денежная премия;

Определены следующие типы филиалов согласно их площади:

•Малый филиал — одноэтажное помещение, площадью не более 200м2. Обычно это операционные отделения.

•Стандартный филиал — одно- или двухэтажное помещение, площадь не менее 200м2, но не более 500м2. Обычные филиалы.

•Большой филиал — двух- и более этажное помещение, площадь более 500м2.

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

ПОРЯДОК ОРГАНИЗАЦИИ ПРЕМИРОВАНИЯ

Порядок премирования по пунктам 1 и 2

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

1. Глава департамента ИТ пишет запрос (в электронном или бумажном виде) на имя руководства. В запросе указываются название филиала, имена и фамилии сотрудников, вид премирования и рекомендуемое разделение премии между сотрудниками (в случае денежного вознаграждения);

2. Руководство подтверждает запрос и пересылает его в департамент управления кадрами. Определены следующие виды премирования (Б и В) за данную работу и сумма разовой премии. Премия выдается за филиал и распределяется между работниками, принимавшими участие в работе:

• Малый филиала — для работников ИТ 400 манат (или 2 дня отпуска на работника);

• Стандартный филиала — для работников ИТ 500 манат (или 3 дня отпуска на работника);

• Большой филиала — для работников ИТ 650 манат (или 4 дня отпуска на работника);

3. Департамент Управления Кадрами производит начисление;

4. Возможен иной вид или сумма премии при воздействии дополнительных факторов. Это глава ИТ департамента обсуждает с административным менеджером.

5. Действие данного раздела премирование распространяются на всех работников ИТ департамента исключая главу отдела и менеджера.

Порядок премирования по пункту 3

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

1. Работник ИТ департамента присылает сертификат (в любой форме) главе отдела ИТ.

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

3. Глава департамента ИТ прикрепляет копию сертификата к запросу.

4. Административный менеджер подтверждает запрос и пересылает его в отдел кадров. Определены виды премирования (В) и сумма разовой премии. Разовая премия выдается за получение сертификата одного из ниже приведённых уровней. Определены следующие уровни сертификаций:

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

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

•Сертификаты высокого уровня — сертификаты, получение которых требует наличия сертификатов предыдущих уровней.

•Сертификаты уровня мастера — один из наивысших уровней сертификаций.

Сертификат начального уровня:

• Microsoft Certified Professional (MCP) – 240 манат.

• CompTIA A+ Technician – 240 манат.

• EXIN ITILv3 Foundation – 240 манат.

• Microsoft Certified Technical Specialist (MCTS) – 240 манат.

• Cisco Certified Entry Network Technician (CCENT) – 240 манат.

Сертификат продвинутого уровня:

• CompTIA Network + или CompTIA Security + – 400 манат.

• CompTIA Classroom Trainer CTT+ – 400 манат.

• Microsoft Certified IT Professional (MCITP) – 400 манат.

• Microsoft Certified IT Professional DB Administrator — 400 манат.

• Microsoft Certified System Administrator (MCSA) – 400 манат.

• Cisco Certified Network Associate (CCNA) – 400 манат.

• VMware Certified Specialist (VCP) – 400 манат

• Certified Ethical Hacker  (CEH) – 400 манат

• Security Certified Network Specialist (SCNS) – 400 манат.

Сертификат высокого уровня:

• Microsoft Certified System Engineer (MCSE) – 650 манат.

• Microsoft Certified Trainer (MCT) – 650 манат.

• Cisco Certified Network Professional (CCNP) – 650 манат.

• VMware Certified Advanced Professional  (EA or D) – 650 манат

• ITIL v3 Certified Expert (ITILv3 Expert) – 650 манат

• Security Certified Network Professional (SCNP) – 650 манат.

• Certified Information System Manager (CISM) – 650 манат.

• Certified Information System Auditor (CISA) – 650 манат.

• Certified Associate Project Management (CAMP) – 650 манат

Сертификат уровня мастера:

• Microsoft Certified Master (MCM) – 1350 манат.

• Microsoft Certified Architect (MCA) – 1350 манат.

• Cisco Certified Internetwork Expert (CCIE) – 1350 манат.

• Cisco Certified Internetwork Architect (CCIE) – 1350 манат.

• VMware Certified Design Expert (VCDX) – 1350 манат

• ITIL v3 Certified Master (ITILv3 Master) – 1350 манат

• Project Management Professional (PMP) – 1350 манат

5. Департамент Управления Кадрами производит начисление;

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

7. Сертификаты, действующие по принципу наследования (т.е., например, при получении сертификата MCITP: DBA автоматически получается базовый сертификат MCITP), оплачиваются один раз.

8. Сертификаты, действующие по принципу направленности (т.е., например, при получении сертификата MCSA направления Security), оплачиваются один раз как базовый (MCSA).

9. Действие данного раздела о премировании распространяется на всех работников ИТ департамента, исключая главу отдела.

Порядок премирования по пункту 4

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

1. Глава департамента ИТ пишет запрос (в электронном или бумажном виде) на имя административного менеджера Банка. В запросе указываются название проекта, краткое описание проекта и указывается целесообразность выдачи поощрения работнику.

2. Глава отдела ИТ обязан руководствоваться несколькими ключевыми факторами:

•Значимость проекта для Банка;

•Сложность проекта;

•Выдающиеся действия сотрудника, приведшие к успешному выполнению проекта;

•Проект не является прямыми обязанностями сотрудника;

•Сохранение высокого уровня мотивации сотрудников.

3. Административный менеджер подтверждает запрос и пересылает его в отдел кадров.

4. Департамент Управления Кадрами производит начисление;

5. Определены виды премирования (А, Б и В). Возможен иной вид или сумма премии при воздействии дополнительных факторов. Это глава ИТ департамента обсуждает с административным менеджером.

6. Действие данного раздела о премировании распространяется на всех работников ИТ департамента, исключая главу отдела.

Политика Работы с ИТ Документами

ОБЩИЕ ПОЛОЖЕНИЯ

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

•Действующему законодательству и иными правовыми актам;

•Нормативной документацией контролирующего органа;

Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами организации;

•Рекомендациям практик и стандартов, принятых в отрасли;

•Рекомендациям практик и стандартов, принятых в ИТ;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

Маркер безопасности — буквенно-цифровой идентификатор, определяющий уровень конфиденциальности документа.

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

ЦЕЛИ ДОКУМЕНТА

Цели данного документа:

•Внесения ясность в организацию работы с документами;

•Определение ключевых элементов и этапов при формировании, обсуждении, принятии руководящих документов;

•Регламентирует порядок внесение изменений и утверждения;

•Регламентирует порядок их распространения;

•Повышение эффективности взаимодействия ИТ и бизнеса;

ЗАДАЧИ ДОКУМЕНТА

Задачи данного документа:

•Классификация документов и их нумерация

•Определение важных атрибутов документа

•Контроль изменений документов

•Мониторинг соблюдения требований данного документа

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

БАЗОВЫЕ ПРИНЦИПЫ ПОЛИТИКИ

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

•Все руководящие документы ИТ должны быть пронумерованы;

•Все руководящие документы ИТ должны иметь маркер безопасности;

•Формат и структура всех руководящих документов ИТ должны соответствовать утвержденному стандарту;

•Все действия с руководящими документами ИТ должны соответствовать утвержденной процедуре;

•Все руководящие документы ИТ должны быть формально утверждены на ИТ комитете;

РОЛИ И ОТВЕТСТВЕННОСТИ

Директор ИТ департамента отвечает за:

•Формирование документа

•Согласование с другими документами ИТ департамента;

•Согласование с бизнесом, взаимодействие с которым затрагивается в документе;

•Согласование содержания с департаментом Управления Кадрами.

•Согласование содержания с департаментом ИБ.

•Согласование содержания с Юридическим департаментом.

•Согласование содержания с департаментом Документа-оборота.

•Представление документа на ознакомление и утверждение ИТ комитетом

Директор бизнес департамента отвечает за:

•Соответствие политикам и процедурам департамента,

•Соответствие содержания документа требованиям регуляторов

•Соответствие содержания документа рекомендациям по отрасли

Директор департамента Управления Кадрами отвечает за:

•Соответствие политикам и процедурам департамента,

•Соответствие содержания документа требованиям регуляторов

•Соответствие содержания документа рекомендациям по отрасли

•Информирование сотрудников организации с данным документом после утверждения

Директор департамента ИБ отвечает за:

•Соответствие политикам и процедурам департамента,

•Соответствие содержания документа требованиям регуляторов

•Соответствие содержания документа рекомендациям по отрасли

•Определение маркера безопасности

Директор Юридического департамента отвечает за:

•Соответствие политикам и процедурам департамента,

•Соответствие содержания документа требованиям регуляторов

•Соответствие содержания документа рекомендациям по отрасли

• Правильности формулировок, содержащихся в документе

Директор департамента Документа-оборота отвечает за:

•Определение формата документа

•Соответствие политикам и процедурам департамента,

•Нумерация документа, классификацию, формат документа

•Поиск несоответствия и не стыковок документа с уже имеющимися документами других департаментов

•Контроль статуса документа

ИТ комитет отвечает за:

•Утверждение документа,

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

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки достижения целей являются:

•Отсутствие претензий со стороны сотрудников;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Данный документ имеет отношение к следующим документам:

•«Стандарт организации работы с документами и нумерации руководящих документов ИТ департамента».

•«Процедура организации работы с документами и нумерации руководящих документов ИТ департамента».

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

Политика Управления коммуникациями (Communication Policy) является частью рекомендации стандарта ISO 20000—1:2011.

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

СТАНДАРТЫ И МЕТРИКИ ИТ

Стандарт Устаревание ИТ Активов

ОБЩИЕ ПОЛОЖЕНИЯ

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

ЗАДАЧИ ДОКУМЕНТА

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

ИТ АКТИВЫ

В организации присутствуют следующие виды ИТ ресурсов подверженных устареванию:

•Сервера

•Рабочие станции

•Прочее активное оборудование

•Программное обеспечение

•Резервные копии серверов

•Файлы конфигураций

•Базы данных содержащие конфиденциальную информацию

•Файлы содержащие конфиденциальную информацию

•Меморандумы и прочие документы ИТ департамента

•Учетные записи пользователей

Существуют следующая политика в отношении серверов:

•Минимальный срок использования — не менее 1 года.

•Максимальный срок использования — не более 5 лет.

•Плановый срок использования — 3 года.

Существуют следующая политика в отношении рабочих станций:

•Минимальный срок использования — не менее 1 года.

•Максимальный срок использования — не более 5 лет.

•Плановый срок использования — 4 года.

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

•Минимальный срок использования– не менее 1 года.

•Максимальный срок использования– не более 5 лет.

•Плановый срок использования– 4 года.

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

•Минимальный срок использования ОС сервера — 1 год.

•Максимальный срок использования ОС сервера — не ограничен *.

•Плановый срок использования ОС сервера — 4 года.

•Минимальный срок использования ОС рабочей станции — 1 год.

•Максимальный срок использования ОС рабочей станции — не ограничен *.

•Плановый срок использования ОС рабочей станции — 4 года.

•Минимальный срок использования приложений — 1 год.

•Максимальный срок использования приложений — не ограничен *.

•Плановый срок использования приложений — 4 года.

Существуют следующая политика в отношении служебных резервных копий (РК) серверов:

•Периодичность создания (EMC Avamar) — раз в день.

•Тип резервной копии (EMC Avamar) — полный.

•Срок хранения РК (EMC Avamar) — 2 месяца.

•Срок хранения РК (EMC Avamar) на удаленном сайте — 2 месяца.

•Периодичность создания РК (станд. ср-ва) — отсутствует.

•Тип резервной копии (станд. ср-ва) — отсутствует.

•Срок хранения РК (станд. ср-ва) — отсутствует.

•Срок хранения РК на удаленном сайте (станд. ср-ва) — 5 лет.

•Периодичность создания архива (станд. ср-ва) — раз в квартал.

•Тип архивной копии (станд. ср-ва) — полный.

•Срок хранения архива (станд. ср-ва) — 1 месяц.

•Срок хранения архивной копии на удаленном сайте — 5 лет.

Существуют следующая политика в отношении файлов конфигураций:

•Периодичность создания РК (EMC Avamar) — раз в день.

Тип резервной копии (EMC Avamar) — полный.

•Срок хранения РК (EMC Avamar) — 2 месяца.

•Срок хранения РК (EMC Avamar) на удаленном сайте — 2 месяца.

•Периодичность создания РК (станд. ср-ва) — отсутствует.

•Тип резервной копии (станд. ср-ва) — отсутствует.

•Срок хранения РК (станд. ср-ва) — отсутствует.

•Срок хранения РК на удаленном сайте (станд. ср-ва) — 5 лет.

•Периодичность создания архива (станд. ср-ва) — раз в квартал.

•Тип архивной копии (станд. ср-ва) — полный.

•Срок хранения архива (станд. ср-ва) — 1 месяц.

•Срок хранения архива на удаленном сайте — 5 лет.

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

•Периодичность создания РК (EMC Avamar) — раз в 3 часа.

•Тип РК (EMC Avamar) — агрегированный полный.

•Срок хранения РК (EMC Avamar) — не ограниченный **.

•Срок хранения РК (EMC Avamar) на удаленном сайте — не ограниченный **.

•Периодичность создания РК (станд. ср-ва) — ежедневно.

•Тип резервной копии (станд. ср-ва) — полный.

•Срок хранения РК (станд. ср-ва) — 1 месяц.

•Срок хранения РК на удаленном сайте (станд. ср-ва) — отсутствует.

•Периодичность создания архива (станд. ср-ва) — ежедневно.

•Тип архивной копии (станд. ср-ва) — полный.

•Срок хранения архива станд. ср-ва) — не ограничен.

•Срок хранения архива на удаленном сайте — не ограничен.

Существуют следующая политика в отношении файлов содержащих конфиденциальную информацию:

•Периодичность создания РК (EMC Avamar) — ежедневно.

•Тип РК (EMC Avamar) — агрегированный полный.

•Срок хранения РК (EMC Avamar) — 3 месяца.

•Срок хранения РК (EMC Avamar) на удаленном сайте — 3 месяца.

•Периодичность создания РК (станд. ср-ва) — ежедневно.

•Тип резервной копии (станд. ср-ва) — изменения.

•Срок хранения РК (станд. ср-ва) — 1 месяц.

•Срок хранения РК на удаленном сайте (станд. ср-ва) — отсутствует.

•Периодичность создания архива (станд. ср-ва) — ежемесячно.

•Тип архивной копии (станд. ср-ва) — полный.

•Срок хранения архива (станд. ср-ва) — отсутствует.

•Срок хранения архива на удаленном сайте — не ограничен.

Существуют следующая политика в отношении документов ИТ департамента:

•Периодичность создания РК (EMC Avamar) — ежедневно.

•Тип РК (EMC Avamar) — агрегированный полный.

•Срок хранения РК (EMC Avamar) — 3 месяца.

•Срок хранения РК (EMC Avamar) на удаленном сайте — 3 месяца.

•Периодичность создания РК (станд. ср-ва) — отсутствует.

•Тип резервной копии (станд. ср-ва) — отсутствует.

•Срок хранения РК (станд. ср-ва) — отсутствует.

•Срок хранения РК на удаленном сайте (станд. ср-ва) — отсутствует.

•Периодичность создания архива (станд. ср-ва) — ежемесячно.

•Тип архива (станд. ср-ва) — полный.

•Срок хранения архива (станд. ср-ва) — отсутствует.

•Срок хранения архива на удаленном сайте — не ограничен.

Меморандумы ИТ департамента хранятся в отделе на бумажных носителях за текущий и предедущий года. Далее сдаются в архив. Электронная копия документов не делается.

Существуют следующая политика в отношении учетных записей пользователей:

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

•Минимальный срок хранения неактивной учетной записи на Почтовом Сервере– удаляется в конце года или 90 дней неиспользования.

•Минимальный срок хранения неактивной учетной записи АБС– без ограничений.

•Минимальный срок хранения неактивной учетной записи платежных систем– определяется требованиями системы или без ограничений.

•Максимальный срок хранения ограничивается политикой безопасности или техническими возможностями.

Стандарт ИТ Активов

ОБЩИЕ ПОЛОЖЕНИЯ

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

•ИТ архитектуре организации

•Рекомендациям практик и стандартов, принятых в отрасли;

•Рекомендациям практик и стандартов, принятых в сфере ИТ;

ЦЕЛИ ДОКУМЕНТА

Цели данного документа:

•Определение стандартов программно-аппаратных средств;

•Формирует технические требования для департамента закупок;

ЗАДАЧИ ДОКУМЕНТА

Задачи данного документа:

•Определение требований к программно-аппаратным решениям;

•Формирование спецификации к техническим решениям;

•Определение производителя и модели устройств;

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Сервер первой категории — компьютер выполняющий критически важные задачи в обеспечению бизнес процессов в банке. К таким серверам можно отнести сервер базы данных, контролер домена, почтовый сервер, фаервол и т. п. Т.к. простой таких серверов приводит к остановке бизнес процессов и убыткам, то необходимо оборудование способное работать в режиме 24/7. Параметры серверов определяются в приложении.

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

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

•Рабочая станция стандартной конфигурации — компьютер выполняющий не критически важные задачи пользователя банка. Приоритетом при выборе компьютера данной категории является цена. Компьютер обладает минимальной конфигурацией и ценой. Комплектуется плоским жидкокристаллическим монитором. Используется для большинства пользователей банка.

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