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

Бренд CleverKPI предлагает несколько продуктов и услуг: бесплатные ресурсы (заметки на портале Real ITSM, статьи на сайте Cleverics, вебинары CleverTALK), книгу о методике измерения в ИТ за 500 рублей, авторский учебный курс за 29 500 рублей, экспресс-диагностику состояния управления ИТ в организации от 360 000 рублей, консалтинговые услуги для улучшения системы управления по KPI с индивидуальной стоимостью, а также преднастроенное программное обеспечение для измерения ИТ с помощью современных инструментов.

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

В ITIL проблема — это причина или потенциальная причина одного или нескольких инцидентов, тогда как инцидент — это сам факт незапланированного прерывания услуги. Пример: если пользователь не может распечатать документ (инцидент), то проблемой может быть конфликт драйвера сетевого принтера с диспетчером печати Windows, который привел к этому инциденту. Проблема требует анализа для выявления корневой причины, чтобы предотвратить повторение инцидентов.

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

Решение проблем часто требует внедрения изменений в инфраструктуру или ПО, поэтому процессы тесно связаны. После выявления корневой причины создаётся запрос на изменение (RFC), который проходит стандартные этапы оценки и утверждения. Ключевая роль управления проблемами — чётко определить необходимость изменения, а управления изменениями — безопасно его осуществить. Неотъемлемая часть процесса — обратная связь: фиксация в KEDB успешности внедрённого решения и его влияния на снижение инцидентов.

Неправильное распределение задач приводит к ряду негативных последствий: руководитель становится перегруженным рутинной работой, теряет контроль над стратегическими вопросами, снижается эффективность всей команды. В примере с деловой игрой Apollo-13 менеджер инцидентов, ставший маршрутизатором заявок, не смог обеспечить необходимый контроль за выполнением задач, в результате решено только 44% инцидентов, а среднее время решения увеличилось почти вдвое по сравнению с установленными SLA. Также может возникнуть хаос, потеря заявок и замедление работ, когда руководитель постоянно вмешивается в задачи сотрудников.

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

После того как команда смогла достичь стабильной частоты релизов раз в две недели вместо запланированных еженедельных, существуют четыре основных сценария: 1) Согласиться с текущим положением как улучшением по сравнению с прошлым и продолжать пассивно пытаться улучшить ситуацию, но не предпринимая активных действий. 2) Продолжать активно работать над улучшением процесса, выявляя корневые причины и применяя изменения. 3) Зафиксировать текущую частоту как новую норму и планировать дополнительные внеплановые релизы. 4) Установить амбициозную цель ежедневных релизов, используя принципы DevOps и идя на радикальные изменения в процессах.

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