Разработка бизнес-процессов

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение Тихоокеанский государственный университет

Факультет: Экономики и Управления

Кафедра: Экономики и менеджмента

Курсовая работа

по дисциплине: Планирование бизнеса

Разработка бизнес-процессов

Выполнила:

Паздников Р.А.

Проверила:

Аксюк Ольга Фёдоровна

Хабаровск 2015 г.



Введение

реинжиниринг проектирование бизнес

В современной практике моделирования управленческой и производственной деятельности для обозначения объектов моделирования принято использовать термин «бизнес-процесс» (businessprocess). В международном стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее время эти термины можно считать синонимами. Моделирование бизнес-процессов является важной составной частью проектов по реинжинирингу (реорганизации) бизнес-процессов и созданию крупномасштабных систем программного обеспечения (ПО). Отсутствие таких моделей является одной из главных причин неудач многих проектов. Однако даже наличие моделей не гарантирует успеха, поскольку существует ряд других серьезных причин, приводящих к неудачам:

отсутствие заинтересованности со стороны высшего руководства организации;

некорректная постановка целей проекта;

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

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

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

неэффективное применение инструментов моделирования.

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

Сложившаяся ситуация еще более усугубляется следующими обстоятельствами:

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

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

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



1. Бизнес-процесс, понятие, структура

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

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

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

основные процессы;

обеспечивающие процессы.

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

Бизнес-процессы можно также классифицировать по видам деятельности или составу работ (элементам процесса):

планирование деятельности (например, планирование производства готовой продукции);

осуществление деятельности - собственно выполнение работы (например, изготовление продукции);

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

контроль и анализ исполнения плана;

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

Существуют три вида бизнес-процессов:

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

Операционные -- бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг и Продажи.

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

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

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

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

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

1.2 Методы проектирования бизнес-процессов

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

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

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

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

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

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

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

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

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

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

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

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

Модель бизнес-процесса должна давать ответы на вопросы:

Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?

В какой последовательности выполняются эти процедуры?

Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?

Кто выполняет процедуры процесса?

Какие входящие документы/информацию использует каждая процедура процесса?

Какие исходящие документы/информацию генерирует процедура процесса?

Какие ресурсы необходимы для выполнения каждой процедуры процесса?

Какая документация/условия регламентирует выполнение процедуры?

Какие параметры характеризуют выполнение процедур и процесса в целом?

Существует множество нотаций, применяемых для моделирования бизнес-процессов, например:

- BPMN -- функциональная последовательность работ;

- EPC -- событийная последовательность работ;

- IDEF0 -- логическая последовательность работ.

- Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

- Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

- Прочие методологии.

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

Основные бизнес-процессы (например, маркетинг, производство, поставки и сервисное обслуживание продукции).

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

Бизнес-процессы управления.

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

Этапы описания бизнес-процессов:

Определение целей описания.

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

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

Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.

Построение организационной структуры процесса (отделы, участники, ответственные).

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

Управляющая информация входит в блок сверху.

Входная информация входит в блок слева.

Результаты выходят из блока справа.

Механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу. Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Общее число уровней в модели не должно превышать 5-6. Построение диаграмм начинается с представления всей системы в виде одного блока и дуг, изображающих интерфейсы с функциями вне системы. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. На таких диаграммах не указаны явно ни последовательность, ни время. Метод обладает рядом недостатков: сложность восприятия (большое количество дуг на диаграммах и большое количество уровней декомпозиции), трудность увязки нескольких процессов.

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

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

Типы связей IDEF3:

Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.

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

Нечеткое отношение (Relationship), пунктирная стрелка.

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

"И", блок со знаком &.

"Исключающее ИЛИ" ("одно из"), блок со знаком Х.

"ИЛИ", блок со знаком О.

Если действия "И", "ИЛИ" должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно - одной. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.

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

Так же, как и в других моделях, поддерживается декомпозиция.

Основными компонентами диаграмм потоков данных являются:

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

системы и подсистемы (например, подсистема по работе с физическими лицами);

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

накопители данных (абстрактные устройства для хранения информации);

потоки данных (на диаграмме - стрелки).

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

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

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

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

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

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

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

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

Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.

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

Основные объекты нотации eEPC:

Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, "запускающей" выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.

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

Организационная единица. Например, управление или отдел.

Документ. Отражает реальные носители информации, например, бумажные документы.

Прикладная система.

Кластер информации. Характеризует набор сущностей и связей между ними.

Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.

Логический оператор. Оператор "И", "ИЛИ" или исключающее "ИЛИ", позволяет описать ветвление процесса.

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

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



2. Проектная часть курсовой работы

2.1 Описание предметной области задачи

Функционирование организации по продаже канцелярских товаров: ООО "КТ" осуществляет продажу канцелярских товаров. Хранится следующая информация о предприятиях-клиентах: название, юридический адрес, телефон, руководитель, главный бухгалтер. Клиентами являются магазины, частные предприятия, кафе, туристические фирмы. Менеджер оформляет заказ, в котором указано наименование заказчика, дата заказа, наименование товара, количество товара, а так же отметки о выполнении\не выполнении заказа, и о выполнении оплаты заказчиком. Заключается двусторонний договор. После выполнения заказа составляется отчет в разрезе клиента, в котором указывается наименование клиента, дата заказа, наименование, количество и цена товара, и выводится общий итог по стоимости.

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

Цель проектирования ИС:

Потребность в создании ИС обусловлена необходимостью автоматизации деятельности фирмы.

Основные функции, требующие автоматизации:

учет клиентов и заказов;

учет договоров.

Используемые документы и их описание:

Товар - внутренний документ, содержащий информацию о наличии товара, о его цене. Функция: учет товара.

Клиент - внутренний документ, содержащий информацию о клиенте. Функция: учет клиентов.

Заказ - внутренний документ, содержит информацию обо всех заказах, сделанных клиентами. Функция: учет заказов.

Договор - исходящий документ. Функция: юридическое обоснование.

Отчет - внутренний документ, составляется на основе запроса по клиентам и товару.

2.3 Построение модели потоков данных (IDF0, DFD) в BPwin

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

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

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

На контекстной диаграмме А-0 отображена система управления процессом.

Report for Diagram: A-0, Организация процесса отгрузки товара.

Activity Name: Организация процесса отгрузки товара.

Link Name: Канцелярские принадлежности.

Link Name: Материалы.

Link Name: Услуги организации.

Link Name: Стандарты.

Link Name: Мнение эксперта.

Link Name: Персонал.

Link Name: Оборудование.

Link Name: Сведения о клиенте.

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

Report for Diagram: A0, Организация процесса отгрузки товара.

Activity Name: Комплектование набора товаров.

Activity Name: Обслуживание клиентов.

Link Name: Канцелярские принадлежности.

Link Name: Материалы.

Link Name: Услуги организации.

Link Name: Стандарты.

Link Name: Мнение эксперта.

Link Name: Персонал.

Link Name: Оборудование.

Link Name: Отгружаемый товар.

Link Name: Сведения о клиенте.

Следующие две диаграммы - это частные случаи декомпозиции подсистем рассматриваемого процесса. В них выделяются основные процессы. Ниже приведены отчеты по каждой из диаграмм. (А2, А23).

Report for Diagram: A2, Обслуживание клиентов.

Подсистемы:

Activity Name: Оформление "карточки" клиента.

Activity Name: Оформление пакета документов.

Activity Name: Предоставление услуги.

Потоки данных:

Link Name: Услуги организации.

Link Name: Стандарты.

Link Name: Мнение эксперта.

Link Name: Персонал.

Link Name: Оборудование.

Link Name: Отгружаемый товар.

Link Name: Пакет документов клиента.

Link Name: Готовый пакет документов.

Link Name: Карточка клиента.

Link Name: Документация.

Link Name: Сведения о клиенте.

Link Name: Карточка документов клиента.

Хранилища:

Data Store Name: База клиентов.

Data Store Name: Хранилище оформленных документов.

Report for Diagram: A23, Предоставление услуги.

Подсистемы:

Activity Name: Прием заявки.

Activity Name: Поиск заказанного товара.

Activity Name: Заполнение первичной документации.

Activity Name: Отгрузка товара.

Потоки данных:

Link Name: Услуги организации.

Link Name: Стандарты.

Link Name: Мнение эксперта.

Link Name: Персонал.

Link Name: Оборудование.

Link Name: Готовый пакет документов.

Link Name: Сведения о клиенте.

Link Name: Отложенные заявки.

Link Name: Заявка на товар.

Link Name: Первичная документация.

Link Name: Отчет об отгрузке.

Link Name: Заявка на склад.

Link Name: Документы на отгрузку.

Link Name: Отчет о наличии.

Link Name: Выполненная заявка.

Link Name: Отказ.

Хранилища:

Data Store Name: БД выполненных заявок.

Data Store Name: БД отложенных заказов.

Data Store Name: БД отчетов.

Внешние сущности:

External Name: Клиент.

2.4 Построение модели данных в ERwin

Erwin имеет два уровня представления данных: логический и физический.

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели логического уровня называются сущностями и атрибутами.

Рис. 1. Диаграмма ERD-уровень сущности



Рис. 2. Диаграмма ERD-уровень атрибутов

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

Рис. 3. Диаграмма ERD-физическая модель

Вторая задача - масштабирование. Существует реальная возможность создания физической модели под любую поддерживаемую ERwin СУБД на основе одной логической модели.



2.5 Создание базы данных

Создадим базу данных "Отгрузка товаров в разрезе клиентов" в СУБД MS Access. Основным назначением базы данных "Отгрузка товаров в разрезе клиентов" будет автоматизация функции по учету клиентов и заказов.

Рис. 4. Схема данных БД "Отгрузка товаров в разрезе клиентов"

Таблицы для хранения данных.

В соответствии со схемой данных БД "Отгрузка товаров в разрезе клиентов" имеет следующие таблицы:

Рис. 5. Таблицы БД "Отгрузка товаров в разрезе клиентов"

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



Рис. 6. Пример структуры таблицы "Договоры" в конструкторе

Формы для ввода информации.

Создадим формы для ввода информации. Например, для заполнения формы - Заказы, необходимо заполнение форм-справочников: формы - Товар и формы - Клиенты; а для формы Договоры, необходима форма-справочник: Справочник договоров.

Рис. 7. Пример форм-справочников: товар и клиенты

Рис. 8. Форма для оформления заявки на товар



Рис. 9. Форма для оформления договора

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

Рис. 10. Главная кнопочная форма БД "Отгрузка товаров в разрезе клиентов"

Запросы для создания отчетов



Рис. 11. Вкладка "Запросы" в окне БД "Отгрузка товаров в разрезе клиентов"

Для формирования отчета в разрезе клиента создадим запрос "Клиент запрос". Данный запрос предназначен для выбора клиентов, заказов и стоимости заказов за определенный промежуток времени (месяц).

Рис. 12. Запрос "Клиент запрос" в Конструкторе

Отчет.

Для формирования отчета в разрезе клиентов, создадим "Отчет_Клиенты" на основании запроса "Клиент Запрос".



Рис. 13. "Отчет_Клиенты", сформированный по запросу "Клиенты Запрос"

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

Заключение

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

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

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

1. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г.А. Титоренко, - М.: Компьютер, ЮНИТИ, 2004.

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

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

4. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. - М.: ДИАЛОГМИФИ, 2004.



Приложение

Контекстная диаграмма отгрузки товара

Диаграмма декомпозиции отгрузки товара



Диаграмма декомпозиции по работе с клиентами

Диаграмма декомпозиции системы предоставления услуг



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

Размещено на Allbest.ru

...