Support Forum

[sekob]

Установлена кофигурация:
http://www.trackstudio.ru/itil.html

Изучена документация:
- файл configuration.odt
- http://www.trackstudio.ru/roles.html

В итоге в целом не понятна логика определения ролей.

Если смотреть на конфигурацию. Задана следующая иерархия объектов:
Проекты

Служба поддержки

Инциденты
Проблемы
Изменения
Конфигурационная база данных
База знаний

Далее, насколько я понял, есть условно "глобальные" роли, которые привязаны к оргструктуре (оператор службы поддержки, специалист службы поддержки, инженер и т.д.) есть условно "локальные" роли. В рамках объекта (задачи) глобальные переопределяются на локальные. Например, в рамках управления инцидентами Оператор службы поддержки = 1 линия.


Если смотреть реальную настройку, по каждому объекту происходит настройка ролей:

Проекты
Admin = administrator

Служба поддержки
1-я линия = 1-я линия
2-я линия = 2-я линия
3-я линия = 3-я линия
Escalator Bot = 1-я линия
Escalator Bot = 2-я линия
Escalator Bot = 3-я линия
Help Desk Admin = administrator
Инженер = 3-я линия
Клиент = Клиент
Менеджер 1 линии = Менеджер 1 линии
Менеджер 2 линии = Менеджер 2 линии
Менеджер 3 линии = Менеджер 3 линии
Оператор службы поддержки = 1-я линия
Роман Кузнецов = Менеджер 2 линии
Сервисный отдел = Менеджер 3 линии
Специалист службы поддержки = 2-я линия

Инциденты
Менеджер конфигураций = Обозреватель
Операторы службы поддержки = Менеджер 1 линии
Сервисный отдел Менеджер = 2 линии
Специалисты службы поддержки = Менеджер 3 линии
Федор Федоров = Обозреватель


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


Идем дальше. В описании конфигурации и в настройках есть роли:
- Service Bot;
- Инициатор изменений.

Но, где и как они задействованы не понятно?

По первой роли. Есть оперирование на уровня пользователя, т.е. Escalator Bot, но не нашел Service Bot.
По второй роли. Есть сама роль, есть её описание в configuration.odt "Пользователи с этой ролью регистрируют в системе запросы на изменения. (Инженер)", но на уровне определения ролей к объекту "Изменения", есть следующее:

Инженер = Менеджер изменений
Менеджер изменений = Менеджер изменений
Оператор службы поддержки = Оператор службы поддержки
Руководитель = Координатор изменений
Руководитель = Аналитик изменений
Специалист службы поддержки = Обозреватель

А где Инициатор изменений, непонятно.

Еще не совмес понятно такое опредление ролей (в каких случах и зачем так определяются роли):
1-я линия = 1-я линия
Клиент = Клиент
Менеджер изменений = Менеджер изменений

и т.д. Особенно с тем учетом, что такое не всегда встречается, например, нет:

Инициатор проблем = Инициатор проблем
Координатор изменений Координатор изменений
Менеджер конфигураций = Менеджер конфигураций
и т.д.

[mvasenkov]

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

По идее, да, роли 1-2-3 линий должны использоваться только для инцидентов, а для других задач должны использоваться свои роли (вроде того же инициатора изменений). Но это всплыло уже после того, как часть с инцидентами была полностью настроена, поэтому я решил не переделывать.

Идем дальше. В описании конфигурации и в настройках есть роли:
- Service Bot;
- Инициатор изменений.

Но, где и как они задействованы не понятно?

По первой роли. Есть оперирование на уровня пользователя, т.е. Escalator Bot, но не нашел Service Bot.
По второй роли. Есть сама роль, есть её описание в configuration.odt "Пользователи с этой ролью регистрируют в системе запросы на изменения. (Инженер)", но на уровне определения ролей к объекту "Изменения", есть следующее:

Инженер = Менеджер изменений
Менеджер изменений = Менеджер изменений
Оператор службы поддержки = Оператор службы поддержки
Руководитель = Координатор изменений
Руководитель = Аналитик изменений
Специалист службы поддержки = Обозреватель

А где Инициатор изменений, непонятно.

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

Еще не совмес понятно такое опредление ролей (в каких случах и зачем так определяются роли):
1-я линия = 1-я линия
Клиент = Клиент
Менеджер изменений = Менеджер изменений

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

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

Вообще конфигурацию еще есть куда допиливать. Я и планировал этим заняться, но мне нужна информация о практическом опыте использования, чтобы изменения вносить. Иначе будет ересь получаться.

[sekob]

Спасибо за оперативный ответ. Кое-что прояснилось.

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

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

По тем же ролям: "Service Bot", "Инициатор изменений" на первый взгляд кажется что их просто упустили. Т.к. в документации они описаны, есть в системе, но в качестве "локальных" ролей к задачам не привязаны.

Но с другой стороны есть "Менеджер изменений" в роли которого выступает Инженер, что и по "Инициатору изменений" (по документации) и у "Менеджера изменений" есть права на регистрацию изменений. Т.е. в последний момент может по "идеологическим" причинам отказались от роли "Инженер изменений", но в документации не отразили и роль не удалили из системы.

Поэтому хочется понять, есть ли ошибка, если есть то какая (техническая, идеологическая). Или я что-то не понимаю.

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

Задача "Инцидент".
1) Название операций "Решение подтверждено", правильно "Подтверждение решения".
2) Между статусами "Решение отклонено" и "Передан на вторую линию" нет связи (операции), напрашивается "Передача на вторую линию"
3) Есть статус "Закрыт", но при этом кроме "заметки" - там нет операций.

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


Но возвращаясь к ролям. Возник еще вопрос. Почему по задаче "Инцидент" используется привязка не ролей, а условно в терминах орг.структуры, т.е. прописано:

Операторы службы поддержки = Менеджер 1 линии
Сервисный отдел = Менеджер 2 линии
Специалисты службы поддержки = Менеджер 3 линии

а не:
Оператор службы поддержки = Менеджер 1 линии
Инженер = Менеджер 3 линии
Специалист службы поддержки = Менеджер 2 линии

[mvasenkov]

Спасибо за оперативный ответ. Кое-что прояснилось.

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

ITSM - довольно сложная конфигурация, она именно для ITSM. Если у вас деятельность не по ITIL организована, может лучше другую конфигурацию попробовать? Стандартную ту же (хотя лично мне она не нравится).

По тем же ролям: "Service Bot", "Инициатор изменений" на первый взгляд кажется что их просто упустили. Т.к. в документации они описаны, есть в системе, но в качестве "локальных" ролей к задачам не привязаны.

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

Но с другой стороны есть "Менеджер изменений" в роли которого выступает Инженер, что и по "Инициатору изменений" (по документации) и у "Менеджера изменений" есть права на регистрацию изменений. Т.е. в последний момент может по "идеологическим" причинам отказались от роли "Инженер изменений", но в документации не отразили и роль не удалили из системы.

В данном случае "менеджер" - это тот, кто может управлять. Редактор изменений как-то не звучит.

Штука тут вот в чем: для инцидентов, изменений и т.п. есть роли, прописанные в методологии ITIL. А есть роли, которые нужны для реализации какой-либо функциональности в TrackStudio.

Задача "Инцидент".
1) Название операций "Решение подтверждено", правильно "Подтверждение решения".

Да, наверное. Странно, обычно я именно "Подтверждение решения" использую в качестве названия операции. Надо исправить.

2) Между статусами "Решение отклонено" и "Передан на вторую линию" нет связи (операции), напрашивается "Передача на вторую линию"

Передается на третью линию потому что

3) Есть статус "Закрыт", но при этом кроме "заметки" - там нет операций.

А с закрытыми инцидентами и не должно быть операций.

Но возвращаясь к ролям. Возник еще вопрос. Почему по задаче "Инцидент" используется привязка не ролей, а условно в терминах орг.структуры, т.е. прописано:

Операторы службы поддержки = Менеджер 1 линии
Сервисный отдел = Менеджер 2 линии
Специалисты службы поддержки = Менеджер 3 линии

а не:
Оператор службы поддержки = Менеджер 1 линии
Инженер = Менеджер 3 линии
Специалист службы поддержки = Менеджер 2 линии

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

[sekob]

ITSM - довольно сложная конфигурация, она именно для ITSM. Если у вас деятельность не по ITIL организована, может лучше другую конфигурацию попробовать? Стандартную ту же (хотя лично мне она не нравится).

Мы хотим именно ITSM в первую очередь организовать деятельность. Ну и для этого как следствие уже требуется некое IT-решение.

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

Методологически их назначение - понятно. Не понятно как именно в системе они задействуются. Т.е. я не нашел:
Escalator Bot (пользователь) = Service Bot (роль). Я понимаю, что Escalator Bot - это служебный пользователь и который реально задействован, т.е. есть определение: Escalator Bot = 1-я линия.

Аналогично по "Инициатору изменений" роль в системе заведена, но не один пользователь не соотносится с этой ролью, т.е. нет:
"Инженер" = "Инициатор изменений", хотя в документации заявлено:

Инициатор изменений
Пользователи с этой ролью регистрируют в системе запросы на изменения. (Инженер)

В общем вопросы если коротко сводятся не методологического свойства, а почему эти роли заведены, а технического почему в системе чисто технически они не определены, просто в воздухе повисают?

Передается на третью линию потому что

С точки зрения логики странно. Получается, поступил инцидент на 1-ой линии не решили и передали на 2-ую, на 2-ой линии нашли решение, его отклонили и после этого инцидент сразу переходит на 3-ию линию? А у 2-ой линии второй попытке нет, найти другое решение? Логично, со статуса "решение отклонено" передать на ту линию, где инцидент решался, в случае если решался 1-ой линией то она же ищет еще решения или повышает уровень.

Повторюсь все эти тонкости большого значения не имеют, поскольку тут понятно как это корректировать (адаптировать). Не важно то ли это ошибка то ли концептуальная задумка.

А с закрытыми инцидентами и не должно быть операций.

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

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

Возможно. Но ответа на вопрос я не получил. Переформулирую, можно ли вместо привязок к ролям в рамках задачи "инцидент":

Операторы службы поддержки = Менеджер 1 линии
Сервисный отдел = Менеджер 2 линии
Специалисты службы поддержки = Менеджер 3 линии


определить вот так:

Оператор службы поддержки = Менеджер 1 линии
Инженер = Менеджер 3 линии
Специалист службы поддержки = Менеджер 2 линии

Или там есть какие-то подводные камни?



P.S. В предыдущем моем сообщении
"Т.е. в последний момент может по "идеологическим" причинам отказались от роли "Инженер изменений", но в документации не отразили и роль не удалили из системы."
опечатка. Правильно: Инициатор изменений.

[sekob]

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

Задумался. Да. Идею понял. Фактически сейчас получается, что есть:

Оператор службы поддержки
Специалист службы поддержки
Инженер
Руководитель
Клиент
Service Bot

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


Насчет роли "Service Bot" - понял где она задействована. Т.е. при заведении пользователя Escalator Bot ему там присваивается "глобальная" роль "Service Bot".

Но вот по роли "Инициатор изменений" связи найти не могу, склоняюсь к тому что её завели, но забыли задействовать. Если её удалить, то ничего не произойдет.

[mvasenkov]

Аналогично по "Инициатору изменений" роль в системе заведена, но не один пользователь не соотносится с этой ролью, т.е. нет:
"Инженер" = "Инициатор изменений", хотя в документации заявлено:

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

Передается на третью линию потому что

С точки зрения логики странно. Получается, поступил инцидент на 1-ой линии не решили и передали на 2-ую, на 2-ой линии нашли решение, его отклонили и после этого инцидент сразу переходит на 3-ию линию? А у 2-ой линии второй попытке нет, найти другое решение? Логично, со статуса "решение отклонено" передать на ту линию, где инцидент решался, в случае если решался 1-ой линией то она же ищет еще решения или повышает уровень.

Да, пожалуй имеет смысл при отклонении передавать на 2-ю линию обратно. Надо проверить, задействуется ли при отклонении поле Резолюция. Если нет - задействовать.

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

Нда... действительно, статус повис в воздухе. Вообще конечным этапом именно для инцидентов является их решенное состояние - в нем они остаются и используются в системе для поиска быстрых решений. А статус "Закрыто" задумывался для вывода инцидентов из системы после анализа и т.п. Видимо не доделал я.

Возможно. Но ответа на вопрос я не получил. Переформулирую, можно ли вместо привязок к ролям в рамках задачи "инцидент":

Операторы службы поддержки = Менеджер 1 линии
Сервисный отдел = Менеджер 2 линии
Специалисты службы поддержки = Менеджер 3 линии


определить вот так:

Оператор службы поддержки = Менеджер 1 линии
Инженер = Менеджер 3 линии
Специалист службы поддержки = Менеджер 2 линии

Или там есть какие-то подводные камни?

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

[mvasenkov]

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

В новых конфигурациях, которые я делаю, я с роли "Пользователь" начинаю. Отключаю ей все, кроме редактирования своей учетной записи. А остальное навешивается новыми ролями с также ограниченными под выполняемые функции возможностями.

[sekob]

Спасибо за ответы.

Продолжу еще по конфигурации...

Роль "Обозреватель"

По правам доступа, данная роль имеет доступ на просмотр - всего. И имеет право выполнять операции:
"Утверждение решения"
"Отклонение решения"
в рамках задачи "проблема".

Но исходя из документации:

Обозреватель
Специальная роль с доступом только на чтение данных. (Менеджер конфигураций)

Далее. В рамках задачи, например, "База знаний", роли "Клиент" присваивается роль "Обозреватель". Т.е. клиент получает доступ на просмотр всего. Не думаю, что это идеологически правильно. Не говоря уже о том, что может выполнять какие-то операции в рамках задачи "Проблема".

Ну или я не совсем понимаю эти тонкости настройки конфигурации.

[mvasenkov]

Далее. В рамках задачи, например, "База знаний", роли "Клиент" присваивается роль "Обозреватель". Т.е. клиент получает доступ на просмотр всего. Не думаю, что это идеологически правильно. Не говоря уже о том, что может выполнять какие-то операции в рамках задачи "Проблема".

Ну или я не совсем понимаю эти тонкости настройки конфигурации.

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