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

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

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

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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

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

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

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

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

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

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

    • Екатерина

      Спасибо

    • Дмитрий

      Здравствуйте!
      Вы написали: “Если Вы подразумеваете некий процесс, в рамках которого происходит первичная обработка обращений пользователей и их дальнейшая маршрутизация в управление инцидентами или управление запросами, то в этом нет большого смысла.”
      В нашей компании именно такой процесс маршрутизации. А можете сказать подробнее почему в этом нет смысла?

  • Дмитрий Л.

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

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

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

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

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

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

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

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

     


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM