В редакцию портала поступил вопрос:
Добрый день, коллеги!
Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами.
Возник спор: в какой последовательности внедрять процессы.
Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие.
Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно.
Подскажите, есть ли какие-то жесткие требования к последовательности внедрения процессов? Можно ли нарушить эти требования, исходя из соображений оптимизации трудозатрат внедренцев, разработчиков систем автоматизации и персонала?
Здравствуйте!
Для начала давайте немного "сверим часы" в плане теории. В нашем всеми любимом )) ITIL описаны процессы управления инцидентами (Incident Management) и управления запросами на обслуживание (Request Fulfilment). Отдельного процесса управления обращениями там не описано. Если Вы подразумеваете некий процесс, в рамках которого происходит первичная обработка обращений пользователей и их дальнейшая маршрутизация в управление инцидентами или управление запросами, то в этом нет большого смысла. Наиболее традиционным подходом является внедрение единого процесса управления инцидентами и запросами на обслуживание, который решает все необходимые задачи. С этого процесса и стоит начать. К нему также полезно добавить элементы не упомянутого Вами процесса управления уровнем услуг, прописав хотя бы базовые нормативы на решение инцидентов и выполнение запросов. Таким образом Вы сразу встанете на правильный путь с точки зрения контроля качества услуг, которые ваш департамент предоставляет бизнесу. При этом начать нужно, как Вы правильно предполагаете, с проработки и формализации регламента процесса управления инцидентами и запросами. Далее целесообразно сразу же уложить его в систему автоматизации и запустить, предварительно написав инструкции и обучив пользователей.
Следующим этапом будет регламентация и автоматизация процессов управления изменениями и управления конфигурациями, которые целесообразно внедрять именно в связке ввиду их сильной зависимости друг от друга. При этом нужно будет очень внимательно отнестись к определению целей и охвата этих процессов, чтобы не заставлять ИТ-специалистов заниматься бесполезной работой по регистрации изменений, которые ни на что не влияют и никому не интересны. Также нужно помнить, что при разработке процессов управления изменениями и управления конфигурациями может возникнуть необходимость внести корректировки и в процесс управления инцидентами и запросами. Это нормальная ситуация. Нужно что-то поменять – меняйте.
Управление проблемами стоит оставить "на сладкое". И заниматься им только тогда, когда Вы и Ваши коллеги сможете чётко сформулировать, зачем этот процесс вам нужен, и выделить ответственных. Это наиболее сложный в плане запуска процесс из перечисленных Вами. На нашем портале можно найти много полезных статей про управление проблемами, которые стоит почитать прежде, чем даже начинать думать об этом процессе. Основная мысль здесь следующая – если есть непонимание в среде сотрудников, если нет заинтересованного Менеджера процесса управления проблемами – процесс работать не будет и смысла тратить ресурсы на его внедрение нет.
Итого я бы крайне не рекомендовал сначала писать пачку регламентов, а потом всю эту кухню автоматизировать. Действуйте итеративно, не пытайтесь "проглотить слона" )). Не внедряйте процессы ради "галочки". Начинайте с малого. Ставьте себе достижимые цели на ограниченный период времени. По итогам задавайтесь вопросом: "Мы получили, что ожидали?". Анализируйте сложности и узкие места, собирайте обратную связь от сотрудников ИТ и пользователей. Планируйте дальнейшее итеративное развитие процессов.
Так, шаг за шагом, зрелость вашей системы управления будет расти.