FTR (First Time Resolution) — это показатель, представляющий долю инцидентов, решенных с первого раза без необходимости переделок или доработок. Снижение FTR негативно влияет на процесс управления инцидентами,因为它 указывает на то, что решения не проходят достаточной проверки или не полностью устраняют проблему, что приводит к необходимости повторного рассмотрения инцидентов. Это увеличивает нагрузку на службу поддержки, снижает рациональность процесса, ухудшает показатели эффективности и может негативно сказываться на удовлетворенности клиентов.

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

Роль лидера трансформируется от лидера-менеджера к лидеру-партнеру по мере развития команды. На уровне «Детский сад» лидера должен быть директивным, активно организовывать процессы, решать текущие проблемы и постепенно вовлекать команду, расширяя границы самостоятельности. На уровне «Пубертат» лидер выступает как посредник, помогающий в конструктивном взаимодействии и гашении конфликтов, «продавая» решения вместо директивного управления. На уровне «Яркая молодость» лидер становится «мотором-метрономом», поддерживающим скорость и ритмичность работы, востребован в роли лидера-слуги на 100%. На высшей стадии «Зрелость» лидера-слуги заменяет лидер-партнер, наделенный полномочиями для поддержки инициатив на высоких уровнях, обладающий достаточной осведомленностью и авторитетом для интеграции целей команды с целями компании.

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

Incident Rate позволяет прогнозировать объем обращений пользователей в ИТ-службу, используя текущее количество пользователей системы. Умножив ожидаемое число пользователей на средний показатель Incident Rate (например, 0.8–1.2), можно рассчитать примерное количество инцидентов за месяц и спланировать необходимые ресурсы, такие как количество сотрудников в службе поддержки или объём автоматизации процессов управления инцидентами.

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

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

PCF (Process Classification Framework) - это открытый стандарт, межотраслевая процессная модель, не привязанная к области деятельности предприятия или сектору промышленности, не зависящая от его размера и местоположения. Он представляет собой общую структуру процессов для любых предприятий, изначально задуманную для систематизации бизнес-процессов и определения общего языка. PCF позволяет идентифицировать процессы на предприятии, используя уже наработанный и накопленный опыт многих компаний; сравнивать между собой эффективность процессов, выполняющихся в разных организациях; заниматься реинжинирингом и совершенствовать процессы. Модель была разработана в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать её. Текущая версия PCF - 6.1.0 от марта 2014 года.

Успешность реализации сервисного мышления в организации можно оценить через ответы на вопросы, структурированные по 7 принципам ITIL: 1) Фокус на ценности — получает ли клиент желаемую ценность? 2) Начало с текущего состояния — учитывается ли контекст и предыдущий опыт? 3) Постепенное развитие с обратной связью — есть ли система сбора и использования обратной связи? 4) Сотрудничество и видимость — прозрачны ли процессы и ясно ли распределены роли? 5) Целостный подход — учитывается ли связь услуг с целями клиента? 6) Простота и практичность — насколько хорош пользовательский опыт? 7) Оптимизация и автоматизация — идут ли постоянные улучшения процессов? Положительные ответы на эти вопросы свидетельствуют об успешной реализации сервисного мышления.

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