Проектирование информационной системы логистики
Содержание
1..... Характеристика
компании «ТК»
1.1 Краткая
характеристика деятельности компании
1.2 Цели
и задачи компании
1.3.. Организационная
структура «ТК»
2.. Документооборот
компании «ТК»
3..... Разработка
информационной модели компании «ТК»
3.1 Выбор
инструмента моделирования. ERWin
3.2 Основы
методологии IDEF1X
3.3.. Построение
модели данных компании в нотации IDEF
1X
4.. Разработка
функциональной структуры деятельности компании «ТК»
4.1 Выбор
инструмента моделирования. BPWin
4.2 Принципы
моделирования бизнес-процессов в нотации IDEF0
4.3.. Принципы
моделирования бизнес-процессов в нотации IDEF3
4.4 Построение
модели процессов верхнего уровня в нотациии IDEF0
.5 Построение
модели процессов нижнего уровня в нотациии IDEF3
5.. Рекомендации
по совершенствованию процесса грузоперевозок
6..... Вывод
1.
Характеристика компании «ТК»
.1 Краткая характеристика деятельности компании
В связи с быстрым темпом развития
рыночных отношений в России, перевозка грузов
<#"555367.files/image001.gif">
3. Разработка информационной модели компании
«ТК»
3.1 Выбор
инструмента моделирования. ERWin
ERwin Data Modeler (ранее: ERwin) позволяет
проектировать, документировать и сопровождать базы данных, хранилища данных и
витрины данных (data marts). Создав наглядную модель базы данных, можно
оптимизировать структуру БД и добиться её полного соответствия требованиям и
задачам организации. Визуальное моделирование повышает качество создаваемой
базы данных, продуктивность и скорость её разработки.
Руководители проектов могут с помощью ERwin Data
Modeler тщательно задокументировать структуру БД, получить отчеты презентационного
качества и обеспечить эффективное управление проектом, используя среду для
совместного проектирования AllFusion Model Manager (ранее: ModelMart).
Поскольку ERwin Data Modeler поддерживает работу
с БД на физическом уровне, учитывая особенности каждой конкретной СУБД,
администраторы БД могут с его помощью максимально повысить производительность
информационной системы. Разработчики с помощью ERwin Data Modeler могут
сначала, используя визуальные средства, описать схему БД, а затем автоматически
сгенерировать файлы данных для выбранной реляционной СУБД (прямое
проектирование). Автоматически генерируются также триггеры, обеспечивающие
ссылочную целостность БД. ERwin Data Modeler поддерживает нотации
проектирования данных IDEF1х, IE и Dimensional.
Пользователь описывает структуру данных
визуально. Он задает служащие прообразами реляционных таблиц сущности с их
атрибутами и при помощи мыши "натягивает" между ними связи, которые
являются прототипами реляционных отношений.Data Modeler позволяет по уже существующим
файлам БД восстанавливать логическую структуру данных. Это называется обратным
проектированием. Оно позволяет, во-первых, переносить структуру БД (но не
данные!) из одной СУБД в другую и, во-вторых, исследовать старые проекты. Этот
процесс наиболее распространен при переходе с одной технологии на другую (с
файл-сервер на клиент-сервер), а также при смене сервера БД. На основе модели
данных предоставляется возможность создавать отчеты, которые позволяют
существенно упростить процесс документирования технического проекта.
3.2 Основы
методологии IDEF1X
X является методом для разработки реляционных
баз данных и использует условный синтаксис, специально разработанный для
удобного построения концептуальной схемы.
Концептуальной схемой мы называем универсальное
представление структуры данных в рамках коммерческого предприятия, независимое
от конечной реализации базы данных и аппаратной платформы. Будучи статическим
методом разработки, IDEF1X изначально не предназначен для динамического анализа
по принципу "AS IS", тем не менее, он иногда применяется в этом
качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее
целесообразно для построения логической структуры базы данных после того, как
все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и
решение о внедрении реляционной базы данных, как части корпоративной
информационной системы, было принято.
Сущность в IDEF1X описывает собой совокупность
или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от
друга по одному или нескольким признакам. Каждый экземпляр является реализацией
сущности. Таким образом, сущность в IDEF1X описывает конкретный набор
экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет
собой абстрактный набор информационных отображений реального мира. Примером
сущности IDEF1X может быть сущность ГРУЗОПОЛУЧАТЕЛЬ, которая представляет собой
всех грузополучателей предприятия, а один из них, скажем, ООО «Дуб» , является
конкретной реализацией этой сущности.
Сущность описывается в диаграмме IDEF1X
графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий
собой сущность, разделяется горизонтальной линией на часть, в которой
расположены ключевые поля и часть, где расположены неключевые поля.
Сущность в нотации IDEF1X
Верхняя часть называется ключевой областью, а
нижняя часть областью данных. Ключевая область объекта ГРУЗОПОЛУЧАТЕЛЬ содержит
поле «ID
Грузополучателя», в области данных находятся поля «Наименование организации»,
«Фамилия», «Имя» , «Отчество» контактного лица и т.д.
Ключевая область содержит первичный ключ для
сущности. Первичный ключ - это набор атрибутов, выбранных для идентификации
уникальных экземпляров сущности. Атрибуты первичного ключа располагаются над
линией в ключевой области. Как следует из названия, неключевой атрибут - это
атрибут, который не был выбран ключевым. Неключевые атрибуты располагаются под
чертой, в области данных.
Связи в IDEF1X представляют собой ссылки,
соединения и ассоциации между сущностями. Связи это суть глаголы, которые
показывают, как соотносятся сущности между собой. Ниже приведен ряд примеров
связи между сущностями:
Сотрудник <оформляет> разные Документы
Заказ <содержит> несколько Товаров
Во всех перечисленных примерах взаимосвязи между
сущностями соответствуют схеме один ко многим. Это означает, что один экземпляр
первой сущности связан с несколькими экземплярами второй сущности. Причем
первая сущность называется родительской, а вторая - дочерней. В приведенных примерах
глаголы заключены в угловые скобки.
Родительская и дочерняя сущности в нотации IDEF1X
Связи многие ко многим обычно используются на
начальной стадии разработки диаграммы, например, в диаграмме зависимости
сущностей и отображаются в IDEF1X в виде сплошной линии с точками на обоих
концах.
Виды связей в нотации IDEF1X
В IDEF1X концепция зависимых и
независимых сущностей усиливается типом взаимосвязей между двумя сущностями.
Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в
результате, создавал зависимую сущность), то можете создать идентифицирующую
связь между родительской и дочерней сущность. Идентифицирующие взаимосвязи
обозначаются сплошной линией между сущностями.
Неидентифицирующие связи,
являющиеся уникальными для IDEF1X, также связывают родительскую сущность с
дочерней. Неидентифицирующие связи используются для отображения другого типа
передачи атрибутов внешних ключей - передача в область данных дочерней сущности
(под линией).
Неидентифицирующие связи
отображаются пунктирной линией между объектами. Так как переданные ключи в
неидентифицирующей связи не являются составной частью первичного ключа дочерней
сущности, то этот вид связи не проявляется ни в одной идентифицирующей
зависимости. В этом случае и ЗАКАЗ, и ПУТЕВОЙ ЛИСТ рассматриваются как
независимые сущности.
3.3 Построение
модели данных компании в нотации IDEF
1X
Построение модели данных начинается с выделения
сущностей данной предметной области. В нашем случае были выделены следующие
сущности:
· Грузоотправитель - организация
(физическое лицо), которая (ый) имеет груз на перевозку;
· Грузополучатель - организация
(физическое лицо), которой (ому) предназначается груз;
· Персонал - сотрудники компании
(здесь уместно разделение на должности, в сущности Водитель и Менеджер);
· Транспортное средство - парк
автомобилей компании;
· Договор - документ, подтверждающий
соглашение о грузоперевозке;
· Путевой лист - документ, согласно
которому совершается грузоперевозка (маршрут, точка отправление/прибытия);
· Заказ - перечень груза, который
необходимо доставить грузополучателю;
· Товарно-транспортная накладная и
Счет-фактура - документы, сопровождающие груз в пути. У каждого из этих
документов есть перечни грузов на доставку, они выделены в сущности
ТТН_Номенклатура груза и СФ_Номенклатура груза.
Далее рассмотрим некоторые связи между
сущностями:
Ø Персонал - Договор: В оформлении
договора принимает участие менеджер по работе с клиентами.
Ø Грузоотправитель - Договор:
грузоотправитель также участвует в оформлении договора.
Ø Договор - Заказ: Указывается на
основании какого договора сформирован заказ.
Ø Заказ - Путевой лист: указывается на
основании какого заказа оформлен путевой лист.
Ø Транспортное средство - Путевой
лист: Транспортное средство для перевоза груза.
Ø Персонал - Путевой лист: Указывается
водитель транспортного средства.
Ø Заказ - Заказ_Номенклатура груза:
Перечень груза на доставку.
Ø Заказ - ТТН и Заказ - СФ: Указание в
сопровождающих документах на основании какого заказа они сформированы.
Ø Грузополучатель - Заказ: Указание
лица получающего груз.
4. Разработка функциональной структуры
деятельности компании «ТК»
4.1 Выбор
инструмента моделирования. BPWin
Для проведения анализа и реорганизации
бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня - BPwin,
поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow
Diagram) и DFD (DataFlow Diagram). Основной из трех методологий, является
IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс
пользователя, дающий возможность аналитику создавать сложные модели при
минимальных усилиях.автоматизирует задачи, связанные с построением моделей
развития, обеспечивая семантическую строгость, необходимую для гарантирования
правильности и непротиворечивости результатов. Это достигается применением в
BPwin следующих методологий: IDEF0, DFD и IDEF3.
Но прежде чем заниматься этой, более сложной,
задачей, необходимо, действительно, по крайней мере "пересчитать" все
элементы бизнеса, то есть создать оргштатную структуру компании. Следующий этап
- попытаться графически изобразить взаимосвязи между различными элементами
ранее определенной структуры.
Все работы модели нумеруются. Номер состоит из
префикса и числа. Может быть использован префикс любой длины, но обычно
используют префикс А. Контекстная (корневая) работа дерева имеет номер А0.
Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции
нижнего уровня имеют номер родительской работы и очередной порядковый номер,
например работы декомпозиции A3 будут иметь номера А3.1 А3.2, АЗ.З, А3.4 и т.
д.
В результате дополнения диаграмм, IDEFO диаграммами
DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом
описывает все стороны деятельности предприятия. Иерархию работ смешанной модели
можно увидеть в окне Model Explorer. Работы в нотации IDEFO изображаются
зеленым цветом, DFD - синим.так же как и локальные интегрированные системы,
практически не позволяют выполнить комплексный анализ систем, который в большей
или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их
помощью можно разрабатывать локальные ИС или небольшие подсистемы,
предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет
необходимости в комплексном анализе предприятия. Типичная сфера использования
малых интегрированных средств - решение задач так называемой “кусочной” автоматизации
предприятия.
4.2 Принципы
моделирования бизнес-процессов в нотации IDEF0
Основу методологии IDEFO составляет графический
язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой
совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая
диаграмма является единицей описания системы и располагается на отдельном
листе.модель предполагает наличие четко сформулированной цели единственного
субъекта моделирования и одной точки зрения.
Модель может содержать четыре типа диаграмм:
· контекстную диаграмму (в каждой
модели может быть только одна контекстная диаграмма);
· диаграммы декомпозиции;
· диаграммы дерева узлов;
· диаграммы только для экспозиции
(FEO).
Контекстная диаграмма является вершиной
древовидной структуры диаграмм и представляет собой самое общее описание
системы и ее взаимодействия с внешней средой.
Этот процесс называется функциональной
декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие
фрагментов, называются диаграммами декомпозиции.
В основе нотации и методологии IDEF0 лежит
понятие "блока", то есть прямоугольника, который выражает некоторую
функцию бизнеса. Как известно, прямоугольник имеет четыре стороны. В IDEF0 роли
(функциональные значения) всех сторон различны:
ü верхняя сторона имеет значение
"управления";
ü левая - "входа";
ü правая - "выхода";
ü нижняя - "механизма".
Вторым элементом методологии и нотации является
"поток" (в стандарте называемый - "интерфейсная дуга") -
элемент, описывающий данные, неформальное управление, или что-либо другое
"оказывающее влияние" на функцию, изображенную блоком. В зависимости
от того, к какой стороне блока направлен поток, он, соответственно, носит
название "входной", "выходной", "управляющий".
Изобразительным элементом, представляющим "поток",
является стрелка.
Управление - это что управляет деятельностью
компании, в данной разрабатываемой модели - это различная правовая документация
(федеральные законы).
Стрелки "входа" вносят функции входных
данных, в контекстной диаграмме - это заявка на перевозку груза.
Стрелки "выхода" - выходные данные. В
контекстной диаграмме - это различная отчетность и денежные средства
контрагентам.
Стрелка "механизма" - это влияющие на
процессы данные. В диаграмме - это персонал и транспортные средства.
Контекстная диаграмма компании «ТК» в нотации IDEF0
После декомпозиции контекстной диаграммы
проводится декомпозиция каждого большого фрагмента системы на более мелкие, при
этом каждому фрагменту задается имя и так далее, до достижения нужного уровня
подробности описания.
После каждого сеанса декомпозиции проводятся
сеансы экспертизы - эксперты предметной области указывают на соответствие
реальных бизнес-процессов созданным диаграммам.
Найденные несоответствия исправляются, и только
после прохождения экспертизы без замечаний можно приступать к следующему сеансу
декомпозиции. Так достигается соответствие.
4.3 Принципы
моделирования бизнес-процессов в нотации IDEF3
В отличие от IDEF0, представляющего моделируемую
систему как совокупность видов деятельности, IDEF3 представляет собой технику
моделирования деятельности как последовательности событий, а также участвующих
в этих событиях объектов. Модели IDEF3 могут использоваться для детализации
функциональных блоков IDEF0, они более низкого уровня . IDEF3 удобен для
подробного моделирования деятельности отдельных подразделений, сотрудников,
описания техпроцессов и т.д.
В IDEF3 используются следующие типы объектов:
· работа
(Unit of Work, Activity)
· стрелка (Arrow)
· перекресток, или коннектор
(Junction)
· ссылочный объект (Referent)дополняет
IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем
могут быть использованы для имитационного анализа. IDEF3 - это метод, имеющий
основной целью дать возможность аналитикам описать ситуацию, когда процессы
выполняются в определенной последовательности, а также описать объекты,
участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является
частью структурного анализа. В отличие от некоторых методик описаний процессов
IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что
может привести к созданию неполных или противоречивых моделей.
Каждая работа в IDEF3 описывает какой-либо
сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку
сценарий описывает цель и рамки модели, важно, чтобы работы именовались
отглагольным существительным, обозначающим процесс действия, или фразой,
содержащей такое существительное. Диаграмма является основной единицей описания
в IDEF3.
Единицы работы
- Unit of Work (UOW). UOW, также называемые работами
(activity), являются центральными компонентами модели. В IDEF3 работы
изображаются прямоугольниками с прямыми углами и имеют имя, выраженное
отглагольным существительным, обозначающим процесс действия, одиночным или в
составе фразы, и номер (идентификатор).
Связи показывают взаимоотношения работ. Все
связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно
диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева
направо.
В IDEF3 различают три типа стрелок, изображающих
связи:
· Старшая (Precedence) - сплошная
линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз.
· Отношения (Relational Link) -
пунктирная линия, использующаяся для изображения связей между единицами работ
(UOW) и между единицами работ и объектами ссылок.
· Потоки объектов (Object Flow) -
стрелка с двумя наконечниками используется для описания того факта, что объект
используется в двух или более единицах работы, например, когда объект
порождается в одной работе и используется в другой.
В отличие от IDEF0 для стрелок нет понятия вход,
выход, управление или механизм и неважно, в какую грань работы входит или из
какой грани выходят стрелки.
Перекрестки - окончание одной работы может
служить сигналом к началу нескольких работ, или же одна работа для своего
запуска может ожидать окончания нескольких работ. Перекрестки используются для
отображения логики взаимодействия стрелок при слиянии и разветвлении или для
отображения множества событий, которые могут или должны быть завершены перед
началом следующей работы. Различают перекрестки для слияния и разветвления
стрелок. Перекресток не может использоваться одновременно для слияния и для
разветвления.
Средства документирования и
моделирования IDEF3 позволяют выполнять следующие задачи:
· Документировать
имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса
компетентных сотрудников, ответственных за организацию рассматриваемого
процесса.
· Определять и анализировать
точки влияния потоков сопутствующего документооборота на сценарий
технологических процессов.
· Определять
ситуации, в которых требуется принятие решения, влияющего на жизненный цикл
процесса, например изменение конструктивных, технологических или
эксплуатационных свойств конечного продукта.
· Содействовать
принятию оптимальных решений при реорганизации технологических процессов.
· Разрабатывать
имитационные модели технологических процессов, по принципу "КАК БУДЕТ,
ЕСЛИ..."
5. Рекомендации по совершенствованию
процесса грузоперевозок
При написании данной курсовой работы была
составлена характеристика транспортно-экспедиторской компании «ТК» и выявлены
ключевые проблемы предприятия при осуществлении междугородних автомобильных
перевозок. В первую очередь это:
Ø Недостаточно корректное формирование
квартального графика доставки грузов ;
Компания ТК покрывает широкий диапазон городов,
имеет большой паркинг и развитую организационную структуру. Однако формирование
графика квартальных перевозок отсутствует как операция. Информация о
грузоперевозках разрозненна, что не позволяет эффективно использовать имеющиеся
ресурсы (транспорт, персонал и др.). Остро встает вопрос простоя транспортных
средств, отсутствие достаточной загруженности компании.
Я считаю, что при четком плане грузоперевозок
есть высокая вероятность существенно увеличить прибыль компании «ТК», засчет
сокращения непроизводственных расходов (простои, рабочая сила, не
задействованная в работах и др.), увеличения числа заказчиков и соответственно
грузоперевозок, засчет грамотной логистики предприятия.
Ø Хищение грузов
Необходимо увеличить уровень безопасности
перевозки груза. Экспедиторская деятельность подразумевает страхование и охрану
груза в пути, однако один только водитель с данной задачей полностью не
справляется. Компании «ТК» для обеспечения большей надежности стоит
организовать услугу «Сопровождение груза». Это усложнит процесс и увеличит его
стоимость, но положительно скажется на репутации компании, что поможет
увеличить приток клиентов, заинтересованных в перевозке ценных грузов.
. Вывод
В результате разработки проекта решены следующие
задачи:
1. Проанализирована
деятельность ООО «ТК»;
2. Построена
организационная структура компании;
3. В
соответствии с целями компании, по внедрению информационной системы, произведен
структурный анализ предметной области «КАК ЕСТЬ»;
4. Разработана
схема документооборота;
5. Разработана
информационная модель компании;
6. Разработана
модель бизнес-процессов компании;
7. Наиболее
глубокие декомпозиции были произведены в работе отдела логистики;
При моделировании были использованы нотации IDEF1X
(информационная модель компании), IDEF0
( модель бизнес-процессов верхнего уровня), IDEF3
(модель бизнес-процессов нижнего уровня).
Поскольку в работе компании документооборот
является определяющим для построения процессов, то вопросы формирования
документов были выделены в отдельный параграф «Документооборот компании «ТК»».