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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Екатерина

      Спасибо

    • Дмитрий

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

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

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

  • Дмитрий Л.

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

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

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

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

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

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

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

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

     


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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT