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

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

## [Как интерпретировать значение метрики KPI группы поддержки в диапазоне от 0 до 1?](https://cleverics.ru/digital/kb-qa/kak-interpretirovat-znachenie-metriki-kpi-gruppy-podderzhki-v-diapazone-ot-0-do-1/)

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

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

Рейтинг: 1129

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

## [Когда аутсорсинг является менее эффективным решением по сравнению с прямым наймом?](https://cleverics.ru/digital/kb-qa/kogda-autsorsing-yavlyaetsya-menee-effektivnym-resheniem-po-sravneniyu-s-pryamym-naymom/)

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

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

Рейтинг: 1129

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

## [Чем BRM отличается от менеджера по продажам (sales manager)?](https://cleverics.ru/digital/kb-qa/chem-brm-otlichaetsya-ot-menedzhera-po-prodazham-sales-manager/)

BRM (Business Relationship Management) принципиально отличается от менеджера по продажам своей основной целью и фокусом деятельности. Основная цель BRM – построение и поддержание долгосрочных партнерских отношений с заказчиком, ориентированных не на продажи и прибыль сервис-провайдера, а на ценность и удовлетворенность заказчика. BRM выступает в роли «голоса заказчика» внутри сервис-провайдера, передавая понимание бизнес-задач и ожиданий заказчика. В отличие от менеджера по продажам, BRM не фокусируется на заключении сделок и достижении краткосрочных финансовых целей. Предостережение в тексте гласит, что неаккуратное сочетание задач BRM с sales и pre-sale активностями может быстро выхолостить понятие business relationships, так как истинные business relationships не про продажи, а про партнерство с заказчиком.

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

Рейтинг: 1129

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

## [Как соотносятся практики управления изменениями и управления запросами на обслуживание?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-praktiki-upravleniya-izmeneniyami-i-upravleniya-zaprosami-na-obsluzhivanie/)

Практика управления изменениями и практика управления запросами на обслуживание взаимодействуют, но не заменяют друг друга. Управление изменениями отвечает за оценку рисков, авторизацию и мониторинг всех изменений, включая те, что реализуются через запросы на обслуживание. Управление запросами выполняет стандартные операции, такие как установка ПО или изменение прав доступа. Ключевое отличие: запросы на обслуживание — это средства выполнения определенного типа работ, а изменения как таковые требуют оценки и контроля по специальной процедуре. Стандартные изменения могут инициироваться как запросы на обслуживание, но сами по себе запросы не равны изменениям. Важно, чтобы все изменения (даже выполняемые через запросы) попадали в общую систему контроля, что обеспечивается разработкой предопределенных моделей стандартных изменений.

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

Рейтинг: 1128

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

## [Что такое обходное решение и какие у него есть недостатки?](https://cleverics.ru/digital/kb-qa/chto-takoe-obkhodnoe-reshenie-i-kakie-u-nego-est-nedostatki/)

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

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

Рейтинг: 1128

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

## [Каковы основные обязанности менеджера процесса управления уровнем услуг?](https://cleverics.ru/digital/kb-qa/kakovy-osnovnye-obyazannosti-menedzhera-protsessa-upravleniya-urovnem-uslug/)

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

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

Рейтинг: 1128

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

## [Каково определение риска согласно ISO 31000 и как оно связано с ИТ-управлением?](https://cleverics.ru/digital/kb-qa/kakovo-opredelenie-riska-soglasno-iso-31000-i-kak-ono-svyazano-s-it-upravleniem/)

Согласно ISO 31000, риск - это влияние неопределенности на цели. Риск-менеджмент, соответственно, представляет собой скоординированные действия по направлению и контролю организации в отношении рисков. В контексте ИТ-управления это означает, что управление проводится не собственно рисками, а организацией с учетом рисков. Управление рисками в ИТ-сфере - это управление организацией с учетом неопределенности. Чем лучше эта неопределенность проработана (корректно идентифицирована, проанализирована и оценена), тем более обоснованные управленческие решения можно принимать и тем более предсказуемые результаты получать. В этом смысле управление рисками становится неотъемлемой частью работы любого менеджера в ИТ-сфере.

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

Рейтинг: 1128

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

## [Как принципы ITIL Practitioner Guidance 2016 года трансформировались в ITIL 4?](https://cleverics.ru/digital/kb-qa/kak-printsipy-itil-practitioner-guidance-2016-goda-transformirovalis-v-itil-4/)

Девять принципов ITIL Practitioner Guidance 2016 года трансформировались в семь принципов ITIL 4 2019 года следующим образом: два идентичных принципа остались без изменений ("Фокусируйтесь на ценности" и "Отталкивайтесь от текущей ситуации"); два принципа были объединены ("Сотрудничайте" и "Будьте прозрачны" стали одним - "Сотрудничайте и поощряйте прозрачность"); три принципа получили незначительные изменения формулировок ("Действуйте итерационно" стало "Действуйте итерационно, используя обратную связь", "Упрощайте" превратилось в "Простота и практичность", "Используйте целостный подход" получил дополнение "Think and work holistically"); один принцип ("Проектируйте, ориентируясь на потребительский опыт использования") был интегрирован в более общий принцип "Фокусируйтесь на ценности"; элементы другого принципа ("Приоритет прямого наблюдения") нашли отражение в рекомендациях по применению принципа "Отталкивайтесь от текущей ситуации"; и был добавлен новый принцип "Оптимизируйте и автоматизируйте".

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

Рейтинг: 1128

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

## [Как DevOps влияет на распределение ответственности между бизнесом и ИТ?](https://cleverics.ru/digital/kb-qa/kak-devops-vliyaet-na-raspredelenie-otvetstvennosti-mezhdu-biznesom-i-it/)

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

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

Рейтинг: 1127

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, управление процессами, ИТ-процессы

## [Что входит в регламент управления изменениями и релизами в контексте разработки и внедрения прикладного программного обеспечения?](https://cleverics.ru/digital/kb-qa/chto-vkhodit-v-reglament-upravleniya-izmeneniyami-i-relizami-v-kontekste-razrabotki-i-vnedreniya-pri/)

Регламент управления изменениями и релизами в контексте разработки и внедрения прикладного программного обеспечения состоит из двух основных компонентов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы или выполнения доработок («Положение о разработке прикладного ПО»), который описывает состав работ, ответственных лиц, входные и выходные документы для каждой стадии. 2) Документ, определяющий порядок приёмки новых систем в эксплуатацию («Положение о внедрении информационных систем»), который включает порядок и охват тестирования, подготовку тестовых сред, опытную эксплуатацию и другие аспекты внедрения. Этот регламент может дополняться политиками релизов по информационным системам, что позволяет согласовать с бизнесом календарь релизов и определить необходимость и порядок выделения ресурсов на проведение пользовательского тестирования (UAT). В совокупности эти документы обеспечивают структурированный процесс управления изменениями и релизами при разработке и внедрении программного обеспечения.

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

Рейтинг: 1127

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