В редакцию портала поступил вопрос:
Добрый день!
Заказчик присылает большое количество пользователей для заведения в системе. Завести всех пользователей за раз не представляется возможным (специфика системы), поэтому возникают вопросы:
1) Можно ли на всех пользователей сразу завести одну заявку в Service Deck, или необходимо заводить отдельную заявку на каждого пользователя?
2) Что об этой ситуации говорит ITIL?
Нет, не шутка, в этой рубрике публикуются вопросы, которые нам задают читатели в разделе “Задать вопрос”
https://realitsm.ru/ask-us/
В каком контексте он размещен? Варианты:
Нужно реально помочь человеку;
Есть такая известная проблема;
Обсудить корректность вопроса и его стиль;
Частые вопросы;
Уточните, пожалуйста.
Вопрос реален. Пользователи добавляются в систему VipNet, заявки на подключение пользователей представляют собой согласованные руководством заказчика заявления в формате PDF. Какого либо реестра со списком всех пользователей, которых необходимо добавить нет. Обращение по поводу заведения пользователей представляет собой архив с файлами PDF, следовательно использовать какой либо скрипт и автоматизировать процесс заведения пользователей не представляется возможным, необходимо заводить каждого пользователя вручную. Заявка на изменение в данном случае некорректна, ибо нет никакого изменения в системе. Самым верным в данном случае будет использовать запрос на обслуживание. Но возникает вопрос, заводить ли по каждому пользователю отдельную заявку(упрощает процесс контроля кол-ва пользователей, дает четкую картину по принятым заявкам на заведение пользователей и кол-ву заведенных пользователей), либо завести одну завку на всех(что будет быстрее, но тяжелее будет проконтролировать каждого пользователя)
Ильгизар Талипов автор вопроса ответил вам на портале. Посмотрите, пожалуйста,
https://realitsm.ru/2017/04/dobavlenie-novyx-polzovatelej-v-sistemu-odna-zayavka-na-vsex-ili-na-kazhdogo/
Попробуем разобраться
Заявка переведена в статус решено. Если в течении 48 часов она не будет возобновлена, то произойдет автоматиский перевод в статус закрыто ))
Ильгизар Талипов спасибо за помощь в поиске решения!
VipNet это Ваша единственная информационная система? Видимо существует некая основная система, в которой заведены, работают все или большая часть пользователей.
VipNet – единственная система, которую обслуживает Наша организация. Заказчик также использует AD, но к нему у нас нет доступа. На самом деле, основной вопрос заключается не в том, как автоматизировать и максимально быстро завести в систему n-ое кол-во пользователей, а как правильно с точки зрения ITIL будет заводить заявку, на всех одну или на каждого пользователя по заявке. Пытался найти своими силами в разных редакциях ITIL ответ на этот вопрос, но не смог, поэтому решил обратиться на форум к более знающим людям.
Если для случая когда автоматизация невозможна, то не вижу проблемы в создании одной заявки, но с конкретным списком и предоставлением всех необходимых данных. Формулировка "Завести всех" конечно неприемлема.
О каком порядке, количестве пользователей и о каком из продуктов VipNet идет речь?
Более 150 пользователей, ключи выпускаются для ViPNet Client для рабочих станций.
Иногда, при необольшом количестве пользователей, выполнить "тупую" работу по ручному составлению и ведению списков бывает быстрее и дешевле, чем выстраивать ее автоматизацию. Здесь каждый решает сам. Везде есть + и –
Владимир, это решается технически, настройкой периодического импорта записей пользователй из AD. Это реализуется с помощью ViPNet Registration Point (Пункт Регистрации)
Ручное ведение – каменный век, с проблемами постоянного отслеживания ротации пользователей. Поэтому решение вижу в проведении изменения в системах с целью настройки интеграции с AD. Что вполне соответствует рекомендациям ITIL.
Благодарю за информацию!
Дополню, с вашего позволения.
Задача изначально звучала иначе, и по сути то своей, к ITIL имеет отношение посредственное. Тут скорее от целей надо отталкиваться, и от здравого смысла.
Я вижу решение в двух параллельных плоскостях:
1. Учёт таких заявок.
Владимир, "Заказчик" у заявки один, поэтому мне кажется, имеет смысл делать именно одну заявку. Сколько при этом пользователей вы завели – не важно. Ну только если у вас нет обязательств каких-то, каждому из заведённых пользователей слать какие-то оповещения, из вашей же ITSM-тулы (что вряд ли), Цель "регистрировать обращения и контролировать их жизненный цикл" решена.
2. Учёт заведённых пользователей.
Один из вариантов привёл выше Ильгизар. Уверен, найдутся и другие, начиная от простого ведения реестра заведённых пользователей в .xls и заканчивая какой-то сквозной интеграцией (при условии что Заказчик даст все необходимые доступы и интерфейсы).
Опять же, отталкиваемся от целей. Если у вас контракт подразумевает $ за каждого заведённого пользователя, вам очень нужен такой реестр, причём свой, "независимый" от данных Заказчика. В иных случаях – он тоже нужен, но уже с точки зрения контроля выполненных работ и отслеживания конфигураций, во имя истории и облегчения дальнейшего траблшутинга.
Если у вас работают процессы Управления изменениями и конфигурациями, "загоните" этот реестр под их охват. Если нет – тоже не беда. Сам файлик-реестр может быть Конфигурационной Единицей, даже если нет формальных CFG и CHG процессов. При этом не важно, оформлено ли это как заявка на обслуживание или на изменение. И то и другое в жизни может повлечь за собой изменение "CMDB", и та и другая могут содержать этап воркфлоу "обновить данные в CMDB", без которого она не может считаться выполненной/закрытой.
Всё имхо, слова – из ITIL, принципы – из жизни.
Мы решали данную задачу (а дело касается не только заведения пользователей, но и массовой установке рабочих мест) следующим образом, ввели ограничения на количество записей в заявке, но не с точки зрения разбиения на количество заявок, а с точки зрения классификации запроса. Т.е. если в заявке до 10 рабочих мест – это Запрос на обслуживание с соответствующим временем на обработку, если более – стандартный запрос на изменение, который временем изначально не обременён.
Благодарю за комментарии, ответы и способы решения!
Здесь нужно отталкиваться от SLA, если по услуге заведения пользователя существует регламент, который определяет, что в одном обращении неоьходимо указывать только одного пользователя, то ответ очевиден. Если же количество заводимых в одной заявке пользователей не определено, то количество указанных в заявке заводимых пользователей может любым. В другой стороны, для второго случая должно быть определено время для заведения одной учетной записи, а в системе Service Desk должна быть возможность увеличивать автоматически проставленный крайний срок согласно количеству учетных записей.
Самый полезный, на мой взгляд, комментарий…
Это реальный вопрос или шутка? Он выглядит запутанным или как плохой перевод с другого языка. Для вразумительного ответа требуется много уточнений по имеющейся инфраструктуре, специфике. В принципе это возможно, одной заявкой на изменение.