SAP BW: Муки рождения

Часто от многих людей можно слышать один и тот же вопрос: "Зачем SAP нужно было создавать с нуля систему хранилищ данных и весь инструментарий Business Intelligence, когда на рынке уже существовали производители, предлагающие целый ряд сложившихся продуктов такого класса?" Ответить на это будет довольно просто, если мы сначала взглянем на историю развития SAP в области отчетности, анализа и управления данными. На самом деле, у SAP уже существовали наработки, частично или полностью реализующие такую функциональность в составе системы R/3. И если мы проследим эволюцию этих инструментов, то поймем, что решение о создании отдельного продукта было принято не за один день.

Началось все с разработки внутри R/3 так называемого слоя информационных систем - уровня абстракции, который позволял упростить создание различных отчетов на базе OLTP данных. Этот уровень абстракции появился в R/3 очень давно - еще с версии 2.0 (напомню, что текущая версия 7.10). Однако проблема состояла в том, что реализация слоя информационных систем очень разнилась в различных частях системы. Например, Информационная система логистики (Logistics Information System, LIS) имела один набор инструментов доступа к данным, называемый standard and flexible analysis, в то время как Информационная система персонала (Human Resources Information System, HRIS) имела совсем другой набор инструментов, реализованный с помощью отчетов. Разработка каждой из этих частей системы велась отдельной командой. И хотя такая узкая специализация позволяла создавать более продуманные решения с точки зрения разработки, разность подходов создавала довольно большие проблемы в процессе внедрения.

Во-первых, в информационных системах сильно отличались структуры данных и методы доступа к ним, поэтому для их настройки и администрирования требовались разные специалисты. Второй аспект уже касался конечных пользователей. Дело в том, что в зависимости от прикладной области, в которой изначально обрабатывались данные, пользователи были вынуждены изучать и использовать разные инструменты доступа. Во многих случаях на вид простые отчеты приходилось реализовывать в виде целого набора отдельных отчетов или писать специальные ABAP-программы. Все это вызывало у заказчиков огромное разочарование и, в конечном итоге, выливалось в существенное удорожание и затягивание внедрений. К примеру, примитивный отчет, в котором напротив каждой строки заказа должна стоять сумма текущей задолженности перед поставщиком, реализовывался посредством двух различных информационных систем.

Первая разработка, созданная SAP целенаправленно в области OLAP, называлась аналитический процессор (research processor). В начале 90-х этот инструмент использовался в подмодуле Анализ прибыльности модуля Контроллинг (Controlling Profitability Analysis, CO-PA). Аналитический процессор позволял создавать многомерные отчеты по прибыльности и организовывать просмотр таких отчетов на различных уровнях агрегации. Этот инструмент существует в R/3 и поныне, нося название сквозная отчетность (Drill-Down Reporting). Повсеместному распространению возможностей сквозной отчетности внутри R/3 способствовал постоянно растущий спрос на многомерную отчетность со стороны пользователей системы.

Итак, в определенный момент SAP осознала ситуацию, в которой оказалась. С одной стороны, компания уже обладала рядом очень мощных аналитических инструментов, реализованных в R/3. С другой стороны, существовала масса клиентов, которым были остро необходимы инструменты для анализа данных. На почве этого неудовлетворенного спроса процветал целый ряд производителей продуктов Business Intelligence, а SAP теряла клиентов, обладая при этом всеми компетенциями, необходимыми для создания полноценного решения в области хранилищ данных.

Результатом такой ситуации стало решение создать так называемый Аналитический сервер (Research Server), который позже и получил имя SAP Business Information Warehouse (SAP BW). (Кстати, думаю, многим консультантам SAP BW всегда было интересно, почему все, что связано с BW - транзакции, пакеты, функциональные модули и проч. - имеет префикс RS; так вот и ответ на этот вопрос). Эта инициатива стала самым крупным проектом разработки в истории SAP, не считая, конечно, системы R/3. В первой половине 1997 года SAP отобрала пять компаний-клиентов для проведения пилотных внедрений SAP BW. В начале 1998 года для дополнительного анализа технических требований и проверки продукта "в полевых условиях" среди уже шести клиентов была запущена так называемая Программа первых клиентов (Early Customer Program, ECP). Самой известной компанией, принявшей участие в этой программе, была корпорация DEC (Digital Equipment Corporation). В сентябре 1998 года SAP BW версии 1.2A стал доступен всем остальным клиентам. Вот таким образом и состоялось рождение BW.

Думаю, никогда при проектировании SAP BW не вставал вопрос использования какой-либо сторонней OLAP разработки. Скорей всего, без долгих колебаний было принято решение просто перенести целый ряд концепций из R/3 и воспользоваться существующим опытом. Двумя яркими примерами концепций BW, изначально реализованных в R/3 (имеются в виду именно концепции, а не сам программный код), могут стать система раннего предупреждения (Early Warning System) и интерфейс "отчет-отчет" (Report-to-Report Interface). Первая из этих концепций позволяет устанавливать пороговые значения или условия, при достижении которых система выдает сообщение с предупреждением. Например, такая возможность может использоваться для мониторинга состояния складских запасов. Пользователь устанавливает минимально допустимое количество единиц на складе и временной интервал, по которому система будет производить проверку. При достижении установленного порогового значения система автоматически уведомит ответственное лицо о том, что нужно отправить поставщику заказ для пополнения складских запасов.

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

Мы рассмотрели лишь две концепции, перенесенные из R/3 в BW. В действительности их намного больше. Выходит, что еще до создания BW, компания SAP имела многолетний опыт построения OLAP инструментов и решений для управления данными. И этот факт совершенно нельзя сбрасывать со счетов при рассмотрении SAP в качестве производителя продуктов Business Intelligence и систем хранилищ данных.

При подготовке материала использовались следующие источники:

• K. McDonald, A. Wilmsmeier, D.C. Dixon, and W.H. Inmon. 2002. "Mastering the SAP Business Information Warehouse". Wiley Publishing, Inc.
• N. Hashmi. 2000. "Business Information Warehouse for SAP - Your Guide to Data Warehousing and BW". Prima Publishing
• help.sap.com

more >>

Знакомьтесь, это - SAP BW, OLTP-система (проект РЖД №1: КАК+ПОЧЕМУ)

Здесь я продолжу рассмотрение одного проекта внедрения SAP в РЖД. Первую часть, описывающую суть поставленной задачи, смотрите здесь. Ну, а далее последует еще одна, завершающая часть цикла статей об этом проекте, где я покажу, что мог бы получить заказчик, если бы к проекту подошли с других позиций и пользовались подходящими технологиями.
Итак, система была реализована, как уже, наверно, ясно, на базе SAP BW. Был создан набор отчетов, запуская которые пользователь мог получить списки "подозрительных" вагонов. Отчеты брали информацию из хранилища данных BW. Чтобы от организаций в хранилище данных попадала информация о вагонах, был изготовлен web-интерфейс, в котором пользователь указывал имя файла с данными, нажимал кнопку "Обработать", и данные попадали в хранилище. Немногим сложнее устроен процесс работы с акцептами. Сначала пользователь должен сформировать отчет со списком "подозрительных вагонов", затем сохранить его где-нибудь у себя на компьютере и одновременно отослать организации. Потом, когда от организации придет ответ, нужно будет открыть сохраненный отчет, проставить в нем кое-где специальные отметки, и далее через web-интерфейс загрузить этот файл в хранилище. Все звучит просто и логично, не так ли?
Теперь приглядимся чуть внимательнее. Для начала рассмотрим ту часть получившейся системы, с которой уже непосредственно сталкивается заказчик. Что же он видит?

• Тормозная и глюкавая загрузка. С глюками тут, конечно, вина самого SAP, ибо BW при определенном стечении обстоятельств (встречавшемся, тем не менее, довольно часто) просто "ломается", и пришлось даже описать "пляски с бубном" для обхода этой ситуации в инструкции пользователя. Но тут дело наживное - ошибку исправят и выпустят заплатку. А вот с тормозами принципиально уже ничего не изменится. В инструкции пользователя так и написано: загруженные данные появятся в системе в среднем через 10 минут; чтобы проверить, появились ли данные, запустите или обновите отчет. И вот, представляете, пользователь в течении 10 минут сидит перед открытым отчетом и кликает кнопку "Обновить". И ждет, пока что-то появится. А оно, ведь, может и не появиться. Например, очень часто при загрузке в BW возникают разные ошибки, и процесс загрузки не доходит до конца. Все, что может сделать в данной ситуации пользователь, - это пожаловаться: "Я делаю все, как написано, а файл не грузится". Ведь никто не станет отправлять его на курсы по администрированию BW или нанимать для этой цели специального человека.
• Отчетный беспредел. В техническом задании были довольно четко расписаны все алгоритмы формирования отчетов. Но наивный заказчик не знал, что за инструмент будет выбран для реализации. Когда изготовили первые несколько отчетов, стали заметны некоторые хитрые вещи: то каких-то вагонов недосчитаются, то какие-то - лишние. Стали разбираться и в итоге выкатили несколько дополнительных проектных решений, которые предусматривали "расчленение" каждого отчета на 3 или даже на 5 подотчетов, имеющими между собой некоторые отличия. Проектные решения подписали и реализовали. Ну, я думаю, понятно, насколько быстрее работают сразу 5 отчетов вместо одного. И это при условии того, что и так каждый из них не быстр. Я лично замерял: был отчет, который открывался 23 минуты! Уже не говорю о том, что знать, как пользоваться всем этим лесом отчетов со всеми нюансами нужно было пользователям, у которых и без этой системы было полно других развлечений.

А сейчас взглянем, что же там в системе "под капотом".

• Атака клонов. Множество почти одинаковых по настройкам, но, тем не менее, довольно существенно отличающихся по поведению отчетов. В итоге их развелось столько, что ни один консультант уже не был в состоянии удержать в голове, какой из них как работает и что конкретно делает. Для внесения правок в отчет, за который не брался всего несколько дней, приходилось разбираться каждый раз почти заново. Был выбран способ реализации, при котором часто стало невозможно пользоваться простым копированием отчетов. В результате нередко очередной отчет-клон необходимо было настраивать "с нуля". За счет OLAP-направленности отчетного движка каждый отчет требовал использования чудовищных по сложности условий, программирования виртуальных показателей и переменных, и еще черт знает чего. Когда к коллективу подключился человек, ранее не участвовавший в проекте, встала задача передать ему свои знания. По завершению последней беседы он с остекленевшим взглядом промолвил: "Да-а, ну, вы тут и навернули... Я, конечно, понимаю как это все круто, но зачем?!"

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

• Демоны-инвалиды. Для обработки данных, загружаемых пользователями, на стороне BW "крутятся" так называемые демоны - фоновые процессы, которые организуют прием данных и запись их в хранилище. Они являются частью новой подсистемы BW - real-time data acquisition (RDA). Не буду углубляться в технические детали, скажу лишь, что подсистема эта на поверку оказалась довольно капризной, и не такой уж real-time. Даже в спокойной обстановке своего офиса консультантам приходилось подолгу разбираться, "почему ни черта не грузится", что уж говорить о таких ответственных и нервных мероприятиях как тестирование или сдача в опытную эксплуатацию. В результате пришлось дойти до того, чтобы обычным пользователям дать доступ к административной части системы (которую, я считаю, они, вообще, не должны никогда видеть) и обучить заниматься вполне администраторскими задачами.

И последнее. Какие я вижу причины такого замечательного результата? Вот они:

• BW - это OLTP-система. Звучит утрированно, но я лично видел на примере нескольких проектов, что многие даже не задумываются о природе BW. Не задумываются о том, что это хранилище данных, а не транзакционная (OLTP) система, не задумываются о том, в чем разница. Меня настолько удручает такая ситуация, что я решил вынести данное заблуждение в заголовок цикла статей. Возможно, с эти можно и поспорить, но я считаю, что отчетность на основе плоских массивов данных должна быть в BW явлением исключительным, маргинальным. То есть, такие отчеты имеют право на существование, но, скажем, в случаях, когда нужно "провалиться" из многомерного OLAP-отчета на детальный уровень. Например, находясь в отчете, отражающем месячную выручку по подразделениям, проверить проводки, составляющие сумму в конкретной ячейке отчета. Использование BW для создания целой системы плоских отчетов - это уже от лукавого.
  Ведь несмотря на то, что отчет строится на плоском массиве данных, сам подход к его настройке остается многомерным, то есть система составляет один запрос к таблицам, быть может, со множеством условий. Но это всего один запрос! И если у нас появляется необходимость с помощью отчета, по существу, соединять несколько независимых выборок данных или производить внутри массива данных какое-то подобие поиска, то придется применять некие "извращения". Например, накладывать дополнительные изощренные условия (что и было сделано в этом проекте), либо получать заведомо более раздутую выборку данных и с помощью самописных подпрограмм вычленять нужные данные. А смысл? Зачем тут, вообще, BW, если все равно программировать? Более того, такие приемы весьма существенно замедляют быстродействие, ведь тогда системе не дают воспользоваться ни специально разработанной для OLAP многомерной схемой "звезда", ни применить множество оптимизаций, которые оказываются бессильными в случаях применения условий или дополнительного программирования. Результат - тормоза и чудовищная сложность настройки.

• BW - это генератор отчетов. "Раз BW умеет выгружать цифры в Excel, значит будем делать все отчеты в BW". Именно так думают многие "специалисты". Нет, и еще раз нет! Ведь, подумайте, что нужно сделать, чтобы вожделенный отчет "заработал в BW". Сначала нужно передать в BW все основные данные, то есть справочники, атрибуты и проч. Затем нужно передать в BW необходимые транзакционные данные. Для каждого из этих процессов, во-первых, нужно подготовить данные к отправке из исходной системы, а для этого нужны настройки и, часто, программирование. Во-вторых, при передаче в BW задействуется вся заложенная там махина ETL со множеством проверок, перекачек и служебных операций. В-третьих, процедуру закачки в BW надо будет проводить регулярно, чтобы отчеты отображали актуальную информацию. И, в завершение, нужно настроить OLAP-отчет, который будет отображать ваши не-OLAP данные. А это, как я уже говорил, значит, что будет программирование, замороченные настройки и тормоза. А что, если захочется еще иметь такую кнопочку, которая бы делала у нас системе то-то? Замечательно, тогда добавим сюда еще немного программирования, обратную выгрузку из BW (ретракцию) или межсистемное взаимодействие. То есть, в результате вместо, допустим, одного ABAP-отчета в R/3 вы получаете полноценное внедрение BW средней степени сложности. Весело? Мне - нет. И даже если это не один отчет, а несколько. Всегда нужно, прежде всего, смотреть на природу задачи, а уже потом выбирать инструмент. И я знаю, что это было сказано до меня, но это так. BW подходит для многомерного анализа данных. Это ваш случай?

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

• Любопытство. Или какие еще можно назвать причины, которые толкают почти каждого профессионала опробовать в действии в своей системе новую модную "мульку"? Под "мулькой" в данном случае я имею в виду real-time data acquisition (RDA) - новую технологию в BW, позволяющую "на лету" подкачивать пакеты данных из внешних систем. Технология эта призвана заменить довольно тяжеловесный процесс загрузки данных BW (длительность которого, к тому же, невозможно гарантированно предсказать) на облегченную процедуру в случаях, когда данные могут поступать регулярно и относительно небольшими порциями. Что ж, несмотря на используемое здесь словосочетание "на лету", RDA не подразумевает использования в режиме интерактива с пользователем. Основная цель этой технологии - сделать аналитическую отчетность, получаемую на базе данных из транзакционных систем, более оперативной; перейти от концепции "ночная загрузка данных" к концепции "данные в течение рабочего дня".
  Неявным, но от того не менее важным, тут является предположение, что данные получаются из надежных источников, целостность данных в которых подразумевается априори. Получаемые данные тогда будут, в основном, безошибочно ложиться на свои места в хранилище, может быть, только в исключительных случаях вызывая ошибки. У нас же в качестве внешних данных выступают файлы с выгрузками из негармонизированных, "недружелюбных" систем, которые содержат множество ошибок, неточностей и отклонений от формата.
  Ну, и наконец, технология RDA пока очень и очень молода, и еще не преодолела, как говорится, первую волну глюков. Это, к сожалению, отразилось на нашем проекте, а не должно было бы. Ведь везде, а в IT - так в особенности, профессионалы всегда должны сначала серьезно протестировать новинку, прежде чем предлагать ее клиенту. Это уже прописная истина.

• Оставьте ваши притязанья. По моей информации, Микротесту "отдали" только делянку с BW. Всем, что касается R/3 и других систем, занимаются другие субподрядчики. А поэтому, даже если в Микротесте захотели бы реализовать этот функционал в R/3, им бы не дали этого сделать. Следовательно, в интересах самого же Микротеста было, ну, если не "впаривать", то строить все свои внедрения вокруг BW. Вот так. Системная архитектура системной архитектурой, а кушать хочется всегда. Рождения уродца было неизбежным, заказчик был обречен. Хочу заметить, что такой фатализм встречается на российском рынке системной интеграции очень часто. Именно поэтому я, все же, довольно мягко отношусь к использованным на этом проекте подходам, точнее к людям, которые их реализовали. В конце концов, выбора у них большого не было, а их работа стала результатом политических решений. А следовательно, вся команда Микротеста была изначально "запрограммирована" на использование BW. Правда, если бы выбор у них таки был, я не уверен, что не вступил бы в действие другой фактор: "BW-шники у нас простаивают, а ABAP-еров свободных нет", как я уже наблюдал впоследствии. Но об этом позже, и это уже совсем другая история.

Ждите продолжения в следующих постах. more >>

Тезисы вальдорфского аптекаря

В журнале Эксперт вышло интервью второго топ-менеджера в SAP AG (напомню, что штаб-квартира корпорации находится в немецком городе Вальдорф) Лео Апотекера. Этот человек, вероятнее всего, в скором времени возглавит корпорацию. Интервью взято еще в конце октября 2007 года, когда господин Апотекер прибыл с визитом в Россию для выступления на Индустриальном форуме SAP 2007, однако напечатано (видимо, по редакционным причинам) только в последнем номере.

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

• претенденты на должность президента SAP,
• частицы корпоративной философии SAP,
• состояние глобальной индустрии IT,
• суть противостояния SAP и Oracle,
• причины покупки Business Objects,
• проблемы мировоззрения многих CIO,
• коррупция vs. прозрачность и эффективность бизнеса,
• явление глобальных бизнес-сетей.

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

Лео Апотекер: <...> Единственный способ оставаться на гребне волны, который мы за 35 лет существования SAP нашли, — это правило, скажем так, держать уши широко открытыми. Слушать. Слушать своего клиента очень внимательно и — что немаловажно — очень активно слушать. Воспринимать и плохие новости, и хорошие. Но и это еще не все. Многие клиенты приходят к нам, чтобы обучиться тому, как вести бизнес завтра, а не сегодня. Приходят, чтобы найти технологию завтрашнего дня. Это значит, что нам надо быть более инновационными, чем они. Таким образом, мы должны постоянно балансировать между двумя этими задачами: слушать, что беспокоит бизнес сегодня, но в то же время думать над решением его проблем в будущем. <...>

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

Эксперт: Скандально известный журналист Николас Карр считает, что индустрия ERP переживает не лучшие времена, потому что ИТ-решения стали типичным коммодити и скоро ERP-вендоры превратятся в «электростанции», ток из которых бежит в каждый дом. <...>

Л.А.: <...> Я абсолютно убежден, что Николас Карр не прав, не прав фундаментально. <...> Потому что любая компания образуется двумя типами бизнес-процессов - стандартными и уникальными. Соотношение - оно, конечно же, зависит от компании, отрасли и еще десятка разных факторов - в среднем 80 на 20. <...> Во всяком бизнес-процессе главное, чтобы он исполнялся вообще и чтобы он исполнялся верно. Так что если мы возьмем другие 20 процентов — уникальных процессов, тех, что отвечают за конкурентные преимущества, они не будут работать, если остальные 80 процентов не будут исполняться верно. Если у вас не работает система приема и отправки платежей, тут уж не до преимуществ. То есть их просто не будет, если не будут работать те самые 80 процентов процессов.

Тут, прежде всего, конечно, надо заметить, что обсуждается знаменитая статья журналиста Николаса Карра (Nicholas Carr) с игрой слов в качестве названия - IT Doesn’t Matter. Надо признать, что журналистская профессия иногда просто требует употребления рубленых фраз и сенсационных выводов, иначе тебя тривиально не заметят. Однако эта статья, вышедшая в 2003 году, вызвала широкую полемику, продолжающуюся до сих пор. Что касается слов господина Апотекера, мне кажется, точку зрения он отстаивает правильную, но защита выбрана неверно. Ведь, если рассмотреть приведенный им пример, то нам становится только очевиднее, что IT превратилось в очередную своего рода коммунальную услугу: нет электричества, нет телефона, нет IT - и бизнес "не поедет". И так оно и есть. Только если компания не включает IT в те 20 процентов своих уникальных бизнес-процессов. Ведь посмотрим на ту же телефонию: она является стержнем (с той или иной долей условности, конечно) таких бизнесов, например, как Skype, Twitter, входит в уникальные 20 процентов. То же и с IT. Кто-то производит продукты IT (Microsoft, SAP), кто-то внедряет их (Ernst & Young, Bearing Point), у кого-то уникальный подход к автоматизации (складской учет в Wal-Mart). А про всех остальных - не надо обманываться: да, IT стало коммодити, это просто базис, на котором строится бизнес.

Л.А.: <...> Oracle и SAP имеют противоположные философии бизнеса. Oracle искренне верит, что рынок софтверных решений давно насыщен, что он развивается неторопливо и темпы его роста очень низки. В такой ситуации логичный выход - заняться поглощением различных компаний и консолидировать свою рыночную долю. Они потратили уже 25 миллиардов долларов на то, чтобы остаться на нашем рынке номером два. Номером два, заметьте. Когда они начали покупать PeopleSoft и других перспективных ребят, разрыв в рыночной доле между нами измерялся единицами процентов. Прошло несколько лет, истрачены миллиарды - а разрыв остается тем же. А между тем, если вы сложите доходы всех предприятий, за последние годы купленных Oracle, и сравните с оборотом самой компании сегодня, 40 процентов первой суммы вы не найдете. Эти деньги пропали, как будто растворились.

Вы знаете, здесь я посоветую всем, кто этого еще не сделал, ознакомиться с книгой Эла Райса и Джека Траута "22 непреложных закона маркетинга" (The 22 Immutable Laws of Marketing). Только, если есть возможность, постарайтесь прочитать ее в оригинале. Лично я видел только безобразные русские переводы и от их прочтения становиться просто тошно. Книжка довольно предвзятая и спорная, и законы, описанные в ней уже неоднократно опровергались, но читать интересно и понимаешь, над чем надо задуматься. Итак, то что здесь рассказывает Лео Апотекер, является одним из прямых следствий закона №7, Закона лестницы: если ты занимаешь вторую позицию после лидера, лучше оставайся на ней и укрепись на ней (сам закон звучит как "стратегия зависит от ступеньки, которую вы занимаете").

И вот еще цитата без комментариев.

Э.: ИТ-директора зачастую говорят: я автоматизировал бухучет, логистику — львиную долю своих бизнес-процессов; у меня все работает как часы, зачем мне перекраивать систему всякий раз, когда талантливый продажник из SAP впаривает моему боссу очередную красочную финтифлюшку? Что бы вы на это ответили?

Л.А.: <...> Пусть ребята в отделе маркетинга полагают, что им нужны новые инструменты анализа рынка и прогноза продаж. Новые методы, новые инструменты, не такие, как в прошлом, - потому что рынок меняется. А товарищ из ИТ размышляет: зачем нам все эти новые штуки, когда мы делаем отличные деньги с теми опциями, которые я уже настроил? Зачем дергаться и усложнять себе жизнь? А я хочу спросить: быть может, он гуру в маркетинге? Знает эту сферу лучше своих коллег? Откуда это высокомерие?

И еще одна.

Э.: <...> экономисты пишут, что в некоторых случаях неформальные методы ведения бизнеса могут быть куда эффективнее, чем формальные. Подтверждают цифрами. В то же время ERP-система — это такая модель четкой регламентации, прозрачных бизнес-процессов. Что если эта модель вступает в конфликт с принятой в организации системой, а последняя даже более эффективна? <...>

Л.А.: <...> Да, компания может выстроить вокруг себя целую сеть полезных, коррупционных связей и знакомств — и капитализировать это преимущество долгое время. Но поверьте, в жизни любой взрослой организации всегда наступает момент, когда она начинает принимать рациональные решения. Быть может, вчера она еще делала что-то персонально для господина А или Б, но в конце концов решения неизбежно должны стать рациональными. Иначе ваш бизнес обречен. В такой момент компания осознает: если я могу стать прозрачной, я буду более эффективной.

Итак, оригинал статьи находится здесь.

more >>

Зачем нужны платформы Business Intelligence?

Опубликованная буквально несколько часов назад, очень хорошая статья одного из крупнейших профессионалов по Oracle Business Intelligence в России, Андрея Пивоварова, интересно и доступно отвечает на вопрос, поставленный в заголовке.

Автор на примерах из своей реальной практики показывает закономерности развития проектов по построению аналитических систем у заказчика. В поле зрения статьи попадают такие варианты решений, как самописные разработки, open source и коммерческие BI-платформы. Для каждого из вариантов автор приводит преимущества и недостатки.

Статья будет полезна и тем, кто только принимает решение, нужно ли связываться с внедрением программного обеспечения BI, и тем, кто уже стоит перед выбором конкретного продукта. Также статья будет полезна всем, кто интересуется теорией и практикой в области Business Intelligence.

Итак, статья: Зачем нужны платформы Business Intelligence?

P.S.: Кстати, там в комментариях завязалась довольно интересная дискуссия с участием, в том числе, и вашего покорного слуги :)

more >>

Английская королева и тайна частной жизни

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

Уже второй раз досрочно завершается бесплатная расдача Windows Vista и Office 2007 в рамках кампании под названием Windows Feedback Program, организованной корпорацией Microsoft, основная задача которой заключается в получении информации о том, что делают пользователи на своих компьютерах. Пользователи буквально сметают запас выделенных для мероприятия бесплатных копий продуктов, и каждый раз кампанию приходится приостанавливать раньше отведенного срока. Следует заметить, что раздаются самые топовые версии ПО, Ultimate.

Суть Windows Feedback Program в том, что пользователь соглашается регулярно отвечать на вопросы опросов, проводимых корпорацией, и установить у себя на компьютер специальную программу, которая ежедневно передает в Microsoft информацию о действиях пользователя.

Мне кажется, эта новость в мире (ну и в Рунете, соответственно, тоже) слегка обделена вниманием. Точнее, она, конечно, освещалась, но...

"Некоторым пользователям идея постоянной "отчетности" покажется неприемлемой, но, судя по всему, многим это же предложение придется по душе. Почему бы не принять предложение поучаствовать в Windows Feedback Program, и получить бесплатно то, что в розницу стоит почти тысячу долларов, и на вполне законном основании?"

- такого рода благодушные реплики завершают большинство новостных сообщений.

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

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

Перед участием в программе вы должны предоставить свое имя, пол, e-mail и почтовый адрес. Затем данными (заметьте, не обезличенными, как часто декларируют в различных privacy policy, а четко привязанными к личности участника!), которыми вы должны щедро поделиться, Microsoft и любой из его филиалов могут пользоваться любым необходимым им образом.

Для Microsoft - это коммерческое исследовательское мероприятие. А для нас, - по сути, социальный эксперимент. Что же полезного говорят нам его результаты? Позвольте, вместо ответа процитировать один старый театральный анекдот.

Говорят, однажды Бернард Шоу выразил мнение, что все женщины продажны, вопрос только в цене. Случайно узнав об этом, английская королева, решила урезонить Шоу, и при встрече с ним спросила:

- До меня дошли слухи, будто вы, сэр, утверждаете, что все женщины продажны. Это действительно так?

- Да, ваше величество, я действительно однажды так сказал.

- Что, и я - тоже продажная?! - возмутилась королева.

- И вы тоже, ваше величество, - со вздохом ответил Шоу.

- Хм, и сколько же я стою?! - начала багроветь от гнева королева.

- Десять тысяч фунтов стерлингов, - подумав, сказал Шоу.

- Что, так дешево?! - удивилась королева.

- Ну, вот видите, вы уже торгуетесь, - вышел из положения драматург.

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

Дело в том, что в результате работы, например, тех же пресловутых социальных сетей в руках компаний, ими управляющих, образуются базы данных пользовательской личной информации чудовищных объемов. Изучая такие данные, можно получать ценные статистические срезы предпочтений пользователей, проводить data mining и выявлять определенные закономерности между типами пользователей и их поведением (- вот где Business Intelligence ;)). Владение такой информацией - сильное конкурентное преимущество. А имея возможность идентифицировать пользователя, можно сильно увеличить эффективность бизнеса, адресно продвигая свои продукты. Поэтому такие базы данных - весьма лакомый кусок для всех, кто так или иначе строит свой бизнес на потребителях.

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

А что это, скажите мне, как не еще один вариант монетизации своего успешного стартапа, набравшего приличное количество пользователей? Или еще один источник очень неплохого дохода для тех, кто уже в игре? Я считаю, что пути обратно нет. Прогрессивное сообщество первое время будет смотреть криво и плеваться, но этот процесс неизбежен. Приватные данные станут обычным товаром, а privacy policy похудеют, если не исчезут вообще. Появится понятие privacy layer. Каждый сможет продать свой первый privacy layer дешево, второй - подороже, продать третий - значит продаться с потрохами. Это как торговля органами. Дьявол уже здесь! Вы собираетесь вступить в игру, пока еще не поздно? Хотите получить дивиденды от этого нарождающегося вида бизнеса? Я - да, и я уже работаю в этом направлении.

Кстати, список источников таких огромных баз данных личной информации можно продолжить: это и интернет-магазины, через которые проходит существенное количество заказов, и сайты подписных информационных рассылок, и вообще, любые интернет-сервисы, даже сайты платежных систем. Так что, не удивляйтесь, если в один прекрасный день вы получите e-mail с предложением согласиться на изменение нескольких пунктов Privacy Policy в обмен на какой-нибудь бонус. От которого будет трудно отказаться...

Дьявол уже здесь!

more >>