«А.В. Маслов ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ Учебное пособие Издательство Томского политехнического университета 2008 УДК 004.415.2(076.5) ББК 65ф.я73 М 31 Маслов А.В. М 31 Проектирование информационных ...»

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

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

Постановка задач РБП выполняется, как правило, на специальных двухдневных семинарах руководителей предприятия, на которых решаются следующие задачи.

1. Формулирование (уточнение) миссии предприятия.

2. Определение критических факторов успеха (7–8 факторов) или критериев эффективности организации бизнес-процессов: длительность, издержки, качество, сервисное обслуживание и т.д.

3. Выявление основных видов бизнес-процессов, как существующих, так и перспективных (10–15 процессов).

4. Неформальное описание отличительных особенностей выявленных бизнес-процессов.

5. Оценка важности бизнес-процессов по степени влияния на реализацию критических факторов успеха.

6. Определение ограничений, связанных с уровнем квалификации персонала фирмы, технической оснащенности производства, наличием информационных технологий, финансовых ресурсов.

7. Описание возможных сценариев развития предприятия: появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов.

8. Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров, конъюнктуры рынка.

9. Ранжирование бизнес-процессов для проведения РБП в соответствии с полученной оценкой важности, ограничениями, рисками и перспективами.

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

Так, формулирование миссии предполагает решение задач качественного анализа деловых процессов, связанных с определением стратегии поведения предприятия на рынке в части расширения границ рынка или глубокого проникновения на рынок, диверсификации деятельности или повышения качества товаров и услуг, глобализации или локализации деятельности и т.д. В качестве основных методов формирования стратегии предприятия обычно используются методы анализа иерархий Саати, нечеткой логики Заде, а инструментальных средств – статические экспертные системы с возможностью обработки качественных (нечетких) оценок, такие, как Expert Choice, Guru, Level5, Nexpert Objects и др.

Выбор бизнес-процессов выполняется на основе анализа сегментов рынка, с помощью которого конкретизируются стратегические цели предприятия для определения регионов, потребителей, каналов распределения продукции и услуг, а следовательно, и особенности организации бизнес-процессов. Основными методами исследований на этом этапе выступают методы статистического анализа и прогнозирования, нейронных сетей, интеллектуального анализа данных современных информационных хранилищ. Наиболее мощными инструментальными средствами анализа и прогнозирования для выявления основных сегментов рынка являются ППП SAS, Oracle Express, Business Objects, SPSS, NeurOn-Line, BrainMaker, PolyAnalyst и др.

Оценка ограничений и рисков, связанных с проведением РБП, выполняется в ходе решения задач бизнес-планирования. В частности, для выделенных бизнес-процессов осуществляется оценка возможностей предприятия в плане эффективности распределения капиталовложений по различным проектам. Для решения этой задачи обычно используются экономико-математические модели и методы оптимизации. К наиболее известным программным средствам бизнес-планирования относятся ППП Project Expert, «Альт-Инвест», ТЭО-ИНВЕСТ, COMFAR, PROPSPIN и др.

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

Планирование РБП осуществляется с помощью методов и средств управления проектами. С помощью простейших программных средств управления проектами типа TimeLine, Microsoft Project, Primavery строятся сетевые календарные графики выполнения работ. Более сложные программные продукты, такие, например, как Process Engineer (LBMS), позволяют определять ресурсы на выполнение проектных работ, вести библиотеки проектов, осуществлять коллективную разработку и мониторинг состояния проекта на последующих стадиях РБП. Средства планирования и управления работами поддерживаются также в комплексных технологиях проектирования и внедрения корпоративных ЭИС, например CASE Method (Oracle), Accelerated SAP (SAP), Orgware (BAAN).

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

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

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

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

На этапе обратного инжиниринга для понимания сущности функционирующих бизнес-процессов широко используются методы и средства структурного анализа деловых и информационных процессов (функционально-ориентированного или объектно-ориентированного моделирования), которые реализованы в таких известных ППП, как, например, Design/IDEF, BPWin, ERWin, OOWin, ARIS Toolset, Rational Rose и др.

Для оценки эффективности существующих бизнес-процессов используются прежде всего методы и средства функциональностоимостного анализа (ABC – Activity Based Costing), поддерживаемые, например, в ППП Design/IDEF, Easy ABC+, ARIS ABC и др. Так, функционально-стоимостной анализ позволяет выявить:

• наиболее трудоемкие и затратные функции;

• функции, не вносящие вклад в образование прибыли;

• функции с низким коэффициентом использования ресурсов.

Для динамической оценки существующих бизнес-процессов при наличии развитой функционирующей информационной системы и информационного хранилища могут использоваться методы анализа реальной статистики. В противном случае применяются методы и средства имитационного моделирования, например, ППП ReThink, РДО, Pilgrim, Ithink, Workflow Analyser, Service Model и др.

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

идеальную модель, которая может быть достигнута в перспективе и к которой следует стремиться;

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

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

Моделирование проблемной области бизнес-процессов (подробно особенности моделирования проблемной области см. в п. 5.3) выполняется в два подэтапа:

• во-первых, определяется объективная структура новой организации бизнес-процессов: состав объектов, функций и событий;

• во-вторых, объекты и функции бизнес-процессов распределяются по структурным подразделениям предприятия, и определяются требования к информационной системе.

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

На этапе прямого инжиниринга целесообразно использовать программные средства моделирования, которые позволяют отображать результаты моделирования проблемной области в репозитории – хранилище метаинформации о проекте, используемом на всех последующих этапах разработки проекта. К таким программным средствам относятся либо CASE-средства, например Oracle Designer 2000, SilverRun, Natural Engineering Workbench, Rational Rose и др. (см. тему 7), либо модельноориентированные средства компонентного проектирования, например, Business Engineer (SAP), Enterprise Modeler (Baan), либо специализированные, которые позволяют экспортировать модели в CASE-средства или модельно-ориентированные средства компонентного проектирования, например ARIS Toolset.

Достоинство специализированных программных средств моделирования бизнес-процессов заключается в большей ориентированности на собственно бизнес-реинжиниринг и предпроектный для информационной системы анализ, в то время как CASE-средства и модельноориентированные средства компонентного проектирования – на разработку информационной системы. В частности, для специализированных программных средств моделирования бизнес-процессов (например, ARIS Toolset, Design/IDEF) характерна поддержка инструментов статического функционально-стоимостного анализа и динамического имитационного моделирования для оценки заданных критериев эффективности бизнес-процессов.

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

Целями проведения имитационного моделирования бизнеспроцессов могут быть:

1) сравнения средних значений и дисперсий динамических характеристик различных альтернатив процессов при одинаковых исходных данных (один сценарий моделирования на несколько моделей);

2) отыскание оптимальных значений переменных на некотором множестве возможных значений (несколько сценариев моделирования на одну модель);

3) определение зависимостей между различными факторами процессов в результате специального анализа полученной статистики.

Развитые средства имитационного моделирования, такие, например, как ReTink (Gensym), позволяют:

• повысить степень обоснованности проектов по реорганизации деятельности предприятия с учетом анализа и прогнозирования внешних и внутренних факторов развития экономической ситуации;

• анализировать и прогнозировать деятельность предприятия с учетом множества вариантов организации бизнеса и различных схем поведения предприятия на рынке;

• оптимизировать использование материальных, финансовых, людских и информационных ресурсов на различных стадиях жизненного цикла проекта реорганизации предприятия;

• разрабатывать обоснованные рекомендации по изменению организационной структуры предприятия и внедрению информационных технологий.

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

Для изменения структуры организационно-экономической системы осуществляются:

• разработка организационно-штатной структуры предприятия;

• разработка должностных инструкций;

• разработка системы стимулирования работников;

• обучение персонала;

• подготовка рабочей документации.

Для создания новой информационной системы осуществляются:

• генерация, настройка, программирование и отладка программных модулей;

• разработка и наполнение базы данных;

• установка вычислительного оборудования и системы телекоммуникации.

Для быстрой разработки информационной системы широко используются CASE-средства автоматизации проектирования (см. тему 7) или средства конфигурации комплексных систем управления ресурсами предприятия (ERP-системы), например R/3, BAAN IV, Oracle Application, «Галактика», БОСС и др. В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средства быстрой разработки приложений (RAD-технология) и языки программирования 4-го поколения (4GL), например АВАР4, JAM и др. (см.

п. 7.4).

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

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

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

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

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

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

Для того чтобы получить адекватный проблемной области проект ЭИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы.

При этом под моделью понимается некоторая система, имитирующая структуру или функционирование исследуемой проблемной области, отвечающей основному требованию – адекватности этой области.

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

К моделям проблемных областей предъявляются следующие требования:

• формализованность, обеспечивающая однозначное описание структуры проблемной области. Для представления моделей используются нотации различных формальных языков моделирования;

• понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

• реализуемость, подразумевающая наличие средств физической реализации модели проблемной области в ЭИС;

• обеспечение оценки эффективности реализации модели проблемной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования проблемной области. Структурный аспект функционирования ЭИС предполагает построение:

• объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

• функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

• структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

• организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

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

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

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

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

Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой ЭИС.

Оценочные аспекты моделирования проблемной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

• время решения задач;

• стоимостные затраты на обработку данных;

• надежность процессов;

• косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

Для расчета показателей эффективности ЭИС, реализующей модель проблемной области, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.

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

Рассмотрим особенности построения моделей проблемной области на трех уровнях детализации.

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

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

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

Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС.

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

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

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций.

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

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

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

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

На концептуальном уровне устанавливаются бизнес-правила определяющие условия вызова функций при возникновении событий и достижении состояний объектов.

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

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

На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений.

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.

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

На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям.

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

На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.

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

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

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

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ЭИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ЭИС. Для функциональных моделей характерны процедурная строгость декомпозиции ЭИС и наглядность представления.

В функциональном подходе объектные модели данных в виде ERдиаграмм «объект – свойство – связь» разрабатываются отдельно. Для проверки корректности моделирования проблемной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.

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

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

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

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

В объектно-ориентированном подходе изменяется и принцип проектирования ЭИС. Сначала выделяются классы объектов, далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы. Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, обобщенные в языке унифицированного моделирования UML [89] (подробное описание объектно-ориентированного подхода представлено в п.

7.3). Однако по наглядности представления модели пользователюзаказчику объектно-ориентированные модели явно уступают функциональным моделям.

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

В полной мере комбинированный подход к моделированию проблемной области реализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information Systems), содержащем множество различных методологий, соответствующих различным взглядам на проектируемую систему: объекты, функции, организационная структура [46].

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

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

В качестве метода построения интегрированной модели бизнеспроцессов используется метод, основанный на управлении событиями (ЕРС – event-driven process chain method), который предполагает зависимость выполнения операций (функций) процесса от происходящих событий. При этом все операции процесса четко определены по входу и выходу, а также исполнителям по организационной структуре и техническим средствам. В ЕРС-модели однозначно определяется характер разветвления и соединения путей модели через логические связки X (AND, OR, XOR). От ЕРС-модели можно переходить в дальнейшем как к функционально-ориентированному, так и к объектно-ориентированному программированию системы.

1 Что такое бизнес-процесс и чем управление бизнес-процессами отличается от управления ресурсами?

2. Что такое реинжиниринг бизнес-процессов и чем он отличается от концепции всеобщего управления качеством?

3. Какие задачи решает реинжиниринг бизнес-процессов?

4. Какие требования предъявляются к корпоративной ЭИС?

5. Какие изменения архитектуры КЭИС способствуют реинжинирингу бизнес-процессов?

6. Назовите основные принципы реинжиниринга бизнеспроцессов.

7. Каковы основные этапы РБП?

8. Как изменяется модель жизненного цикла ЭИС в связи с РБП?

9. Какие классы инструментальных программных средств используются на различных этапах РБП?

10. Что понимается под моделью проблемной области?

11. Какие требования предъявляются к модели проблемной области?

12. В каких аспектах осуществляется моделирование проблемной области?

13. Какие существуют уровни моделирования проблемной области?

14. Что включает структурный уровень представления модели проблемной области?

15. Какие критерии используются для оценки модели проблемной области?

16. Какие существуют подходы к построению структурных моделей проблемной области на различных уровнях представления?

Тема 6. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНЫХ

КОРПОРАТИВНЫХ ЭИС

6.1. Основные понятия и особенности проектирования клиентсерверных экономических информационных систем (КЭИС) Архитектура современных КЭИС базируется на принципах клиент-серверного взаимодействия программных компонентов информационной системы.

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

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

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

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

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

Клиент-серверная архитектура в вычислительной сети может быть реализована по-разному. Выбор конкретной схемы определяется различными вариантами территориального распределения удаленных подразделений предприятия, требованиями эксплуатационной надежности, быстродействием, простотой обслуживания. Рассмотрим различные схемы клиент-серверной архитектуры (рис. 6.2).

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

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

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

Двухуровневая клиент-серверная архитектура основана на использовании только сервера базы-данных (DB-сервера), когда клиентская часть содержит уровень представления данных, а на сервере находится база данных вместе с СУБД и прикладными программами.

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

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

Обращение к базе данных осуществляется на языке SQL, который фактически стал стандартом для реляционных баз данных. Отсюда сервер баз данных часто называют SQL-сервером, который поддерживается всеми реляционными СУБД: Oracle; Informix, MS SQL, ADABAS D, InterBase, SyBase и др. Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.).

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

Централизованная “клиен т-сервер” “клиент-сервер” Многоуровневая “клиент-сервер” Рис. 6.2. Варианты клиент-серверной архитектуры КЭИС Трехуровневая клиент-серверная архитектура позволяет по мешать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «ceрвисами». Прикладные программы в свою очередь обращаются к серверу базы данных с помощью SQLзапросов. Такая организация позволяет еще более повысить производительность и эффективность КЭИС за счет:

• многократности повторного использования общих функций обработки данных во множестве клиентских приложений при существенной экономии системных ресурсов;

• параллельности в работе сервера приложений и сервера баз данных, причем сервер приложений может быть менее мощным по сравнению с сервером базы данных;

• оптимизации доступа к базе данных через сервер приложений из клиентских мест путем диспетчеризации выполнения запросов в вычислительной сети;

• повышения скорости и надежности обработки данных в результате дублирования программного обеспечения на нескольких серверах приложений, которые могут заменять друг друга в сети в случае перегрузки или выхода из строя одного из них;

• переноса функций администрирования системы по проверке полномочий доступа пользователей с сервера базы данных на сервер приложений.

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

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

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

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

• синхронный режим, когда тиражируемые данные обновляются по мере возникновения необходимости одновременно на серверах баз данных во всех копиях. Требуемое быстродействие каналов для синхронного режима – единицы Мбит в секунду;

• асинхронный режим, когда тиражирование данных выполняется в строго определенные моменты времени, например каждый час работы информационной системы. Требуемое быстродействие каналов для асинхронного режима – единицы Кбит в секунду. Асинхронный режим может вызывать откладывание выполнения транзакций до момента обновления данных.

Направление тиражирования между серверами баз данных может быть:

• равноправным, т.е. в обоих направлениях;

• сверху-вниз типа «ведущий/ведомый», когда на серверах филиалов содержатся только некоторые подмножества данных центральной базы данных;

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

Рассмотрим технологическую сеть техно-рабочего проектирования трехуровневой клиент-серверной КЭИС (рис. 6.3).

1. Разработка общей структуры корпоративной Эта операция выполняется на основе описания предметной области D1 и технического задания D4, а также универсумов сетевых операционных систем и технических платформ (U1), серверов БД (U2), программных средств разработки КЭИС (U3). Выходом данной технологической операции служат описание выбранной конфигурации технических средств и сетевой операционной системы D3, описание выбранного сервера БД – D2, описание выбранных программных средств разработки КЭИС – D5, описание функциональной структуры КЭИС – D6.

Сущность операции сводится к выбору программно-технической среды реализации КЭИС и распределению функций обработки данных КЭИС по уровням клиент-серверной архитектуры.

Рис. 6.3. Технологическая сеть техно-рабочего проектирования клиент-серверной КЭИС: D1 – описание предметной области;

D2 – описание выбранного сервера БД; D3 – описание выбранной конфигурации технических средств и сетевой операционной системы;

D4 – техническое задание; D5 – описание выбранных программных средств разработки КЭИС; D6 – описание функциональной структуры КЭИС; D8 – права доступа различным категориям пользователей КЭИС; D9 – журнал заполнения областей БД; D10 – сопровождающая документация; U1 – универсум сетевых операционных систем и технических платформ; U2 – универсум серверов БД; U3 – универсум программных средств разработки КЭИС; G1 – вычислительная сеть;

G2 – СУБД; G5 – SQL описание БД с управляющими элементами;

G6 – программное обеспечение сервера; G7 – приложения клиентских Выбор сетевых операционных систем во многом зависит от технической платформы вычислительных средств. При использовании платформы INTEL наиболее распространенными сетевыми ОС являются WINDOWS 95, 98, NT 2000. При использовании других платформ, таких, как IBM, SUN, HP и других, применяют ОС UNIX различных версий для соответствующих платформ.

Выбор сервера БД для КЭИС основывается на анализе рынка серверов БД по различным критериям:

• независимость от типа аппаратной архитектуры;

• независимость от программно-аппаратной платформы;

• поддержка стандарта открытых систем;

• поддержка многопроцессорной и параллельной обработки данных;

• оптимальное хранение распределенных данных;

• поддержка WEB-серверов и работа с Интернет;

• поддержка вторичных индексов;

• непрерывная работа;

• простота использования.

В качестве примера рассмотрим сравнение по вышеназванным критериям серверов БД ORACLE 7.0, MS SQL SERVER и ADABAS D.

Сравнительный анализ серверов БД представлен в табл. 6.1.

Выбор программных средств разработки КЭИС определяется требованиями применяемой технологии проектирования КЭИС.

Разработка общей функциональной структуры корпоративной информационной системы на основе функционально-ориентированной или объектно-ориентированной модели проблемной области (см. тему 7) заключается в определении:

• функций сервера БД;

• функций серверов приложений;

• функций клиентских мест;

• информации, которая необходима для выполнения этих функций;

• распределения серверов и клиентских мест по узлам вычислительной сети;

• прав доступа пользователей к КЭИС.

Основными правами доступа являются следующие:

• права на доступ к вычислительным ресурсам. Такие права задаются администратором вычислительной сети с помощью инструментов сетевой операционной системы. Процесс задания прав заключается в назначении различным категориям пользователей прав доступа к ресурсам сети и возможности выполнения над ними функций чтения, редактирования, записи. Например, пользователю с именем manager 1 доступны ресурсы, представленные в табл. 6.2.

Независимость от типа аппаратной архитектуры аппаратной платформы Поддержка стандарта открытых систем Поддержка многопроцессорной данных деленных данных бота с Интернет сов • права на доступ к объектам схемы базы данных КЭИС. Такие права задаются администратором сервера БД с помощью инструментов серверной СУБД. Процесс задания прав заключается в назначении различным категориям пользователей возможности выполнения над объектами схемы БД функций чтения редактирования, записи. Например, пользователю с именем manager 1 доступны объекты, представленные в табл. 6.3.

2. Создание вычислительной сети (ВС) для КЭИС (П2) Создание ВС заданной архитектуры для КЭИС заключается в закупке и монтаже оборудования, а также инсталляции сетевого программного обеспечения и СУБД. На основе описания функциональной структуры D6, описания выбранной конфигурации технических средств и сетевой операционной системы D3, описания выбранного сервера БД D2 происходят создание вычислительной сети G1 и установка СУБД G2.

manager1 D:\zapasy\ostatok1.dbf Только чтение D:\zapasy\ostatok.dbf Чтение, редактирование

KODM RW

На основе технического задания D4, описания выбранных программных средств разработки D5, описания функциональной структуры КЭИС D6, описания выбранного сервера БД D2 и его СУБД G2, конфигурации вычислительной сети G1 осуществляются разработка схемы БД с управляющими элементами – G5 и ее документирование D10.

Создание схемы БД сводится к выполнению следующих технологических операций (рис. 6.4).

Проектирование структуры распределенной базы данных (П31).

Разработка структуры распределенной базы данных D7 происходит на основе описания функциональной структуры КЭИС D6, как правило, с помощью CASE-технологии D5 с учетом описания выбранного сервера БД D2 в конкретной программно-технической среде G1 и СУБД G2. В результате строятся модель базы данных и подмодели для различных категорий пользователей на основе установления им прав доступа к данным.

Рис. 6.4. Технологическая сеть проектирования базы данных в клиент-серверной среде: D2 – описание выбранного сервера БД; D5 – описание выбранных программных средств разработки КЭИС; D6 – описание функциональной структуры КЭИС; D7 – структура базы данных; D10 – сопровождающая документация; G1 – вычислительная сеть; G2 – СУБД; G3 – область базы данных; G4 – SQL описание БД; G5 – SQL описание БД с управляющими элементами Создание области базы данных (П32).

Создание области базы данных G3 заключается в инициализации областей внешней памяти (системной, хранения данных, транзакций, хранения архивных данных). Данная операция выполняется системным администратором БД, который использует для этих целей средства СУБД сервера БД G2 и спроектированную структуру базы данных D7.

Загрузка SQL-описания БД (П33).

Загрузка SQL-описания БД G4 осуществляется системным администратором БД на основе схемы базы данных D7 средствами СУБД сервера БД G2.

Разработка управляющих элементов БД (триггеров, процедур и т. д.) (П34).

Разработка управляющих элементов G5, к которым относятся хранимые процедуры и триггеры, осуществляется на основе структуры базы данных D7 с учетом ее SQL-описания БД G4 и возможностей средств СУБД сервера БД G2. В результате получается готовая для эксплуатации схема базы данных с управляющими элементами, которая документируется в D10.

Хранимая процедура представляет собой вариант программного наполнения базы данных, основная функция которой – функциональное расширение схемы БД. Хранимая процедура выполняет то или иное логическое действие. Например, администратор банковской системы создает хранимую процедуру, которая реализует функцию «занести на счет номер X сумму Y».

Разработчик приложения пользуется этой процедурой, но не знает, как именно она работает. Это дает следующие преимущества:

• когда меняется алгоритм данного действия, то администратор меняет только эту хранимую процедуру и все приложения сразу начинают работать по-новому;

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

• хранимая процедура пишется одним человеком, а используется многими, следовательно, повышаются темпы разработки КЭИС;

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

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

На основании разработанной схемы БД с управляющими элементами G5, описания выбранного сервера БД D2 и его СУБД G2 осуществляется создание сервера БД, то есть физическое наполнение БД и настройка программ доступа СУБД. Выходом данной операции служат физическое установление прав доступа различным категориям пользователей КЭИС D8, журнал заполнения областей БД D9.

5. Разработка серверов приложений (П5) Исходя из информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, разрабатывается сервер приложения G5 и сопровождающая документация D10.

В состав сервера приложений входят набор сервисов (функций обработки данных) и монитор транзакций, осуществляющий управление выполнением сервисов по обслуживанию клиентских потребностей.

6. Разработка клиентских приложений на рабочих станциях (П6) На основе информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, создаются приложения клиентских мест G7, а также сопровождающая документация D10. В частности, осуществляется проектирование пользовательского интерфейса клиентских частей приложений.

6.2. Проектирование систем оперативной обработки транзакций Клиент-серверная архитектура КЭИС упрощает взаимодействие пользователей с информационной системой и между собой в процессе выполнения деловых процессов или длинных транзакций. Под д л и н н о й транзакцией будем понимать совокупность операций делового процесса, требующих обращения к КЭИС, каждая из которых не имеет ценности без выполнения всей совокупности. Под к о р о т к о й транзакцией или просто транзакцией будем понимать отдельное обращение к одному из компонентов КЭИС или обращение клиента к серверу. С помощью обработки длинных транзакций КЭИС позволяет управлять достаточно сложными цепочками операций делового процесса как единым целым. Такие информационные системы называют системами оперативной обработки транзакций (OLTP – OnLine Transaction Processing).

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

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

Использование систем управления рабочими потоками Под рабочим потоком будем понимать совокупность информационного и материального потоков в цепочке операций делового процесса.

Система управления рабочими потоками (СУРП) – это программный комплекс, который оперативно связывает персонал из различных подразделении предприятия и программные приложения в общий деловой процесс, позволяя его автоматизировать и управлять им как единым целым. СУРП интегрирует по управлению все взаимодействующие элементы рабочего потока, переключает потоки между приложениями, управляет выбором исполнителей операций (как персонала, так и программ). С позиции проектирования ЭИС СУРП обеспечивает выстраивание цепочек автоматизированных рабочих мест, которые обмениваются между собой информацией по вычислительной сети через распределенную базу данных. С позиции многоуровневой клиентсерверной архитектуры СУРП – это управляющая (супервизорная) программа, которая регулирует множественное взаимодействие клиентов и серверов приложений и баз данных в длинных транзакциях (рис. 6.5).

Таким образом, клиент обращается не напрямую к серверу приложений, а через СУРП, которая выбирает необходимое приложение в зависимости от конкретных событий в деловом процессе.

СУРП создаются на основе использования специального программного обеспечения для организации коллективной (групповой – workgroup) работы в локальных вычислительных сетях. В эту систему входят средства электронного обмена сообщениями и маршрутизации, которые позволяют организовывать непосредственный обмен результатами работы между участниками делового процесса, мониторинг выполнения делового процесса со стороны руководства предприятия, а также инициировать работу исполнителей по завершении выполнения автоматических процедур. Система управления рабочим потоком может быть реализована на основе специализированного программного обеспечения, например Staffware, Workroute, или встроена в контур интегрированной ЭИС, как в системах комплексной автоматизации R/3 и BAAN IV.

Основными особенностями системы управления рабочими потоками являются:

• наличие программы-менеджера рабочего потока, управляющей переходами между шагами задания и документирующей исполняемые процессы;

• поддержка маршрутной карты предприятия, определяющей схему прохождения работ в деловом процессе; обеспечение выбора исполнителей процессов по модели организационной структуры предприятия;

• обработка событий: временных (deadline) и завершения операций, условий (триггеров) подключения процессов;

• наличие средств электронной почты для обмена сообщениями между исполнителями и передача списка заданий от руководителей;

• автоматический контроль исполнения работ и информирование руководителей;

• обращение к интегрированной базе данных, через которую осуществляется обмен результатами работ исполнителей;

• открытые интерфейсы с внутренними и внешними приложениями, подключение транзакций по Интернету;

• сбор статистики о выполнении деловых процессов;

• подключение стандартных процедур и шаблонов оформления документов.

Центральным компонентом СУРП является менеджер рабочих потоков, который выполняет следующие функции:

• создание шагов задания;

• оценку условий выполнения шага заданий;

• обработку возникающих событий и принятие решений по сообщениям;

• контроль сроков выполнения шагов заданий (события по таймеру);

• передачу управления между приложениями;

• синхронизацию несколько одновременно выполняющихся процессов;

• распределение результатов выполнения шага задания по получателям;

• ведение журнала операций.

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

СУРП использует модель организационной структуры предприятия для создания списка заданий с учетом наличных ресурсов (поступления и выбытия работников и оборудования). Таким образом, СУРП поддерживает модель организационной структуры предприятия, внося по мере необходимости изменения в структуру взаимосвязей организационных единиц.

В работе менеджера рабочих потоков используются различные методы маршрутизации, основанные на определенных правилах. Так, в зависимости от предопределенности порядка выполнения процедур различают правила:

Рис. 6.5. Многоуровневая клиент-серверная архитектура на основе • жесткой маршрутизации;

• свободной маршрутизации;

• гибридной маршрутизации.

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

Свободная маршрутизация (ad hoс-маршрутизация) означает, что последовательность операций делового процесса не известна заранее и определяется только в ходе его выполнения. В этом случае решение о запуске определенной операции предоставляется участнику делового процесса, наделенному соответствующими правами.

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

В зависимости от порядка следования активизируемых операций может выполняться последовательная, параллельная или смешанная маршрутизация.

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

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

Смешанная маршрутизация допускает сочетание последовательной и параллельной маршрутизации.

Использование Интернет-приложений Многоуровневая клиент-серверная архитектура распространяется на Интернет-приложения, связывающие множество участников делового процесса, территориально удаленных друг от друга в рамках как одного, так и нескольких предприятий на основе применения сетевого протокола TCP/IP. Эти приложения разрабатываются для таких предметных областей, как управление финансами, логистикой, персоналом, учет и отчетность и др. Достоинство распределенных приложений заключается в устранении промежуточных звеньев делового процесса, когда пользователь, минуя обращения к тому или иному подразделению предприятия, напрямую обращается к информационной системе для выполнения требуемой функции. Причем обращение может быть выполнено из любого места, в любой день и в любое время суток в удобной для пользователя форме, используя обычную программу навигации (браузер) и мультимедийное представление информации в Интернете.

Типичными Интернет-приложениями являются:

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

Все необходимые документы (счета, накладные, платежные поручения) оформляются автоматически. Пользователю высылается уведомление о выполнении операции или отказе;

• «предприятие – предприятие», осуществление сделок закупкипродажи товаров, выполнение совместных проектов. В первом случае между предприятиями осуществляется обмен документов: договоров, заказов, счетов, накладных, платежных поручений. Причем в отличие от традиционного электронного обмена данными (EDI – Electronic Data Interchange) возможна такая синхронизация транзакций, что два деловых процесса закупки и продажи по сути сливаются в один общий процесс.

В случае осуществления проектов взаимная деятельность предприятий расширяется до проектирования изделий и планирования производства и образования совместных виртуальных предприятий. При этом обычно используется международный стандарт для обмена данными по моделям продукции STEP (Standard for the Exchange of Product model data);

• «работник (подразделение) – работник (подразделение)», приложения Интранета предполагают применение технологии Интернета для связи между сотрудниками одного предприятия. При этом используются описанные выше системы управления рабочими потоками.

В корпоративной информационной системе R/3 (SAP) для реализации распределенных деловых процессов с помощью Интернетприложений разработан специальный механизм Application Link Enabling (ALE), с помощью которого свободно связываются друг с другом программные компоненты, относящиеся к различным информационным системам. В частности, для взаимодействия программных компонентов предлагается использовать стандартные интерфейсы BAPI (Business Application Programming Interface). В системе R/3 в настоящее время разработано более 25 Интернет-приложений и более 100 BAPI интерфейсов к ним.

На рис. 6.6 представлена многоуровневая клиент-серверная архитектура для реализации Интернет-приложений в системе R/3. В этой архитектуре добавляется дополнительный уровень, обеспечивающий обработку транзакций в Интернете. В частности, SAP-сервер транзакций Интернета обеспечивает надежный доступ из Интернета/Интранета ко всем транзакциям R/3. Получив обращение из Интернета, SAP-сервер вызывает соответствующее Интернет-приложение, которое через BAPIинтерфейс осуществляет доступ к приложению R/3, в свою очередь обращающемуся к серверу базы данных.

ИНТЕРНЕТ

ИНТЕРНЕТ

BAPI BAPI BAPI

Рис. 6.6. Многоуровневая клиент-серверная архитектура для 6.3. Проектирование систем оперативного анализа данных Современные системы поддержки принятия решений и информационные системы руководителей основаны на применении специализированных информационных хранилищ (ИХ) и технологий оперативного анализа данных (ОLAP).

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

В основе информационного хранилища лежит понятие многомерного информационного пространства или гиперкуба (рис. 6.7), в ячейках которого хранятся анализируемые числовые показатели (например, объемы оборота, издержек, инвестиций и т.д.). Измерениями (осями) гиперкуба являются признаки анализа (например, время, группа продукции, регион, тип процесса, тип клиента и др.). При хранении признаки анализа отделяются от фактических данных, образуя так называемую инвертированную организацию хранения данных или структуру данных типа «звезда».

Рис. 6.7. Многомерная организация информационного хранилища К особенностям хранимой информации в ИХ относятся:

• интеграция или обобщение данных в ИХ из транзакционных баз данных по всем бизнес-процессам и структурным 7подразделениям предприятия в виде единого многомерного информационного пространства. Например, организуется хранение показателей объемов производства, сбыта, сервиса и т.д. в продуктовом, территориальном, отраслевом, временном и других разрезах;

• произвольность агрегации данных на основе отделения от фактических данных независимых и равноправных измерений информационного пространства (признаков анализа информации, разрезов) в виде иерархий агрегации. Например, региональный признак анализа представляется в виде иерархии агрегации: «область – район – город – село», временной при знак «год – квартал – месяц – день» и т.д.;

• обязательное хранение временного признака в данных, дающего возможность отслеживать динамику изменения показателей в течение длительного периода времени;

• непротиворечивость данных во всех используемых источниках в течение определенного периода времени (например, дня), которая позволяет обеспечить единую точку зрения всех пользователей на экономическую систему;

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

С технологической точки зрения к архитектуре ИХ предъявляются общие требования [104].

• Единообразно определенная структура многомерных данных с равноправными измерениями информационного пространства.

• Пользователь не должен знать о том, где хранятся данные, как они организованы и как обрабатываются.

• Поддержка многопользовательского режима оперативного анализа в среде «клиент-сервер».

• Легкая адаптация к новым информационным потребностям путем добавления новых показателей и измерений.

• Автоматическое обновление информации из оперативных баз данных.

• Выполнение запросов без ограничений на количество измерений и уровней их агрегации примерно с одинаковым временем реакции на запрос.

• Удобный, «интуитивный» интерфейс пользователя, обеспечивающий простоту манипулирования данными.

Архитектура системы оперативного анализа данных представлена на рис. 6.8.

Рассмотрим состав основных подсистем информационного хранилища.

Многомерное хранилище данных может быть организовано в виде одной из следующих структур:

• физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружаются данные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным инструментальным средством, поддерживающим MOLAP, являются Oracle Express (Oracle), Power Play (Cognos Corp), DataDirect (INTERSOLV);

• виртуальной структуры, называемой ROLAP (Relational OLAP), которая динамически используется при запросах, вызывающих физическое манипулирование с файлами-источниками из реляционных баз оперативных данных (формирование ответа на запрос к ИХ «на лету»).

ROLAP-система рассматривается просто как надстройка над реляционными базами данных, обеспечивающая удобный интерфейс пользователя. Типичными инструментальными средствами, поддерживающими ROLAP, являются MetaCube (Informix), Business-Objects (BusinessObjects) и др.;

• гибридной структуры, называемой HOLAP (Hybrid OLAP), которая используется при построении многоуровневых информационных хранилищ, применяемых на разных уровнях управления больших корпораций. Типичным инструментальным средством, поддерживающим HOLAP, является SAS System (SAS Institute).

Рис. 6.8. Архитектура информационного хранилища Сравнительный анализ применения MOLAP и ROLAP хранилищ представлен в табл. 6.5.

Анализ параметров использования MOLAP и ROLAP информационных хранилищ показывает, что внедрение и эксплуатация ROLAPсистем являются более простыми и дешевыми по сравнению с MOLAPсистемами, но уступают последним в эффективности оперативного анализа данных.

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

Важнейшей функцией репозитория является представление схем отображения структуры данных файлов-источников на структуре данных ИХ, в соответствии с которой осуществляется периодическая загрузка MOLAP-хранилища или непосредственная реализация запросов «на лету» в ROLAP-хранилищах.

В репозитории задается также схема отображения структуры ИХ на схемах представлений данных пользователей или витринах данных.

Через репозиторий осуществляется интерпретация запросов к ИХ на проведение оперативного анализа данных.

Сравнительный анализ применения MOLAP и ROLAP ИХ Требования к серверу Специализированный Скорость доступа Не зависит от транзакций Зависит от транзакций Кроссмерные функции мульные вычисления) Реорганизация (модифи- Пересоздание и Реструктуризация кация состава показателей перезагрузка хранилища отдельных таблиц Специализация измерений Разрешенный для всех из- Динамическое Отображение данных между источниками данных и ИХ, ИХ и представлением данных осуществляется либо через механизм межуровневого взаимодействия, либо через процедуры преобразования данных.

Подсистема преобразования данных (загрузки хранилища) Подсистема загрузки ИХ создается только для MOLAP-систем.

Для ROLAP-систем в процессе выполнения запросов осуществляется преобразование данных из файлов-источников. В том и другом случае требуется выполнение следующих основных функций:

• сбор данных (Data Acquisition);

• очистка данных (Data Cleaning);

• агрегирование данных (Data Consolidation).

Сбор данных предполагает передачу данных из источников в ИХ в соответствии со схемой отображения, представленной в репозитории.

В процессе очистки данных осуществляются проверка непротиворечивости (целостности), исключение дублирования данных, отбраковка шумовых (случайных) данных, восстановление отсутствующих данных, приведение данных к единому формату.

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

Подсистема представления данных (организации витрин данных) Под витриной данных (Data Mart) понимается предметно-ориентированное хранилище, как правило, агрегированной информации, предназначенное для использования группой пользователей обычно из 10– человек в рамках конкретного вида деятельности предприятия, например маркетинга, инжиниринга, финансового менеджмента и т.д.

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

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

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

• Поворот. Добавление нового признака анализа.

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

• Раскрытие (drill-down). Осуществляется декомпозиция признака агрегации на компоненты, например, признак года разбивается на кварталы. При этом автоматически детализируются числовые показатели.

• Свертка (roll-up/drill-up). Операция, обратная раскрытию. При этом значения детальных показателей суммируются в агрегируемый показатель.

• Сечение (slice-and-dice). Выделение подмножества данных по конкретным значениям одного или нескольких измерений.

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

Типичными задачами интеллектуального анализа данных являются:

• установление корреляций, причинно-следственных связей и временных связей событий, например определение местоположения прибыльных предприятий;

• классификация ситуаций, позволяющая обобщать конкретные события в классы, например определение типичного профиля покупателя конкретных видов продукции;

• прогнозирование развития ситуаций, например прогнозирование цен, объемов продаж, производства.

К основным методам интеллектуального анализа данных относятся:

• методы многомерного статистического анализа;

• индуктивные методы построения деревьев решений;

• нейронные сети.

Подсистема «Информационная система руководителя»

Информационная система руководителя предназначена для лиц, непосредственно принимающих решения. Поэтому интерфейс таких систем должен быть в наибольшей степени упрощенным. Обычно в качестве интерфейса руководителям предприятий предлагается набор стандартных отчетов и графиков, настраиваемых на потребности руководителя через систему меню. Часто в качестве интерфейса предлагаются диаграммы Ишикава («скелета рыбы»), представляющие собой саморазворачивающееся дерево показателей, в котором листья ветвей раскрашиваются в разные цвета, символизирующие характер состояния показателя (нормальный, тревожный, кризисный). Лист любой ветви дерева показателей может быть развернут в таблицу значений показателя или график. Подобные диаграммы применяются в таких корпоративных ЭИС, как R/3 и BAAN IV.

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

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

П1. Идентификация проблемной области На основе материалов предпроектного обследования (Д1) осуществляется параметризация проекта создания информационного хранилища и выделяются все необходимые материальные, финансовые, людские и временные ресурсы на выполнение проектных работ, т.е. составляются техническое задание (Д2) и технико-экономическое обоснование проекта (Д3). В частности, в рамках технического задания в разрезе конкретных видов деятельности или бизнес-процессов формулируются цели и задачи, области применения и пользователи ИХ, устанавливаются источники исходных данных, определяются информационные потребности пользователей.

Цели и задачи. Цели построения информационного хранилища во многом определяют характер используемых источников данных, направлений и методов анализа извлекаемой информации. В качестве целей создания ИХ могут выступать:

• реинжиниринг и непрерывный инжиниринг процессов и структуры управления предприятием;

• повышение качества и оперативности обоснования управленческих решений на стратегическом, тактическом и оперативном уровнях;

• упрощение управленческого документооборота для процесса принятия управленческих решений и др.

К важнейшим задачам, которые решаются с помощью ИХ, относятся:

• бизнес-планирование – обоснование принятия стратегических решений;

• контроллинг – анализ финансово-хозяйственной деятельности и выявление резервов совершенствования бизнес-процессов предприятия;

(benchmarking) важнейших показателей деятельности предприятия.

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

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

Перечень источников данных:

• внутренние источники: базы оперативных данных об объемах продаж, производства, закупок, издержках по центрам затрат, состоянии материальных, финансовых, людских ресурсов;

• внешние источники: официальные статистические данные о деятельности отрасли, смежных отраслях, состоянии финансов; нормативная государственная информация; маркетинговая информация о зондировании рынка, состоянии конкурентов; коммерческие базы данных специализированных компаний в области информационного бизнеса, например Reuters.

Для каждого источника данных определяются параметры: территориальное расположение, административное подчинение, периодичность обновления, конфиденциальность и достоверность хранимой информации, форматы данных и характеристики программно-технической среды, объемы данных.

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

П2. Разработка концептуальной модели ИХ Этап разработки концептуальной модели ИХ соответствует этапу логического проектирования, который выполняется на основе технического задания Д2 и технико-экономического обоснования Д3. На выходе этого этапа получаются логическая структура данных ИХ Д4, схема преобразования данных Д5, логическая структура витрин данных Д6 и схема представления данных Д7.

Проектирование логической структуры ИХ осуществляется на основе анализа статистики использования конкретных информационносправочных документов в процессе решения основных задач принятия решений. В результате выполнения операции производятся:

- отбор признаков анализа;

- построение схем агрегации показателей;

- построение схем обобщения признаков;

- определение временного горизонта хранения показателей;

- отбор первичных и производных показателей для хранения;

- выбор типа логической структуры ИХ;

- распределение показателей по типам логической структуры.

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

Сложность структуры данных показателей предопределяет выбор ее типа: «звезды» с однородной структурой признаков для всех показателей или «расширенной снежинки» с применением нескольких типов хранилищ показателей. В последнем случае осуществляется распределение показателей по типам хранилищ.

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

В частности, на этом этапе осуществляется анализ альтернативных источников данных, например выбор из числа коммерческих баз данных, а также устанавливаются схемы преобразований исходных данных в хранимые структуры ИХ. Сложность схем отображения источников данных в структуру хранилища предопределяет выбор типа ИХ: MOLAP, ROLAP, HOLAP.

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

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

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

Этап формализации завершает техническое проектирование информационного хранилища. На основе спроектированной на предшествующей операции архитектуры ИХ (Д4–Д6) и универсумов программно-технических средств (U1–U2) осуществляется выбор схемы размещения ИХ в сетевой вычислительной среде (Д7) и программнотехнических средств реализации ИХ (U3–U4).

Рис. 6.9. Технологическая сеть проектирования информационного хранилища: Д1 – материалы предпроектного обследования; Д2 – техническое задание; Д3 – технико – экономическое обоснование проекта; Д4 – логическая структура данных ИХ; Д5 – схема преобразования данных; Д6 – логическая структура данных витрин; Д7 – схема размещения ИХ в сетевой вычислительной среде; Д8 – проектная документация; U1 – универсум программных средств; U2 – универсум технических средств; U3 – универсум программных средств реализации ИХ; U4 – универсум технических средств реализации ИХ; G1 – репозиторий; G2 – настройка или процедуры инструментальных средств; G3 – наполнение информационного хранилища для MOLAP – структуры; G4 – модифицированный репозитарий; G5 – модифицированные настройки или процедуры инструментальных средств; G6 – модифицированное информационное хранилище для MOLAP – структуры Выбор схемы размещения ИХ в сетевой вычислительной среде осуществляется в зависимости от выбранного типа организации и предполагает определение числа уровней хранения:

• структура данных реализована централизованно на одном MOLAP-сервере;

• структура данных распределена на нескольких серверах в соответствии с ROLAP-организацией;

• наиболее оперативные и агрегированные данные хранятся на быстродействующем MOLAP-сервере, а детальные данные в ROLAPхранилище – на менее производительных серверах.

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