Рационализация цифровых активов

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

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

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

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

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

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

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

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

Инструкции по созданию списка вопросов качественного анализа см. в разделе Подходы к планированию цифровых активов.

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

Рационализация в корпоративном масштабе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка предположений

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

Прекращение использования ресурса

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

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

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

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

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

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

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

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

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

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

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

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

Критерии бизнеса

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

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

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

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

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

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

Миграция

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

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

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

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

Подход "Сила десяти"

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

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

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

Улучшение процесса

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

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

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

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

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

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

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

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

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

Сопоставление моделей затрат на цифровые активы