Портал №1 по управлению цифровыми
и информационными технологиями

ITSM 101: начало работы с ITIL

Подозреваю, что большинство читателей слышали об ITIL, самом популярном в мире своде практике для управления ИТ-услугами. На самом деле, я уверен, что многие из вас даже уже пытались «применить» ITIL. К сожалению, многие из тех, что пытался это сделать, поняли, что на деле это не так просто, как казалось. Если это так, эта статья именно для вас; надеюсь показать, насколько легко начать работу с ITIL и как быстро она может дать ощутимые результаты вам, вашим коллегам и вашим клиентам.

Если вы читали другие статьи о том, как начать работу с ITIL, вероятно, вы думаете, что уже знаете, что вас ждёт. Вы думаете, что я напишу о том, как внедрять процессы и инструменты для управления инцидентами, управления проблемами, управления изменениями и так далее для трансформации вашего ИТ-отдела. Но я не буду этого делать. Дело в том, что, независимо от того, что вы, возможно, читали ранее, изначально ITIL не о реализации процессов и инструментов. Нет, ITIL учит нас, что управление ИТ-услугами – это создание ценности для наших клиентов.

И первый шаг к этому — определить, кто наши клиенты.

Наши клиенты – кто они?

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

Команды, называемые в стиле «Storage team» или «Windows team» формируют инфраструктуру. Эти инфраструктурные команды имеют клиентов в командах приложений. У команд приложений есть клиенты в подразделениях с такими названиями, как «Производство», «Продажи», и эти подразделения, в свою очередь, создают ценность для внешних (платящих) клиентов. (Я говорю о клиентах, которые приносят деньги, но очевидно, что некоторые услуги предоставляются для общественного блага, а не для платящего заказчика). Если все в ИТ понимают, как они вписываются в поток ценностей, и как способствуют созданию ценности для платящих клиентов, то у вас отличное начало. Однако если люди в команде хранения думают лишь о том, что они должны делать, чтобы обеспечить хранилище, а команда приложений думает лишь о том, что они согласились поставить бизнес-единицам, то всё становится гораздо более проблематичным. Самое время завершить использовать малоэффективный подход, когда сотрудники делают то, что им сказали, но клиенты остаются недовольными результатами.

Результаты, стоимость, затраты и риск

Заметили, что слово «результаты» стоит в конце прошлого абзаца? Это очень важный термин в ITIL.  Результаты — это то, чего ИТ-услуги помогают нашим клиентам достичь. Именно эти результаты создают ценность для клиентов. Например, финансовая компания может иметь «ипотечную поддержку», которая помогает обрабатывать заявки на ипотеку. Результатом для клиентов является кредит, и это создаёт ценность, поскольку позволяет им купить дом или квартиру.

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

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

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

Постоянное улучшение

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

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

  • Убедитесь, что все понимают, чего вы пытаетесь достичь. Как правило, это видение, четко переданное представление о том, как выглядит успех
  • Измерьте, насколько хорошо вы работаете, но помните, что ваши измерения — не ваша цель, это просто инструмент, который можно использовать, чтобы обозначить тренды и пороговые значения
  • Получите обратную связь в каждой точке цепочки создания ценности. Это означает общение с людьми, которые являются прямыми получателями вашей работы, и понимание вашего влияния на общую цепочку создания ценности и платящих клиентов
  • Подумайте о том, каким образом можно делать лучше и разработайте безопасный эксперимент для проверки своих идей
  • Запустите свой эксперимент и посмотрите, были ли вы правы. Если да, утвердите свою идею и начините работать так в будущем; если вы ошиблись, вернитесь к предыдущему состоянию и попробуйте что-то другое

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

Как начать

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

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

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

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

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

Оригинал ITSM 101: Getting Started with ITIL, автор Стюарт Рэнс (Stuart Rance)

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT