Практика управления проблемами по методологии ITIL
Решение бизнес-задач с помощью технологий – устоявшаяся практика, при этом обойти проблемы, связанные с программным обеспечением, крайне сложно. Внедрение практики управления проблемами позволит оптимизировать большую часть бизнес-процессов и снизить издержки на IT-услуги. Рroduct owner ELMA365 Service Виктор Ситник и технический директор компании Onellect Константин Боколяр объяснили, как сделать ITSM-систему эффективным инструментом для управления проблемами и минимизировать их влияние на бизнес в целом.
Проблема и инцидент: в чем разница
На рынке больше 30 лет существует библиотека ITIL, которой пользуются многие компании, но, несмотря на это, до сих пор пользователи не всегда правильно используют термины «проблема» и «инцидент». Давайте разберемся в этих понятиях.
Инцидент – незапланированное прерывание услуги или снижение качества обслуживания.
Проблема – причина возникновения одного или нескольких инцидентов. То есть, проблема – это не инцидент, ею надо заниматься отдельно, и связывать два этих понятия не рекомендуется.
Практика по управлению проблемами ставит своей целью снизить вероятность и уровень влияния инцидентов на решение бизнес-задач путем выявления фактических и потенциальных причин этих инцидентов, с последующим поиском обходных путей по известным ошибкам.
Жизненный цикл практики управления проблемами состоит из нескольких этапов.
1. Идентификация проблемы. В своей практике компании периодически сталкиваются с ситуацией, когда возникает одна и та же техническая «неполадка». Например, на этапе формирования отчета программа 1С зависает. После обращения в службу поддержки вопрос решается, однако в следующий раз история повторяется. В таком случае у IT-специалистов возникает вопрос: почему так происходит и какая причина на самом деле стоит за такими зависаниями? Они пытаются классифицировать проблему. В ITIL есть два способа выявления проблем: реактивный и проактивный. Первый подходит, когда появился инцидент, и нужно найти причину его возникновения, а второй – когда нужно выполнить набор действий, которые нацелены на то, чтобы инцидент в принципе не появился.
2. Управление проблемой. Второй этап – самый важный, так как здесь IT-специалисты пытаются определить набор действий, который приводит к возникновению проблемы, в том числе во время беседы с сотрудниками, сталкивающимися с ней. Затем в тестовой среде они попытаются воспроизвести ситуацию, после которой проблема возникает. В случае с зависанием 1С повторяется тот же порядок действий и восстанавливается цепочка событий, чтобы найти причину, ставшую триггером для проблемы.
3. Контроль ошибок. Идеальным решением возникшей ситуации будет полное устранение ошибки, но, к сожалению, такой итог не всегда возможен по разным причинам. Например, это может быть дорого, нецелесообразно или невозможно из-за того, что причиной является оборудование вендора, которое не обладает необходимым функционалом.
Практика управления проблемами позволяет быстро их обнаружить и устранить причины возникновения. Исходя из этого, важно, чтобы система сервис-менеджмента позволяла весь этот жизненный цикл реализовывать, и ITSM была эффективным инструментом, способным выстраивать предлагаемый процесс.
Больше материалов на эту тему читайте в Компас CIO
Обязательные функциональные требования к ITSM-системе
Для того, чтобы проблемы и инциденты не оказывали серьезного влияния на бизнес-процессы, нужно грамотно подойти к их решению. Рассмотрим, какие функциональные требования позволят это сделать.
1. Выделение отдельного подразделения, занимающегося проблемами. Важно, чтобы проблемой управляли отдельные сотрудники и аналитики, а те, кто занимается инцидентами, не участвовали в процессе. Дело в том, что задачи практик управления инцидентами и проблемами сильно отличаются друг от друга. Если инциденты нужно разбирать как можно скорее, то проблему можно разрешать несколько дней или месяцев, а иногда и вовсе не найти решения, определив вместо этого эффективный обходной путь.
2. Возможность сбора статистики по инцидентам. Выявление корневой причины проблемы состоит из анализа предшествующих ей инцидентов, поиска информации в базе знаний о разрешении инцидентов в подобных ситуациях.
3. Кастомизация формы и полей проблемы. В каждой компании существует своя практика управления проблемами, под которую они хотят кастомизировать форму, придумать поля и использовать в них уникальные наборы знаний. Продукт low-code позволяет удобно и быстро, без привлечения вендора или интегратора, самостоятельно кастомизировать форму подачи обращения, в том числе форму проблемы.
4. Наличие возможности связывать проблемы с другими сущностями системы. Это необходимо для того, чтобы вся цепочка, от возникновения инцидента до появления запроса на изменения и выпуск релиза, отслеживалась в системе. В таком случае аналитики, участвующие в разрешении проблем, могут отследить эту цепочку, выстроить причинно-следственные связи, а затем либо полностью устранить проблему, либо найти эффективное обходное решение.
Преимущества управления проблемами по методологии ITIL
Зачастую IT-специалисты и руководители подразделений понимают, насколько важно внедрять отдельную практику по управлению проблемами, однако обосновать руководству или финансистам видение, зачем покупать систему или выделять дополнительный ресурс в виде персонала, не могут. Очевидными выгодами для бизнеса становятся сокращение времени простоев от инцидентов и снижение числа сбоев, а следовательно, долгая бесперебойная работа всех сотрудников и отделов.
Но помимо этого есть еще и не такие явные преимущества. Рассмотрим некоторые из них:
- улучшение коммуникации между сотрудниками разных отделов;
- развитие базы знаний и появление регламентов о том, как быстро обойти инциденты;
- улучшение контакта с бизнес-подразделениями;
- повышение имиджа IT;
- дополнительная мотивация для сотрудников. Когда в компанию приходит молодой IT-специалист, со временем он хочет карьерного роста. Заведя практику управления проблемами, фирма может предложить ему использовать свои навыки в чем-то новом и через эту практику повышать компетенции;
- сокращение нагрузки на IT;
- снижение стоимости IT-услуг.
Благодаря внедрению практики управления проблемами, сбои в программном обеспечении сокращаются, а инциденты по особо критичным для бизнеса сервисам решаются быстрее.