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

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

## [Какие ошибки в управлении изменениями привели к возникновению кризиса в ИТ?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-v-upravlenii-izmeneniyami-priveli-k-vozniknoveniyu-krizisa-v-it/)

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

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

Рейтинг: 977

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

## [Как определяется целесообразность применения методик DevOps в организации?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-tselesoobraznost-primeneniya-metodik-devops-v-organizatsii/)

Целесообразность применения методик DevOps определяется оценкой их соответствия конечной бизнес-задаче и контексту организации. Необходимо проанализировать, является ли поддерживаемый ИТ-решением бизнес-процесс фактором дифференциации компании. Если нет, возможно, разумнее адаптировать бизнес-процесс под возможности доступных решений, включая коробочные продукты. Также важно учитывать уровень сложности инфраструктуры: в условиях высокой сложности (область 'Сложно' по Cynefin) традиционные методы могут быть неэффективны, и предпочтительнее использовать итеративный подход вместо сложного планирования.

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

Рейтинг: 977

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

## [Что такое продуктовый подход и как он помогает в управлении бизнесом?](https://cleverics.ru/digital/kb-qa/chto-takoe-produktovyy-podkhod-i-kak-on-pomogaet-v-upravlenii-biznesom/)

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

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

Рейтинг: 977

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

## [Почему простого обсуждения технического плана проекта может быть недостаточно для успешной реализации задачи в ИТ-команде?](https://cleverics.ru/digital/kb-qa/pochemu-prostogo-obsuzhdeniya-tekhnicheskogo-plana-proekta-mozhet-byt-nedostatochno-dlya-uspeshnoy-r/)

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

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

Рейтинг: 977

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

## [Что является основным препятствием для преобразования теории в практику в области межличностного взаимодействия на рабочем месте?](https://cleverics.ru/digital/kb-qa/chto-yavlyaetsya-osnovnym-prepyatstviem-dlya-preobrazovaniya-teorii-v-praktiku-v-oblasti-mezhlichnos/)

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

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

Рейтинг: 977

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

## [Какие стандарты существуют для управления аутсорсингом ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-standarty-sushchestvuyut-dlya-upravleniya-autsorsingom-it-uslug/)

Для управления аутсорсингом ИТ-услуг существуют различные стандарты и руководства, включая стандарты серии ISO 37500, которые охватывают основные этапы, процессы и аспекты управления аутсорсингом на всех стадиях взаимодействия заказчика и поставщика. Также широко используются своды знаний, такие как OPBOK (Outsourcing Professional Body of Knowledge), разработанный IAOP, и документация SIAM Foundation Body of Knowledge, описывающая модель управления услугами при работе с несколькими поставщиками. Эти стандарты и руководства обеспечивают базу для внедрения механизмов аутсорсинга, описывают лучшие практики и предоставляют инструменты для успешного управления отношениями с поставщиками.

Автор: Дмитрий Хруслов

Рейтинг: 977

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

## [Существуют ли усредненные данные по количеству обращений в ИТ-поддержку на одного пользователя?](https://cleverics.ru/digital/kb-qa/sushchestvuyut-li-usrednennye-dannye-po-kolichestvu-obrashcheniy-v-it-podderzhku-na-odnogo-polzovate/)

Да, в открытых источниках есть данные за 2012 и 2018 годы, которые демонстрируют различия по отраслям. В 2012 году разрыв между отраслями был значительным: в финансовом секторе — до 4–5 обращений на пользователя в месяц, в здравоохранении — около 0,8–1. К 2018 году разрыв сократился: лидеры снизили нагрузку (до 2,5–3). Это связано с ростом ИТ-грамотности пользователей и улучшением качества услуг. В 2020 году из-за пандемии наблюдался кратковременный рост обращений на 16% из-за массового перехода на удалёнку.

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

Рейтинг: 977

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

## [Что означает переход из области 'Запутанно' в область 'Сложно' по модели Cynefin в контексте управления изменениями?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-perekhod-iz-oblasti-zaputanno-v-oblast-slozhno-po-modeli-cynefin-v-kontekste-upravlen/)

По модели Cynefin переход из области 'Запутанно' (Complicated) в область 'Сложно' (Complex) означает, что с ростом сложности объекта управления (инфраструктуры, компании) причинно-следственные связи между событиями перестают быть определяемыми заранее даже с привлечением квалифицированных экспертов. В области 'Запутанно' эксперты могут установить эти связи, тогда как в области 'Сложно' такие связи могут быть выявлены лишь постфактум. Это означает, что в условиях высокой сложности традиционные методы планирования и прогнозирования становятся малоэффективными, и целесообразнее перейти к экспериментальному подходу с небольшими итерациями.

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

Рейтинг: 977

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

## [Какова основная цель практики управления проблемами?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-tsel-praktiki-upravleniya-problemami/)

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

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

Рейтинг: 977

Теги: управление инцидентами, управление проблемами

## [Какие аспекты необходимо учитывать при проектировании модели изменений?](https://cleverics.ru/digital/kb-qa/kakie-aspekty-neobkhodimo-uchityvat-pri-proektirovanii-modeli-izmeneniy/)

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

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

Рейтинг: 977

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