Интерфейс для каталога услуг

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

 

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

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

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

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

Что хочется?

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

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

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

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

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Konstantin

    Тоже этот вопрос интересует. Пока слышал, что Sysaid собираются добавить в свою систему каталог услуг (якобы релиз летом будет), но как это будет выглядеть пока непонятно, вебинар на эту тему к сожалению пропустил... ((

  2. Андрей

    Опираясь на собственный опыт скажу:

    1. Инциденты — это не в каталог, а в ServiceDesk. Можно на отдельном линке со стартовой страницы протала самообслуживания, но инцидент, это не услуга.

    2. Заказ доступа к системам тоже не каталог. Основа каталога — ИТ услуга. Роль- это, как правило, доступ к НЕСКОЛЬКИМ ИТ услугам. К тому же, предоставление доступа практически никогда не заказывается самим пользователем. Т.е. сами пользователи не решают, к чему им нужен доступ. Обычно им назанчают роль, которая содержит доступы, необходимые для выполнения этой роли. Заказ доступа лучше отправить в IM (Identity Management).

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

    1. Андрей Труфанов Автор

      Здесь есть, что прокомментировать, далее по порядку.

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

      2. Если IM в организации присутсвует, то это прекрасно, и этот интерфейс в нашем случае должен позволять «заказывать роли» для пользователей, оставляя исполнение этих назначений на IM. Если IM слаб или отсутствует, то чаще всего эти запросы реализуются через отдельный класс сервисных запросов со своими моделями. Опять же, задача интерфейса и в этом случае остается той же.

      3. Интерфейс типа «магазин» с «корзиной» требует от заказываемых элементов быть неизменными, не иметь параметризации. Если жы мы при заказе начинаем использовать какую-то параметризацию, использовать мастеры, то смысл корзины в виде «собрать в кучу и заказать/оплатить разом пакет» пропадает. Если опция оплаты отсутсвует, то манипуляции с "корзиной" только добавляют кликов.

       

      1. Андрей

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

        2. Даже если IM есть, исполнение запроса зачастую сопровождается заявками, но это change order  в ServiceDesk, а не заказ отдельной услуги. Хотя — можно вывести отдельную услугу — предоставление доступа, а уже в рамках услуги реализовать процесс выбора и назанчения ролей.

        3.Категорически не соглашусь. Мы через каталог реализовали услугу — заказ видеоконференцсвязи, между различными городами, в городах различные офисы, в офисах различные люди-участники, в различное время с различными уровнями поддержки. Параметров там было более чем достаточно:))). Можно не платить, но можно/нужно отправить на согласование. Вы конечно можете не собирать корзину, а по каждой хотелке размещать заказ — кликов будет ни как не меньше. 

         

        1. Андрей Труфанов Автор

          по п.1 — спорить можно, но не буду, это отдельная дискуссия о роли и ответственности SD в отдельно взятой организации

          по п.3

          Если это не «военная тайна», то можете поделиться скриншотами по вашему п.3? Можно грубо ретушированные, интересен только подход и дизайн реализации, особенно в части параметризации.

          Согласовывать все равно надо многое, и разные запросы на практике согласовываются с разными людьми. Вопрос в эргономике, да.  

           

                1. Андрей Труфанов Автор

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

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

                  Визуально интерфейс выглядит несколько устаревшим, особенно в части работе со списками (это ИМХО). Представленные скриншоты — не web. В целом функционально, интерфейсно — это примерно тот уровень от которого и хочется оттолкнуться и сделать его более user-friendly.

                2. Андрей Труфанов Автор

                  С разрешения Андрея публикую изображения.

                  1. Общий вид окна каталога - http://imgur.com/Ec10KaY

                  2. Выбор услуги - http://imgur.com/wecU50P

                  3. Мастер заказа - http://imgur.com/2oaLGVs

                  4. Сложный мастер - http://imgur.com/zYTid0a

                  5. Настройка маршрута согласований - http://imgur.com/zYTid0a

  3. Андрей Щербаков

    День добрый всем! Делал несколько разных вариантов, пришел к выводу, что оптимум — вопросник, т.к. составляется ИТ и позволяет 1. хоть как-то достаточно достоверно идентифицировать инцидент/запрос, 2. Получается короче классического дерева при том же Каталоге услуг (в моем случае 400+), 3. Позволяет прозрачно для пользователя "склеить" инциденты и запросы нп обслуживание. Минусы — тяжелая первичная настройка, достаточно громозкое администрирование. По инструментам — самому интересно. Реально удобных пока не встречал ибо хочется и иерархию (для КУ) и отношение многие ко многим (для вопросника).

  4. Евгения

    Андрей, добрый день!

    наша компания как раз подходи под ваше описание: крупная, с большой службой ИТ.

    У нас уже внедрены базовые процессы — управление инцидентами, изменениями, активами и т.д. Мы используем тех. платформу ИнфраМенеджер.

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

    Если вас интересует какая-либо еще информация, могу ответить на вопросы в почте.

    1. Андрей Труфанов Автор

      Евгения, я ознакомился с материалами по этому решению и к сожалению скажу, что веб-интерфейс ИнфраМенеджера не может быть образцом, увы. На Youtube нашел ролик по веб-интерфейсу (правда 2012 года) и он просто ужасен, честно. В версии 5.6 (судя по доступным скриншотам) были достигнуты определенные результаты по улучшению внешнего вида, но концепция осталась прежней. Структура "Дерево слева — список справа" уже недостаточно функциональна. Приведенный выше в пример IBM наглядно это подтверждает.

      Не увидел возможности использования мастеров для заказа услуги/ подачи обращения

      Даже портал поддержки многое объясняет:

      support.iiko.ru/sd/help/r...?privatepage.htm

      Евгения, если я не прав — разубедите меня. Это не то, чем хотелось бы пользоваться.

      1. Евгения

        Андрей,

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

        В любом случае, если вам будет не сложно поделитесь потом подробностями о вашей системе, пожлуйста. Для нас тоже интересен подобный продукт.

  5. Владимир

    Согласен, что для требуемой задачи очень многие конструктивные или интерфейсные решения неочевидны и более этого – не реализуемы: инструмент web-порталов Омитрекера или HP Сервис менеджера ограничен платформой, логикой и БД. С точки зрения заказчика —  web-портал не должен каждый раз **** лицензию учетной системы для входа, ведь пользователь может тратить много времени для оформления, чтения и т.д. Нельзя ли лицензию использовать только на момент передачи данных от web-портала в учетную систему? Нельзя делать порталы на оторванных от учетных систем платформах?

    Видел собственную внутреннюю разработку компании web-портала, которая лезла в БД Сервис менеджера и тянула оттуда данные, которые можно было отдельно отбирать, сортировать, выгружать в Excel, да ещё и показывать сколько времени обращение находится «без движения». Это было сделано настолько удобно и работало так быстро, что в интерфейс Сервис менеджера заходили, если требовалось большее, чем просто посмотреть. Платой за удобство был минус – при обновлении версии учетной системы, приходилось править «съехавшие поля» и для такого портала нужно держать «своего» администратора.

    P.S. Коллеги, дайджест читаю с интересом, спасибо! Можно рассылку дайджеста – проводить по пятницам, а не в понедельник? В понедельник очень много работы, нормально почитать и поучаствовать в дискуссиях – не всегда получается 🙁

    1. Андрей Труфанов Автор

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

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

    1. Андрей Труфанов Автор

      Концепия интерфейса «все в одном фрейме» хорошо смотрится на мобильных устройствах. Для веб-интерфейса хотелось бы иметь больше информации на экране, в виде навигации, связей между разделами, сейчас при заказе ноутбука нет summary по инцидентам по нему, например. При заказе Если у меня как у корпоративного клиента есть возможность выбирать, я бы хотел видеть такую информацию, причем не искать её специально. Разделы «Get help» и «Get knowlege» интерфейсно не связаны.

      Эти задачи можно решить в этом интерфейсе штатными средствами?

       

       

  6. Андрей Бангерт

    Добрый день!

    Описанная Вами задача была нами реализована для одного из наших клиентов следующим способом:

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

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

    Выглядит это примерно так:

    "У меня не работает"(из списка на первом уровне) => "Мне не удалось запустить программу" (из списка на втором уровне)

    После нажатия на "Мне не удалось запустить программу" открывается форма для заполнения, например, со следующими полями:

    ФИО: <текстовое поле> (заполняется автоматически из AD, если необходимо)

    Ваше местоположение: <поле выбора> (заполняется автоматически из AD, если необходимо)

    Программа: <выбор из списка>

    Описание проблемы: <текстовое поле>

    Вложения:<выбор файла> (например скриншот ошибки)

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

    В данный момент разработка активно используется, портал опубликован по короткой ссылке.

    Если Вас заинтереует наша разработка пишите на эл. почту

    a.bangert@dynamicbusiness.ru

  7. Ольга

    Сами такое искали очень долго и мучительно. Решения на sharepoint изначально не рассматривали так как надоело.

    Сегодня посмотрели одно из решений где более менее внятно реализовна каталог. Из перечисленных вами требовнаий увидели все=)

    И да

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

    Мне очень понравилось.

    Решение на отдельном портале или штатном интерфейсе ITSM продукта?

    На штатном интерфесе, допиленном

     

    не знаю, можно ли размещатьссылки или это будет сочтено рекламой...

     

     

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Empty