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

Эволюционный подход к внедрению канбана заключается в постепенном введении изменений, а не в радикальной перестройке существующих процессов. Вместо того чтобы сразу полностью менять систему работы, команды начинают с визуализации текущих процессов и затем постепенно вносят улучшения, основываясь на наблюдениях и анализе возникающих проблем. Этот подход позволяет найти и устранить узкие места, установить ограничения на количество задач в работе (WIP), улучшить поток работы и создать вытягивающую систему, где новые задачи берутся на выполнение только когда есть свободные ресурсы. Эволюционный подход делает внедрение канбана более плавным и менее болезненным для команды.

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

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

Контроль и измерения в процессах необходимы для обеспечения их стабильности и эффективности. Без измерений невозможно оценить, насколько процесс достигает поставленных целей. Контроль позволяет выявлять отклонения, понимать причины сбоев и вносить корректировки. Измерения предоставляют объективные данные для анализа, помогают в постановке задач, установке KPI и создании системы мотивации. Отсутствие контроля и измерений неизбежно приведет к снижению качества, невыполнению задач и потере прозрачности работы.

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

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

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

Учёт участия нескольких групп поддержки в обработке одного инцидента реализован через пропорциональное распределение ответственности за нарушение срока. Для каждого инцидента, в обработке которого участвовала группа, рассчитывается доля времени (ti/Ti), которое группа потратила на его обработку. Эта доля учитывается при определении степени ответственности группы за просрочку. Если инцидент просрочен, то штрафное значение для KPI распределяется между всеми участвовавшими группами пропорционально их доле в общем времени обработки (ti/Ti). Таким образом, чем больше группа «задержала» инцидент, тем более значительным будет снижение её KPI.

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