Несколько лет назад моя команда разрабатывала модели прогнозирования продаж на уровне отдельных магазинов для крупного ретейлера. Анализ должен был охватывать сотни миллионов комбинаций магазин/товар. Многие виды товаров продавались часто и стабильно, что соответствовало предположениям, на которые опираются широко используемые алгоритмы для такого типа прогнозов. Однако также было много товаров, что не вписывались в стандартные шаблоны продаж. Клиент нанял мою команду, чтобы разработать индивидуальные решения, применимые к таким исключениям. Однако, с учетом масштабов организации, исключения все равно составляли миллионы комбинаций магазин/товар.

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

Когда проект только начался, я предположил, что другая команда превзойдет нас в абсолютной прогностической точности, однако для масштабирования разработанного ею решения потребуются настолько значительные усилия, что это будет признано нецелесообразным. В то же время наши пусть и менее точные модели должны были лучше работать на практике. Я был приятно удивлен, когда оказалось, что наши модели оказались и более точными. Учитывая неполную и разреженную природу данных, изощренные многоступенчатые алгоритмы усиливали помехи, вместо того чтобы их контролировать. Моя команда думала, что мы отказываемся частично от аналитической мощности ради операционной масштабируемости (об этой концепции уже несколько раз говорилось в книге). Однако в итоге вышло так, что в данном случае простой подход сработал лучше и нам не пришлось ничем жертвовать. Вот почему не следует думать, что всегда лучше делать выбор в пользу изощренности. Пробуйте и простые варианты.

В свете нашего разговора об аналитике легко впасть в заблуждение и решить, что сотрудников среднего звена в организациях интересует аналитика. Она их не интересует! Большинство сотрудников интересует возможность решения тех проблем, которые у них есть. Если аналитика может предложить такое решение, они ее принимают, но сама по себе она им неинтересна. Запомните: их интересует не аналитика, а решение проблемы!

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

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

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

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

Наиболее важные положения этой главы:

• Операционная аналитика должна опираться на прочный фундамент пакетной аналитики. По-прежнему применим и традиционный аналитический процесс.

• Организация должна иметь возможность применять и сочетать различные аналитические дисциплины, чтобы, помогая друг другу, они позволяли улучшать результаты.

• Платформа для обнаружения данных – лучшее место для применения к проблеме мультидисциплинарного подхода.