Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.

6170+
вопросов и ответов

25
авторов

440+
источников

100%
оригинальный контент
Основные подводные камни при проведении PIR включают: неполные данные для анализа, субъективность оценок участников, отсутствие четких измеримых критериев, игнорирование негативных результатов, недостаточное вовлечение заинтересованных сторон. Также часто возникают сложности с определением причинно-следственных связей между внедрением и наблюдаемыми результатами. Чтобы избежать этих проблем, важно заранее определить методологию оценки и обеспечить прозрачность процесса.
Правильное определение заказчика критически важно для эффективного управления ИТ-услугами, так как каждый процесс должен удовлетворять ожиданиям своего заказчика или заинтересованной стороны. Неверное определение заказчика может привести к созданию услуг, которые не соответствуют реальным потребностям бизнеса. Например, если ИТ-подразделение будет ориентироваться только на технические характеристики, не учитывая реальных потребностей конечных пользователей или непосредственных заказчиков, это приведет к снижению ценности предоставляемых услуг.
Если компания провозглашает определенные ценности, но не следует им на практике, это приводит к когнитивному диссонансу у клиентов и сотрудников. У клиентов формируется негативное впечатление и разочарование, так как ожидания, возникшие на основе заявленных ценностей, не оправдываются реальным взаимодействием. Например, когда компания заявляет, что важен каждый клиент, но опаздывает на встречи, не готовит документы и игнорирует обязательства, это создает негативный клиентский опыт. Такие ситуации могут быстро привести к потере доверия и отказу от сотрудничества, как в описанном примере, где потенциальный клиент сразу отказался от продолжения отношений из-за несоответствия заявленных ценностей и реального поведения сотрудников.
Ориентация только на формальные метрики при управлении ИТ-процессами приводит к нескольким негативным последствиям. Во-первых, некоторые данные трудно собрать, есть сомнения в их объективности или они не помогают в принятии управленческих решений. Во-вторых, может происходить замена здравого смысла набором измеримых показателей, хотя некоторые процесс не требуют измерений. В-третьих, отдельные KPI различных процессов могут не складываться в целостную систему оценки деятельности ИТ-отдела в целом, что создает фрагментарную "лоскутную" картину вместо единой системы показателей.
Недовольство вызывают избыточное количество вложенных меню, вынуждающее клиента долгое время слушать голосовые подсказки; сообщения, не учитывающие статус клиента (например, упоминание об услугах для новых клиентов, когда звонит действующий заёмщик); заверения о переводе на специалиста при отсутствии фактического соединения; повторяющиеся просьбы подтвердить выбор при нажатии клавиш; отсутствие возможности быстро связаться с живым оператором; навязчивые промо-сообщения в начале или конце звонка; угроза автоматического разрыва связи при превышении лимита ожидания без предупреждения.
Современные формы ориентации на клиента стали более цивилизованными по сравнению с девяностыми. Если раньше предприниматели вывешивали простые надписи на авто или рынках, например, «Рассмотрю любые предложения», то сегодня компании формулируют свою миссию как «наиболее качественное удовлетворение покупательского спроса». Это показывает переход от эмоционального, прямого подхода к более профессиональной и структурированной формулировке целей.
Каскад показателей — это последовательность шагов от общей цели до конкретных измеримых показателей. Он позволяет убедиться, что метрики действительно соотносятся с исходной целью, а не выбираются из соображений легкости или привычки. Каскад помогает исключить ненужные измерения и сохранить только те, что способствуют достижению целей, предотвращая ситуацию, когда отчётность не ведёт к решениям или наоборот, вредит общей задаче.
Без дорожной карты легко теряется фокус на предназначении продукта для бизнеса, что приводит к тому, что работа сводится к перемалыванию требований в бэклоге без четкой картины того, каким должен стать продукт. Это похоже на сборку мебели без инструкции: в конце концов результат будет получен, но медленно и возможно с ошибками, которые потребуют переделки. Разработка без дорожной карты может привести к перекосу в сторону оперативных задач, поскольку они наиболее понятны и часто бизнес настоятельно требует их выполнить. Также возможно отклонение в сторону долгосрочных крупных изменений, что приведет к игнорированию текущих проблем с качеством. Без среднесрочного плана сложно контролировать баланс между разными типами задач и удерживать правильное направление развития продукта, что негативно сказывается на темпе улучшения продукта, интересующем бизнес-заказчиков.
Основным препятствием для преобразования теории в практику в области межличностного взаимодействия является устойчивый шаблон поведения, выработанный в профессиональной среде. У ИТ-специалистов, в силу особенностей их деятельности, преобладает техническое мышление, что приводит к игнорированию важности уточнения деталей с клиентами. Даже при наличии знаний о правильном подходе к коммуникации с заказчиком, на практике сотрудники склонны полагать, что требования ясны без дополнительных вопросов. Это связано с психологическими особенностями профессиональной группы и типичными стереотипами мышления в технических профессиях.
CMDB помогает в поддержке изменений в ИТ-инфраструктуре, обеспечивая корректную оценку влияния планируемых изменений еще до их реализации. Зная связи между компонентами и структуру услуг, можно понять, как изменение отдельного компонента повлияет на конечную услугу. Это также помогает в планировании реализации изменений, выборе подходящих тестов, определении способа развертывания и релиза, а также выборе параметров для мониторинга во время и после изменений, что позволяет минимизировать риски и гарантировать стабильность ИТ-услуг.