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

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

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

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

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

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

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

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

Уровень защищенности системы напрямую влияет на вероятность того, что угроза приведет к наступлению нежелательного события. Чем выше уровень защищенности, тем ниже уязвимость системы к конкретным угрозам и, соответственно, ниже вероятность реализации риска. Например, даже при высокой вероятности возникновения определенной угрозы (например, DDoS-атаки), хорошо защищенная система с правильно настроенными защитными механизмами может предотвратить наступление нежелательного события. Таким образом, повышение уровня защищенности является одним из ключевых способов снижения общего уровня рисков в организации.

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