» Adventnet ManageEngine ServiceDesk Plus
это отправленные письма от системы или от техника - отвечать вы себе будете?
Цитата:
это отправленные письма от системы или от техника - отвечать вы себе будете?
Ситуация следующая. Техник Иванов создал заявку и направил ее в свой отдел.
Техник Петров ему ответил. Техник Иванов открывает переписку "Обсуждения с инициатором заявки" и видит ответ от техника Иванова, где вместо кнопки"Ответить" видна только кнопка "Переслать".
А должно быть и "Ответить" и "Переслать".
Как быть??
Коллеги, кто еще сталкивался с такой проблемой.... и в каком билде SDP8... ее устранили?? Проблема имеет место быть только при переписке техников.
установил SDP8.0.7 все осталось по прежнему. Делаю вывод что это не баг, а фича))
Отвечайте на заявку кнопкой "Ответить" для самого запроса (заявки)
Цитата:
Отвечайте на заявку кнопкой "Ответить" для самого запроса (заявки)
так и делаю
Коллеги, подскажите. Ни Гугл, ни ФАК не помог.
Наша Организационная структура - лес доменов. Основной и подчиненные.
Если использовать AD аутентификацию то пользователи импортируются из одного домена. (Ну или для каждого можно провести эту операцию). Но ведь, в дальнейшем, при синхронизации SDP будет синхронизировать только последний настроенный для импорта домен? Или все с которыми его подружили?
А если же использовать LDAP то не будет уже синхронизации
Есть ли выход? Чтоб SDP синхронизировал AD-ных пользователей в нескольких доменах?
Наша Организационная структура - лес доменов. Основной и подчиненные.
Если использовать AD аутентификацию то пользователи импортируются из одного домена. (Ну или для каждого можно провести эту операцию). Но ведь, в дальнейшем, при синхронизации SDP будет синхронизировать только последний настроенный для импорта домен? Или все с которыми его подружили?
А если же использовать LDAP то не будет уже синхронизации
Есть ли выход? Чтоб SDP синхронизировал AD-ных пользователей в нескольких доменах?
Установил с нуля SDP8, немного поработал и столкнулся со следующей проблемой!
При попытки сделать заявку самим пользователем через вкладку "Новая заявка", заявка не записывается в базу!!!! (до этого, пару дней работало)
Заявка созданная специалистом от пользователя, успешно записывается в базу.
Если пользователь создает заявку через шаблон или "каталог служб" все работает.
В журнале осталась запись:
Коллеги, что может быть? Думаю что проблема связана с разделением доступа...
При попытки сделать заявку самим пользователем через вкладку "Новая заявка", заявка не записывается в базу!!!! (до этого, пару дней работало)
Заявка созданная специалистом от пользователя, успешно записывается в базу.
Если пользователь создает заявку через шаблон или "каталог служб" все работает.
В журнале осталась запись:
Коллеги, что может быть? Думаю что проблема связана с разделением доступа...
Коллеги, при попытке отправить какое либо письмо внутри организации - все ок
При попытке отправить это же письмо, скажем на gmail - SDP выдает сообщение "Не удалось отправить уведомление."
в логах "Exception while trying to send notification for Request ID : 57178 Mail sending failed."
кто знает в чем проблема?
При попытке отправить это же письмо, скажем на gmail - SDP выдает сообщение "Не удалось отправить уведомление."
в логах "Exception while trying to send notification for Request ID : 57178 Mail sending failed."
кто знает в чем проблема?
SVRRR
Открою тебе еще более страшную тайну, ты путаешь Каталог услуг с категорией инцидентов )))))
И я работаю на 8 версии уже третий месяц, вот там и начались проблемы со сквозной авторизацией она не хрена не работает, и галочка "запомнить меня тож не хрена не работаетю и там есть нормальный готовый КАТАЛОГ УСЛУГ. Наконец то, на базе него и можно создавать заявки на облуживание, а то что сделал ты используется для ИНЦИДЕНТОВ созданных или по запросам пользователей или автоматическими системами. Это РАЗНЫЕ ВЕЩИ! правда чтобы это понимать нужно хотя бы один СЕРВИСДЕСК поднять в своей жизни, не программный в смысле, а реальную службу. так что ставь 8 версию и наслаждайся ))))
Открою тебе еще более страшную тайну, ты путаешь Каталог услуг с категорией инцидентов )))))
И я работаю на 8 версии уже третий месяц, вот там и начались проблемы со сквозной авторизацией она не хрена не работает, и галочка "запомнить меня тож не хрена не работаетю и там есть нормальный готовый КАТАЛОГ УСЛУГ. Наконец то, на базе него и можно создавать заявки на облуживание, а то что сделал ты используется для ИНЦИДЕНТОВ созданных или по запросам пользователей или автоматическими системами. Это РАЗНЫЕ ВЕЩИ! правда чтобы это понимать нужно хотя бы один СЕРВИСДЕСК поднять в своей жизни, не программный в смысле, а реальную службу. так что ставь 8 версию и наслаждайся ))))
dencomua
Скорее всего у тебя нет внешней почты на адресе с которого SDP собирает и отправляет почту. ТОбишь адрес выглядит так SDP@домен.lan. Надо добавить внешку для отправки
Добавлено:
Ребята! Кто пользуется сайтами? Помогите настроить! Я никак не могу их победить. У меня есть несколько филиалов со своими специалистами. Мне надо, чтобы они видели только заявки своих филиалов (что достигается посредством сайтов) - вроде бы все логично и понятно. Так вот если спец видит только заявки своего сайта - то при назначении заявки своего сайта на спеца, который видит все сайты, - у него пропадает доступ к этой заявке. why???)
Скорее всего у тебя нет внешней почты на адресе с которого SDP собирает и отправляет почту. ТОбишь адрес выглядит так SDP@домен.lan. Надо добавить внешку для отправки
Добавлено:
Ребята! Кто пользуется сайтами? Помогите настроить! Я никак не могу их победить. У меня есть несколько филиалов со своими специалистами. Мне надо, чтобы они видели только заявки своих филиалов (что достигается посредством сайтов) - вроде бы все логично и понятно. Так вот если спец видит только заявки своего сайта - то при назначении заявки своего сайта на спеца, который видит все сайты, - у него пропадает доступ к этой заявке. why???)
2 shamsa
Цитата:
1. для тугослышащих повторяю еще раз:
Цитата:
Цитата:
печально
Цитата:
а у меня работает
Цитата:
Его все равно надо переделавать под специфику своей организации
Цитата:
конечно
Цитата:
см. п.1
На данный момент перевел все подразделения предприятия, организовав единую точку контакта.
Цитата:
уже перешел на нее))
Цитата:
Открою тебе еще более страшную тайну, ты путаешь Каталог услуг с категорией инцидентов )))))
1. для тугослышащих повторяю еще раз:
Цитата:
"лично я, каталог услуг организовал в разделе - Категории/подкатегория/позиция
версия SDP 7.6.0"
Цитата:
И я работаю на 8 версии уже третий месяц, вот там и начались проблемы со сквозной авторизацией она не хрена не работает,
печально
Цитата:
и галочка "запомнить меня тож не хрена не работаетю
а у меня работает
Цитата:
и там есть нормальный готовый КАТАЛОГ УСЛУГ.
Его все равно надо переделавать под специфику своей организации
Цитата:
Наконец то, на базе него и можно создавать заявки на облуживание,
конечно
Цитата:
а то что сделал ты используется для ИНЦИДЕНТОВ созданных или по запросам пользователей или автоматическими системами. Это РАЗНЫЕ ВЕЩИ! правда чтобы это понимать нужно хотя бы один СЕРВИСДЕСК поднять в своей жизни, не программный в смысле, а реальную службу.
см. п.1
На данный момент перевел все подразделения предприятия, организовав единую точку контакта.
Цитата:
так что ставь 8 версию и наслаждайся ))))
уже перешел на нее))
[b]vrednyi[
Гы, там должна быть включена херня, типа видеть только свой сайт и заявки не для одного сайта. Вот и все
Гы, там должна быть включена херня, типа видеть только свой сайт и заявки не для одного сайта. Вот и все
Коллеги, бьюсь с SSO - версия 8.0.0.7 - не сохраняет настройки в базу jespaconfiguration; - дошел до того. что руками вбил туда через mysql данные, но всё равно на контроллере домена не авторизуется (говорит jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password). на контроллер домена передаётсмя след инфа - потом в логе безовасности видно
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: SDPCOMP$
Account Domain: domain.RU
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: JCIFSX_X_8F
Source Network Address: x.x.x.x
Source Port: 57436
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Может кто-нть показать с рабоатющей системы, какие поля заполнены в таблице?
в ком строке
C:\ManageEngine\ServiceDesk\mysql\bin>mysql -u root -P 33366 servicedesk
и уже скуль-строчку
select * from jespaconfiguration;
Буду очень благодарен, бьюсь уже два дня, пробовал и на 2003, и на 2008R2 - не хочет работать
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: SDPCOMP$
Account Domain: domain.RU
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: JCIFSX_X_8F
Source Network Address: x.x.x.x
Source Port: 57436
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Может кто-нть показать с рабоатющей системы, какие поля заполнены в таблице?
в ком строке
C:\ManageEngine\ServiceDesk\mysql\bin>mysql -u root -P 33366 servicedesk
и уже скуль-строчку
select * from jespaconfiguration;
Буду очень благодарен, бьюсь уже два дня, пробовал и на 2003, и на 2008R2 - не хочет работать
+---------------+-----------------------------+
| JESPACONFIGID | JESPACONFIG_KEY |
+---------------+-----------------------------+
| 301 | jespa.bindstr |
| 302 | jespa.service.acctname |
| 303 | jespa.service.password |
| 304 | jespa.dns.servers |
| 305 | jespa.account.canonicalForm |
| 306 | jespa.log.level |
| 307 | jespa.domainname |
| 308 | jespa.fallback.location |
+---------------+-----------------------------+
| JESPACONFIGID | JESPACONFIG_KEY |
+---------------+-----------------------------+
| 301 | jespa.bindstr |
| 302 | jespa.service.acctname |
| 303 | jespa.service.password |
| 304 | jespa.dns.servers |
| 305 | jespa.account.canonicalForm |
| 306 | jespa.log.level |
| 307 | jespa.domainname |
| 308 | jespa.fallback.location |
+---------------+-----------------------------+
kmtrx
Спасибо! а вас третий столбик JESPACONFIG_VALUE - присутствует - вы скрыли его т.к. там приватные данные - или его нету??
у меня три столбика
+---------------+-----------------------------+-------------------------------+
| JESPACONFIGID | JESPACONFIG_KEY | JESPACONFIG_VALUE |
+---------------+-----------------------------+-------------------------------+
| 3301 | jespa.bindstr | azimut.ent |
и т.п.
если всё-таки у вас три столбца, интересует в каком виде и регистре заданы значения для
jespa.service.acctname - к примеру так - TESTCOMP$@AZIMUT.ENT |
значение jespa.account.canonicalForm - у меня 3 и 4 пробовал, не работают
Спасибо! а вас третий столбик JESPACONFIG_VALUE - присутствует - вы скрыли его т.к. там приватные данные - или его нету??
у меня три столбика
+---------------+-----------------------------+-------------------------------+
| JESPACONFIGID | JESPACONFIG_KEY | JESPACONFIG_VALUE |
+---------------+-----------------------------+-------------------------------+
| 3301 | jespa.bindstr | azimut.ent |
и т.п.
если всё-таки у вас три столбца, интересует в каком виде и регистре заданы значения для
jespa.service.acctname - к примеру так - TESTCOMP$@AZIMUT.ENT |
значение jespa.account.canonicalForm - у меня 3 и 4 пробовал, не работают
НУ так что, никто не может разобраться почему не проходит сквозная авторизация?
Добавлено:
SVRRR
Я уже писал выше. Не надо путать инцидент с запросом на обслуживание
Новая заявка в SDP подразумевает новый инцидент. новое нарушение в работе сервисом. Проблема просто в том, что перевод неправильный. вот вы все и путаетесь, потому что нужно учить теорию. Я уже про это писал
Добавлено:
SVRRR
Я уже писал выше. Не надо путать инцидент с запросом на обслуживание
Новая заявка в SDP подразумевает новый инцидент. новое нарушение в работе сервисом. Проблема просто в том, что перевод неправильный. вот вы все и путаетесь, потому что нужно учить теорию. Я уже про это писал
jespa.account.canonicalForm | 3
jespa.log.level | 3
Цитата:
jespa.fallback.location | HomePage.do
jespa.log.level | 3
Цитата:
jespa.service.acctname- похоже имя$@домен
jespa.fallback.location | HomePage.do
2 shamsa
Цитата:
Shamsa, сейчас пользователю по мимо стандартного шаблона "Новая заявка" к которому он уже привык, предлагается пользоваться еще одним шаблоном "Каталогом служб". Объясните мне, зачем ему два девайса?? У него возникла -ПРОБЛЕМА. "Инцидент" это, или "запрос на обслуживание", ему это фиолетово, да и слов он таких заморских не знает)))
Вы попытайтесь взглянуть на эту проблему глазами пользователя. Для него должна быть Единая форма заявки c перечнем всех ИТ-сервисов. И все. А если нет единых понятий, то возникают разночтения...СТП не понимает пользователя, и наоборот. Двадцать лет назад никто про ITIL не знал, но ведь работали...Были обыкновенные диспетчера, которые принимали заявки и эскалировали их дальше... А сегодня это называется 1-ая линия. Ничего по сути не изменилось..
ALL
Добавлено:
Коллеги, повторю свой очередной вопрос.
В сведениях о заявке, есть параметр "Срок ответа":
Для чего он нужен?
Цитата:
Я уже писал выше. Не надо путать инцидент с запросом на обслуживание
Новая заявка в SDP подразумевает новый инцидент. новое нарушение в работе сервисом. Проблема просто в том, что перевод неправильный. вот вы все и путаетесь, потому что нужно учить теорию. Я уже про это писал
Shamsa, сейчас пользователю по мимо стандартного шаблона "Новая заявка" к которому он уже привык, предлагается пользоваться еще одним шаблоном "Каталогом служб". Объясните мне, зачем ему два девайса?? У него возникла -ПРОБЛЕМА. "Инцидент" это, или "запрос на обслуживание", ему это фиолетово, да и слов он таких заморских не знает)))
Вы попытайтесь взглянуть на эту проблему глазами пользователя. Для него должна быть Единая форма заявки c перечнем всех ИТ-сервисов. И все. А если нет единых понятий, то возникают разночтения...СТП не понимает пользователя, и наоборот. Двадцать лет назад никто про ITIL не знал, но ведь работали...Были обыкновенные диспетчера, которые принимали заявки и эскалировали их дальше... А сегодня это называется 1-ая линия. Ничего по сути не изменилось..
ALL
Добавлено:
Коллеги, повторю свой очередной вопрос.
В сведениях о заявке, есть параметр "Срок ответа":
Для чего он нужен?
заработала SSO, пароль не правлиьно заполнял, всёж-таки пришлось таблицу jespaconfiguration заполнять руками - вот сижу и думаю, в чём это может в дальнейшем вылезти
Коллеги, по закрытию заявки в SDP 8 есть вопрос. Тестирую сейчас версию 8.0.0.7, в версии 8.0.0.0 такое также наблюдается.
Когда мы закрываем заявку, нам предлагают- "закрыть принятые":
Если мы отвечаем "ДА", заявка закрывается, статус переводится в "closed".
Если мы отвечаем "Нет", заявка также закрывается c переводом статуса на "closed".
Вопрос: в чем принципиальное отличие закрытия заявки? (и в том и другом случаи заявка закрывается с переводом статуса в "closed").
Когда мы закрываем заявку, нам предлагают- "закрыть принятые":
Если мы отвечаем "ДА", заявка закрывается, статус переводится в "closed".
Если мы отвечаем "Нет", заявка также закрывается c переводом статуса на "closed".
Вопрос: в чем принципиальное отличие закрытия заявки? (и в том и другом случаи заявка закрывается с переводом статуса в "closed").
Цитата:
Если мы отвечаем "ДА", заявка закрывается, статус переводится в "closed".
Если мы отвечаем "Нет", заявка также закрывается c переводом статуса на "closed".
Если нажимаем"ДА" - заявка закрывается якобы с подтверждением пользователя.
Если "Нет" - то без подтверждения пользователя.
Вот и вся разница... Кстати когда заявку открываешь в сведениях о заявки видно следующие:
"Сведения о закрытии заявки
Закрыто после подтверждения от запросчика
Комментарии
выполнено" - это в случае с "Да".
В противном случае: текст меняется на: "... закрыто без подтверждения"..
Вот и весь "тайный" смысл этих "да" и "нет"...
Добавлено:
to SVRRR
по поводу параметра "Срок ответа"....
Этот параметр есть в настройках SLA. Помимо времени решения, есть время первого ответа.
Применяется допустим в случае, если новая заявка зарегистрирована со статусом "открыто", но при начале решения заявки специалистом меняется статус или другие поля До окончания данного срока ответа.
Если специалист должен принять во внимание заявку (допустим в течении 15 минут), отреагировать на нее (в соответствии в вашими процессами), а не сделал этого, то считается уже нарушением соглашения (если есть) о первой реакции, первого ответа по данной заявке.. полезная "фишка" на самом деле... и пользователь может быть уведомлен о том что его заявка принята к рассмотрению специалистом и находится "в работе"...
2 kogor222
Большое Спасибо! за оперативный и полный ответ!
не совсем понятно... по поводу "Срока ответа"
Цитата:
Параметр "Время первого ответа" (в сведениях о заявке) является - "Дата ответа". И с ним все ясно. Получил специалист заявку от пользователя, ответил первый раз, и это время зафиксировалось как "время первого ответа"- "Дата ответа" . Если время первого ответа нарушается, то у специалиста рядом с параметром "статус" появляется оранжевый кружок- нарушение первого ответа:
А вот "срок ответа" если я правильно понял, указан в SLA и привязан к строке: "Ответ на любой запрос, который соответствует вышеупомянутым правилам, должен быть дан не позднее чем".
Получается что этот параметр ("срок ответа") автоматически проставляется системой при задержке ответа, или в ручную корректируется специалистом. Вот только в чем выражается его полезность?? (не путать со "временем первого ответа" - "Дата ответа")
Цитата:
а где настраивается этот шаблон уведомления, и как он точно называется?
В разделе Уведомления для инициатора заявки, есть только эти:
Большое Спасибо! за оперативный и полный ответ!
не совсем понятно... по поводу "Срока ответа"
Цитата:
по поводу параметра "Срок ответа"....
Этот параметр есть в настройках SLA. Помимо времени решения, есть время первого ответа.
Параметр "Время первого ответа" (в сведениях о заявке) является - "Дата ответа". И с ним все ясно. Получил специалист заявку от пользователя, ответил первый раз, и это время зафиксировалось как "время первого ответа"- "Дата ответа" . Если время первого ответа нарушается, то у специалиста рядом с параметром "статус" появляется оранжевый кружок- нарушение первого ответа:
А вот "срок ответа" если я правильно понял, указан в SLA и привязан к строке: "Ответ на любой запрос, который соответствует вышеупомянутым правилам, должен быть дан не позднее чем".
Получается что этот параметр ("срок ответа") автоматически проставляется системой при задержке ответа, или в ручную корректируется специалистом. Вот только в чем выражается его полезность?? (не путать со "временем первого ответа" - "Дата ответа")
Цитата:
.. полезная "фишка" на самом деле... и пользователь может быть уведомлен о том что его заявка принята к рассмотрению специалистом и находится "в работе"...
а где настраивается этот шаблон уведомления, и как он точно называется?
В разделе Уведомления для инициатора заявки, есть только эти:
Цитата:
А вот "срок ответа" если я правильно понял, указан в SLA и привязан к строке: "Ответ на любой запрос, который соответствует вышеупомянутым правилам, должен быть дан не позднее чем".
"полезность" простая... Контроль за решением заявок к примеру..
существуют разные реализации сервисдэска на предприятиях и в организациях.
если пользователь Звонит в службу (к примеру) и диспетчер заводит заявку назначая на специалиста (с другого подразделения), то тут можно отследить взяли на обслуживание заявку или она до сих пор висит под первоначальным статусом (к примеру).. а если заключены OLA между подразделениями (к примеру департаментом СервисМенеджмента (ДСМ)и ДИТ), то тут можно сказать "норма поведения"... ДСМ отвечает перед бизнеспользователями за предоставление качества услуг Айти.. а OLA по сервисам заключено между этими департаментами АйТи.. Т.к. в данном случае SLA может быть заключен (в данном примере) между ДСМ и Бизнесом.. Но не между Бизнесом и ДИТ напрямую... Вообщем смотря какая организация, какая структура и пр...
Эти параметры применять к различным целям и задачам.. Все зависит от полета "фантазии" ..
Добавлено:
Цитата:
а где настраивается этот шаблон уведомления, и как он точно называется?
В разделе Уведомления есть только эти:
в SLA есть эскалация 1,2,3... и т.д. .. там есть и шаблоны.. там есть и кому.. это как минимум.. )
Цитата:
в SLA есть эскалация 1,2,3... и т.д. .. там есть и шаблоны.. там есть и кому.. это как минимум.. )
В SLA шаблонов нет. А потом, задача стоит посылать уведомления не специалистам а пользователям. ) Поэтому я и привел подробную таблицу с уведомлениями пользователя.
Цитата:
В SLA шаблонов нет. А потом, задача стоит посылать уведомления не специалистам а пользователям. ) Поэтому я и привел подробную таблицу с уведомлениями пользователя.
согласен в самом SLA нет.. есть шаблоны уведомлений.. и электронных сообщений..
а чем сложность допустим поставить "галочку" насчет уведомлений инициатора об Обновлении его заявки?!... ведь внутренние задачи и переписка не "светится" пользователю (если конечно у пользователя нет прав или не направлены специалистами).. к примеру .. при регистрации заявки пользователь может получать уведомление о регистрации его заявки.. далее.. при изменении статуса, например (если меняется статус при приеме специалистом на расследование или исполнение заявки) высылается уведомление пользователю.. в данном случае он в курсе что его заявка принята специалистом для решения.. или когда заявка будет выполнена.. тут можно манипулировать уведомлением пользователя.. но конечно многие моменты зависят от организации самого процесса... и Не все, к сожалению, можно реализовать в данном ПО.. пока "WorkFlow" не на высоте.. не тот уровень ПО для реализации сложных Процессов.. может все-таки доработают со временем..
2 kogor222
Цитата:
В этом случае при каждом изменении заявки специалистом пользователь будет постоянно получать уведомления. Это его будет напрягать.
Цитата:
а чем сложность допустим поставить "галочку" насчет уведомлений инициатора об Обновлении его заявки?!...
В этом случае при каждом изменении заявки специалистом пользователь будет постоянно получать уведомления. Это его будет напрягать.
Цитата:
В этом случае при каждом изменении заявки специалистом пользователь будет постоянно получать уведомления. Это его будет напрягать.
на каком именно этапе изменений?..
как-то тестировал:
назначение категорий, подкатегорий и т.д. - получает
назначение, переназначение специалистов - получает
все практически изменения в "шапке" заявки - да, получает..
решение - получает..
а вот назначение задач, сообщения специалистам, внутренние обсуждания - не получает..
Но... если автоматизирована система срочности, приоритетов, назначение специалистов или групп по категориям заявки, и прочее прочее... - то минимизировано получение пользователем дополнительных уведомлений.. это понятно почему.. если "грамотно" сделана первоначальная классификация инцидента или типового запроса на обслуживание, то пользователь получает минимум 4 сообщения.. 1. регистрация 2. классфикация и взятие на обслуживание инцидента или решение.. 3. о решении и 4. закрытие.. И то... последнее можно получать, можно не получать.. Так же как и первое... Но опять же.. насколько оптимизирован, расписан сам процесс.. столько конечно и уведомлений получит пользователь, если стоит "галка" уведомления о обновлении заявки..
конечно так пользователей сам не "мучил" раньше.. у меня своя служба сервисдеска была. которая снимала эти вопросы.. и сам процесс управления инцидентов не стремился усложнять.. надобности в лишних оповещениях не было.. а вот что касалось хорошего описания сервисов и реализации в системе - тут вот пришлось "по потеть"..
2 kogor222
Цитата:
на этапе внесения изменений в заявку специалистом, причем при каждом изменении..
Цитата:
у меня всего три уведомления для пользователя.
1. регистрация
2. классификация и взятие на обслуживание инцидента
3. закрытие
Цитата:
это самое главное)
Добавлено:
еще вопрос
Если применяется схема работы дежурных специалистов по графику, например 2Х2.
Как в таком случаи настроить автоматическое переназначение заявки на каждого специалиста с интервалом работы два дня.
Есть специалист - Иванов и Петров. В смену Иванова заявки должны назначаться Иванову, а в смену Петрова соответсвенно Петрову.
Пробовал через "Планировщик" и через "Автоматическое назначение специалиста" не получается.
И возможно ли вообще такое сделать?
Добавлено:
а также, как настроить SMS уведомления специалистам? И с каким оператором сотовой связи работает этот сервис?
Цитата:
на каком именно этапе изменений?..
на этапе внесения изменений в заявку специалистом, причем при каждом изменении..
Цитата:
если "грамотно" сделана первоначальная классификация инцидента или типового запроса на обслуживание, то пользователь получает минимум 4 сообщения.. 1. регистрация 2. классфикация и взятие на обслуживание инцидента или решение.. 3. о решении и 4. закрытие..
у меня всего три уведомления для пользователя.
1. регистрация
2. классификация и взятие на обслуживание инцидента
3. закрытие
Цитата:
а вот что касалось хорошего описания сервисов и реализации в системе - тут вот пришлось "по потеть"..
это самое главное)
Добавлено:
еще вопрос
Если применяется схема работы дежурных специалистов по графику, например 2Х2.
Как в таком случаи настроить автоматическое переназначение заявки на каждого специалиста с интервалом работы два дня.
Есть специалист - Иванов и Петров. В смену Иванова заявки должны назначаться Иванову, а в смену Петрова соответсвенно Петрову.
Пробовал через "Планировщик" и через "Автоматическое назначение специалиста" не получается.
И возможно ли вообще такое сделать?
Добавлено:
а также, как настроить SMS уведомления специалистам? И с каким оператором сотовой связи работает этот сервис?
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
Предыдущая тема: Клиент для чтения форумов :)
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.