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

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

Эффективная работа с поставщиками услуг в рамках ITIL строится на четком определении ожиданий и метрик успеха. Сначала создайте каталог услуг, описывающий все услуги, предоставляемые как внутренними, так и внешними поставщиками, с четкими SLA и OLAs. Тщательно проработайте договоры с поставщиками, включив в них измеримые KPI и последствия за их невыполнение. Установите регулярные встречи с ключевыми поставщиками (не реже раза в месяц) для обсуждения выполнения SLA, выявления проблем и планирования улучшений. Создайте единую систему управления инцидентами, которая включает как внутренние, так и внешние поставщики, чтобы обеспечить сквозное отслеживание проблем. Внедрите процесс управления поставщиками (Supplier Management), который включает оценку, выбор, управление отношениями и выход из отношений. Обеспечьте прозрачность затрат поставщиков через регулярные финансовые отчеты и анализ стоимости услуг. Для критически важных поставщиков создайте совместные планы непрерывности бизнеса. Проводите регулярные аудиты поставщиков для проверки соответствия требованиям безопасности и качества. Внедрите систему оценки поставщиков на основе их вклада в бизнес-результаты компании, а не только технических показателей.

Примеры успешного фокуса на результатах: магазин, внедривший ИИ-аналитику (выход), который смог составлять персонализированные предложения и увеличить средний чек на 17% (результат); компания Ford, заменившая KPI 'количество строк кода' на 'снижение времени сборки авто', что повысило эффективность ИТ на 200%; внедрение чат-бота, приведшее к сокращению затрат на поддержку на 500 000 рублей в год и повышению удовлетворенности клиентов. Во всех случаях внимание было сфокусировано на конечных бизнес-результатах, а не только на технических показателях.

Важно устанавливать четкие временные рамки для CI/CD конвейера, чтобы избежать неопределенных ситуаций и иметь объективный критерий эффективности работы. Например, если установлено, что конвейер должен доставлять изменения до продуктивной среды не дольше чем за 15 минут, это создает четкий ориентир для оценки его работы. Такая конкретика не оставляет места для расплывчатых формулировок вроде 'как бы работает, но не очень' или 'вчера был, сегодня нет'. Четкие временные рамки помогают команде понимать, соответствует ли система требованиям и когда требуется вмешательство. Это также способствует дисциплине и ответственности внутри команды, так как все понимают, что конвейер должен работать стабильно и быстро, без компромиссов.

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

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

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

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

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