Каждый IT-директор ежедневно сталкивается в будничной работе с решением следующих вопросов: оптимизация бюджета IT-департамента, повышение производительности труда IT-департамента, оптимизация IT-процесса (поиск более гибких решений как технологически, так и финансово для внутреннего бизнес-заказчика). В большинстве кейсов эти задачи решаются благодаря использованию облачных технологий. Менеджер отдела облачных сервисов OnCloud.ru Сергей Афанасьев выявил 5 основных нюансов, которые следует учитывать IT-директору при переводе IT-инфраструктуры к облачному сервис-провайдеру, и подготовил материал, который должен помочь IT-директору в выборе критериев и квалифицированной оценке облачного провайдера.
Нюанс №1. Управленческий.
Миграция в облако означает перевод IT-инфраструктуры компании на другую бизнес-модель: переход от CAPEX к OPEX. Что это значит для IT-директора? Отказ от дорогих разовых покупок оборудования/ПО, сокращение бюджета на поддержку IT-инфраструктуры и оптимизация штата IT-персонала. Во многих организациях зарплата IT-директоров растет в зависимости от количества подчиненных, расширения парка собственного оборудования и ПО – такая матрица ответственности противоречит самой идее аутсорсинга и миграции в облако. Первое, что должен сделать IT-директор перед принятием решения о миграции, - взвесить личную мотивацию.
Второе - провести детальные переговоры с сервис-провайдером: донести до него, что именно требуется перенести в облако, на каком уровне SLA, обозначить границы ответственности между заказчиком и сервис-провайдером. Профессиональный облачный провайдер должен проявить максимальную проактивность в предоставлении помощи и консультаций на этапе оценки предстоящих работ, особенно при выводе в облако критичных для бизнеса заказчика приложений или сервисов.
Третье, о чем стоит помнить: вывод инфраструктуры заказчика на аутсорсинг в облако порой, как следствие, подразумевает сокращение штата действующих сотрудников и их замену на более квалифицированных и дорогостоящих. Возникает вопрос: готов ли к этому IT-директор?
Нюанс №2. Технологический.
При переходе на облачную модель работы на плечи IT-директора ложится дополнительная ответственность: ему предстоит сделать сайзинг ресурсов, которые требуется перенести в облако, выбрать провайдера, провести сравнение цен услуг на рынке. Ко всему прочему IT-директор должен хорошо разбираться в функционировании IT-процессов внутри своей организации.
Не все бизнес-критичные приложения рекомендуется переносить в облачную среду. Выбирая модель гибридного облака, IT-директор вправе попросить провайдера о помощи: например, закупить железо и настроить Oracle или SAP из облака. Облачный провайдер должен иметь необходимые компетенции для предоставления подобных решений «под ключ».
Неправильный сайзинг, стремление сэкономить, отсутствие четкого понимания, какие ресурсы являются бизнес-критичными, их перенос на низкий уровень SLA, выбор недобросовестного провайдера могут сказаться на работе всей компании, а ответственность за риски будет нести IT-директор. Работа с облаками требует более широких компетенций от IT-директора, желания разобраться в новых процессах и досконально изучить тему.
Существуют приложения, которые не рекомендуется размещать в публичном облаке по тем или иным причинам. В таком случае заказчик может разместить приложения на физических серверах, подключённых к публичному облаку и, при необходимости, оперативно изменять выделенные для себя виртуальные мощности.
Для справедливости отметим, что большинство названных проблем можно избежать при выборе добросовестного облачного провайдера, который разделит технологические риски с IT-директором, поможет разобраться в нюансах и обеспечит максимально гладкий перевод информационных систем компании в облако.
Нюанс №3. Кадровый.
Говоря про управленческие нюансы, мы уже упоминали о возможной необходимости сокращения штата IT-сотрудников. Департаменту IT могут потребоваться специалисты совершенно другой квалификации: технические профессионалы с навыками менеджмента, которые будут осуществлять административно-техническое взаимодействие с аутсорсером. Такие специалисты призваны контролировать аутсорсера, правильно ставить ему задачу, проверять сроки выполнения работ. Возможно, что эти задачи лягут дополнительной нагрузкой на плечи самого IT-директора.
При грамотном выборе облачного провайдера данный тип риска снижается. Некоторые облачные провайдеры выделяют под каждый проект одного или даже двух менеджеров. В их задачи входит максимальная помощь заказчику: оперативное предоставление отчетности и любой необходимой информации обо всех этапах развития проекта.
Нюанс №4. Организационный.
Организационный риск связан с формализацией IT-процессов внутри компании и при взаимодействии с заказчиком. Договорные отношения заказчика и облачного провайдера формализуют границу ответственности между ними, в частности, подразумевают оформление заявок, связь через сервис деск, письменный контакт с руководителем проекта. Формализация процедур, которые раньше решались внутри компании без регламентов, может быть новым и непривычным процессом для IT-директора и компании заказчика.
По факту данные процедуры занимают немного времени, к ним требуется привыкнуть. Зато анализ ежемесячных отчетов о потреблении ресурсов, результатов мониторинга, отчетов об инцидентах от облачного провайдера позволяет оптимизировать IT-процессы.
Нюанс №5. Экономический.
Миграция в облако для IT-директора означает изменение системы планирования бюджета компании. Расходы на IT становятся более контролируемыми. Облачные услуги позволяют экономически обоснованно подходить к трате денег: вместо разовых дорогих закупок компания ежемесячно перечисляет определенную сумму облачному провайдеру. Во-первых, снижается риск управленческих ошибок, во-вторых, – выявляются просчеты IT-директора при первоначальном планировании.
Даже если IT-директор допустил ошибку при планировании бюджета в первый месяц, на следующий месяц ее можно исправить. Помесячная оплата позволяет перезаключить соглашение при неправильном распределении бюджета. Можно увеличить ресурсы, приобрести дополнительные лицензии, ПО или оборудование. Такая система поддержки IT-инфраструктуры по факту оказывается намного более гибкой, оперативной, надежной и выгодной для бюджета компании, нежели крупные разовые закупки.
Добавить 1 комментарий
Ч — честность. :)))
Не каждый день видишь статью явно рекламной направленности, которая вот так вот прямо с вертушки… вот это вот про мотивацию IT-директора, который прекрасно знает, что свита красит короля, и что же он захочет её сам взять и зарезать? Если только не сам честный-пречестный. :)
Мне кажется, что адресатом такой статьи должен быть не тот, кто заинтересован в распухании свиты, а тот, кто в ней НЕ заинтересован. Т.е. тот, кто выше и кому бюджет нужнее свиты. Или наоборот, тот кто ниже (не всегда по статусу, но всегда по цепочке исполнения бизнес-процессов). Т.е. те же програмизды. Мне почему-то всегда мерещится, что все програмизды мира так же искреннее и яростно ненавидят одминов, как я. Хотя я встречал немало отличных админов как рядовых, так и не очень, но в общем и целом слишком много они суммарно моей крови попили, и по прошествии лет я еще лучше вижу, что ни разу они не оказались правы в своих загонах. Т.е. вот два сегмента.
С точки зрения денег. Даже вот я, совершенно мелкая пузатая мелочь, и то наизусть знаю, чем для меня отличается капекс от опекса. Потому что если вот я вижу, что моя бизнес-идея всё же чего-то стоит и её надо масштабировать, то да, я могу вооружится мощным экселем и посчитать затраты на покупку оборудования. Но до этих пор я буду изо всех сил держаться за опекс, потому что тогда я в любой момент смогу выкинуть оказавшуюся дохлой идею в мусорку, и мои затраты на «аборт» будут стремиться к нулю. Тогда как продать оборудование я могу в самом лучшем случае за половину стоимости. Уверен, что и более большие бизнесы так или иначе что-то такое ощущают на уровне управления финансов.
P.S. Сейчас подумал, что это только на моей практике «ИТ-директора» всегда были админ-начальниками, а програмизды были к ним пристёжкой, и на самом деле всё может быть наоборот. Но я не видел. И чо такое модное слово DevOps, до сих пор не прочитал
к стыдук нерезиновому времени.