Революция в аналитике. Как в эпоху Big Data улучшить ваш бизнес с помощью операционной аналитики - Билл Фрэнкс

Информация, поступающая от продуктов, является ценной для централизованной программы инвентаризации и генератора списка покупок. Однако в долгосрочном плане эти данные не имеют никакой ценности. Единственное, что нам нужно, – это список необходимых покупок перед посещением магазина. Нам совершенно неинтересны детали коммуникации между вещами на кухне, в результате чего был составлен список{48}. За исключением этих данных здесь не происходит ничего такого, что бы отличалось от наших повседневных дел. Разве семейные пары запоминают в мельчайших подробностях, как они составляли список покупок перед походом в магазин? Нет. Они запоминают только то, что им действительно важно, – окончательно составленный список покупок.

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

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

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

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

Определите, где потребуется аналитика

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

• Какой из компонентов окружения может справиться с обработкой?

• Какие инструменты обладают необходимой функциональностью?

• Какими навыками, имеющимися и доступными, обладает команда?

• Где в настоящее время хранятся необходимые данные?

• Существуют ли какие-либо уже известные процессы, у которых можно позаимствовать код?

• Цель заключается в поиске нового инсайта или применении уже имеющегося?

• Какие вам требуются аналитические методы?

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

Никогда не говорите, что это невозможно!

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

Если вы спросите у первоклассного программиста, использующего язык SQL, сможет ли он выполнить предложенный ему набор логических задач, в большинстве случаев он ответит: «Да». Если вы спросите у специалистов по SAS или R, смогут ли они выстроить требуемую логику, они также ответят: «Да». Если вы спросите у программистов, специализирующихся на Python или Java, смогут ли они выстроить эту логику на Hadoop, они тоже ответят: «Да». Вот что вам нужно понять: все опытные специалисты смогут реализовать требуемую вам аналитическую логику. Проблема в том, что есть более или менее эффективные способы.

Никогда не говорите специалисту, что данный аналитический процесс не может быть реализован в предпочитаемом им компоненте единого аналитического окружения при помощи предпочитаемого им набора инструментов. Заявлять сразу: «Не сможете!» – значит обострять отношения. Когда вы говорите специалисту: «Это невозможно сделать в том окружении и теми инструментами, которые вы предпочитаете», его немедленной реакцией будет: «Возможно!» И он действительно сделает все возможное, чтобы доказать вашу неправоту. Но такой подход контрпродуктивен.

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

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

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