Поделиться через


Функции Cloud Center of Excellence

Многие ИТ-организации стремятся к главной цели через достижение гибкости бизнеса и технических возможностей. Cloud Center of Excellence (CCoE) — это функция, которая помогает организациям сбалансировать скорость и стабильность при решении этой задачи.

Структура функции

Модель CCoE требует совместной работы каждого из следующих ресурсов:

  • Внедрение облака (архитекторы решений)
  • Облачная стратегия (руководители программ и проектов)
  • Система управления облаком
  • Облачная платформа
  • Облачная автоматизация

Произведенный эффект

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

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

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

Diagram that shows an analogy for a C C o E paradigm shift.

Оба подхода допустимы. они являются альтернативными представлениями матрицы ответственности и управления. Модель CCoE подойдет при такой технологической стратегии, когда вы хотите создать модель самообслуживания, которая позволит бизнес-подразделениям принимать собственные решения, сохраняя набор рекомендаций и установленные повторяемые элементы управления.

Ключевые обязанности

Основная задача команды CCoE — ускорить внедрение облачных технологий посредством облачных или гибридных решений.

Цель CCoE:

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

Частота собраний

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

Решения и элементы управления

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

В следующей таблице описываются некоторые примеры этого перехода.

Сценарий Решение до CCoE Решение после CCoE
Подготовка экземпляра SQL Server в рабочей среде Группы по работе с сетевыми, ИТ-отделами и платформой данных подготавливают компоненты в течение нескольких дней или недель. Команда, требующая развертывания сервера платформы как службы (PaaS) База данных SQL Azure. Кроме того, развертывание может использовать предварительно подготовленный шаблон для всех ресурсов инфраструктуры как службы (IaaS) в облако в часах.
Подготовка среды разработки Группы разработчиков сети, ИТ,разработки и DevOps согласуются с спецификациями и развертывают среду. Команда разработчиков определяет свои собственные спецификации и развертывает среду на основе выделенного бюджета.
Обновление требований безопасности для улучшения защиты данных Сетевые, ИТ-отделы и группы безопасности обновляют сетевые устройства и виртуальные машины в нескольких средах, чтобы добавить защиту. Облачные инструменты управления используются для обновления политик, которые можно применить сразу ко всем ресурсам во всех облачных средах.

Согласование

Непрерывный процесс согласования — это основной фактор в работе CCoE. Команда CCoE проводит согласование с существующими ИТ-специалистами, чтобы сократить затраты на централизованный контроль. Обратная сторона такого согласования с точки зрения бизнеса — свобода, гибкость и скорость, а преимущества этих результатов для существующих ИТ-отделов реализованы в виде новых решений. Новые решения предоставляют существующей команде специалистов ИТ одно или несколько следующих преимуществ.

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

Взамен этих преимуществ существующий ИТ-отдел может обеспечить следующее:

  • Контроль над процессами утверждения вручную
  • Ощущение стабильности за счет контроля изменений
  • Ощущение безопасности в результате выполнения необходимых повторяющихся задач
  • Ощущение согласованности за счет стабильных связей с существующими поставщиками ИТ-решений

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

Организация успешной работы CCoE

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

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

Ключевые заинтересованные лица

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

Менее очевидна необходимость участия и поддержки со стороны руководства коммерческих направлений. Гибкость бизнеса и время на рынке являются основными мотивациями для формирования CCoE. Таким образом, к ключевых заинтересованных лиц есть свой интерес в этих областях. Примерами таких заинтересованных лиц являются руководители коммерческих направлений, руководители финансовых структур, руководители операционных подразделений и владельцы бизнес-продуктов.

Поддержка заинтересованных лиц в бизнесе

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

  • Ожидаемые бизнес-результаты и цели.

  • Текущие точки боли в ИТ-процессе, такие как скорость, гибкость, стабильность и сложности затрат.

  • Исторические последствия этих точек боли, таких как потерянная доля рынка, конкуренты получают преимущества функций и функций, плохое взаимодействие с клиентами и увеличение бюджета.

  • Возможности улучшения бизнеса, которые блокируются текущими точками боли и операционными моделями.

  • Временные шкалы и метрики, связанные с этими возможностями.

Эти точки данных не играют против ИТ-специалистов. Вместо этого они помогают команде CCoE учиться в прошлом, создавать реалистичные невыполненные работы и планировать улучшение.

Постоянная поддержка и участие заинтересованных лиц

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

В течение первых шести и девяти месяцев работы CCoE мы рекомендуем проводить ежемесячные собрания с участием заинтересованных лиц в сфере ИТ и CCoE. Пусть эти собрания будут неформальными. Простое напомните участникам команды CCoE и ее руководству о важности этой программы — этого может быть достаточным для успешной работы CCoE.

Мы также рекомендуем заинтересованным лицам бизнес-заинтересованным лицам оставаться в курсе прогресса и блокирующих проблем, с которыми сталкиваются команды CCoE. Может показаться, что технические аспекты будут непонятны заинтересованным лицам в коммерческих структурах, однако им нужно видеть прогресс по выполнению плана, чтобы они могли подключаться, если команда CCoE потеряет темп или отвлечется на другие задачи.

Поддержка ит-заинтересованных лиц

Поддержка ИТ-заинтересованных лиц должна включать следующие действия:

  • Поддержка концепции: для успешной работы команды CCoE требуется активное согласование с существующими ИТ-специалистами.

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

  • Сохранение фокуса: ИТ-группы с ограниченными ресурсами могут считать CCoE досадной помехой и лишним бременем.

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

  • Создание буферной зоны: команда CCoE экспериментирует с новыми подходами.

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

Следующие шаги

В модели CCoE должны быть функции облачной платформы и облачной автоматизации. Следующий шаг — выравнивание функций облачной платформы.