Зачем обращаться к аутсорсерам?
По прогнозам SAP, более 75% расходов на ИТ к 2016 году будет связано с облачными сервисами. Соответственно вырастет рынок ИТ-аутсорсинга. Почему вообще компании обращаются к ИТ-аутсорсерам?
Во-первых, для успешного внедрения облачного решения необходимы подробный анализ текущего ИТ-ландшафта и выбор наиболее подходящего комплекса продуктов и работ для решения задачи конкретной компании. Для качественного выполнения этой части проекта оптимально использовать внешний консалтинг в области ИТ-услуг.
Во-вторых, это может быть недостаток собственной экспертизы в сфере внедрения облачных решений, особенно в случае если ИТ не основной вид деятельности заказчика. Даже в ИТ-компаниях, у операторов, провайдеров ИТ-услуг, не всегда достаточно внутренней экспертизы по тем или иным вопросам внедрения новых систем.
Третья причина
— отсутствие нужных кадров для обеспечения внедрения. Необходимо либо отвлекать имеющиеся силы от основных задач, либо увеличивать штат на этот период. В такой ситуации проще обратиться к сторонним специалистам. К тому же так гораздо проще разбить работу на несколько этапов, посмотреть на предложенное решение в работе, а потом его полностью интегрировать. Кроме того, негативно может сказаться и отсутствие «взгляда со стороны». При наличии уже сложившихся организационной структуры, ИТ-инфраструктуры, процессов эксплуатации очень сложно поменять систему изнутри. Сотрудники часто подвержены стереотипу «работает – не трогай» или не заинтересованы в использовании новых для себя инструментов, что влечет за собой трудности в процессе перехода на новые решения. Внутренним ИТ-специалистам часто психологически тяжело расставаться с устоявшимися правилами использования ИТ-инфраструктуры. Для роста обновленной экспертизы внутри компании очень важно наличие квалифицированных специалистов аутсорсера, имеющих возможность выполнять роль помощников и наставников при внедрении.
Три облачные модели
Аналитики iKS-Consulting подсчитали, что объем российского облачного рынка за 2014 год вырос на 35%. Заинтересованность заказчиков во внедрении облачных решений только растет – не в последнюю очередь из-за возросшей необходимости обеспечения экономии и большей гибкости инфраструктуры, отвечающей сегодняшним жестким экономическим условиям. Облачное решение часто подразумевает тот или иной вид трансформации CAPEX в OPEX. Примером может быть стремление уменьшить закупки нового оборудования и увеличить степень утилизации инфраструктуры за счет операционных преобразований. Другой пример – централизация программного обеспечения в виде SaaS или VDI (Virtual Desktop Infrastructure) для сокращения лицензионного обременения и расходов на клиентское оборудование.
Но как же правильно выбрать облачное решение для бизнеса? Чтобы получить ответ на этот вопрос, необходимо определить потребителей и владельцев облачных сервисов, потребности и существующие процессы в ИТ-инфраструктуре, распределить ответственность между подразделениями или пользователями. Насколько компания готова взять на себя задачи эксплуатации, и какую часть ответственности можно передать стороннему поставщику облачных услуг, если это приемлемо.
Существует три модели облачных сервисов: SaaS (Software as a Service), PaaS (Platform as a Service) и IaaS (Infrastructure as a Service). В классической модели SaaS на стороне потребителя минимум ответственности, работу по этой модели можно сравнить с использованием электронной почты – необходимо только запомнить пароль от своего аккаунта, остальное сделает за вас облако. В модели PaaS пользователь может уже самостоятельно настроить приложение и его окружение. Поставщик облачных услуг по данной схеме предоставляет потребителю облачный «полуфабрикат» для создания конечных сервисов. Здесь на стороне клиента больше ответственности за то, как правильно использовать структурные строительные блоки. И самая низкоуровневая модель облачных услуг — IaaS. В ее рамках пользователю предоставляется только инфраструктура — вычислительные мощности, сетевая инфраструктура. На стороне потребителя полная ответственность за весь «стэк» программного обеспечения сервисов и настройку инфраструктуры (операционные системы, взаимодействие между серверами).
В зависимости от наиболее удобных сочетаний этих моделей для обеспечения нужд компании выбирается то или иное облачное решение или целый комплекс продуктов, планируются шаги по интеграции.
Практические шаги при внедрении облаков
Что представляет собой процесс развертывания облака? Первый шаг при интеграции облачной платформы – формирование задачи. Для заказчика очень важно определить, какого результата он хочет достичь с помощью облачной инфраструктуры. Проблема выбора встает при этом очень остро – на первый взгляд, рынок заполнен качественными промышленными решениями, а о простоте и скорости внедрения любой вендор рассказывает очень убедительно. Но за красивыми презентациями и быстрыми «пилотами» часто теряется история длительного и сложного внедрения – очень важно не упускать это из виду и заранее планировать этапы внедрения. На этой стадии без привлечения профессионалов сложно заранее увидеть трудности — большинства из них можно избежать, воспользовавшись консалтингом или опытом интегратора.
Следующий шаг — это уже сама интеграция и развертывание облачного решения. Рассмотрим два сценария развития действия. Первый — мы остановились на решении какого-то вендора. Он сначала делает пилотный запуск решения (уже начинают работу машины, сервисы). На данном этапе мы можем столкнуться со следующими проблемами: как интегрировать это решение с уже существующей системой? как научить сотрудников им пользоваться? И тут вендор или предоставляет дополнительные услуги для кастомизации решения, или предлагает премиум-поддержку. Второй вариант развития событий — обратиться к облачному провайдеру или интегратору, которые специализируются на предоставлении комплексных услуг. Заказчик заранее будет знать, сколько стоит каждая услуга, каждый внедряемый компонент, что и с чем можно интегрировать, какие решения и у каких вендоров выбрать.
Третий шаг — эксплуатация. Здесь заказчик для себя решает, обслуживать ли данную инфраструктуру своими силами, или использовать аутсорсинг. В случае если внедрение производил аутсорсер, на этом этапе он может научить персонал заказчика, как работать с данной кастомизированной системой. Стоит отметить, что у вендора не настолько персонализированный подход.
Риски и ошибки
Безусловно, удобнее и выгоднее отдать процесс построения облачной инфраструктуры внешним экспертам, но при этом могут возникнуть некоторые трудности. Начнем, на мой взгляд, с самого серьезного риска: в результате плохой интеграции может получиться некий «Франкенштейн». Система настолько кастомизируется, что после внедрения разобраться с ней сможет только тот аутсорсер, который разрабатывал данное решение. Выходит, что интегратор становится вендором, создателем того решения, которое получил заказчик. В данном случае клиент рискует стать зависимым от своего интегратора. Если решение было разработано интегратором, то такие системы становится сложно и дорого эксплуатировать, сменить экспертизу будет проблематично. Но если решение внедрял вендор, то на рынке можно найти хороших специалистов, которые смогут разобраться с обслуживанием такой системы. Конечно, это наихудший вариант развития, так как в хорошем случае такое персонализированное решение сыграет на руку и вы получите эксклюзивный продукт, который поможет сократить расходы и увеличить продажи.
В проектах по аутсорсингу при неудачной интеграции решения, безусловно, можно винить в первую очередь ИТ-аутсорсера. Но и ИТ-директора часто совершают ошибки при построении облачных инфраструктур. На мой взгляд, самая частая ошибка CIO — плохая подготовка к внедрению решения. Облачная платформа — это очень широкое понятие, а ИТ-директора не всегда четко представляют необходимый результат. Если не разобраться в компонентах решения, в том, как оно должно работать на бизнес компании, результат может быть непредсказуемым. Без четкого понимания, какие функции должна выполнять облачная инфраструктура и какими свойствами обладать, можно получить абстрактную платформу.
Залог успеха
Как же подготовиться к внедрению облака аутсорсером? Я советую иметь выделенного на проект хорошего технического специалиста — архитектора, который будет сопровождать процесс интеграции облачной инфраструктуры и контролировать качество внедряемых решений. Для крупных проектов такую роль должен играть архитектурный комитет. И второй совет: при составлении требований к технологическому решению необходимо сформулировать задачу, которую должно решать облако, в меньшей степени обращая внимание на технические нюансы. Очень часто ИТ-директора концентрируются на технических нюансах, на требованиях к облачной платформе. Да, это, безусловно, хорошо, если вендор или интегратор будет иметь такую информацию. Но важнее, на мой взгляд, определиться, что решение должно делать в системе бизнеса — облачное решение должно или продавать свои сервисы, или обеспечивать скорость развертывания виртуальных серверов в вашей инфраструктуре, или экономить ваши затраты. Результатом работы по такому техническому заданию будет именно решение бизнес-задач компании, а не просто внедренное решение.
После того как облачное решение внедрено в компании аутсорсером, встает логичный вопрос, как же настроить поддержку облачной инфраструктуры. Если брать какое-то программное решение, например систему CRM, то после его интеграции будет осуществляться поддержка в ее классическом понимании — помощь в исправлении ошибок системы, запуск того, что работало и в какой-то момент сломалось. Но в проектах облачной инфраструктуры поддержка представляет собой чуть более медленное ее развитие, чем на этапе внедрения. Облачная инфраструктура — это очень сложная среда, и если ее запуск прошел успешно, то в дальнейшем заказчик совершенствует и дорабатывает облачную платформу, добавляет в нее новые сервисы. В данном случае аутсорсинг поддержки облачной инфраструктуры может быть наиболее выгодным решением по использованию экспертизы, приобретаемой аутсорсером на многих проектах.
Опубликовано 24.12.2015
