Андрей Шолохов
Стратегия попутного ветра. Как обнаружить или создать асимметрии, способные придать бизнесу ускорение
Также были разработаны и предложены рекомендации по дополнительной продаже опций в ранее закупленные клиентом «голые» СУБД Oracle. Рекомендации совмещали планомерное исследование организационной структуры клиента с точки зрения задач, которые решают опции к СУБД Oracle.
Данное направление деятельности не принесло видимых результатов с точки зрения продаж опций по всей территории, но существенно помогло тем немногим продавцам, которые потратили время на такую проработку, увеличить свои результаты в будущем и не только по опциям.
Также был составлен список опций к СУБД Oracle, которыми продавцам Oracle Direct заниматься не стоило. Туда входили продукты, интересные очень небольшому количеству клиентов, а трудозатраты на собственно продажи были высоки.
В 2011 финансовом году продажи опций продавцами Oracle Direct ECEMEA составили приблизительно $7,2 млн. План на 2012 финансовый год установили в размере $ 11,4 млн, чтобы нагнать отставание от стратегического плана. Действительный результат на конец 2012 года составил чуть меньше $14,5 млн, что составило 127 % выполнения плана и увеличило продажи опций в Oracle Direct ECEMEA в два раза за один год, а не за три.
Простейшие рекомендации, которые предполагают приоритетную разработку сделок, способных принести результат в пять раз выше, чем обычные сделки (составленные исключительно из опций, против сделок СУБД+опции), а также активная борьба против продаж «голых» баз данных, с одной стороны, плюс наличие «черного» списка продуктов, для которых овчинка выделки не стоит, принесли очень неожиданный, но приятный результат.
Как уже было отмечено, источником несимметричности данного кейса служили правила лицензирования продуктов, а также премирования продавцов. В следующей главе мы рассмотрим теоретические аспекты составления стратегий и управления компаниями на основе асимметрий бизнес-пространства.
Глава 2. Базис сверхпроизводительности
В 1966 году вышла книга американского математика Эдварда Торпа «Обыграй дилера»[1], в которой впервые была широко представлена выигрышная стратегия игры в блэкджек. Автор не в последнюю очередь заинтересовался этой азартной игрой потому, что у нее была замечательная асимметрия: вероятность того, что игрок проиграет казино при использовании базовой стратегии, была наименьшей среди всех доступных автору азартных игр.
Более того, если добавить к базовой стратегии игры в блэкджек дополнительную информацию о том, какие карты уже вышли из игры, то игрок статистически уже может рассчитывать не на минимальный проигрыш, но на победу и деньги казино. В разных изданиях книги автор представил стратегии со счетом «пятерок», «десяток» (куда по правилам игры входят собственно «десятки» и все «картинки») или вообще всех карт.
Торп на компьютере просчитал все асимметрии блэкджека с дополнительной информацией о выходе определенных карт из колоды, а предложенная им стратегия в упрощенном изложении звучала так: если складывается невыгодная ситуация для игрока, то нужно делать минимальные ставки. Если же ситуация благоприятная, то ставка должна быть максимальной и комфортной. Сравните такую стратегию с фокусом на опции без СУБД Oracle и черным списком из прошлой главы.
Эдвард Торп не только рассчитал оптимальную стратегию игры в блэкджек, но и самостоятельно проверил ее на практике. Описание этого успешного опыта также присутствует в книге, что сделало ее не сухим набором правил игры и стратегий выигрыша, но скорее приключенческой литературой, где были взлеты и ошибки, изменения внешности и борьба с шулерством. Многие читатели «Обыграй дилера» стали успешными игроками, а казино начали менять правила игры.
Перспектива сидеть часами за столом для блэкджека, считая карты и зарабатывая сотни и тысячи долларов с риском для жизни, не была мечтой Эда Торпа. Сначала он, используя наработанную методологию с блэкджеком, «сломал» другую карточную игру – баккара. Позже совместно с Клодом Шенноном разработал первый портативный компьютер и обыграл казино в рулетку. Поиск и использование асимметрий помогли Торпу сделать успешную карьеру инвестора на фондовом рынке, находя возможности заработать больше на рынках варрантов, опционов, облигаций, привилегированных акций и других производных финансовых инструментов.
Используя естественные и искусственные, динамические и статичные асимметрии, можно «ломать» не только азартные игры или фондовые биржи, но и более традиционные производственные и сервисные рынки. Существуют несколько вариантов подобного «взлома», но один из самых удачных был представлен в 2015 году в книге Джеффри Мура Zone to Win. Русский перевод названия – «Зона победы» исключительно неточный, так как речь идет о разделении бизнеса на зоны для достижения победы. Иначе говоря, разделяй и властвуй.
Как и Эдвард Торп, который использовал понятие «базовая стратегия», Джеффри Мур описывает базовый инструмент управления компанией, названный им матрицей производительности. Автор определяет ее как организационную модель, оптимизированную под управление товарными категориями, объединенными общей системой выведения на рынки. Эту модель успешно применяют IT-компании, например, в книге представлены примеры компаний Salesforce и Microsoft, а я лично сталкивался с внедрением подобной системы в PTC.
Данную модель легче всего описать в виде таблицы, где в строках отображаются ключевые товарные категории, а в столбцах конкретные каналы сбыта, через которые весь объем произведенных продуктов поставляется на рынок (см. Таблицу 3). Чтобы матрица оказалась одновременно эффективным и результативным инструментом, автор вводит некоторые требования к таблице.
Во-первых, одна товарная категория должна приносить не менее 10 % выручки компании. Именно такие строки он называет ключевыми. Если это не так, то такая товарная категория должна быть объединена с какой-нибудь другой. Во-вторых, практика автора показывает, что количество товарных категорий и каналов продаж не должно быть менее 3 и больше 6 в большинстве случаев.
Особо стоит отметить, что развитие разных товарных категорий для компании не является сеансом одновременной игры на нескольких досках, которую с блеском продемонстрировал Остап Бендер в Васюках. Это скорее похоже на опыт лирического героя Владимира Высоцкого, когда «Мы сыграли с Талем десять партий – в преферанс, в очко и на бильярде. Таль сказал: «Такой не подведет!» Развитие каждой продуктовой категории – это отдельная (азартная) игра со своими правилами, стратегиями, ритмами, асимметриями.
Основная идея матрицы производительности как инструмента управления предприятием состоит в назначении ответственных за каждую строку и каждый столбец матрицы. Таким образом, каждая ячейка таблицы находится на пересечении ответственности двух руководителей – один отвечает за продажи, а второй – за товарную категорию. В ячейки матрицы могут помещаться разные числовые данные, например размер оборота, маржинальность бизнеса, даже количество продуктов определенной товарной категории, проданной через конкретный канал продаж.
Перекрестное управление позволяет, с одной стороны, легко масштабировать лучшие управленческие идеи, найденные в бизнес-практике одной из ячеек, на всю продуктовую категорию или на весь канал продаж, а соответственно, и на весь бизнес, а с другой стороны – такой подход, почти как двойная запись в бухгалтерском учете, позволяет гарантировать контроль, проверку корректности представления бизнеса.
Так в бизнес-кейсе, представленном в главе 1, я задействовал лучшую практику по продаже опций к СУБД Oracle, сложившуюся в Германии, и перенес ее на территорию Восточной Европы, России, Ближнего Востока и Африки. Аналогично успешный метод продажи какой-нибудь независимой от СУБД опции, например GoldenGate, где-нибудь в Польше может быть распространен на все похожие географические регионы или каналы продаж.
Одна из основных идей, для чего Мур определил матрицу производительности, заключается в «зональной атаке». В рамках такой атаки организация за короткий период времени выводит на рынок новую для себя продуктовую категорию или, другими словами, добавляет новую строку в матрицу производительности. Успех «зональной атаки», по мнению Джеффри Мура, заключается в достижении продаж нового продукта на уровне 10 % от общего оборота компании, при этом продажи старых продуктовых категорий должны также показывать умеренный рост.
Зональная атака – очень рискованное занятие, требующее много ресурсов компании, но овчинка стоит выделки. Мур предполагает, что в развитых продуктовых категориях очень сложно достичь существенного, например, двузначного или даже трехзначного роста продаж, но это можно сделать с помощью нового продукта, способного трансформировать текущую бизнес-модель компании, или вообще отрыть новый «голубой океан». Именно рост бизнеса или даже продуктовой категории очень любят инвесторы на фондовом рынке, а значит, компания и ее CEO выиграют еще и в «очковой квалификации» – капитализации компании.
Нужно отметить, что Мур рекомендует заниматься выводом исключительно одной новой продуктовой категории в один период времени, чтобы компания не оказалась в ситуации «за двумя зайцами погонишься, ни одного не поймаешь». Риск же потенциально неверного выбора можно минимизировать предварительным помещением потенциальных успешных продуктов в так называемую «инкубационную зону» компании, куда по мысли автора попадают купленные корпорацией стартапы. Данный процесс в книге проиллюстрирован примером зональной атаки компании Salesforce.
По сути, Мур пытается использовать только одну базовую несимметричность окружающего его бизнес-ландшафта – влияние ускоренного роста новой продуктовой категории на капитализацию компании, но таких несимметричностей гораздо больше. Матрица производительности и в этом случае будет очень полезным инструментом управления компанией.
Вернемся к кейсу, описанному в главе 1. Если бы мне дали в 2011 году задачу составить матрицу производительности для бизнеса продажи опций к СУБД Oracle в регионе ECEMEA, следуя буквальным рекомендациям Джеффри Мура, у меня, скорее всего, вышло бы следующее:
Практически всегда при построении матрицы производительности легче всего выбираются столбцы. В данном случае они очевидны и следуют организационной структуре. Регион ECEMEA в Oracle состоял из Восточной Европы (CE), Турции, Греции, стран бывшей Югославии (SEA), России (CIS), Ближнего Востока и Африки (MEA). В каждом регионе был свой руководитель и какое-то количество продавцов.
Строки же сформированы из групп опций, которые близки, но не идентичны их официальному определению в корпорации Oracle. В таблице 4 представлены опции для управления работой базы данных (Management Packs), опции, отвечающие за производительность приложений (Performance Options), опции безопасности (Security Options) и другие подобные группы продуктов. В регионе ECEMEA в Oracle Direct отсутствовали руководители, отвечающие за конкретные группы опций, но такие люди обязательно существовали хотя бы на уровне штаб-квартиры.
Это достаточно нейтральный вариант матрицы производительности, которая практически полностью следует рекомендациям из книги, но она имеет и свои недостатки. На практике, получая в конце отчетного периода подобную заполненную матрицу, менеджер вынужден комментировать ее примерно так: «Как мы видим, рост продаж опций производительности очень хороший, а вот опции безопасности отстают от плана, поэтому предлагаю в следующем квартале сделать маркетинговую активность, посвященную безопасности базы данных».
Нужно понимать, что уровень плана чаще всего зависит от результатов продаж предыдущего года. На практике обычно не учитывается емкость рынка, а проводить маркетинговое мероприятие, на которое позовут в первую очередь людей, контакты которых уже есть в организации и которые наверняка уже слышали про безопасность баз данных, далеко не всегда имеет практический смысл.
Таблица 4 не несет дополнительной контекстной информации о потенциальных действиях, которые можно предпринять руководству, чтобы исправить ситуацию, кроме фокуса работы на «отстающие» продуктовые категории. Также из такой матрицы непонятно, как планировать продажи на будущий период или реагировать на какие-то изменения посреди отчетного периода.
Давайте посмотрим на альтернативную матрицу производительности, составленную на основе стратегии развития бизнеса опций к СУБД Oracle, описанной в главе 1.
Столбцы в таблице 5 полностью идентичны таблице 4, но вот строки существенно различаются. Здесь мы отходим от принципа продуктовых категорий, объединенных единым подходом вывода на рынки, к принципу действий, имеющих разный индекс отдачи на вложенные усилия. В прошлой главе я показал, что в условиях отсечки по размеру сделки продажа продуктов, идентифицируемых как опции к СУБД Oracle, но в реальности не связанных с ней и продающихся независимо от нее, приносит в среднем в пять раз более высокий результат, чем опции, проданные совместно с базой данных в одной сделке.
Как раз такие сделки представлены в строке Stand-alone Options. Причем очень важно при формировании подобных матриц, чтобы тип сделки вычислялся автоматически, без субъективного мнения человека. В данном случае сделки типа Stand-alone Options можно выбирать из общего списка сделок по типу опции, например GoldenGate, и отсутствию СУБД Oracle или даже продуктов иного класса, кроме опций в сделках.
В строке No Naked Discounts представлены случаи, когда клиент через продавца запрашивает дополнительную скидку на сделку, где присутствует редакция Enterprise базы данных Oracle без опций. Правила в этом случае были изменены, и скидка предоставлялась исключительно при добавлении в сделку минимального количества опций, например, Tuning Pack и Diagnostics Pack. Сделки, где проходил такой запрос, маркировались автоматически через программу запроса дополнительных скидок.
Высокий индекс отдачи этой операции определяется очень небольшими усилиями, требуемыми продавцу на ее реализацию. Особенно успешно такое действие в первый год и на территориях, где продаются много «голых» баз данных. В нашем случае, согласно таблице 2, это Ближний Восток, Африка, Россия, Турция и юг Восточной Европы. В первый год в этой строке существенным образом увеличилась выручка именно на этих территориях, но потом продавцы начали заранее предупреждать клиентов о таких правилах, и количество запросов на дополнительные скидки на «голую» базу данных начало снижаться, поскольку стали запрашиваться дополнительные скидки сразу на сделки, где присутствовали опции. Тем не менее данное действие все равно имеет положительное влияние, так как улучшает со временем уровень отдачи в среднем в строке Other Options.
В строке Install-base Upsell представлен вариант дополнительной продажи опций на ранее проданную редакцию Enterprise базы данных. Система оформления сделок устроена таким образом, что при покупке опции в сделке, где не присутствует база данных, требуется специальным образом указать, к какой инсталляции СУБД будет привязана опция. Это также необходимо, чтобы совпадали параметры лицензирования. Именно это действие отслеживается и суммируется в данной строке.
В строке Stand-alone Options высокий индекс отдачи действия обусловлен асимметрией, связанной с правилами лицензирования и премиальной мотивацией продавцов, а в строке No Naked Discounts асимметрия происходит из минимально необходимых усилий, требуемых для реализации, то есть фактически является локальным дополнением правил лицензирования, модулирующим поведение как продавцов, так и покупателей. В случае же со строкой Install-base Upsell асимметрия вытекает из того, что механизм выполнения продавцом своих обязанностей имеет тенденцию к улучшению.
Напомню, что для осуществления дополнительной продажи опций на ранее проданную Enterprise редакцию СУБД Oracle я разработал специальную методологию DBO Discovery, которая объединяла несколько технологий продаж, включая работу с компаниями. DBO Discovery имела разветвленную организационную структуру и психологический портрет клиента, а также понимание, где, когда и как возникает необходимость в функциональности той или иной опции.
По сути дела, это фактическое обучение сотрудника, и, как показал опыт работы, продавцы, которые неоднократно применяли подобную методологию, с определенного момента становятся более эффективны в продажах вообще и технологического стека Oracle в частности, хотя на первом этапе «кривой обучения» эффективность продавца может быть на уровне продуктов из черного списка.
Строка Black List как раз и представляет собой тот самый черный список опций к СУБД Oracle, которыми продавцу Oracle Direct заниматься не стоило. Появление потенциальной сделки в этой строке должно всегда вызывать вопрос. Случалось, что продукт из черного списка уже был ранее продан, например, полевым продавцом, и речь шла о расширении использования. В таком случае требовались минимальные усилия для реализации сделки, но в большинстве случаев анализ вопроса показывал, что продавец не понимал ситуации, и в реальности клиенту требовался другой продукт или услуга.
Строка Other Options остается на все остальные случаи жизни, когда индекс отдачи при продаже продуктов средний по больнице. Эта строка может и обычно приносит существенную долю выручки и от нее ни в коем случае нельзя отказаться.
Таблицу 5 можно назвать матрицей сверхпроизводительности для продажи опций к СУБД Oracle в организации Oracle Direct c наличием отсечки сверху по размеру сделки. Откуда получается сверхпроизводительность? В обычной бизнес-ситуации руководители продаж не исследуют вопрос асимметрий бизнес-пространства и не стремятся фокусироваться на действиях с максимальным индексом отдачи. Получается, что существует некий средний индекс отдачи, размер которого мы не контролируем, а количество потенциальных действий отдела продаж всегда ограничено имеющимися ресурсами.
Допустим, средний индекс отдачи для действий продавцов равен двум (на единицу работы продавца приходится две единицы результата). Если максимальное количество активностей, которое может провести отдел продаж за отчетный период равно 25, то рассчитывать мы можем только на максимальный результат в 50 единиц.
В случае же работы по модели матрицы сверхпроизводительности максимальный результат деятельности рассчитывается иначе.
В таблице 6 представлена гипотетическая модель бизнес-пространства, в котором работает отдел продаж с максимальным количеством активностей 25 единиц в отчетный период по матрице сверхпроизводительности, представленный в таблице 5. В колонке «Индекс отдачи» записаны расчетные индексы отдачи от действий в выбранном отчетном периоде, а в колонке «Потенциал на территории за отчетный период» – максимальное количество действий по каждой категории.
На этом месте самое время вспомнить Эдварда Торпа и его выигрышную стратегию игры в блэкджек. Напомню, если ситуация с вышедшими из игры картами была благоприятна для игрока, то следовало делать максимальную ставку. Если же карты и звезды не сулили ничего хорошего, нужно было минимизировать свои риски. Мы договорились считать, что у отдела продаж есть только 25 активностей или, другими словами, ставок в отчетном периоде, поэтому я рекомендую здесь играть по аналогичному «жадному» алгоритму, как в блэкджеке.
Мы максимально выполняем действия с индексом отдачи больше среднего, минимизируем количество действий с индексом отдачи меньше единицы (черный список), а оставшееся количество активностей заполняем деятельностью с базовым индексом отдачи. Например, можем получить такой финальный результат:
5 * 3 + 7 * 4 + 2,5 * 6 + 0,5 * 1 + 2 * 11 = 15 + 28 + 15 + 0,5 + 22 = 80,5
Сравните этот результат с цифрой 50 из предыдущих расчетов, когда мы не разделяли сделки по индексу отдачи усилий продавцов, а использовали усредненный подход.
Отметим, что матрица сверхпроизводительности для полевого отдела продаж, у которого размер сделок ограничен уровнем отсечки снизу, будет выглядеть совершенно иначе, например, так:
Географическое распределение полевого отдела продаж и Oracle Direct в ECEMEA совпадает, поэтому совпадают и столбцы в таблицах 5 и 7. В обеих таблицах присутствуют строки Black List и Other Options, но наполнение продуктовыми группами и активностями в них будет разное. В черный список мы вносим те продуктовые группы или действия, индекс отдачи которых меньше либо очень близок к единице для конкретного подразделения продаж. И для Oracle Direct и для полевого подразделения это будут разные продукты. То же самое можно сказать и про группу Other Options, куда вносятся продукты, продающиеся с неким усредненным индексом отдачи, который мы не можем назвать слишком маленьким или слишком большим.
Про строку ULA или Unlimited License Agreement я уже рассказывал в главе 1. Заключить с клиентом огромную сделку, которая объединяет десятки и сотни отдельных контрактов на продукты вендора, – это серьезный вариант для формального увеличения продаж в начале десятых годов XXI века.
Как мы отметили ранее, были условно «русский» и «немецкий» методы заключения ULA в части опций. Прилагательные «русский» и «немецкий» даны здесь исключительно из кейса, описанного в главе 1. Все офисы Oracle на практике использовали либо тот, либо другой подход к включению опций к СУБД Oracle в контракты ULA. Российский офис стремился внести в ULA весь прайс-лист, включая саму СУБД Oracle, опции к ней, Fusion Middleware и даже иногда некоторые приложения. Получая всю сумму контракта, Oracle перераспределял ее по продуктовым группам на основании внутренних правил. При «русском» пути в ячейки строки ULA нужно вносить именно эти перераспределенные в категорию опций суммы. При «немецком» подходе, когда в ULA опции намеренно не включаются, в эту строку нужно вносить сумму сделок по допродажам опций к ранее заключенным ULA, размер которых больше уровня отсечки.
Real Application Clusters (RAC) – это опция, с помощью которой можно создавать кластерную архитектуру базы данных. Используя такую архитектуру, можно, например, организовать беспрерывную работу базы данных в случае незапланированной остановки работы одного из серверов (логического узла кластера). Допустим, у нас есть кластер из четырех узлов, и на одном из них происходит ошибка. СУБД Oracle с помощью опции RAC автоматически распределит нагрузку на три работоспособных узла. При этом пользователь заметит лишь некоторую задержку для операций, проводившихся на поломавшемся сервере. Что даже приятнее, можно динамически подключать и отключать логические узлы кластера. Например, во время новогодних праздников, когда нагрузка на телефонную сеть очень большая, телеком-компании могут таким образом увеличивать мощность систем.
Несимметричность, связанная с опцией Real Application Clusters, опять основана на правилах лицензирования Oracle. Так, если пользователь использует кластер из четырех логических узлов, то ему нужно заплатить четырежды стоимость самой базы данных, четырежды – стоимость опции RAC, которая сама по себе тоже не слишком дешевая, и также четырежды – стоимость любых других опций, используемых на данном кластере. Это очень эффективный мультипликатор размера сделки, а также способ полевому продавцу достигнуть плана продаж, затратив меньшее количество усилий. В строку Real Application Clusters таким образом я бы заносил стоимость самого RAC, а также всех опций, которые идут с кластеризацией в одной системе.
Обратим внимание, что матрица производительности в таблице 4, а также матрицы сверхпроизводительности в таблицах 5 и 7 представляют данные по одному и тому же множеству объектов: закрытым или потенциальным сделкам по опциям к СУБД Oracle размером больше и меньше уровня отсечки на территории ECEMEA за некий отчетный период. Таким образом, для любого набора сделок из нашего множества можно сделать отчет в форме таблиц 4, 5 или 7. Причем в каком бы формате мы ни хранили данные по нашему множеству, сами таблицы всегда будут показывать одни и те же данные.
Интересно отметить, что матрица производительности в таблице 4 одинаково хорошо (или плохо) подходит как для полевого отдела продаж, так и для Oracle Direct. Возможно, она не содержит дополнительного контекста, который помогает руководству предпринимать более эффективные действия, но она все же дает некий релевантный набор информации для обоих подразделений, работающих со сделками ниже и выше уровня отсечки, так как форма таблицы 4 вообще не учитывает асимметрию отсечки.
Таблицы 5 и 7 очень эффективны, но окажутся практически бесполезными, если Oracle Direct попытается пользоваться формой таблицы 7, а полевой отдел продаж по какой-то причине начнет пользоваться формой таблицы 5. В таком случае эти таблицы можно назвать матрицами пониженной производительности.
На этом этапе или чуть раньше читатели с математическим образованием должны вспомнить про понятие базиса. Если заглянуть в определение, то можно увидеть нечто такое: базис – упорядоченный (конечный или бесконечный) набор векторов в векторном пространстве, такой, что любой вектор этого пространства может быть единственным образом представлен в виде линейной комбинации векторов из этого набора.