Три года назад я внимательно изучал продукты компаний, предлагающих услуги бизнес-аналитики на платформе SaaS. Мне очень нравилось то, что я видел в демонстрациях: красивые графики и таблицы, настраиваемые сводные отчеты и средства анализа данных создавали впечатление, что все это работает легко и просто. Но потом я начал рассматривать вопрос более тщательно. И оказалось, что все эти примочки очень полезны для продвинутых аналитиков, но в основном бесполезны для обычных пользователей. Заказчики же не хотят становиться аналитиками; им нужно, чтобы софт сам выполнял аналитическую работу за них.

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

Оказалось, что такое несовпадение существует не только применительно к инструментам бизнес-аналитики, но и к любому ПО, которое обрабатывает какие-либо данные. Возьмем в качестве примера Sales Cloud разработки Salesforce. Программа собирает и обрабатывает огромные массивы данных, но очень слабо их анализирует и предлагает мало выводов. Разве не было бы лучше, если бы клиенты могли просто получать от Salesforce емейл в том случае, если программа обнаружила какие-то интересные тенденции?

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

Мы прогнозируем невыполнение вашего квартального плана продаж.
Ваш план составляет 2,5 миллиона долларов; исходя из имеющихся у нас данных, ожидается его недовыполнение на 400 тысяч.
Прогноз основывается на недостаточном количестве Потенциальных Заказов в системе, с учетом вашего прошлого коэффициента конверсии Потенциальных Заказов в Фактические Продажи (55%). Общая сумма потенциальных продаж на текущий квартал составляет 3,8 миллиона.
Основные проблемы возникли в западном регионе. Более конкретно, планы не выполняются менеджерами Петром XX и Татьяной XX. Для получения более подробной информации нажмите здесь. (Тут заказчик уже сможет перейти к вашему приложению с его графиками и запросами, чтобы углубиться в изучение проблемы.)

Кому-то такое может показаться научной фантастикой, но на самом деле сделать что-то подобное не так уж и сложно. Сами того не замечая, мы постоянно сталкиваемся с “умным” софтом. Amazon автоматически рекомендует продукты, которые могут нам подойти. Nest сам оптимизирует работу термостатов в доме. VideoIQ даже может распознать, когда кто-то готовится совершить преступление. Главное свойство всех этих продуктов – они предугадывают желания своих пользователей, и выполняют их автоматически.

Как вам подтвердят все разработчики ПО, как правило, чем легче работать с программой конечному пользователю, тем больше усилий вложено в нее разработчиком. Так что же нужно для создания “умного” аналитического софта, который может автоматически предоставить пользователям готовую к применению информацию?

1. Начните с понимания предметной области

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

Поставщики систем для бизнес-аналитики (BI) это уже поняли, и создали ряд cпециализирвоанных отраслевых приложений, которые надстраиваются на их платформы. Некоторые из них очень неплохие. Но тем не менее, они все равно еще не дотягивают до ожиданий заказчиков.

2. Определите важные моменты

Основную часть времени человеку не нужно смотреть на данные, пока все идет как надо. Это одна из проблем со сводными отчетами: когда постоянно к ним обращаешься, а ничего особенного не происходит, то вскоре перестаешь в них заглядывать вовсе. Заказчикам нужно получать уведомления в том случае, если происходит что-то необычное или возникает проблема.

Инструменты бизнес-аналитики обычно имеют функции уведомления. Но те, которые я видел, слишком простые; кроме того, они требуют от пользователя самостоятельной установки правил того, что считать “отклонением от нормы”. Опять же, такой софт нельзя назвать “умным”: он требует, чтобы пользователь выполнял аналитическую часть работы сам, вместо того, чтобы делать это за него.

Ниже привожу некоторые соображения в части обнаружения необычных событий, требующих внимания человека:

Определите нормальный диапазон значений

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

Рассматривайте бюджеты и прогнозы

Часто для данных в системе имеется бюджет или прогноз, заданный пользователем, которые можно использовать для определения “нормального” или “ожидаемого” поведения данных. Если же их фактическое поведение отличается, генерируйте предупреждение.

Пользуйтесь пониманием того, как используются информация, для выявления аномалий

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

Регулярно шлите обновления, даже когда ничего не происходит

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

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

3. Установите первопричину

Если ваш софт может предупредить вас о предстоящем невыполнении плана, это конечно уже полезно. Но сразу же возникает вопрос: а почему план не выполняется?

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

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

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

Если же более подробно рассматривать возникшую проблему в продажах, необходимо взглянуть на следующие элементы:

Понимание иерархии позволяет “умному” аналитическому софту самостоятельно углубляться в данные, выполняя работу клиента вместо него.

4. Консультируйтесь с профильным экспертом

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

Если вы говорите с вице-президентом по продажам, он, вероятно, захочет получать информацию следующего рода:

•  Выполнится ли мой квартальный план продаж?
  – А также он расскажет вам, каким образом он сам диагностировал бы наличие проблем, рассматривая отдельные сегменты данных, как я попытался показать выше.

• Ведется ли работа таким образом, чтобы план на следующий квартал также был выполнен?
  – Нужно смотреть на обсуждаемые и заключаемые договора в воронке продаж.

• Кто из моих менеджеров по продажам не справляется?
  – Какая именно часть процесса продаж вызывает у них затруднения – например, демонстрации клиентам? (Руководитель может принять корректирующие меры – например, провести дополнительное обучение.)
  – Кто из менеджеров лучше всего владеет соответствующей техникой продаж (проведение демонстраций)? Можно поручить им обучение тех менеджеров, у которых есть проблемы с конверсией демонстраций в реальные заказы.

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

5. Можно ли также рекомендовать корректирующие меры?

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

Заключение

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

Автор – David Skok.