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

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

## [Как соотносятся процессы управления проблемами (PRB) и постоянного совершенствования (CSI) в рамках ITIL?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-protsessy-upravleniya-problemami-prb-i-postoyannogo-sovershenstvovaniya-csi-v-ramk/)

Существует два основных подхода к определению соотношения этих процессов.  1) Модель №1: CSI рассматривается как общий подход к совершенствованию, который встраивается во все области деятельности, в том числе в процесс управления проблемами. В этом случае CSI является мета-практикой или инструментом, который используется на всех этапах жизненного цикла услуги и опоясывает стратегию, проектирование, преобразование и эксплуатацию. Процесс управления проблемами, в свою очередь, использует подходы CSI для решения конкретных проблем.  2) Модель №2: Граница между CSI и PRB проходит не между различными видами деятельности, а между различными уровнями организации. В этом случае CSI представляет собой общекорпоративную практику, которая охватывает всю организацию (например, весь ИТ-департамент), в то время как процесс управления проблемами фокусируется на решении конкретных технических ошибок. При этом в большинстве организаций эти практики появляются не одновременно и имеют разный охват, что делает вопрос границы между ними актуальным только после установления жизнеспособности обеих практик.  Если рассматривать CSI как мета-практику, обеспечивающую единые подходы к управлению качеством (аналогично практике риск-анализа), то эти процессы находятся в разных плоскостях, но взаимодействуют друг с другом.

Автор: Игорь Гутник

Рейтинг: 781

Теги: ITIL, постоянное улучшение, совершенствование, CSI, PDCA, стратегия, управление проблемами, управление рисками

## [Почему в некоторых случаях целесообразно отойти от жёстких временных рамок при обработке запросов ИТ-поддержки?](https://cleverics.ru/digital/kb-qa/pochemu-v-nekotorykh-sluchayakh-tselesoobrazno-otoyti-ot-zhestkikh-vremennykh-ramok-pri-obrabotke-za/)

Жёсткие временные рамки могут мешать качественному решению задач, особенно в нестандартных ситуациях. Отсутствие фиксированного лимита позволяет сотрудникам сосредоточиться на реальном результате вместо гонки за временем. Например, если для полного решения проблемы пользователю требуется 25 минут вместо 15-минутного ориентира, это приведёт к повышению его удовлетворённости и снижению количества повторных обращений. Гибкость процессов поддерживает мотивацию сотрудников, так как они видят ценность своих действий в качестве обслуживания, а не формальном соблюдении сроков.

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

Рейтинг: 781

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

## [Как понятие опыта (experience) соотносится с разделением на полезность и гарантию в ITIL?](https://cleverics.ru/digital/kb-qa/kak-ponyatie-opyta-experience-sootnositsya-s-razdeleniem-na-poleznost-i-garantiyu-v-itil/)

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

Автор: Игорь Гутник

Рейтинг: 781

Теги: ITIL, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, управление отношениями, взаимодействие, BRM

## [Какие проблемы возникают при цифровой трансформации?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-tsifrovoy-transformatsii-upomyanutye-v-tekste/)

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

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

Рейтинг: 781

Теги: бизнес, ценность, бизнес-заказчик, трансформация, ускорение, Time-to-Market

## [В чем состоит ошибка, когда люди называют 'продажу шоколадки' услугой?](https://cleverics.ru/digital/kb-qa/v-chem-sostoit-oshibka-kogda-lyudi-nazyvayut-prodazhu-shokoladki-uslugoy/)

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

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

Рейтинг: 781

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

## [Какие преимущества дает включение оргвопросов в управление проблемами?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-vklyuchenie-orgvoprosov-v-upravlenie-problemami/)

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

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

Рейтинг: 781

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

## [Как текст описывает взаимодействие между бизнес-специалистами и ИТ-специалистами?](https://cleverics.ru/digital/kb-qa/kak-tekst-opisyvaet-vzaimodeystvie-mezhdu-biznes-spetsialistami-i-it-spetsialistami/)

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

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

Рейтинг: 781

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

## [Чем отличается управление изменениями от управления инцидентами в ИТ-сфере?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-upravlenie-izmeneniyami-ot-upravleniya-intsidentami-v-it-sfere/)

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

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

Рейтинг: 781

Теги: командная работа, поддержка пользователей, Service Desk, Help Desk, управление изменениями, управление инцидентами

## [Какие факторы привели к экспоненциальному росту инцидентов ИТ-услуг в компании?](https://cleverics.ru/digital/kb-qa/kakie-faktory-priveli-k-eksponentsialnomu-rostu-intsidentov-it-uslug-v-kompanii/)

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

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

Рейтинг: 781

Теги: командная работа, поддержка пользователей, Service Desk, Help Desk, управление инцидентами

## [Как определить заинтересованные стороны (стейкхолдеров) в контексте коммуникационного процесса?](https://cleverics.ru/digital/kb-qa/kak-opredelit-zainteresovannye-storony-steykkholderov-v-kontekste-kommunikatsionnogo-protsessa/)

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

Автор: Елена Колбей

Рейтинг: 781

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