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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Екатерина

      Спасибо

    • Дмитрий

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

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

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

  • Дмитрий Л.

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

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

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

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

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

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

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

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

     


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

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

  • Рубрики

  •  
  • Авторы

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

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

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT