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

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

## [Почему коммуникация между бизнесом и ИТ-отделом часто приводит к недопониманию и неэффективности?](https://cleverics.ru/digital/kb-qa/pochemu-kommunikatsiya-mezhdu-biznesom-i-it-otdelom-chasto-privodit-k-nedoponimaniyu-i-neeffektivnos/)

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

Автор: Сандра Урядова

Рейтинг: 1154

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

## [Что означают термины «полезность» (utility) и «гарантия» (warranty) в контексте услуг ITSM/ITIL?](https://cleverics.ru/digital/kb-qa/chto-oznachayut-terminy-poleznost-utility-i-garantiya-warranty-v-kontekste-uslug-itsm-itil/)

Полезность (utility) — это функциональность, предлагаемая продуктом или услугой для удовлетворения конкретной потребности. Это отвечает на вопрос «то, что услуга делает». Например, услуга может обеспечивать формирование отчетов или возможность проведения видеоконференций. Гарантия (warranty) — это гарантия того, что продукт или услуга будут соответствовать согласованным требованиям. Это отвечает на вопрос «то, как услуга предоставляется». Например, это могут быть такие параметры, как скорость формирования отчетов, максимальное количество пользователей, использующих услугу, доступность услуги и другие нефункциональные характеристики.

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

Рейтинг: 1153

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

## [Каковы основные функции сервис деска в рамках ITIL 4?](https://cleverics.ru/digital/kb-qa/kakovy-osnovnye-funktsii-servis-deska-v-ramkakh-itil-4/)

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

Автор: Игорь Фадеев

Рейтинг: 1152

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

## [Почему рекомендация ISO 20000 о расчете целевых показателей на основании приоритета вызывает сомнения?](https://cleverics.ru/digital/kb-qa/pochemu-rekomendatsiya-iso-20000-o-raschete-tselevykh-pokazateley-na-osnovanii-prioriteta-vyzyvaet-s/)

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

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

Рейтинг: 1151

Теги: ISO 20000, ITIL, бизнес, ценность, бизнес-заказчик, управление инцидентами, управление процессами, ИТ-процессы

## [Почему компаниям реального сектора экономики необходимо внедрять цифровые технологии?](https://cleverics.ru/digital/kb-qa/pochemu-kompaniyam-realnogo-sektora-ekonomiki-neobkhodimo-vnedryat-tsifrovye-tekhnologii/)

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

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

Рейтинг: 1151

Теги: экономика и финансы

## [Какие преимущества дает использование PCF для анализа и оптимизации бизнес-процессов предприятия?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-ispolzovanie-pcf-dlya-analiza-i-optimizatsii-biznes-protsessov-predpriyat/)

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

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

Рейтинг: 1151

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

## [Как определяется допустимый размер штрафных санкций при разработке SLA?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-dopustimyy-razmer-shtrafnykh-sanktsiy-pri-razrabotke-sla/)

Допустимый размер штрафных санкций при разработке Соглашений об уровне обслуживания (SLA) определяется в зависимости от типа поставщика и характера услуги. Для внешних поставщиков (Тип III) штрафы обычно составляют 20-30% от суммы контракта, но могут быть ограничены законодательством, как в случае с 44-ФЗ, где максимальный размер штрафа составляет 2,5% от суммы контракта. Для внутренних поставщиков размер штрафов, как правило, не выражается в денежном эквиваленте, а влияет на премии сотрудников. При этом важно учитывать, чтобы размер штрафов мотивировал поставщика на улучшение качества услуги, но не превышал разумные пределы, чтобы не привести к убыточности сотрудничества.

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

Рейтинг: 1151

Теги: SLA, аутсорсинг, интеграция услуг, мотивация персонала, стимулирование, постоянное улучшение, совершенствование, CSI, PDCA, управление уровнем услуг, SLM, эффективность, оптимизация

## [Что такое OLA (Operational Level Agreement) и в каких ситуациях его использование оправдано?](https://cleverics.ru/digital/kb-qa/chto-takoe-ola-operational-level-agreement-i-v-kakikh-situatsiyakh-ego-ispolzovanie-opravdano/)

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

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

Рейтинг: 1151

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

## [Как связаны между собой RTO, RPO и планы непрерывности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-svyazany-mezhdu-soboy-rto-rpo-i-plany-nepreryvnosti-it-uslug/)

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

Автор: Павел Дёмин

Рейтинг: 1150

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

## [Как определить, когда следует переходить к гибкому управлению ИТ-разработкой, а когда можно оставаться на проектном подходе?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kogda-sleduet-perekhodit-k-gibkomu-upravleniyu-it-razrabotkoy-a-kogda-mozhno-ostavatsy/)

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

Автор: Светлана Сапегина

Рейтинг: 1150

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