Для достижения кратного ускорения необходимо проработать четыре ключевых направления: 1) принцип организации ресурсов - переход от иерархической структуры к более самоорганизованным, почти самодостаточным командам; 2) архитектурная и технологическая составляющая - устранение монолитности систем, внедрение практик CI/CD и модульная архитектура; 3) работа со входом - систематизация и приоритизация запросов, фокус на бизнес-ценные задачи вместо технического долга и рутины; 4) организация производства - внедрение управления потоком создания ценности, ограничение текущей работы (WIP-лимиты), методичное устранение потерь через Канбан-метод. Эти направления взаимодополняют друг друга и необходимы в совокупности для достижения кратного ускорения.

Для сокращения среднего времени решения инцидентов необходимо проанализировать этапы их обработки, выявить узкие места и оптимизировать процессы. Согласно ITIL методологии, стоит использовать подход Expanded incident lifecycle для детализации этапов решения инцидента и поиска возможностей для ускорения на каждом этапе. Также критически важно внедрять процесс управления проблемами, так как его влияние на сокращение количества инцидентов часто недооценивают. Даже при одинаковой производительности персонала, сокращение общего числа инцидентов благодаря управлению проблемами существенно снизит среднее время решения, так как уменьшает очередь и перегрузки, связанные с неравномерным поступлением инцидентов.

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

Основная цель внедрения гибких практик в разработке ПО - достижение кратного увеличения скорости поставки решений. Это связано с тем, что бизнес работает в конкурентной среде с высокой неопределенностью, где быстрое получение новых возможностей от собственного ИТ является вопросом выживания. При этом гибкие практики направлены именно на кратное ускорение (а не на прибавку в 10-50 процентов), так как преобразования на сложном ИТ-ландшафте стоят очень дорого и без кратного ускорения не окупаются.

Сокращение времени решения инцидентов достигается за счет организации системы обращения за технической поддержкой, которая минимизирует временные затраты на сбор информации и маршрутизацию запросов. Это реализуется через специальную программу, заменяющую традиционные способы связи (email и телефон). Программа предусматривает последовательное заполнение пользователем контекстно-зависимых вопросов, автоматический сбор технических данных, правильную классификацию запроса по ИТ-услугам и его отправку в соответствующую группу специалистов. Подобный подход позволяет достичь значительного сокращения времени решения, как показывает практика - до 40% за полгода при полном переходе на новые процессы.

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

Большая часть обращений (порядка 60%) связана с работой специфических ИТ-систем, которые требуют глубоких технических знаний. Первая линия не обладает необходимой квалификацией даже для грамотного общения с пользователем по таким вопросам, не говоря уже об их решении. Это приводит к тому, что подавляющее большинство сложных случаев изначально должны обрабатываться специалистами второй линии, минуя первую линию, которая в текущих условиях не может быть эффективным фильтром для обращений. Ситуация усугубляется небольшим количеством сотрудников на первой линии и отсутствием возможности увеличения штата.

Для значительного увеличения количества обращений через портал самообслуживания необходимы, во-первых, доступность web-интерфейса для всех пользователей. Например, не во всех компаниях работники могут использовать компьютеры для подачи обращений, особенно на производственных предприятиях, где сотрудники работают за станками или с оборудованием и не имеют персональных компьютеров. Для них телефон остается единственным удобным способом связаться с поддержкой. Во-вторых, важна подготовленность пользователей. Если данные, вводимые пользователями, будут использоваться для автоматической маршрутизации обращений, необходимо, чтобы эта информация была точной. Хотя интерфейс может быть дизайнерски продуманным, чтобы минимизировать ошибки, важно также, чтобы пользователи понимали специфику использования ИТ в своей работе. Эта подготовка может проходить при приеме на работу или в ходе обучения, но в некоторых ситуациях, например, при высокой текучести кадров, она может быть экономически нецелесообразной.

В PIR применяются количественные и качественные критерии: соблюдение бюджета и сроков, достижение целевых метрик (например, рост производительности на 15%), уровень удовлетворенности пользователей, соответствие требованиям и анализ рисков. Также оцениваются непредвиденные последствия и влияние на другие процессы. Для каждого критерия устанавливаются пороговые значения, и на основе их сравнения с фактическими результатами определяется успешность внедрения.

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