Да, кратное ускорение возможно без смены персонала, включая программистов, аналитиков, тимлидов и руководителей. Ключевым является фокус на изменении системных аспектов работы, а не на замене людей. Необходимо сосредоточиться на четырёх направлениях: перестроить организацию ресурсов от иерархии к более самостоятельным командам; провести архитектурные изменения для поддержки быстрого цикла разработки; наладить приоритизацию входящих задач с фокусом на бизнес-ценные инициативы; внедрить систему организации производства с управлением потоком создания ценности и ограничениями на текущую работу. Пример деловой игры 'Проект Феникс' показывает, что те же люди, изменив подход к работе, могут ускориться в 15-25 раз без изменения состава команды.

Внедрение расширенного жизненного цикла инцидента позволяет анализировать и улучшать ряд ключевых показателей: время обнаружения инцидента, время диагностики, время устранения сбоя, время восстановления и время возобновления нормальной работы. Это даёт возможность более детально контролировать, какие аспекты процесса требуют улучшения, и целенаправленно оптимизировать их. Например, можно сократить время обнаружения за счёт автоматизации мониторинга или уменьшить время диагностики с помощью улучшенных методов анализа.

Термин OLA может быть избыточным, потому что содержательно OLA не отличается от SLA, а является всего лишь SLA с другой стороны. Если рассматривать цепочку создания ценности, то то, что для одного участника выглядит как OLA, для другого будет SLA. Примеры из ITIL Service Design показывают, что предлагаемые SLA и OLA очень похожи. Поэтому OLA как отдельная концепция не добавляет ценности и может только запутать при реализации, так как теряет четкое определение и аргументированное обоснование, что и приводит к путанице в практическом применении.

Менеджеры проектов чаще выделены, чем менеджеры ИТ-процессов, потому что проекты имеют четкие сроки, цели и результаты, что делает их более заметными и контролируемыми для бизнеса. Организации часто сосредотачиваются на краткосрочных задачах и достижении конкретных результатов, тогда как управленческая работа над процессами воспринимается как фоновая и менее приоритетная. Кроме того, реализация проектов может напрямую коррелировать с доходами или конкурентными преимуществами, что приводит к выделению ресурсов на управление проектами. В то же время процессное управление часто рассматривается как поддерживающая функция без явного «кейса» для бизнес-лидера.

При экстренных изменениях часто нарушаются или сокращаются следующие стандартные этапы процесса управления изменениями: тестирование в тестовой среде (тестирование проводится непосредственно в продуктивной среде), стандартная процедура согласования (применяются упрощенные процедуры или согласование проводится после внедрения), и своевременное документирование (оформление изменений происходит задним числом). Это приводит к увеличению рисков, связанных с некорректной реализацией изменений и возможными последствиями для продуктивной среды.

Альтернативный алгоритм снижает влияние действий других групп путём нормировки не на общее время обработки инцидента Ti, а на установленный срок решения инцидента Ti0. Весовой коэффициент wi для просроченных инцидентов определяется как отношение времени обработки силами данной группы (ti) к сроку решения (Ti0), но не менее 1. Рейтинг ответственности ri рассчитывается по формуле: ri = (ti/Ti0) * (1 - 1/wi) для просроченных инцидентов и ri=0 для решенных в срок. Это позволяет точнее учитывать вклад конкретной группы в просрочку, исключая искажающее влияние задержек на этапах, где данная группа не участвовала.

Flow Efficiency может ошибочно показывать завышенные значения (90% и более) из-за методологических ошибок в расчете. Например, если учитывать только рабочее время, но неправильно определить время активной работы (Touch Time), то числитель может оказаться неадекватно большим. Также часто возникает проблема, когда при совместной работе нескольких сотрудников время работы учитывается не корректно (например, суммируются часы всех участников, тогда как фактически задача выполнялась параллельно). Кроме того, некоторые автоматизированные инструменты могут неправильно интерпретировать изменения статусов задач, принимая за активную работу периоды ожидания. Все эти факторы приводят к искажению результата и созданию иллюзии сверхвысокой эффективности, не соответствующей реальности.

Компании стремятся к самостоятельному развитию средств автоматизации, чтобы не зависеть от решений вендоров и иметь возможность адаптировать системы под свои уникальные потребности. Это позволяет быстрее внедрять изменения, гибко реагировать на запросы бизнеса и избегать ограничений, накладываемых настроенной функциональностью коммерческих продуктов.

Координатор проблем — это специалист, который в более сложных организациях берет на себя часть обязанностей по управлению проблемами. Его основные обязанности включают рассмотрение представленной информации о возможных проблемах, их анализ, а также рутинные задачи, связанные с закрытием проблем. Координатор проблем занимается повседневным управлением, позволяя менеджеру по управлению проблемами сосредоточиться на более стратегических аспектах, таких как выявление корневых причин и разработка долгосрочных решений.

В контексте улучшения процессов с использованием PDCA KPI (ключевой показатель эффективности) представляет собой количественный метрический показатель, с помощью которого оценивается успешность внедренных изменений. Например, при улучшении процесса управления инцидентами KPI может включать среднее время решения инцидента, уровень удовлетворенности пользователей или количество инцидентов, решенных в установленные сроки. На этапе Планируй устанавливаются целевые значения KPI, на этапе Проверяй сравниваются фактические показатели с плановыми, а на этапе Корректируй принимаются решения о дальнейших действиях на основе полученных данных KPI.