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

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

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

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

Определены три основные цели процесса управления знаниями: хранить и передавать уникальные знания; сократить трудозатраты на поиск необходимой для решения задач информации; по возможности исключить «испорченный» телефон, то есть искажения информации при передаче данных.

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

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

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

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

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