# Бесплатная экспертная база знаний по управлению ИТ Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами ## [Какие вопросы следует задавать бизнесу при определении требований к восстановлению данных?](https://cleverics.ru/digital/kb-qa/kakie-voprosy-sleduet-zadavat-biznesu-pri-opredelenii-trebovaniy-k-vosstanovleniyu-dannykh/) При определении требований к восстановлению данных следует задавать бизнесу следующие ключевые вопросы: - Какие данные являются критически важными для вашего бизнеса и должны быть в приоритете при восстановлении? - Какой максимальный период простоя системы вы можете допустить, прежде чем восстановление данных станет критически необходимым? - Какой объем потери данных (в минутах, часах или транзакциях) является приемлемым для вашего бизнеса? - Требуется ли вам возможность восстановления данных не только на момент сбоя, но и на определенные точки времени в прошлом? - Нужно ли восстанавливать данные целиком или достаточно отдельных элементов (отдельные файлы, документы, записи в базах данных)? - Есть ли у вас специфические требования к точности и полноте восстановления данных для соответствия нормативным требованиям? - Кто будет ответственным за процесс восстановления данных и как будет организовано подтверждение успешного восстановления? - Были ли в прошлом случаи, когда потребовалось восстановление данных, и какие проблемы возникали в тот раз? Автор: Дмитрий Исайченко Рейтинг: 830 Теги: бизнес, ценность, бизнес-заказчик, управление инцидентами, управление процессами, ИТ-процессы ## [Какие данные должны содержаться в CMS для обеспечения её полезности?](https://cleverics.ru/digital/kb-qa/kakie-dannye-dolzhny-soderzhatsya-v-cms-dlya-obespecheniya-ee-poleznosti/) Для обеспечения полезности CMS должна содержать информацию, непосредственно используемую в процессах ИТ-управления. Это включает данные об основных конфигурационных единицах (CI), их атрибутах, отношениях и зависимостях; информацию о физическом и логическом расположении компонентов; данные об ответственных лицах и командах; данные об установленных версиях программного обеспечения и характеристиках аппаратного обеспечения; информацию об интеграциях с другими системами. Важно, что набор данных должен быть минимально достаточным для удовлетворения конкретных потребностей процессов организации, без избыточной информации, которая не используется ни в одном из процессов. Автор: Игорь Гутник Рейтинг: 830 Теги: бизнес, ценность, бизнес-заказчик, командная работа, управление конфигурациями, CMDB ## [Почему оценка 10-20% от общего числа респондентов для проведения опроса является завышенной?](https://cleverics.ru/digital/kb-qa/pochemu-otsenka-10-20-ot-obshchego-chisla-respondentov-dlya-provedeniya-oprosa-yavlyaetsya-zavyshenn/) Оценка 10-20% (100-200 ответов при 1000 пользователях) основана на здравом смысле и интуитивных предположениях, но с математической точки зрения эта оценка завышена. Анализ с использованием доверительных интервалов и распределения Стьюдента показывает, что даже при выборке в 40-50 человек достигается достаточная точность (ошибка 0.25-0.5 балла при 95% вероятности), и дальнейшее увеличение размера выборки приводит к незначительному повышению точности. Автор: Дмитрий Исайченко Рейтинг: 830 Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, Service Desk, Help Desk ## [Как доля экстренных изменений связана с KPI процесса управления изменениями?](https://cleverics.ru/digital/kb-qa/kak-dolya-ekstrennykh-izmeneniy-svyazana-s-kpi-protsessa-upravleniya-izmeneniyami/) Доля экстренных изменений является одним из ключевых показателей эффективности (KPI) процесса управления изменениями. Высокая доля экстренных изменений указывает на недостаточное предварительное планирование, слабый контроль за процессом и увеличение рисков. Статистика подтверждает, что высокая доля экстренных изменений коррелирует с низким качеством их выполнения. Идеал — минимальная доля экстренных изменений, поскольку процесс управления изменениями по своей сути направлен на снижение рисков через соблюдение стандартных процедур. Автор: Дмитрий Исайченко Рейтинг: 830 Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента, управление изменениями, управление рисками, эффективность, оптимизация ## [Почему в описании услуги необходима сущность «доступ к ресурсам»?](https://cleverics.ru/digital/kb-qa/pochemu-v-opisanii-uslugi-neobkhodima-sushchnost-dostup-k-resursam/) Сущность «доступ к ресурсам» необходима в описании услуги, потому что поставщик не всегда владеет информацией о том, как устроена деятельность потребителя. Также могут отсутствовать возможности для объективного измерения деятельности потребителя, в которой услуга способствует выполнению задач. Поэтому проще и корректнее договариваться об услуге как о предоставлении доступа к ресурсам, описав правила этого предоставления. Например, в некоторых ИТ-службах каталог услуг построен именно так: услуга определяется как информационная система (программно-аппаратный комплекс), и описываются правила предоставления доступа к этой системе (например, доступ гарантируется с определенного времени до определенного времени). Это упрощает согласование ожиданий между поставщиком и потребителем, даже если поставщик не участвует в дальнейшем использовании ресурса потребителем. Автор: Игорь Гутник Рейтинг: 830 Теги: аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление каталогом ИТ-услуг ## [Как определить Time in Process, если поток производства работает не круглосуточно?](https://cleverics.ru/digital/kb-qa/kak-opredelit-time-in-process-esli-potok-proizvodstva-rabotaet-ne-kruglosutochno/) Если поток производства не работает круглосуточно (как это обычно бывает в ИТ), Time in Process должен рассчитываться только с учетом рабочего времени, а не полных календарных дней. Это означает, что период времени от начала до завершения задачи должен быть исчислен в рабочих часах или рабочих днях. Например, задача, которая начала обрабатываться в пятницу вечером и завершилась в понедельник утром, должна учитывать только рабочее время между этими временными точками, исключая выходные дни и нерабочие часы. Для этого необходима автоматизация или специальные правила обработки данных, учитывающие календари сотрудников, что значительно усложняет расчет по сравнению с простым вычитанием времени начала из времени завершения. Автор: Олег Скрынник Рейтинг: 830 Теги: Канбан, WIP-лимиты, общие вопросы менеджмента, экономика и финансы ## [Как правильно организовать процесс по определению требований к системе мониторинга?](https://cleverics.ru/digital/kb-qa/kak-pravilno-organizovat-protsess-po-opredeleniyu-trebovaniy-k-sisteme-monitoringa/) Для правильной организации процесса по определению требований к системе мониторинга необходимо: начинать анализ с уровня ИТ-сервиса, а не с отдельных ресурсов; определять критические ресурсы и их параметры, которые влияют на качество предоставления услуг; устанавливать пороговые значения для этих параметров; разрабатывать требования на основе потребностей бизнеса и конечных пользователей; предусмотреть не только реакцию на возникновение событий, но и на их отсутствие, когда это критично для работы системы. Автор: Евгений Шилов Рейтинг: 830 Теги: бизнес, ценность, бизнес-заказчик, мониторинг, поддержка пользователей, Service Desk, Help Desk ## [Почему в ITSM-системах часто плохо реализовано управление проблемами?](https://cleverics.ru/digital/kb-qa/pochemu-v-itsm-sistemakh-chasto-plokho-realizovano-upravlenie-problemami/) Типовые ITSM-решения адаптированы под управление инцидентами, где ключевые параметры — срочность, приоритет, SLA. Для проблем не предусмотрены специфические поля (например, этапы диагностики) и триггеры. Недостаток гибких механизмов для отслеживания известных ошибок и связи с изменениями приводит к упрощению процесса: проблемы сводят к расширенным инцидентам. Это усиливает путаницу между процессами и снижает качество решения повторяющихся проблем. Автор: Дмитрий Исайченко Рейтинг: 830 Теги: ITSM, SLA, управление инцидентами, управление проблемами, управление процессами, ИТ-процессы, управление уровнем услуг, SLM ## [Сколько человек должно участвовать в проведении диагностики одной продуктовой команды?](https://cleverics.ru/digital/kb-qa/skolko-chelovek-dolzhno-uchastvovat-v-provedenii-diagnostiki-odnoy-produktovoy-komandy/) В проведении диагностики одной продуктовой команды должно участвовать от трёх до пяти человек. Точное количество зависит от выбранной модели управления и особенностей организационной структуры компании. Меньше трёх человек может не обеспечить достаточного охвата и глубины анализа, а более пяти могут создать избыточную нагрузку на команду и привести к снижению эффективности процесса. Оптимальная численность позволяет сохранить баланс между полнотой охвата, качеством анализа и минимальным воздействием на повседневную работу диагностируемой команды. Автор: Олег Скрынник Рейтинг: 830 Теги: командная работа, управление инцидентами, эффективность, оптимизация ## [Как нештатная ситуация помогает определить качество отношений между компанией и клиентом?](https://cleverics.ru/digital/kb-qa/kak-neshtatnaya-situatsiya-pomogaet-opredelit-kachestvo-otnosheniy-mezhdu-kompaniey-i-klientom/) Нештатная ситуация выступает практическим тестом для оценки качества отношений между компанией и клиентом. Если компания сохраняет спокойствие, вежливость и готовность помогать, это показывает, что сотрудничество строится на доверии и уважении. В то же время, если компания начинает вести себя негативно, это указывает на поверхностные или исключительно формальные отношения. Такие моменты позволяют клиенту понять, насколько он действительно важен для компании, и решить, готов ли он продолжать взаимодействие в будущем на основе полученного опыта. Автор: Дмитрий Исайченко Рейтинг: 830 Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление отношениями, взаимодействие, BRM