» Adventnet ManageEngine ServiceDesk Plus

Цитата:

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

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


Цитата:

Сайт это что-то вроде филиала фирмы. Другими словами территориально удалённое подразделение фирмы либо другая фирма (в случае работы с внешними организациями). У каждого сайта могут быть свои отделы. например и у сайта "А" и у сайта "Б" могут быть отдел с одинаковым названием такими как "Администрация", "Бухгалитерия" и т.д. Но самое главное кроется глубже, а именно в разделении прав и назначении SLA. У каждого отдельного сайта может быть свой режим работы, свой SLA и выделенные операторы службы поддержки, которые видят в сервисдеске только указанные сайты. так же например руководителю сайта можно выставить "Видеть все запросы своего сайта". Другими словами это разделение нужно в том случае если вы работаете в распределённой структуре. Либо это филиалы вашей фирмы, либо это вообще отдельные фирмы или филиалы фирм, в случае если вы аутсорсер. Примерно так.

Если же у Вас нет распределённой территориально филиальной структуры, то сайты Вам не нужны!
Ну не знаю как ещё объяснить. Попробуйте себе просто запомнить, что сайт - всегда клиент! Т.е. это группа пользователей, а не группа админов. Это может быть как отдельный клиент, так и часть клиента (филиал, склад, производство - в общем территориально отдельный кусочек клиента).

2 optimusprinceps


Цитата:

Это может быть как отдельный клиент, так и часть клиента (филиал, склад, производство - в общем территориально отдельный кусочек клиента).

Спасибо большое, теперь все стало ясно!

Ну дык вроде же так же писали выше


Цитата:

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

Коллеги, подскажите пожалуйста, как сделать групповую рассылку пользователям уведомления об объявлении? SDP 8.0.7
и как использовать "уведомление об объявлении"?

Цитата:

как использовать "уведомление об объявлении"?

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


Цитата:

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

Ну шлите объявление на список рассылки вида allusers@yoursdomaim.ru, сделав его предварительно на вашем почтовике... Хотя я не вижу смысла в том, что бы уведомлять всех пользователей о том, что у них закончился контракт или что-то связанное с заказом. Ну и собственно кому конкретно слать уведомления об истекающих Контрактах или о Заказах - настраивается соответственно в Заказах и в Контрактах, для этого не нужно править шаблон.

Други! а есть у когонить доступ к подаче "хотелок" на ихним сайте?
Мож кто напишет что было бы неплохо фильтровать "Объявления" по "Сайтам".
Есть же там галочка - Только для "спецов" или "для всех". Вот было бы не плохо чтобы можно было вывесить объявление для определённого "сайта".
Ну и в догонку хотелось бы такое же разделение и в "Решениях". Чтобы решения по одному подразделению/клиенту - не было видно другим. А то иной раз и хочется написать объясняловку - но тогда вскрываются приватные данные - не нужные для посторонних глаз.

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

Коллеги!
Подскажите, как почикать аккуратно старые записи - нужно оставить только за прошлый год базу, а все остальное удалить!
Версия 7.0.0 Build 7022
win 2003

alexxbeer
а в чем проблема? или тебе нужно и нумерацию "сбить"?

Цитата:

а в чем проблема? или тебе нужно и нумерацию "сбить"?

Да что-то притормаживать начинает

А как же режим "Архивированных запросов"? Мне кажется именно для этого он и предназначен.

Цитата:

А как же режим "Архивированных запросов"? Мне кажется именно для этого он и предназначен.

я про это ничего не знаю просветите?

2 optimusprinceps


Цитата:

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

&

Цитата:

Ну шлите объявление на список рассылки вида allusers@yoursdomaim.ru, сделав его предварительно на вашем почтовике... Хотя я не вижу смысла в том, что бы уведомлять всех пользователей о том, что у них закончился контракт или что-то связанное с заказом. Ну и собственно кому конкретно слать уведомления об истекающих Контрактах или о Заказах - настраивается соответственно в Заказах и в Контрактах, для этого не нужно править шаблон.

Речь идет не о использование заказа или контракта, это отдельная тема.
Вы создали новое объявление, например, о том, что сервер будет временно не доступен. И нужно его разослать юзерам. То что сейчас предлагается (вручную вбивать почтовые адреса) для рассылки:
это не совсем удобно.

Цитата:

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

если не существует групповых электронных адресов, то Да.. согласен не удобно.. а если есть эл. адреса групповых рассылок - то почему бы и не воспользоваться этим..

2 kogor222


Цитата:

а если есть эл. адреса групповых рассылок - то почему бы и не воспользоваться этим..

Воспользовался групповой рассылкой, действительно удобно! Спасибо!

Цитата:

Воспользовался групповой рассылкой

Ну дык и я об этом...

Добрый день.
Поставили новую версию и появилась проблема:

в заявке присланной по почте не вставляется автоматически отдел.
Из-за этого отчет заявки по отделам теперь показывает все заявки в неназначенных.
Кто-то столкнулся с этой проблемой?

Добрый день, коллеги. Несколько вопросов.
Для чего следует использовать статус заявки "On Hold"? В моём представлении самые ходовые "Открыта - Open", "В работе" (создал сам), "Назначено" (создал сам), "Выполнено - Resolve" и "Закрыта - Close", не могу понять для чего этот статус, к тому же отключаться он не желает.

Не нашёл как у Специалистов отключить вкладку "Поддержка" и как урезать ссылки в шапке до "Личные настройки Выход [%username%]" Людям которые


Версия 8007

для тех случаев, когда невозможно далее (временно) осуществлять поддержку, например из-за отсутствия комплектующих или лицензий на ПО.

Цитата:

Для чего следует использовать статус заявки "On Hold"?

Добавлю к предыдущему ответу..
Статусы можно свои добавлять Любые... которые Вам необходимы по Процессу..
Но...
Обращайте внимание на таймер выполнения заявок при Статусах.. Если применяете настройки SLA и ведете учет времени, то обращайте на таймеры статусов...
В данном случае статус "On Hold" как раз таки останавливает Время решения заявки, что по сути является ожиданием для ее решения (примеры приведены ранее)...

Ну а если я не хочу этот статус использовать или скажем, не хочу чтобы у всех специалистов был доступ к статусу с остановкой таймера.
SLA пока не используется, только планируется.

Цитата:

Статусы можно свои добавлять Любые...

На самом деле, если исходить из теории, то статусы должны быть именно те, которые там есть и никакие другие. Понятно, что ITIL\ITSM это есть просто рекомендации, но они не зря уже стали фактически стандартом. Дело в том, что каждый из этих статусов несёт за собой конкретный процесс и ведёт к определённым действиям, как со стороны Инициатора заявок, так и со стороны Исполнителя. Если добавить в этот список ещё статусы, то соответственно - это либо новые процессы, либо это просто мусор. В своё время на курсах по ITIL кто-то тоже задавал этот вопрос. И по итогу мы сами же на него и ответили - мы не смогли привести случая, когда заявка может иметь статус отличные от тех, которые есть по умолчанию.

Конечно, в данном ПО, да и не только в этом, есть возможность добавлять новые статусы, но как правило это делается просто от непонимания теории - реальной необходимости в этом как правило нет (если конечно оптимально настроены сам автоматизируемый этим ПО процесс).


Цитата:

Ну а если я не хочу этот статус использовать

Опять же нужно вернуться к теории. Проблема не в том, что вы хотите, а что нет - под каждое "хочу" ПО написать очень дорого, стоить оно будет немеряно и конфигурить его Вы просто устанете. Возьмите внедерите у себя HP ServiceDesk 4.5 - там можно делать практически всё, но внедрение занимает минимум полгода. Цена же продукта - просто ппц.

Статус OnHold, используется в том случае, если заявку нужно поставить "на удержание". Дело даже не в остановке счётчика. дело в самом процессе и в цели для которой это сделано. Практически всегда может возникнуть ситуация, когда от Инициатора нужна доп. информация, которую он не может предоставить прямо сию секунду. Как раз в этом случае заявку ставят на OnHold. И, поверьте, это не просто блажь. Если заявка находится в статусе "Открыта", но фактически над ней Специалист не может начать работу, т.к. ему не хватает данных от Инициатора, то возникает момент, когда заявка не может быть Закрыта, как решённая и может висеть в данном статусе вечно, т.к. грубо говоря Инициатор вообще может забыть о том, что он кому-то что-то должен предоставить дополнительно, а ч ерез месяц он обратиться к руководителю поддержки с вопросом: "... собственно, а какого х... оно до сих пор открыта?". И вот здесь как раз статус OnHold разруливает данный конфликт.
Примеров конечно использования данного статуса можно привести массу, но смысл такой - заявка в статусе OnHold в некотором смысле снимает ответственность за сроки её решения (не зря она останавливает и таймер).

Цитата:

На самом деле, если исходить из теории, то статусы должны быть именно те, которые там есть и никакие другие. Понятно, что ITIL\ITSM это есть просто рекомендации, но они не зря уже стали фактически стандартом.

Согласен и одновременно не согласен... Дилема?!.. Нет..
Статусы могут выставлены разные.. В зависимости от "сложности" самого процесса, структуры, вида деятельности предприятия и пр...
ITIL - не стандарт.. А Рекомендации... и не всякий "стандарт" "решает" "инциденты" "проблемы" и пр. заморочки на предприятии..
Если, к примеру, у вас Пользователи регистрируют заявку (инцидент), то она по умолчанию имеет статус Open (или Открыто). Если Вам надо информировать пользователя о взятии заявки на решение специалистом, то можно просто менять Статус специалистом (к примеру: В работе)... Все относительно..
Основной смысл и предназначение статусов уже определены в системе..
Я с точки зрения удобства, информативности рассуждал, когда писал что статусы "любые".. и не зря же есть две категории, где определяются статусы.. на этапе решения и этапе закрытия.. они могут дополнятся своими статусами, которые определены этапами процесса..

Ребята, кто делал автоматическое назначение группы, а именно:
Есть несколько групп, в которой по несколько спецов. Так вот надо, чтоб при назначении на специалиста автоматом назначалась группа в которой он находится. Конечно, можно назначить группу потом техника. Но вот надо чтобы автоматом.
Сейчас я стараюсь прикрутить тригер к этому делу. Если кто делал скажите как, дабы не лапатить, спасибо

optimusprinceps, спасибо кеп. Реалии несколько иные и подгонять всё под полностью итиль когда 250 юзеров нету возможности. Спасибо что прояснил зачем статус, но всётаки хотелось бы заблокировать его у специалистов кроме некоторых, так как могут тупо поставить статус чтобы не появилось флажка =)

Если рассуждать так, то
Цитата:

с точки зрения удобства

чем оптимальнее процесс, чем меньше в нём звеньев - тем удобнее. Соответственно, чем меньше статусов - тем тоже удобнее, т.к. спец-там меньше нужно заморачиваться выбирая в какой статус отправить заявку, да и просто лишний раз его менять - тратить лишнее время. С точки зрения
Цитата:

информативности

для уведомления пользователя о том, что с его заявкой происходит - есть уведомления на почту + возможность отправить пользователю "Ответ" на его заявку, по которому можно отслеживать "Время реакции" и который можно создать из готового шаблона, к прмеру такого: "Уважаемый ФИО Ваша заявка перенаправлена профильному специалисту. Ожидайте её решения в установленные SLA сроки".
Поймите, статусов можно и 300штук придумать, просто их в каждой заявке 300 раз менять прийдётся - вопрос в том, стоит ли на это тратить время? Если вы своё время не считаете, как внедренца, то посчитайте время операторов и специалистов, которые эти статусы каждый день клацать будут...


Добавлено:

Цитата:

подгонять всё под полностью итиль

Это реально не нужно, просто ITIL это всё же опыт тысяч специалистов и он не зря писался. Понятно, что у каждого свой гемор, под который нужно софт заточить, но базовых принципов проще придерживаться...

Цитата:

когда 250 юзеров нету возможности

Не правда, у меня больше 1000 юзеров и поверьте, чем точнее вы подгоняете, тем проще и универсальнее система. Поймите, что любое отклонение от базы вас ведёт по сути в сторону от основной ветки, которое в свою очередь может потребовать потом ещё чтонить дописать, потом допилить и через годик-другой софт, который устраивает большинство, вас уже ну никак устраивать не будет. Ну по крайней мере я такие случаи уже видел...
Ну а что касается собственно самого статуса OnHold, то если зайти в его настройки, то там можно снять галочку "Остановить таймер". После этого при установке заявки в данный статус - таймер останавливаться не будет и статус этот будет вам для
Цитата:

удобства, информативности

ну и для чего ещё там Вы их плодите

2 vrednyi


Цитата:

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

Зайди в "Категории", и назначь специалиста на группу:

Также можно делать назначения через бизнес-правила.

Подскажите пожалуйста подоходит ли SDP в следующем случае.
Сапорт который админит несколько организаций? В данном случае каждую организацию мы создаём в Сайтах?
Просто коллеги уверяю меня, что SDP это классная штука исключительно если она работает в пределах одного предприятия, а в вышеназванном она неудобная.

Ещё хотелось бы узнать возможна ли инвентаризация виндовых машин в том случае если сам SDP работает на Linux сервере?

Цитата:

Сапорт который админит несколько организаций? В данном случае каждую организацию мы создаём в Сайтах?

Сам так работаю - отлично подходит. Если спорили с коллегами на пиво - вы выиграли. Каждую организацию, а если быть точнее, то каждый её филиал, создаём в сайтах.


Цитата:

а в вышеназванном она неудобная.

Та адых х..н как говорится. разницы нет никакой для какого кол-ва организаций вы используете данный софт.


Цитата:

Ещё хотелось бы узнать возможна ли инвентаризация виндовых машин в том случае если сам SDP работает на Linux сервере?

Давно не пробовал, но на старых версиях вывалилась ошибка "станция не просканирована, т.к. сервисдеск работает не на платформе Windows". Что-то вроде этого.

Добавлено:
Кстати, если заработает - маякните!

2 optimusprinceps


Цитата:

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

По поводу дополнительных статусов в SDP. Когда первый раз внедрял SDP, то количество дополнительных статусов было введено около 3-4 штук. Со временем понял, что эти дополнительные статусы оказались не нужны по причине описанной optimusprinceps. На данный момент, из дополнительных статусов оставил только один, по специфики бизнес-процесса обработки заявок.
Надеяюсь в дальнейшем перейти на стандартные статусы в SDP.