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

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос:

Добрый день, коллеги!

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

Возник спор: в какой последовательности внедрять процессы.

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

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

Подскажите, есть ли какие-то жесткие требования к последовательности внедрения процессов? Можно ли нарушить эти требования, исходя из соображений оптимизации трудозатрат внедренцев, разработчиков систем автоматизации и персонала?

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 6

  • Артем Мукосеев

    Здравствуйте!

    Для начала давайте немного "сверим часы" в плане теории. В нашем всеми любимом )) ITIL описаны процессы управления инцидентами (Incident Management) и управления запросами на обслуживание (Request Fulfilment). Отдельного процесса управления обращениями там не описано. Если Вы подразумеваете некий процесс, в рамках которого происходит первичная обработка обращений пользователей и их дальнейшая маршрутизация в управление инцидентами или управление запросами, то в этом нет большого смысла. Наиболее традиционным подходом является внедрение единого процесса управления инцидентами и запросами на обслуживание, который решает все необходимые задачи. С этого процесса и стоит начать. К нему также полезно добавить элементы не упомянутого Вами процесса управления уровнем услуг, прописав хотя бы базовые нормативы на решение инцидентов и выполнение запросов. Таким образом Вы сразу встанете на правильный путь с точки зрения контроля качества услуг, которые ваш департамент предоставляет бизнесу. При этом начать нужно, как Вы правильно предполагаете, с проработки и формализации регламента процесса управления инцидентами и запросами. Далее целесообразно сразу же уложить его в систему автоматизации и запустить, предварительно написав инструкции и обучив пользователей.

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

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

    Итого я бы крайне не рекомендовал сначала писать пачку регламентов, а потом всю эту кухню автоматизировать. Действуйте итеративно, не пытайтесь "проглотить слона" )). Не внедряйте процессы ради "галочки". Начинайте с малого. Ставьте себе достижимые цели на ограниченный период времени. По итогам задавайтесь вопросом: "Мы получили, что ожидали?". Анализируйте сложности и узкие места, собирайте обратную связь от сотрудников ИТ и пользователей. Планируйте дальнейшее итеративное развитие процессов.

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

    • Екатерина

      Спасибо

    • Дмитрий

      Здравствуйте!

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

      В нашей компании именно такой процесс маршрутизации. А можете сказать подробнее почему в этом нет смысла?

  • Дмитрий Л.

    Тут нет процесса управления каталогом услуг на нулевом этапе и процесса управления уровнем услуг среди последних. Без них реального прихода не ощутить, получится просто стопка регламентов и пачка инструкций к системе.

    Ну а в целом, согласен с Артёмом — внедрять "не аджайл" сейчас практически моветон, всё по итерациям, всё по ощущениям, в том числе обязательный пересмотр любого процесса, как только есть понимание "работать так людям не удобно"

  • Андрей другой

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

  • Яковлев Андрей

    1. Критическим фактором успеха  является идейная приверженность методологии со стороны высшего руководства. Лучше с оттенком религиозного фанатизма.

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

    Но, если поддержки руководства на должном уровне  нет — epic fail неизбежен. Кокой бы Вы "быстрой победы" не добились на первом этапе. В менеджменте всегда очень сильна политическая составляющая. Добавьте сюда чисто психологическую составляющую — сопротивление изменениям, особенно, когда вводятся формальности. Потом самые ярые враги становятся самыми ярыми сторонниками, но см CSF 1.

     


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

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

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT