Антипаттерны облачной организации
Клиенты часто сталкиваются с антипаттернами внедрения облака в своей организационной структуре. Многие факторы могут вызвать следующие проблемы:
- Наборы инструментов
- Партнеры
- Инженеры
- Некорректные ИТ-отделы
Важно понимать роль этих факторов в успешном сценарии внедрения облака.
Антипаттерн: рассматривать ИТ как центр затрат
Многие компании рассматривают ИТ-отделы как центры затрат. Такой подход может привести к тому, что ИТ-служба не добавляет ценности в компанию. Когда сотрудники рассматривают ИТ скорее как поставщика, а не как помощника, они могут утратить мотивацию. Компании также трудно привлечь подходящих специалистов. Снижение мотивации и длительные сроки жизненного цикла приводят к результатам. Качество работы ит-специалистов может страдать, и силосов и фифедомов может развиваться.
Пример. Рассматривать ИТ как центр затрат
Корпорация управляет ит-отделом как центром затрат, подотчетным главному финансовому директору (CFO). Руководящий совет воспринимает ИТ как медленного поставщика услуг, который является одним из крупнейших источников затрат компании. Руководящий совет не осознает, что бизнес-единица мобильности потребляет большую часть ресурсов, заказанных ИТ-отделом. ИТ-отдел приобретает центр обработки данных для использования всеми бизнес-единицами, но мобильное подразделение получает этот слишком крупный ресурс. Совет не рассматривает ИТ как катализатор или партнера.
Предпочтительный результат: рассматривать ИТ как средство поддержки
Вместо управления ИТ-отделом в качестве центра затрат рассмотрите один из следующих подходов:
- Чарджбэк: бизнес-подразделения учитывают ИТ-расходы как операционные расходы в своих бюджетах.
- Обратная связь или обратная осведомленность: ИТ-функции в качестве агента. В отчетах для бизнеса ИТ-служба приписывает все прямые затраты соответствующим бизнес-единицам.
Используйте облако в качестве инструмента для повышения стоимости и прозрачности бизнеса. Например, реализуйте дисциплину "Управление затратами" для повышения прозрачности затрат. Затем вы будете более осведомлены о стоимости различных бизнес-единиц. Вы будете видеть ИТ-отдел как инструмент для этих подразделений.
Чтобы повысить прозрачность, сосредоточьтесь на видимости, подотчетности и оптимизации при переходе в облако. Дополнительные сведения см. в статье Создание организации, ориентированной на затраты.
Антипаттерн: Инвестировать в новую технологию без участия бизнеса
ИТ-отделы часто инвестируют значительные людские и финансовые ресурсы в создание и развертывание надежных платформ и наборов инструментов. Но иногда ИТ-подразделениям не удается рассмотреть и их потребности во время этапов проектирования и разработки. Это упущение приводит к новым платформам с минимальной релевантностью для бизнес-подразделений. Затем сотрудники нерешительны принять новую технологию. Плохое или медленное внедрение может иметь последствия. Разочарование накапливается в ИТ, когда бизнес-подразделения не используют его платформы.
Пример. Настройка платформы без участия бизнес-подразделений
ИТ-отдел фирмы по анализу данных настраивает и модифицирует платформу Azure без участия бизнес-подразделений. При использовании платформы разработчики бизнес-подразделений:
- Убедитесь, что у них нет разрешений, необходимых для развертывания.
- Может использовать только ограниченное количество служб.
- Выдача запросов в службу поддержки, которые продлиют циклы утверждения.
- Начните сомневаться в новой платформе.
В конце концов, некоторые разработчики покупают подписку Azure самостоятельно, чтобы избежать проблем с правилами и правилами ИТ. Появляется теневой ИТ. Так как фирма имеет мало контроля над теневым ИТ,высокий риск безопасности возникает.
Предпочтительный результат: участие бизнес-подразделений в принятии решений
Не создавайте ИТ-изолированные структуры при развертывании облачной платформы, готовой для корпоративного использования. Привлекайте разработчиков и технических лиц, принимающих решения (TDM) из бизнес-подразделений к процессам дизайна и разработки. Чтобы улучшить внедрение платформы, прослушивайте входные данные бизнес-подразделения.
Ознакомьтесь с Начало работы с целевыми зонами корпоративного масштаба в рамках Cloud Adoption Framework для лучших практик и принципов проектирования Azure, которые повышают скорость внедрения и приспособлены для разработчиков. Найти оптимальный баланс между соответствием и гибкостью. Например, найти способы удовлетворения политик управления и безопасности, сохраняя гибкие среды разработки.
Антипаттерн: Аутсорсинг основных бизнес-функций
Партнеры-консультанты и поставщики управляемых услуг (MSPs) могут играть важную роль в облачном путешествии. Но компании должны заботиться о том, что работа партнеров и MSPs не обеспечивают большую ценность в их бизнесе. Компании, которые передают на аутсорсинг обязанности MSP или облачным консультантам, не должны зависеть от этих поставщиков.
Пример. Внедрение и миграция облачных решений для аутсорсинга
Исследовательский институт имеет критически важный проект миграции в облако. Чтобы сократить процесс внедрения облака, он нанимает MSP для создания основы Azure и реализации миграции. Вместо изучения этапа использования облачных технологий и наращивания профессиональных навыков институт решает передать всю ответственность за платформу Azure MSP. Поскольку институт не имеет знаний о облачных технологиях и Azure, MSP принимает все решения, делая институт зависимым от MSP.
Предпочтительный результат: возложить ответственность за критически важные области проектирования на компанию
Имейте в виду аутсорсинг как хорошую стратегию сокращения затрат. Но принимайте решения в вашей компании, которые касаются этих критически важных областей проектирования.
- Управление
- Риск
- Согласие
- Идентичность
Сохраните ответственность в рамках компании за эти и другие области, которые чрезвычайно важны для ваших активов безопасности. Используйте внешние партнеры для ускорения процесса внедрения. Но, чтобы не зависеть от поставщиков, не передавайте на аутсорсинг всё.
Антипаттерн: нанимайте технических руководителей решений вместо разработки облачных инженеров
Компании придают важность подбору подходящего персонала. В результате они часто нанимают или создают TDM во время начальных этапов принятия облачных технологий. Успех облачных решений зависит от ТИМ. Но более важно, что внедрение облака нуждается в инженерах со всеми практическими умениями и глубокими техническими навыками.
Пример: нанимайте только TDM.
Исследовательский институт нанимает нескольких менеджеров по внедрению облачных технологий для руководства своей облачной трансформацией. После завершения начального этапа высокоуровневой концепции начинается этап реализации. Затем институт понимает, что облачные развертывания ведут себя не так, как локальные развертывания. Для правильной реализации концепций инфраструктуры как кода (IaC) и управления, основанного на политике, требуется дополнительное усилие в области облачной инженерии.
Предпочтительный результат. Использование облачных инженеров для этапа реализации
Помните, что инженеры необходимы для правильной реализации концепций облачной автоматизации и целевой зоны. Обязанности и задачи могут значительно измениться при внедрении моделей служб. Перенеся обязанности на облачного провайдера, вы можете быстрее перейти в эксплуатацию. Вы также можете использовать TDM для принятия решений, но использовать способных облачных инженеров для задач, требующих глубоких технических знаний. Затем вы узнаете о преимуществах, которые предоставляет облако.