Результат решения

[JohniGo]

Собствено продолжаю пихать методические вопросы в раздел "Общее".

Решаю локальную проблему, как заставить агента писать результат решения при устранении инцидента. Постояно натыкаюсь на заявки с текстом "не работает" с заметкой "решено". Даже при наличии для заполнения классификационных полей по типам заявки и сервисам толку от анализа данных тикетов не особо много.
Поделитесь, кому не жалко, кто как решает проблему? Пока есть мысль заставить агента при закрытии заявки писать внутренню заметку с описанием решения и еще ввести классификатор с типами причин сбоя типа "неправильные настройки", "выход из строя оборудования", "тупой юзер не умеет пользоваться" и т.п.
Что-то мне подсказывает, что я изобретаю уже готовый функционал модуля ITSM, но никак не могу разобраться, как-же им пользоваться.

[ykolesnikov]

Добрый день!
В принципе, без ITSM, есть поля типа ArticleFreeText, там можно задать выбор из списка предустановленных значений, также как и в обычных FreeText полях и сделать их обязательными.

[dvp]

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

[ykolesnikov]

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

[JohniGo]

Про раздачу пирожков - это все понятно, и про ArticleFreeText - тоже, но это как говорил один из моих бывших сотрудников "радиолюбительство". Методикой же предусмотрено одно из ключевых направлений - управление проблемами на основе анализа инцидентов. Должны же быть и методики их выявления и какая-то автоматизация. Есть у кого-то еще варианты, кроме стимулирования через правильные места самосознания агентов и философского размышления над многостраничными опусами лирических объяснений кучи инцидентов?

"Жаль, что так и не удалось услышать начальника транспортного цеха" (с) если тут есть люди, кто еще помнит откуда эта цитата.

[alexus]

Вы правильно заметили, что в Проблем-мендежменте ключевое направление - анализ инцидентов. Для помощи анализу нужна корректная классификация инцидентов. И тут функционала OTRS вполне достаточно. А вот анализ уже должен делать опытный сотрудник с ролью проблем-менеджер с помощью

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

И без "пирожков" в виде поощрения за выявленную проблему и рабочее решение оной тут тоже не обойтись, т.к. любому из нас без пирожков со временем становится очень грустно

[JohniGo]

Вы правильно заметили, что в Проблем-мендежменте ключевое направление - анализ инцидентов. Для помощи анализу нужна корректная классификация инцидентов. И тут функционала OTRS вполне достаточно. А вот анализ уже должен делать опытный сотрудник с ролью проблем-менеджер с помощью

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

И без "пирожков" в виде поощрения за выявленную проблему и рабочее решение оной тут тоже не обойтись, т.к. любому из нас без пирожков со временем становится очень грустно

Пирожки - это святое! Пирожки - это наше все!! Мы бесконечно грустны без пирожков!!!

Поставлю вопрос иначе, какие поля кто использует для классификации инцидентов? У меня пока используется сервис и тип инцидента, чего ИМХО явно не достаточно.
Планирую добавить предопределенный справочник причин инцидента, который постепенно будет наполняться и расширяться (в разумных пределах конечно).
Кроме того, возможно сделаю справочник типовых решений (настроено оборудование, обучен пользователь, установлено ПО и т.п.)
Связи с FAQ и с тикетами проблем я так понимаю остаются добровольно принудительными? Или кто-то все-таки жестко регламентирует необходимость связи?

[dvp]

Для меня типа заявки вполне достаточно для классификации. сервисы сначала попробовал спланировать на использование, но понял что не прокатит при моей специфики.
с FAQ у меня все намного проще. если заявка не типична, то пополнять FAQ не обязательно, а вот если ситуация повторилась или МОЖЕТ повториться (выплывет в результате анализа) то FAQ должен быть дополнен обязательно. кроме того клиенту должна быть предоставлена ссылка на статью.
траблшутигн ведется в обязательном порядке и предоставляется совместно с документацией. если мы имеем дело с аппаратными средствами, то идет совместно с мануалом на использование. бумажный вариант обязателен.

[alexus]

Не стоит нагружать инцидент излишней информацией. Опытный админ сможет из минимума выявить проблему. Требовать описания решения и связи тикета с КЕ или статьями FAQ от сервисдеска нужно обязательно, если таковые имеются. И нужно все-таки различать цели процессов управления инцидентами и проблемами.
Основная задача сервисдеска по отношению к инцидентам - скорейшее его устранение. Не нужно при этом заниматься поиском причин, т.е. Проблем!

[JohniGo]

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

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

И нужно все-таки различать цели процессов управления инцидентами и проблемами.
Основная задача сервисдеска по отношению к инцидентам - скорейшее его устранение. Не нужно при этом заниматься поиском причин, т.е. Проблем!

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

Собственно в "священной книге" написано (ЕМНИП), что устраненный инцидент должен ссылаться либо на известную проблему, либо на обходное решение.
Т.е. вопрос в том, как отделить мух от котлет.
К сожалению, вот как раз обязательности я в системе не нашел. Опять же по каждому конкретному косяку типа неправильно настроенной программы на клиентской машине (да даже и на сервере) писать отдельную статью в FAQ как-то ИМХО не правильно. Туда думаю стоит заность только повторяющиеся инциденты, коих не такой большой процент, ну и у которых соответвенно есть корневая проблема, которую надо фиксировать, реашать и т.д.

[alexus]

Об излишества я говорил в контексте дополнительных полей

для классификации инцидентов

А то, что надо или не надо писать решение и с чем связывать тикет, это уже как вам надо. Любые дополнительные нагрузки должны приносить конкретную практическую пользу. И книги эти вовсе не "священные" . Надо в них искать свою собственную

золотую середину

.
Думаю вполне достаточно на первых порах обязать СТП (сотрудник техподдержки) содержательно заполнять текстовое поле при закрытии инцидента, т.е. указывать решение. Когда у вас будет полноценный FAQ и все СТП его будут знать наизусть и учить постоянно по мере пополнения оного, тогда уже можно обязывать связывать тикет с FAQ. То же самое и для CMDB.

[JohniGo]

Резонно, но видимо все зажимают свое "ноу-хау" и неговорят, кто как работает...

[JohniGo]

Коллеги, а не подскажите как использовать функционал кнопулечки "Решение" (Add a decision!)?
В общем-то невооруженным глазом видно, что при нажатии на оную открывается окно "Change Decision of Ticket", где создается внутрення заметка с готовым шаблоном указания причины. (в общем-то это примерно то. чего я и хочу добиться)
Собственно как использовать данный механизм в методологическом плане? К чему его применять: ко всем инцидентам или только к проблемам? Кто должен одобрять или отклонять это решение? и к чему относится это одобрение: к заметке (решению) или ко всему тикету?
Кто использует это механизм, поделитесь плиз!

[ykolesnikov]

А где она, эта кнопочка? У меня ее и нет. У меня по максимуму отключено управление изменениями. Может это там и к нему относится?

[alexus]

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

[yuri0001]

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

Я, конечно, иногда тоже могу так ответить, но, многоуважаемый alexus! Нам, вообще-то и шашечки и ехать, потому что имеем в руках черный ящик и, кроме наших процессов есть еще и постижение новых, возможно, нам пока непонятных возможностей, а там, смотришь, и к процессам прикрутится.
Был простой вопрос. Мог бы быть и ответ простым. На сложные я ответов и не вижу. На Help поместил, все стороной обходят, как от чумы. На английском в Errors, похожий и тоже тишина, а вокруг бантиков и бус - танцы с бубнами.

[alexus]

Уважаемый Юрий! Мой пост был адресован не вашему простому вопросу, вопросам уважаемого JohniGo.

Собственно как использовать данный механизм в методологическом плане? К чему его применять: ко всем инцидентам или только к проблемам? Кто должен одобрять или отклонять это решение? и к чему относится это одобрение: к заметке (решению) или ко всему тикету?
Кто использует это механизм, поделитесь плиз!

А ваш простой вопрос имеет простой ответ - наберите в SysConfig в строке поиска "decision" и вы получите все связанные с этой фичей настройки. Decion появляется после установки ITSM Core и к Change не относится. Служит для расширения функциональности тикета.
А за мой легкий сарказм прошу извинить. Просто я категорически против "натягивания" "шашечек" на "ехать". Т.е. я против методики:
1. Берем ITIL-совестимое ПО
2. Внедряем его (Внедряй! Поддерживай! Не сс.....ы! http://www.youtube.com/watch?v=-uGdaKFboHo).
3. В результате получили ITIL-процессы
4. Расслабляемся, т.к. у нас теперь "кирпич на педали и куда она(он, они) теперь денутся".

[ykolesnikov]

О.К. В вашей позиции есть, конечно, правильный посыл. Я просто хотел сказать, что изучение продукта тоже способствует возникновению вопросов и побуждаетразбираться и в теории.
Кроме того, JohniGo не замечен в бездумном подходе и я вижу у него желание выстроить процессы не ради них а пользы для, а потому, способ, которым он или я или кто-то другой придет к пониманию пользы для своего дела, не особенно важен. Главное, чтобы дело двигалось.

[JohniGo]

Ух-ты, какие тут баталии развернулись, пока я в тему не заходил..
Коллеги, предлагаю снизить накал страстей. Многоуважаемый alexus никому ничего не должен объяснеть и рассказывать. Мы все тут общаемся и высказываем свои личные мнения.

А по поводу процесса - процес все тот-же (мы же вроди все еще мой топик обсуждаем, не так-ли). Интересует возможность применения данного механизма для фиксации решений инцидентов. Хотел узнать использует ли кто-то данный механизм и если использует - то как.

[alexus]

Ни в коем случае никого не хотел ни в чем обвинять. Это не наш метод . Если кому так показалось, то прошу прощения.
Перечитал еще раз топик сначала. Вопрос стоял в том, как заставить СТП писать решение в тикете. При чем Евгений сразу "сознался" в методическом характере вопроса, с первых слов. Поэтому есть предложение разделить топик на кнопочки и методику по соответствующим разделам.
Теперь про кнопочки. По факту "Решение" есть внутреняя (или внешняя, но это реже) заметка с использованием двух полей - текстового и временнОго, которые автоматом резервируются под Решение после установки модуля ИТСМ. Можно, например, сделать доступным для закрытия только заметку с Решением, а из остальных заметок убрать статус "Закрыт" иже с ним. Это как вариант обязаловки для СТП. Ну а как заставить писать содержательно - это уже вопрос "пряников и волшебных пендалей".

[JohniGo]

Алексей, Вы наверно отличный продавец - всегда отвечаете на другой вопрос..

Можно, например, сделать доступным для закрытия только заметку с Решением, а из остальных заметок убрать статус "Закрыт" иже с ним. Это как вариант обязаловки для СТП. Ну а как заставить писать содержательно - это уже вопрос "пряников и волшебных пендалей".

В принципе - очень неплохой вариант. Надо посмотреть, можно ли это реализовать настройками без кодинга (попахивает ACL мне кажется).
Вопрос то был как раз в других полях, про которые Вы скромно умолчали.
Не совсем понятен смысл временнОго поля. Есть галка для его включения и возможность выбора даты времени. Что сие символизирует? (факт фиксации даты решения? Дату предполагаемого решения? Дату фактического решения?)
Результат решения. Очевидно относится не к конкретной заметке, а к тикету целиком (или я не прав?). Кто его должен заполнять? И в чем смысл данной операции? Контроль правильности решения? Подтверждение, что решение помогло? Или это вообще хвост от управления изменениями, разобрать которые я так и не могу собраться (надоел метод научного тыка), а других вариантов нет.

Предвижу ответ Алексея, что мол если вам эти поля не нужны, так и не используйте...

[ykolesnikov]

Добрый день!
Поискал про Decision Result
Под Decision Result - зарезервировано FreeText16 в SysConfig in Ticket -> Core::TicketFreeText с предустановленными значениями:
Approved - утверждено
Pending - в ожидании
Postponed - отложено
Pre-approved - предварительно одобрено
Rejected - отклонено
Можно использовать для заявок требующих одобрения/рассмотрения, скажем, руководством. Но как выстроить сам процесс одобрения/санкционирования - тоже пока не могу придумать, без подключения ChangeManagement, мне тоже кажется это крючок туда, а въезжать в него - это много времени на опыты, сроки проекта уже подгоняют.
Здесь - или менеджер заявок должен рулить направляя ее сначала руководителю и, затем, после того как он примет решение и поставит Decision Result - отправляет ее на исполнение или закрывает в соответствии с резолюцией.
Какие еще есть мнения, варианты?

[alexus]

Если вы не знаете, зачем Вам эти поля - так не и не трогайте их .
А если серьезно (хотя и в каждой доле шутки только доля шутки)... Здесь под Решением имеется ввиду решение по тикету. Дата отражает время фиксации решения, так за дату предполагаемого решения и фактического восстановления сервиса отвечают соотв. поля Additional ITSM Fields. Однако если дополнительные ITSM поля вы использовать не планируете, то на это поле (дата в решении) можно возложить другой смысл аксиоматически -> "Пусть поле "дата" в решении у нас будет обозначать время "Ч"".
Результат решения к изменениям никакого отношения не имеет, я уже писал об этом чуть выше. Этот функционал вы можете использовать, если вам вдруг по какой-то причине надо будет утверждать решения, например, для создания статей FAQ на основе этих решений.Ну или для "пряников".

Надо посмотреть, можно ли это реализовать настройками без кодинга (попахивает ACL мне кажется).

Edit Config Settings in Ticket -> Frontend::Agent::Ticket::ViewClose (и прочие View*) в параметрах
Ticket::Frontend::AgentTicketClose###StateType
Ticket::Frontend::AgentTicketClose###StateDefault
ставите нужные состояния и все, тикет нельзя закрыть, кроме как через "Решение". А модуль Close можно вообще из менюшки убрать через
Edit Config Settings in Ticket -> Frontend::Agent::Ticket::MenuModule параметр Ticket::Frontend::MenuModule###450-Close

[JohniGo]

Эка мы навалились на Алексея, он даже подробно все разжевал.
Если без шуток, то спасибо Вам, Алексей, за науку.
Не совсем понятно зачем там таки галка, и зачем возможность редактирования даты (для фиксации даже поле-то отображать не надо), но видимо именно для вариативности ияпользования. Одобрение решения инцидента в принципе логично (хоть мне пока и не применимо), надо только поэкспериментировать какими правами оно дается. Не понятно зачем одобрение именно в интерфейсе решения. (редактировать заметки нельзя, а самому себе одобрение ставить бесмыслено). По логике его бы надо отображать в интерфейсе заметки, но опять же не всегда, а только когда есть что одобрять. В общем, как всегда "после сборки обработать напильником", что хоть и логично (исходя из цены), но все-таки не приятно. (однако я теперь вполне хорошо понимаю, кто палитит за написание сложного бесплатного софта)
В общем пока больше склоняюсь к орагнизации справочника типовых решений совместно с пряниками за текстовое описние (другое дело, что эти описания не всегда желательно видеть пользователю, но это уж вы оставим на усмотрение "корпоративной культуры" ). Заставлять писать 2 заметки (решение - внутренню и с собщением клиенту о решении - внешнюю) мне кажется уж чересчур жестоко...

[alexus]

Про кнопки-галочки.
Мне эти фишки тоже не совсем пока понятны с практической точки зрения.
Про напильник.
А вы думаете какой-нибудь HP Service Manager или BMC Remedy не надо напильником? Да там без слесарно-токарного набора вообще делать нечего. Вот там точно понятно, кто за что платит, и платит за все по полной программе.
Про справочник...
Решение клиенту точно не надо отправлять. А перемещать решения надо во внутренний FAQ, т.е. делать статьи на их основе. А клиента уведомлять автоматически по закрытию или ожиданию закрытию.
Про бардак...
Если бардак нельзя предотвратить, то его надо возглавить