Постановка задачи
Необходимо разработать курсовой проект на тему: «Система управления менеджментом и маркетингом КБ»
1. Произвести сбор необходимой литературы и анализ входной информации.
2. Определить состав главных и вспомогательных работ, происходящих процессов, информационных потоков, хранилищ данных и т.д.
3. Разработать эскизный проект будущей ИС.
4. Определить взаимосвязь модулей и потоков информации.
5. Реализовать эскизный проект с помощью инструментов моделирования BPwin 4.1 и Erwin 4.1.
6. Проверить согласованность всех используемых объектов системы и соблюдение наследования потоков, наличие описания комментариев к каждому объекту.
7. Создать отчет согласованности с выбранной методологией (для каждой нотации).
8. Провести генерацию отчетов по каждому пакету моделирования (BPwin 4.1 и Erwin 4.1.) в форматах HTML и RTF согласно к требованию к курсовому проектированию: вариант в формате RTF включается к приложению в отчете по курсовому проектированию; вариант в формате HTML сдается на электронном носителе руководителю проекта.
9. Оформить пояснительную записку (в печатном и электронном виде) по разработанному курсовому проекту и представить ее руководителю.
Введение
Управление маркетингом является эффективным, если основывается на разносторонних и хорошо организованных исследованиях. Это обусловлено тем, что исследовательская функция маркетинга представляет фундамент всей деятельности предприятия.
Цель управления маркетингом — достижение не эпизодических, а стабильных результатов на достаточно длительный период времени, во всяком случае, не менее 5—10 лет. Любая производственная или торговая организация должна определить для себя главную задачу маркетинговой деятельности в конкретных цифрах, чтобы можно было проверить и оценить достигнутые результаты. Это могут быть общие объемы продаж, величина прибыли, самоокупаемость, возможность выполнения обязательств перед акционер») ми. Конкретизация цели особенно важна ввиду необходимости ведения контроля соотношения затрат на маркетинговые мероприятия и результатов коммерческой деятельности.
Управление маркетингом всегда должно носить комплексный характер, т. е., представлять собой систему действий по оценке собственных возможностей и конкурентоспособности сбываемых товаров, по анализу состояния и прогнозированию рынка, по регулированию изготовления и сбыта товаров, включая активное воздействие, как на производителей, так и на потребителей.
Маркетинговая деятельность предприятия и торговой организации должна всегда осуществляться на основе применения программно-целевого метода, по которому любое действие должно способствовать решению текущих и перспективных задач, а любая ситуация, возникшая на рынке, должна рассматриваться с точки зрения решения этих задач. Маркетинг должен стать идеологией организации управления предприятий и коммерческих фирм, нацеленных на внутренний или внешний рынок.
Чтобы уметь использовать различные методики маркетинговых исследований на практике, необходимо их наглядно представлять и, прежде всего, их назначение, направления и процедуру проведения. Корни маркетинговых исследований следует искать в маркетинге, в рынке, поскольку само понятие "исследования" без понятия маркетинга имело бы более обобщенную форму. Однако, основой маркетинговых исследований, как и просто исследований, является выявление и решение проблемы.
Маркетинг является формой управления, а управление само по себе является информационным процессом, который без информации перестает существовать. Это в свою очередь и предопределяет место маркетинговых исследований, как одной из наиболее важных составляющих маркетинговой деятельности на всех ее этапах.
BPwin - мощный инструмент моделирования с возможностью анализа, документирования и корректирования бизнес процессов. Он поможет устранить лишние или неэффективные операции, уменьшить издержки, повысить гибкость и улучшить уровень обслуживания заказчика.
В модели BPwin, мы можем четко задокументировать важные позиции, такие как необходимые операции, проследить, как они выполняются и какие необходимы для этого ресурсы.
Модель BPwin обеспечивает интегрированное изображение того, как работает наша организация.
В данном курсовом проекте необходимо с помощью инструментальной среды BPwin автоматизировать систему управления менеджментом и маркетингом КБ. Не смотря на сложность реализуемой работы этот пакет программ позволяет наилучшим образом отобразить все этапы оперативного планирования.
1
Исследование предметной области
Маркетинг — это деятельность коммерческого банка по формированию своего позиционно-деятельностного поведения на рынке, основывающегося на экспертно-аналитическом (рефлективном) отслеживании процессов продвижения и обращения товаров в рамках осуществления конкретной ценовой политики под влиянием факторов внешней и внутренней среды для достижения максимально возможных результатов. При этом рыночная ситуация развивается в условиях риска и неопределенности.
Управление маркетингом — это целенаправленная деятельность коммерческого банка по регулированию своей позиции на рынке посредством планирования, организации, учета, контроля исполнения каждой фазы позиционно-деятельностного поведения коммерческого банка с учетом влияния закономерностей развития рыночного пространства, конкурентной среды для достижения прибыльности и эффективности деятельности субъекта на рынке.
Маркетинг — это в первую очередь не предмет изучения рынка, а взгляд на рынок, на систему рыночного поведения компании.
В управлении маркетингом целесообразно различать следующие основные функции:
1) планирование маркетинга;
2) организация осуществления маркетинговых стратегий и маркетинговых программ;
3) учет и контроль маркетинговой деятельности;
4) экспертное отслеживание и регулирование позиционно-деятельностного поведения коммерческого банка на рынке
Принципы управления маркетингом — это руководящие правила, вытекающие из действия объективных экономических законов и закономерностей развития рынка, его конкурентного проявления в условиях риска и неопределенности.
К принципам, определяющим и ситуационно-регулирующим деятельность коммерческого банка на рынке, относят:
1.1. Принцип управленческого риска;
1.2. Принцип организационного поведения;
1.3. Принцип инструментарного обеспечения руководства;
1.4. Принцип предпринимательского риска;
1.5. Принцип формирования потребительских предпочтений.
К принципам, уточняющим стратегии и цели поведения, относятся:
5.1. Принцип самооценки и саморегулирования;
5.2. Принцип рефлективного поведения;
5.3. Принцип равноправного партнерства;
5.4. Принцип конкурентного преимущества;
5.5. Принцип свободного предпринимательства.
Особенностью этих двух подгрупп принципов является возможность доопределения принципов, оценивающих ситуацию и регулирующих эту ситуацию в конкретной рыночной среде, которое позволяет доуточнять свои действия посредством группы принципов, доуточняющих стратегию компании.
Доуточнение стратегических целей и разработка программ развития компании происходят через сопоставление данных, полученных в результате исследований как внутренней, так и внешней среды компании, фиксацию изменений, происходящих в этих средах, и сопоставление полученных данных с информационными показателями прошлых периодов. Создание информационных баз данных — одно из проявлений применения системы принципов управления маркетингом, обусловливающих комплексность и синтетичность управленческого воздействия.
Так, принцип управленческого риска, дающий правила оценки и осмысления важности определения уровня риска и принятия решения по его преодолению, прежде всего путем самокоррекции и саморегулирования, позволяет руководству коммерческого банка не только использовать оценки того риска, который необходим для принятия решений по усилению позиций коммерческого банка на рынке, но и выявить слабые и сильные стороны, как самой компании, так и ее конкурентов.
В качестве элементов структуры управления маркетингом выступают менеджеры и работники коммерческого банка, специализирующиеся в маркетинговой деятельности; структуры и виды организационного управления; форма организации структурной политики маркетингового управления. Каждый элемент маркетингового управления имеет иерархическое построение и выполняет самостоятельные функции:
1) по анализу рынка;
2) по разработке стратегии, определяющей цели маркетинговых действий по продукту или территориальному сегменту рынка.
Структура управления маркетингом характеризует статику его управления. Динамику отражает сам процесс управления маркетингом.
Процесс управления маркетингом представляет собой совокупность последовательных действий для достижения поставленных целей. Его можно охарактеризовать с двух позиций. С точки зрения организации процесс управления маркетингом представляет собой совокупность действий коммерческого банка на рынке, направленных на обеспечение корректирующего поведения в зависимости от проявления факторов внешней среды, а также оценки границ риска, которые фирма должна преодолеть, чтобы принять маркетинговое решение или отказаться от него, учитывая собственные стратегии поведения.
Технология процесса управления маркетингом отображает совокупность операций и процедур, выполняемых работниками маркетинговых служб в определенной последовательности. Она включает в себя:
1) сбор и анализ экспертной информации о поведении рынка и конкурентов на нем;
2) позиционирование стохастических и динамических процессов на рынке;
3) моделирование психологических реакции поведения потребителей на рынке с последующим моделированием управленческих решений, направленных на уточнение или формулирование новых стратегий развития текущих рынков, проникновение на рынок, выбор продуктовой стратегии, стратегий роста для новых рынков, стратегических альянсов и консолидации, стратегий диверсификации и др.
Контроль маркетинга осуществляется на различных этапах с помощью отдельных элементов контрольно-аналитической системы. Она включает:
• ситуационный анализ — предварительный аналитический этап маркетингового планирования, преследующий цель определить положение предприятия на рынке. Используется анализ составляющих внешней и внутренней среды маркетинга в форме ответов на заранее подготовленные группы вопросов;
• контроль маркетинга — заключительный этап маркетингового планирования, преследующий цель выявить соответствие и результативность выбранной стратегии тактики реальным рыночным процессам. Осуществляется в виде стратегического, текущего контроля и контроля прибыльности с использованием стандартизированных форм;
• ревизия маркетинга — процедура пересмотра или существенной корректировки стратегии и тактики маркетинга в результате изменений условий как внешнего, так и внутреннего характера. Проводятся соответствующие рас: четы и оценки;
• аудит маркетинга — анализ и оценка маркетинговой функции предприятия. Осуществляется специалистами в форме независимой внешней проверки всех элементов системы маркетинга. Строится на общих принципах аудита' направленных на выявление упущенных выгод от неадекватного использования маркетинга на предприятии. Представляет собой новое направление в области маркетингового консультирования. Использует общепринятые процедуры управленческого консультирования (диагностика, прогноз и т.д.).
Стратегический контроль представляет собой оценку стратегических решений маркетинга с точки зрения их соответствия внешним условиям деятельности предприятия.
Оперативный (или текущий) контроль направлен на оценку достижения поставленных маркетинговых задач, выявление причин отклонений, их анализ и корректировку. Оперативно контролируются следующие показатели:
• объем продаж (сопоставление факта и плана);
• доля рынка (изменение конкурентного положения);
• отношение потребителей к предприятию и его продукции (обследования, конференции, экспертиза и др.). Проверяется также эффективность использования финансовых средств, выделенных на маркетинговые мероприятия, например: число торговых сделок относительно проведенных коммерческих переговоров, доля административных расходов в объеме продаж, затраты на рекламу и узнаваемость потребителем продукции предприятия и т.д. Разрабатываются дополнительные меры по повышению эффективности конкретных маркетинговых действий.
Контроль прибыльности представляет собой проверку фактической прибыльности по различным товарам, рынкам, группам потребителей или клиентов, каналам распределения и другим как результат реализации плана маркетинговых мероприятий.
При контроле прибыльности различают прямые и косвенные затраты на маркетинг. Прямые затраты — это затраты, которые могут быть отнесены непосредственно к отдельным элементам маркетинга: расходы на рекламу, комиссионные торговым агентам, проведение анкетных обследований, заработная плата работников службы маркетинга, оплата привлекаемых экспертов и специалистов и др. Такие затраты закладываются в бюджет маркетинга по соответствующим направлениям.
Косвенные затраты — это затраты, которые, сопутствуют маркетинговым мероприятиям: аренда помещений, транспортные расходы, развитие технологических процессов и т.п. Такие затраты непосредственно в бюджет маркетинга не закладываются, но при контроле могут при необходимости учитываться.
Финансовый менеджмент в коммерческом банке — это управление процессами формирования и использования денежных ресурсов. Он тесно связан с организационно-технологическим менеджментом — управлением банковскими подразделениями, их взаимоотношениями в различных процессах банковской деятельности, в том числе управлением персоналом банка. Наряду с проблемами финансового, организационно-технологического характера в коммерческом банке большое значение имеют проблемы информационного и логико-аналитического обеспечения финансового менеджмента коммерческого банка, оптимизации деятельности коммерческого банка как хозяйствующего субъекта и оптимизации технологических процессов и организационных структур. Последние относятся к проблемам системного анализа (исследования операций, информатики).
Цели и задачи финансового менеджмента в коммерческом банке — определение рациональных требований и методических основ построения оптимальных организационных структур и режимов деятельности функционально-технологических систем, обеспечивающих планирование и реализацию финансовых операций банка и поддерживающих его устойчивость при заданных параметрах, планирование финансовой деятельности банка и управление процессами привлечения и размещения денежных средств.
Объект деятельности финансового менеджмента в коммерческом банке— процессы исследования финансовых операций банка и управления потоками денежных средств банковской клиентуры.
Предмет деятельности финансового менеджмента в коммерческом банке — разработка и использование систем и методик рационального планирования и реализации финансовых операций (процессы привлечения и размещения денежных средств).
Цель финансового менеджмента в коммерческом банке — определение рациональных требований и методических основ построения оптимальных организационных структур и режимов работы функционально-технологических систем, обеспечивающих планирование и реализацию финансовых операций банка и поддерживающих его устойчивость при заданных параметрах, направленных на приращение собственного капитала (акционерного капитала) или прибыли при условии сохранения стабильности и устойчивости коммерческого банка.
Для реализации целей финансового менеджмента необходимо определить основные функции подсистемы подразделений коммерческого банка. К этим функциям подсистемы относятся:
1. Стратегическое планирование — определение перспективных финансовых задач и разработка программы эффективных действий, нацеленных на выполнение этих задач. Задача — данная в определенных условиях (например, в проблемной ситуации) цель деятельности, которая должна быть достигнута преобразованием этих условий согласно определенной процедуре.
2. Моделирование — использование совокупности методов, технологий и инструментальных средств для подготовки информации, способной убедить высшее руководство в эффективности предлагаемых проектов и целесообразности предлагаемых действий, а также для оценки текущего и прогнозного состояния объекта управления. Модель — материальный объект или знаковая система, имитирующие структуру или функционирование исследуемого объекта.
3. Оперативное планирование — определение рациональных способов решения текущих финансовых задач с учетом необходимости достижения перспективных финансовых целей банка.
4. Мониторинг — сбор информации о состоянии объекта управления и окружающей среды.
5. Диагностика — оценка соответствия текущих значений параметров, характеризующих состояние объекта, плановым показателям на данный момент времени.
6. Цель управления — обеспечение надежности объекта управления.
Отсюда вытекает третья особенность и вторая предметная область финансового менеджмента в коммерческом банке — создание продуктового ряда банка. В целях дальнейшей идентификации предметной области финансового менеджмента рассмотрим понятие "банковская операция" и его взаимосвязь с понятиями "банковский продукт" и "банковская услуга".
7. Банковский продукт — способ оказания услуг клиенту банка (форма отношений "банк-клиент"); регламент взаимодействия служащих банка с клиентом при оказании услуги, т.е. комплекс взаимосвязанных организационных, информационных, финансовых и юридических мероприятий, объединенных единой технологией обслуживания клиента.
8. Банковская операция — система согласованных по целям, месту и времени действий, направленных на решение поставленной задачи по обслуживанию клиента.
9. Банковская услуга — форма удовлетворения потребности (в кредите, расчётно-кассовом обслуживании, гарантиях, покупке-продаже и хранении ценных бумаг, иностранной валюты и т.д.) клиента банка.
10. Продуктовый ряд банка — банковская продукция.
11. Простой продукт — продукт, который реализуется одним функциональным подразделением банка путем оказания одной услуги клиенту.
12. Сложный продукт — продукт, в реализации которого могут быть задействованы несколько подразделений банка в течение длительного времени путем оказания комплексной услуги клиенту.
Под развитием продуктового ряда понимается следующий механизм расширения продуктового ряда банка:
а) выявление потребностей клиентов в новых банковских услугах;
б) разработка постановки задачи по созданию продукта, реализация которого обеспечивает оказание требуемой услуги;
в) разработка регламента оказания требуемой услуги;
г) разработка методики информационного обеспечения процесса оказания услуги;
д) решение организационных вопросов по созданию рабочей группы (в случае необходимости) для оказания услуги;
е) решение вопросов по оценке стоимости оказания услуги;
ж) решение вопросов, связанных с материальным стимулированием исполнителей услуги и разработчиков продукта;
з) разработка комплекса документации и договора с заказчиком, регламентирующих оказание услуги.
По целевому назначению можно различать следующие классы операций:
— пассивные операции — аккумулирование денежных ресурсов для предоставления банковских услуг;
— активные операции — использование собственных и привлеченных средств для получения текущих и будущих доходов;
— посреднические операции — обслуживание клиентов за комиссионное вознаграждение.
Банковская триада
— сочетание трех понятий "продукт — операция — услуга".
Продукт
— регламент (документально оформленная упорядоченная совокупность правил) выполнения операции по обслуживанию клиента.
Операция
— упорядоченная совокупность действий по удовлетворению заказанной потребности (обслуживанию) клиента.
Услуга
— результат обслуживания клиента (выполнения операции).
По степени сложности можно выделить три класса триад — элементарные, комбинированные, интегрированные.
2 Описание модели функционирования ИС
2.1 Анализ возможностей методологии и инструментальных средств проектирования заданной ИС
Рассматриваемые case-средства ERwin и BPwinбыли разработаны фирмой Logicworks. После слияния в 1998 году LogicworkscPLATINUMtechnology они выпускаются под логотипом PLATINUMtechnology. Для проведения анализа и реорганизации бизнес-процессов PLATINUMtechnology предлагает сase-средство верхнего уровня BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlowDiagram) и DFD (DataFlowDiagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS, т.е. «как есть») и идеального положения вещей – того, к чему нужно стремиться (модель TO-BE, т.е. «как будет»). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром, после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно. Затем каждая система разбивается на более мелкие и т.д. до достижения нужной степени подробности. После каждого сеанса декомпозиции производится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Модель может содержать четыре типа диаграмм:
- контекстную диаграмму
- диаграмма декомпозиции;
- диаграмма дерева узлов;
- диаграмма только для экспозиции (FEO).
Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия компонентов системы.
На основе модели BPwin можно построить модель данных. Для построения модели данных PLATINUMtechnology предлагает мощный и удобный инструмент – ERwin, хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, PLATINUMtechnology предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели – механизм двунаправленной связи BPwin-ERwin. ERwin имеет два уровня представления модели: логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого.
2.2 Контекстная диаграмма
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Контекстная диаграмма состоит из одной работы, которая называется «Система управления менеджментом и маркетингом КБ». Взаимодействие работы с внешним миром описывается в виде стрелок, которые представляют собой некую информацию и именуются существительными. В данной работе описаны стрелки типа вход (Input), «информация о сотрудниках» и «информация по клиентам», они представляют собой входную информацию. Стрелка типа выход (Output), «документация и договора» содержит в себе выходную информацию. Стрелка «маркетинговый отдел» является стрелкой типа механизм (Mechanizm) и входит в нижнюю грань работы. Стрелки «информация о конъюнктуре рынка», «цель и стратегия управления» являются стрелками типа управление (Control), входят в верхнюю грань работы и показывает правила, процедуры, которыми руководствуется работа «Система управления менеджментом и маркетингом КБ».
Контекстная (корневая) работа имеет номер А-0(рис. 1)
2.3 Диаграммы декомпозиции в методологии
IDEF
0
Основной из трех методологий, поддерживаемых BPwin, является IDEF0, оно относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем.
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.
Рис.1 Контекстная диаграмма
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекстную диграмму входит определение субъекта моделирования, цели и точки зрения на модель.
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. Диаграммы декомпозиции содержат родственные работы, т.е. работы, имеющие общую родительскую работу. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т.д. до достижения нужного уровня подробности описания системы.
Декомпозиция контекстной диаграммы имеет номер А0 (рис.2). Эта декомпозиция состоит из следующих основных работ «Управление маркетинговой деятельностью КБ», «Управление финансовым менеджментом КБ».
Рис.2 Диаграмма декомпозиции А0
Декомпозиция работы «Управление маркетинговой деятельностью КБ» имеет номер А1 (рис.3) и состоит из следующих работ:
- планирование маркетинга
- организация осуществления маркетинговых стратегий и программ
- учет и контроль маркетинговой деятельности
Рис.3 Диаграмма декомпозиции
«Управление маркетинговой деятельностью КБ»
А1
Декомпозиция работы «Управление финансовым менеджментом КБ»
имеет номер А2 (рис.4) которая состоит из следующих работ: планирование, информация о конъюнктуре рынка, создание продуктового ряда.
Декомпозиция работы «Планирование» А2.1. (рис.5) будет состоять из следующих работ:
- Стратегическое планирование
- Моделирование
- Оперативное планирование
Рис.4 Диаграмма декомпозиции «Управление финансовым менеджментом КБ» А2
Рис 5. Диаграмма декомпозиции «Планирование» А2.1
Диаграмма декомпозиции «Создание продуктового ряда» А2.3 (рис.6) включает в себя следующие работы: выбор вида услуги, оказание услуги, оформление документации и договоров.
Рис.6 Диаграмма декомпозиции «Создание продуктового ряда» А2.3
2.4 Диаграммы декомпозиции в методологии
DFD
Диаграммы потоков данных используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ, их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
· функции обработки информации (работы);
· документы (стрелки), объекты, сотрудников или отделы;
· информации;
· внешние ссылки(external references);
· таблицы для хранения документов(хранилища данных).
Работы.
Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота. Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы. Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.
В BPwinдля построения диаграмм потоков данных используется нотация Гейна-Сарсона. В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов, хранение объектов, поставка и распространение объектов. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.
В диаграмме потоков данных (рис.7) под названием «Оформление документации и договоров» показаны хранилища данных под названиями «Услуги», «Договор», «Клиент», показана внешняя ссылка «Сведения о договоре». Данная диаграмма состоит из следующих работ:
1. Составление договора;
2. Утверждение договора;
3. Обсуждение и согласование частей договора.
Базы данных используемые в данной работе:
Таблица 1. Базы данных
Имя БД (
Name
)
|
Определение
(Definition)
|
Услуги |
Сведения об услугах |
Договор |
Сведения о договоре |
Клиент |
Сведения о клиенте |
Таблица 2. База данных Услуги
Имя поля |
Тип |
Краткое описание |
Код_услуги |
Цифры |
Код_услуги |
Дата_оказания_услуги |
Дата |
Дата_оказания_услуги |
Назв_услуги |
Символы |
Назв_услуги |
Стоим_услуги |
Цифры |
Стоим_услуги |
Таблица 3. Договор
Имя поля |
Тип |
Краткое описание |
Номер_ договора |
Цифры |
Номер_ договора |
Дата _заключения _договора |
Дата |
Дата _заключения _договора |
Сумма _вложений |
Цифры |
Сумма _вложений |
Назв_проекта |
Символы |
Назв_проекта |
Срок_ договора
Условия_ договора
|
Цифры
Символы
|
Срок_ договора
Условия_ договора
|
Таблица 4. Клиент
Имя поля |
Тип |
Краткое описание |
ФИО_клиента |
Символы |
ФИО_клиента |
Адрес _клиента |
Символы |
Адрес _клиента |
ИНН_клиента |
Цифры |
ИНН_клиента |
E-mail |
Символы |
E-mail |
Телефон |
Цифры |
Телефон |
Рис. 7 Диаграмма
DFD
А2.3.3
2.5 Диаграммы декомпозиции в методологии
IDEF
3
Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также Workflowdiagramming, методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии, например порядок определения страхового риска. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 – это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Методология IDEF3 содержит следующие основные элементы:
· Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.
· Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ.
В IDEF3 различают три типа связей:
· Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
· Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.
Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:
· Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.
· Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.
На диаграмме под номером А2.3.1.1 «Выбор вида услуги», (рис.8) показаны следующие виды работ:
1. Сбор данных и анализ информации для выбора вида услуги;
2. Выбор вида банковской операции;
3. Выбор продуктового ряда банка;
4. Выбор простого продукта;
5. Выбор сложного продукта;
6. Выбор банковской услуги;
Также использована ссылка «Услуги» и «Мониторинг внешней среды» и перекресток типа AsynchronousOR. Перекресток типа АsynchronousOR под номером J1 показывают, что один или несколько процессов должны быть запущены, и перекресток типа АsynchronousOR под номером J2 показывает, один или несколько процессов должны быть завершены.
Каждая работа IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Для создания сценария необходимо из диаграммы декомпозиции А2.3.1.1 удалить работы, стрелки и перекрестки, не входящие в сценарий. На рис. 9 показана диаграмма сценария под номером А2.3.1.2 созданная на основе диаграммы IDEF3 «Выбор вида услуги»
Рис.8 Диаграмма
IDEF
3
«Выбор вида услуги» А2.3.1.1
Рис.9 Диаграмма сценария А2.3.1.2
2.6 Функционально-стоимостной анализ
ABC - методика функционально-стоимостного анализа для идентификации истинных генераторов затрат на предприятии (организации). Методика предназначена для определения общей стоимости реализации целевого технологического процесса и представляет собой соглашение об учете, используемое для определения как затрат, возникающих на каждом этапе процесса, так и суммарных затрат.
BBPwin модуль ABC применяется для:
· понимания происхождения выходных затрат и определения их стоимости;
· определение действительной стоимости производства продукта;
· определения требуемых ресурсов;
· определение действительной стоимости поддержки клиента;
· оценки и анализа затрат на осуществление различных видов деятельности;
· облегчения выбора оптимальной модели процесса при реорганизации деятельности предприятия;
· выделения наиболее дорогостоящих операций для их реинжиниринга.
Применение модуля ABCи имеющихся в BPwin средств подготовки отчетов позволяет обеспечить корпоративную стратегию управления хозяйственной деятельностью.
ABC включает следующие основные понятия:
· объект затрат - цель существования функции процесса, т. е. основной выход. Стоимостью целевого технологического процесса будет являться суммарная стоимость всех объектов затрат. Результат расчета суммарной стоимости представляется на контекстной диаграмме;
· движитель затрат – входы и управления функции, определяющие ее существование и влияющие на срок ее действия;
· центры затрат – различные статьи расходов.
Функционально-стоимостной анализ проводится только при полностью созданной модели процесса, т. е. когда модель:
- последовательная – следует синтаксическим правилам IDEF0;
- корректная – полностью отражает процесс;
- полная – охватывает всю рассматриваемую область;
- стабильная – проходит цикл экспертизы без изменений.
Метод ABC может быть осуществлен в любой модели BPwin путем задания в объекте затрат применяемой валюты, как единицы измерения затрат, или назначения временного периода.
Для эффективного использования механизма стоимостного анализа сначала строится функциональная модель существующей организации работы – AS – IS (как есть). На основании этой модели анализируется существующие процессы, изучаются имеющиеся потоки данных, определяются возможность изменения их направления, и строится модель TO-BE , из которых по определенному авторским коллективом критерию выбирается лучшая.
Механизм поддержки ABC в BPwin, хотя и учитывает стоимость выполнения каждой работы, продолжительность каждой работы по времени и сколько раз необходимо выполнить работу в течение одного цикла бизнес-процесса, все же дает довольно грубые оценки и, к тому же требует, чтобы все диаграммы, для которых производится оценка, были выполнены в IDEF0.
Результаты функционально стоимостного анализа отображаются непосредственно на диаграммах. В левом нижнем углу прямоугольника блока может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения функции (диапазон измерения времени в списке Unitofmeasurement достаточен для большинства случаев – от секунд до лет).
Таблица 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
Диаграмма декомпозиции А0
F
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Диаграмма дерева узлов работы «Система управления менеджментом и маркетингом КБ» состоит из четырех уровней и будет иметь следующий вид:
Рис.12 Диаграмма дерева узлов
3 Информационная модель в нотации
IDEF
1.
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 Логическая модель в нотации
IDEF
1.
X
3.2.Физическая модель
Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД.
В ERwin также представлены два уровня физической модели: трансформационная модель и модель СУБД. Целью трансформационной модели является предоставление информации администратору. Модель СУБД транслируется из трансформационной модели. Являясь отображением системного каталога, ERD-диаграмма графически представляет структуру данных проектируемой ИС.
ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого.
Рис.16 Физическая модель в нотации
IDEF
1.
X
3.3 Генерация физической модели
Посредством Erwin можно также создавать и физические модели данных для различных СУБД. Для создания физической модели необходимо в окне создания новой модели выбрать тип создаваемой модели Logical/Physical и тип базы данных, в которой необходимо создать таблицы (Рис. 17). В данном курсовом проекте мы создадим физическую модель для СУБД BorlandC++Builder 6 в сервере БД – Paradox 7.
Рис. 17 Выбор типа модели
Далее создается модель из уже ранее существующей модели созданной в Erwin. Для начала перейдем на физический уровень данных (рис. 18).
Рис. 18. Выбор уровня данных
Затем, в панели инструментов нажимаем кнопку , в появившемся окне выбираем Modellevelcompare и указываем файл из которого необходимо импортировать данные (рис. 16)
Рис. 19. Импорт данных из существующей модели
В последующих окнах необходимо выбрать данные, настройки которые необходимо импортировать. Импорт таблиц и их строк осуществляется путем нажатия на кнопку Import
. Чтобы не импортировать не нужные данные, надо выбрать их из списка и нажать на кнопку Ignore
. Окно выбора данных представлено на рисунке 20.
Рис.20. Окно выбора импортируемых данных
После нажатия кнопки необходимо подтвердить появившийся запрос Erwin. Получившаяся модель представляет собой физическую модель для сервера БД Paradox 7 (рис. 21)
Рис. 21 Физическая модель
На данном этапе возможно изменить формат конечной БД, для этого необходимо щелкнуть по кнопке «Selecttargetserver» и в открывшемся окне Рис. 22выбрать необходимый тип. При нажатии на кнопку «ОК» модель преобразуется в тот тип, который мы выбрали.
Рис. 22
Target
Server
3.4
. Экспорт физической модели
Теперь необходимо построить таблицы на основе данной модели, для этого необходимо щелкнуть по кнопке «ForwardEngineer» или же Tools-> ForwardEngineer/SchemaGeneration… В результате чего откроется окно представленное на Рис. 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.
Список использованной литературы
1.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000.
2.
Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.
3.
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование нформационных систем: учебное пособие / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – 2-е изд., испр. М.: Интернет-Университет Информационных Технологий; БИНОМ.Лабора-тория знаний, 2008.–300с.
4.
Дубейковский В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? М.:ДИАЛОГ-МИФИ, 2004. – 464 с.
5.
Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник / Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. – М.: Финансы и статистика, 2001.
6.
Базы данных: Учебник для высших учебных заведений/ Под ред. проф. А.Д.Хомоненко. – СПб.: КОРОНА принт, 2000. – 416 с.
7.
Маклаков С.В. Моделирование бизнес процессов с AllFusion Process Modeler (BPWin 4.1). М.: ДИАЛОГ – МИФИ, 2004. – 240с.
8.
Маклаков С.В. BPWin, ERWin. CASE-средства разработки информационных систем. – М. ДИАЛОГ-МИФИ, 1999.
9.
Моделирование и анализ IDEF-технологии: практикум/ С.В.Черемных, И.О.Семенов, В.С.Ручкин. – М. Финансы и статистика, 2002. – 192 с.: ил.
10.
Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
11.
Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
Приложение 1
Отчет по модели
BPwin
на тему
«Автоматизированная система управления менеджментом и маркетингом КБ»
Зелфикарова Атира Зелфикаровна
Model
|
Model
|
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
|
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
|
Name
|
Definition
|
Cost
|
Раббочая сила |
Затраты на оплату рабочих |
70 503,00 |
Управление |
Затраты на управление, связанные с сотавлением графика работ |
39 800,00 |
Arrow
|
Arrow
|
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
|
Name
|
Definition
|
Договор |
Клиент |
Услуги |
Data Store
|
Data Store
|
Name
|
Number
|
Definition
|
Author
|
Status
|
Договор |
2 |
Зелфикарова А.З. |
WORKING |
Клиент |
3 |
Зелфикарова А.З. |
WORKING |
Услуги |
1 |
Зелфикарова А.З. |
WORKING |
Diagram
|
Diagram
|
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'.
Main Subject Area/Display1
Attribute
|
Attribute
|
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
|
Name
|
Author
|
Database Name
|
база |
Entity
|
Name
|
Type
|
Definition
|
Note
|
E-mail |
Dependent |
Договор |
Dependent |
Клиент |
Independent |
Реквизиты |
Dependent |
телефон |
Dependent |
Условия |
Independent |
Услуги |
Dependent |
Relationship
|
Parent to Child Phrase
|
Type
|
Definition
|
имеет |
Identifying |
имеет |
Identifying |
имеет |
Identifying |
имеет |
заключает |
Identifying |
получает |
Identifying |
зависит от |
Non-identifying |
|