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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не обостряйте отношения без необходимости

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

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

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

Предыдущий раздел оставляет без решения открытую проблему, а именно изначальную неопределенность насчет того, какой из вариантов эффективнее другого. Возможно, сработают несколько вариантов. Несколько лет назад на одной конференции одновременно обсуждались два подхода к анализу социальных сетей. В конференц-зале № 1 проходила презентация проекта по реализации анализа социальных сетей в реляционном окружении. В конференц-зале № 2 обсуждались возможности анализа социальных сетей в нереляционном окружении. Я присутствовал во втором конференц-зале и обнаружил, что бо́льшая часть обсуждения была сосредоточена не на аналитике или ценностях, создаваемых ею, а на утверждении о том, что анализ социальных сетей не может быть выполнен в реляционном окружении. Парадоксально, но в конференц-зале № 1 в это время говорили о том, как наладить такой анализ в реляционном окружении и почему оно является единственно пригодным для этого местом.