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

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

## [Какие типичные подходы используются при первоначальном внедрении процесса управления уровнями обслуживания (SLM)?](https://cleverics.ru/digital/kb-qa/kakie-tipichnye-podkhody-ispolzuyutsya-pri-pervonachalnom-vnedrenii-protsessa-upravleniya-urovnyami/)

При первоначальном внедрении процесса управления уровнями обслуживания (SLM) обычно используются следующие типичные подходы: - Запуск процесса не на всех услугах, а только на наиболее критичных, где существует большая потребность и лучшее понимание со стороны бизнеса. - Проведение предварительной оценки необходимости внедрения SLM, так как этот процесс управления не требуется или не обоснован для всех организаций (в отличие от процесса поддержки пользователей). - Начало с хорошо понятных и уже проработанных бизнес-требований, таких как требования к резервному копированию и восстановлению данных. - Проведение аудита текущих "как есть" (as is) процедур и определение требований, если они были зафиксированы ранее. - Постепенное расширение покрытия процессами управления уровнями обслуживания, начиная с конкретных и понятных областей. Эти подходы помогают снизить сопротивление бизнеса и увеличить шансы успешного внедрения процесса SLM.

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

Рейтинг: 817

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

## [В чем заключается траектория "Заряженная пружина" в контексте работы агента изменений?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-traektoriya-zaryazhennaya-pruzhina-v-kontekste-raboty-agenta-izmeneniy/)

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

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

Рейтинг: 817

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

## [Почему автор статьи считает, что громкие формулировки миссий могут вызывать скептицизм у сотрудников?](https://cleverics.ru/digital/kb-qa/pochemu-avtor-stati-schitaet-chto-gromkie-formulirovki-missiy-mogut-vyzyvat-skeptitsizm-u-sotrudniko/)

Автор статьи считает, что громкие формулировки миссий могут вызывать скептицизм у сотрудников, потому что на практике реальная работа часто не соответствует грандиозным декларациям компании. Например, миссия Asana, которая «помогает человечеству процветать», кажется преувеличенной, если продукт компании представляет собой всего лишь менеджер задач. Когда слова не подкреплены реальными делами и достижениями, сотрудники начинают воспринимать подобные заявления как «высокопарную муть». Люди, наученные опытом и критическим мышлением, быстро научатся игнорировать такие формулировки. Таким образом, если компания стремится использовать миссию для мотивации сотрудников, важно, чтобы эта миссия была реалистичной и подкрепленной конкретными действиями.

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

Рейтинг: 817

Теги: мотивация персонала, стимулирование, общие вопросы менеджмента, управление продуктами, продуктовый подход

## [Какие компоненты качества решения инцидента необходимо контролировать?](https://cleverics.ru/digital/kb-qa/kakie-komponenty-kachestva-resheniya-intsidenta-neobkhodimo-kontrolirovat/)

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

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

Рейтинг: 817

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

## [Как в DevOps понимается продукт-ориентированность, согласно второму принципу?](https://cleverics.ru/digital/kb-qa/kak-v-devops-ponimaetsya-produkt-orientirovannost-soglasno-vtoromu-printsipu/)

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

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

Рейтинг: 817

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

## [Каким образом документируется и отслеживается «известная ошибка» после ее выявления?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-dokumentiruetsya-i-otslezhivaetsya-izvestnaya-oshibka-posle-ee-vyyavleniya/)

После выявления «известной ошибки» она документируется в специальной базе данных известных ошибок (KEDB - Known Error Database). В запись об ошибке включается информация о корневой причине, описании проблемы, временном обходном решении (workaround), а также данные о влиянии на бизнес и истории связанных с ней инцидентов. Эта информация используется при возникновении аналогичных инцидентов для быстрого применения известного обходного решения. Запись поддерживается в актуальном состоянии и обновляется по мере получения новых данных или поиска постоянного решения проблемы.

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

Рейтинг: 817

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

## [Как метод NPS может быть применен для оценки удовлетворенности сотрудников сервис деска?](https://cleverics.ru/digital/kb-qa/kak-metod-nps-mozhet-byt-primenen-dlya-otsenki-udovletvorennosti-sotrudnikov-servis-deska/)

Метод NPS (Net Promoter Score) может быть применен для оценки удовлетворенности сотрудников сервис деска через соответствующий вопрос: «Какова вероятность того, что вы порекомендуете нашу компанию своим знакомым в качестве места работы?». На основе полученных ответов можно определить индекс лояльности сотрудников и выявить потенциальные проблемы в работе сервиса. Методика позволяет классифицировать сотрудников на промоутеров (высокая вероятность рекомендации), пассивных (средний уровень удовлетворенности) и detractors (низкая вероятность рекомендации), что дает понимание общего климата в коллективе и направлений для улучшения.

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

Рейтинг: 817

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

## [Почему информация о возможностях внешних поставщиков ИТ-услуг быстро устаревает?](https://cleverics.ru/digital/kb-qa/pochemu-informatsiya-o-vozmozhnostyakh-vneshnikh-postavshchikov-it-uslug-bystro-ustarevaet/)

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

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

Рейтинг: 817

Теги: аутсорсинг, интеграция услуг, управление конфигурациями, CMDB

## [Почему терминология ITIL меняется от версии к версии?](https://cleverics.ru/digital/kb-qa/pochemu-terminologiya-itil-menyaetsya-ot-versii-k-versii/)

Терминология ITIL меняется от версии к версии, потому что подходы к управлению ИТ-услугами эволюционируют в соответствии с изменениями в бизнес-среде и технологиях. ITIL4 делает акцент на гибкости, ко-создании ценности и интеграции с современными методологиями (такими как Agile и DevOps), что требует более гибкой терминологии. Жесткое разделение, существовавшее в ITIL V3, заменяется концепцией видимости ресурсов в зависимости от контекста, что лучше отражает сложность современных сервисных экосистем.

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

Рейтинг: 817

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, ITIL, бизнес, ценность, бизнес-заказчик

## [Что означает термин 'Практик' в контексте управления изменениями по ITIL V3?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-termin-praktik-v-kontekste-upravleniya-izmeneniyami-po-itil-v3/)

В контексте управления изменениями по ITIL V3 термин 'Практик' (Practitioner) относится к роли ответственного за координацию работ по отдельным изменениям, в том числе относящимся к определенной области. Из перечисленных в ITIL V3 ролей (владелец и менеджер процесса, инициатор, практик, авторизующий, участник и председатель CAB) именно практик выполняет функции, которые похожи на обязанности менеджера изменений. В более мелких организациях одна и та же роль 'практик' часто объединяла в себе функции менеджера процесса, владельца процесса, администратора изменений и председателя CAB.

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

Рейтинг: 817

Теги: ITIL, общие вопросы менеджмента, управление изменениями, управление процессами, ИТ-процессы