Проектирование информационной системы логистики

Проектирование информационной системы логистики

Содержание

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 (модель бизнес-процессов нижнего уровня).

Поскольку в работе компании документооборот является определяющим для построения процессов, то вопросы формирования документов были выделены в отдельный параграф «Документооборот компании «ТК»».