PCF (Process Classification Framework) - это открытый стандарт, межотраслевая процессная модель, не привязанная к области деятельности предприятия или сектору промышленности, не зависящая от его размера и местоположения. Он представляет собой общую структуру процессов для любых предприятий, изначально задуманную для систематизации бизнес-процессов и определения общего языка. PCF позволяет идентифицировать процессы на предприятии, используя уже наработанный и накопленный опыт многих компаний; сравнивать между собой эффективность процессов, выполняющихся в разных организациях; заниматься реинжинирингом и совершенствовать процессы. Модель была разработана в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать её. Текущая версия PCF - 6.1.0 от марта 2014 года.

Ролевое управление доступом (RBAC, Role Based Access Control) — это модель предоставления доступа, при которой весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль представляет собой набор прав доступа. Пользователи получают доступ к системам и ресурсам исключительно через присвоенные им роли. Это означает, что права не закрепляются напрямую за пользователями, а устанавливаются через назначенные роли. Такая модель позволяет упростить управление доступом, особенно в крупных организациях, группируя права в логические наборы и привязывая их к должностям или функциональным обязанностям сотрудников.

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

Сервисно-ресурсная модель (СРМ) — это концепция, применяемая в управлении активами и конфигурациями, которая фокусируется на взаимосвязях между сервисами и ресурсами в организации. Она предполагает детальное описание всех компонентов системы, их отношений и роли в обеспечении конечных сервисов. Эта модель служит основой для управления изменениями, анализа воздействия и планирования инцидентов.

ABAC (Attribute-Based Access Control) — это модель управления доступом, которая использует атрибуты субъектов, объектов, среды и времени для принятия решений о доступе. В отличие от RBAC (Role-Based Access Control), где доступ определяется ролями, ABAC проверяет комплексные условия, например, должность сотрудника, стоимость заказа, филиал, время суток или IP-адрес. Основное отличие заключается в том, что ABAC позволяет создавать динамические правила, учитывающие множество контекстных факторов, тогда как RBAC ограничивается статическими наборами прав, привязанными к ролям.

Мандатная модель (MAC) предполагает жёсткую привязку пользователей и информации к уровням допуска (например, 'секретно', 'совершенно секретно'). Все ресурсы одного уровня автоматически доступны всем, у кого есть мандат на этот уровень. Основной недостаток — негибкость: добавление новых классов секретности усложняет систему. Дискреционная модель (DAC) настраивает доступ на уровне отдельных объектов и операций для каждого пользователя через матрицу разрешений (таблицы доступа). Это даёт максимальную детализацию, но требует громоздкого администрирования при росте системы. Ролевая модель (RBAC) группирует права в бизнес-роли (например, 'бухгалтер', 'менеджер'). Пользователи получают доступ через назначение ролей, а не прямое управление объектами. Это сочетает структурированность (как в MAC) и управляемость (лучше, чем в DAC), так как изменения в правах вносятся на уровне ролей, а не пользователей. RBAC также поддерживает иерархию ролей и разделение полномочий, что недоступно в других моделях.

RASCI-матрица - это расширение классической RACI-матрицы, где к стандартным ролям добавлено дополнительное значение S (Supports). Стандартные значения в RACI расшифровываются как: R (Responsible) - непосредственный исполнитель задачи, A (Accountable) - ответственный за конечный результат, C (Consulted) - те, кого нужно проконсультировать в процессе выполнения задачи, I (Informed) - те, кого нужно информировать о результатах. В RASCI добавляется S (Supports), что означает участников, которые поддерживают выполнение задачи и вносят вклад в результат, но не несут ответственности за процесс или конечный результат. Это позволяет более точно распределить роли, особенно когда в задаче участвует большое количество людей, и четко разделить тех, кто организует работу, и тех, кто просто оказывает поддержку в процессе выполнения.

Google провела исследование Project Oxygen с целью научно обосновать влияние менеджеров на эффективность работы сотрудников и всей организации. Первоначально руководство компании стремилось доказать, что менеджеры не имеют существенного влияния на результаты, что могло бы подтвердить целесообразность радикального сокращения управленческого звена. Однако исследования показали обратное: от качества работы руководителей напрямую зависят как индивидуальные достижения сотрудников, так и общий успех организации. Это открытие привело к переосмыслению роли менеджеров в компании и к созданию системы подготовки руководителей на основе выявленных ключевых компетенций.

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

Для перехода к более частым релизам необходимы следующие технические улучшения: внедрение полной автоматизации процесса сборки и развёртывания; создание достаточного количества тестовых сред для параллельной работы; увеличение покрытия кода автоматическими тестами (юнит-тесты, интеграционные тесты, end-to-end тесты); внедрение практик непрерывной интеграции для немедленного обнаружения проблем; применение принципов разработки с малыми циклами изменений (small batches); создание системы мониторинга и обратной связи для быстрой реакции на проблемы; оптимизация процесса выделения ИТ-ресурсов под различные задачи; реализация стратегии feature toggles для безопасного включения новых функций. Эти изменения позволяют минимизировать риски и увеличить надёжность процесса доставки.