Портал №1 по управлению цифровыми
и информационными технологиями

Записки с полей:Типовые заявки

За последние пару месяцев несколько раз столкнулся в разных организациях с непреодолимым желанием ИТ-специалистов упростить жизнь пользователям в части оформления типовых заявок на выполнение работ из разряда "предоставьте рабочее место", "дайте права", "отберите права" и т.д. Обычно такие заявки оформляются в виде служебных записок, длинных форм в Word или Excel и тому подобного.

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

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

Регистрация

Заявки должны подаваться пользователями в электронном виде. Желательно, чтобы пользователь мог подать заявку на портале самообслуживания с использованием специализированной формы. Формы должны отличаться в зависимости от типа заявки: предоставление нового рабочего места и предоставление прав требуют получения от пользователя различных подробностей. На формах должен выполняться контроль вносимых значений (обязательность и корректность с применение максимально возможного количества справочников). Регистрация усложняется, когда принимается решение, что в одной заявке пользователь может запросить несколько однотипных операций, например, запросить доступ к разным ресурсам. При этом в заявке должна быть возможность перечисления списка пользователей, например, когда руководитель запрашивает доступ для своих сотрудников, он подает одну заявку со списком сотрудников. Желательно разводить понятия "заявитель", "пользователь" и "контактное лицо", т.к. тот ,кто подает заявку, может делать это не в своих интересах, а с вопросами по заявке надо обращаться к третьему человеку.

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

Согласование

Заявка может проходить несколько этапов согласования, например, сначала непосредственный руководитель пользователя, затем ответственный за запрошенный ресурс,  далее служба безопасности. Маршрут согласования зависит от типа заявки, а в некоторых случаях – еще и от региона, в котором находится пользователь, и значений полей с формы заявки. Возможны повторные согласования по заявке. Если пользователем запрошено несколько ресурсов, то на этапе согласования может быть не согласован доступ к одному из ресурсов. При этом дальнейшая реализация выполняется только по согласованным ресурсам. Заявитель должен информироваться о результатах согласования. Возможны вопросы к заявителю по ходу согласования.

Реализация

Так как заявки типовые, то и состав работ по каждому типу заявки должен быть предопределен, в некоторых случаях можно также зафиксировать сроки выполнения, как заявки в целом, так и шагов, которые необходимо предпринять для выполнения заявки. Выполнение должно осуществляться только тех работ, которые прошли согласование. В ряде случаев по окочании отдельных работ необходимо уведомлять заявителя и/или контактное лицо и/или пользователя, например, если речь идет о предоставлении доступа к системам, когда выполнение отдельной работы самоценно, и сотруднику необходимо узнать об этом как можно скорее, не дожидаясь окончания обработки всей заявки.

Проверка и закрытие

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

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 3

  • Alexey Yusov

    Основная "грабля" – это заставить клиентов эти самые типовые заявки на портале регистрировать. При правильной автоматизации такое решение существенно снижает нагрузку на 1-ую линию и позволяет гибко процесс обработки за счет формализации запроса.

    Но если клиенты не готовы к этому, то это проблема. Они же понимают спинным мозгом (верхним или нижним утолщением – у кого как), что на них перекладывают работу по категоризации запроса.

    Варианта решения, как обычно, два:

    1. Кнут – распоряжение по компании (это для случая с  внутренним ИТ), что типовые заявки принимаются только с портала. Баста!

    2. Пряник – для заявки с портала можно повысить приоритет.

    Особенно тяжело эта "типизация" идет в слаборазвитых (с точки зрения регламентации деятельности и вообще порядка) компаниях. Т.е. почти всегда :-).

    • Довольно хорошо работает кнут в форме пряника. Т.к. обычно такие заявки содержат в себе довольно много информации, которую надо сообщить для выполнения работы, то наличие форм (неважно в виде бумажных бланков, шаблонов в ворде или портала) помогает пользователю не забыть, а значит не переделывать работу по подаче заявки 5 раз, прежде чем он получит требуемое.

      Соответственно, я с Вами согласен, что без кнута не обойтись, но его можно преподнести в виде облегчения жизни самим пользователям. Если конечно действительно удалось обеспечить облегчающую реализацию.

      • Alexey Yusov

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

        В качестве бумеранга можно получить сокращение штата HRов и ИТшников тоже, т.к. затраты на создание(для первых) и обработку (для вторых) запросов уменьшаются. Для них – грустно, для бизнеса полезно.

        Издержки автоматизации. Ничего не попишешь.


Добавить комментарий для Alexey YusovОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM