От переводчика: любопытная статья Стюарта Рэйнса с предложением, как ИТ повысить свою ценность в рамках компании, перейдя от управления инцидентами в ИТ к управлению инцидентами в бизнес процессах компании.

Идея не нова и известна, как Enterpeise Service Management. Вряд ли его можно и стоит применять повсеместно, но если у руководства компании есть вера и доверие к ИТ, а также персонал и процессы ИТ обладают соответственно высокими уровнями сервисной культуры и зрелости. Тем не менее, как саму идею стоит знать и понимать, также она вполне подходит, как цель, к которой стоит стремиться.

Ссылка на оригинал
Опубликована 15.01.2018.
Сложность: начальный уровень (идеология)

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

Что такое инцидент?

Наиболее популярный сейчас в мире сборник практик по управлению ИТ услугами — ITIL даёт такое определение инцидента:

«Незапланированное прерывание ИТ услуги или ухудшение качества ее предоставления…»

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

Мой клиент же определяет инцидент по другому. Инцидент — это

«любое отклонение продукта бизнес процессов в сторону нежелательного для бизнеса результата.»

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

Кто может предложить действие для решения инцидента?

Обычно управление инцидентами фокусируется на проблемах с ИТ. Необходимые действия предлагаются сотрудниками из ИТ, ответственными за решение инцидента. Если им требуется участие заказчика в решении (требуется какое-либо действие), то оно часто не выглядит, как часть процесса управления инцидентами, и ИТ может иметь немного влияние на (или ответственности за то) как и когда эти действия выполняются. В худшем случае ИТ “выключает счётчик" и перестает учитывать время ожидания выполнения действия заказчиком в своем целевом значении показателя процесса управления инцидентами.

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

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

Когда закрывать инцидент?

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

По рекомендациям ITIL инцидент должен находиться в состоянии “решен” до того момента, пока заказчик не подтвердит, что его можно закрыть. На практике же многие ИТ организации автоматически закрывают инциденты, если заказчики не дают им обратную связь о результате в течение определенного времени.

Организация же, следующая бизнес ориентированному определению инцидента, приходит к однозначному пониманию, что инцидент может закрываться только ПОСЛЕ того, как все отклонения бизнеса процесса заказчика были устранены. Это означает, что все запрошенные действия от заказчика уже выполнены и всё сейчас возвращено в штатное состояние.

Какие отчеты об инцидентах создавать?

Обычно отчёты управление инцидентами сосредоточены на том, как быстро ИТ организация решает инцидент. Это может быть полезным при планировании и управлении совершенствованием ИТ и показывает, на сколько выполняются обязательства перед заказчиком по уровню обслуживания услуги (Service Level Agreement, SLA). Но для бизнеса такой подход ценности практически не несет.

Когда Вы переопределите инцидент на более “бизнесовый” вариант, то с большей вероятностью будете создавать отчётность, несущую ценность для бизнеса:

• На сколько значительные негативные последствия были в бизнес процессе?
• Какие причины наиболее часто вызывают инциденты? (Часто проблемы с ИТ будут не при чем).
• Где в процессе решения инцидентов случаются наиболее длительные задержки?

Все эти данные могут помочь планировать и управлять совершением того, как управляется бизнес. А также на сколько хорошо ИТ помогает бизнесу.

Заключение

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

Источник изображения: miningcamper