Тони Бирн: в центре внимания эксперт

В этой новой серии мы углубимся в истории наших опытных авторов. Это интервью было отредактировано для ясности и длины.

Тони Бирн — основатель Real Story Group, аналитической фирмы по технологиям. RSG оценивает технологии Martech и CX, чтобы помочь владельцам корпоративных технологических стеков. Он рассказал нам о том, что был болваном, и о том, как падение Советского Союза привело его на путь основания RSG.

В: Откуда ты?

О: Я вырос в Висконсине, родился на юго-востоке штата Висконсин в Милуоки. и, уехав в колледж, но вы получаете эту специальную выездную визу, когда вы уезжаете из Висконсина, которая представляет собой униформу Green Bay Packers, сырную голову и все такое прочее. Так что в глубине души я все еще, как говорится, очень «Сконни». На самом деле, мы собираемся отправиться на две недели в северный Висконсин. Так что я взволнован этим.

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

В: Как это происходит?

О: Это было в тот странный период, когда пала Берлинская стена, но новый облик того мира еще не сложился. Я возглавлял эту группу, которая в конечном итоге создала то, что мы назвали Корпусом мира в Интернете. Мы взяли молодых, технически подкованных русскоязычных, студентов и аспирантов и отправили их с кучей модемов и немного денег, чтобы они работали с университетами и НПО, чтобы помочь им выйти в интернет. Это превратилось в помощь им в создании веб-сайтов, когда появилась Всемирная паутина, чтобы помочь им создавать сообщества и взаимодействовать в реальном мире.

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

Вопрос: Что вы разработали?

О: Первоначально это был веб-сайт нашей некоммерческой организации, а затем мы начали создавать легкие приложения на Perl. Так что я изучил Perl достаточно, чтобы быть опасным и доставлять некоторые небезопасные модули, и изучил PHP и немного javascript, когда он появился. Затем, во время бума доткомов, я возглавил группу инженеров в системном интеграторе. Это было одно из агентств гибридных системных интеграторов, которые существовали в те дни.

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

Поэтому я пошел сам и основал CMS Watch, предшественницу Real Story Group. Одно из решений, которое мы приняли на раннем этапе и которое, как я обнаружил позже, было уникальным в мире аналитиков, заключалось в том, что мы решили работать только на стороне покупателя. Мы работали только с предприятиями-конечными пользователями и никогда не советовали и не консультировались с поставщиками, потому что считали это конфликтом интересов.

A: Что привело к…?

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

В: Что должен знать каждый, собирая стек?

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

Так что есть ощущение, что если я просто сведу все это к одному поставщику, насколько это возможно, это каким-то образом упростит мою жизнь, и этот поставщик будет нести ответственность за мой успех, но на самом деле это не так. Вы по-прежнему отвечаете за свой успех. Реальность такова, что ни Adobe, ни Salesforce, ни Microsoft, ни Oracle, ни Acoustic не могут охватить весь ваш стек. Таким образом, у вас будет составной стек. Вопрос только в том, насколько составной.

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