Тема для обсуждения предложена читателем нашего портала. (См. раздел "Задать вопрос").
"Как с помощью ITSM-процессов улучшить качество ИТ-услуг? Есть несколько процессов. Все эти процессы, конечно, косвенно влияют на качество сервисов, инциденты решаются своевременно, проблемы не остаются без внимания, изменения не приводят к новым инцидентам. Однако, если взглянуть на статистику, то оказывается, что количество инцидентов не только не уменьшается, но даже потихоньку растет, соответственно можно сказать, что качество сервисов по основному показателю ухудшается. Корень проблемы видится в том, что имеющиеся метрики и построенная на них система мотивации нацелены исключительно на качество работы процессов (своевременная и упорядоченная обработка инцидентов, проблем и т.п.). В итоге получился скорее менеджмент ITIL-процессов, а не сервисов, так как за сами сервисы никто как бы и не отвечает."
Давайте разберемся по порядку. Начнем с того, что есть качество. Обычно под "качеством" мы понимаем степень соответствия определенным стандартам или договоренностям. Например, продукт питания качественный, если он вкусно пахнет, сделан из понятных ингредиентов и не сокращает продолжительность жизни.
С ИТ-сервисами примерно такая же история. Говорить о снижении качества ИТ-сервиса мы сможем после того как определим показатели, по которым мы этот сервис оцениваем, и зафиксируем ожидания от значений этих показателей. Например, по ИТ-сервису "Электронная почта" важен показатель доступность. Определим его целевое значение как 95%. Тогда сможем говорить, что в декабре доступность была 98%, а в ноябре 80%, значит в декабре ИТ-сервис был качественным, а в ноябре нет. Естественно возникает вопрос, откуда мы возьмем перечень показателей и их целевые значения. Ответ в разных ситуациях может быть разным, например, это может быть процесс SLM или некая деятельность на него похожая. В идеале, показатели и их целевые значения должны исходить от потребителей.
Поэтому в отношении такого показателя как "количество инцидентов" возникает вопрос, интересен ли он потребителям? Скорее всего нет, ведь 2 крупных инцидента за месяц могут остановить работу ИТ-сервиса на более продолжительное время, чем 10 мелких. К тому же рост числа инцидентов может быть продиктован объективными причинами, которые не связаны с качеством ИТ-сервиса. Например, выросло число пользователей, многие из которых видят ИТ-систему впервые, или вышло обновление ИТ-системы и пользователям стали доступны новые функции.
Теперь давайте разберемся с тем, чем нам могут помочь ITSM процессы. Исходя из сказанного выше, разматывать клубок качества ИТ-сервисов удобно от требований заказчиков (потребителей) ИТ-сервисов. Т.е.
- Поняли какие ИТ-сервисы мы предоставляем (например, "Электронная почтв").
- Поняли какие параметры ИТ-сервисов важны заказчикам (например, "Доступность").
- Поняли как на эти параметры можно повлиять (например, обработка обращений пользователей, контроль компонент инфраструктуры, аккуратное изменение инфраструктуры и т.д.).
- Поняли как организовать свою деятельность (например, в виде процессов управления инцидентам, событиями, изменениями) так, чтобы она решала задачи п.3. Деятельность можно выдумывать самостоятельно, а можно обратиться к ITIL, ISO и т.п.
И вот после того как вы придумали и внедрили деятельность, которая по вашему мнению решает задачи п.3., важно следить за тем, чтобы оно именно так и работало и решало эти задачи, еще лучше, чтобы делала это рационально. Вот тут и приходят на помощь метрики и деятельность по контролю и совершенствованию самих процессов, в ходе которой мы формируем мероприятия, позволяющие нашим процессам работать лучше. Но не стоит забывать ради чего эти процессы придумывались, важно чтобы первоначальный посыл о параметрах ИТ-сервисов и качестве ИТ-сервисов не был забыт.
Поэтому в идеальной картинке наряду с деятельностью по оперативной работе с ИТ-сервисами и компонентами инфраструктуры, должна быть еще деятельность (менее оперативная) по выявлению изменений в требованиях, выяснению причин нарушения договоренностей, разработке предложений по совершенствованию ИТ-сервисов и процессов, обеспечивающих их работу, поддержку и т.д. Иными словами в списке из 4х пунктов должен появиться 5й: "Контроль качества ИТ-сервисов и формирование предложений по совершенствованию ИТ-сервисов и процессов." тогда вы получите уже не только "менеджмент процессов", но и "менеджмент ИТ-сервисов".
А вы что думаете?
В таких ситуациях, как описана в вопросе, обычно говорят: «вот внедрите SLM и тогда…». А что тогда? Процессы группы SLM у нас обычно внедряют в последнюю очередь, но ведь к первоначальному решению о внедрении СУИС приходят уже с определенным набором целей. И одна из главных целей обычно повышение стабильности работы ИТ, то есть, например, уменьшение количества инцидентов и времени простоев. При этом существующий уровень качества работы ИТ априори следует считать неудовлетворительным.
Я считаю, что процессы ITIL всего лишь инструменты необходимые для достижения требуемого качества ИТ-сервисов. Но кто должен этими инструментами пользоваться? На практике вместо СУИС зачастую получается набор айтиловских процессов, к тому же совершенно не связанных между собой, где есть роли, отвечающие за работу процесса, но нет людей отвечающих за решение основных целей СУИС, а значит, нет и взаимодействия процессов, нет системы. Думаю, тему данной статьи можно конкретизировать: «кто и как должен отвечать за качество ИТ-сервисов?».