Коллеги, приветствую!

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

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

Сейчас в нашей компании ведется целевая работа по организации удобного интерфейса для портала самообслуживания, и подход к организации такого интерфейса вызывает споры. Поскольку мы работаем над созданием интерфейса для того, чтобы им можно было пользоваться в режиме реальной эксплуатации, а не для того, чтобы презентовать его на показах в контексте "вот наш прекрасный портал; вот все ваши 5 (пять) услуг демо модели", то и требования к нему формулируются достаточно жестко.

Представим себе крупную компанию с развитым и распределенным блоком ИТ. В компании есть действующий каталог услуг, с различными бизнес-подразделениями заключены SLA. Подразумеваем, что пользователь, обращающийся с инцидентом, с сервисным запросом или даже стандартным изменением, владеет русским языком и наделен разумом для навигации по порталу и самостоятельной регистрации обращения. Интерфейс содержит текстовые поля и справочники, нет потребности сводить интерфейс к одной большой "аварийной" кнопке. Более того, подполагается, что в последующем такой портал будет обогащен выходами к статьям базы знаний и соотвествующим информационным обвязкам. Длина списка доступных видов обращений среднестатистического пользователя измеряется в десятках: в список входят различные виды обращений по рабочему месту и стандартному ПО, поддержке профильного ПО (полномочия, настройки, администрирование; пользователь пользуется не одной, а несколькими системами).

Что хочется?

1. Веб-страница, безальтернативно
2. Обеспечение прозрачной и однозначной навигации с минимальным числом кликов/скроллов по перечню предварительно разрешенных для данного пользователя видов обращений с/без группировкой по услугам, доменам ИТ-архитектуры, бизнес-процессам. Древовидный, плиточный или плоский интерфейс (по вкусу 🙂 ).
3. Кроме списка иметь возможность удобного поиска услуг в каталоге, отображения детальной информаци об услуге до её заказа.
4. Ряд видов обращений, например на предоставление полномочий пользователю в специальном ПО, может требовать специальных форм и процедур обработки. Большим плюсом будет наличие конфигурируемых мастеров, которые будут позволять кастомизировать или детализировать подаваемую заявку (контекстные радио-кнопки, чекбоксы, справочники).

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

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

Поделитесь знанием, в каком продукте эта задача решена наиболее корректным на ваш взгляд образом? Видели ли вы решение в продуктивной среде которое бы вам понравилось, чтобы прямо "так нравится, сам бы пользовался"? Решение на отдельном портале или штатном интерфейсе ITSM продукта?

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

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

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