Знакомьтесь, это - 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 >>