Настройка каскада полей (сервис-подсервис-freetext поля))

[Ромео2008]

Доброго времени суток!

Пару недель назад решили развернуть у себя OTRS, компания крупная - решили запустить в качестве HelpDesk для филиала, с перспективой на ServiceDesk для всей компании (если взлетит конечно все). Ситуация примерно такая: настроили группу - очередь - роль для 1-ой линии поддержки, остальные очереди планируются для 2 и 3 линий поддержки (для ИТ и узких специалистов), клиенты берутся по LDAP из AD, агентов пока вручную создаем. Чтобы запустить OTRS в качестве HelpDesk нужно нормально настроить веб-интерфейс для клиентов, на данный момент есть:

То что есть на данный момент

На данный момент.png (34.87 КБ) 21398 просмотров

Поле: Сервис (с прописанными подсервисами, а их около 60шт)
Поле: Тема
Поле: Текст

Само собой пользователю неудобно выбирать из большого кол-ва сервисов-подсервисов конкретный, интересующий именно его, тем более что нужно сделать скидку на то что пользователю как можно скорее нужно сообщить о проблеме, а не сидеть по 10 минут выбирать нужный сервис-подсервис.
Соответственно чтобы запустить HelpDesk и в качестве точки входа для пользователей использовать веб-интерфейс нужна следующая схема:

Как планируется сделать (прошу прощения за транслит и за низкое разрешение)

Как должно быть.png (105.94 КБ) 21398 просмотров

Поле: Сервис (около 12 пунктов)
Поле: Подсервис (данное поле должно зависеть от поля Сервис)
Список полей, зависящих от подсервиса

Например:
Сервис: Телефония
Подсервис: Не проходит регистрация SIP-клиента
(Появляется список полей): Имя компьютера
Место установки компьютера
Учетная запись SIP, под которой невозможно авторизоваться
Наблюдается ли проблема у всех

[Ромео2008]

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

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

[ykolesnikov]

Добрый день!
Идея понятна. С реализацией возможны проблемы. Посмотрите на англоязычном форуме, там было много постов о взаимосвязи полей и вывод их в интерфейсе клиента в зависимости от заполнения предыдущих. Но все это потребует дополнительного кодирования. Это что касается сервисов м подсервисов.
Что касается заполнения необходимых реквизитов, то можно использовать FreeText1 - 16 поля. Там есть множество настроек, почитайте мануал и посмотрите в АдминКонфиге - разберетесь. Их можно делать обязательными и со списками выбора.
Но, только мое мнение - в OTRS сделать очень удобной работу с каталогом сервисов, как в больших покупных системах, нереально.
Заставить и обучить клиента правильно классифицировать заявку очень трудно. Да и велика вероятность, что он просто не сможет это сделать правильно, т.к. отсутствие печати на сетевом принтере, например, может быть как по проблеме с принтером, так и с сетью и с самой рабочей станцией и клиент этого определить не сможет.
Если компания крупная, можно ускорить ввод, заставляя клиента вводить только ключевую информацию, которую он реально способен ввести корректно (например, номер учетной единицы оборудования с которым произошел инцидент. Можно и ввести нумерацию рабочих мест и привязать все оборудование клиента к нему в CMDB) и краткое описание проблемы. Классификацию инцидента\заявки - поручить менеджеру заявок (привязка к сервису)(это можно настроить через изменение дополнительных ITSM полей).
Подчеркиваю, это мое мнение, необязательно правильное.

[alexus]

Отчасти согласен с Юрием в плане ускорения. А вот с этим не соглашусь категорически.

Но, только мое мнение - в OTRS сделать очень удобной работу с каталогом сервисов, как в больших покупных системах, нереально.

Даже если в большой покупной софт внедрить такой (как на скриншоте) каталог сервисов, то пользователи вас не поймут, а их руководители дадут понять, что людям работать надо, а не ерундой заниматься.
А все почему? Да потому что такой каталог сервисов - это неправильно. Хотел написать чуть резче, но не стал, ибо вдруг уважаемый ТС не читал еще про ITIL&ITSM. С точки зрения OTRS и ITIL сервис - это конечная услуга, которую ИТ предоставляет Заказчику (внутренние или внешние пользователи.) Для наглядности примеры сервисов - 1С, эл. почта, доступ в Интернет, сетевая печать, сканирование, система документоборота и т.п. Из этого следует, что

Сервис: Телефония

это "правильный сервис", а

Подсервис: Не проходит регистрация SIP-клиента и "Не приходит статистика"

это никакой не сервис вообще!
Хочу заметить, что построение каталога услуг (или сервисов, что суть одно и тоже), есть одна из самых сложных задач на этапе внедрения практик ITIL.
Для того, чтобы OTRS и прочие подобные системы, основанные на сервисном подходе ITSM дали ощутимую отдачу, надо некоторое время посвятить изучению методологии и составить для себя четкое понимание о предмете. Кто дочитал, тому коньяк. А не "натягивать" втупую на софт какую-либо деятельность, а потом говорить, что софт плохой и ничего не умеет. Софт это всего лишь инструмент, который ПОМОГАЕТ АВТОМАТИЗИРОВАТЬ вашу текущую деятельность. Первично все-таки процессы и люди, а затем уже средства автоматизации.

[alexus]

Теперь про клиентский интерфейс. Рекомендую для начала вообще оставить только поля "Тема" и "Текст" и все! Пусть пишут своими словами.

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

Да не будет никто заморачиваться вообще! Человек так устроен, что идет по пути наименьшего сопротивления, во-первых. А во-вторых, соглашусь с Юрием, когда юзер начинает диагностировать проблему вместо того, чтобы просто сообщить о факте, он скорее всего напишет полную ерунду, за которой и смысл инцидента потеряется.
Не надо юзерам всего и сразу, ну не надо! Надо делать их жизнь удобнее и "регламентированнее" постепенно! И вообще каталог сервисов желательно согласовывать с руководством компании и отдельных подразделений. И не всем ведь нужен сервис 1С или PALO, так что можно конкретные сервисы назначить конкретным пользователям, чем уже сократить список доступных услуг.
В общем во избежание разочарований, рекомендую начинать не с установки OTRS, а сесть и подумать "Где мы сейчас? И куда хотим прийти?"
Всегда готов поддержать конструктивную беседу.

[yuri0001]

Согласен с Алексеем полностью. Сначала надо решить как мост строить вдоль/поперёк или наискосок, но лучше по проекту, по науке.
А клиента надо любить и лелеять и выращивать как английский газон - ухаживать каждый день.

[Ромео2008]

Уважаемые господа, наверняка мы друг друга превратно поняли - давайте немного резюмируем для того чтобы убрать некие непонимания:

1) OTRS мы на сегодняшний день хотим использовать в качестве HelpDesk

решили запустить в качестве HelpDesk для филиала

- а никак не ServiceDesk, поэтому начинать тут же внедрять сервисы строго по библии ITIL невозможно, да и не нужно на самом деле (в будущем возможно) => следовательно фразы

это "правильный сервис

или

это никакой не сервис вообще!

и уж тем более

Хотел написать чуть резче, но не стал, ибо вдруг уважаемый ТС не читал еще про ITIL&ITSM

- не совсем актуальны, ITSM имел честь прочитать (это конечно не вся библиотека ITIL но все же), также хотел сделать комментарий по поводу

Хотел написать чуть резче

- Уважаемый, резче не нужно, данный форум предназначен (насколько я понимаю конечно) для конструктивного обсуждения а не для ругани и громких дебатов - будем же вежливы друг к другу

2) Далее, как вы,вероятно, догадываетесь - у пользователей до OTRS был HelpDesk с определенной функциональностью (разумно полагать, что ИТшники не бумажками заявки принимают) - соответственно функционал нового HelpDesk (пока HelpDesk - в будущем возможно ServiceDesk по ITIL) должен быть не хуже предыдущего + должен быть не менее удобным как для ИТ так и для пользователей. В предыдущем система каскадных полей реализована и прекрасно работает, проблема что в нем даже гипотетически не сделать ServiceDesk и проблематично его использовать в качестве единого HelpDesk для всей компании => фразы

Заставить и обучить клиента правильно классифицировать заявку очень трудно. Да и велика вероятность, что он просто не сможет это сделать правильно

,

то пользователи вас не поймут

или

Да не будет никто заморачиваться вообще!

- опять же неактуальны.

[Ромео2008]

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

3) Тема называется "Настройка каскада полей (сервис-подсервис-freetext поля))" а не "Ребята - помогите пожалуйста что-нибудь внедрить желательно по ITIL" - поэтому хочу поблагодарить за хоть какое-то дельное предложение "по теме" -

Если компания крупная, можно ускорить ввод, заставляя клиента вводить только ключевую информацию, которую он реально способен ввести корректно (например, номер учетной единицы оборудования с которым произошел инцидент. Можно и ввести нумерацию рабочих мест и привязать все оборудование клиента к нему в CMDB) и краткое описание проблемы. Классификацию инцидента\заявки - поручить менеджеру заявок (привязка к сервису)(это можно настроить через изменение дополнительных ITSM полей).
Подчеркиваю, это мое мнение, необязательно правильное.

Все остальное по большей части - ненужная информация в духе "иди читай книжки по ITIL" и "Нужно посидеть и подумать прежде чем делать"
CMDB - действительно пытаемся ввести даже в рамках HelpDesk - удобная штука.

4) Насчет

И не всем ведь нужен сервис 1С или PALO, так что можно конкретные сервисы назначить конкретным пользователям

- вы, вероятно, заметили что в OTRS сервисы привязываются к конкретным пользователям, а не к группам (если кто знает другой вариант - буду рад узнать) - поэтому руками нескольким сотням человек привязывать конкретные сервисы мягко говоря неудобно.

P.S. Не хотел никого обидеть, но давайте вернемся к конструктивному общению "как можно сделать" а не "рассуждения по поводу квалификации моей лично и наших специалистов в целом"

[arvas]

Вообщем то я согласен отчасти с мнением общественности.
1. Телефония – сервис, «не работает sip переадресация» - не сервис.
2. Внедрять helpdesk на системе предназначенной для sevicedesk и говорить о том, что идеология ITSM не устраивает тебя – в корне неверно
И согласен с мнением Ромео2008, что выбор проблемы из ниспадающего меню – это нужно, т.к. вариант "тема + суть" работает для пары десятков или даже сотни пользователей, но никак не работает для тысяч. Чтобы сортировать такой поток требуется весьма большой ресурс.
Не страшно, если пользователь ошибется в выборе сервиса или типа ошибки. Процент ошибки будет не более 10-20 при правильном составлении списков, зато 80-90% будет изначально правильно классифицированно и эскалировано, что избавит техподдержку от рутиной работы по сортировке.
В случае Ромео2008 верным было бы составить список сервисов как-нть типа:

Телефония:
*Переадресация
*Софт-Phone
*Стационарный телефон
ARM:
*WEB-Arm
*Толстый клиент ARM
*Отчеты из ARM

А дополнительными полями (не относящимися к сервису, но привязанными к нему) уже описывать проблему:
Ошибка (Free text с возможность выбора варианта??):
*неработает авторизация
*Ошибка #1212423
*Ошибка #98787
Объект (CMDB):
*Компьютер comp1
*Компьютер comp2
База (CMDB):
*База кирова
*База Новосибирска

Типа того.

Вопросы:
1. как сделать freetext поля ниспадающим списком (возможность выбора, а не ввода)
2. как вышеупомянутый список связать с сервисом? (поле и варианты выбора должно зависеть от выбранного сервиса)
3. как привязать CMDB к сервису?

[ykolesnikov]

Добрый день!
Понизим градус обсуждения.
Не надо упрекать Алексея, за его стремление вывести нас на методически правильную основу, а только поблагодарить. Прочитать по ITIL/ITSM и следовать этим стандартам/рекомендациям - две большие разницы. Сразу кастомизировать не есть хорошо и усугублять ошибки ранее сделанные в предыдущих системах тоже. Переход к новой системе - как раз повод остановиться и решить куда идти!

1. как сделать freetext поля ниспадающим списком (возможность выбора, а не ввода)

Примеры этого практически есть в АдминКонфиге.

Core__TicketFreeText.png (18.45 КБ) 21364 просмотра

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

2. как вышеупомянутый список связать с сервисом? (поле и варианты выбора должно зависеть от выбранного сервиса)

В лоб способов нет. Видел похожее на буржуйском (англ.) форуме. Поищите. Там именно о связи FreeText полей с сервисами. Поскольку я, все-таки сомневаюсь, что это необходимо, потму внимательно не смотрел и не сохранял ссылки.
По третьему вопросу ответ такой же, что и по второму.
В заключение. Для крупной компании логичнее на сегодняшний день не заниматься кастомизацией такого продукта самим, а заказать это партнерам OTRS, либо купить готовый продукт с сопровождением. Иначе, мне это напоминает ИТ 80-х - всё самописное и гвардия сопровожденцев. Это тупик, поверьте старому ИТэшнику из тех лет. Сейчас программеры очень мобильны и надежда сохранить команду разработчиков/сопровожденцев невелика. Оценивайте риски собственной разработки/кастомизации. Удачи!

[Ромео2008]

Доброго времени суток!

Не надо упрекать Алексея, за его стремление вывести нас на методически правильную основу, а только поблагодарить

- благодарю..от всего сердца

Удачи!

- Спасибо, она нам пригодится - будем искать дальше.

Для ищущих в том же направлении:

1) Ссылка на буржуйский форум (правда он касается OTRS 2.4 вроде) http://doc.otrs.org/developer/2.4/en/html/c410.html - смотреть нужно "7.1.2. Output Filter" - как раз оно, как реализовать - пока не разобрался
2) Тех.поддержка OTRS предлагает модуль Multi-Level Service Selection Add-On доступен в подписке которая стоит $4,995 в год - это, насколько я понял, взаимосвязь сервисов с подсервисами, про free-text поля ни слова, но возможно поддерживает

[alexus]

Уважаемый Александр!
У меня не было цели обсуждать чью либо квалификацию, и тем более доводить это до ругани. Это действительно тут не принято. Но дебаты вполне себе случаются.
Для успешного внедрения OTRS важно правильно понимание основ ITSM (и ITIL - Библия его ). К сожалению на форуме да и в жизни приходится сталкиваться с тем, что часто берут систему используют ее некорректно как с точки зрения настроек, так и с точки зрения логики работы системы. А потом говорят, что весь open-source - это очень плохо, а Microsoft и BMC Remedy - это хорошо.
Я вижу определенные ошибки на стадии планирования системы в вашем случае. Может я где-то и сказал все-таки резковато, но, поверьте, без злого умысла. За идею обидно!
Для меня ITIL - это всего лишь набор советов, как сделать лучше, и мне кажется, что внедрять сервисы строго по ITIL не всегда имеет смысл. Но все-таки есть определенные правила.
Я просто советую Вам подумать еще раз на каталогом сервисов, а не призываю внедрять по ITIL. И то, что у Вас HelpDesk, а не ServiceDesk, сути не меняет.
В целом, ведь речь идет о том, чтобы облегчить пользователю диагностику инцидента? А нужно это для ускорения работы ИТ? Если основная задача такова, то и надо думать, как ее решить, а не чтобы сделать интерактивный выбор полей. См. далее продолжение.....

[alexus]

Тут есть два пути. На мой взгляд они таковы:

1. Сервис-подсервис заносятся в "Сервисы". Назначаются все-таки конкретным юзерам. Сколько у вас сервисов-подсервисов и сколько юзеров? В любом случае за 1-2 дня максимум (если юзеров даже несколько сотен) можно все сделать. Далее во FreeText поля заносятся варианты симптомов инцидентов. Далее с помощью JavaScript (пример тут http://forums.otrs.org/viewtopic.php?f=60&t=8032) настраиваются возможные варианты выбора. Но это все уже получается достаточно серьезный кастом, как вы понимаете.

2. Я рекомендую этот вариант. Используйте модуль FAQ, который доступен юзерам в их web-интерфейсе. Туда можно поместить базу знаний как по решению типовых ситуаций, так и с описанием кодов ошибок и т.п. Их ведь все равно надо разрабатывать и вносить в систему. И потом пусть номер статьи FAQ вставляет в тело сообщения или ссылку. Это поможет при наличии развитого FAQ существенно снизить кол-во обращений в ИТ-службу вообще. И юзер будет рад, что такой умный - сам все решил. И это без кастома вообще. Т.е. меньше проблем с дальнейшей поддержкой.

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

[alexus]

Если уж без каскада никак, то варианта 2:
1. http://www.otrs.com/en/solutions/subscr ... criptions/ - доступно в рамках платной подписки. Можно купить через нас.
2. Самому на JavaScript написать.

[Artjoms]

Romeo, Благодарю Вас за мотивацию к работе над этим проектом. платить 5000 $ за эту небольшую функциональность кажется бездумно. решил реализовать ее на нашем тестовом сервере, so please watch the result:
Переделал этот блок, добавив пару функций чтобы в зависимости от типа Ticket'a менялись сервисы. (всё равно ACL не работает с сервисами), но переделать код под ваши нужды - дело одной бессонной ночи
(//Don't hold the cat in the bag - share your code )

File: CustomerTicketMessage.dtl

Change:

Код: Выделить всё

<label for="TypeID" class="Mandatory"><span class="Marker">*</span>$Text{"Type"}:</label>
					$Data{"TypeStrg"}
					<span id="definition1" class="TooltipErrorMessage"><p> $Text{"A formal proposal for a Change to be made"}</p></span>
					<span id="definition2" class="TooltipErrorMessage"><p> $Text{"An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services and Customer productivity."}</p></span>
                    <div id="TypeIDError" class="TooltipErrorMessage" ><p>$Text{"This field is required."}</p></div>
                    <div id="TypeIDServerError" class="TooltipErrorMessage NoJavaScriptMessage$QData{"TypeIDInvalid"}" ><p>$Text{"This field is required."}</p></div>
                    <div class="Clear"></div>
                </div>
<!--dtl:js_on_document_complete-->
<script type="text/javascript">//<![CDATA[
/*Added by Artjoms on 06.09.2011 to achieve Multi-Level Service Selection add-on functionality */
switch ($('#TypeID :selected').text() ) { //Checks the value of type input field
    case  "Request for Change": // for RfC shows that description
      document.getElementById('definition1').style.display = 'block';
	  document.getElementById("definition2").style.display = 'none';
    /* this is the ID of our drop down */
var dl = document.getElementById('ServiceID')


/*hide values */
hidevals('');
hidevals('Employee Dismissal');
	
	break;
	case "Incident":
	  document.getElementById("definition1").style.display = 'none';
	  document.getElementById('definition2').style.display = 'block';
	  
	  /* this is the ID of our drop down */
var dl = document.getElementById('ServiceID')


/*hide values */
hidevals('Employee Dismissal');

function hidevals(identtext) {
for (i=0;i<dl.length;i++)
if (dl.options[i].text == identtext){
	document.getElementById("ServiceID").options[i] = null;
}
}
	  
	break;
    default:
      document.getElementById("definition1").style.display = 'none';
	  document.getElementById("definition2").style.display = 'none';
    }
    $('#TypeID').bind('change', function (Event) {
        // make sure the ticket is not yet created on queue change
        $('input#Expand').val(1);
        Core.Form.Validate.DisableValidation($(this).closest('form'));
        $(this).closest('form').submit();
    });
//]]></script>
<!--dtl:js_on_document_complete-->
<!-- dtl:block:TicketType -->

[alexus]

Я согласен, что только за это платить 5000 у.е. Но если посчитать все "добавки" Feature Add-Ons, то как раз и выйдет стоимость, в которую выльется JavaScript-кодинг. А там еще и поддержка. Тем не менее Ваш код после тестов можно добавить в раздел HowTo.

[Artjoms]

Наверное Вы правы, но многим не нужен полный комплект этих функций.
Кстати, появилась идея создать динамичные списки сервисов, чтобы не приходилось исправлять сервисы в коде. Кто-нибудь знает для чего используется поле Service::Type (Тип сервиса)? Может в нём можно хранить связку с типом не сервиса, а тикета? Как к таким фривольностям относится ITIL? Я не очень хорошо ориентируюсь м в ITIL'e но потихоньку читаю, так что Ваши советы и замечания будут полезны.

[alexus]

В каждом случае надо смотреть индивидуально, согласен.

Может в нём можно хранить связку с типом не сервиса, а тикета?

Не понял. Что Вы имеете ввиду?

[Artjoms]

Comparing ticket types and service types

Ticket_service_type.JPG (49.25 КБ) 21002 просмотра

Я имел в виду - где используется Service->Type и можно ли в нём хранить тип ticket'a к которому он относится? Идея - сравнивать выбранный тип ticketa с хранимым, и если они совпадают, то отобразить service в dropdown'e

[alexus]

Это разные типы. Их нельзя скрещивать.

[Ромео2008]

Доброго времени суток,

Romeo, Благодарю Вас за мотивацию к работе над этим проектом

Напротив, это я вас благодарю за участие
Особенно за

переделать код под ваши нужды - дело одной бессонной ночи

Протестируем - отпишемся что получилось , но,вероятно,кодинга и консалтинга все равно не избежать насчет платной подписки - тут я воздержусь от комментариев

В любом случае я хочу сказать "спасибо" господину Artjoms и уверен что доработка окажется ценной!