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

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

## [Как применять матрично-иерархическую структуру в классификаторе изменений?](https://cleverics.ru/digital/kb-qa/kak-primenyat-matrichno-ierarkhicheskuyu-strukturu-v-klassifikatore-izmeneniy/)

Матрично-иерархическая структура в классификаторе изменений применяется следующим образом:  Сначала устанавливается иерархия категорий изменений: - На верхнем уровне разделяются стандартные и нестандартные изменения - Далее по критериям риска, типа объекта (ИТ-инфраструктура, информационные системы, сети) - Иерархия продолжается до уровня конкретных типов или групп систем  Затем формируется матрица параметров для каждой категории: - Для каждой группы систем или направлений определяются свои наборы параметров - Параметры включают: ответственных за координацию, уполномоченных на согласование, обязательные результаты этапов - Набор опциональных этапов для конкретной группы систем  Особенность применения такой структуры: - Для ИТ-инфраструктуры может быть определен общий типовой порядок с опциональными этапами для работ в боевой среде - Для информационных систем — мастер-порядок с обязательным приёмочным тестированием - Для разных групп информационных систем (например, критически важных) — дополнительные этапы оценки влияния  Как пример конкретной реализации: - Категория «Стандартные изменения для серверной инфраструктуры»:   * Общие этапы: запрос, техническое согласование, выполнение, подтверждение   * Параметры: ответственный координатор — администратор соответствующего направления, срок выполнения — не более 2 часов   * Специфика: не требуется приёмочное тестирование, так как работы выполняются в режиме реального времени  - Категория «Изменения для критически важных информационных систем»:   * Общие этапы: запрос, анализ влияния, утверждение комитета, планирование, тестирование, выполнение, подтверждение   * Параметры: ответственный координатор — старший сотрудник, срок планирования — минимум 5 рабочих дней   * Специфика: обязательное приёмочное тестирование в выделенной среде  Этот подход позволяет значительно сократить количество уникальных моделей, оставаясь при этом достаточно гибким для учета специфики различных систем и направлений.

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

Рейтинг: 962

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

## [Какие проблемы возникают при выполнении работ с участием нескольких групп ИТ-специалистов?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-vypolnenii-rabot-s-uchastiem-neskolkikh-grupp-it-spetsialistov/)

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

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

Рейтинг: 961

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

## [Почему важно определять приоритеты устранения инцидентов?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-opredelyat-prioritety-ustraneniya-intsidentov/)

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

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

Рейтинг: 961

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

## [Почему важно ограничивать количество одновременно обрабатываемых проблем?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-ogranichivat-kolichestvo-odnovremenno-obrabatyvaemykh-problem/)

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

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

Рейтинг: 961

Теги: Канбан, WIP-лимиты, эффективность, оптимизация

## [Как ITIL 4 определяет взаимосвязь между процессами и потоками создания ценности?](https://cleverics.ru/digital/kb-qa/kak-itil-4-opredelyaet-vzaimosvyaz-mezhdu-protsessami-i-potokami-sozdaniya-tsennosti/)

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

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

Рейтинг: 961

Теги: ITIL, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, поток создания ценности (Value Stream), управление изменениями, управление инцидентами, управление конфигурациями, CMDB, управление проблемами, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы

## [Как правильно выбрать первый процесс ITIL для внедрения в организации?](https://cleverics.ru/digital/kb-qa/kak-pravilno-vybrat-pervyy-protsess-itil-dlya-vnedreniya-v-organizatsii/)

Выбор первого процесса ITIL для внедрения должен основываться на комплексной оценке. Необходимо проанализировать несколько ключевых факторов: 1) Какие процессы в данный момент вызывают наибольшие проблемы и боли у бизнеса и пользователей (частые простои, низкая удовлетворенность, регулярные ошибки); 2) Какой процесс при успешном внедрении даст самые быстрые и заметные улучшения, чтобы создать позитивный импульс для дальнейших изменений; 3) Какой процесс имеет наибольшую поддержку среди ИТ-персонала и руководства; 4) Какие процессы имеют простую структуру и четкие границы, что упростит внедрение. Обычно рекомендуется начинать с управления инцидентами, так как это процесс, который непосредственно влияет на пользователей, имеет четкие метрики (время решения, удовлетворенность), и его улучшение быстро заметно бизнесу. Альтернативой может быть управление запросами на обслуживание (Service Request Management), который часто менее сложен в реализации и также дает быстрый эффект. Важно избегать сложных процессов, таких как управление конфигурациями или управление изменениями, на начальном этапе, так как они требуют значительных изменений во многих других процессах.

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

Рейтинг: 961

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

## [Почему важно включать удовлетворённость пользователей в формулировку назначения практики управления инцидентами?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-vklyuchat-udovletvorennost-polzovateley-v-formulirovku-naznacheniya-praktiki-upravlen/)

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

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

Рейтинг: 961

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

## [Как формулируется назначение практики управления инцидентами в ITIL 4 и какие недостатки есть у этой формулировки?](https://cleverics.ru/digital/kb-qa/kak-formuliruetsya-naznachenie-praktiki-upravleniya-intsidentami-v-itil-4-i-kakie-nedostatki-est-u-e/)

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

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

Рейтинг: 961

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

## [Какие принципы бизнеса сохранились неизменными с девяностых годов до сегодняшнего дня?](https://cleverics.ru/digital/kb-qa/kakie-printsipy-biznesa-sokhranilis-neizmennymi-s-devyanostykh-godov-do-segodnyashnego-dnya/)

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

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

Рейтинг: 961

Теги: бизнес, ценность, бизнес-заказчик

## [Как различаются уровни внедрения процессов управления проблемами и постоянного совершенствования в организациях разного размера?](https://cleverics.ru/digital/kb-qa/kak-razlichayutsya-urovni-vnedreniya-protsessov-upravleniya-problemami-i-postoyannogo-sovershenstvov/)

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

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

Рейтинг: 961

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