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

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

Опубликовано 26 февраля 2014
Рубрики: Обо всём на свете
Комментарии

Позвольте о наболевшем. Кто из вас не сталкивался с согласованиями? Мне они последнее время попадаются на каждом шагу:approved

  • Согласования заявок на доступ
  • Согласования ресурсов на выполнение работ
  • Согласования времени выключения оборудования
  • Согласования SLA
  • Согласования схем согласования

И ладно бы, если бы они были простыми. А то ведь, что ни согласование, то цепочки:

  • Руководитель сотрудника

     

     

    • Владельцы запрошенных/затрагиваемых ресурсов

       

       

      • Служба безопасности

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

Хорошо, если все участники согласования из ИТ, но ведь попадаются и люди из "бизнеса", а им зачастую "ИТ не указ", поэтому оговаривать сроки согласования можно, но практически бесполезно.

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

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

Думаю, что зря до сих пор нет единого источника знаний по правильной организации согласований. Или есть и я просто не знаю?

75989.strip

ОБУЧЕНИЕ
Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Также по теме:

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

  • Nargiza Suleymanova

    У нас было так:

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

    2. Задержек было предостаточно, но посмотреть на ком конкретно зависла заявка на согласовании можно было всегда посмотреть. Те, кому было совсем срочно, сами "пинали" задерживающего.

    3. У меня конкретно был всегда назначенный ИО и ДЛ, поскольку невозможно было за всем успеть: объемы иногда зашкаливали.

  • Grigory Kornilov

    Вели ли вы статистику апрувов\отказов и делали ли выводы на ее основании вместе с заказчиком?

    Например можно отказаться от некоторых согласований со стороны "непосредственного руководителя" ибо

    1. За бюджет, который расходуется для обеспечения данного запроса, он не отвечает.

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

     

     

    • Андрей

      Поспорю. В заметке приведена типовая процедура согласования:

      Руководитель сотрудника – он определяет реальную потребность ЕГО сотрудника в запрашиваем ресурсе для исполнения сотрудником его бизнес задач. Утрированно – руководитель решает, действительно ли бухгалтеру необходим Autocad для подготовки бухгалтерского отчета.

      Владельцы запрошенных/затрагиваемых ресурсов – он фактически выполняет capacity managemet. Он определяет, а есть ли возможность (необходимость определяет руководитель) выделить запрашиваемый ресурс. Утрированно – сотрудник удаленного филиала просит online доступ к системе, при этом между офисами нет прямого канала. Или свободных лицензий уже нет.

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

  • Андрей

    ТЕХНОЛОГИЯ. Она необходима для того, чтобы гарантированно получить требуемый результат при различных условиях. В данном конкретном случае (процессы согласования) в качестве технологии мы применяем различные BPM (Business Process Management) или WF (Work Flow management) системы. Для перечисленных ситуаций есть варианты решения:

    1. Нарушены сроки. Либо система автоматически после заданного срока выставляет признак "согласованно" с полной ответственностью согласуещего за это решение, либо идёт автоматическое оповещение (эскалация) вышестоящего начальника (тоже дисциплинирует исполнителей).

    2. Конкретный согласующий при постоянно меняющемся штате. Тут потребуется переход на ролевую модель исполнения процессов. Сам процесс описывается на основе ролей, а при запуске экземпляра процесса из сситем HR или AM выбирается конкретный носитель роли на данный момент.

  • Михаил

    В своей практике при формировании каталогов очень часто сталкивался с маршрутами согласования “Руководитель сотрудника – Владелец ресурса – ИБ”. Менеджеры услуг в ИТ с маниакальной настойчивость воспроизводят такую схему по самым различным запросам. При этом в некоторых случаях мне удавалось оптимизировать схемы согласования. Например, руководитель сотрудника якобы должен подтвердить необходимость предоставления доступа или выполнения какой-либо работы со стороны ИТ конкретно для его сотрудника. Однако в зрелых организациях разработаны и поддерживаются в актуальном состоянии ролевые модели, которые определяют перечень ресурсов и доступов, которые должен быть предоставлени сотруднику. По сути организация задает корпоративную политику, которая позволяет исключить необходимость постоянно принятия решения (согласования) руководителем. Безусловно требуется приложить определенные усилия и воля для ведения подобной ролевой модели, а также предварительная оценка экономического эффекта от ее разработки: превысит ли снижение затрат от задержек согласования по сравнению с затратами на разработку ролевой модели.

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

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

Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.