бесплатные рефераты

Автоматизированная система управления менеджментом и маркетингом коммерческого банка

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

· Перекресток ветвления (Fan-out Junction) - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.

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

На диаграмме под номером А2.3.1.1 «Выбор вида услуги», (рис.8) показаны следующие виды работ:

1. Сбор данных и анализ информации для выбора вида услуги;

2. Выбор вида банковской операции;

3. Выбор продуктового ряда банка;

4. Выбор простого продукта;

5. Выбор сложного продукта;

6. Выбор банковской услуги;

Также использована ссылка «Услуги» и «Мониторинг внешней среды» и перекресток типа Asynchronous OR. Перекресток типа Аsynchronous OR под номером J1 показывают, что один или несколько процессов должны быть запущены, и перекресток типа Аsynchronous OR под номером J2 показывает, один или несколько процессов должны быть завершены.

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

Для создания сценария необходимо из диаграммы декомпозиции А2.3.1.1 удалить работы, стрелки и перекрестки, не входящие в сценарий. На рис. 9 показана диаграмма сценария под номером А2.3.1.2 созданная на основе диаграммы IDEF3 «Выбор вида услуги»

Рис.8 Диаграмма IDEF3 «Выбор вида услуги» А2.3.1.1

Рис.9 Диаграмма сценария А2.3.1.2

2.6 Функционально-стоимостной анализ

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

B BPwin модуль ABC применяется для:

· понимания происхождения выходных затрат и определения их стоимости;

· определение действительной стоимости производства продукта;

· определения требуемых ресурсов;

· определение действительной стоимости поддержки клиента;

· оценки и анализа затрат на осуществление различных видов деятельности;

· облегчения выбора оптимальной модели процесса при реорганизации деятельности предприятия;

· выделения наиболее дорогостоящих операций для их реинжиниринга.

Применение модуля ABC и имеющихся в BPwin средств подготовки отчетов позволяет обеспечить корпоративную стратегию управления хозяйственной деятельностью.

ABC включает следующие основные понятия:

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

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

· центры затрат - различные статьи расходов.

Функционально-стоимостной анализ проводится только при полностью созданной модели процесса, т. е. когда модель:

- последовательная - следует синтаксическим правилам IDEF0;

- корректная - полностью отражает процесс;

- полная - охватывает всю рассматриваемую область;

- стабильная - проходит цикл экспертизы без изменений.

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

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

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

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

Таблица 5. Центры затрат АВС

Название

Описание

Персонал

Затраты на оплату заработной платы рабочим

Управление проектом

Затраты на управление предприятием

Оборудование

Затраты на покупку нового оборудования

Центры затрат ABC

Введём следующие данные для работ:

Таблица 6. Стоимости работ

Имя работы

(Activity name)

Цент затрат

(Cost Center)

Сумма центра затрат (Cost Center Cost)t,руб.

Продолжи

тельность

Duration день)

Частота

(Frequency)

Управление марк деят КБ

Рабочая сила

Управление

25503

15500

13,00

1,00

Управление фин менедж КБ

Рабочая сила

Управление

4500

24300

33,00

1,00

Организация

осуществления марк-х стратег

и программ

Рабочая сила

Управление

5700

3300

3,00

1,00

Учет и контроль

маркетинговой

деятельности

Рабочая сила

Управление

19800

10800

19,00

1,00

Планирование

Рабочая сила

Управление

15000

5400

9,00

1,00

информация о

конъюнктуре рынка

Рабочая сила

Управление

6300

1800

6,00

1,0

Создание

продуктового

ряда

Рабочая сила

Управление

23700

17100

18,00

1,00

Рис.10 Фрагмент отчета Cost Report

2.7 Диаграммы FEO диаграмма дерева узлов

Диаграммы «только для экспозиции» часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и входа. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и с одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения, рекомендуется все-таки придерживаться синтаксиса IDEF0.

FEO диаграмма «Система управления менеджментом и маркетингом КБ» (рис. 11) показывает взаимодействие между работами на этой диаграмме без указания стрелок управления и входа.

Рис.11 FEO Диаграмма декомпозиции А0F

Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Диаграмма дерева узлов работы «Система управления менеджментом и маркетингом КБ» состоит из четырех уровней и будет иметь следующий вид:

Рис.12 Диаграмма дерева узлов

3 Информационная модель в нотации IDEF1.X

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

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

ER-диаграммы были приняты в качестве основы для создания стандарта IDEF1.X. Предварительный вариант этого стандарта был разработан в военно-воздушных силач США и предназначался для увеличения производительности при разработке компьютерных систем. В 1981г. этот стандарт был формализован и опубликован организацией ICAМ, и с тех пор является наиболее распространенным стандартом для создания моделей баз данных по всему миру.

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

3.1 Логическая модель

· ЕRD-диаграммы;

· Модель данных, основанная на ключах;

· Физическая модель.

Первым шагом при создании логической модели БД является построение диаграммы ERD. ЕRD-диаграммы состоят из трех частей: сущностей, атрибутов и. взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи глаголами.

3.1.1 ЕRD-диаграммы

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

3.1.2 Сущности и Атрибуты ERwin

Сущность служит для представления набора реальных или абстрактных предметов (людей, мест, событий и т.п.), которые обладают общими атрибутами или характеристиками. Сущность «логический» объект, который в физической среде СУБД представлен таблицей. Сущность в ERwin обычно описывает три части информации: атрибуты, являющиеся первичными ключами, неключевые атрибуты и тип сущности.

3.1.3 Логические взаимосвязи

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

Данные, относящиеся к связям, очень важны и часто являются критическими данными, которые мы используем в повседневном бизнесе. Например, важно знать о каком-то типе инструмента, но знание того, к кому относится конкретный инструмент (связь между человеком и инструментом) может иметь критическую важность. Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - «логический» объект, представленный одним или несколькими атрибутами - внешними ключами. Связь в ERwin обычно содержит пять типов информации: тип связи, родительский конец связи, дочерний конец связи, ERwin toolbox содержит два типа сущностей: независимые и зависимые. Независимая СУЩНОСТЬ это сущность, экземпляры которой могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая СУЩНОСТЬ - это сущность, экземпляры которой не могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью или сущностями. Она представляется на ЕR-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

Связи в IDEFIX представляют собой ссылки; соединения и ассоциации между сущностями. Связи это глаголы, которые показывают, как соотносятся сущности между собой

3.1.4 Модель данных, основанная на ключах

Каждая сущность содержит горизонтальную линию, разделяющую атрибут на две группы.

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

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

· Никакой из атрибутов первичного ключа не должен иметь нулевое значение.

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

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

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

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

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERwin генерирует неуникальный индекс для каждого инверсионного входа. На рисунке можно рассмотреть таблицы, перенесенные из BPwin в Erwin, к которым добавлены некоторые из сущностей и атрибутов. (Рис. 13).

Рис. 13 Модель сущность-связь

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

Следующим этапом будет создание модели, основанной на ключах (рис. 14).

Рис. 14 Модель, основанная на ключах

На рисунке 14 показаны все сущности независимые. Для каждой сущности определяем ключевые атрибуты. Для сущности «Договор» это будет уникальный код «Код_договора». Для сущности «Клиент» это будет код «ИНН_клиента». Сущность «Реквизиты» будет определятся кодом «ИНН_банка». Для сущности «Услуги» это будет код «Код_услуги».

Далее следует построение полной атрибутивной модели (рис. 15).

Рис. 15 Логическая модель в нотации IDEF1.X

3.2.Физическая модель

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

В ERwin также представлены два уровня физической модели: трансформационная модель и модель СУБД. Целью трансформационной модели является предоставление информации администратору. Модель СУБД транслируется из трансформационной модели. Являясь отображением системного каталога, ERD-диаграмма графически представляет структуру данных проектируемой ИС.

ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого.

Рис.16 Физическая модель в нотации IDEF1.X

3.3 Генерация физической модели

Посредством Erwin можно также создавать и физические модели данных для различных СУБД. Для создания физической модели необходимо в окне создания новой модели выбрать тип создаваемой модели Logical/Physical и тип базы данных, в которой необходимо создать таблицы (Рис. 17). В данном курсовом проекте мы создадим физическую модель для СУБД Borland C++Builder 6 в сервере БД - Paradox 7.

Рис. 17 Выбор типа модели

Далее создается модель из уже ранее существующей модели созданной в Erwin. Для начала перейдем на физический уровень данных (рис. 18).

Рис. 18. Выбор уровня данных

Затем, в панели инструментов нажимаем кнопку , в появившемся окне выбираем Model level compare и указываем файл из которого необходимо импортировать данные (рис. 16)

Рис. 19. Импорт данных из существующей модели

В последующих окнах необходимо выбрать данные, настройки которые необходимо импортировать. Импорт таблиц и их строк осуществляется путем нажатия на кнопку Import . Чтобы не импортировать не нужные данные, надо выбрать их из списка и нажать на кнопку Ignore . Окно выбора данных представлено на рисунке 20.

Рис.20. Окно выбора импортируемых данных

После нажатия кнопки необходимо подтвердить появившийся запрос Erwin. Получившаяся модель представляет собой физическую модель для сервера БД Paradox 7 (рис. 21)

Рис. 21 Физическая модель

На данном этапе возможно изменить формат конечной БД, для этого необходимо щелкнуть по кнопке «Select target server» и в открывшемся окне Рис. 22 выбрать необходимый тип. При нажатии на кнопку «ОК» модель преобразуется в тот тип, который мы выбрали.

Рис. 22Target Server

3.4. Экспорт физической модели

Теперь необходимо построить таблицы на основе данной модели, для этого необходимо щелкнуть по кнопке «Forward Engineer» или же Tools -> Forward Engineer/Schema Generation… В результате чего откроется окно представленное на Рис. 23

Рис. 23 dBASE IV Schema Generation

Во вкладке «Options» мы указываем опции генерации таблиц, во вкладке «Summary» мы можем просмотреть включенные опции, а во вкладке «Comment» оставить комментарии.

Щелкнув по кнопке «Filter…» мы можем выбрать таблицы которые будут созданы Рис. 24

Рис.24 Выбор таблиц

Щелкнув по кнопке «Preview…» мы просматриваем о действиях программы и данные о таблицах Рис. 25

Рис.25 Preview

Щелкнув по кнопкам «Print» и «Report…» мы можем вывести на печать отчет или сохранить его в отдельном файле соответственно. Нажав на кнопку «Generate…» появляется окно Рис. 26 в котором мы должны указать папку для сохранения таблиц.

Рис. 26 Paradox/ODBC Connection

Созданные нами таблицы могут в дальнейшем быть использованы для создания БД. На Рис. 27 представлены созданные таблицы.

Рис. 27 Таблицы в Database Desktoр

Заключение

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

Курсовой проект выполнен с использованием инструментов визуального моделирования бизнес-процессов BPwin 4.1 и баз данных Erwin 4.1 автоматизированным способом и посвящен системе анализа управления менеджментом и маркетингом КБ.

В соответствии с поставленной целью нами в курсовой работе решены следующие задачи:

изучены основные теоретические и методологические положения по автоматизированной системе управления менеджментом и маркетингом КБ;

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

· осуществлено моделирование бизнес-процессов с использованием case-средств BPwin и ERwin.

Список использованной литературы

Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2000.

Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование нформационных систем: учебное пособие / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - 2-е изд., испр. М.: Интернет-Университет Информационных Технологий; БИНОМ.Лабора-тория знаний, 2008.-300с.

Дубейковский В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? М.:ДИАЛОГ-МИФИ, 2004. - 464 с.

Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник / Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. - М.: Финансы и статистика, 2001.

Базы данных: Учебник для высших учебных заведений/ Под ред. проф. А.Д.Хомоненко. - СПб.: КОРОНА принт, 2000. - 416 с.

Маклаков С.В. Моделирование бизнес процессов с AllFusion Process Modeler (BPWin 4.1). М.: ДИАЛОГ - МИФИ, 2004. - 240с.

Маклаков С.В. BPWin, ERWin. CASE-средства разработки информационных систем. - М. ДИАЛОГ-МИФИ, 1999.

Моделирование и анализ IDEF-технологии: практикум/ С.В.Черемных, И.О.Семенов, В.С.Ручкин. - М. Финансы и статистика, 2002. - 192 с.: ил.

Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.

Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989. - 351 с.

Приложение 1

Отчет по модели BPwin на тему

«Автоматизированная система управления менеджментом и маркетингом КБ»

Зелфикарова Атира Зелфикаровна

Model

. 'Model' section. 'Model' section. 'Model' sectionModel TableModel TableModel TableModel

Property

Value

Name

Система управления менеджментом и маркетингом КБ

Definition

Scope

Time Frame

(AS-IS)

Status

WORKING

Purpose

Моделирование бизнес-процессов системы управления менеджментом и маркетингом КБ

Source

Author

Зелфикарова А.З.

Creation Date

19.12.2010

System Last Revision Date

26.12.2010

User Last Revision Date

26.12.2010

Activity

. 'Activity' section. 'Activity' section. 'Activity' sectionActivity TableActivity TableActivity TableActivity

Name

Number

Definition

Status

Author

Аудит маркетинга

12

WORKING

Зелфикарова А.З.

Выбор банковской услуги

6

WORKING

Зелфикарова А.З.

Выбор вида банковской операции

2

WORKING

Зелфикарова А.З.

выбор вида услуги

A2.3.1

WORKING

Зелфикарова А.З.

Выбор продуктового ряда банка

3

WORKING

Зелфикарова А.З.

Выбор простого продукта

4

WORKING

Зелфикарова А.З.

Выбор решения

9

WORKING

Зелфикарова А.З.

Выбор сложного продукта

5

WORKING

Зелфикарова А.З.

Диагностика

A2.2.2

WORKING

Зелфикарова А.З.

Доля рынка

34

WORKING

Зелфикарова А.З.

информация о конъюнктуре рынка

A2.2

WORKING

Зелфикарова А.З.

Контроль маркетинга

14

WORKING

Зелфикарова А.З.

Контроль прибыльности

36

WORKING

Зелфикарова А.З.

Косвенные затраты

38

WORKING

Зелфикарова А.З.

Моделирование

A2.1.2

WORKING

Зелфикарова А.З.

Мониторинг

A2.2.1

WORKING

Зелфикарова А.З.

Обсуждение и согласование частей договора

A2.3.3.3

WORKING

Зелфикарова А.З.

Объем продаж

33

WORKING

Зелфикарова А.З.

оказание услуги

A2.3.2

WORKING

Зелфикарова А.З.

Оперативное планирование

A2.1.3

WORKING

Зелфикарова А.З.

Оперативный контроль

32

WORKING

Зелфикарова А.З.

Организация осуществления марк-х стратегий и программ

A1.2

WORKING

Зелфикарова А.З.

Отношение потребителей к предприятию и его продукции

35

WORKING

Зелфикарова А.З.

оформление документации и договоров

A2.3.3

WORKING

Зелфикарова А.З.

Планирование

A2.1

WORKING

Зелфикарова А.З.

Планирование маркетинга

A1.1

WORKING

Зелфикарова А.З.

Постановка задачи

7

WORKING

Зелфикарова А.З.

Проведение контроля марк деятельности

30

WORKING

Зелфикарова А.З.

Прямые затраты

37

WORKING

Зелфикарова А.З.

Реализация задачи

10

WORKING

Зелфикарова А.З.

Ревизия маркетинга

13

WORKING

Зелфикарова А.З.

Сбор данных и анализ информации для выбора вида услуги

1

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A0

WORKING

Зелфикарова А.З.

Ситуационный анализ

11

WORKING

Зелфикарова А.З.

Создание продуктового ряда

A2.3

WORKING

Зелфикарова А.З.

Соотв и результативность выбранной стратегии

39

WORKING

Зелфикарова А.З.

Составление договора

A2.3.3.1

WORKING

Зелфикарова А.З.

Стратегический контроль

31

WORKING

Зелфикарова А.З.

Стратегическое планирование

A2.1.1

WORKING

Зелфикарова А.З.

Управление маркетинговой деятельностью КБ

A1

WORKING

Зелфикарова А.З.

Управление финансовым менеджментом КБ

A2

WORKING

Зелфикарова А.З.

Утверждение договора

A2.3.3.2

WORKING

Зелфикарова А.З.

Учет и контроль маркетинговой деятельности

A1.3

WORKING

Зелфикарова А.З.

Формирование альтернативных решений

8

WORKING

Зелфикарова А.З.

Cost Center

. 'Cost Center' section. 'Cost Center' section. 'Cost Center' sectionCost Center TableCost Center TableCost Center TableCost Center

Name

Definition

Cost

Раббочая сила

Затраты на оплату рабочих

70 503,00

Управление

Затраты на управление, связанные с сотавлением графика работ

39 800,00

Arrow

. 'Arrow' section. 'Arrow' section. 'Arrow' sectionArrow TableArrow TableArrow TableArrow

Name

Definition

Status

Author

выбранный вид услуги

WORKING

Зелфикарова А.З.

готовая модель

WORKING

Зелфикарова А.З.

готовый договор

WORKING

Зелфикарова А.З.

данные мониторинга

WORKING

Зелфикарова А.З.

документация и договора

WORKING

Зелфикарова А.З.

документы и договора

WORKING

Зелфикарова А.З.

информация о договоре

WORKING

Зелфикарова А.З.

информация о конъюнктуре рынка

WORKING

Зелфикарова А.З.

информация о сотрудниках

WORKING

Зелфикарова А.З.

информация по клиентам

WORKING

Зелфикарова А.З.

маркетинговый отдел

WORKING

Зелфикарова А.З.

маркетинговый план

WORKING

Зелфикарова А.З.

менеджер

WORKING

Зелфикарова А.З.

оказание услуг

WORKING

Зелфикарова А.З.

отчеты и отчетность КБ

WORKING

Зелфикарова А.З.

принятие решения клиентом

WORKING

Зелфикарова А.З.

принятый договор

WORKING

Зелфикарова А.З.

программа маркетинга

WORKING

Зелфикарова А.З.

способы решения задач

WORKING

Зелфикарова А.З.

услуга оказанная

WORKING

Зелфикарова А.З.

услуги для утверждения договора

WORKING

Зелфикарова А.З.

финансовые показатели КБ

WORKING

Зелфикарова А.З.

цель и стратегия управления КБ

WORKING

Зелфикарова А.З.

Entity

. 'Entity' section. 'Entity' section. 'Entity' sectionEntity TableEntity TableEntity TableEntity

Name

Definition

Договор

Клиент

Услуги

Data Store

. 'Data Store' section. 'Data Store' section. 'Data Store' sectionData Store TableData Store TableData Store TableData Store

Name

Number

Definition

Author

Status

Договор

2

Зелфикарова А.З.

WORKING

Клиент

3

Зелфикарова А.З.

WORKING

Услуги

1

Зелфикарова А.З.

WORKING

Diagram

. 'Diagram' section. 'Diagram' section. 'Diagram' sectionDiagram TableDiagram TableDiagram TableDiagram

Name

Number

Status

Author

выбор вида продукта

A2.3.1.2

WORKING

Зелфикарова А.З.

выбор вида услуги

A2.3.1.1

WORKING

Зелфикарова А.З.

информация о конъюнктуре рынка

A2.2

WORKING

Зелфикарова А.З.

Организация осуществления марк-х стратегий и программ

A1.2.1

WORKING

Зелфикарова А.З.

оформление документации и договоров

A2.3.3

WORKING

Зелфикарова А.З.

Планирование

A2.1

WORKING

Зелфикарова А.З.

Планирование

A2.1

WORKING

Зелфикарова А.З.

Планирование маркетинга

A1.1.1

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A-0

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A0

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A0

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A0

WORKING

Зелфикарова А.З.

Система управления менеджментом и маркетингом КБ

A0

WORKING

Зелфикарова А.З.

система управления менеджментом и маркетингом КБ

A0F

WORKING

Зелфикарова А.З.

Создание продуктового ряда

A2.3

WORKING

Зелфикарова А.З.

Создание продуктового ряда

A2.3

WORKING

Зелфикарова А.З.

Управление маркетинговой деятельностью КБ

A1

WORKING

Зелфикарова А.З.

Управление маркетинговой деятельностью КБ

A1

WORKING

Зелфикарова А.З.

Управление финансовым менеджментом КБ

A2

WORKING

Зелфикарова А.З.

Управление финансовым менеджментом КБ

A2

WORKING

Зелфикарова А.З.

Учет и контроль маркетинговой деятельности

A1.3.1

WORKING

Зелфикарова А.З.

Приложение 2

Отчет по модели ERwin на тему «Автоматизированная система управления менеджментом и маркетингом КБ»

Зелфикарова Атира Зелфикаровна

Table of Contents

'Table of Contents' needs to be generated! For instance, if this is Microsoft Word then you need to select this text, bring up the context menu - right mouse click, and choose 'Update Field'.

. 'Picture' section. 'Picture' section. 'Picture' sectionMain Subject Area/Display1Main Subject Area/Display1Main Subject Area/Display1Main Subject Area/Display1

Attribute

. 'Attribute' section. 'Attribute' section. 'Attribute' sectionAttribute TableAttribute TableAttribute TableAttribute

Name

Required

E-mail

Yes

ИНН_клиента

Yes

телефон

Yes

ИНН_клиента

Yes

ИНН_банка

Yes

ИНН_клиента

Yes

Коррес_счет

No

КПП

No

Лицев_счет

No

Адрес_КБ

No

Телефон_КБ

No

Код_услуги

Yes

ИНН_клиента

Yes

Дата_оказания_услуги

No

Стоимость_услуги

No

Название_услуги

No

ИНН_клиента

Yes

Телефон

No

Адрес

No

ФИО_клиента

No

E-mail

No

№_договора

Yes

ИНН_клиента

Yes

Срок_договора

No

Дата_закючения

No

Название_проекта

No

Сумма_вложений

No

Условия_договора

No

Условия_договора

Yes

Срок_договора

No

Diagram

. 'Diagram' section. 'Diagram' section. 'Diagram' sectionDiagram TableDiagram TableDiagram TableDiagram

Name

Author

Database Name

база

Entity

. 'Entity' section. 'Entity' section. 'Entity' sectionEntity TableEntity TableEntity TableEntity

Name

Type

Definition

Note

E-mail

Dependent

Договор

Dependent

Клиент

Independent

Реквизиты

Dependent

телефон

Dependent

Условия

Independent

Услуги

Dependent

Relationship

. 'Relationship' section. 'Relationship' section. 'Relationship' sectionRelationship TableRelationship TableRelationship TableRelationship

Parent to Child Phrase

Type

Definition

имеет

Identifying

имеет

Identifying

имеет

Identifying

имеет

заключает

Identifying

получает

Identifying

зависит от

Non-identifying

Страницы: 1, 2


© 2010 РЕФЕРАТЫ