none
Разработка усложненной формы заявки Установка\Удаление ПО RRS feed

  • Вопрос

  • Прошу помощи в реализации задуманной концепции.

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

    ----------------------------------------------------------------------------------------------------

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

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

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

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

    Тут собираюсь использовать сортировку по полю "Категория классификации", не понимаю как менять значение в поле автоматически после создания инцидента (запроса на обслуживание) в зависимости от выбранного ПО.

    3. Если выбрано ПО, требующее разрешения на установку, то такой инцидент (запрос на обслуживание) должен сперва попасть к "рецензенту" для согласования, после чего попасть к специалисту.

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

    4. Предоставить пользователю выбор - Установить или Удалить выбранное ПО

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

    6. Все введенные пользователем данные, необходимые для работы специалиста, будут собраны в поле "Описание" из всех источников (связанные данные, расширения класса). Вопрос об этом нюансе я поднял в другом месте:

    http://social.technet.microsoft.com/Forums/ru-RU/7d57df79-8d95-4822-90bd-12b209bb324f/-

    пока реализовать не удалось.

    ----------------------------------------------------------------------------------------------------

    Мой уровень scsm2012 базовый, мне очень поможет, по возможности, пояснение на примере.



    • Изменено Zhenya Ieropolskiy 18 августа 2013 г. 23:38 корректировка текста
    18 августа 2013 г. 23:36

Все ответы

  • Вы описали вполне реализуемый сценарий. А в чём, собственно, вам помочь? Вы бы написали вопрос или что не получается реализовать из описанного? Какие шаги были предприняты. И т. п.

    19 августа 2013 г. 6:46
  • Основная проблема в разбиении пользовательской заявки на работы специалистов, т.е. в пункте 1. Пытался реализовать через параллельные действия в "Действиях" запроса на обслуживание. Но в таком случае у меня должно быть строго фиксированное количество действий, а мне необходимо что бы количество создаваемых запросов на обслуживание варьировалось в зависимости от кол-ва выбранного ПО, и при этом еще и сортировалось по очередям в зависимости от принадлежности ПО тому или иному подразделению. Хотя в этом случае не было бы проблемы с переносом в новые рабочие действия введенных пользователем значений (раб. телефон, имя пользователя и т.д.), т.к. это присвоилось бы соответствующим полям в процессе настройки сопоставления при создании предложения запроса.

    Далее попытался реализовать задачу через рабочий процесс в Authoring Tools. Настроил триггер при создании процесса чтобы мой процесс запускался сразу при появлении запроса на обслуживание с определенным значением в поле "Область". Далее, по идее, необходимо поставить цикл, создающий n-ное кол-во запросов на обслуживание и расставляющий в их полях "Описание" по одному значению из указанных ПО, а так же переносящий прочие пользовательские данные и изменяющий значение в поле "Область" для сортировки по очередям. Подобная настройка вызвала неразрешимое затруднение. Кроме того, как мне показалось, Authoring Tools позволяет в рабочем процессе работать только с инцидентами (т.к. это единственный предлагаемый инструмент).

    20 августа 2013 г. 5:10
  • Разделите мухи и котлеты. Очереди и доступы отдельно, рабочие процессы и действия отдельно.

    Общая модель:

    Создайте в Оркестраторе (устанавливается отдельно от SCSM) формирующий ранбук, который будет выполнять всё нужное: определять входные данные, разбивать их, создавать вложенные ручные активности внутри заданной параллельной, формировать описания этих действий и т. д. Получится что-то вроде:

    Создайте в SCSM шаблон для созданного Ранбука.

    Создайте вышеизображенный шаблон запроса на обслуживание. В шаблон заложите созданный шаблон Ранбука (ранбук может быть и не один). За ранбуклм заложите Параллельное действие, которое будет наполняться Ручными при помощи Ранбука.

    Потом можно и очереди с доступами настраивать.

    Такая вот модель. Но для её реализации потребуется Оркестратор, SMLets и Powershell.

    Всё вышесказанное верно, если вы хотите процесс формирования запроса автоматизировать.

    Наверно, это можно реализовать и в Авторинг Туле, без Оркестратора. Но это будет сравнимо поездке за хлебом на бульдозере.

    22 августа 2013 г. 7:06
  • Подход к решению понятен. Смущает содержимое Вашего ранбука. Дело в том, что после установки оркестратора, я не нашел в нем таких иконок как в Вашем ранбуке. Кроме первого и последнего.

    Поясните какая у Вас стоит версия и, если это возможно, покажите на примере 2012. У меня оркестратор 2012.

    26 августа 2013 г. 2:47
  • Это пакеты интеграции для Оркестратора. Скачиваются и устанавливаются отдельно.


    • Изменено Dismantled 26 августа 2013 г. 6:43
    26 августа 2013 г. 6:41
  • п.1 Во-первых, в рамках одного RO невозможно разделить его на несколько Service Request. Для разделения задач есть действия. Или делать сам RO из нескольких более мелких. Соответственно, п.1 отпадает сразу.

    п.2 Создавайте несколько (можно параллельных) действий в рамках одного запроса на обслуживание. Логику можно обеспечить как PowerShell+рабочие процессы, так и Orchestrator.

    п.3 Сделайте дополнительно поле в объекте ПО, что-то типа "Требует утверждения", и по его значению пропускайте или нет действия утверждения. Опять же - PowerShell+рабочие процессы или Orchestrator.

    п.4 Собственно, в чем проблема? Список или "флажок" на портале.

    п.5 Так и есть, прям "из коробки"

    п.6 Там и обсудим )


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    3 сентября 2013 г. 9:52
    Модератор