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

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

Объем проекта

В начале проекта определяются тре­бования бизнеса относительно того, какие данные, отчеты, показатели ин­тересны бизнесу. У любого проекта есть ограничения (бюджет, сроки, тре­бования качества), поэтому результа­том сбора требований может оказаться больший объем работ, чем предусмотрено оговоренными ограничениями. Здесь важно выделить требования, ко­торые необходимо получить в результате реализации проекта, причем независимо от того, имеется ли на данный момент такая информация или нет. Это могут быть требования, которые уже сегодня исполняются и которые следует пере­нести в хранилище, а также требования, которые сегодня не исполняются, но которые желательно реализовать. В том случае, если проект сталкивается с огра­ничением по времени и ресурсам, сле­дует придерживаться приведенной по­следовательности для дальнейших работ. Ограничения могут коснуться команды специалистов по реализации проекта на стадии сбора отчетов, KPI, изучения ис­точников данных.

Разработать модель данных всегда проще, чем потом ее реализовать физи­чески в хранилище и заполнить данны­ми. Теоретически количество сущностей в модели может быть огромным (от 200 до 400 и более). Но надо учитывать, что объем дальнейших работ будет линейно зависеть от количества сущностей моде­ли. Поэтому, если изначально нет огра­ничений на данное количество, можно выполнить проектирование модели в срок, однако дальнейшие работы в срок выполнены не будут. Есть два пути ре­шения задачи: построить модель всех интересуемых областей бизнеса, но при этом не ставить целью создание физиче­ски всей ее сущности; создавать модель постепенно, последовательно заполняя сущности и разбив проект на несколько этапов.

Обязательные условия

Проектный опыт нашей компании (Energy Consulting/Integration на момент публикации, прим. Prj-Exp.ru) показывает, что для построение модели требуется выполнение двух обязатель­ных условий: наличие опытного лидера по моделированию; активное участие в работах представителей бизнеса и ИТ-службы заказчика. Модель данных – это «взгляд» на деятельность компании, и лучше самого заказчика его бизнес не знает никто. При затрате больших вре­менных ресурсов бизнес-консультантов для получения информации модель бу­дет создана и будет верна. Но при таком подходе не будет полного понимания того, что это за модель и какие отчеты можно получить из хранилища, а так­же что надо предпринять в компании для улучшения информационной среды. Теоретически идеальной является ситуа­ция, которая предусматривает участие в проекте со стороны его исполнителя эксперта по всем областям деятельности компании, который знает, как устроены ее системы данных. В проекте появляет­ся лидер по модели, который постепен­но собирает все сведения о взглядах ана­литиков на деятельность компании и в дальнейшем о том, как эта информация представлена в ее системах. При этом основным его качеством должны быть не столько глубокое знание специфики деятельности компании, сколько умение правильно задавать вопросы и наличие опыта проектирования баз данных.

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

Процесс создания

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

С лидером по формированию модели будет создана первая модель, которую нужно проверить на адекватность и точ­ность со специалистами, работающими с источниками данных. Это исследова­ние проводят ИТ-консультанты, выяс­няя наличие данных и правильность их взаимосвязи в системах, а также бизнес-консультанты, поскольку именно они формулировали требования, и в случае возникновения вопросов решат их са­мостоятельно или совместно с бизнес-заказчиком.

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

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

К сожалению, даже проверка с источ­никами данных без точного определения сущности не даст правильного ответа. Имеются примеры, когда в формиро­вании какого-либо справочника ИТ-специалисты не участвуют и сверить со­держание справочников с источниками данных не могут. Например, рассмотрим частое употребляемое понятие «продукт» («услуга» или «товар»). Есть список про­дуктов в бухгалтерском учете компании, есть продуктовая линейка в ее марке­тинговом отделе, отличная от списка в бухгалтерском учете (это и услуги, и пакеты услуг, и продукты). Аналогично может отличаться степень детализации продукта у коммерческого отдела и у маркетинга. Следовательно, как будут описаны справочники и какие будут приведены представителями бизнеса и бизнес-консультантами примеры, так и будет составлена модель. Это могут быть либо одна, либо две, либо три сущности в зависимости от различий в принципе выделения продуктов. Именно поэтому определения и то, как эти сущности с точки зрения бизнеса связаны, важны для того, чтобы в дальнейшем на вопро­сы каждого отдела в отдельности по про­дуктам можно было ответить с помощью созданной модели.

Оптимальный путь создания модели

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

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

Белозеров Антон. "Финансовая газета", 31 июля 2008, №31 (867)