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

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

## [Какой метод агрегирования более подходит для системы, где все метрики критически важны?](https://cleverics.ru/digital/kb-qa/kakoy-metod-agregirovaniya-bolee-podkhodit-dlya-sistemy-gde-vse-metriki-kriticheski-vazhny/)

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

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

Рейтинг: 1343

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

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

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

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

Рейтинг: 1342

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

## [Что может произойти, если компания теряет лицо в конфликтной ситуации?](https://cleverics.ru/digital/kb-qa/chto-mozhet-proizoyti-esli-kompaniya-teryaet-litso-v-konfliktnoy-situatsii/)

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

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

Рейтинг: 1342

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

## [Какое практическое применение может иметь предложенная метрика в ИТ-управлении?](https://cleverics.ru/digital/kb-qa/kakoe-prakticheskoe-primenenie-mozhet-imet-predlozhennaya-metrika-v-it-upravlenii/)

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

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

Рейтинг: 1342

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

## [Может ли первая линия ИТ-поддержки решать все обращения, и если нет, то почему?](https://cleverics.ru/digital/kb-qa/mozhet-li-pervaya-liniya-it-podderzhki-reshat-vse-obrashcheniya-i-esli-net-to-pochemu/)

Превращение первой линии ИТ-поддержки в структуру, которая решает 99,9% всех обращений, на практике редко является оптимальным решением и может фактически перестать быть «первой линией» в традиционном понимании. Это связано с несколькими причинами: необходимостью наличия глубоких и разнообразных технических знаний у сотрудников первой линии, что делает их квалификацию и стоимость существенно выше; вероятностью возникновения сложных, нестандартных проблем, требующих специфических знаний и опыта; риском снижения качества решения сложных задач из-за расширения спектра обязанностей сотрудников; экономической нецелесообразностью использования высококвалифицированных (и более дорогих) специалистов для решения самых простых проблем. В идеале, первая линия должна решать тот объем обращений, который соответствует ее квалификации и позволяет эффективно использовать ресурсы разных уровней поддержки.

Автор: Анна Васильева

Рейтинг: 1342

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

## [Какие преимущества имеет модель RBAC перед другими моделями управления доступом?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-imeet-model-rbac-pered-drugimi-modelyami-upravleniya-dostupom/)

Модель RBAC имеет ряд преимуществ перед другими моделями управления доступом, такими как DAC (Discretionary Access Control) и MAC (Mandatory Access Control). Во-первых, RBAC обеспечивает более высокую масштабируемость, что особенно важно для организаций с большим количеством сотрудников. Во-вторых, она повышает прозрачность управления доступом, так как права привязаны к ролям, соответствующим должностям и бизнес-процессам. В-третьих, RBAC обеспечивает легкость администрирования - добавление или удаление пользователей не требует перенастройки всего механизма доступа, достаточно назначить или отозвать соответствующую роль. Также RBAC позволяет лучше соблюдать принцип разделения обязанностей, что повышает информационную безопасность организации.

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

Рейтинг: 1341

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

## [Как интерпретировать значение метрики KPI группы поддержки в диапазоне от 0 до 1?](https://cleverics.ru/digital/kb-qa/kak-interpretirovat-znachenie-metriki-kpi-gruppy-podderzhki-v-diapazone-ot-0-do-1/)

Значение метрики KPI группы интерпретируется следующим образом: 1 – идеальный результат, все инциденты, в которых участвовала группа, решены в срок; 0 – наихудший результат, все инциденты с участием группы нарушены по срокам и вся ответственность за просрочку лежит именно на этой группе. Промежуточные значения отражают долю инцидентов, своевременно обработанных группой, и степень её ответственности за нарушения сроков. Такой подход позволяет легко установить целевые показатели и использовать метрику для оценки эффективности работы поддержки.

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

Рейтинг: 1340

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

## [Как можно минимизировать конфликты при распределении ИТ-ресурсов между бизнес-подразделениями?](https://cleverics.ru/digital/kb-qa/kak-mozhno-minimizirovat-konflikty-pri-raspredelenii-it-resursov-mezhdu-biznes-podrazdeleniyami/)

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

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

Рейтинг: 1339

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

## [Какие культурные особенности в команде могут мешать внедрению системы учёта трудозатрат?](https://cleverics.ru/digital/kb-qa/kakie-kulturnye-osobennosti-v-komande-mogut-meshat-vnedreniyu-sistemy-ucheta-trudozatrat/)

Культурные барьеры включают сопротивление сотрудникам из-за недоверия к целям учёта (например, восприятие его как инструмента контроля), нежелание тратить время на фиксацию, традиции завышения данных для создания видимости загруженности и установки 'все заняты на 100%'. Например, практика округления времени до 15 минут или игнорирование параллельных задач искажает данные, что делает систему неэффективной. Преодоление требует объяснения пользы учёта для оптимизации процессов, а не наказания.

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

Рейтинг: 1339

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

## [Что такое co-creation в контексте разработки продукта и почему это важно?](https://cleverics.ru/digital/kb-qa/chto-takoe-co-creation-v-kontekste-razrabotki-produkta-i-pochemu-eto-vazhno/)

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

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

Рейтинг: 1339

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