CC BY
41
РАЗРАБОТКА СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ КАК ИНФОРМАЦИОННОЙ МАРКЕТИНГОВОЙ СИСТЕМЫ
M.I. РВМДВВВД, вавдвдат эваввшчвсвн iagi, дввтвр Гасддарствввввга ¡вавврнтета двравдевн (Москва)
В той или иной степени системы поддержки принятия решений (СППР) присутствуют в любой информационной системе (ИС). Поэтому, осознанно или нет, к задаче создания СППР организации приступают сразу после приобретения вычислительной техники и установки программного обеспечения. По мере развития бизнеса, упорядочения структуры организации и налаживания межкорпоративных связей, проблема разработки и внедрения СППР становится особенно актуальной. Основным подходом к созданию таких систем стало использование хранилищ данных.
В настоящей статье рассматриваются этапы и методики проведения подобных работ на опыте и с применением методологии компании Price Waterhouse, которая на сегодня выполнила 40 крупномасштабных проектов по созданию корпоративных хранилищ данных (ХД) [1].
СППР можно, в зависимости от данных, с которыми они работают, разделить на оперативные, предназначенные для немедленного реагирования на текущую ситуацию, и стратегические -основанные на анализе большого количества информации из разных источников с привлечением сведений, содержащихся в системах, аккумулирующих опыт решения проблем.
СППР первого типа получили название информационных систем руководства (Executive Information Systems, ИСР). По сути, они представляют собой конечные наборы отчетов, построенные на основании данных из транзакционной информационной системы предприятия или OLTP-системы, в идеале адекватно отражающей в режиме реального времени все аспекты производственного цикла предприятия. Для ИСР характерны следующие основные черты: • отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико;
• представляются отчеты в максимально удобном виде, включающем, наряду с таблицами, деловую графику, мультимедийные возможности и т.п.;
• как правило, ориентированы на конкретный вертикальный рынок, например финансы, маркетинг, управление ресурсами.
СППР второго типа предполагают достаточно глубокую проработку данных, специально преобразованных так, чтобы их было удобно использовать в ходе процесса принятия решений. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, которые на основе агрегированных данных подсказывают менеджерскому составу выводы и придают системе черты искусственного интеллекта. Такого рода системы создаются только в том случае, если структура бизнеса уже достаточно определена и имеются основания для обобщения и анализа не только данных, но и процессов их обработки. Если ИСР есть не что иное как развитие системы оперативного управления производственными процессами, то СППР в современном понимании - это механизм развития бизнеса, который включает в себя некоторую часть управляющей информационной системы, обширную систему внешних связей предприятия, а также технологические и маркетинговые процессы развития производства.
зарождение концепции хранилища данных
Ясно, что чем больше информации вовлечено в процесс принятия решений, тем более обоснованное решение может быть принято. Информация, на основе которой принимается решение, должна быть достоверной, полной, непротиворечивой и адекватной. Поэтому при проектировании СППР возникает вопрос о том, на основе каких
BBianiiiifluia мштвченвВ ним дд1дкст мвдвсы
17
данных эти системы будут работать. В ИСР качество оперативных решений обеспечивается тем, что данные выбираются непосредственно из информационной системы управления предприятием (или из базы данных (БД) предприятия), которая адекватно отражает состояние бизнеса на данный момент времени. Ранние версии СППР второго типа в качестве исходных использовали относительно небольшой объем агрегированных данных, поддающихся проверке на достоверность, полноту, непротиворечивость и адекватность.
По мере роста и развития ИСР, а также совершенствования алгоритмов принятия решений на основе агрегированных данных, системы принятия решений столкнулись с проблемами, вызванными необходимостью обеспечить растущие потребности бизнеса. В ИСР накопился объем данных, замедляющий процесс построения отчетов настолько, что менеджерский состав не успевал готовить на их основе соответствующие решения. Кроме того, с развитием межкорпоративных связей потребовалось вовлекать в процесс анализа данные из внешних источников, не связанных напрямую с производственными процессами и потому не входящих в систему управления предприятием.
В СППР второго типа традиционная технология подготовки интегрированной информации на основе запросов и отчетов стала неэффективной из-за резкого увеличения количества и разнообразия исходных данных. Это стало сильно задерживать менеджмент, для которого требовалось быстро принимать решения. Кроме того, постепенное накопление в БД предприятия данных для принятия решений и последующий их анализ стали отрицательно сказываться на оперативной работе с данными.
Решение было найдено и сформулировано в виде концепции хранилища данных (Data Warehouse, ХД), которое выполняло бы функции предварительной подготовки и хранения данных для СППР на основе информации из системы управления предприятием (или БД предприятия), а также информации из сторонних источников, которые в достаточном количестве стали доступны на рынке информации [2].
Этот подход потребовал новых технологических решений, к созданию которых несколько лет назад приступили основные производители промышленных систем управления базы данных (СУБД) и разработчики систем анализа данных. Сегодня накоплен обширный опыт разработки и внедрения специализированных структур данных и создания СППР на основе СУБД разных типов. Известна и технология создания больших хранилищ, как правило, на основе реляционных СУБД.
Ограниченный объем статьи не позволил рассмотреть все аспекты технологии ХД, поэтому
II
некоторые вопросы затронуты здесь только вскользь, а отдельные проблемы (например, взаимодействие СППР с Internet) не обсуждаются вовсе. Мы постарались сосредоточиться на ключевых этапах разработки ХД, чтобы охарактеризовать процесс разработки ХД в целом.
ТЕХНОЛОГИЯ РАЗРАБОТКИ И ВНЕДРЕНИЯ ХРАНИЛИЩА ДАННЫХ
Этапы проекта
Первой фазой проекта разработки ХД является бизнес-анализ процессов и данных предприятия. В России, несмотря на широкое распространение CASE-технологии, к бизнес-анализу и проектированию данных на концептуальном уровне не всегда относятся достаточно серьезно. Между тем относительно СППР на основе ХД можно с уверенностью утверждать, что ее разработка без подобного анализа заранее обречена на неудачу. Без ясного понимания разработчиками целей бизнеса, способов их достижения, возникающих при этом проблем и методов их решения, ресурсы, необходимые для разработки ХД, будут потрачены зря. Самым критичным из ресурсов сейчас является время, и тот, кто начал разработку СППР, не определив заранее, кто, когда, зачем и как будет принимать решения, какое влияние то или иное решение оказывает на бизнес, какие решения отнести к оперативным, а какие к стратегическим и т.д., обрекает себя на неизбежное отставание в конкурентной борьбе.
Основное назначение модели предприятия -определение и формализация данных, действительно необходимых в процессе принятия решения. Известно два подхода к бизнес-анализу. Первый ориентируется на описание бизнес-процессов, протекающих на предприятии, которое моделируется набором взаимосвязанных функциональных элементов. Поскольку эти процессы, как правило, хорошо известны, на первый взгляд кажется, что это самый естественный и быстрый путь бизнес-анализа. Действительно, если бизнес стабилен и внешние факторы не играют в нем решающей роли либо также стабильны, этот путь может оказаться наиболее эффективным. Второй подход основан на первичном анализе бизнес-событий. При проектировании СППР на основе ХД именно он обеспечивает наибольшую эффективность:
• позволяет гибко модифицировать бизнес-про-цессы, ставя их в зависимость от бизнес-со-бытий;
• интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных;
• объединяет управляющие и информационные потоки;
1ШЖШ1Ш Ш11ЛЮС1111УШ ДА1Д1ЕСТ Ы1Д1Ш
• наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется. Иными словами, бизнес-событие является
более устойчивым и более тесно связанным с информационными и управляющими потоками понятием, чем бизнес-процесс.
Через анализ биЬнес-событий необходимо перейти к анализу данных, используемых предприятием. При этом должна быть собрана информация об используемых внешних данных и их источниках; о форматах данных, периодичности и форме их поступления; о внутренних информационных системах предприятия, их функциях и алгоритмах обработки данных, используемых при наступлении бизнес-событий. Такой анализ, как правило, производится при проектировании любой информационной системы. Особенность анализа данных при проектировании СППР на основе ХД состоит в необходимости создания моделей представления информации. То, что в транзакци-онных системах является вторичным понятием, а именно состав и форма отображаемых данных, в СППР приобретает особую важность, так как нужно выявить все без исключения признаки, требуемые для менеджерского состава.
Модель представления данных является организационно-функциональным срезом модели системы, а при ее разработке последовательно изучаются:
• распределение пользователей системы: географическое, организационное, функциональное;
• доступ к данным: объем данных, необходимый для анализа, уровень агрегированности данных, источники данных (внешние или внутренние), описание информации, совместно используемой различными функциональными группами предприятия;
• аналитические характеристики системы: измерения данных, основные отчеты, последовательность преобразования аналитической информации, степень предопределенности анализа, существующие или находящиеся в стадии разработки средства анализа.
При проектировании транзакционной системы обычно строго выдерживается последовательность процессов: бизнес-анализ, концептуальная модель данных, физическая модель данных, структура интерфейса и т. п. Возврат на предыдущий уровень происходит редко и считается отклонением от нормального хода выполнения проекта. В случае СППР на основе ХД нормальным считается итерационный, а иногда и параллельный, характер моделирования, при котором возврат на предыдущую стадию - обычное явление. Это связано с необходимостью выделения всех требуемых данных для произвольных запросов (ad-hoc), для чего следует составить исчерпывающий пере-
чень необходимых данных и построить схему их связей через бизнес-события. При этом из общего массива выделяется значимая информация и выясняется потребность в дополнительных источниках данных для принятия решений.
В ходе анализа бизнес-событий необходимо также сформировать схему взаимодействия между транзакционной и аналитической системами на предприятии. Помимо того, что транзакционная система зачастую является важнейшим источником данных для хранилища, желательно задействовать один и тот же пользовательский интерфейс в ИСР и СППР. Подходы к совместному использованию этих систем определяются именно на данной фазе выполнения проекта.
Итак, по результатам анализа бизнес-процессов и структур данных предприятия отбирается действительно значимая для бизнеса информация с учетом неопределенности будущих запросов. Следующий шаг связан с пониманием того, в каком виде и на каких аппаратных и программных платформах размещать структуру данных СППР на основе ХД.
Историю OLAP в России следует, наверное, отсчитывать с 1996 года, когда несколько компаний начали заметно продвигать OLAP-продукты. К этому времени относится и разработка первых известных российских OLAP-приложений. Если судить по сайтам компьютерных компаний с описаниями OLAP-продуктов, то в настоящее время OLAP в России и странах СНГ продвигают несколько десятков компаний. Если же принять во внимание другие проявления активности по продвижению OLAP, то придется говорить о гораздо более узком круге компаний.
Компания «Терн» (http://www.tern.ru/) не только продает комплект BusinessObjects компании Business Objects, она успешно использует его при выполнении заказных проектов. OLAP-продукты компаний Cognos и CA/Platinum продвигает фирма Aigussoft (http://www.aigussoft.ru/). OLAP-продукты от Oracle, Microsoft и Seagate Software распространяет компания Interface (http://www.interface.ru/). которая регулярно проводит семинары по тематике OLAP и СППР. Финансовые приложения и OLAP-сервер корпорации Hyperion, а также приложения собственной разработки предлагает компания Ланит (http://www.lanit.ru/). Поставщики основных реляционных СУБД архитектуры клиент-сервер и их партнеры также действуют с разной степенью активности на российском рынке OLAP. Крупным организациям предлагает свои сложные и дорогие продукты, в том числе и OLAP-продукты, компания SAS Institute [3].
Что сдерживает развитие российского рынка OLAP? Можно указать ряд причин, обусловленных как действиями поставщиков и распространителей, так и отношением потенциальных пользователей.
IltlFMWim МШТ1ЧЕС111 КУША М1Д1ЕСТ мшш
II
С одной стороны, что касается поставщиков и распространители OLAP-продуктов, многие из них ведут работу с выделенными по каким-то критериям (или сложившимися стихийно) узкими кругами организаций. Например, Oracle СНГ и ее партнеры, похоже, наиболее активно продвигает OLAP в России, но это продвижение происходит в рамках продвижения всех продуктов Oracle и покупают Oracle Express в основном пользователи СУБД ORACLE. А ведь OLTP-подсистемы информационных систем множества российских предприятий, в том числе и весьма крупных, основаны на файл-серверной технологии (или простейшем варианте технологии клиент-сервер на основе Btrieve) и нет оснований ожидать от них в обозримом будущем массового перехода на технологию клиент-сер-вер (корпорация «Галактика* опубликовала результаты продаж своей одноименной системы, позиционируемой как система автоматизации средних и крупных предприятий, в 1999 году. Продажи по платформам СУБД распределились так: Oracle - 16%, Microsoft - 7%, Btrieve - 77%(!)). Эти организации могли бы использовать MOLAP-продукты, такие как Oracle Express, или OLAP-приложения на основе MOLAP-продуктов [4].
В целом же создается впечатление о пассивности большинства поставщиков и распространителей OLAP в России, что проявляется в проблемах с русификацией продуктов и документации, технической поддержкой, отсутствием активного маркетинга.
С другой стороны, в отношении потенциальных пользователей к OLAP-технологии можно отметить несколько моментов, препятствующих ее восприятию. В потоке переводных западных публикаций OLAP рассматривается почти всегда в контексте тематики хранилищ данных, больших и сверхбольших баз данных OLTP (десятки и сотни гигабайт данных), информация которых, перекачанная в хранилище (витрины) данных, и должна анализироваться средствами OLAP. Базы данных OLTP, с которыми имеют дело российские специалисты, как правило, намного меньше - большими у нас называют базы данных, содержащие несколько гигабайт данных, а то и несколько сот мегабайт. А это приводит к тому, что специалисты российских предприятий часто воспринимают OLAP как нечто, не имеющее к ним в настоящее время отношения. И не только они. Сотрудники московского офиса одной крупной западной компании, выпускающей ряд программных продуктов, на вопрос, почему они не уделяют внимания продвижению своего OLAP-продук-та, отвечали: «Но ведь OLAP нужен для баз данных размером под 80 и более гигабайт. А таких баз в России единицы». (Справедливости ради должен отметить, что этот разговор состоялся два года назад. Но активность этой компании в продвиже-
нии своего OLAP-продукта за это время не изменилась.) [5].
И так, OLAP успешно применяется для анализа баз данных размером в десятки мегабайт (нужно уточнить, это размер баз данных OLAP, то есть размер исходных баз данных OLTP в 2 - 10 больше - не все данные OLTP нужны для анализа; здесь имеется в виду размер содержательных данных). В 1997 году Международная группа пользователей Oracle провела опрос пользователей Oracle Express, результаты которого были опубликованы на http://www.ioug.org/. Согласно этому опросу, размеры используемых баз данных варьируют в диапазоне от 10 мегабайт до 4 гигабайт, среднее значение от 100 до 350 мегабайт. Эти данные позволяют сделать вывод, что круг российских организаций - потенциальных пользователей OLAP - очень широк (а ведь многие организации, отработав с данными OLTP, архивируют их, не имея ясных планов по их использованию).
Еще один и, пожалуй, более важный момент заключается в убеждении, также вынесенном из западных публикаций, что аналитика начинается тогда, когда автоматизированы основные бизнес-процессы и информационная система организации построена как совокупность интегрированных подсистем, включая хранилище (витрины) данных. На многих же российских предприятиях царит «островковая» автоматизация, то есть информационная система - это «зоопарк» из слабосвязанных и (или) изолированных разнородных (по используемым средствам) подсистем, задач, баз данных и т.д. Но российские разработчики успешно использовали OLAP и в таких условиях (в этом случае особенно необходимы OLAP-продукты, реализующие HOLAP), идя от конкретных задач. На Украине фирма UBS (http://www.ubs-solutions.com/) внедряет в одной организации почти полный набор модулей Oracle Applications, причем в первую очередь модули аналитики, используя накопленные данные и не ожидая полного перестроения информационной системы заказчика в результате внедрения других модулей.
Некоторые специалисты высказывают мнение, что основным препятствием для использования OLAP являются даже не те проблемы, относящиеся к специалистам информационной технологии (ИТ) и компьютерному бизнесу, о которых идет речь в этой статье, а незаинтересованность конечных пользователей в аналитике. Это действительно проблема, и, очевидно, единственный путь ее решения - просвещение этих пользователей. Но, что внушает оптимизм, приводимые примеры такой незаинтересованности относятся почти исключительно к высшему составу военнослужащих и чиновникам государственных учреждений. А вообще-то замечено, что в отраслях, где выше уровень конкуренции, аналитика воспринимается охотнее.
21
HilFMUim МШПЧЕСМ ГОШ ДйЦЦЕСТ ММ1Ш
Результаты 10 лидеров мирового рынка OLAP в 2002 и 2003 гг. [6]
Поставщик 2003 г. 2002 г.
Место Доля (%) Место Доля (%)
Hyperion Solutions 1 28,4 1 34,0
Oracle 2 11,4 2 17,0
Cognos 3 11,1 3 9,6
MicroStrategy 4 7,9 4 6,5
Microsoft 5 7,6 - -
Business Objects 6 5,3 6 4,4
Comsharc 7 3,2 5 4,8
Applix 8 3,1 8 2,5
1ВМ(включая продажи DB2 OLAP Server и перепродажи Essbase) 9 3,0 9 1,9
Sterling Software 10 2,8 7 2,9
К настоящему времени в России и странах СНГ лидерами мирового рынка уже реализовано не менее 100 проектов с применением OLAP (эта минимальная оценка, скорее разработано 200 -300 проектов) (табл. 1). Отсутствие активного маркетинга OLAP проявляется, в частности, и в том, что информация об этих проектах редко публикуется. Но даже немногие известные описания проектов, общение с разработчиками О LAP-приложений позволяет сделать некоторые выводы. OLAP-продукты как инструмент разработчика значительно проще, чем СУБД архитектуры клиент-сервер. При реализации OLAP решающее значение имеет качество данных, то есть их верность, полнота, согласованность. Эта проблема подчеркивается западными пользователями OLAP-npo-дуктов, но, похоже, в России решать ее особенно трудно (как обеспечить сопоставимость ценовых данных за 90-е годы, если учет не велся в у.е.?). OLAP, как отмечалось выше, используется прежде всего в СППР руководителей и в случае успешной реализации OLAP отношение руководителей к ИТ значительно улучшается.
В последние годы аналитическая обработка данных постепенно выходит на передний план. Например, аналитические модули появились в составе пакетов финансово-производственных приложений SAP R/3, Oracle Applications и др.; почти одновременно с лидерами мирового рынка включили аналитические модули в свои системы российские фирмы «Парус», АйТи (система «Босс-Корпорация») и др. В условиях рыночной экономики качество информационной поддержки деятельности руководителей и аналитиков становится одним из факторов достижения предприятиями конкурентных преимуществ. Осуществить такую поддержку непосредственно на основе данных OLTP (On-Line Transaction Processing)-cnc-тем, автоматизирующих сбор и первичную обработку данных о деятельности предприятия, невозможно. Именно это и обусловило интерес к
системам поддержки принятия решений (СППР или DSS), которые являются основной сферой применения OLAP (On-Line Analytical Processing, оперативная аналитическая обработка, оперативный анализ данных), превращающей «руду» OLTP-систем в готовое «изделие», которое руководители и аналитики могут непосредственно использовать.
Аналитическая обработка данных, результаты которой используются конечными пользователями, в СССР ранее реализовывалась на машинах ЕС и СМ ЭВМ. Какие-либо специализированные программные средства для этого не использовались. Как правило, для реализации аналитической обработки применялись те же средства, что и для реализации оперативной обработки транзакций (OLTP) - СУБД и средства разработки приложений, а также генераторы отчетов. Разработчики информационных систем, реализуя как OLTP, так и аналитическую обработку данных, часто сталкивались со следующей проблемой: для оптимальной (в смысле минимизации используемых машинных ресурсов, трудоемкости разработки и т.д.) реализации OLTP необходима база данных одной структуры, а для оптимальной реализации аналитической обработки необходима база данных другой структуры.
Наиболее важная задача, решаемая с применением OLTP, - это ввод (с контролем) информации в базу данных (технологически, как правило, это множество коротких транзакций к базе данных), который должен быть выполнен в заданный срок. Важность решения этой задачи в рамках любой информационной системы очевидна и если разработчики принимали решение работать с единой базой данных, то выбор этот чаще всего делался в пользу той ее структуры, при которой оптимизировался ввод данных (либо выбиралась структура базы данных не оптимальная ни для ввода данных, ни для аналитической обработки, но позволяющая решать обе задачи удовлетворительно). Но нередко разработчики выбирали работу с двумя базами: ввод данных происходил в одну
пирмцимшдптай ш щЩеппшш
21
яяяшя
.... -^^ff
базу данных, затем после завершения этого процесса прошедшие все необходимые виды контроля данные переносились во вторую базу данных (в первом приближении такую базу можно назвать, используя современную терминологию, хранилищем данных), структура которой выбиралась для оптимизации последующей обработки, в том числе и аналитической. Причем необходимость во второй базе данных была тем выше, чем сложнее были запросы к данным при аналитической обработке. Эта схема - с двумя базами данных, для работы с которыми используется одна СУБД, применяется и в настоящее время. Естественным шагом в развитии схемы с двумя базами данных является использование для работы со второй базой специализированной технологии (и продуктов, которые ее реализуют). Наибольшее признание к настоящему времени в качестве такой технологии получила OLAP-технология.
Многомерная модель в OLAP является логической, она может быть реализована как базовая в СУБД \(в этом случае говорят о многомерных базах данных (МБД или MDB по англ.) и соответственно о MOLAP) или смоделирована на реляционной базе данных (в этом случае говорят о ROLAP) благодаря применению схемы типа «звезда». В центре «звезды» находится главная таблица - таблица фактов, запись которой содержит показатель и составной ключ, состоящий из первичных ключей таблиц измерений (лучей, справочных таблиц).
Первоначально мировой рынок OLAP-продук-тов развивался как рынок систем, реализующих MOLAP, но с середины 90-х годов основные поставщики реляционных СУБД архитектуры кли-ент-сервер начинают предлагать ROLAP.
OLAP-продукты, реализующие MOLAP, весьма разнообразны. Хотя статья Кодда привлекла широкое внимание к OLAP в начале 90-х годов, необходимо отметить, что первые MOLAP-систе-мы появились еще в конце 60-х годов. Ряд MOLAP-систем разрабатывался именно как О LAP-продукты, например, семейство Oracle Express, в состав которого входят сервер МБД Express Server, система анализа МБД Express Analyzer, средства разработки OLAP-приложений Express Objects и несколько утилит и готовых приложений. Эти продукты позволяют создавать сложные OLAP-при-ложения. В других продуктах OLAP реализован как опция, например, как OLAP-модуль в пакете Seagate Info, созданном на основе генератора отчетов Crystal Reports компании Seagate Software. Естественно, возникает вопрос о том, что предпочтительнее - MOLAP или ROLAP. В самом общем виде ответ звучит так - для больших (десятки гигабайт) баз данных OLAP предпочтительнее ROLAP, для баз данных меньшего размера -MOLAP. Но острота этого вопроса в последнее вре-
мя снимается благодаря развитию гибридного OLAP - HOLAP: это относится прежде всего к MOLAP-продуктам, которые получают возможность подключения к реляционным базам данных и другим источникам данных и подкачки информации из них (а это особенно важно в российских условиях, но об этом ниже). Корпорация Oracle помимо развития ROLAP в СУБД ORACLE в 1995 году приобрела семейство MOLAP-продуктов Express. Корпорации IBM и Microsoft только в недавно начали предлагать OLAP в рамках своих серверов баз данных. Подход Microsoft, пожалуй, наиболее оптимален из подходов всех поставщиков OLAP-продуктов с точки зрения реализации HOLAP. Кроме того, предложенный ею протокол доступа к данных OLE DB for OLAP становится таким же стандартом в мире OLAP, каким в мире реляционных СУБД архитектуры клиент-сервер является ODBC. От выхода Microsoft на рынок OLAP ждут многого, но пока еще рано делать выводы о его успешности.
Исходя же из рыночных способов распространения OLAP, можно выделить три класса [7J:
1) готовые тиражируемые OLAP-приложения, распространяемые либо автономно, либо в составе прикладных пакетов;
2) OLAP-приложения, создаваемые в рамках заказных проектов;
3) OLAP-продукты (сервер, средства разработки приложений) для создания OLAP-приложе-ний организацией-покупателем.
На сайте http://www.olap.ru/ проводилось голосование на тему: Что мешает распространению аналитики (и, следовательно, OLAP, DSS, DW...) в организациях России (СНГ)? Посетителям сайта предлагалось выбрать один из 8 вариантов ответа.
Всего проголосовало 230 человек, результаты приведены в табл. 2.
Очевидно, всегда будут пассивные специалисты (варианты 2,5,6) и, наверное, только конкуренция может привести к уменьшению их числа. Изменения бизнес-процессов в результате внедрения ИТ вызывают недовольство и сопротивление тех людей, которые из-за этого что-то теряют, иногда это сопротивление значительно (вариант 3). Более подробно нужно остановиться на нехватке информации для ИТ-отделов (вариант 4) и просвещения пользователей (вариант 1). Эту нехватку нужно преодолевать усилиями компьютерной и деловой прессы, а также фирм распространителей OLAP. Особенно нужна информация об опыте отечественных разработок, о приложениях, доступных на российском рынке «здесь и сейчас». И хотя в России уже реализовано несколько сот проектов по созданию OLAP-приложений, в Интернете и прессе можно найти описания не более 30 разработок и почти все они для крупных и средних организаций.
22
1И1ШЦ1Ш1ШШНЕИ11КУРШ ДЯ1Д1ЕСТ tlUini
Результаты голосования за аналитические системы в России [8]
Вариант ответа Количество проголосовавших
% человек
1 Безразличие пользователей из-за незнания 24,8 57
2 Безразличие пользователей в принципе 17,0 39
3 Противодействие владеющих информацией 7,0 16
4 Нехватка информации для ИТ-отделов 10,4 24
5 Уровень руководителей ИТ-отделов 13.5 31
6 Уровень специалистов ИТ-отделов 7,0 16
7 Пассивность фирм-распространителей OLAP 7,4 17
8 Цена ПО 13,0 30
Среди причин малой распространенности OLAP в России вопреки объективно очень высокой потребности предприятий в подобных системах можно назвать напористую и не совсем корректную рекламную активность OLTP-поставщи-ков, которые утверждают, что их системы сами по себе (без OLAP-надстройки) удовлетворяют все аналитические потребности предприятия. (В противном случае OLTP-поставщик может оказаться в невыгодном положении по сравнению с конкурентами, которые скажут, что их системы при той же цене не требуют никаких дополнительных надстроек). После такой обработки руководителя предприятия трудно убедить в необходимости приобретения дополняющих OLTP-систему компонентов.
Литература
1. Открытые системы, 2001, № 9, Львов В. Price Waterhouse.
2. www.iso.ru (компания InterSoft Lab).
3. http://expert.next.ru/.
4. www.olap.ru , опубликовано в PC Week/RE, No 25/2000 от 18 июля.
5. PC Week № 3/2001, Владимир Некрасов, технический директор Intersoft Lab.
6. http://www.olapreport.com/.
7. http://glossary .basegroup. ru.
8. www.olap.ni, опубликовано в PC Week/RE, № 29/2000, Алексей Резниченко.
imwAuiiiMJuumnECKil игмм дЩксг-ишн
23
