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

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

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

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

В формуле First Time Resolution (FTR) при расчёте в разрезе рабочих групп используются два основных операнда: Nj и Sj. Sj представляет собой количество объектов, возвращённых на доработку в j-тую группу. Nj — это количество обращений, полностью обработанных j-той группой, включая как закрытые без рекламаций обращения (Cj), так и возвраты на доработку (Sj). Таким образом, Nj = Cj + Sj, где Cj — количество обращений, закрытых без рекламаций. Расчёт выполняется за период, когда завершена проверка решения, а не само решение задачи.

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

При полном аутсорсе базовой инфраструктуры, включая IaaS и SaaS, команде необходимо сохранить компетенции в области конфигурирования и настройки middleware, управления конфигурациями через системы контроля версий и автоматизации процессов CI/CD. Кроме того, важно сохранить экспертизу в анализе и настройке потоков данных, безопасности и мониторинга работы приложения. Даже если инфраструктура предоставляется третьей стороной, команда должна уметь правильно настраивать и адаптировать middleware к специфическим потребностям продукта, что требует высокого уровня технической компетенции. Особенно важно удерживать в руках управление конфигурациями, чтобы иметь возможность быстро менять и перестраивать инфраструктуру без прямого вмешательства в запущенные узлы.

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

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

Cj и Sj связаны между собой через операнд Nj, который определяется как сумма этих величин: Nj = Cj + Sj. Здесь Cj — количество обращений, обработанных j-той группой и закрытых без рекламаций, а Sj — количество возвратов на доработку в эту группу. Эти два показателя вместе формируют полную картину обработанных обращений, участвующих в расчёте метрики First Time Resolution (FTR), и позволяют корректно отразить качество работы группы.