Системы принятия решений и Хранилища Данных

Решения, которые мы принимаем

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

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

Как же действовал до недавнего времени предприниматель, банкир, государственный служащий, одним словом, тот, кто должен принимать ответственные решения по долгу службы? Конечно, к его услугам есть база данных (БД), пополняемая по мере поступления новой информации. Конечно, есть квалифицированные специалисты, умеющие эту информацию извлекать и представлять в удобном для восприятия виде. И, разумеется, есть эксперты, умеющие эту информацию интерпретировать. Достаточно было сначала объяснить программистам, какая именно информация нужна, затем подождать, пока она будет готова, потом проконсультироваться с экспертами, и решение готово! Правда, программисты не сразу поняли, что от них требовалось, и предоставили информацию лишь с третьей попытки, да и сам руководитель только после этого увидел, что затребовал не совсем то, что действительно было нужно, да еще эксперты запросили дополнительных сведений, так что пришлось опять обращаться к программистам и так далее и тому подобное. В итоге ложка, которая, как известно, дорога к обеду, подоспела где-то ночью, между ужином и завтраком, почему и осталась неиспользованной.

Что такое Хранилище Данных?

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

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

Выход из этой ситуации был нащупан относительно недавно - в конце 80-х - начале 90-х годов. Ход рассуждений при этом был примерно такой. Несомненно, база данных как источник информации необходима. Но ведь обычная база данных обслуживает не только руководителей, принимающих решения, но и других пользователей: вводящих информацию, модифицирующих данные, исключающих данные, потерявшие актуальность и т.д. Неизбежно, возникает замедление доступа к данным из-за того, что разные транзакции приходится обрабатывать последовательно. Кроме того, было замечено, что частота запросов к БД связана с тем, насколько детальные данные требуются, а именно, чем данные более агрегированы, тем чаще они нужны. Отсюда напрашивается вывод: для ускорения доступа к данным нужна отдельная БД, работающая только в режиме чтения и хранящая агрегированные данные.

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

Чтобы сформулировать последнее требование к нашей БД, нам придется более подробно рассмотреть ситуацию с продажами, о которой шла речь выше. Что интересует руководителя или менеджера торговой компании? Вероятно, не только объем продаж за квартал (месяц, год и т.д.), но и распределение продаж по товарам и/или группам товаров. Это означает, что в базе нужно хранить агрегаты данных, суммированные не только по времени, но и по товарам/группам товаров. Аналогичные соображения можно привести и для регионов, фирм-поставщиков и многих других аспектов или измерений продаж. Принято представлять такую базу в виде многомерного куба, или гиперкуба. Фактически, это обобщение обычной таблицы, которой представляются отчеты.

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

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

Как строить Хранилище?

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

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

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

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

Будущие пользователи предоставляют всю необходимую консультантам информацию. Это совсем не такая простая задача, как может показаться. Дело в том, что пока ХД нет, и решения принимаются "вручную", никто не может точно определить и потребность в тех или иных решениях. Даже руководство фирмы зачастую не в состоянии точно сказать, какие решения придется принимать в будущем, поскольку, в силу обстоятельств, вынуждено непрерывно решать текущие вопросы.

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

Таким образом, процесс создания ХД является по самой своей природе циклическим. Ясно также, что стоит выкинуть из цепи консультант-пользователь-разработчик одно звено, и процесс неизбежно зайдет в тупик. Поэтому ХД может быть реализовано только во взаимодействии разных невзаимозаменяемых специалистов, объединенных общей целью.

Часто в процессе создания ХД предусматривается разработка прототипа - небольшой системы, которая призвана продемонстрировать пользователю новые возможности, с тем чтобы он, попробовав систему в работе, оценил, стоит ли продолжать разработку, или отложить ее до лучших времен.

К 2000 году, как считают эксперты известной консалтинговой фирмы Meta Group, примерно 90-95% американских фирм, входящих в список Fortune 1000 и использующих в своей деятельности информационные технологии, развернут Хранилища Данных. Наиболее масштабные ХД, существующие к настоящему времени, развернуты в телекоммуникационных компаниях и достигают объема 5 Tb. Объем вложений в технологии ХД на Западе достиг миллиардов долларов в год и продолжает нарастать. В компьютерной литературе проскальзывают упоминания о том, что экономия от внедренного ХД может достигать 1000%.

На фоне этих победных реляций холодным душем стала информация консалтинговой группы Earl Hadden&Associates, опубликованная пару лет назад. Фирма провела исследование законченных и ведущихся проектов по созданию ХД и установила, что 40% проектов ХД оказалось полностью убыточными, а 80% не принесли ожидаемых результатов. Эта информация оказалась настолько важной, что привела к появлению новой технологии построения ХД, основанной на понятии Витрины Данных.

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

Что дальше?

Следующим шагом в технологии ХД, который уже сделан ведущими производителями ПО, стала интеграция ХД и Интернет. Оказалось, что гипертекстовые возможности WWW естественным образом могут быть использованы при доступе к ХД. Это поставило в повестку для проблему параллельного доступа к нескольким ХД. При этом корпоративное ХД становится Витриной для конечного пользователя. Пока еще рано говорить о новом качестве такого ХД. Скорее, идет количественный рост за счет доступа к все большим и большим объемам данных.

Настоящий качественный скачок ожидается от быстрого распространения методов Интеллектуального Анализа Данных (ИАД). Цель ИАД - выявление скрытых закономерностей в данных, или трендов. Как самостоятельная дисциплина ИАД существует давно и развивается независимо от Хранилищ Данных, но только с появлением последних методы ИАД стали применяться к действительно гигантским объемам данных, хранящимся в ХД. С точки зрения пользователя, ИАД состоит в поиске и/или подтверждении гипотез, например, "верно ли, что снижение расходов на рекламу данного товара на N процентов приведет к падению продаж не более чем на K процентов?". Наиболее развитые системы ИАД способны сами находить закономерности, например "с вероятностью 0.75 совместная продажа товаров X и Y повышает продажи товара Y на 15%". Появились первые оптимистические отклики на ИАД-системы, но говорить о широком распространении этих методов пока еще рано.

Хранилища Данных в России

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

Стереотип первый. "Хранилище Данных - это просто Oracle Express" (или Informix MetaCube, Sybase IQ и т.д. в зависимости от вкусов и пристрастий говорящего). Нисколько не умаляя достоинств Oracle Express, необходимо констатировать, что этот продукт (как и все остальные, перечисленные выше) реализует только один из технических аспектов ХД и притом одним-единственным способом. Рынок подобных продуктов насчитывает десятки наименований, и у каждого продукта свои достоинства и недостатки. Выбор соответствующего технического средства (или набора средств) может быть сделан только на основании предварительного бизнес-анализа деятельности предприятия.

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

Не случайно этот стереотип противоречит всей мировой практике разработки ХД. Даже фирмы-производители ПО для Хранилищ Данных сознательно отказываются от самостоятельной разработки ХД, предпочитая заключать партнерские соглашения с консалтинговыми фирмами, специализирующимися в области бизнес-анализа. Лидерами в области консалтинга являются сейчас фирмы так называемой "большой шестерки", такие, например, как Price Waterhouse.

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

Стереотип четвертый. "Хранилище Данных? Опять покупка нового оборудования, нового программного обеспечения, поиск специалистов и т.д." Это даже не российская, а общемировая проблема. Стоит заметить, что как раз в России, где переход на новые технологии почему-то традиционно сопровождается полным забвением старых (на Западе до сих пор работают сотни IBM 370, и тысячи программистов пришут программы на КОБОЛе) эта проблема не так остра. Да и разработчики ПО для Хранилищ Данных прекрасно осознают, что их продукты будут покупать, только если они интегрируются в существующую программно-аппаратную среду. На самом деле нужно помнить, что ХД - это не догма, а гибкая технология, следование которой как раз и обеспечивает постепенный переход к новому качеству. Другими словами, именно постановка задачи разработки ХД позволяет по-новому взглянуть на процесс развития информационных технологий, в том числе, на необходимость модернизации имеющейся информационной среды.

Совсем короткое заключение

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