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

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

25
авторов

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

100%
оригинальный контент
Управленческие, основные и обеспечивающие процессы образуют взаимосвязанную систему внутри организации. Управленческие процессы определяют стратегию и цели, на основе которых формируются основные процессы, создающие ценность для клиентов. Обеспечивающие процессы поддерживают обе эти категории, предоставляя необходимые ресурсы и инфраструктуру. Эффективная организация требует слаженной работы всех трех типов процессов: управленческие процессы направляют деятельность, основные процессы создают продукцию или услуги, а обеспечивающие процессы гарантируют, что все работает без сбоев. Нарушение баланса между этими процессами может привести к снижению эффективности всей организации.
SLA способствует повышению ответственности подразделений компании, так как чётко фиксирует обязательства каждого подразделения перед другими внутренними клиентами. Поскольку показатели и сроки выполнения обязательств измеримы и конкретны, подразделения не могут уклоняться от ответственности за невыполнение задач. Это создаёт систему взаимной ответственности, где каждое подразделение вынуждено учитывать потребности и ожидания своих внутренних клиентов. Кроме того, регулярный мониторинг выполнения SLA позволяет выявлять проблемы на ранних стадиях и оперативно реагировать на них, что дополнительно повышает ответственность за результаты работы.
Для учета различного влияния инцидентов на бизнес при расчете метрики времени реакции можно использовать два подхода: первый - выполнять расчет метрики отдельно для каждого уровня влияния или приоритета инцидента, что позволяет проанализировать эффективность реакции на каждый категорий инцидентов; второй - использовать формулу взвешенного среднего, где весом (Wi) выступает уровень влияния или приоритет инцидента: Rw = (Σ(Ti*Wi)) / (Σ((Ti+Qi)*Wi)). Это позволяет получить более точную оценку общей эффективности процесса с учетом бизнес-значимости каждого инцидента.
При усложнении схемы оценки влияния инцидентов важно учитывать следующие аспекты: 1) Схема должна оставаться понятной и простой в использовании для сотрудников первой линии поддержки. 2) Не следует создавать избыточное количество правил и исключений, которые будут затруднять быстрое принятие решений. 3) Дополнительные критерии (VIP-пользователи, критичные периоды) должны быть четко определены и документированы. 4) Важно провести обучение сотрудников новым правилам. 5) Схема должна периодически пересматриваться на предмет эффективности и актуальности. Оптимально стремиться к балансу между точностью оценки и практической применимостью схемы.
Некоторые организации бездумно заменяют проектный менеджмент на продуктовый из-за моды и популярности последнего в последние годы. Проектный менеджмент сейчас не в фаворе - его считают жестким и неудобным из-за фиксированных результатов, сроков и бюджетов. При этом продукт-менеджмент представляется как более гибкий подход, ориентированный на создание ценности в условиях неопределенности. Однако многие организации не анализируют границы применимости подходов и просто 'приклеивают' продуктовый менеджмент к тем областям, где он не подходит, например, к внутренним ИТ-системам с фиксированными требованиями и без необходимости в активном развитии продукта для внешних клиентов. Это приводит к неэффективному использованию ресурсов и инструментов.
WIP-лимиты (ограничения работы в процессе) напрямую связаны с отсутствием этапа 'Отложено' в потоке. Если задача может быть отложена, она все равно занимает слот в потоке, что может привести к превышению WIP-лимитов. Чтобы сохранить производительность, команды либо будут вынуждены уменьшить количество задач в потоке (что обычно невозможно из-за сохраняющегося давления на входе), либо отказаться от идеи слотов и WIP-лимитов в целом. Соответственно, без WIP-лимитов невозможна вытягивающая система, а без вытягивающей системы нет потока, а без потока нет высокоэффективной работы.
Альтернативный метод оценки эффективности потока заключается в проведении практического упражнения: представить поток и для каждого этапа процесса прикинуть, сколько времени задача проводит на этом этапе и сколько времени на ней фактически выполняется работа. Суммируя эти показатели и разделив суммарное время работы на суммарное время всего процесса, можно получить оценку эффективности потока. Хотя это не точный расчет, такие оценки часто удивляют команды, показывая реальный уровень эффективности в 10-25%, в то время как субъективные ощущения предполагают гораздо более высокие показатели (75-80%). Такой подход помогает выявить проблемные зоны, даже не обладая точными данными.
Оценка эффективности потока обычно предполагает экспертное приближение: команды интуитивно или на основе наблюдений определяют, сколько времени задачи проводят в активной работе и сколько времени в ожидании. Точный расчет же требует сбора и анализа конкретных данных по времени каждой задачи. В реальности большинство попыток «точного» расчета Flow Efficiency оказываются упрощенными оценками из-за сложности точного измерения Touch Time и Time in Process. Как правило, результаты оценки дают более реалистичные и полезные для команды показатели (в районе 10-25%), тогда как «точные» расчеты могут приводить к абсурдно высоким значениям (90% и более), не отражающим действительное положение дел.
Важно, чтобы переход руководителей ИТ в бизнес был с неопределённым сроком, потому что если срок будет фиксированным, руководитель может просто переждать время на новой должности, не пытаясь глубоко погрузиться в бизнес-проблемы. Неопределённый срок заставляет руководителя серьёзно заниматься бизнес-задачами, так как возвращение в ИТ возможно только при наличии конкретного и реализуемого плана улучшений. Это гарантирует, что полученный опыт не будет потерян, а переход не станет просто формальностью или пугалом.
Так называемые кризисные ситуации, например, уход ключевого сотрудника или эскалация проблемы со срывом сроков проекта, часто являются следствием системных проблем управления, а не настоящих непредвиденных кризисов. Они возникают из-за неумения правильно планировать и организовывать работу, отсутствия управления рисками и чрезмерно больших размеров проектов. Такие ситуации предсказуемы и могут быть предотвращены при наличии здоровой системы управления с правильно организованным планированием, небольшими задачами и стабильными процессами. Настоящие кризисы по своей природе непредсказуемы, тогда как указанные ситуации являются результатом неэффективного управления и отсутствия системного подхода к организации работы.