Как пришить SLM к поддержке

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

Сложности перевода

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

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

Наиболее распространенный первый шаг – построение каталога ИТ-услуг, который бы позволил решить несколько задач:

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

При этом часто такой каталог строится от ИТ-ресурсов², то есть в каталоге фигурирует по сути перечень ИТ-систем, элементов инфраструктуры и так далее. Такой подход удобен для классификации поступающих обращений, так как в большинстве случаев пользователи знают, с какими системами они работают. Однако с таким каталогом ИТ-услуг сложно решать основную задачу SLM – ведение диалога с Заказчиками:

• предъявлять требования Заказчикам проще, ориентируясь на свои бизнес-процессы. Тем более что одна система может использоваться сразу в нескольких бизнес-процессах;
• анализировать отчетность и оценивать влияние ИТ на бизнес-процессы тоже лучше в разрезе ИТ-услуг, построенных от бизнес-процессов.

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

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

Классификация

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

Во-первых, можно узнать об ИТ-системе или оборудовании, с которыми у пользователя возникли проблемы/задачи. Например, он может сказать «Я работаю в системе А», «Я пытался зайти в систему B» или «Мне нужно получить доступ к системе C».

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

Для этого, можно уточнить, в чем именно заключается причина обращения:

• какую часть своей работы (какое действие в рамках бизнес-процесса) пользователь не может выполнить;
• что требуется от ИТ-специалистов. Например, дать определенные права, перенести компьютер, скорректировать справочные данные, восстановить данные.

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

Построение классификатора

Порядок построения классификатора отличается от порядка его последующего применения. Традиционно основой для построения служит каталог ИТ-услуг. Последовательность шагов следующая:

1. построение списка ИТ-услуг;
2. построение списка ИТ-систем;
3. построение перечня причин обращений с привязкой к ИТ-системам и ИТ-услугам.

Список ИТ-услуг

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

Список ИТ-систем

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

Причины обращений

В том случае, если ИТ-услуги специфицировались с применением метода сервисных операций³, все просто:

• среди перечня сервисных операций, выделяем те, по которым должна осуществляться поддержка пользователей;
• дополняем перечнем стандартных запросов на обслуживание: предоставление доступов, корректировки справочников, выполнение других регламентированных работ.

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

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

Расстановка связей

Следующим шагом после формирования списка причин обращений является расстановка связей между получившимися справочниками. Простейший вариант модели данных выглядит следующим образом:

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

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

То есть перейти к модели:

В данном случае наиболее распространенные причины обращений, характерные для различных ИТ-систем и ИТ-услуг, могут существовать в справочнике в единственном экземпляре. Например, «Предоставление доступа».

Кроме того, такой подход позволяет менять последовательность классификации поступающих обращений, начиная не с определения ИТ-системы, а с причины обращения. В таком случае наряду с традиционной последовательностью классификации «ИТ-система → Причина обращения → ИТ-услуга» мы можем также использовать следующую последовательность:

• выясняем причину обращения;
• определяем ИТ-систему;
• на основании причины и ИТ-системы ИТ-услугу.

Однако следует учитывать, что множественные связи приводят к двум негативным последствиям:

• управлять таким классификатором значительно сложнее;
• не всегда на основании ИТ-системы, причины обращения и информации о потребителях ИТ-услуги ее можно будет вычислить однозначно. Иногда результатом будет перечень ИТ-услуг, из которых придется вручную выбрать единственно верную, например, при закрытии обращения.

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

Приведу небольшой пример, чтобы прояснить картину. Предположим, что две ИТ-системы A и B используются в предоставлении двух ИТ-услуг 1 и 2, при этом в каждой ИТ-услуге используются обе системы. Тогда пример классификатора, построенного по второй схеме, может иметь вид:

Сложности и пути их преодоления

На стороне пользователя

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

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

Последовательность фильтрации в этом случае следующая:

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

Таким образом, с чего бы ни начал заполнение формы пользователь, мы сможем упростить ему выбор.

На стороне ИТ-специалистов

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

При этом фактам корректировки классификации обращений следует уделять особое внимание:

• некорректная классификация на стороне пользователей может говорить о том, что классификатор неудобен, неполон, непонятен пользователям;
• некорректная классификация на первой линии может говорить о необходимости обучения специалистов, подготовки специальных опросных листов или корректировки классификатора;
• изменение классификации на второй линии может быть способом ухода от ответственности за просроченные обращения (например, достаточно выбрать причину обращения, с которой связаны менее жесткие сроки).

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

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

Выводы

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

Сноски

1. Здесь и далее под процессом поддержки пользователей имеется виду процесс, построенный на базе процессов Incident Management и Request Fulfilment процессной модели ITIL.
2. Подробнее см. статью в Альманахе itSMF 2015 «Подходы к формированию каталога ИТ-услуг» Д.Денисов, Д.Исайченко
3. См. статью в Альманахе itSMF 2015 «Метод сервисных операций» Д.Исайченко

Автор: Евгений Шилов