Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
В базовой схеме оценки уровень влияния для случая, когда у одного сотрудника недоступна только часть функционала ИТ-услуги, считается наименее критичным, то есть самым простым случаем. Например, если сотруднику не работает печать, но все остальные функции доступны, такой инцидент должен решаться в последнюю очередь по сравнению с более серьезными проблемами. Однако на практике эти правила часто модифицируются, учитывая контекст: если для сотрудника в данный момент критически важно распечатать отчет, несмотря на то, что остальное работает, то уровень влияния может быть повышен в соответствии с дополнительными правилами, учитывающими бизнес-процессы и временные рамки.
В контексте прозрачности для процесса Управления инцидентами (INC) упоминается критический фактор успеха: «Улучшать прозрачность и коммуникации в работе процесса». Это означает, что процесс должен быть организован так, чтобы обеспечивать своевременную и понятную информацию всем заинтересованным сторонам о текущем состоянии инцидентов. Данный CSF направлен на минимизацию неопределённости для пользователей и подразумевает создание эффективных механизмов коммуникации, позволяющих быстро и удобно предоставлять информацию о статусе инцидентов.
Если после попыток делегирования задач у руководителя в RACI-матрице все еще остались R-позиции, необходимо: 1. Проанализировать эти задачи на предмет их критичности и объема работы - возможно, они действительно требуют личного участия руководителя. 2. Для задач, которые все же требуют личного участия, определить, можно ли разделить их на подзадачи, часть из которых можно будет делегировать. 3. Если задача должна выполняться несколькими людьми (включая руководителя), четко определить, кто отвечает за организацию процесса выполнения, а кто выполняет конкретные операции. 4. Рассмотреть возможность использования расширенной RASCI-матрицы, где можно отделить организатора работы от тех, кто просто участвует в исполнении (S - Supports). Это позволит руководителю перейти из позиции R (Responsible) в позицию, связанную с контролем (I или C), сохранив необходимый уровень влияния на процесс без непосредственного выполнения операций. 5. Регулярно пересматривать RACI-матрицу, так как со временем могут появиться сотрудники, готовые взять на себя больше ответственности, что позволит дальнейшее делегирование.
Деловые игры полезны для оценки эффективности команд, поскольку имитируют реальные рабочие процессы в контролируемой среде. Они позволяют наблюдать, как команды принимают решения под давлением, распределяют ресурсы и достигают поставленных целей. Кроме того, проведение параллельных игр для разных команд даёт возможность сравнить подходы и результаты, что может служить основой для обсуждения лучших практик и выявления областей для улучшения.
В ITIL указывается, что если изменение является частью релиза, то его построение, тестирование и развёртывание координируются процессом управления релизами. Это означает, что процесс управления релизами берёт на себя общее руководство всеми изменениями, входящими в состав данного релиза. В результате, при планировании и реализации нескольких связанных изменений, которые должны быть внедрены одновременно, управление релизом становится центральным процессом, обеспечивающим успешное внедрение всех компонентов в согласованном порядке. Координация происходит на уровне процесса в целом, а кто конкретно выполняет эту координацию, зависит от внутренней структуры организации.
Основное ограничение, которое может повлиять на использование CMDB для экономических расчётов, — это особенности программного обеспечения, используемого для реализации ITSM-процессов. Некоторые инструменты могут быть спроектированы таким образом, что CMDB и инструменты финансового учёта разделены и не интегрированы должным образом. Например, некоторые системы могут не поддерживать необходимую гибкость в конфигурации связей или не позволять корректно учитывать виртуальные ресурсы. Однако эти ограничения обусловлены выбором конкретного программного продукта, а не самой концепцией CMDB, поэтому при правильном выборе ITSM-инструмента можно использовать CMDB для экономических расчётов без дополнительных сложностей.
ISO 22301 играет ключевую роль в системе международных стандартов по управлению непрерывностью, так как является основным требуемым стандартом, на который ссылаются другие документы. Он устанавливает общие требования к системе управления непрерывностью бизнеса и служит основой для разработки руководств по применению (таких как ISO 22313), специализированных стандартов (например, ISO 27031) и сводов знаний от различных институтов (таких как GPG от BCI и Professional Practices от DRII).
Владелец продукта играет ключевую роль в создании ценности, обеспечивая прозрачность работы команды и ее результатов. Он должен быть тем связующим звеном, которое не только управляет бэклогом, но и предоставляет команде доступ к реальной обратной связи от пользователей, помогая участникам увидеть эффект их работы на окружающий мир. Владелец продукта должен вовлекать команду в исследовательские активности по идентификации и выявлению новой ценности, а не изолировать разработчиков от процесса формирования задач. Важная функция владельца продукта - способствовать совместному принятию решений и помогать команде осознавать, какую именно ценность они создают вместе с пользователями, а не просто механически выполнять задачи по разработке отдельных фич.
Основные факторы, мешающие клиентам оставлять отзывы: недостаток времени, сложность форм обратной связи, отсутствие видимой пользы от участия, негативный опыт предыдущих взаимодействий (например, игнорирование замечаний). Многие потребители считают, что их мнение не повлияет на качество услуги, поэтому предпочитают не тратить усилия. Кроме того, длинные анкеты или технические барьеры (например, необходимость регистрации) снижают мотивацию к участию.
Подробная диагностика рабочих процессов необходима при переходе к гибкому управлению, потому что без понимания действительной ситуации в компании невозможно организовать эффективное управление. Диагностика помогает выявить скрытые проблемы, которые изнутри не выглядят как проблемы, но мешают эффективной работе. Например, может быть выявлено, что до 50% задач в бэклоге не несут бизнес-ценности, или что показатель дефектов в 15-50% ошибочно считается нормой. Диагностика позволяет точно определить проблемные зоны, оценить текущую зрелость процессов и разработать четкую последовательность шагов для перехода к гибкому управлению без нарушения работоспособности организации. Чем четче проявлены проблемы, тем проще и успешнее будет трансформация.