# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

## [Как выявить и использовать стереотипы клиентов (Юг) для улучшения ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-vyyavit-i-ispolzovat-stereotipy-klientov-yug-dlya-uluchsheniya-it-uslug/)

Чтобы выявить и использовать стереотипы клиентов (Юг) для улучшения ИТ-услуг, следует: 1) Провести исследования и собрать информацию о существующих установках клиентов посредством опросов, интервью и анализа обратной связи. Например, для ИТ-поддержки стереотипом может быть мнение, что служба медленно реагирует на запросы. 2) Определить, какие из этих стереотипов негативны и влияют на восприятие услуги. 3) Разработать специальные мероприятия для разрушения негативных стереотипов: например, внедрить систему отслеживания времени ответа и гарантировать ответ в течение 15 минут. 4) Создать коммуникацию, демонстрирующую клиентам, что негативные стереотипы не соответствуют реальности вашей услуги. Например, сообщать клиентам при обращении в поддержку: "Спасибо за обращение, ваш запрос будет обработан в течение 15 минут". 5) Регулярно измерять, как изменяются восприятие и стереотипы после внедрения изменений. Это позволит целенаправленно улучшать восприятие вашей ИТ-услуги.

Автор: Артём Мукосеев

Рейтинг: 910

Теги: бизнес, ценность, бизнес-заказчик, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление запросами на обслуживание, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление релизами, эффективность, оптимизация

## [Какие подходы помогают минимизировать технический долг в процессе разработки?](https://cleverics.ru/digital/kb-qa/kakie-podkhody-pomogayut-minimizirovat-tekhnicheskiy-dolg-v-protsesse-razrabotki/)

Минимизация технического долга достигается за счёт применения методологии Test-Driven Development (TDD), постоянного рефакторинга кода, внедрения сквозного автоматизированного тестирования и регулярного контроля качества. Также важно поддерживать баланс между скоростью разработки и стабильностью системы, выделяя время на устранение уязвимостей и улучшение архитектуры. Раннее выявление и исправление проблем помогает избежать накопления долгосрочных рисков и упрощает дальнейшее развитие продукта.

Автор: Андрей Труфанов

Рейтинг: 910

Теги: архитектура ИТ, TOGAF и IT4IT, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, управление продуктами, продуктовый подход, управление релизами, управление рисками, эффективность, оптимизация

## [Как правильно организовать работу, чтобы избежать постоянной смены приоритетов?](https://cleverics.ru/digital/kb-qa/kak-pravilno-organizovat-rabotu-chtoby-izbezhat-postoyannoy-smeny-prioritetov/)

Чтобы избежать постоянной смены приоритетов, работу следует организовывать иначе. Необходимо работать с небольшими порциями задач, так как чем меньше средний размер задачи, тем ниже вероятность попасть в ситуацию, когда потребуется смена приоритетов. Следует отказаться от менять приоритеты задач и проектов, к которым уже приступили - такой инструмент управления должен быть исключен. Можно организовать работу четко, ритмично и предсказуемо, зная среднюю скорость работы потока задач. Если проект становится нежизнеспособным, лучше разрешить ему 'умереть', а не отнимать ресурсы у других проектов. Важно не пытаться решать проблемы через 'революции' и 'цифровые трансформации' в условиях уже существующего хаоса, а сначала создать устойчивую основу управления. Главный принцип: при рассмотрении смены приоритета следует фокусироваться не на том, что поднимается вверх, а на том, что остальное будет автоматически сдвинуто вниз.

Автор: Олег Скрынник

Рейтинг: 910

Теги: Канбан, WIP-лимиты, трансформация, ускорение, Time-to-Market, управление проектами, PRINCE2, управление процессами, ИТ-процессы

## [Какие последствия имеет включение дублей в расчет метрики продуктивности](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-vklyuchenie-dubley-v-raschet-metriki-produktivnosti/)

Если дубли включать в расчет метрики продуктивности, это может привести к двойственным последствиям: KPI может необоснованно увеличиться (если дубли учитываются как выполненные задачи) или случайно снизиться (из-за ошибок регистрации). Улучшенная версия метрики исключает дубли и другие проблемы из группы 'в' из расчета полностью, чтобы такие разовые ошибки не влияли на показатель эффективности, обеспечивая более точную оценку реальной работы.

Автор: Дмитрий Исайченко

Рейтинг: 910

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, эффективность, оптимизация

## [Как предложенная метрика учитывает как закрытие старых проблем, так и регистрацию новых?](https://cleverics.ru/digital/kb-qa/kak-predlozhennaya-metrika-uchityvaet-kak-zakrytie-starykh-problem-tak-i-registratsiyu-novykh/)

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

Автор: Дмитрий Исайченко

Рейтинг: 910

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление проблемами

## [Как связаны управление проблемами и значительные инциденты?](https://cleverics.ru/digital/kb-qa/kak-svyazany-upravlenie-problemami-i-znachitelnye-intsidenty/)

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

Автор: Роман Журавлёв

Рейтинг: 910

Теги: ITIL, управление инцидентами, управление конфигурациями, CMDB, управление проблемами

## [Какие потенциальные последствия могут быть от чрезмерного ужесточения требований к пунктуальности в транспортной сфере?](https://cleverics.ru/digital/kb-qa/kakie-potentsialnye-posledstviya-mogut-byt-ot-chrezmernogo-uzhestocheniya-trebovaniy-k-punktualnosti/)

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

Автор: Андрей Труфанов

Рейтинг: 910

Теги: управление рисками

## [Что подразумевается под 'специфическими затратами и рисками' в определении услуги?](https://cleverics.ru/digital/kb-qa/chto-podrazumevaetsya-pod-spetsificheskimi-zatratami-i-riskami-v-opredelenii-uslugi/)

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

Автор: Константин Нарыжный

Рейтинг: 909

Теги: аллокация затрат, расчёт себестоимости услуг, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, управление инцидентами, управление рисками, экономика и финансы

## [Какие два типа сроков необходимо выделять для управления инцидентами?](https://cleverics.ru/digital/kb-qa/kakie-dva-tipa-srokov-neobkhodimo-vydelyat-dlya-upravleniya-intsidentami/)

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

Автор: Евгений Шилов

Рейтинг: 909

Теги: SLA, бизнес, ценность, бизнес-заказчик, управление инцидентами, управление уровнем услуг, SLM

## [Какие различия существуют между 'человеком процесса' и 'человеком результата'?](https://cleverics.ru/digital/kb-qa/kakie-razlichiya-sushchestvuyut-mezhdu-chelovekom-protsessa-i-chelovekom-rezultata/)

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

Автор: Денис Денисов

Рейтинг: 909

Теги: поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление проектами, PRINCE2