Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.

6170+
вопросов и ответов

25
авторов

440+
источников

100%
оригинальный контент
Специфика компании определяет, какие риски являются критическими и как они проявляются. Поэтому в разных организациях одни и те же практики ITIL могут применяться с акцентом на разные аспекты. Например, в одной компании реализовавшийся риск может регистрироваться строго как инцидент, а в другой — обрабатываться через внутренние процессы, не связанные с управлением инцидентами.
Почему показатель SPI из методики EVM не подходит для оценки соблюдения сроков завершенных проектов?
Показатель SPI (Schedule Performance Index) из методики EVM не подходит для оценки соблюдения сроков завершённых проектов, так как по окончании проекта, даже с большим запозданием, весь первоначальный объём считается освоенным, и значение SPI автоматически становится равным единице. Это приводит к тому, что SPI не отражает реальное отставание по срокам выполнения проекта. Например, при измерении проекта рытья канавы, когда работы завершаются с задержкой, SPI в конце проекта станет 100%, несмотря на то, что работа была выполнена дольше запланированного срока.
Учет требований к компетенциям исполнителя при оценке трудозатрат на сопровождение CMDB важен по нескольким причинам. Разные группы конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) обслуживают специалисты с различными уровнями квалификации и, соответственно, разной стоимостью рабочего времени. Задачи сопровождения CMDB (первичная регистрация, обновление статусов, аудит и т.д.) имеют различную сложность и требуют различных компетенций от исполнителей. Более высококвалифицированные специалисты обычно имеют более высокую стоимость рабочего времени, что влияет на общие трудозатраты. Поэтому без учета требований к компетенциям исполнителя невозможно точно оценить реальную стоимость выполнения задач и спланировать необходимые ресурсы для сопровождения CMDB.
Сходство заключается в том, что в обоих случаях отсутствие жёстких временных рамок приводит к более качественному результату. При катании на лыжах отказ от планирования конкретного времени позволяет наслаждаться процессом и завершить его тогда, когда достигнуто максимальное удовольствие. Аналогично в ИТ-поддержке сотрудники, не ограниченные строгими временными KPI, могут выделять на запрос столько времени, сколько необходимо для полного решения проблемы, что повышает удовлетворённость пользователей и снижает количество повторных обращений. Оба случая демонстрируют, что жёсткие нормативы часто мешают достижению реальной цели процесса.
Аргументы в пользу первого способа организации взаимодействия линий поддержки (когда инцидент остается на первой линии, а на вторую назначается задание) могут включать сохранение единой точки контакта для пользователя, что упрощает коммуникацию с клиентом. В некоторых случаях это может быть полезно для малых организаций с ограниченным количеством специалистов второй линии. Также этот метод может быть удобен, когда первая линия играет активную роль в координации решения проблемы и должна сохранять полный обзор происходящего. Однако важно отметить, что эти преимущества должны быть четко обоснованы конкретными требованиями организации, а не представлять собой автоматическое следование шаблонам.
Сравнение уровня зрелости с принципом суперпозиции квантовой системы обусловлено тем, что процесс в COBIT может одновременно проявлять признаки разных уровней зрелости, подобно тому как квантовая система может находиться в нескольких состояниях одновременно. Это подчеркивает невозможность четкого, дискретного определения уровня зрелости процесса, поскольку он может частично соответствовать уровням 2, 3 и 4 одновременно. Этот подход напоминает квантовую неопределенность, где система не принимает одно определенное состояние, пока не будет произведено измерение.
Для обеспечения высокого качества решения инцидента необходимо контролировать несколько ключевых компонентов. Прежде всего, важно следить за долей инцидентов, которые были возвращены на доработку, так как это указывает на то, насколько качественно и окончательно были устранены инциденты с первой попытки. Также необходимо уделять внимание количеству коммуникационных итераций между пользователем и поддержкой, стремясь к тому, чтобы инциденты решались с первого обращения (показатель FCR). Кроме того, важно обеспечивать необходимый и достаточный уровень прозрачности процесса решения, включая своевременное информирование пользователя о ходе работ и проактивное уведомление о любых изменениях в статусе инцидента. Качество коммуникации, включая профессиональный этикет и ясность передаваемой информации, также является важным компонентом.