Вопрос из зала: один сотрудник и множество сервисных объектов

Сергей Посыльный спрашивает:


Работаем с системой построенной по третьему ITIL (BMC Remedy — не сочтите за рекламу).

В третьем ITILе по которому построена наша Remedy, обращения, инциденты, изменения разнесены по разным сущностям.

Мы говорим своим специалистам: закончил работу с Инцидентом залезай и бери новый (в зависимости от приоритета и крайнего срока).

Однако в нашей системе (да и презенташку MS видел – там та же проблема существует) для просмотра разных сущностей – разные «вьюшки».

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

Может быть подскажут уважаемые коллеги что с этим можно сделать или как выкручивались из этой ситуации?


Версия редакции портала realitsm.ru — на картинке. А что думаете вы?

© cybertheater.com
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

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

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

  1. Александр Жилинский

    Есть техническое решение проблемы — «общая вьюха» (в HP SD, HP SM, OmniTracker это возможно; именно для Remedy решения не знаю).

    Есть процессные решения. В качестве процесса, реализующего единую сущность (общего объекта) может выступать, например Управление Работами. Которого, кстати, пока нет в ITIL, но это минус в основном для ITIL.

    1. Андрей Загорский

      На предыдущем месте работы рабочее место дежурного инженера (что-то вроде совмещенного ХелпДеска и 1-1.5 линии поддержки) так и выглядело — 3 широких ЖК монитора 🙂

  2. Pavel Solopov

    Вы уверены, что в BMC такого нет? Может внедренцы забыли показать куда кликать?

    Я в BMC не дока, но короткий гуглинг дал мне вот такой документ:

    remedy.ucsf.edu/remedy/70...uide_Ver_1.0.pdf

    В нём есть такая фраза: The Overview console displays all records together in one table (Incident, Problem,

    Task, Change, etc.)

  3. Grigory Kornilov

    А зачем куда-то залезать и что-то смотреть?

    Если вы хотите стоить конвеер, то самое бенефитное, чтобы при отрабоке инцидента автоматом система подкидывала новый (на основе приоритетов и специализацию сотрудника).

    PS: 2 монитора для специалиста (в нашей компании) уже норма, причем на это идет бизнес, тратящий деньги.

  4. Георгий

    что-то я не пойму, в чем проблема.

    Если технически, то в любом соверменном решении, такая возможность (общего представления на разные объекты) есть.

    конкретно по Remedy — обращайтесь, подскажу

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

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

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

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28