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

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

## [Какие ограничения должны быть установлены для полномочий координаторов изменений?](https://cleverics.ru/digital/kb-qa/kakie-ogranicheniya-dolzhny-byt-ustanovleny-dlya-polnomochiy-koordinatorov-izmeneniy/)

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

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

Рейтинг: 914

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

## [Для чего необходим этап согласования в обработке ИТ-заявок?](https://cleverics.ru/digital/kb-qa/dlya-chego-neobkhodim-etap-soglasovaniya-v-obrabotke-it-zayavok/)

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

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

Рейтинг: 913

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

## [Какое значение имеют человеческие отношения в управлении услугами ИТ?](https://cleverics.ru/digital/kb-qa/kakoe-znachenie-imeyut-chelovecheskie-otnosheniya-v-upravlenii-uslugami-it/)

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

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

Рейтинг: 913

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

## [Почему для значительных инцидентов необходима отдельная процедура обработки?](https://cleverics.ru/digital/kb-qa/pochemu-dlya-znachitelnykh-intsidentov-neobkhodima-otdelnaya-protsedura-obrabotki/)

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

Автор: Роман Журавлёв

Рейтинг: 913

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

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

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

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

Рейтинг: 913

Теги: бизнес, ценность, бизнес-заказчик, обучение сотрудников, учебные курсы, тренинги, управление знаниями, управление отношениями, взаимодействие, 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, описывающая модель управления услугами при работе с несколькими поставщиками. Эти стандарты и руководства обеспечивают базу для внедрения механизмов аутсорсинга, описывают лучшие практики и предоставляют инструменты для успешного управления отношениями с поставщиками.

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

Рейтинг: 913

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

## [В каких случаях целесообразно использовать проектный подход вместо Agile?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-tselesoobrazno-ispolzovat-proektnyy-podkhod-vmesto-agile/)

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

Автор: Светлана Сапегина

Рейтинг: 913

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, поток создания ценности (Value Stream), управление продуктами, продуктовый подход, эффективность, оптимизация

## [Каково различие между ролью менеджера уровня услуг (service level manager) и владельцем услуги (service owner)?](https://cleverics.ru/digital/kb-qa/kakovo-razlichie-mezhdu-rolyu-menedzhera-urovnya-uslug-service-level-manager-i-vladeltsem-uslugi-ser/)

Владелец услуги (service owner) отвечает за сквозное управление конкретной ИТ-услугой, тогда как менеджер уровня услуг фокусируется на достижении и соблюдении договоренностей об уровне услуги между поставщиком и заказчиком. В ITILv3 есть таблица сравнения этих ролей (Table 6.8 Comparison of CSI manager, service level manager, service owner and business relationship manager roles), но эта таблица скорее порождает вопросы, чем дает четкие ответы о границах ответственности между этими ролями. На практике в большинстве организаций найти достаточно убедительный ответ на вопрос о проведении границы ответственности между этими ролями сложно.

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

Рейтинг: 913

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

## [Какие последствия имеет ресурсный характер традиционных ИТ-услуг для ИТ-менеджмента?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-resursnyy-kharakter-traditsionnykh-it-uslug-dlya-it-menedzhmenta/)

Ресурсный характер традиционных ИТ-услуг приводит к нескольким важным последствиям для ИТ-менеджмента: 1) сложность в обосновании инвестиций в процессные улучшения и инфраструктурные проекты, так как их ценность для бизнеса неочевидна; 2) проблемы в коммуникации с бизнес-заказчиками, которые фокусируются только на конечных ресурсах, а не на процессах их предоставления; 3) слабое понимание бизнесом скрытых аспектов ИТ-сервисов, обеспечивающих надежность и безопасность; 4) трудности в формировании актуального каталога услуг, если он составлен на языке ИТ, а не бизнеса; 5) необходимость постоянного усилия по трансляции ценности ИТ-процессов в понятные бизнесу термины, что требует от ИТ-менеджеров развития навыков бизнес-коммуникации и аргументации.

Автор: Роман Журавлёв

Рейтинг: 913

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

## [Как оценить, действительно ли ваш бизнес-контекст детерминирован и можно ли использовать дедлайны?](https://cleverics.ru/digital/kb-qa/kak-otsenit-deystvitelno-li-vash-biznes-kontekst-determinirovan-i-mozhno-li-ispolzovat-dedlayny/)

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

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

Рейтинг: 913

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