Рационализация цифрового пространства

Рационализация облака — это процесс оценки ресурсов для определения оптимального подхода к их размещению в облаке. После определения подхода и агрегирования инвентаризации можно начать рационализацию облака. Рационализация облака обсуждает наиболее распространенные варианты рационализации.

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

Традиционное представление рационализации

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

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

Количественный анализ: В дереве принятия решений количественные вопросы управляют первым слоем решений. Ниже приведены распространенные вопросы:

• Используется ли ресурс сегодня?
• Если да, то оптимизировано ли это и правильно ли задан размер?
• Какие зависимости существуют между ресурсами? Эти вопросы жизненно важны для классификации инвентаризации.

Качественный анализ: Следующий набор решений требует человеческого интеллекта в виде качественного анализа. Вопросы, которые часто возникают здесь, связаны с конкретным решением и могут быть решены только заинтересованными сторонами и продвинутыми пользователями. Эти решения обычно задерживают процесс, замедляя вещи значительно. Этот анализ обычно потребляет 40–80 часов FTE для каждого приложения.

Рекомендации по созданию списка качественных вопросов анализа см. в статье "Подходы к планированию цифровых активов".

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

Рационализация на уровне предприятия

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

Хотя полная рационализация является конечным состоянием и отличным направлением для развития, она редко обеспечивает высокий ROI (рентабельность инвестиций) относительно времени и энергии, которые требуются.

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

В остальной части этой статьи описывается альтернативный подход, известный как добавочная рационализация.

Добавочная рационализация

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

Инвентаризация: уменьшение точек данных обнаружения

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

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

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

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

Количественный анализ: упрощение решений

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

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

Качественный анализ: временные предположения

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

Например, если варианты ограничены переносом или выводом из эксплуатации, бизнесу нужно ответить только на один вопрос во время первоначальной рационализации: следует ли вывести актив из эксплуатации.

"Анализ предполагает, что пользователи активно не используют этот ресурс. Мы точно правильно поняли это, или мы что-то упустили? Как правило, такие двоичные вопросы проще анализировать с помощью качественного анализа.

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

Испытание предположений

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

Вывод активов из эксплуатации

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

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

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

Корректировки программы

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

В примере миграции IaaS, приведенном в этой статье:

• Попросите команду DevOps определить ресурсы, которые уже являются частью автоматизации развертывания, и удалить эти ресурсы из основного плана миграции.

• Попросите команды по анализу данных и R&D определить ресурсы, которые создают новые потоки доходов и удалить их из основного плана миграции.

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

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

Выберите первую рабочую нагрузку

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

Бизнес-критерии

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

Технические критерии

Выберите рабочую нагрузку с минимальными зависимостями, которую можно переместить как небольшую группу ресурсов. Рекомендуется выбрать рабочую нагрузку с определенным путем тестирования, чтобы упростить проверку.

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

Качественный анализ

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

Миграция

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

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

Планирование выпуска

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

Мощность 10

Традиционный подход к рационализации пытается удовлетворить все обозримые потребности. К счастью, план для каждого приложения часто не требуется для запуска пути преобразования. В инкрементной модели подход «Power of 10» обеспечивает хорошую отправную точку. В этой модели команда по облачной стратегии выбирает первые 10 приложений, которые необходимо перенести. Эти десять рабочих нагрузок должны содержать смесь простых и сложных рабочих нагрузок.

Создание первых невыполненных работ

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

Развивать процесс

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

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

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

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

Конечное состояние

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

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

Дальнейшие действия

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