Зачем посылать SAP

Проект Покупедия.ру жив и здоров, однако в изменившихся условиях его таймлайн претерпел некоторые изменения. Появились новые этапы, и проект, по видимому, даст одно или более ответвлений, благо технологическое ядро может быть использовано многими способами. Сейчас, когда прошел долгий период сложной, но увлекательной работы, несмотря на то, что нужно еще очень много сделать, хочется перевести дух. Как раз в такие моменты оглядываешься назад и осознаешь многие вещи. Череда флешбэков встает перед глазами и ответы на вопросы, которые много раз задавал себе сам, кристаллизуются в голове. Почему SAP-консультант бросил SAP? И что он забыл в обработке изображений? Что ж, ответы не на два слова.

Работать я начал, как и многие в наше время, еще на старших курсах, пробуя себя то в web-программировании, то в области СУБД, то пописывая различные утилиты и системки. В то время всё для меня было новым и интересным, хотелось узнать побольше технологий, результаты своей деятельности приносили много радости. Часто, увлекаясь работой, я задерживался в офисе и вполне мог понять людей, которые приходили поработать в выходные. Но постепенно щенячий энтузиазм уступал место здоровому прагматизму и под его давлением я стал принимать «стратегические» решения.

Первое такое решение - прекратить быть «тупым кодировщиком» и начать заниматься «взрослыми вещами». Под «взрослыми вещами» я тогда понимал «большие» системы, иными словами КИС. «Программизм», как я считал, - занятие для «мальчиков», т.е. студентов и прочих социально неустроенных личностей. К числу последних я с сочувствием относил и множество виденных мной программистов, не способных объясниться с заказчиком без злоупотребления профессиональными жаргонизмами и совершенно не понимающих прикладной специфики. Особенно впечатляли меня не самые молодые из них: они оставляли у меня ощущение великовозрастных детей или засидевшихся девок.

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

После некоторой борьбы с неподатливой судьбой, мне таки удалось нагнуть строптивую и претворить в жизнь свое первое «стратегическое» решение, на 90 градусов изменившее курс моей вяло дрейфующей карьеры. Но, как это часто бывает в жизни, по прошествии времени сияющий Грааль оказался невзрачной грудой глиняных черепков. Работа в области КИС оказалась довольно грязным и склочным дельцем. Несмотря на то, что мне лично пришлось заниматься, дай Бог, чтобы половиной вещей из моих мечтаний, весь процесс изнутри мне стал отчетливо виден. Я был консультантом, но понял, что работать методологом, аналитиком и даже самым-самым раз-начальником не сильно лучше. Не буду здесь расписывать подробно, какой это забавный бизнес, многие и так знают. А кто не знает и кому интересно узнать, то, как говорится, пишите в личку.

Ну, раз уж не суждено было видеть интересную работу и улыбки заказчиков, я принял еще одно «стратегическое» решение. Менять всё снова на 90 градусов и полностью уходить из области казалось глупым, поэтому я постановил, что буду просто зарабатывать деньги - чем больше, тем лучше. Как я теперь понимаю, это была моя серьезнейшая ошибка. Таким образом я лишь законсервировал нарождающийся внутри себя психологический кризис, который по прошествии некоторого времени набрал полную силу и принес мне немало моральных мучений. Тогда же казалось, что продолжить существование, проведя дихотомию «работа-неработа» - всего лишь дело техники.

Итак, «подымать бабло» я решил в области SAP. Я понимал, что SAP - это волшебная кормушка, единожды попав в которую, будешь обеспечен всю оставшуюся жизнь. Но на тот момент я являлся вполне сформировавшимся специалистом по совершенно другим системам, поэтому мне пришлось провести очередной раунд интенсивной борьбы с судьбой. Мой состав уже вовсю катился не по тем рельсам, но мне снова удалось вырулить на нужную колею.

Далее пошли, как это бывает с SAP-консультантами, внедрения, поездки в Сибирь, поддержки, документации и презентации. Через некоторое время до меня стало доходить, что, продолжая так работать, я начну морально и личностно деградировать, если уже не начал. Я понял, что когда проходит новизна освоения неизвестной системы, когда позади все обучения и первые запуски, ты становишься, по существу, дрессированной обезьянкой для внедрения. Из раза в раз ты применяешь свой минимально растущий опыт. Для компании ты - фактически commodity, основное средство с определенной ежемесячной стоимостью владения, черный ящик для генерации прибыли. И компании абсолютно пофигу, если ты хочешь полностью реализовать свой потенциал или заниматься интересными задачами. Позднее мой будущий босс Смелянский Руслан Леонидович скажет: «Как это ни цинично звучит, бизнес не заинтересован в развитии личности. Он заинтересован в ее эффективной отдаче.» И это осталось бы верным, даже если бы я ушел в совершенно другую организацию заниматься совершенно другими вещами.

Я начал пытаться параллельно к основной работе создавать свои собственные проекты. Сначала они были довольно наивными, затем становились более серьезными. И тем более сложно их стало совмещать с работой. Кто бывал в такой ситуации - тот знает. Конечно, в основном, мои проекты больше приносили интерес, чем приличные деньги. Основная работа постепенно становилось совсем невмоготу. Каждое утро и каждый вечер я мужественно преодолевал под землей почти всю Москву наискосок, придавленный мрачными мыслями о том, что, ё-моё, сколько ж времени пропадает зазря и что мне уже почти 30 лет, а своё место в жизни так и не найдено. Свой моральный кризис я уже вполне осознавал, но бросить всё в одночасье было невозможно, требовалась подготовка.

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

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

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

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

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

- Меня всегда интересовал вопрос: вот, допустим некоторые учатся, скажем, на физика, и идут работать программистом. Или еще лучше, учатся на геологическом, а заканчивают менеджером по продажам. Куда идут полученные знания? В канализацию? Мне могут ответить, что вуз, прежде всего, учит учиться, получать информацию, общаться и выполнять работу. Ну, хорошо, но все же, целый пласт специальных знаний - он же практически пятидесяти процентам из нас так и не пригодился в работе. Вам не жалко целых пять лет жизни? Мне - жалко, тем более, что образование я получил одно из самых лучших - ВМиК МГУ. Почти всегда главной целью обучения в вузе являлась казенная корочка под названием диплом. В данном же случае, «богатство, которое всегда с тобой» имеет шанс действительно стать твоим сильнейшим конкурентным преимуществом.

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

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

Совсем ли я распрощался с SAP-ом? Я надеюсь, да. Ну, разве что, если нужда припрет - тут уж ничего не поделаешь. А так, думаю, что да. Да и примерно то же я думаю про любую наемную работу.

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

И кто знает, может, я, все-таки, защищу кандидатскую? Уже в области обработки изображений :)
more >>

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 >>

Басня об "одном флаконе"

Здесь я хочу поговорить о культуре программирования на SAP-проектах. Изначально я планировал включить этот кусок в качестве небольшого лирического отступления к одному из своих ПОЧЕМУ (см. вступление к одному из первых моих постов). Но, как водится, сказать нашлось много чего.

Итак, на заре своей SAP-карьеры, но уже имея некоторый опыт работы, я пытался устроиться в одну уважаемую западную компанию на должность консультанта по SAP SEM. На интервью я шел с радужными мыслями. Ведь, я собирался поменять область деятельности. Прощайте, годы программирования и копания в технических настройках! Я хотел стать функциональным консультантом по SAP SEM. Своими представлениями я заранее поделился с рекрутером, который отправлял меня на то интервью. Он меня похвалил за четкое позиционирование и сообщил, что это как раз то, что нужно его клиенту. Концептуальное проектирование системы, интервью и консультирование заказчиков, применение и изучение методик стратегического управления предприятием - вот, что меня ждало, и я этого хотел! Передо мной открывались новые горизонты, интересные дела. Внутри бродил тревожный, но приятный холодок неизвестности. Я думал: "Уж в западных конторах-то знают, как правильно внедряются системы. У них там и методологии, и разделение обязанностей, и ваще все по уму". На то, как внедряется SAP, да и, вообще, любая система российскими интеграторами, я уже насмотрелся...

Меня собеседовал какой-то начальник отдела. В какой-то момент он спросил: "А приходилось ли вам писать на ABAP-е?". Я сказал, что нет. Он поцокал языком и сообщил: "Вообще-то, без ABAP консультанту в SAP-е никуда. Стандартного функционала настолько часто не хватает, что практически в любом месте приходится хоть две строчки, но написать. А нередко и отнюдь не две." Во мне зародилось смутное подозрение, что эту работу я не получу. Потом он начал мучать меня вопросами вроде "а как нам сделать так, чтобы если в продуктив BW придет пакет лишь с парой ошибочных записей, то не надо было бы удалять и перегружать все, ведь инициализация дельты может проходить сутки?". Мне приходилось мычать или пытаться выжать из своих обширных обще-IT-шных и скудных BW-шных знаний хоть что-нибудь, что напоминает ответ. Я понял, что работу точно не получу. Но заодно и понял и другое.

Понял, что моему идеализму нет места на российском рынке специалистов по SAP Business Intelligence (это сейчас этот термин активно используется, а тогда говорили просто SAP SEM или SAP BW/SEM). Ситуация в России и тогда, и сейчас сродни вообще ситуации с любой профессией в сфере IT: нужно все и сразу, и в одном флаконе. И не важно, какая порода у конторы-интегратора: российская или западная.

Сейчас, умея ABAP-ить, и зная почти все о BW, я, скорее, соглашусь с тем начальником, но соглашусь лишь отчасти. На то место наверняка взяли BW-шника с опытом в ABAP-е. Может, он был грамотный программист, но это вряд ли. Среди "модульных" консультантов SAP я еще не видел ни одного, кто хотя бы сносно пишет на ABAP-е. Да и, вообще, на каком-нибудь языке. Основной принцип: лишь бы работало. Господа, чем ТАК писать, лучше не писать вообще! И, уважаемые работодатели, не гонитесь за тем пресловутым "одним флаконом": лучше наймите немного больше ABAP-еров и дайте им посидеть со вступительным курсом по нужному модулю. Или, хотя бы, потрудитесь проверить, как справляется "модульный" консультант с ABAP-ом, прежде, чем он начнет "колбасить" на проекте.

Практически только у профильных программистов на SAP-проектах получается качественный код. У консультантов же на входе:

• Дурной стиль кода. Например, не видел, чтобы кто-то задумывался о системном применении отступов и регистра символов, и в идентификаторах, и в ключевых словах. Тут еще употребление переносов строк, комментарии, логическое разбиение на блоки операторов и многое-многое другое. Ну, кто знает, что такое плохой стиль, - тому объяснять не надо.
• Запутанная, неочевидная логика. Усугубляется тем, что плох стиль, но это не главная причина. В стремлении к тому, чтобы "лишь бы заработало", консультант по многу раз вносит небольшие правки и пробует кусок кода, а когда он, наконец, заработал, бросает как есть, вместо того, чтобы "причесать" его.
• Бездумный Copy-Paste. Консультанту проще скопировать кусок кода откуда-нибудь еще и "подкрутить" его, чем разобраться, как он работает и понять, что из него, например, нужна только одна строчка. Или он весь, вообще, не нужен.
• "Hard-coded" подход. Например, использование выборки напрямую из таблицы через оператор SELECT, а не использование специализированного гибкого функционального модуля или класса, разработанного SAP.
• Просто неоптимальный код. Консультант не есть профессиональный ABAP-ер, поэтому просто не может знать, как проще, быстрее и эффективнее реализовать ту или иную задачу. Или делается так, что вызывается один и тот же код по многу раз, хотя достаточно и одного, но вначале. В результате, получаются хромые и кривые ABAP-убожества.
• Отсутствие обработки особых ситуаций. Хороший программист всегда учитывает, что на вход куску кода могут попасть самые различные данные или внутри него могут возникнуть ошибки. Консультант почти никогда не думает об этом. "Лишь бы работало!"

На выходе:

• Кирпич в себе. Представление о том, что делает этот нечитабельный код имеет только тот, кто его писал, да и то через некоторое время это будет весьма не факт. Чтобы модифицировать такой негибкий код, нужно прилагать чудовищные усилия, если не переписывать полностью под новые требования. Заказчик получает вещь в себе, монолитный немодифицируемый кирпич.
• Тормоза. Неоптимальный, раздутый, да мало ли еще какой может быть плохой код. А заказчик страдает, ожидая построения отчета по 20 минут или завершения обработки по несколько часов. Его, конечно, успокоят: "Ничего, все в порядке. SAP - прожорливая система. Поставьте еще один сервер, добавьте памяти, и будет вам щастье".
• Ползучие ошибки. Консультанты попробовали на паре (ну хорошо, не на паре - на тысяче, код-то неправильный!) записей - ура, все работает! Работу сдали, а потом медленно начнут проявляться "непонятные" ошибки. То на каком-то материале отчет "валится в дамп", то почему-то зависает Java-часть, то просто результаты не верные. А заказчик либо столкнется с простоем системы, либо внедрение просто затянется.

Поверьте, как правило, при той загрузке и темпах работы, что имеет "модульный" консультант, у него в голове остается очень немного места, чтобы еще при этом и хорошо программировать. И даже можно не уточнять, SAP это или не SAP. То, что я сказал выше, вполне можно приложить и к любой корпоративной информационной системе, которая внедряется в России. Лично я был свидетелем этого в той же Axapta, пардон, Microsoft Dynamics AX.

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

Забудьте про "флаконы", не умножайте зло для заказчиков, не плодите проблемы для своих же внедрений. Пора пользоваться услугами профессиональных консультантов и профессиональных программистов!

А пока мы имеет то, что я еще неоднократно буду ссылаться на этот пост в своих последующих ПОЧЕМУ :)

more >>

Знакомьтесь, это - SAP BW, OLTP-система (проект РЖД №1: ЧТО)

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

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

На данный момент, у меня в голове находится концепция серии заметок, когда каждая из них будет отвечать на один из вопросов "ЧТО автоматизировалось", "КАК шло внедрение", "ПОЧЕМУ оно так шло" и "как было БЫ, если бы внедрение шло по-другому".

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

Итак, к первому ЧТО.

Задачка такая. РЖД. Вагоны регулярно отправляются в рейсы. Есть некий набор станций, на которых происходит передача вагонов от одной организации к другой. При передаче для каждого вагона составляется документ, в котором фиксируется номер вагона, а также дата и время его передачи. Каждая организация, и сдающая, и принимающая, составляет свой такой документ. В целом, организаций в процесс вовлечено много, и вагон в каждом рейсе может несколько раз передаваться между ними. А потом возникает вопрос, кто сколько должен РЖД за пользование вагоном. Плата рассчитывается на основе времени пробега. В установленные сроки все организации отсылают свои документы за прошедший отчетный период (месяц) в одно из расчетных подразделений РЖД, где и производится начисление. Технически документы организации за один отчетный период попадают в РЖД в электронном виде, грубо говоря, как массив данных вида вагон-период-дата-время.

В целом, все понятно. Есть рейс вагона. Вагон несколько раз сдают-принимают. Все непрерывные сегменты пути тарифицируются, а далее выставляются счета поучаствовавшим организациям. Если на одной и той же станции найдено несоответствие в временах сдачи и приема (а такое бывает часто: одна организация считает, что передача вагона произошла в одно время, а другая - что в другое), то есть правила, кому предъявлять претензии и как урегулировать разногласия.

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

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

Что же хотел заказчик от автоматизации? До внедрения несколько целых подразделений занимались перелопачиванием поистине гигантских объемов информации. За каждым компьютером сидел человек с двумя окнами Microsoft® Excel, в каждом из которых было открыто по массиву данных, и глазами искал "несходки". Иногда надо свериться с распечаткой, иногда - залезть в специализированную информационную систему РЖД. Хотелось, чтобы была создана система, умеющая формировать отчеты, в которые бы попадали "подозрительные" вагоны. Далее бы пользователи их бегло проверяли, возможно, удаляли бы из них "несправедливо оклеветанные" вагоны, и отправляли ли бы список прямиком виноватой организации. Те, в свою очередь, должны либо согласиться с претензиями (акцептовать), либо обосновать отказ от претензий, либо предложить свой вариант правды.

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

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

Читайте продолжение в следующем посте. Там я расскажу КАК было проведено внедрение.

more >>

Да, я знаю про Business Intelligence в SAP (SAP BI) больше других :)

Этот пост впервые появился на Хабре. Но, видя, как падает моя Карма на этом ресурсе, я решил переехать сюда. Все, что я думаю по этому поводу, я написал там же.

Проработав в компании REDLAB LTD. почти 2 года, я имел возможность ознакомиться с различными, доселе неведомыми мне, видами бизнеса. Я думал, что будучи уже более 6 лет консультантом в области Business Intelligence со специализацией в продуктах SAP, уж точно умею автоматизировать процессы стратегического управления на предприятиях нефтянки, розничной торговли, масс-медиа и т.д., и вроде бы, учиться уже нечему. Я ошибался :) Специфика в отраслях, в которых мне довелось поработать, есть, и существенная.

Итак, эти отрасли - железные дороги и ВУЗы :)

Но подозреваю, что многие могли подвизаться на ниве РАО РЖД, ибо его культивирует целый пласт интеграторов. Внутри этого пласта получилось, что затерялся и РЕДЛАБ. Точнее, меня и еще других консультантов от РЕДЛАБ взяла в субподряд компания Микротест, а та была субподрядчиком у компании Техносерв. За разработку протоколов взаимодействия отвечал ВНИИЖТ. В некоторых задачах участвовала наша талантливая компания ABBYY. Ну, в общем... Понамешано было прилично. Не думаю, что вся эта информация нарушает какие-либо подписаные договоры или существующие законы, я ничего не подписывал, проинформирован не был, так что пишу об этом без опаски. Кстати, я возможно, неверно истолковал всю иерархию взимодействия в этом клубке суб- и ген- подрядов, но у меня есть информация, которую еще есть время обработать, и я собираюсь опубликовать свои изыскания в ближайшее время.

Так что, в моих следующих постах ждите информации о том, как в данный момент живут подразделения РЖД и какие проблемы у них животрепещут. Как "решались" их проблемы с помощью автоматизации и что должно было быть сделано на самом деле, без "реверансов" между подрядчиками; что действительно экономило бы средства этого большого и всем нам знакомого заказчика, а что имело роль припарки мертвому.

А позже я расскажу о том, как внедряется SAP в ВУЗах. Здесь, наверно, компетенции не наработал почти никто...

Ждите новых сообщений :)

more >>