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

Использование сопоставимых KPI при оценке руководителей дает несколько ключевых преимуществ: возможность объективного сравнения результатов работы различных подразделений и руководителей; упрощение процесса агрегации метрик на разных уровнях управления; ясность и прозрачность системы оценки для самих руководителей и вышестоящего руководства; минимизация спорных ситуаций, связанных с интерпретацией результатов. Сопоставимые KPI, приведенные к единой шкале (от 0 до 1) и с единым направлением оценки (чем ближе к 1, тем лучше), позволяют комбинировать результаты из разных процессов и строить итоговый рейтинг руководителя. Это способствует более целостному восприятию эффективности руководителя и помогает выявить сильные и слабые стороны его управления. Кроме того, сопоставимые метрики облегчают мониторинг прогресса во времени и сравнение с целевыми значениями.

Автоматизированные метрики эффективны для количественных показателей, где данные генерируются системой без участия человека (например, время обработки запроса). Ручные методы необходимы для оценки качественных аспектов, которые сложно формализовать (например, корректность классификации или удовлетворенность клиента). Граница определяется балансом между затратами на автоматизацию и ценностью получаемой информации. Если стоимость внедрения автоматизации превышает выгоду от точного измерения метрики, предпочтение отдается ручным методам.

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

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

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

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

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

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

Принципиальный компромисс в ITSM заключается в исключении из области охвата управления уровнями ИТ-услуг вопросов разработки новой функциональности информационных систем. Этот подход предполагает разделение зон ответственности: Application lifecycle management (ALM) используется для разработки, а IT service management (ITSM) — для эксплуатации и сопровождения систем. Такой компромисс позволяет сосредоточиться на поддержании существующих услуг и их доступности, не беря на себя обязательства по гарантии сроков и качества новых разработок.