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

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

Да, кратное ускорение возможно без смены персонала, включая программистов, аналитиков, тимлидов и руководителей. Ключевым является фокус на изменении системных аспектов работы, а не на замене людей. Необходимо сосредоточиться на четырёх направлениях: перестроить организацию ресурсов от иерархии к более самостоятельным командам; провести архитектурные изменения для поддержки быстрого цикла разработки; наладить приоритизацию входящих задач с фокусом на бизнес-ценные инициативы; внедрить систему организации производства с управлением потоком создания ценности и ограничениями на текущую работу. Пример деловой игры 'Проект Феникс' показывает, что те же люди, изменив подход к работе, могут ускориться в 15-25 раз без изменения состава команды.

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

При индивидуальном обслуживании вместо использования формальных количественных показателей можно напрямую оценивать удовлетворенность заказчика через регулярные опросы, поскольку услуги адаптируются под конкретного потребителя. Это позволяет учитывать субъективное восприятие качества и не ограничиваться только параметрами, зафиксированными в SLA. В отличие от массового производства, где основное внимание уделяется количественным показателям и стандартизации, при индивидуальном подходе можно учитывать как гарантийные показатели (warranty), так и полезность услуги (utility) с позиции конкретного заказчика.

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

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

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

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

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