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

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

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

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

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

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

Такой подход создаёт ощущение безопасности за счёт формального выполнения аудиторских запросов, но игнорирует реальные уязвимости: сотрудник может иметь доступы, несоответствующие его текущей должности, а ручная обработка изменений приводит к задержкам в отмене прав после увольнения. Например, данные для аудита могут быть актуальными на момент проверки, но в промежутках между аудитами система скапливает критические несоответствия, что увеличивает риск утечки данных или злоупотребления правами.

Типичный диапазон значения Incident Rate составляет от 0.8 до 1.2 инцидентов в месяц на одного пользователя. Крайние случаи могут достигать 0.4–2.3, но чаще всего величина находится в пределах 0.3–2.0. Для сравнения, совокупное количество всех обращений пользователей (включая сервисные запросы и инциденты) колеблется от 1 до 2 в месяц на одного пользователя.

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

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