Рефакторинг кода может не привести к ожидаемому результату из-за недостаточного понимания задачи исполнителем и эффекта Даннинга-Крюгера. В тексте приводится пример, когда команда обсудила план рефакторинга, но через месяц выяснилось, что исполнитель просто переносил проблему в другой слой системы, вместо того чтобы решать её. Это произошло потому, что человек не осознавал своей недостаточной компетентности в вопросе рефакторинга, считая, что его действия приведут к улучшению кода. Автор отмечает, что такой случай не уникален: «каждый человек понимает «в меру своей испорченности», переоценивает свои умения, не понимая истинной глубины своей некомпетентности». Поэтому важно не только обсудить план, но и обеспечить постоянный контроль и коммуникацию в процессе выполнения задачи.

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

«Палочная система» — это ситуация, когда показатели и метрики, используемые для оценки и мотивации, на самом деле стимулируют поведение, противоположное изначальным целям. Проблема состоит в том, что измеряемые показатели формально соответствуют критерию измеримости («M»), но не являются релевантными («R»). Например, показатель может поощрять сотрудников действовать в свою пользу, игнорируя долгосрочные задачи организации.

Согласно рекомендациям ITIL, правильная обработка жалоб заказчиков включает несколько важных принципов. Необходимо создать формальный процесс по обработке жалоб, так как жалобы неизбежны. Никакую жалобу нельзя оставлять без внимания – на каждую жалобу должен быть подготовлен ответ. Жалоба всегда является сигналом о явной или скрытой проблеме и должна быть идентифицирована и проанализирована. В ITIL выделяют основания для регистрации жалоб, типы жалоб и правила их обработки. BRM на этапе Service Operation отвечает за управление этим процессом, убеждаясь, что каждая жалоба получает надлежащее внимание и решение, что в свою очередь помогает выявить проблемы и улучшить качество предоставляемых услуг.

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

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

Используемая ITSM-система существенно влияет на решение о разделении процессов. Многие современные ITSM-продукты, такие как HP SM или BMC Remedy ITSM Suite, реализуют строгое разделение инцидентов и сервисных запросов как разные объекты с разными возможностями обработки, что стимулирует организации следовать этой практике. Если система не поддерживает гибкой переклассификации обращений, это может усилить проблемы, связанные с нечеткими границами между типами запросов. Некоторые системы, как HP OpenView Service Desk, предлагают альтернативные подходы к разделению (например, по источнику запроса), что может оказаться более практичным. Поэтому решение о разделении процессов должно учитывать как практические потребности организации, так и возможности используемого инструментария.

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

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

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