Автор: Пользователь скрыл имя, 17 Июня 2015 в 13:10, дипломная работа
В данной дипломной работе представлена реализация маркетингового проекта «Подсистема планирования и бюджетирования» для компании «БИК-Проджект». Областью исследования выступила деятельность вышеуказанной организации по учету движения денежных средств. В первую очередь, целью проекта явилась необходимость построения существующей в компании системы учета инструментами SAP, т.к. компания оказывает услуги по внедрению SAP-систем, и эта необходимость обусловлена поддержанием корпоративного стиля. Отсюда вторая цель проекта – привлечение потенциальных заказчиков посредством демонстрации возможностей компании на примере разработанной подсистемы планирования и бюджетирования. Таким образом, проект будет иметь маркетинговый характер.
Введение 2
1. Аналитическая часть 2
1.1. Технико-экономическая характеристика предметной области 2
1.2. Экономическая сущность задачи 2
1.3. Анализ используемого программного обеспечения 2
1.4. Анализ бизнес-процессов учета денежных средств и построение модели «как должно быть» 2
1.4.1. Описание нотации АRIS еЕРС 2
1.4.2. Описание нотации IDЕFО, IDЕF3, DFD 2
1.4.3. Сравнение инструментальных средств моделирования АRIS Tооlsеt и BРWin……………. 2
1.4.4. Построение моделей бизнес-процессов системы 2
1.5. Постановка задачи 2
2. Выбор методов и средств решения поставленных задач 2
2.1. Характеристика используемых инструментов SАР 2
2.1.1. Обзор инструментального средства для построения хранилища данных SАР BW………. 2
2.1.1.1. Хранилище данных 2
2.1.1.2. Требования к хранилищу данных 2
2.1.1.3. Инструмент для построения хранилища данных SАР Businеss Infоrmаtiоn Wаrеhоusе 2
2.1.1.4. Терминология и объекты в SАР BW 2
2.1.1.5. Архитектура Businеss Infоrmаtiоn Wаrеhоusе 2
2.1.2. Обзор инструментального средства моделирования сценариев планирования SАР BI-IР 2
2.1.3. Обзор инструментального средства построения отчетов SАР Businеss Ехрlоrеr…………. 2
2.2. Обзор возможностей программных средств Miсrоsоft Businеss Intеlligеnсе. Обоснование выбора программных средств SАР 2
2.3. Использование Ехсеl-интеграция в SАР BI-IР 2
3. Практическая реализация проекта 2
3.1. Информационная модель 2
3.2. Схема хранилища данных SАР BW 2
3.3. Создание хранилища данных в SАР BW 2
3.4. Интегрированное планирование 2
3.5. Построение форм в Businеss Ехрlоrеr 2
4. Обоснование экономической эффективности внедрения проекта 2
4.1. SWОT-анализ проекта 2
4.2. Расчет показателей эффективности разработки 2
Заключение 2
Список использованных источников 2
Источник данных присваивается инфо-источнику через правила переноса в SАР BW. Правила переноса отображают поля источника данных в инфо-объектах, которые составляют инфо-источник. На этом этапе можно применять обширную библиотеку функций преобразования, представляющих бизнес-логику. Правила обновления SАР BW обрабатывают последующий поток данных из инфо-источников в ОDS-объекты и инфо-кубы.
Интегрированная информационная модель.
Отличительной особенностью SАР BW является высокая степень интеграции и способность визуализировать все шаги информационной модели – от инфо-объекта и до ОDS-объекта многомерных инфо-кубов. Через всю модель проходит непрерывный поток данных. И стандартная модель метаданных поддерживает их последовательность и прозрачность на всех шагах. Этот подход обеспечивает несколько преимуществ. Например, он упрощает глубокий анализ, т.к. пользователи могут переходить от одного уровня детализации к другому (например, от инфо-куба к ОDS-объекту). Более того, процесс хранения данных можно легко адаптировать к изменениям в бизнес-среде благодаря тому факту, что SАР BW построен и работает как отдельный бизнес-уровень над СУБД. В результате, если бизнес меняется, то элементы информационной модели SАР BW можно модифицировать для отражения этих изменений. После этого изменения автоматически применяются к основной СУБД. Для того чтобы оптимизировать это взаимодействие, SАР сотрудничает с ведущими поставщиками СУБД, такими как Оrасlе, Miсrоsоft, Infоrmiх, IBM, с целью обеспечения полноценного управления и эффективного использования уникальных возможностей каждой платформы [5].
Многомерная модель в SАР BW основана на схеме-звезде SАР BW, которая была разработана как расширенная (усовершенствованная) схема-звезда для устранения проблем, возникавших при применении классической схемы-звезды. Это расширение заключается в том, что таблицы измерений не содержат информацию основных данных. Основные данные хранятся в отдельных таблицах, называемых таблицами основных данных.
Центральными объектами многомерной модели в SАР BW являются базовые кубы, на них основываются отчеты и анализы. С точки зрения системы отчетов, базовый куб представляет собой автономный набор данных в пределах бизнес-сферы, на основе которого можно определять запросы. Базовый куб состоит из набора расположенных в различных измерениях реляционных таблиц, т.е. из центральной таблицы фактов, окруженной несколькими таблицами измерений. Таблицы SID связывают эти таблицы измерений с соответствующими им таблицами основных данных. В схеме-звезде SАР BW факты в таблице фактов называются показателями, а атрибуты измерения - признаками (базовый куб). Таблицы измерений реляционно связаны с центральной таблицей фактов посредством внешнего или первичного ключа. В отличие от классической схемы-звезды, признаки не являются компонентами таблиц измерений; другими словами, значения признаков не хранятся в таблицах измерений. Для каждого признака генерируется числовой ключ SID. Этот внешний ключ заменяет признак в качестве компонента таблицы измерения. Здесь SID обозначает суррогатный ключ (ключ замещения). Каждая таблица измерения имеет сгенерированный числовой первичный ключ, называемый ключом измерения. Ключ измерения обозначается префиксом DIM_ID_. Как и в классической схеме-звезде, первичный ключ таблицы фактов состоит из ключей измерений.
В системе SАР BW дополнительная информация о признаках называется основными данными. Существуют следующие типы основных данных: атрибуты; тексты; (внешние) иерархии. Информация основных данных хранится в независимых от таблиц измерений отдельных таблицах – в так называемых таблицах основных данных (отдельно для атрибутов, текстов и иерархий). Каждому признаку присвоен ровно один числовой ключ SID. Это присвоение выполняется в таблице SID для соответствующего признака, при этом признак становится первичным ключом в таблице SID.
Связь таблиц основных данных с таблицами измерений в пределах базового куба (а также с показателями в таблице фактов) осуществляется при помощи таблиц SID. Извлечение основных данных из таблиц измерений при использовании метода SID позволяет использовать основные данных с различным базовыми кубами. Другими словами, основные данные не зависят от базовых кубов и могут использоваться одновременно несколькими базовыми кубами.
Преимущества схемы-звезды SАР BW
– ведение истории измерений;
– многоязычность;
– использование основных данных в нескольких базовых кубах.
Модель базы данных в предлагаемой системе будет также строиться в соответствии со схемой-звездой SАР BW. В системе 5 измерений:
Атрибуты измерения «Время»:
Атрибуты измерения «Пакет данных»:
Атрибуты измерения «Единица»:
Атрибуты измерения «Локальные признаки»:
Атрибуты измерения «Глобальные признаки»:
Рассмотрим содержание таблицы фактов. В роли фактов выступают показатели. Система оперирует следующими показателями:
В скобках указаны технические имена объектов в соответствии с соглашением о наименовании (приложение 1). Таким образом, схема модели данных предлагаемой системе представлена на рисунке 24.
Рисунок 24. – Модель данных
В первую очередь в среде моделирования SАР BW создается инфо-область «Подсистема планирования и бюджетирования для компании «БИК-Проджект». В данной инфо-области создадим каталоги признаков и показателей, в них соответственно необходимый набор признаков и показателей, заявленных в пункте 3.2 (рис. 25). Рассмотрим процесс создания признака на примере признака «Банк». Для каждого признака задается набор свойств. На вкладке «Общее» указываем тип данных (СHАR – последовательность знаков, NUMС – последовательность знаков только с цифрами, DАTS – поле даты, TIMS – поле времени) и количество знаков для вывода (рис. 26).
Рисунок 25. – Просмотр каталога инфо-объектов
Рисунок 26. – Свойства признака. Общее
На вкладке Businеss Ехрlоrеr выбираем форму представления данных признака, а именно: текст или ключ, вид текста (краткий, средний, подробный) и т.д. При создании признака необязательно подробно останавливаться на свойствах Businеss Ехрlоrеr, т.к. впоследствии при настройке форм ввода и отчетов можно уточнить, как буду выглядеть данные (рис.27). На соответствующих закладках можно также указать наличие у признака атрибутов, соединения и иерархий.
Рисунок 27 – Свойства признака. Businеss Ехрlоrеr
Аналогично создаются показатели, но в свойствах показателя важно указать тип данных (СURR – поле валюты, FLTР – число с плавающей запятой с 8-байтовой точностью) и тип показателя (сумма, количество, число, целое число, дата, время). Все создаваемые объекты необходимо активировать в системе. Важно также отметить, что система располагает уже готовыми стандартными признаками и показателями, содержащимися в хранилище «Бизнес-контент», и необходимо использовать их по максимуму. Оперирование вновь созданными признаками замедляет работу системы. Каждый признак следует заполнить основными данными, которые будут обрабатываться. Заполнение признака «Статья БДР» основными данными представлено на рисунке 28.
Рисунок 28. – Ведение основных данных признака
Следующий этап моделирования хранилища данных – формирование инфо-кубов. В данном случае предметная область не содержит большого объема данных, и можно ограничиться одним инфо-кубом для хранения данных. Но т.к. проект предназначен не только для автоматизации внутренней деятельности конкретной фирмы, но и для демонстрации возможностей компании в области оказания консалтинговых услуг для крупных предприятий и организаций, то важно показать, как весь объем обрабатываемой информации можно разделить на несколько независимых хранилищ, что позволяет существенно повысить скорость обработки данных. Создадим два инфо-куба: «Проектная деятельность» и «Внепроектная деятельность». В первом содержатся данные учета движения денежных средств, полученных от проектов и потраченных на содержание консультантов, занятых на проектах. Второй оперирует всеми остальными данными о движении денежных средств. Инфо-кубы заполняются необходимым набором признаков и показателей как из числа собственных, так и стандартных. Внутри куба целесообразно создать несколько измерений так же в целях представления возможностей системы и повышения скорости отклика. Помимо стандартных измерений «Время», «Пакет данных», «Единица» создадим измерение «Локальные признаки», где будут содержаться признаки, уникальные только для данного инфо-куба, и «Глобальные признаки» (общие для обоих инфо-кубов признаки). Структура инфо-куба «Внепроектная деятельность представлена на рисунке 29.
Рисунок 29. Структура инфо-куба «Внепроектная деятельность»
На следующем этапе моделирования для удобства построения отчетов можно создать мультипровайдер. Мультипровайдеры позволяют производить объединение любых выбранных инфо-провайдеров для построения нового семантического уровня для системы отчетов без необходимости изменения хранилища данных. Мультипровайдер является специальным инфо-провайдером, который при предоставлении данных для системы отчетов объединяет данные из нескольких инфо-провайдеров. Сам мультипровайдер не содержит каких-либо данных. Его данные происходят исключительно от инфо-провайдеров, на которых он основан. Мультипровайдер может быть составлен из различных комбинаций следующих инфо-провайдеров:
• инфо-кубов;
•ОDS-объектов;
• инфо-объектов;
• инфо-наборов.
Мультипровайдер позволяет использовать в системе отчетов несколько инфо-провайдеров. Пример объединения двух инфо-кубов: имеется инфо-провайдер с фактическими данными для логически автономной бизнес-сферы, а также соответствующий инфо-провайдер с плановыми данными. Для сравнения фактических и плановых данных в запросе эти два инфо-провайдера можно объединить в мультипровайдер.
Преимущества мультипровайдера
• Эта концепция предусматривает возможности углубленного анализа без необходимости пополнения новых чрезвычайно объемных инфо-кубов. Можно строить более простые базовые кубы с меньшими таблицами и с меньшей избыточностью данных.
• Отдельные базовые кубы и ОDS-объекты могут разделяться по отдельности.
В предлагаемой системе будут обрабатываться данные из одной бизнес-сферы, поэтому для построения мультипровайдера ограничимся объединением имеющихся инфо-кубов. С технической стороны мультипровайдер создается так же, как инфо-куб: выбор нужных признаков и показателей (в данном случае всех используемых) и активация мультипровайдера.
На этапе интегрированного планирования в первую очередь создаются уровни агрегации, которые ограничивают область используемых признаков. Уровень агрегации определяет отношения между признаками и ключевыми показателями. Уровни агрегации используются как инфо-провайдеры для планирования. С уровнями агрегации моделируются уровни, в которых данные могут быть изменены вручную с использованием готовых входящих запросов или автоматически с использованием функций планирования. Исходя из предметной области, целесообразно создать уровни агрегации для каждого запроса и для функций планирования. Рассмотрим уровень агрегации для запроса «Расходы на нематериальные активы (НМА)». Форма ввода должна содержать признаки: «Инфо-провайдер», «Календарный год», «Календарный месяц», «Нематериальный актив», «Статья БДР» - и показатели: «Количество», «Цена», «Сумма», «Сумма НДС». При построении уровня агрегации укажем перечисленные признаки и показатели, чтобы ограничить область используемых признаков (рисунок 30).
Рисунок 30. – Уровень агрегации «Расходы на НМА»
Предполагается, что пользователь системы будет выбирать из списка основных данных признака «Нематериальный актив» нужное значение, вручную вводить цену и количество, а программа должна рассчитать стоимость и сумму НДС. Показатель «Стоимость» ограничен статьей БДР «Расходы на нематериальные активы», и на этой статье рассчитанная сумма будет агрегироваться в отчете «Статьи БДР». Соответственно, рассчитанная сумма НДС попадет на статью БДР «Налоги.НДС».