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

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

## [Какие методы контроля качества работ можно применять при взаимодействии нескольких ИТ-групп?](https://cleverics.ru/digital/kb-qa/kakie-metody-kontrolya-kachestva-rabot-mozhno-primenyat-pri-vzaimodeystvii-neskolkikh-it-grupp/)

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

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

Рейтинг: 965

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

## [Зачем необходимы критерии приемки на этапах ИТ-процессов?](https://cleverics.ru/digital/kb-qa/zachem-neobkhodimy-kriterii-priemki-na-etapakh-it-protsessov/)

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

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

Рейтинг: 965

Теги: командная работа, управление доступностью

## [Какие коммуникационные сложности возникают при переходе к частым релизам и как их преодолеть?](https://cleverics.ru/digital/kb-qa/kakie-kommunikatsionnye-slozhnosti-voznikayut-pri-perekhode-k-chastym-relizam-i-kak-ikh-preodolet/)

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

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

Рейтинг: 965

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

## [Для каких типов бизнес-процессов микросервисная архитектура является наиболее подходящей?](https://cleverics.ru/digital/kb-qa/dlya-kakikh-tipov-biznes-protsessov-mikroservisnaya-arkhitektura-yavlyaetsya-naibolee-podkhodyashche/)

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

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

Рейтинг: 965

Теги: архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, управление инцидентами, эффективность, оптимизация

## [Какие признаки указывают на неполную реализацию потенциала сервисно-ресурсной модели?](https://cleverics.ru/digital/kb-qa/kakie-priznaki-ukazyvayut-na-nepolnuyu-realizatsiyu-potentsiala-servisno-resursnoy-modeli/)

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

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

Рейтинг: 965

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

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

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

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

Рейтинг: 965

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

## [Что такое ориентация на ценность для заказчика в контексте сервисных отношений?](https://cleverics.ru/digital/kb-qa/chto-takoe-orientatsiya-na-tsennost-dlya-zakazchika-v-kontekste-servisnykh-otnosheniy/)

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

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

Рейтинг: 964

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

## [Как сделать процесс предоставления обратной связи максимально удобным для пользователя?](https://cleverics.ru/digital/kb-qa/kak-sdelat-protsess-predostavleniya-obratnoy-svyazi-maksimalno-udobnym-dlya-polzovatelya/)

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

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

Рейтинг: 964

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

## [Какой подход к обработке запросов на информацию об инциденте способствует снижению нагрузки на Service Desk?](https://cleverics.ru/digital/kb-qa/kakoy-podkhod-k-obrabotke-zaprosov-na-informatsiyu-ob-intsidente-sposobstvuet-snizheniyu-nagruzki-na/)

Подход, при котором процесс Управления инцидентами (INC) организует эффективную проактивную коммуникацию с пользователями, способствует снижению нагрузки на Service Desk. Путём автоматических оповещений (например, по email или SMS при каждом изменении статуса инцидента) пользователи получают необходимую информацию без необходимости обращаться с запросом. Также важно обеспечить доступ к статусу инцидентов через портал самообслуживания, где пользователь может самостоятельно посмотреть текущее состояние своего запроса. Этот подход позволяет минимизировать количество повторных обращений пользователей по уже зарегистрированным инцидентам, что напрямую снижает нагрузку на Service Desk и позволяет сосредоточиться на обработке новых инцидентов.

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

Рейтинг: 964

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

## [Почему процесс управления изменениями особенно важен для ИТ-департамента?](https://cleverics.ru/digital/kb-qa/pochemu-protsess-upravleniya-izmeneniyami-osobenno-vazhen-dlya-it-departamenta/)

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

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

Рейтинг: 964

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