Портал №1 по управлению цифровыми
и информационными технологиями

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

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


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

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

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

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

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

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


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

© cybertheater.com

Комментариев: 10

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

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

    • …причем хорошо бы, чтобы техническое решение – та самая общая вьюха типа “мои задачи” – была основана на процессном решении о том, как эти самые задачи должны строиться в общую очередь.

  • А мне нравится версия редакции. Настоящие айтишники только так и работают: http://www.tnnewspress.com/images/Multi-Monitor-Control-Room-Console-10.jpg

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

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

  • Pavel Solopov

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

    Я в BMC не дока, но короткий гуглинг дал мне вот такой документ:
    http://remedy.ucsf.edu/remedy/7004-DSY/version/default/part/AttachmentData/data/Remedy_ITSM_7_Change_User_Guide_Ver_1.0.pdf

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

  • Даже в 4.5 существует раздел “Service Today”. Неужели софт пошел по отрицательному пути развития?

  • Alexander Peshkov

    Баба яга за передачу исполнителям одной универсальной сущности – работы. И красивые кубики, в стиле Project.

  • Grigory Kornilov

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

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

  • Георгий

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

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

    Если “процессно”, то это не проблема, для этого не обязательно городить отдельный процесс или процессы (хотя можно конечно, так даже круче в чем то:)).
    Речь всего лишь о том, что когда в организации появляется более одного формализованного процесса (пусть, например, по ITIL, это нам ближе), которые проходят через одни и те же функциональные единицы (пусть, например, через ИТ-отделы, это нам ближе), то в организации обязана появиться некая общая система этих процессов, которая помимо прочего, должна включать в себя механизмы приоретизации задач этих процессов между собой (механизмы приоретизации задач внутри процесса – внутреннее дело процесса).
    Под громким словом система, я конечно не имею ввиду что всегда нужна СУИС с кучей документации итп, а под механизмом приоретизации я не имею ввиду, что он должен быть сложным и обязательно иметь формулы расчета приоритета с использованием криволинейных интегралов 2 вида.
    Просто нужно иметь ввиду, что такая система в каком то виде нужна и механизм внутри нее должен быть. Как делать – другой вопрос, как всегда зависит от специфики

    • “обязательно иметь формулы расчета приоритета с использованием криволинейных интегралов 2 вида”

      О-о, мсье понимает толк 😀


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM