alexx2xx ivanov пишет:
И самое интересное старая база, которая была до создания новой( на другом инстансе) - работала и работает сейчас нормально, без проблем.
На старой базе которая работает какой стоит SP? Следуя из документации:
From SP18, Service Desk starts to support Java Runtime Environment (JRE) 1.4.2 and Java Development Kit (JDK) 1.4.2.
Sun has announced end of life (EOL) for JRE/JDK 1.3.1, therefore Service Desk 4.5 will only support JRE/JDK 1.4.2 starting with Service Pack 19. With this Service Pack version JRE/JDK 1.3.1 will no longer be supported. JRE/JDK 1.3.1 will still be supported for earlier Service Pack versions.
Important: For support Oracle 10G R2 (10.2), you MUST use ojdbc14.jar in <service pack extraction directory>\doc\ITSM007871, detailed information please refer to ITSM007871.
Как показал мой опыт с пользователями, чем больше полей для заполнения, тем больше у них вопросов и больше начинают звонить по телефону, чем пользоваться какими либо формами! Пользователь всегда хочет все быстро, просто и удобно... Чем больше будет список категорий, тем больше будет вероятность, что данная проблема будет не связана с реальной проблемой, порой пользователь от балды выставляет категорию (если проблема с почтой, то категорию он может выбрать сеть). На мой взгляд категории с подкатегориями делать не очень удобно для пользователя, получается как анкетирование, а зачастую это раздражает, когда много вопросов, чтобы подать свою проблему надо будет примерно 5 минут потратить, что очень много я считаю и еще более корректно и правильно заполнить все поля, а не как я хочу...
В день 5000 т. Обращений. Более 30 сотрудников первой линии.
Видел такие объемы на предыдущей своей работе (в одной известной нефтяной компании), но работал с системой на второй линии. Сейчас развиваю первую линию.
Цитата
Смотря, что именно Вы хотите оптимизировать, тут вопрос довольно не простой.
Мне нужен итог - мгновенная маршрутизация заявки на вторую линию. А вот что можно оптимизировать для этого....вопрос...
Столкнулся с тем, что заявки нарастают из месяца в месяц, постоянно появляется временной лаг маршрутизации заявок на вторую линию и этот лаг нарастает. сначала 1,5 часа, и до 1 суток. Когда ситуация становится критичной, единственный выход - искать еще сотрудника. Вот и возникают вопросы - а как можно оптимизировать работу первой линии? Например у меня сейчас есть несколько групп заявок, один человек предварительно маршрутизирует заявки в эти группы. На каждой группе есть ответственные, которые в приоритете обрабатывают именно ее. Думаю - а оптимально ли это? Может быть всех на разбор общей кучи и все должны быть универсальны? Какой у вас подход?
Потом еще вопрос - из-за того, что у нас есть предварительная маршрутизация, получается, что в качестве ответственного за заявку на первой линии подтягивается специалист, который сидит на этой самой маршрутизации. Не могу построить достоверную статистику обработки заявок. Может SQL запросом в меня кинетесь или порекомендуете что?
Портала пока нет, понимаем, что это необходимость и часть нагрузки он снимет. Но пока нет ресурсов для его реализации. Кстати, а на чем реализовали портал? В моем опыте была реализация на шаре поинте.
Цитата
настроены специальные формы для удобства пользователей
Что за хитрые формы? Просто шаблоны писем или как то сложнее?
шаблоны писем с определенными назначениями и полями, чтобы можно было сразу же автоматом назначать то или иное обращение на группу....
Да уж, я тут прочитал выше написанное и увидел цифры, мне прям смешно стало, я вообще тогда отдыхаю.... У нас в компании около 5,5 тыс. людей работает, Service Desk развит только внутри компании и больше никуда, в день обращений выходит около 130 шт.... Работает у нас только первая и последняя линия в составе 3 человек. Большая часть обращения (70%) поступает через эл.почту, настроены специальные формы для удобства пользователей, немного времени понадобилось, чтобы приучить их ими пользоваться и они как по маслу штопают обращения... Сейчас оптимизируем Service Page, чтобы можно было распределить подачу обращений (в случае не работы почты или сбоя тех самых форм у пользователя), ну тем самым меньше звонил телефон... НУ как то так получается...
как то у вас маловато обращений для 5,5 тыс человек. Или у вас часть задач уходит "налево", то есть разработчикам и прочим?
ну по существу имеют около 5 тыс. свой е-майл. Обращаются пользователи только со своих филиалов которые внутри компании находятся и свои же спецы по рабочим группам которые распределены обрабатывают данные обращения, левых у нас нету вообще! У нас узкий круг получается, не то что у вас...
Да уж, я тут прочитал выше написанное и увидел цифры, мне прям смешно стало, я вообще тогда отдыхаю.... У нас в компании около 5,5 тыс. людей работает, Service Desk развит только внутри компании и больше никуда, в день обращений выходит около 130 шт.... Работает у нас только первая и последняя линия в составе 3 человек. Большая часть обращения (70%) поступает через эл.почту, настроены специальные формы для удобства пользователей, немного времени понадобилось, чтобы приучить их ими пользоваться и они как по маслу штопают обращения... Сейчас оптимизируем Service Page, чтобы можно было распределить подачу обращений (в случае не работы почты или сбоя тех самых форм у пользователя), ну тем самым меньше звонил телефон... НУ как то так получается...
Елена Петрова пишет:
Я сделала так: там где элемент указала "Запросы на обслуживание", а там где "Объект к" сделала ссылку на созданный ранее справочник, который открывается обычным списком, а не быстрым поиском. В результате получила то же самое поле, которое не открывается бытрым поиском, а также как и ранее созданное, просто, как список.
Вам сначала надо создать код и указать Тип, а в вашем случае и будет иерархический