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

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

Частые малые внедрения имеют несколько значительных преимуществ по сравнению с редкими крупными. Во-первых, они снижают Change Risk, поскольку каждое отдельное изменение проще протестировать и отследить последствия. Во-вторых, малые изменения позволяют быстрее получать обратную связь от пользователей и рынка, что ускоряет процесс принятия решений. В-третьих, частые внедрения сокращают размер очереди изменений (Backlog Size), предотвращая накопление проблем и необходимости их укрупнения. В-четвертых, эта практика обеспечивает непрерывное накопление опыта (повышение Change capability) за счет регулярного выполнения однотипных задач и быстрого извлечения уроков из ошибок. В-пятых, малые внедрения упрощают диагностику и устранение проблем, так как при возникновении сбоя проще определить конкретное изменение, вызвавшее проблему. Все эти преимущества формируют положительный цикл, где частые малые релизы приводят к повышению стабильности и скорости разработки одновременно, что является основной идеей DevOps.

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

Статус 'Ожидание' используется для откладывания обрабатываемого объекта (инцидента, обращения, задания) в сторону, когда его обработка невозможна по объективным причинам. Основные случаи применения: ожидание возвращения пользователя из отпуска, ожидание поставки техники, получение ответа от другой службы или специалиста. Цель статуса - структурировать рабочий процесс, отделяя задания, требующие активных действий, от тех, которые временно невыполнимы без внешнего воздействия.

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

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

На начальных этапах внедрения процессы управления изменениями и релизами часто объединяются в один процесс с упором на фазу 'build', что создает иллюзию упрощения. Однако такой подход приводит к ограниченному охвату процессов, фокусируясь только на критической инфраструктуре продуктивной среды, что формально запускает процесс, но не приносит реальной пользы. Это вызывает сопротивление сотрудников из-за бюрократизации без видимых выгод, а также не позволяет формировать реальные требования к смежным процессам, поскольку команда еще борется с основным процессом. По мере развития процессам требуется обогащение: расширение охвата изменений, связь с услугами и появление финансового измерения, что невозможно без развития соседних процессов.

Ассоциация DASA выделяет шесть основных принципов DevOps: 1) Деятельность должна быть ориентирована на заказчика (Customer-Centric Action), включая постоянные инвестиции в продукты и услуги, обеспечивающие максимальную удовлетворённость заказчика, короткие циклы обратной связи и деятельность в духе Lean-стартапов с постоянными инновациями. 2) Ориентация на конечный результат (Create with the End in Mind), что означает отказ от водопадного подхода и процессно-ориентированных моделей в пользу продуктовой ориентации, когда все сотрудники понимают, что создают продукты для реальных заказчиков. 3) Ответственность от начала до конца (End-To-End Responsibility), подразумевающая, что команды отвечают за полный жизненный цикл продукта от концепции до вывода из эксплуатации. 4) Кросс-функциональные автономные команды (Cross-Functional Autonomous Teams), которые должны быть полностью независимыми на протяжении всего жизненного цикла, иметь сбалансированный набор компетенций и T-образные профили специалистов. 5) Постоянное совершенствование (Continuous Improvement), включающее адаптацию к изменяющимся обстоятельствам, сокращение потерь, оптимизацию скорости и затрат, упрощение поставки и постоянное совершенствование продуктов и услуг через экспериментирование и обучение на ошибках. 6) Автоматизируйте всё, что можете (Automate Everything You Can), что охватывает автоматизацию процессов разработки программного обеспечения (непрерывная поставка, непрерывная интеграция, непрерывное развёртывание) и всего инфраструктурного ландшафта (инфраструктура как код).

Вывод заключается в том, что компании по-разному распределяют ресурсы на управление ИТ в зависимости от их текущей стратегии. Тогда как в периоды кризиса и выживания уделяется больше внимания управлению и контролю ИТ (4-8% бюджета), в периоды роста и экспансии акцент смещается на операционные расходы и внедрение новых решений, а доля бюджета на управление ИТ снижается (1-2%). Однако для долгосрочной эффективности важно не просто реагировать на кризисы усилением контроля, а системно развивать управленческие механизмы в периоды стабильности, чтобы иметь возможность пожинать плоды этих усилий в трудные времена.