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

Гибридная модель (RBAC + ABAC) превосходит чистый RBAC гибкостью и точностью. RBAC ограничен статическими ролями, тогда как добавление ABAC позволяет учитывать контекст (время, местоположение, свойства объекта). Например, менеджер с ролью «Редактор заказов» может редактировать заказы только в своём филиале и при соблюдении лимита стоимости. Это снижает риски избыточных прав и повышает соответствие политикам безопасности.

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

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

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

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

Для успешного внедрения системы измерений необходимо: объяснить команде практическую пользу и цели измерений, провести обучение по правильному использованию инструментов и интерпретации данных, внедрять метрики постепенно, начиная с простых и понятных показателей, обеспечить обратную связь от команды при выборе метрик, связать измерения с целями и интересами команды, а не только с контролем. Важно демонстрировать быстрые результаты, чтобы доказать ценность системы измерений.

Адаптация ITIL-процессов под специфику компании основывается на принципах гибкости и ориентации на бизнес-ценность. Сначала определите ключевые бизнес-процессы компании и ИТ-услуги, которые их поддерживают. Выберите элементы ITIL, которые напрямую влияют на эти услуги и процессы. Проведите анализ текущих практик в компании и выявите, что уже работает хорошо и может быть сохранено. Сфокусируйтесь на результатах, а не на процессах - задавайте вопрос: 'Какой бизнес-результат должен быть достигнут этим процессом?' Упростите процессы до необходимого уровня сложности, исходя из размера компании, сложности ИТ-инфраструктуры и бизнес-требований. Для небольших организаций допустимо объединение ролей и упрощение документации. Для регулируемых отраслей увеличьте внимание к аудиту и отчетности. Создайте гибридные процессы, комбинируя элементы ITIL с существующими практиками компании. Проведите пилотное внедрение адаптированных процессов в одной области, оцените результаты и только потом масштабируйте. Обратите внимание, что ITIL - это не жесткий стандарт, а набор рекомендаций, которые должны быть интерпретированы в контексте конкретной организации. Основное правило - процесс должен создавать ценность для бизнеса, а не существовать ради формального соответствия.

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

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