Войти в систему
Войти с помощью соц. сетей:
2013 финансовый год в Oracle для меня начался с очередного большого карьерного изменения: после того как в 2012 году я увеличил продажи опций к СУБД Oracle департаментом Oracle Direct ECEMEA в два раза, я стал старшим директором по стратегическим инициативам Oracle Direct ECEMEA.
Инициатив оказалось много: я плотно занялся Enablement организации. Enablement в данном случае — это непереводимая игра одного слова, означающего обеспечение продавцов необходимыми инструментами для достижения целей организации, так, я сумел восстановить программу постоянной подготовки сотрудников с получением степени бакалавра Дублинского технологического института. Я написал и внедрил рекомендации по ведению новой CRM, делая их понятными для продавцов Oracle и удобными для администрирования; я руководил проектами, которые спускались на нас из европейской штаб-квартиры, временно замещал вакантные позиции руководителей продаж на разных территориях присутствия Oracle Direct и т.д.
При этом никто с меня не снимал обязанностей по стратегии развития продаж опций к СУБД Oracle, а еще в мое подчинение перевели менее удачливого коллегу, который занимал похожую на мою позицию в 2012 году, но по другой технологической группе — Fusion Middleware. И хотя теперь моя комиссия не зависела напрямую от продаж конкретного вида продуктов, я попытался с Fusion Middleware повторить тот же фокус, который так лихо сработал с опциями в прошлом году. И не смог.
Никаких особенных асимметрий, связанных с регулированием, механизмом или клиентами, с помощью которых можно было бы быстро достичь сверхрезультата в пространстве продаж Fusion Middleware, просто не просматривалось. Стандартный же подход с проведением тренингов по товарной категории, отслеживанию сделок и т.д. давал слабые результаты, в том числе потому что продавать саму систему управления базами данных Oracle и опции к ней было быстрее и легче, чем продавать Fusion Middleware.
И, к сожалению, такие ситуации не так уж редки. Конечно, многие не замечают интересных асимметрий, буквально лежащих под ногами, но бывает и по-другому, когда компании уже максимально используют все известные им факторы, а показывать рост необходимо.
Я родился буквально в десяти километрах от того места, где исторический барон Мюнхгаузен участвовал в штурме крепости. Моя рекомендация опирается на легендарный опыт Карла Фридриха Иеронима, сумевшего вытащить себя за волосы из болота. Когда никаких интересных асимметрий делового пространства не просматривается, компании сами могут создавать асимметрии, которыми потом воспользуются.
Процесс вытягивания компанией самой себя из состояния, когда расти сложно, в состояние быстрого роста я называю инициативой. Это совершенно не похоже на стратегические инициативы Oracle Direct, пожалуй, здесь самыми близкими понятиями является инициатива в шахматах или инициатива (тактическая или стратегическая) в военном деле.
Итак, назовем бизнес-инициативой процесс, состоящий из трех шагов.
Когда человек впервые сталкивается с таким определением инициативы, ему наверняка мало что будет понятно. Например, сравните с определением инициативы в шахматах, как проявления активности с целью придать действиям своих фигур атакующий характер и дезорганизовать игру соперника.
Все слова вроде бы верные, но совершенно непонятно, как это сделать на практике, если не переходить к методам Остапа Бендера. Лучшее понимание инициативы в шахматах (особенно если не обучался игре на профессиональном уровне) можно получить, просмотрев некоторые партии с комментариями профи на общедоступных видеохостингах. Так и я постараюсь представить до конца этой книги несколько примеров разнообразных бизнес-ситуаций, чтобы дать почувствовать инициативу в деловых пространствах.
Но прежде чем мы перейдем к примерам, следует указать, что аналогия инициативы в бизнесе и инициативы в шахматах очень глубока. Так, в шахматах для овладения инициативой часто необходимо пойти на временные позиционные уступки или пожертвовать фигуру.
Хотя бизнес далеко не всегда можно описать как конкуренцию двух игроков, но и бизнес-инициативы требуют от компаний определенных жертв, выделения ресурсов на достижение или поддержание асимметрии, делая компанию неспособной активно вести какие-либо другие действия и минимизируя инвестиции в обычный бизнес. Кроме того, всегда есть риск, что первопроходец не сможет воспользоваться своей идеальной инициативой и все результаты трудов достанутся конкурентам.
Я немного слукавил, когда говорил, что не смог найти значимых асимметрий для товарной категории Fusion Middleware. Объективно в данной разношерстной группе продуктов всегда можно было выделить черный список — набор продуктов, продавать которые силами Oracle Direct не имело смысла: много времени и усилий при мизерном результате. Даже если позитивные асимметрии не просматриваются, удаление негативных факторов все равно улучшает ситуацию.
Была и позитивная инициатива, связанная с механизмом продаж, которая могла бы серьезно повысить выручку Oracle от группы продуктов Fusion Middleware (иногда называемых продуктами срединного слоя). Но в связи с политической сложностью я так и не взялся за ее реализацию. Руководство Oracle довольно быстро осознало, что здесь потребовались бы отдельные группы продавцов, не занимающиеся одновременно продажей базы данных и опций к ней, но так как формально Fusion Middleware была частью технологического стека, то территории продаж СУБД Oracle и продуктов срединного слоя оставались идентичными, что во многом и тормозило развитие категории.
Тут надо пояснить, что такое территория продаж. Когда я начинал свой первый бизнес, связанный с продажами промышленного оборудования и реализаций инжиниринговых проектов, то о территориях продаж я ничего не знал. Начинали мы буквально с нуля, поэтому систему премирования продавцов за результат выбрали следующую: постоянная заработная плата была небольшая, а бонус формировался как доля из прибыли по закрытым продавцом сделкам. Входящий поток запросов формировался из обращений посетителей сайта и повторных обращений из клиентской базы.
На первых порах такой подход принес первоначальный рост бизнеса, но потом он уперся в потолок, когда заработок продавца уже достаточно высок, чтобы удовлетворять потребности, а делать сверхусилия для заработка дополнительных денег уже не хочется.
Люди с опытом работы в крупных или международных компаниях сталкиваются обычно с другим механизмом премирования продавцов, для каждого из которых формируется территория продаж. Обычно это список из одной-двух компаний для продавца, работающего с крупнейшим или глобальным бизнесом, 20–30 компаний для крупного бизнеса и иногда сотни для среднего и мелкого. Продавцу каждый год назначается план продаж с его территории, и за его выполнение он получает оговоренный бонус — существенно увеличенный при большом перевыполнении и иногда отсутствие бонуса, когда план выполнен, для примера, менее чем на 60%.
Так как план продаж с территории растет ежегодно, то продавец должен, как Красная Королева у Льюиса Кэрролла, бежать все быстрее, чтобы оставаться на месте, то есть получать свой стандартный бонус. Заработная плата в международных корпорациях обычно большая, но получив однажды и большой бонус, люди, как правило, стремятся повторить и превзойти свой уровень дохода.
Существует несколько подходов к формированию территорий продаж, но так или иначе и при составлении самой территории, и при планировании деятельности продавцов требуется точно определять самых потенциально перспективных клиентов для продукта. И для разных продуктов один и тот же список заказчиков будет отсортирован по потенциалу продаж неодинаково.
Для наглядности разберем, как еще в начале 2010-х годов Microsoft и Oracle оценивали потенциал продаж своих продуктов. Основным хлебом с маслом для Microsoft было два продукта — Windows и Office, поэтому потенциал продаж для клиента оценивался очень просто: по количеству рабочих мест или персональных компьютеров. Чем больше людей работало в компании-клиенте, тем интереснее она была для Microsoft, а определение территории продаж никогда не составляло большого труда.
Основным продуктом Oracle всегда была одноименная система управления базами данных, которая, если отбросить детали, оплачивалась по количеству пользователей, обращавшихся к ней. Весь фокус состоит в том, что пользователи могут быть как внутренними (работниками компании-клиента), так и внешними — клиентами и партнерами заказчика Oracle.
Именно поэтому банковский и телекоммуникационный сектор, ритейл, органы государственного управления, транспортные пассажирские компании всегда были сладкими клиентами для Oracle, так как предоставляли уже своим клиентам доступ к своим базам данных, даже если просто выписывали счета за услуги и предоставляли «личный кабинет». С них Oracle собирала на порядок больше денег, чем Microsoft. Бывали случаи, особенно в интернет-ритейле финансовыми инструментами, когда малюсенький по меркам Microsoft клиент был гигантом по меркам Oracle. В промышленном же секторе потенциал для обеих компаний был примерно равен.
Так вот, критерий потенциальной значимости для Fusion Middleware совершенно не совпадал с критерием для СУБД Oracle: здесь главную роль играло не количество пользователей базы данных, а активная деятельность компании-клиента в плане разработки своих собственных приложений, интернет-порталов, отчетных форм, интеграции приложений и данных, использование различных средств идентификации пользователей.
Oracle получал меньше выручки от продажи Fusion Middleware, чем потенциально мог рассчитывать, потому что для продажи этой продуктовой категории использовал территории продаж, которые логически были оптимизированы под продукт с другими асимметриями бизнес-модели.
Инициатива в данном случае даже не стартовала, так как представляла бы собой лишь борьбу Дон Кихота с ветряными мельницами. Уровень принятия решения находился очень далеко и высоко от меня. Тем более всегда был риск, что первые территории, составленные по новому принципу, тоже были бы неудачны, в первую очередь, из-за отсутствия опыта. Тем не менее правильно составленные территории продаж — ключевой фактор для обеспечения прогнозируемости и роста бизнеса, особенно при покупке новых компаний и их интеграции с текущим продуктовым портфолио.
В 2010 году, будучи руководителем Oracle Direct в Москве, я получил указание прибыть в Прагу, поселиться в отеле Radisson и пройти корпоративный тренинг по коучингу. Тут надо отметить, что в корпорации Oracle были очень большие возможности для обучения менеджеров. Так как к этому моменту у моей команды пошли серьезные результаты, то я договорился с шефом, что в случае успешного завершения каждого квартала я могу записываться на любой тренинг для менеджеров в Европе.
Таким образом, каждый квартал я выбирал город или страну, где я еще не бывал, и записывался на тренинг для менеджеров. Поскольку корпорация не жалела денег на наем лучших тренинговых компаний из разных стран, то я без отрыва от производства фактически получил третье образование уже по управлению бизнесом. Моя команда одобрительно относилась к тому, когда я, возвращаясь из очередной недельной командировки, начинал практиковать новые инструменты. Лучших продавцов я отправлял на тренинги, которые мне самому понравились. Единственная ловушка, которая была во всем процессе, оказалась вот в чем. Нужно было внимательно смотреть, на каком языке будет проводиться тренинг, особенно если летишь не в англоязычную страну.
Но в этот раз все было по-другому: этот тренинг был обязателен к посещению всеми руководителями продаж в Oracle Direct EMEA. Занятия вел Кит Розен (Keith Rosen), автор ряда книг по коучингу в продажах, в частности «Коучинг: как сделать продавцов чемпионами по продажам» (Coaching Sales People into Sales Champions), которая была опубликована лишь за два года до описываемых событий и копию которой получили все обучающиеся. Такие сессии, как в Праге, прошли в Дублине (несколько раз), Берлине, Дубае, а потом и за пределами EMEA, например, в Индии, так что это были самые настоящие гастроли.
В самом начале тренинга я узнал, как зовут тренера Тайгера Вудса и то, что появление великих спортсменов — немалая доля заслуги их тренеров. Чтобы продавцы становились суперуспешными, руководить ими должны не просто менеджеры, а тренеры или коучи. Нам сообщили, что мы поймали удачу за хвост и к нам в руки попала уникальная методика Кита Розена L.E.A.D.S., благодаря которой можно достигать со своей командой феноменальных результатов.
Процентов 10–20 из предложенного материала я не знал, но сам по себе тренинг был скучным, не ощущалось погруженности аудитории. Я единственный из группы высказывал вслух сомнения в ценности процесса, чем вызывал недовольство как своего менеджера, так и руководителя департамента по развитию навыков Oracle Direct EMEA.
Когда руководителей продаж попросили разбиться на пары и провести по очереди коучинг друг друга, наступила кульминация неловкости. Люди сидели друг против друга с листочками бумаги, c минимумом эмоций зачитывали вопросы L.E.A.D.S. и давали на них лаконичные ответы. С тем же успехом можно было зачитывать вопросы по диагностике стиральной машины или методику допроса вражеского языка. Пикантности добавляло то, что английский не был родным ни для кого из обучаемых, а какие-то эмоции наблюдались только у пары коллег, которые сразу перешли на польский, и у нас с напарником, где мы много шутили.
После тренинга всех отправили по командам, снабдив требованием проводить с каждым из подчиненных еженедельные часовые коучинги по методике L.E.A.D.S. Этот процесс отслеживался, и продавцы Oracle Direct регулярно отвечали на опросные листы о качестве и количестве коучинга со стороны руководства.
Вернувшись в Москву, я предложил своим сотрудникам выбор: или мы проводим часы по методике L.E.A.D.S., или продолжаем сформированную и приносящую результаты процедуру, включив в нее пару удачных находок из L.E.A.D.S. Выбор был очевиден.
Сложнее обстояло дело с моим собственным менеджером, который честно пытался провести коучинговые сессии со мной по методике Кита Розена. Тогда я заметил интересные изменения в поведении шефа. Как человек корпоративный, он не мог не выполнять указания руководства, но он не всегда был готов получать честные ответы на задаваемые им же вопросы. В конце концов мы забросили навязанную форму коучинга, но у нас осталась возможность обсуждать некоторые серьезные разногласия в более открытой манере.
При первой же возможности пообщаться напрямую со Стефаном Руссе (Stéphane Rousset) — руководителем Oracle Direct EMEA и шефом моего шефа — я спросил, зачем нужна была эта коучинговая профанация. Стефан только улыбнулся. По его мнению, многие руководители в организации, которая к тому моменту уже насчитывала около тысячи сотрудников, совершенно не общались со своими подчиненными на личном уровне, фокусируясь исключительно на обсуждении текущих сделок.
Инициатива, связанная с коучингом, предоставляет единый регламент и время, когда руководитель может лучше узнать своего подчиненного, понять не выдуманные, а реальные проблемы в его работе. Стефан прекрасно осознавал, что кому-то коучинг не даст ничего нового, кто-то по разным причинам не воспользуется им, но большинство менеджеров станут чуть лучшими руководителями и будут формировать более сильные команды.
До разговора со Стефаном я не воспринимал коучинговую инициативу с такой точки зрения, и мне стало интересно проверить это на практике. Я обратился к Йохану Чеху (Johan Cheikh), который тогда работал выделенным коучем в пражском хабе Oracle Direct. Его работа чем-то напоминала работу психолога в школе, к нему обращались продавцы либо по собственной инициативе, либо по направлению руководителя. Йохан даже начинал коучить некоторых моих сотрудников, но в Москве его услуги не были особо востребованы.
Он отметил, что часть менеджеров активно использует данную методику, и их коммуникация с командами стала заметно лучше. Это в первую очередь отмечают продавцы, имевшие ранее проблемы в общении с руководителем, которые они пытались решить вместе с Йоханом.
Особенность коучинговой инициативы состояла в создании дополнительного измерения в системе коммуникации внутри команд. При этом сама методология коучинга была неплохая, разве что излишне усложненная для создания возможности брендирования. Если для небольшой команды в Москве я мог позволить себе индивидуальный и довольно разнообразный подход к руководству людьми, то на уровне организации в тысячу сотрудников изменение могло проходить только в очень узкой сфере.
Фактически Стефан и Кит создали асимметрию в процессе коммуникации руководитель — подчиненный, которая позволила большинству руководителей вырваться из модели «белка в колесе» и узнать много нового о своих командах, после чего принимать более адекватные управленческие решения. Риск данной инициативы состоял в том, что если по каким-то причинам результаты организации оказались бы хуже к концу года, то руководство могли обвинить в том, что оно сжигало ресурсы организации зазря. Но этот риск в Oracle был минимален.
Особенность инициатив в механизме не только в инерционности организации при проведении изменений, но и в том, что после успешного завершения инициативы ее результаты будут чувствоваться еще долгое время, так как обученные люди и оптимизированные процессы будут повторять лучшие практики, которые в прошлом принесли им успех.
По окончании финансового года был опубликован рейтинг менеджеров с точки зрения проведения коучинга своих команд. Довольно неожиданно для меня и моего шефа я оказался на первом месте среди сотни менеджеров Oracle Direct EMEA. Для человека, который поначалу критиковал данную инициативу и не стремился участвовать в соревновании, это вдвойне приятно.
Скорость войска всегда определяется по скорости самого тихоходного подразделения, поэтому хорошая инициатива в механизме должна быть похожа на прилив — она должна поднимать все лодки.
За последние несколько лет на страницах публикаций и маркетинговых материалов стали мелькать словосочетания, в которые входят два английских слова: data driven. Это может быть data driven decision — решение, принятое на основе данных, data driven organization — организация, приводимая в движение данными, data driven culture — (корпоративная) культура, основанная на работе с данными.
Устоявшегося перевода data driven в русском языке нет, но в дальнейшем я буду использовать прилагательное фактостремительный. В физике центростремительная сила — это одна из проекций силы инерции, которая направлена к центру вращения. Например, когда мы раскручиваем вокруг себя привязанный к веревке камень, именно центростремительная сила, связанная с наличием веревки, не дает камню удалиться от нас. В случае же вращения Земли вокруг Солнца роль веревки выполняет сила гравитации. Фактостремительная организация крепко связана «веревкой» с фактами, присутствующими в собираемых ею данных, соответственно, при принятии фактостремительных решений эти данные учитываются, а на неожиданное изменение данных такая организация быстро реагирует, пытаясь им воспользоваться или минимизировать его влияние.
Практически одновременное появление моды на облачные технологии, подписку и аренду программного и аппаратного обеспечения, понятия фактостремительности, интернета вещей, искусственного интеллекта далеко не случайно. Дело в том, что IT-гиганты в рамках своих старых бизнес-моделей достигли физических и логических пределов роста.
Если бы существовало много людей, еще не охваченных персональными компьютерами на работе или дома, и рынку ПК было бы куда расти, Microsoft бы продолжала продавать «бессрочные» лицензии на Windows и Office. Если бы было много пользователей, еще не ставших клиентами телекоммуникационных компаний или банков, то Oracle продолжала бы продавать свою одноименную СУБД в виде «бессрочных» лицензий и в ус бы не дула.
Но рынок информационных технологий стал сверхнасыщенным, а стоимость новой продажи неохваченному пользователю Windows или Office — очень высока. Ситуацию можно сравнить с падением добычи у старой нефтяной скважины: если раньше нефть или деньги фонтанировали сами, то нынче требуется прикладывать усилия, чтобы хотя бы удержать добычу на прежнем уровне. При этом именно IT-рынок во многом обеспечивал рост рынка фондового.
За последние пять-семь лет я много раз видел в презентациях больших корпораций, бизнес-школ, коллег консультантов, министров и даже премьер-министров один и тот же слайд с первой десяткой компаний по уровню капитализации в мире. Большинство этих компаний тем или иным образом было связано с информационными технологиями. После показа слайда всегда следовал вывод, что раз IT или цифровые компании успешны, то всем остальным нужно проводить цифровую трансформацию.
IT прочно заняли свое место, поэтому они начали менять бизнес-модель и продавать не обслуживание (автоматизацию) рабочих станций или пользователей, а обслуживание гигабайт или размера хранилища данных на «облачном» сервере. В отличие от рабочих станций и пользователей, гигабайты не имеют логических ограничений для роста, и на этом строится весь расчет инвесторов в IT.
Тем не менее фактостремительная корпоративная культура — это реальная асимметрия механизма организации, которая может обеспечить опережающий рынок рост бизнеса.
В начале 2000 года я получил одновременно тему бакалаврского диплома, который должен был защитить в июне, и приглашение посетить компанию в Германии. Мы с моим напарником месяцев восемь как занимались заказной разработкой программ для трех иностранных компаний. Бизнес шел ни шатко ни валко: для реализации проектов мы нанимали других студентов, я занимался постановкой задачи и проверкой результата перед пересылкой заказчику, а мой напарник, который уже не жил в общежитии и имел постоянный доступ в интернет, вел коммуникацию с клиентами.
Наш немецкий клиент, для которого мы делали какой-то странный модуль визуализации непонятного нам каталога, вдруг очень настойчиво попросил моего напарника приехать. С учетом того, что в программировании я разбирался лучше, ехать нужно было вдвоем, но у меня, как назло, закончился срок действия загранпаспорта. Кроме того, я не очень хотел ехать в связи с занятостью по дипломной работе.
Мы описали нашему контактному лицу ситуацию и оценили время получения загранпаспорта в два месяца, плюс время на получение визы, и попросили сдвинуть визит на июль. На следующее утро пришел вопрос: «Есть ли возможность сделать паспорт быстро?». Мы нашли предложение сделать «мидовский» паспорт за два дня за 500 долларов, о чем и сообщили клиенту. Через три дня нам на счет упали 500 долларов, и я понял, что мог бы попросить 1000.
Паспорт мне сделали за три дня, получение виз также не заняло много времени, и мы отправились в город Гаггенау в компанию PEUS-Systems. Компания занималась разработкой и производством систем стендового тестирования для автомобилей и их отдельных элементов — двигателей, шасси и т.д. Клиентами ее были крупнейшие автомобильные компании в Германии, Соединенных Штатах, Японии, а сами установки, хотя и не занимали лидирующих позиций, но встречались везде, где производят автомобили, например в Бразилии, и, как потом оказалось, на АвтоВАЗе. Чтобы модель автомобиля была допущена к продаже на рынок, она должна пройти законодательно определенные тестовые испытания. И такие компании, как PEUS, AVL или Horiba, как раз и производят необходимое для этого оборудование и программное обеспечение.
Первые две-три недели мы не понимали причины столь срочного вызова. Нам выделили комнату в общежитии на территории офиса, в рабочие дни кормили обедами, всегда были доступны чай, кофе, минеральная вода, а на выходные давали ключи от корпоративной машины эконом-класса, и мы путешествовали по Германии и Франции и платили лишь за бензин. Конечно, когда визуализация каталога попала ко мне в руки, то за две недели удалось сделать раза в три больше, чем за предыдущие четыре месяца, тем более можно было непосредственно общаться с заказчиками и пользователями проекта.
Оказалось, что компания PEUS-Systems широко использовала разработки программного обеспечения на аутсорсинге и у нее были долгосрочные контракты с небольшими фирмами в Киеве и Минске, а под новый проект они наняли группу программистов из Закавказья. Это была группа из пяти человек в спортивных костюмах, и только самый старший из них разговаривал по-английски. Они регулярно о чем-то спорили в своем углу, отчаянно жестикулируя.
Когда я узнал, что это продолжается уже четвертый месяц, и увидел грустные глаза своего будущего шефа, Алекса Прессла, стало ясно, что нас пригласили на смотрины в качестве потенциальной замены. На исходе третьей недели Алекс сказал: «Ты говорил, у тебя есть друзья, которые хорошо программируют». Я спросил, сколько нужно человек и что нужно сделать.
За полгода до этого Алекс сумел продать руководству DaimlerChrysler инновационную идею. Речь шла о создании стенда тестирования на базе обыкновенного компьютера с операционной системой Windows NT 4.0. До этого стенды создавались на базе специального и очень дорогого программно-аппаратного комплекса, работающего в реальном времени, с существенными ограничениями по возможности управления процессом. Алекс нашел системы программирования, которые были способны работать в реальном времени на обыкновенных компьютерах, нужно было только написать всю функциональность стенда на их основе. Внутреннее проектное название было RTA — Real-time adapter, или адаптер реального времени для ПК.
Алекс дал мне распечатку изначального техзадания на шесть страниц и сказал, что если через два месяца ему нечего будет показать DaimlerChrysler, то его закопают на ближайшей лужайке. Рассказ сопровождался активной жестикуляцией, в том числе движениями человека, работающего лопатой.
Проведя еще две недели в Гаггенау, я переписал и уточнил техническое задание, которое разрослось до 70 страниц, вернулся в Москву, пригласил еще двух друзей, и действующая версия RTA появилась пусть не через два, но через три месяца, а еще через четыре мы устранили все недочеты и новые стенды тестирования заработали на реальном производстве.
RTA был очень функциональной и гибкой программой со множеством подсистем, но самым ключевым ее функциональным блоком была система обработки данных. Инструмент, на котором мы программировали RTA, позволял через специальные ячейки памяти компьютера получать внутрь нашей программы данные с подключенных датчиков, а нам самим отсылать управляющие команды на исполнительные устройства. Обновления данных обычно происходили каждые десять миллисекунд, а система на практике легко держала нагрузку в 5000 подсоединенных датчиков и исполнительных устройств.
Логическое управление было организовано через специальные структуры, которые мы назвали каналами. Так, например, сигнал от датчика давления оформлялся как логическая сущность — канал, который можно было использовать в качестве объекта внутри специально разработанного мною языка программирования RTA. Пользователи RTA — инженеры — для каждого канала определяли дополнительную информацию: что он измеряет, в каких единицах измерения, насколько часто обновляется и другие метаданные.
Дополнительная функциональность, которую мы назвали Alarm, или сигнал тревоги, позволяла проверять, насколько текущее значение канала находится в диапазоне практически доступных значений, а в случае выхода за этот диапазон (например, при физическом отключении датчика или ошибок в его работе) предпринимать программным образом или вручную некоторые активные действия.
Но это были только первичные каналы. В реальных тестах информацию часто нужно было преобразовывать, например, данные давления использовать не в единицах измерения датчика, а в тех, которые требует законодательство. Для этого создавались дополнительные каналы — расчетные, которые описывались некоторыми правилами преобразований первичных каналов. Также многие физические сущности нельзя было измерить напрямую, но их можно было получить с помощью расчетных каналов.
Наконец, были внутренние каналы, которые отвечали за хранение информации о состоянии самой системы тестирования, и управляющие каналы, через которые мы отправляли команды на исполнительные устройства. Как я говорил, каналы, по сути, были переменными внутри специального языка программирования. Из первичных и расчетных каналов можно было только получать их текущее значение, в управляющие каналы можно было записывать свои значения, а с внутренними каналами можно было проводить операции как чтения, так и записи.
Кому-то это может показаться странным, но основные принципы эффективной организации работы с источниками данных совершенно не изменились за двадцать лет, прошедших с разработки RTA.
У многих разработчиков программного обеспечения есть продукты, которые называются «каталогами данных» или «магазинами данных». Любая база данных или файл могут быть занесены в каталог данных как первичный источник. Специалисты по качеству данных дополняют каждый источник метаданными, описывающими его предназначение, количественные и качественные характеристики.
Хорошие каталоги данных обладают инструментами, которые позволяют проверять качество данных и с помощью операторов его увеличивать. И, наконец, в каталогах данных с помощью специальных операций, называемых ETL-маршрутами (от Extract-Transform-Load) можно на основе первичных источников данных формировать специальные производные (расчетные) источники данных, которые наиболее оптимальны для каждой решаемой задачи.
Технология работы с данными при помощи каталогов данных, где содержатся первичные и расчетные источники, — на данный момент сильнейшая положительная асимметрия в механизме работы фактостремительной организации. Для реализации такого подхода компании создают специальные центры компетенций по работе с данными. Этим занимаются Hapag Lloyd, HSBC, IKEA в мире и «Газпром нефть», «Росгосстрах», «Утконос» в России.
Тут нужно понимать, что каталоги данных — это не противоположность аналитической работы с Microsoft Excel, а отрицание подхода с единственным источником данных на предприятии, куда интегрированы все возможные данные. Действительно, изначально многие инструменты Business Intelligence (исторически устоявшийся, но не совсем корректный перевод — «Бизнес-аналитика») представляли собой инструменты частичного представления данных из нескольких логически связанных в одной базе данных таблиц. Так Oracle BI в девичестве использовалась для создания отчетов внутри CRM Siebel, приобретенной Oracle.
Вся «аналитика» заключалась исключительно в связях между таблицами внутри базы данных, а BI по этим связям и строила набор связанных отчетов. Многие до сих пор живут в этой парадигме, пытаясь строить одно большое «озеро данных» с единой структурой, в том числе потому, что к нему легко прикрутить простейшие BI инструменты, к которым они привыкли. К сожалению, это хорошо работает с задачами, которые соответствуют ранее выбранной структуре базы данных, и плохо со всеми остальными задачами. Причем «всех остальных» будет подавляющее большинство вне зависимости от выбранной структуры базы данных, это просто математический факт.
Работа с помощью каталогов данных позволяет для каждой конкретной задачи формировать свою систему связей между таблицами с помощью расчетных источников данных. Собственно аналитическая работа переносится с момента формирования связей в первичных источниках данных (базах данных или файлах) на момент создания расчетных источников данных в каталоге. Практика показывает, что для формирования качественного отчета 85% времени проводится на уровне каталога данных и лишь 15% на уровне визуализации и построения отчетов.
К сожалению, реализация аналитической работы через каталоги данных — необходимое, но не достаточное условие для построения фактостремительной организации. Мой друг, коллега, безмолвный соавтор и первый редактор этой книги Сергей Сошников назвал недостающее звено между каталогом данных и фактостремительной организацией геном любопытства в культуре организации, с чем я полностью согласен.
Где-то в начале 2001 года я заметил очень существенное изменение качества запросов к команде разработки RTA, причем исключительно от одного немецкого автомобильного концерна. Обычно запросы были связаны с обнаружением ошибки в работе RTA, что в среднем подтверждалось в 20% случаев, или были запросы на новую функциональность, которую в 95% случаев можно было реализовать имеющимися инструментами.
Но тут пришло несколько запросов о том, как реализована RTA в некоторых своих модулях. На первые два я ответил обстоятельно, но на третий уже начал задавать встречные вопросы. Выяснилось, что новый стенд тестирования от компании PEUS-Systems обнаружил в новых двигателях одного немецкого завода несоответствие законодательным требованиям по безопасности. Проблема состояла в том, что такое несоответствие не обнаруживалось на стендах предыдущего поколения как от нашей компании, так и от конкурентов.
Ошибка могла быть в самих двигателях, в инструкциях тестирования, подготовленных инженерами PEUS, и в RTA, которая эти инструкции исполняла. Клиент не спешил признавать, что ошибку сделал именно он. Его представители начали последовательно искать ошибку в других элементах системы. Сначала они проверили инструкции тестирования, которые были им доступны, и, не найдя там за что уцепиться, начали искать ошибку в RTA.
Процесс от первичного обнаружения ошибки до отзыва всех проблемных двигателей производителем занял почти пять месяцев, в течение которых мы сумели доказать клиенту, что наша программа работает правильно, и даже помогли обнаружить ошибку с помощью стендов предыдущего поколения. Просто то, что можно было сделать с RTA за один четырехчасовой прогон, на старой системе занимало пять прогонов с последующим сведением и анализом данных.
Узнав, что ему придется отозвать большое количество автомобилей с новыми двигателями, клиент, конечно, не пришел в восторг. Но ведь автомобильные концерны тратят деньги на системы стендового тестирования, как раз чтобы предотвращать выпуск проблемного оборудования, которое может привести к существенным потерям для компании в будущем.
Ген любопытства как раз и определяет реакцию компаний на новую информацию, которая разрушает их представление о себе и о мире вокруг. В культуре большинства компаний ген любопытства отсутствует, поэтому любую «опасную» для их мира информацию стараются замолчать или опровергнуть. Компании же с геном любопытства готовы платить только за неожиданную информацию.
С помощью аналитической работы в каталогах данных компания фактически проводит стендовое тестирование различных гипотез, связанных с собственной работой и поведением клиентов или поставщиков. Умение формулировать неожиданные гипотезы, настроенные скорее на нарушение status quo, чем на его подтверждение — самый видимый фенотип гена любопытства.
Когда Сергей Сошников работал в компании Qlik, он перестроил работу канала продаж с фокуса на функциональность BI-инструмента на продажу идеи центра компетенций в области анализа данных, которые сейчас мы называем 3DC (Data Driven Decisions Center или центром принятия фактостремительных решений).
Для того чтобы 3DC заработал на полную мощность, недостаточно было продать функциональность каталога данных, нужно было найти людей в бизнес-подразделениях компаний-клиентов, которые готовы были формулировать неожиданные гипотезы и фактостремительно их проверять.
Такой процесс, как и любое изменение механизма, обычно очень долго стартует, но, однажды набрав обороты, начинает развиваться самостоятельно. Так, одному из промышленных клиентов Сергея потребовался почти год от первоначальных испытаний технологии Qlik до принятия решения о распространении методологии 3DC во всей организации.
Конечно, сначала легче всего собрать уже упавшие с дерева яблоки: у клиента было несколько самостоятельно разработанных IT-систем, к которым Сергей добавил аналитическую функциональность. С приложениями стало легче работать, но для руководства компании это улучшение пока не являлось стратегическим. Следующей попыткой было предложение аудита остатков заявочных компаний, другими словами, закупок организации. И хотя эта тема очень популярна среди большинства промышленных предприятий, но и она не заинтересовала клиента.
В конце концов сотрудники предприятия, продвигавшие инициативу 3DC, сумели показать своему руководству выгоду от внедрения такого подхода к анализу данных. Между заводом и поставщиком электроэнергии был заключен договор, по которому предприятие оплачивало электричество согласно тарифу только в пределах лимита. При превышении лимита предприятие было обязано платить штрафные санкции, о которых узнавало уже по факту.
Объединив в аналитической платформе Qlik информацию от как минимум двух первичных источников данных (самостоятельно разработанной ERP системы и производственных данных из OSIsoft PI System) и сформировав расчетный источник данных под задачу, специалисты предприятия узнали большинство факторов производственного процесса, которые приводят к перерасходу электроэнергии. Отслеживание этих факторов в специально разработанных и автоматически обновляемых отчетах позволило компании практически минимизировать штрафные санкции от поставщика электроэнергии. Именно после успешной реализации такого проекта руководство компании дало «зеленый свет» на повсеместное внедрение 3DC.
Этот случай интересен еще и тем, что негативная асимметрия со стороны поставщика, которая не устранялась напрямую, была решена за счет позитивной асимметрии в механизме работы с данными.
К сожалению, далеко не все компании обладают геном любопытства или могут его создать с помощью социальной инициативы наподобие коучинговой в Oracle Direct. Есть прямая корреляция между этичным ведением бизнеса и наличием в культурном коде компании гена любопытства. Открытые и ведущие этичный внутренний и внешний бизнес компании реализуют 3DC наиболее успешно. В конце концов 3DC — отличный инструмент и для тестирования своих гипотез отделом комплаенса.
Удастся ли IT-компаниям расти бесконечно, продавая своим клиентам бесконечные гигабайты облачного пространства? При наличии у клиентов системы стендового тестирования бизнес-гипотез, скорее нет, чем да. Но детально мы обсудим этот вопрос при обсуждении инициативы в клиентском поведении и регулировании.
Войти с помощью соц. сетей: