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

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

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

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

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

ITIL и быстрое изменение приложений

09.04.2018
09.04.2018

Однажды Роза Бертэн, личная портниха французской королевы Марии-Антуанетты, слегка подновив старое платье королёвы, предложила его королеве, и та с удовольствием его приняла. «Новое — это хорошо забытое старое», — прокомментировала этот случай портниха.

Из мемуаров (1824) Розы Бертэн

Поступательность в единстве с преемственностью составляет суть диалектического развития

Конспект лекций по философии

Если вы решили первым стать в рядах своих сограждан —

Никогда не догоняйте устремившихся вперед.

Через пять минут, ругаясь, побегут они обратно,

И тогда, толпу возглавив, вы помчитесь впереди!

Мое любимое стихотворение Григория Остера

ITIL и новые вызовы времени

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

Так что же, подходы ITIL поколеблены и он безнадежно устарел или все-таки не все так плохо? Попробуем в этом разобраться и понять, что в ITIL останется незыблемым, а что нужно будет совершенствовать согласно современным вызовам. В своих рассуждениях я буду использовать идеи, которые уже были высказаны до меня авторитетами в области разработки, только мы будем рассматривать их через призму задач поддержки.

В менеджменте, как, впрочем, и в остальных областях человеческой деятельности, люди часто пытаются отказаться от уже существующего и строить все с чистого листа. Но, как мне кажется, многое из того, что будет использовано для быстрых изменений, можно взять из существующих практик или они будут являться их следствием с необходимыми корректировками в соответствии с текущим моментом (и это согласуется с принципами, изложенными в книге ITIL Practitioner). Конечно, в текущей версии ITIL вопросы разработки освещены, скажем так, весьма скудно. Будем надеяться, что этот недостаток будет исправлен в следующей версии ITIL, а пока попробуем показать, какие изменения могут претерпеть лучшие практики в этой области.

ITIL – новые нюансы ценности ИТ-услуги для заказчика

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

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

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

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

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

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

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

  • приложение разрабатывается путем нескольких итераций, каждая из которых имеет законченный бизнес-функционал и отражает текущие требования заказчика (вспоминаются шесть шагов постоянного совершенствования услуги, описываемого ITIL);
  • разбиение приложения на законченные компоненты (или микросервисы), отражающие конкретные требования бизнеса, и способные самостоятельно предоставлять законченную ценность для бизнеса;
  • законченные компоненты приложений будут разрабатываться кросс-функциональными командами, имеющими полный набор необходимых навыков в построении пользовательских интерфейсов, архитектуры приложений и управления проектами;
  • в ходе замены одной версии компонента на другой возможен так называемый «канареечный тест», в ходе которого какое-то время возможна параллельная работа в среде эксплуатации обеих версий компонента, чтобы можно было подстраховаться (образно говоря, «два бронепоезда», идущие параллельными курсами, пока команда по частям пересаживается из одного в другой);
  • представитель команды разработчиков может владеть продуктом на протяжении всего срока его жизни (это хорошо коррелирует с жизненным циклом услуги и ролью владельца услуги в ITIL), она не распускается по окончании проекта, а сопровождает его дальше по жизни; совсем крайний пример реализации – команды разработчиков отвечают за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7 (то есть предлагается  разработчиков переселить на вторую линию поддержки, если пользоваться терминологией ITIL);
  • максимальная автоматизация всех процессов разработки, включая тестирование и развертывание в среде эксплуатации, а также разработка и использования более продвинутого инструмента, общего для разработчиков и системных администраторов;
  • переход к модели «инфраструктура как код (IaC)», по которой процесс настройки инфраструктуры аналогичен процессу программирования приложений и ведет к стиранию границ между написанием приложений и созданием сред для этих приложений;
  • приложения должны быть спроектированы таким образом, чтобы они могли работать при отказе отдельных компонентов (частичное функционирование) и имели возможность быстрого отката как всего приложения, так и отдельного компонента в случае неудачного изменения;
  • большой акцент на мониторинге приложения в режиме реального времени, как на техническом, так и на бизнес-уровнях для выявления возможных отклонений как можно раньше.
Так какие риски могут нас тревожить с точки зрения поддержки?

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

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

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

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

Если рассматривать существующую модель ITIL, то данная деятельность, с точки зрения ITIL, может выглядеть как часть дополнительной деятельности по анализу влияния на бизнес (business impact analysis). После определения таких услуг необходимо перестроить в них работу – создать новые модели (pattern) управления для других этапов жизненного цикла услуги, в особенности это касается этапа преобразования услуги.

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

Для простоты назовем данный новый тип изменения «быстрым» («quick»). В существующей библиотеке ITIL наиболее близким к нему является стандартный тип изменения, но есть нюансы J. Например, «быстрое изменение» (далее я буду применять данный термин без кавычек) также несет черты экстренного изменения ITIL (инициация в любой момент, отложенное документирование), а также включает в себя элементы пилотного внедрения. Опираясь на ранее разобранные факторы разработки приложений, можно говорить о том, что быстрое изменение:

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

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

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

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

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

Далее в этой статье под термином «компонент» для краткости я буду иметь в виду термин «динамический компонент» услуги (далее буду использовать его без кавычек) и рассматривать только этот тип компонентов.

Риск: разобщенность миров разработчиков и специалистов поддержки

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

В состав группы по услуге могут входить:

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

Несмотря на то обстоятельство, что «железо» является одним из самых тяжело изменяемых элементов ИТ-услуги, придется меняться и ему. Автор не является глубоким экспертом в области методов построения гибкой ИТ-инфраструктуры, но полагает, что успехи, демонстрируемые в последнее время в области виртуализации ИТ-инфраструктуры, помогут делу и позволят снизить данный риск. Здесь уместно вспомнить такие подходы, как инфраструктура как услуга (Infrastructure-as-a-Service; IaaS) и архитектура Serverless, расширяющиеся границы гибкости ИТ-инфраструктуры. Поскольку динамические компоненты услуги могут включать в себя и «железо», то часть требований бизнеса может быть осуществлена за счет гибкой перенастройки части ИТ-инфраструктуры в ходе быстрых изменений, и это должно быть отражено в лучших практиках.

Риск: увеличение вероятности ошибок в разрабатываемом приложении

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

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

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

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

При возникновении данных событий:

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

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

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

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

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

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

  1. Появляется заявка бизнеса на изменение, возможно неформальная, и если эта заявка относится к динамическому компоненту, то она принимается, кратко фиксируется в базе быстрых изменений и по ней начинается работа.
  2. Как в ходе разработки, так и на выходе перед внедрением, разрабатываемый компонент подвергается автоматизированному тестированию, позволяющему выявить ошибки разработки.
  3. Как только компонент разработан и прошел тестирование, устанавливается время запуска релиза, и о нем оповещаются все заинтересованные стороны.
  4. Необходимые сведения о быстром изменении заносятся в базу знаний по быстрым изменениям, где должно быть зафиксировано место проводимого изменения (изменяемый компонент), интервал «опасного» времени, в течение которого изменение не будет считаться успешно внедренным, характер изменения – постоянный или временный с обязательным откатом, целевая группа, для которой будет доступно данное изменение, что изменилось (изменения интерфейса, логики работы и т.д.) понятным для поддержки и пользователей языком.
  5. Производится автоматический релиз компонента и, при необходимости, переключение целевой группы пользователей на внедренный компонент.
  6. Параллельно поддержка оповещается о проведенном изменении, ей предоставляются описание проведенного изменения и другие необходимые сведения из базы знаний для работы с пользователями, а также проводятся необходимые изменения в базе знаний для пользователей.
  7. Сразу после релиза начинается мониторинг измененного компонента, включающий в себя фиксацию отклонений в работе как самого компонента, так и отклик на его работу со стороны пользователей.
  8. В случае обнаружения отклонений в объемах, превышающих допустимый, дается команда, возможно автоматическая, на откат изменения и (или) запуск компенсирующих мер, например, быстрое исправление ошибок и запуск следующей итерации релиза.
  9. Заявка на откат изменения может также поступить от бизнеса и не являться следствием отклонений в работе измененного компонента, а будет результатом решения самого бизнеса на основе своих бизнес-критериев.
  10. По окончании интервала «опасного» времени изменение считается успешным, что должно быть подтверждено бизнесом и зафиксировано.
  11. Если на изменяемый компонент переводилась только некая целевая группа пользователей («канареечный тест»), то делается перевод всех пользователей на измененный компонент и ненужный более компонент удаляется.
  12. В заключение документируются все необходимые данные по проведенному изменению.
Риск: недостаточный уровень контроля за изменяемыми компонентами

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

Возможными статусами динамических компонентов могут быть следующие:

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

или в случае неудачи

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

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

Риск: повышение вероятности проблем, вызванных частыми изменениями

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

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

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

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

  • новые знания должны быть быстро оформлены (параллельно с разработкой);
  • новые знания должны быть обновлены и доведены до адресатов в нужное время;
  • их форма должна быть удобной для быстрого понимания и использования;
  • распространение знаний может быть многошаговым, если внедрение будет в несколько шагов;
  • новые знания должны быть быстро отозваны и заменены на исходные как в местах хранения, так и в головах адресатов J, если это будет необходимо.
Риск: недостаток знаний пользователей о внесенных изменениях

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

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

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

Риск: необходимость поддержки нескольких параллельных решений

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

ITIL – что же дальше?

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

Существующие описания организации быстрой разработки больше фокусируются на организации разработки приложений, а существующую версию ITIL часто и, наверно, справедливо критикуют за высокоуровневость и чрезмерную научность. Но многие положения и идеи ITIL, уже имеющиеся там, будучи конкретизированы и соединены с новыми подходами разработки, дадут необходимые ответы на вопрос: «Как нам организовать поддержку в этих новых условиях?». Будем же надеяться, что новая версия 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 и Сервис-менеджмент
10.11.2017
Когда пора сбивать высокую температуру? Умеем ли мы принимать правильные решения
Конечно же, речь в этой статье не пойдёт о том, когда необходимо принимать жаропонижающее. Мы попробуем разобраться со схожей, но более общей проблемой – умеем ли мы вообще принимать решения на основании измерений.
ITIL и Сервис-менеджмент

Вверх