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

SCHEDULE Расписание курсов

ITSS Курс «Управление стратегией ИТ-услуг на основе ITIL®»

AJAB Курс «Настройка и администрирование jira Software, настройка функциональности для работы по Scrum и Kanban»

ITILF Курс «Основы ITIL®»

COBIT5F «Основы COBIT 5»

PRINCE2F Курс «Основы управления проектами в соответствии с PRINCE2®»

MLF Курс «Основы машинного обучения»

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®»

DMLF Курс «Основы глубокого машинного обучения»

ITPM Курс «Инструменты управления ИТ-проектами»

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

MSA Курс «Микросервисная архитектура»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

ITHR Курс «Управление ИТ-персоналом»

COBIT-ICS Курс «Система внутреннего контроля ИТ по модели COBIT(COBIT Internal Control System)»

DevOps Курс «Основы DevOps»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

AWS Курс «Мастерская проектирования ИТ-решений»

BCH Курс «Технология блокчейн»

MALC Курс «Управление жизненным циклом услуг»

ITAM Курс «Управление ИТ-активами. Основы и практики»

ITILP Курс «ITIL Practitioner. Практические подходы для успешной работы»

ITAMP Курс «Практики управления ИТ-активами»

BAF Курс «Основы бизнес-анализа»

BASRM Курс «Бизнес-анализ. Управление требованиями к ПО»

QA Курс «QA и тестирование программного обеспечения»

BPA Курс «Моделирование, анализ и оптимизация бизнес-процессов»

SYSA Курс «Системный анализ»

CMMP Курс «Модель CMMI Development V2.0 — руководство к действию»

RISK Курс «Практические подходы управления ИТ-рисками»

AGILE: Гибкие методы управления

ITSO Курс «Эксплуатация услуг по модели ITIL®»

MSA4ITSM Курс «Управление ИТ в условиях применения микросервисной архитектуры»

ITLM Мастер-класс «Разработка карты ИТ‑ландшафта»

ITSD Курс «Проектирование услуг по модели ITIL®»

ITST Курс «Преобразование услуг по модели ITIL®»

CSI Курс «Постоянное совершенствование услуг по модели ITIL® (ITIL Continual Service Improvement)»


Наш канал на youtube
Здесь вы найдёте записи вебинаров и других видео наших экспертов на тему ITIL и не только
Тренажер подготовки к экзамену ITIL Foundation
Страховой сертификат повторной сдачи экзамена
  • 31243

    Количество выданных сертификатов

  • 2754

    Количество проведенных игр и семинаров

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

19.04.2018
19.04.2018

Быть может, ваше единственное

предназначение в жизни – быть живым

предостережением всем остальным.

Законы Мерфи

Среди ITSM-консультантов можно встретить такую точку зрения, что некоторые процессы, описанные в ITIL, на самом деле процессами не являются. В пример обычно приводятся или очень простые процессы, такие, как управление доступом,   или,  наоборот, достаточно сложные, к которым традиционно относят ряд процессов стадии проектирования (Service Design), например, управление мощностями или непрерывностью ИТ-услуг.

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

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

Ошибка №1. Некорректный охват процесса

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

Рисунок 1 Субъекты и объекты управления.

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

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

Ошибка №2. Смешивание функций управления

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

Рисунок 2 Функции управления процессом.

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

Характерным следствием смешивания функций управления является попытка включить в план обеспечения непрерывности все, кроме того, что там действительно должно быть. Ведь, если отвлечься от ITIL и прочих «good practices» в этой области, то план – это документ, который в первую очередь должен стать руководством к действию, воинским уставом для персонала при наступлении по-настоящему чрезвычайной ситуации. Поэтому довольно странно видеть там такие разделы, как «Анализ рисков» или «Порядок проведения и оценки тренировок», что как раз и является примером смешивания контуров организации, координации и контроля процесса.

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

Ошибка №3. Отсутствие вовлеченности бизнес-подразделений

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

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

Ошибка №4. Подход к управлению непрерывностью как к процессу операционного уровня

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

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



Вопросы по этой теме обсуждаются на следующих курсах:
26.10.2018
ITIL® 4 – грядут большие изменения
Многие интересующиеся темой сервис-менеджмента уже знают, что в следующем году ожидается выход новой версии ITIL.
ITIL и Сервис-менеджмент
04.10.2018
Лучше один раз увидеть
Два года назад в Альманахе itSMF России мы писали про контрольные карты Шухарта – прекрасный инструмент статистического управления процессами, который призван помочь нам принимать взвешенные и обоснованные решения на основании проведённых измерений.
ITIL и Сервис-менеджмент
19.04.2018
Непрерывность как процесс. Ошибки, которые вполне можно не допустить при организации управления непрерывностью.
Согласно лучшим практикам, нашедшим отражение в библиотеке ITIL®, основным интерфейсом взаимодействия между бизнесом и ИТ является услуга. ИТ-подразделение - провайдер, предоставляющий некий набор услуг, а бизнес - его потребитель.
ITIL и Сервис-менеджмент
12.04.2018
The Skills Framework for the Information Age – SFIA
SFIA (произносится как «София») или «The skills framework for the infor-mation age» – международно-признанная модель классификации ИТ-навыков.
09.04.2018
ITIL и быстрое изменение приложений
В последнее время часто говорят о необходимости быстрой разработки и внедрения изменений в приложениях и о кризисе традиционной ИТ-поддержки, которая описана в лучших практиках, в том числе в библиотеке ITIL.
ITIL и Сервис-менеджмент
04.04.2018
Как повысить ваши шансы на успех при внедрении процессов. Практические рекомендации
Существуют различные источники знаний о лучших практиках в области управления ИТ-услугами, которые содержат рекомендации и требования, применение и соответствие которым поможет обеспечить предоставление качественных ИТ-услуг.
Управление проектами
26.02.2018
Инструменты постоянного совершенствования услуг
Требования бизнеса к ИТ и его зависимость от ИТ-услуг продолжают стремительно расти. В такой ситуации очень важно, чтобы ИТ-организации постоянно оценивали и совершенствовали свои ИТ-услуги и процессы управления, которые обеспечивают предоставление ИТ-услуг.
ITIL и Сервис-менеджмент
20.02.2018
Управление ИТ-рисками
В данной статье речь пойдет о риск-ориентированном подходе в ИТ-управлении. О трудностях, которые могут возникнуть при внедрении процесса управления ИТ-рисками и о некоторых способах их преодоления.
Управление рисками
17.01.2018
В поисках волшебной пилюли
Несмотря на заголовок, статья будет вовсе не о лечении и медикаментах. В рамках консалтинговой и тренинговой деятельности мне постоянно приходится общаться с людьми совершенно разных профессий, образования, возраста, склада ума и опыта, работающих в абсолютно не похожих организациях по всей нашей необъятной стране.
ITIL и Сервис-менеджмент

Вверх