По функционалу системы

[ykolesnikov]

До принятия решения о применении OTRS, хотелось бы понять:
1. Есть ли в системе функционал управления конфигурациями, ведения базы конфигурационных единиц, связи их с владельцами/клиентами. Возможность при регистрации заявки с телефонног запроса по пользователю видеть приписанное к нему оборудование.
2. Есть ли встроенные средства мониторинга оборудования клиентов и сетевого оборудования или надо прикручивать внешние средства
3. В продолжение/развитие п.2 - есть ли возможность регистрировать инциденты порождаемые средствами мониторинга (напр. алерты от сетевых устройств)
4. Возможность эскалации инцидентов/запросов
5. Оповещение о поступивших запросах на обслуживание руководителей групп поддержки/назначение таких руководителей и их заместителей.

Можно ли это где-то прочитать, желательно на русском языке.
Где можно скачать документацию на русском по OTRS TicketSystem и OTRS ITSM и их взаимодействию.

Заранее спасибо.

[alexus]

Отвечу по пунктам.
1. CMDB есть в решении OTRS ITSM, связь с пользователями не поддерживается по умолчанию (требуется доработка). Связь поддерживается с заявками, изменениями, другими КЕ и сервисами (услугами). Отбражание оборудование пользователя надо докручивать. Отображается сервис. Т.к. используются методы ITIL, то во главе угла не КЕ, а сервисы.
2. и 3. Встроенных средств мониторинга нет. Есть модуль мониторинга, который позволяет принимать сообщения от систем мониторинга и генерировать по ним инциденты. В настоящее время мы разрабатываем комплексное решение OTRS+мониторинг.
4. Само собой разумеется. Вопрос обработки заявок (инциденты, проблемы, запросы и т.п.) раскрыт полностью. OTRS ITSM сертифицирована PinkElehant на соответствие ряду процессов ITIL, в т.ч., конечно, инцидент менеджмент.
5. Это та же эскалация, только не функциональная, а иерархическая. Мониторинг работы ServiceDesk сделан хорошо + генерация отчетов по работе.

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

[JohniGo]

Отвечу по пунктам.
5. Это та же эскалация, только не функциональная, а иерархическая.

Есди по функционально эскалации нашел информацию (насколько я понял работает через GenericAgent), то вот по иерархической так пока не и нашел. Хотя логика подсказывает, что должна быть..

[alexus]

Практически любую логику любой эскалации в OTRS можно реализовать через уведомления о событии Суть иерархической эскалации - уведомлении вышестоящего руководства о каких-либо ситуациях для своевременного принятия решения!

[ykolesnikov]

О.К., спасибо за быстрый ответ.
Еще один вопрос:
Связь OTRS и ITSM. Функционал последнего добавляется к функционалу OTRS и появляется в меню?

[alexus]

Да, в меню. Ну и настроек, конечно. добавляется.

[ykolesnikov]

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

[alexus]

А что вы имеете ввиду под категорированием?

[ykolesnikov]

Под категорированием я понимаю возможность для клиента, создающего, например, web-заявку/запрос или агент принимающий запрос по телефону и регистрирующий запрос - не просто вводит текст описания инцидента, а вводит его из некоего иерархического списка, разбитого по категориям: инциденты с ПК, инциденты с принтером, инциденты с сетью - как первый уровень и затем, следующие уровни уточняют выбор - максимум 3 уровня, обычно достаточно. Это особенно полезно для клиента, который зачастую не в силах правильно сформулировать запрос, и, кроме того не дает ввести заявку типа - "хочу луну с неба". Все это уменьшает количество ошибок при назначении исполнителя/группы и избавляет от объяснений по "дурным" заявкам - все оперируют заранее заданными категориями

[alexus]

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

[ykolesnikov]

Управление через приоритеты я и не предлагал, это, конечно, нонсенс. Что надо использовать каталог сервисов, тоже понятно, вопрос в том, реализован ли он в OTRS::ITSM, где увидеть?
И еще вопрос - есть ли механизм создания задач/заданий для разных групп/исполнителей из запроса?; например, "Подготовка нового рабочего места" - включает задачи - "Получение ПК со склада, заливка образа ОС", "создание учетной записи пользователя", "Установка набора ПО для данной категории сотрудника"... Эти задачи могут выполняться разными группами/исполнителями. Или это решается путем разделения запроса вручную и назначение исполнителям, а, затем сборка опять же вручную, если можно отыскать следы и закрытие первичного запроса?

[alexus]

1. Создаете сервис в разделе "Администрирование->Система->Сервис". Создавать иерархически, разберетесь, это несложно.
2. Затем надо назначить сервис пользователям в разделе Пользователи & Группы & Роли -> [ Customer Users <-> Services ].
3. У вас появляется возможность выбора сервиса для юзера, когда вы выбрали юзера в заявке. В веб-интерфейсе юзера, соотв. тоже появляются сервисы.
Пример сервисов:
Сервис
Антивирусная защита
Локальная сеть
Печать
Сканирование
Доступ Интернет
ПО
ПО - Интернет-банк
ПО - Операционные системы
ПО - Офисные приложения
ПО - Приложения 1С
ПО - Электронная почта
Поставка ПО
Поставка оборудования
Телефонная связь
Удаленный доступ

И еще вопрос - есть ли механизм создания задач/заданий для разных групп/исполнителей из запроса?

А это уже делается с использованием Change management. Он делает все это! Ну или вручную
Настоятельно рекомендую почитать любую доступную литературу по ITIL и ITSM. Это поможет при постановке рабочих процессов и важно для понимания логики и принципов OTRS.

[ykolesnikov]

О.К., спасибо. Книжки уже читаем. Главное совместить теорию с конкретной реализацией в продукте и организации где разворачиваем систему.

[JohniGo]

Кстаи, а не подскажите, можно ли при группировке сервисов запретить выбор верхнего уровня.
Например:
- Локальная сеть
-- Локальная сеть в здании А
-- Локальная сеть в здании Б
-- Локальная сеть в здании В

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

[alexus]

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

[ykolesnikov]

Логичнее было бы, на мой взгляд, чтобы текст следующего уровня продолжал/уточнял формулировку верхнего уровня, иначе может потеряться смысл названия категории/сервиса. Если разрешить выбирать любого уровня, тогда на каждом уровне надо повторять текст предыдущего.
Например: "Сервисы для ОАО "Сталь-коляска".Бизнес-приложения.Контур-Экстерн.Недоступен сервис
"Сервисы для ОАО "Сталь-коляска".Бизнес-приложения.Контур-Экстерн.Другая ошибка
Здесь, если выбрать только последний уровень, будет непонятно о чем речь.

[ykolesnikov]

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

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

[JohniGo]

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

[alexus]

Если не давать доступа к верхнему уровню - теряется смысл в группировке (верхний уровень просто пропадает)

Для Вас смысл может и теряется, а для пользователя наверняка нет. Надо еще пользователя "воспитать" до такой степени, чтоб он заявки в системе сам делал, а не тупо звонил. Позвонить - это быстрее и проще! Поставьте себя на место пользователя. Всегда так делайте. Старайтесь не рассуждать с ИТ-шной точки зрения при проектировании пользовательского интерфейса. Только сделав так как удобно юзеру, а не ИТ, можно заставить его что-то сделать. Уверен, что 90% юзеров на первых порах будут сервис вообще по дефолту оставлять. Только если у Вас во всей компании сервис-менеджмент развит, тогда пользователь может и догадается, что такое вообще этот "сервис" ("Я думал, что сервис - это шиномонтаж!!!").

Вопрос как раз в том, как в списке сервисов оставить, а выбирать его не давать...

В OTRS - никак. Самая распространенная ошибка - "внедрять ИТИЛ" (это круто! вот программа, она ITIL-veryfied, мы ее поставим и все у нас будет хорошо!) начиная с технологий. Я могу построить такой ServiceDesk, что он будет работать безо всякого софта вообще, и все будут счастливы. Потому что, ключ успеха не технологиях и не в процессах, а в людях.
Хотя мечтать, конечно, надо, но рамках разумной необходимости. Ну или если Вам денег девать некуда

[JohniGo]

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

P.S. А то что "кадры решают все" это я очень хорошо понимаю, хотя процессы Вы зря так ИМХО. Если правильные кадры построят правильные процессы...

[ykolesnikov]

Похоже, мы все правильно понимаем что во главе всего процессы. Про интерфейс,я полностью согласен с alexus. Кто несогласен, читайте Алан Купер "Психбольница в руках пациентов". Не менее полезное чтиво чем руководства по ITIL/ITSM. Если пользователю будет удобно, если ему еще ненавязчиво объяснить, что правильный выбор сервиса/категории сервиса приведет к более быстрой реакции на инцидент/запрос, он, конечно не сразу, но научится это вводить. (Здесь не говорим об "отмороженных" VIP'ах, поручающих секретарю разобраться с этими айтишниками, или звонящими сразу CIO, что у них все не работает. У меня на прежней работе на крупном предприятии, генеральный директор не гнушался сам обращаться в ServiceDesk и прочих директоров научил обращаться туда, а не к начальнику УИТ и все поехало. Позицию первого руководителя никто не отменял. Иначе получится: "Рыба гниет с головы, а чистят ее с хвоста.)
Всех с Новым Годом и удачи. Спасибо за помощь и советы.
С уважением Ю. Колесников

[alexus]

Спасибо за поздравления! Вам тоже удачи и здоровья в Новом Году!
Про троицу Люди-Процессы-Технологии продолжим говорить после праздников !