Role-Based Access Control (RBAC) - это подход к управлению доступом, основанный на назначении пользователей ролям. RBAC состоит из четырех основных компонентов: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро - это обязательный компонент, который определяет минимально необходимый набор элементов (пользователи, роли, права доступа, операции и объекты) и связей для построения системы управления доступом. Оно реализует основную идею RBAC - объединение прав доступа в роли и последующее назначение ролей пользователям вместо прямого назначения прав доступа. Иерархичность добавляет возможности наследования прав между ролями. Статическое и динамическое разделение обязанностей вводят правила ограничений на назначение и совмещение ролей.

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

Лидерство-служение (servant leadership) - это подход к руководству, при котором лидер ставит команду на первый план, создавая условия для максимальной реализации потенциала членов команды. Лидер-слуга фокусируется на потребностях других членов команды больше, чем на собственных. Он признает интересы других людей, предоставляет необходимую поддержку для выполнения работы и достижения целей, вовлекает в процесс принятия решений, где это нужно, и формирует чувство общности внутри команды. Концепция была описана Робертом Гринлифом в 1970 году в эссе «Слуга как лидер» и противоречила тогдашним представлениям о менеджменте.

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

Для определения нагрузки на ИТ-системы с помощью среднего чека сначала вычисляется количество сделок, необходимых для достижения плана продаж. Допустим, план продаж составляет 1440 млн рублей при среднем чеке в 10 тысяч рублей. Это означает, что в месяц нужно совершить около 12 000 сделок. Затем, учитывая выработку одного продавца (например, 20 сделок в день), можно определить количество пользователей, которые одновременно будут работать в ИТ-системах. Эта информация позволяет спрогнозировать поток запросов к ИТ-системам и объем обращений в сервисные службы поддержки, что критически важно для правильного планирования ИТ-инфраструктуры и поддержания ее высокой производительности.

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

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

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

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

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