Есть несколько вариантов отображения задач с необходимостью переделки на канбан-доске. 1) Оставить задачу в текущем состоянии (напр., на этапе тестирования) с пометкой "блокер" для привлечения внимания к необходимости переделки. Сигнал о блокере обрабатывается на ежедневных собраниях. 2) Вернуть задачу на этап, где требуется переделка с явной отметкой возврата для анализа системы. В этом случае нарушается плавное течение потока и возникают сложности с WIP-лимитами. 3) Оставить основную задачу на месте, создать дочернюю задачу на переделку и отправить её на соответствующий этап. Такой вариант сочетает преимущества и недостатки первых двух подходов, но добавляет сложность контроля связи между задачами. Д. Андерсон и Т. Божева считают, что передача дочерней задачи вместе с родительской характерна для более высоких уровней зрелости канбан-системы (4-й или 5-й уровень).

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

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

Основные элементы системы управления ИТ-услугами включают: людей, процессы, технологии и организацию. Люди выполняют работу и делают возможным достижение результатов. Процессы как совместно управляемые виды деятельности организуют работу людей для обеспечения стабильного и воспроизводимого результата. Технологии (инструменты автоматизации) обеспечивают функционирование процессов. Организация служит дополнительным элементом, который помогает структурировать систему в целом. Эта модель была расширена на основе подхода Business Model for Information Security (BMIS) от ISACA, добавляющего к традиционной троице четвёртый элемент — «Организация».

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

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

В IT примером Output может быть разработанное приложение или программный продукт, запущенный в эксплуатацию. Outcome — это удовлетворение потребности клиента за счёт использования этого приложения: например, повышение производительности или упрощение рабочих процессов. Если клиент не использует приложение, несмотря на его техническую готовность (output), то желаемый outcome не достигнут, и необходимо пересмотреть сам продукт.

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

Для преодоления низкой отзывчивости клиентов рекомендуется упростить процессы сбора обратной связи: сократить длину форм, сделать их мобильными, добавить элементы gamification (например, розыгрыши призов). Также важно персонализировать запросы, обращаясь к клиенту по имени и указывая, как его отзыв поможет улучшить услугу. Критически важно, чтобы ответы на отзывы были видимыми — клиент должен видеть, что его мнение влияет на изменения. Это повышает вероятность дальнейшего участия и переводит взаимодействие из «Мертвой зоны» в более активные сценарии.

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