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

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

## [Как понятие best practice часто искажается в практике внедрения решений?](https://cleverics.ru/digital/kb-qa/kak-ponyatie-best-practice-chasto-iskazhaetsya-v-praktike-vnedreniya-resheniy/)

Best practice в практике внедрения решений часто искажается и воспринимается как решение, которое уже однажды было применено и позволило закрыть проект, либо как рекомендация из книги, которую научились пересказывать. Такое упрощенное понимание позволяет консультантам и компаниям избегать сложной работы по адаптации решений под специфику конкретной организации. Однако истинно эффективные best practice должны быть результатом глубокого анализа и адаптированы к текущим условиям и целям компании, а не просто скопированы из других источников.

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

Рейтинг: 1329

Теги: управление проектами, PRINCE2, управление релизами

## [Что такое бизнес-роль и как она связана с системными ролями?](https://cleverics.ru/digital/kb-qa/chto-takoe-biznes-rol-i-kak-ona-svyazana-s-sistemnymi-rolyami/)

Бизнес-роль — это набор системных ролей из разных ИТ-систем, объединённых общей функцией в рамках бизнес-процесса или подразделения. Например, бизнес-роль 'Финансовый аналитик' может включать системные роли 'Пользователь модуля отчётности' (в ERP-системе) и 'Аналитик данных' (в BI-инструменте). Бизнес-роли отражают реальные задачи сотрудников, в то время как системные роли — технические права в рамках отдельных приложений. При масштабировании ролевой модели от уровня приложения до всего предприятия роль администратора управляет бизнес-ролями, которые автоматически распространяют доступ через связанные системные роли.

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

Рейтинг: 1328

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

## [Что такое 'восходящий' (upstream) этап производства в разработке ПО и как его можно улучшить?](https://cleverics.ru/digital/kb-qa/chto-takoe-voskhodyashchiy-upstream-etap-proizvodstva-v-razrabotke-po-i-kak-ego-mozhno-uluchshit/)

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

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

Рейтинг: 1326

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

## [Что такое SPOC в контексте поддержки пользователей?](https://cleverics.ru/digital/kb-qa/chto-takoe-spoc-v-kontekste-podderzhki-polzovateley/)

SPOC (Single Point of Contact) в контексте поддержки пользователей — это концепция, при которой каждому набору пользователей или ИТ-услуг назначена единая точка контакта. Эта точка может быть представлена отдельной узкоспециализированной группой, которая обеспечивает поддержку пользователей, взаимодействующих с определенными ИТ-решениями. Такой подход устраняет необходимость наличия общей централизованной службы, так как каждая специализированная группа самостоятельно выступает в роли точки контакта для своих пользователей.

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

Рейтинг: 1326

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

## [Чем SLM отличается от каталога услуг в ИТ-менеджменте?](https://cleverics.ru/digital/kb-qa/chem-slm-otlichaetsya-ot-kataloga-uslug-v-it-menedzhmente/)

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

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

Рейтинг: 1323

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

## [Как практика управления изменениями взаимодействует с другими ИТ-практиками?](https://cleverics.ru/digital/kb-qa/kak-praktika-upravleniya-izmeneniyami-vzaimodeystvuet-s-drugimi-it-praktikami/)

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

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

Рейтинг: 1321

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

## [Чем является Touch Time и почему его сложнее всего измерить?](https://cleverics.ru/digital/kb-qa/chem-yavlyaetsya-touch-time-i-pochemu-ego-slozhnee-vsego-izmerit/)

Touch Time — это сумма всех периодов времени, когда над задачей активно ведется работа, без учета времени ожидания, консультаций, перерывов и других отвлекающих факторов. Измерить его сложно, потому что в реальных условиях сотрудники редко работают над задачей без переключений: они могут участвовать в коммуникациях, оперативках, решать спонтанные проблемы, брать перерывы и т.д. Большинство систем не фиксируют точное время работы над задачей (например, по таймеру), а потому Touch Time обычно оценивается через анализ статусов задач в инструментах управления проектами, что приводит к грубым приближениям и неточностям в расчетах.

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

Рейтинг: 1319

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

## [Как определить границу доступности и недоступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-opredelit-granitsu-dostupnosti-i-nedostupnosti-it-uslug/)

Граница доступности и недоступности ИТ-услуг определяется при составлении SLA и должна быть четко документирована. Эта граница устанавливается на основе требований бизнеса и критериев, при которых услуга считается недоступной, влияя на выполнение бизнес-процессов. Обычно это выражается в определенных временных рамках (например, время простоя сервиса более 5 минут считается недоступностью) или в количественных показателях (например, отклонение времени отклика от согласованного более чем на 50%). Важно, что эта граница должна быть измеримой и понятной как для ИТ-служб, так и для бизнеса, чтобы при возникновении вопросов можно было однозначно определить, был ли факт нарушения SLA.

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

Рейтинг: 1318

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

## [Какие факторы необходимо учитывать при внедрении Kanban-метода в командную работу?](https://cleverics.ru/digital/kb-qa/kakie-faktory-neobkhodimo-uchityvat-pri-vnedrenii-kanban-metoda-v-komandnuyu-rabotu/)

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

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

Рейтинг: 1316

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

## [Как рассчитать метрику First Time Resolution (FTR) для инцидентов в разрезе рабочих групп?](https://cleverics.ru/digital/kb-qa/kak-rasschitat-metriku-first-time-resolution-ftr-dlya-intsidentov-v-razreze-rabochikh-grupp/)

Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.

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

Рейтинг: 1313

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