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

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

## [Как организовать Service Desk при ограниченном количестве ИТ-специалистов?](https://cleverics.ru/digital/kb-qa/kak-organizovat-service-desk-pri-ogranichennom-kolichestve-it-spetsialistov/)

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

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

Рейтинг: 1346

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

## [Что представляют собой стандартные изменения согласно ITIL?](https://cleverics.ru/digital/kb-qa/chto-predstavlyayut-soboy-standartnye-izmeneniya-soglasno-itil/)

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

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

Рейтинг: 1346

Теги: ITIL, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление запросами на обслуживание, управление изменениями, управление рисками

## [Как определить, что является дефектом, а что - частью функциональности?](https://cleverics.ru/digital/kb-qa/kak-opredelit-chto-yavlyaetsya-defektom-a-chto-chastyu-funktsionalnosti/)

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

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

Рейтинг: 1346

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

## [Какие типичные ошибки допускают компании при масштабировании своего сервиса через партнерские программы?](https://cleverics.ru/digital/kb-qa/kakie-tipichnye-oshibki-dopuskayut-kompanii-pri-masshtabirovanii-svoego-servisa-cherez-partnerskie-p/)

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

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

Рейтинг: 1345

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

## [Как правильно применять статус «Срочно» в деловом письме?](https://cleverics.ru/digital/kb-qa/kak-pravilno-primenyat-status-srochno-v-delovom-pisme/)

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

Автор: Андрей Носов

Рейтинг: 1345

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

## [Какой принципиальный компромисс применяется в ITSM для управления уровнем ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakoy-printsipialnyy-kompromiss-primenyaetsya-v-itsm-dlya-upravleniya-urovnem-it-uslug/)

Принципиальный компромисс в ITSM заключается в исключении из области охвата управления уровнями ИТ-услуг вопросов разработки новой функциональности информационных систем. Этот подход предполагает разделение зон ответственности: Application lifecycle management (ALM) используется для разработки, а IT service management (ITSM) — для эксплуатации и сопровождения систем. Такой компромисс позволяет сосредоточиться на поддержании существующих услуг и их доступности, не беря на себя обязательства по гарантии сроков и качества новых разработок.

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

Рейтинг: 1344

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

## [Какие преимущества имеет предложенная метрика перед традиционными подходами к измерению эффективности управления инцидентами в ITSM?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-imeet-predlozhennaya-metrika-pered-traditsionnymi-podkhodami-k-izmereniyu-effe/)

Предложенная метрика имеет несколько ключевых преимуществ: 1) Справедливо распределяет ответственность за нарушение сроков между всеми участвующими группами, а не возлагает её на одну 'последнюю' группу. 2) Создает правильные мотивации, стимулируя группы обрабатывать инциденты даже при получении их близко к окончанию срока. 3) Является чувствительной к реальному участию группы в решении инцидента, а не только к её месту в цепочке обработки. 4) Обеспечивает естественное масштабирование от уровня отдельной группы до уровня всего процесса управления инцидентами. 5) Легко адаптируется для учёта степени превышения срока. 6) Помогает избежать негативных практик, таких как 'футбол' инцидентов между группами.

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

Рейтинг: 1344

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

## [Почему важно учитывать возвраты на доработку индивидуально по группам при расчёте FTR?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-uchityvat-vozvraty-na-dorabotku-individualno-po-gruppam-pri-raschete-ftr/)

Учёт возвратов на доработку индивидуально по группам необходим, потому что если учитывать их на уровне всего обращения (инцидента), это может привести к неверным результатам. Например, если после возврата на доработку в группу А инцидент был переназначен в группу В, которая решила его с первого раза, то при уровне всего инцидента возврат снизит метрику не только группы А, но и группы В, хотя вина за возврат лежит только на первой группе. Также одно обращение может быть возвращено несколько раз в разные группы, и при общем учёте результаты расчёта будут искажены.

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

Рейтинг: 1344

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

## [Какие механизмы можно использовать для управления инцидентами, требующими доработки ПО от внешних подрядчиков?](https://cleverics.ru/digital/kb-qa/kakie-mekhanizmy-mozhno-ispolzovat-dlya-upravleniya-intsidentami-trebuyushchimi-dorabotki-po-ot-vnes/)

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

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

Рейтинг: 1344

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

## [Почему первая линия поддержки считается ключевой для качества ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-pervaya-liniya-podderzhki-schitaetsya-klyuchevoy-dlya-kachestva-it-uslug/)

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

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

Рейтинг: 1343

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