BRM (Business Relationship Management) принципиально отличается от менеджера по продажам своей основной целью и фокусом деятельности. Основная цель BRM – построение и поддержание долгосрочных партнерских отношений с заказчиком, ориентированных не на продажи и прибыль сервис-провайдера, а на ценность и удовлетворенность заказчика. BRM выступает в роли «голоса заказчика» внутри сервис-провайдера, передавая понимание бизнес-задач и ожиданий заказчика. В отличие от менеджера по продажам, BRM не фокусируется на заключении сделок и достижении краткосрочных финансовых целей. Предостережение в тексте гласит, что неаккуратное сочетание задач BRM с sales и pre-sale активностями может быстро выхолостить понятие business relationships, так как истинные business relationships не про продажи, а про партнерство с заказчиком.

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

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

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

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

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

Для измерения Outcome используются методы, учитывающие субъективное восприятие клиента: опросы удовлетворённости, интервью, метрики NPS (Net Promoter Score), анализ поведения пользователей, изучение бизнес-результатов клиента (например, рост продаж после внедрения ИТ-решения). Важно сочетать количественные и качественные подходы, чтобы получить полную картину.

Нужно провести анализ причин: 1) Проверить реалистичность SLA — возможно, показатель недоопределён (например, не учтены внешние факторы вроде сбоев у провайдера). 2) Оценить критичность услуги — если она не влияет на ключевые процессы, можно снизить требования. 3) Выделить ресурсы на устранение проблемы, если услуга важна. Если низкое значение объективно (например, регулярные небольшие сбои в legacy-системе), стоит рассмотреть миграцию на современное решение. В отчётности можно временно исключить такую услугу из обобщённого показателя с пояснением, но только после согласования с бизнесом.

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

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