Выбор агентов/клиентов в ITSMChange

[anya.rar]

Доброго времени суток.
При создании изменений и назначения ответственных лиц (например, выбираем ChangeManager, ChangeBuilder, CAB и т.п.) выходит список лиц, которые можно добавить. Но! в комитет по изменениям (CAB) можно включить и клиентов. У нас есть агенты и клиенты с одинаковыми логинами. Как их отличить в приведенном списке? подозреваю, что дело в волшебных цифрах рядом с именами. что они означают?

[anya.rar]

Попутно хотелось бы всё же спросить про функциональную значимость ChangeManage(-ра).

(Из теории:
Itsm-change – группа доступа к модулю ITSM для управления процессом изменений. Доступ только для чтения. Все агенты, кто участвует в процессе изменений должны быть в этой группе.

Itsm-change-builder – группа доступа к модулю ITSM для управления процессом изменений. Доступ для создания и изменения своих «Изменений» и нарядов. Все, кто создает изменения, должен быть в этой группе.

Itsm-change-manager – группа доступа к модулю ITSM для управления процессом изменений. Полный доступ. Менеджер может создавать изменения или менять изменения, созданные другими агентами из группы itsm-change-builder.)

Т.е. ChangeBuilder - инициатор изменения. Он его (измнение) создает и должен руководить процессом. Правильно ли полагать, что ChangeManage(-ра) необходимо назначать (или он сам назначит себя на какое-либо созданное изменение), когда изменение контролирует кто-то ещё (например, руководство)?

[ykolesnikov]

Добрый день!
В OTRS еще руки не дошли до ChangeManagement, но исходя из теории, менеджеров изменений не должно быть много, хотя это зависит от бизнеса и величины компании. Функции менеджера изменений достаточно разрисованы в книге "Поддержка услуг" одной из немногих на русском языке (стр.225-227 - я думаю номера страниц актуальны, т.к. везде выложена скан-копия книги).
Но это теория. В реальной жизни так работают только в очень крупных компаниях и банках ответственно относящихся к своей ИТ-инфраструктуре. Редко кто может себе позволить выделенных менеджеров изменений. Тем не менее, не имеет смысла любого инициатора изменений делать его менеджером. Все-таки, RFC - это не такой мощный поток, как поток инцидентов. Кроме того, использование этого процесса нельзя превращать в самоцель и создавать RFC для любого мелкого изменения.
Можно иметь, скажем 2 сотрудника в должности начальника\зам.начальника отдела - по одному, ответственному за изменения в ПО, второго в технической инфраструктуре. Конечно, все это условно, это может быть и один квалифицированный и эрудированный сотрудник службы эксплуатации, наделенный правами и желательно, обладающий авторитетом (не по должности).
Боюсь, что не ответил на Ваш вопрос, поскольку раз копаете в этом направлении, значит уже и сами во многом разобрались.

[anya.rar]

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

По цифрам...Может кому на будущее будет надо. Это порядковые номера агентов, занесенных в систему ОТРС. По клиентам - отображаются не номера, а указывается в скобках их логин.

[yuri0001]

Добрый вечер!
Если отвлечься от OTRS и его конкретных понятий, на мой взгляд - менеджер изменений это по почти тоже самое что и проект-менеджер, ведь проведение конкретного изменения это тоже мини-проект. Здесь просто надо решить какого рода изменения проводить через этот процесс. Установка дополнительной планки памяти в системный блок пользователя, формально - изменение. Но этому изменению не нужен менеджер и комитет по изменениям тоже. Внесение дополнений в функционал программного комлекса - это изменение уже достойное работы менеджера. Оно требует обсуждения постановки задачи, согласование с заказчиком, программирование, тестирование, анализ и одобрение\неодобрение результатов, принятие решения о переносе в среду эксплуатации, оформление документации и новых инструкций и т.д. И контролировать все эти этапы по последовательности и срокам должен один человек - менеджер изменений. Я не претендую на истину, возможно, где-то неправ.

[alexus]

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