В редакцию портала поступил вопрос:
Коллеги, доброго дня. Неожиданный вопрос: куда растворился Access management в ITIL4? В практике Request Mgmt есть упоминание о том, что запросы на доступ управляются в практике Security Mgmt, но в описании этой практики нет об этом ничего, кроме управления инцидентами безопасности и аудита и ревью. Есть легкий намек, что эта практика используется в access control.
Процесс управления доступ — лишняя сущность (причём, некоторые эксперты считали [и делали!] так и во времена ITILv3).
Как построить решения любых задач изменения прав доступа (включая выдачу и отъём)? Нужно организовать некоторую последовательность действий. В этой последовательности в зависимости от решаемой задачи может много шагов, много согласований, много изменений или нет.
Если это простые задачи, то их решение может быть описано моделями выполнения соответствующих запросов на обслуживание (service requests).
Если это какие-то сложные истории, то может быть описан поток создания ценности (value stream), в рамках которого может производиться много всего. Вполне возможно, что потребуется вовлечение какой-то части практики управления безопасностью и любых других (например, change enablement, service level management, architecture management, finance management etc)
Если проанализировать процесс, выстроенный «в соответствии с рекомендациями ITILv3» в реальной организации, то мы увидим, что это и есть частный случай потока создания ценности, как он описан в ITIL4.
Если же, наоборот, мы не увидим той гибкости, которая предполагается вышеописанной конструкцией, то либо охват данного процесса довольно узок (только типовые задачи), либо мы должны обнаружить какое-то количество моделей, каждая из которых описывает, как (очень по-разному) работает этот «процесс» в зависимости от того, какая задача пришла на вход.
Общий рецепт ответов на подобные вопросы мне видится таким. Не стоит искать соответствие между библиотеками (это интересное и небесполезное упражнение, но для другого). Нужно 1. понять, какую задачу мы решаем (вряд ли выстраивание процесса — это самоцель; и уж тем более маловероятно, что целью является поиск нового называния для чего уже имеющегося [«как в ITIL4 называется вот эта штука, которую консультанты построили нам, ссылаясь на ITILv3?»]). 2. Разобраться с инструментарием (например, ITIL4) 3. Используя инструментарий, построить то, что будет решать нашу задачу (п.1).
Получившийся конструкт может отличаться от того, к чему мы привыкли (поскольку набор элементов, из которых мы его собирали, отличается).