ITSM-практик с огромным опытом Филлис Друкер в заметке  «Каталог запросов на обслуживание: избегаем падения» («Service Request Catalog: Failing to Fail») на портале AllThingsITSM анализирует наиболее распространённые причины неудач запуска сервисного портала (подразумевается портал самообслуживания [каталог сервисных запросов] а также функционал онлайн–представления каталога услуг).

Одной из основных причин она называет отсутствие фокуса на потребителя.

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

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

Рецепт успеха, казалось бы, простой:

• Понять потребности пользователей
• Понимать, как они используют интернет и осуществляют шоппинг
• Понимать их ожидания

Перед тем, как приступать к построению портала, автор очень советует оценить возможность расширения задачи за пределы ИТ и изучить опыт успешных… интернет магазинов (например, Amazon, e-Bay). По мнению Филлис Друкер, три ключевые области, требующие внимания следующие.

Охват

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

Поэтому хорошей идеей является привлечение других поставщиков услуг для обсуждения будущего каталога.

Привычное взаимодействие (пользовательский опыт)

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

В крупных магазинах (в т.ч. интернет-магазинах) для группировки товаров существуют отделы. В хороших магазинах отделы понятны покупателю. Как выглядят «отделы» в каталоге услуг? Не редко это деление по функциональному (или территориальному) признаку деления внутри поставщика услуг, что абсолютно не понятно пользователю. {Замечательным примером последнего на протяжении многих лет был «портал» gibdd.ru. Да и портал gosuslugi.ru на ранних этапах в точности подходил под это описание}

Разумеется, терминология, используемая в описании должна быть не технической, а «человеческой».

Функциональность

Amazon не ожидает, что пользователь является экспертом. Amazon проводит пользователя через процесс. В том числе напоминает о выбранных, но забытых товарах или товарах, которые могли бы быть полезны (купили ноутбук – не нужна ли вам для него сумка?).

Понять, что ожидает пользователь, по мнению автора, просто – нужно думать об использовании сервисного каталога, как об интернет-шоппинге. Ключевые компоненты здесь следующие:

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

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

1. Определение заинтересованных сторон (stakeholders). Кто может помочь в построении каталога? Для кого может быть полезен данный инструмент (другие поставщики услуг в организации кроме ИТ). Учет мнения маркетинга и службы внешних коммуникаций для соответствия стандартам брэнда стратегии интернет-коммуникаций, что поможет развитию проекта в будущем.
2. Определение потребностей заинтересованных сторон
3. Использование гибкого итеративного подхода. Ненужно пугаться большого масштаба задачи. Можно в том числе рассмотреть подход с двух сторон:
   • Определить наиболее часто используемые запросы по всем поставщикам услуг в организации и реализовать в первую очередь их
   • Сначала построить каталог для одного поставщика услуг, потом двигаться к следующему.

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

Интересно, у кого и в какой мере был реализован описываемый Феллис Друкер подход?
Любопытно посмотреть через призму описанной системы на практический опыт реализации (например, участник форума Олег, привёл довольно подробное описание собственного опыта и в самом начале комментария описывается как раз решение вопроса охвата первой фазы проекта).
Коллеги, а как это было/планируется у вас?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности