Как избежать ошибок при внедрении Больших Данных и облачных вычислений

21.04.2015 | 22:16 Аналитика

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

Исследование McKinsey показало, что в среднем, 45% крупных ИТ-проектов выходят за рамки бюджета, 7% нарушают сроки, обеспечивая при этом на 56% меньше выгоды, чем ожидалось. Еще 17% пошли так плохо, что само существование компании оказалось под угрозой. Большие ERP-проекты служат примерами для современных проблемных ИТ-проектов, с количеством неудач, по крайней мере, на уровне 25%.

Если вы думаете, что это плохие показатели, у облаков и проектов больших данных они еще хуже. Отчет CapGemini показал, что только 13% проектов Больших Данных достигли полномасштабного производства. Только 27% опрошенных назвали инициативы Больших Данных «успешными», и только 8% описали их как «очень успешные».

Аналитик Gartner Том Биттман, опросивший 140 клиентов Gartner, сообщил в своем блоге, что только 5% проектов облачного развертывания прошли без сучка и задоринки. Остальные 95% имели одну из шести различных проблем.

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

«Все начинается с хорошего бизнес-кейса», говорит Биттман. «Можете ли вы определить сервисы, которые выиграют? Вот где наиболее часто ошибаются. Во-вторых, частное облако больше касается людей и процессов, чем технологии. Слишком часто организации говорят: «Я хочу частное облако, что нужно купить? Аппаратная часть наиболее легкая. Самая трудная часть — изменение технологического процесса и людей. Так что, в первую очередь, стоит сосредоточиться на этом. Нужно сделать эти две вещи и правильно сфокусироваться на них, что решит большинство проблем.

Гордон Хафф, вице-президент облачных стратегии в Red Hat, соглашается. «Я наблюдал много неудачных проектов Больших Данных, не имеющих четкой цели и четкого пути к этой цели», говорит он.

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

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

Первый шаг в Больших Данных или облачном проекте должен заключаться в вопросе: «А нужно ли нам это?» Может быть несколько причин, почему компаниям это не нужно: не достаточно данных для работы системы Больших Данных, использование старых систем, таких как ERP, которые не вписываются в облако, правила, которые требуют локального хранения данных в компании и т.д.

«Пользователи, собирающиеся использовать облако, потому что это следующая большая вещь, не имеют бизнес-кейса. Они не спрашивают: “где нужно увеличить скорость еще больше, чем сделала виртуализация, какие полезные нагрузки я не использую?» — говорит Биттман.

Другие проблемы

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

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

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

«Клиент может иметь 50 экземпляров данных о клиентах по всему миру в различных форматах для различных приложений. Иногда, когда вы сначала решаете эту проблему, это делает общение более значимым и привлекательным для клиентов», говорит Хантер.

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

«Технологии в Больших Данных очень отличаются от большинства платформ данных, с которыми большинство людей привыкли работать», говорит Янив Мор, генеральный директор и соучредитель Xplenty, занимающейся развертыванием Больших Данных в качестве SaaS решений для компаний.
«SQL не касается больших данных, но многие имеют навыки работы с SQL. Кроме того, они очень сильно зависят от технологий с открытым исходным кодом, что совершенно новое для парней, работающих с технологиями Microsoft. Так что вам придется нанять новых людей, которые стоят дорого и их трудно найти, или вам нужно будет обучать своих сотрудников», добавляет Мор.

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

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

Кроме того, фирмы не меняют своих процессов и операционной модели при переходе в облака, что подтверждает вышеуказанную проблему. От 80 до 90% того, что развернуто в Amazon Web Services, не является новым контентом, говорит Биттман. Они горизонтально масштабируют нагрузки, что недальновидно.

«Средний цикл жизни локальных виртуальных машин на предприятии — несколько лет. Во времена физических приложений он был около десяти лет. Виртуальные машины на Amazon имеют жизненный цикл несколько дней или недель», говорит он. Проблема в том, что многие фирмы включают VM на AWS и забывают их выключить, когда работа окончена. Вы платите за простой. Он считает, что где-то от 30% до 50% расходов на публичные облачные сервисы за использование VM являются бесполезными, потому что клиенты забывают выключить виртуальные машины, когда они закончили работу и не используют их.

Что делать

Так что же делают компании, чтобы уменьшить потенциал неудачного внедрения? Есть ряд шагов, которые нужно предпринять, и они не будут стоить дорого, если вообще будут что-то стоить.

«Спросите — нуждаетесь ли вы в проекте Больших Данных в первую очередь», говорит Мор. «С Большими Данными так много шумихи, что люди не понимают, что они могут получить от проекта Больших Данных сегодня, поэтому они не знают, как определить показатели успешного внедрения. Они не знают, что хотят получить».

Следующий шаг состоит в выборе лидера, который может создавать и управлять видением проекта, говорит Хантер. «Это видение более важно, чем руководство. Если есть видение, которое четко сформулировано, почему мы хотим использовать Большие Данные и как мы будем двигаться вперед, как они будут проникать в компанию и приниматься, проект будет более успешным», сказал он.

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

«Развертывание в облаке должно быть сосредоточено на новых облачных нативных нагрузках, при этом сохраняя связь с существующими классическими ИТ-услугами, рабочими процессами, хранилищами данных и предоставляя унифицированное управление. Однако они не должны стараться быть всем для всех приложений», говорит Хафф.

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

Кроме того, начинайте с малого. Не пытайтесь решить все ваши проблемы с данными, когда начинаете проект Больших Данных. «Просто выберите бизнес-кейс, ограничьтесь несколькими источниками данных. Определите, что именно вы хотите получить от этого проекта. Вам нужно начать с малого, потому что, когда вы думаете о Больших Данных, вы не должны сразу пытаться решить все ваши проблемы с данными в организации», добавляет Мор.