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

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

25
авторов

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

100%
оригинальный контент
В ITIL за разные аспекты процесса отвечают следующие роли: 1. Дизайнер (технолог/проектировщик процессов): определяет назначение процесса – его базовую функцию в общей процессной модели. 2. Владелец процесса: формирует и актуализирует цели процесса в формате SMART, привязанные к конкретным периодам времени. 3. Менеджер процесса: определяет задачи процесса, обеспечивающие выполнение назначения и достижение целей, и отвечает за оперативное управление процессом. Каждая роль фокусируется на своём уровне детализации: дизайнер на стратегическом, владелец на тактическом, менеджер на оперативном.
Опора на недостоверную статистику может привести к неправильным решениям при выборе ИТ-решений и процессов. Это может вызвать перерасход бюджета, неоправданные ожидания от внедрения и, как результат, снижение доверия к методологиям управления ИТ-услугами. Кроме того, некорректные данные могут быть использованы в маркетинговых целях без фактического подтверждения эффективности.
В организациях с географическим распределением матрица функций и процессов может быть использована для эффективного управления ресурсами на разных территориях. Матрица позволяет определить, какие функции участвуют в реализации каких процессов на каждой территории, и соответственно распределять ответственность. Например, начальник определенной функции на каждой из территорий будет отвечать за предоставление ресурсов, необходимых для реализации процессов на своей территории. Его оценка будет строиться на основе процессных метрик подчиненных. В то же время начальник соответствующей функции в HQ будет оцениваться по агрегированным метрикам региональных начальников. Такой подход обеспечивает единообразие управления процессами на всех территориях, позволяет сравнивать эффективность работы по регионам и своевременно выявлять проблемы. При этом все метрики должны быть приведены к сопоставимому виду (шкала от 0 до 1), что позволяет объективно сравнивать результаты различных регионов.
Услуга как предоставление доступа подразумевает, что клиент получает лишь возможность пользоваться ресурсами (например, входить в жилое помещение), без дополнительных обязательств по поддержанию функциональности отдельных компонентов. Услуга как обеспечение уровня комфорта включает в себя обязательства по обеспечению определенных условий и удобств (например, исправной работы бытовой техники). Эта разница влияет на то, что будет считаться инцидентом и на какие действия будет реагировать поставщик
Ответственность за Outcome лежит на обеих сторонах. Поставщик должен предоставить качественный и подходящий Output, а потребитель — использовать его правильно и вовремя. Например, в случае дня рождения пекарня предоставляет торт (output), но родители должны его купить, поставить на стол и устроить праздник, чтобы дети были счастливы (outcome). Если одна из сторон не выполняет свои обязательства, outcome достигнут не будет.
Для управления задачами разной природы можно использовать вертикальное или горизонтальное разделение ресурсов. Вертикальное разделение предполагает чередование периодов: например, две недели на разработку, неделю на R&D, неделю на технический долг. Горизонтальное разделение заключается в выделении долей трудозатрат (например, 70% на развитие, 20% на эксплуатацию, 10% на исследования), с контролем результатов по каждому направлению. Однако такой подход требует четкого баланса, чтобы избежать формирования силосов и потери общей целостности команды.
Количество затронутых пользователей или точек потребления услуги учитывается через установление порога, при котором инцидент считается значимым. Например, если инцидент затронул менее N пользователей или менее M процентов от общего числа пользователей, это не будет считаться недоступностью услуги. Такой подход позволяет не учитывать мелкие сбои, не влияющие существенно на бизнес, и сосредоточиться на крупных инцидентах, имеющих заметное влияние.
Культура команды существенно влияет на эффективность обработки блокеров в канбан-системе. Если в команде принято прямое и оперативное взаимодействие между коллегами, сигналы о блокерах могут обрабатываться быстрее, чем в рамках ежедневных собраний. Важна также открытость к обсуждению проблем и готовность немедленно реагировать на возникшие препятствия. Эффективная команда способна адаптировать правила визуализации блокеров под свои особенности, определяя оптимальную частоту анализа проблем и методы их оперативного решения, что позволяет минимизировать задержки в потоке задач.
Под «ценностью приоритизации» в управлении инцидентами подразумевается способность системы правильно расставить задачи по мере их значимости и влияния на бизнес. Когда приоритизация работает корректно, это позволяет своевременно выделять ресурсы на наиболее критичные инциденты, минимизируя негативные последствия для организации. Однако если сроки разрешения напрямую рассчитываются по приоритету, теряется смысл самой приоритизации, так как приоритет становится формальным показателем, а не инструментом повышения эффективности работы и оперативности реагирования.
Округление времени до 15 минут приводит к кардинальному искажению данных о реальной загрузке сотрудников. Например, действия, занимающие 1–2 минуты, фиксируются как 15, что многократно увеличивает суммарные трудозатраты. Это мешает объективно оценивать эффективность, выявлять узкие места и распределять задачи. В итоге система учёта перестаёт быть инструментом анализа, а превращается в формальность. Такой подход часто отражает негативное отношение сотрудников к учёту, что может сорвать внедрение всей системы.