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

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) имеют несколько преимуществ перед классическим подходом. Они позволяют: 1) Более точно оценить влияние доступности ИТ-услуг на конкретные бизнес-процессы; 2) Учесть специфику разных видов бизнеса - для некоторых критичны долгие простои, для других частые кратковременные; 3) Принимать обоснованные решения по повышению надежности систем с учетом реального бизнес-влияния; 4) Создать более прозрачные SLA с учетом особенностей воздействия простоев на бизнес; 5) Лучше оценить успешность мероприятий по повышению надежности на основе их реального влияния на бизнес-процессы.

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

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

В разделе «о чем просим / что требуем» должно быть четко и конкретно указано действие, которое требуется от получателя. Примеры формулировок: «Прошу Вас содействовать / довести до сведения персонала / назначить ответственных / согласовать расходы на…», «Инициировать проект не позднее …», «Начать работы с …». Если вы что-то требуете, важно ссылаться на соответствующее основание из предыдущего раздела (например, приказ или решения встречи), которое подтверждает ваши полномочия в постановке таких требований. Также желательно указать конкретные сроки выполнения задачи. Четкое формулирование запроса и наличие ссылок на нормативные документы или решения значительно увеличивают вероятность получения нужного ответа в требуемые сроки.

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

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

Операционный стандарт — это документ, фиксирующий уровень предоставления определённой технической услуги в рамках ИТ-инфраструктуры в целом. Например, «Операционный стандарт. Сети и каналы передачи данных», «Операционный стандарт. СУБД», «Операционный стандарт. СХД» и другие. Эти стандарты описывают параметры услуги: доступность, технологические перерывы, время восстановления, поддержку, ограничения, ответственных лиц и т.д.

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

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