# Бесплатная экспертная база знаний по управлению ИТ Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами ## [Как рассчитывается эффективная стоимость IT-услуги и для чего она нужна?](https://cleverics.ru/digital/kb-qa/kak-rasschityvaetsya-effektivnaya-stoimost-it-uslugi-i-dlya-chego-ona-nuzhna/) Эффективная стоимость услуги — это стоимость, начиная с которой предоставление услуги становится рациональным для организации. По сути, это определение точки безубыточности: сколько должна стоить услуга, чтобы организация не теряла деньги или начинала зарабатывать. Для расчёта эффективной стоимости необходимы компетенции в работе с фактическими затратами и прогнозировании. Зная свои возможности и умея прогнозировать спрос, организация может в перспективе нескольких лет оценивать целесообразность предоставления тех или иных услуг заказчикам. Автор: Андрей Труфанов Рейтинг: 71 Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, экономика и финансы ## [Как соотносятся рассматриваемые показатели с концепцией SRE (Site Reliability Engineering)?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-rassmatrivaemye-pokazateli-s-kontseptsiey-sre-site-reliability-engineering/) Из восьми рассматриваемых ключевых показателей управления только три непосредственно относятся к эксплуатации. Остальные показатели охватывают более широкие области: управление затратами, разработку, удовлетворённость потребителей и другие аспекты. Таким образом, система показателей выходит за рамки чисто эксплуатационных метрик SRE и охватывает комплексное управление ИТ-подразделением. При этом сами по себе факты обращений пользователей не являются показателем «хорошо» или «плохо» — основанием для оценки служат диапазоны значений и тренды, наблюдаемые в реальной практике. Автор: Дмитрий Исайченко, Павел Дёмин Рейтинг: 71 Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, экономика и финансы ## [Какие задачи выполняются в рамках деятельности по оптимизации ИТ-активов?](https://cleverics.ru/digital/kb-qa/kakie-zadachi-vypolnyayutsya-v-ramkakh-deyatelnosti-po-optimizatsii-it-aktivov/) В рамках деятельности по оптимизации активов выполняется ряд задач по обработке информации об активах с целью подготовки предложений по оптимизации структуры активов и дальнейшей передачи этих предложений в процесс управления изменениями. К таким задачам относятся: анализ соответствия структуры активов внутренним политикам организации; анализ затрат на активы; анализ статистики ремонтов; контроль истечения сроков гарантии и полезного использования; оценка возможностей по стандартизации активов; оценка перспектив применения новых технологий; поиск путей оптимизации. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 70 Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента, управление изменениями, управление ИТ-активами, ITAM, SAM, экономика и финансы, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой доли инцидентов, решённых с помощью стандартных решений, рекомендованных процессом управления проблемами?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-reshennykh-s-pomoshchyu-standar/) Системная структура объясняет проблему низкой доли инцидентов, решённых с помощью стандартных решений, рекомендованных процессом управления проблемами (IRPS — Incident Resolution with Proposed Standard), через эффективность «лаборатории» и её интеграцию с «конвейером». Механизм: 1. IRPS характеризует, какая доля инцидентов решается с помощью стандартных решений, разработанных процессом управления проблемами. 2. Низкая доля означает, что стандартные решения либо не разрабатываются, либо не используются. 3. Это приводит к тому, что: - Каждый инцидент решается индивидуально, что увеличивает время и затраты. - Качество решений снижается — сотрудники могут применять неоптимальные или неправильные решения. - Растёт нагрузка на вторую и третью линии — первая линия не имеет готовых решений. - Увеличивается MTRS — время решения инцидента растёт. Факторы, влияющие на низкую долю: 1. **Недостаточная работа по выявлению проблем.** Стандартные решения не создаются. 2. **Низкое качество стандартных решений.** Решения не работают из-за устаревания или ошибок. 3. **Недостаточная интеграция.** Стандартные решения не интегрированы с процессом обработки инцидентов. 4. **Отсутствие доверия.** Сотрудники не доверяют стандартным решениям. 5. **Изменение инфраструктуры.** Решения устаревают быстрее, чем обновляются. Системная структура показывает, что IRPS — это индикатор эффективности «лаборатории» и её интеграции с «конвейером». Улучшение IRPS требует улучшения процесса управления проблемами, обеспечения актуальности решений и их интеграции с процессом обработки инцидентов. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 70 Теги: DevOps, CI/CD, аллокация затрат, расчёт себестоимости услуг, постоянное улучшение, совершенствование, CSI, PDCA, управление инцидентами, управление конфигурациями, CMDB, управление проблемами, экономика и финансы, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой полноты покрытия инфраструктуры средствами мониторинга и её влияние на MTRS?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-polnoty-pokrytiya-infrastruktury-sredstvami-moni/) Системная структура «лаборатории» объясняет проблему низкой полноты покрытия инфраструктуры средствами мониторинга (Discovery tools coverage) и её влияние на MTRS (Mean Time to Restore Service). Механизм: 1. Полнота покрытия инфраструктуры средствами мониторинга характеризует, какая часть инфраструктуры отслеживается системами мониторинга. 2. Низкое покрытие означает, что значительная часть инфраструктуры находится в «слепых зонах». 3. Это влияет на MTRS: - Проблемы в «слепых зонах» не обнаруживаются автоматически — их обнаруживают только пользователи. - Время обнаружения проблем увеличивается — MTRS растёт, потому что время обнаружения — часть MTRS. - Невозможно быстро локализовать проблему — без мониторинга сложно определить, какой элемент инфраструктуры вышел из строя. - Невозможно проанализировать взаимосвязи — без визуализации сервисно-ресурсных моделей сложно оценить взаимное влияние элементов. 4. Высокий MTRS, в свою очередь: - Увеличивает время простоя сервисов. - Увеличивает финансовые потери. - Снижает удовлетворённость пользователей. - Усиливает давление бизнеса на ИТ. Факторы, влияющие на низкое покрытие: 1. **Недостаточные инвестиции.** Средства мониторинга требуют затрат. 2. **Сложность инфраструктуры.** Динамичная инфраструктура сложно покрывается. 3. **Отсутствие стандартов.** Нет единых требований к покрытию. 4. **Недостаточная интеграция.** Средства мониторинга не интегрированы с CMDB. Системная структура показывает, что полнота покрытия мониторингом — это критический фактор MTRS. Инвестиции в мониторинг окупаются через снижение времени обнаружения и локализации проблем. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 70 Теги: ISO 20000, аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, мониторинг, поддержка пользователей, Service Desk, Help Desk, управление конфигурациями, CMDB, экономика и финансы ## [Как системная структура объясняет проблему низкой доли изменений, документированных в соответствии с требованиями, и её влияние на PIR?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-dokumentirovannykh-v-sootvetstvii/) Системная структура объясняет проблему низкой доли изменений, документированных в соответствии с требованиями, и её влияние на эффективность PIR (Post-Implementation Review). Механизм: 1. Качество документирования изменений (Data quality) — это ключевой фактор, влияющий на эффективность PIR. 2. Низкая доля изменений, документированных в соответствии с требованиями, означает, что данные о изменениях неполные, некорректные или нестандартизированные. 3. Это влияет на PIR: - Невозможно эффективно проанализировать изменение — данные неполные. - Невозможно выявить корневые причины проблем — данные некорректные. - Невозможно извлечь уроки — информация о изменении ненадёжна. - Невозможно создать модели изменений и шаблоны стандартных изменений — данные нестандартизированные. 4. Неэффективный PIR, в свою очередь: - Не улучшает качество изменений. - Не снижает риски. - Не увеличивает долю стандартных изменений. - Не снижает затраты. Факторы, влияющие на низкое качество документирования: 1. **Сложность процессов.** Обременительные требования демотивируют. 2. **Отсутствие автоматизации.** Ручной ввод данных. 3. **Непонимание ценности.** Сотрудники не видят пользы. 4. **Давление сроков.** Спешка приводит к формальному документированию. 5. **Отсутствие контроля.** Качество не проверяется. Системная структура показывает, что качество документирования — это критический фактор эффективности PIR. Инвестиции в качество документирования окупаются через улучшение PIR и, как следствие, улучшение качества изменений, снижение рисков и повышение эффективности управления изменениями. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 70 Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, управление изменениями, управление проблемами, управление рисками, экономика и финансы, эффективность, оптимизация ## [Какие компоненты инфраструктуры обычно отсутствуют в упрощённой модели, но должны быть учтены в реальной?](https://cleverics.ru/digital/kb-qa/kakie-komponenty-infrastruktury-obychno-otsutstvuyut-v-uproshchennoy-modeli-no-dolzhny-byt-uchteny-v/) В упрощённой модели часто отсутствуют: система мониторинга, система резервного копирования, структура печати (формирование бухгалтерских чеков и актов предоставления услуг), тестовая среда, среда разработки, копия приложения. В реальной модели все эти компоненты присутствуют и требуют учёта собственных затрат: серверы для мониторинга, хранилища для резервных копий, среды для тестирования и разработки. Это существенно обогащает дерево модели и увеличивает количество элементов, на которые необходимо распределять затраты. Автор: Андрей Труфанов Рейтинг: 64 Теги: аллокация затрат, расчёт себестоимости услуг, мониторинг, управление конфигурациями, CMDB, экономика и финансы ## [При каких условиях водопадная модель разработки позволяет получать качественные результаты?](https://cleverics.ru/digital/kb-qa/pri-kakikh-usloviyakh-vodopadnaya-model-razrabotki-pozvolyaet-poluchat-kachestvennye-rezultaty/) Водопадная модель позволяет получать качественные выходные результаты при достаточно детальном контроле расходов при разработке крупных информационных систем с конечной функциональностью, которую возможно определить и зафиксировать в самом начале работ, а также при отсутствии требования максимально быстрого завершения полного цикла разработки. Автор: Олег Скрынник Рейтинг: 60 Теги: аллокация затрат, расчёт себестоимости услуг, общие вопросы менеджмента, экономика и финансы ## [Как системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на эффективность?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-svyazannykh-s-otkrytymi-problem/) Системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на эффективность через взаимосвязь «конвейера» и «лаборатории». Механизм: 1. Доля инцидентов, связанных с открытыми проблемами, характеризует, насколько эффективно процесс управления проблемами выявляет и регистрирует корневые причины инцидентов. 2. Низкая доля означает, что многие инциденты не связываются с известными проблемами. 3. Это приводит к тому, что: - Инциденты обрабатываются повторно, без использования стандартных решений. - Корневые причины не устраняются, инциденты повторяются. - Растёт нагрузка на «конвейер» обработки инцидентов. - Увеличиваются затраты на обработку повторяющихся инцидентов. - Снижается удовлетворённость пользователей. 4. Низкая доля, в свою очередь: - Увеличивает количество инцидентов (проблемы не устраняются). - Увеличивает MTRS (каждый инцидент решается заново). - Снижает эффективность использования базы знаний. Факторы, влияющие на низкую долю: 1. **Недостаточный анализ инцидентов.** Инциденты закрываются без анализа корневой причины. 2. **Недостаточные ресурсы управления проблемами.** Аналитики не успевают обрабатывать все инциденты. 3. **Отсутствие интеграции.** Система обработки инцидентов не связана с системой управления проблемами. 4. **Недостаточная квалификация.** Аналитики не обладают навыками выявления проблем. 5. **Отсутствие стимулов.** KPI фокусируются на MTRS, а не на связывании инцидентов с проблемами. Системная структура показывает, что доля инцидентов, связанных с открытыми проблемами, — это индикатор эффективности «лаборатории». Улучшение требует улучшения анализа инцидентов, выделения ресурсов на управление проблемами и развития интеграции между процессами. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 60 Теги: DevOps, CI/CD, аллокация затрат, расчёт себестоимости услуг, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление знаниями, управление инцидентами, управление проблемами, управление процессами, ИТ-процессы, экономика и финансы, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на затраты?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/) Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR — Problem Solution Rate), и её влияние на затраты через взаимосвязь «конвейера» и «лаборатории». Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это приводит к тому, что: - Каждое обращение решается «с нуля» — сотрудники тратят время на диагностику и поиск решения. - Увеличивается Processing Time — решение без базы знаний занимает больше времени. - Увеличиваются затраты — больше ресурсов тратится на обработку каждого обращения. - Снижается продуктивность — сотрудники не используют накопленный опыт. - Увеличивается нагрузка на вторую и третью линии — первая линия не имеет готовых решений. 4. Низкая доля, в свою очередь: - Увеличивает Cost per ticket. - Увеличивает MTRS. - Снижает удовлетворённость пользователей. Факторы, влияющие на низкую долю: 1. **Недостаточное содержание базы знаний.** Мало статей, они устарели или не покрывают типичные ситуации. 2. **Низкое качество статей.** Статьи написаны непонятно или не соответствуют реальным сценариям. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний. Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и её интеграции с «конвейером». Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Высокий PSR напрямую снижает затраты на управление инцидентами. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 60 Теги: DevOps, CI/CD, аллокация затрат, расчёт себестоимости услуг, мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление запросами на обслуживание, управление знаниями, управление инцидентами, экономика и финансы, эффективность, оптимизация