Информационная модель и ее описание

СПЕЦИАЛЬНЫЙ РАЗДЕЛ

Описание обеспечивающих подсистем ЭИС

Информационное обеспечение

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

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

Для создания информационного обеспечения необходимо:

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

· совершенствование системы документооборота;

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

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

· создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения.

Информационная модель и ее описание

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

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

В результате анализа предметной области была разработана функциональная модель бизнес — процессов предприятия. Проектирование проводилось на основе методологии IDEF0. Найденные в модели “AS-IS” недостатки исправляются путем создания модели “ТО-ВЕ” (как будет), т.е. модели новой организации процессов на предприятии. Создание и внедрение ИС приводит к изменению условий выполнения отдельных операций, структуры процессов и предприятия в целом. Это приводит к необходимости изменения системы правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель “TO-BE” позволяет уже на стадии проектирования будущей ИС определить эти изменения. Применение функциональной модели “TO-BE” позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям. Модель “ТО-ВЕ” нужна для анализа альтернативных путей выполнения функции и документирования того, как компания будет делать бизнес в будущем. Функциональная модель “TO-BE” позволит четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов после предлагаемого реинжиниринга. Контекстная диаграмма приведена на Рисунке 2.1.

Рисунок 2.1 — Общая схема организации бизнес-процесса работа с заказами «TO-BE»

Рассмотрим входные документы для принятия решения о приёме заказа. Такими документами являются: статьи затрат, информация о заказчике, требования к выполнению заказа.

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

Информация о заказчике представляет собой перечень основных сведений о заказчике таких как: полное наименование, юридический адрес, телефон, расчётный счёт и другие. В требованиях к заказу указаны сроки выполнения заказа, количество, наименования и характеристика товара и цена. Функциональная декомпозиция первого уровня системы приведена на Рисунке 2.2. В целом контекстная диаграмма и декомпозиция первого уровня в «TO-BE» отличается от «AS-IS» только инструментом, вместо использования MS Excel будет использоваться 1С: Бухгалтерия обозначенная как ЭИС. Это внедрение значительно облегчит работу и взаимодействие с другими отделами предприятия т. к. большая часть отделов, в том числе и бухгалтерия, используют различные конфигурации 1С.

Рисунок 2.2 — Работа с заказами клиентов «TO-BE»

Функциональная декомпозиция второго уровня системы приведена на Рисунке 2.3. В данной декомпозиции в блок «расчёт рентабельности» добавлен расчёт затрат на рубль товарной продукции, для более точного определения выгодности заказа. Разделён блок «регистрация заказа и заключение договора» на блок «занесение заказа в базу» в данной базе можно будет следить за выполнением заказа, просмотреть крайний срок выполнения заказа, проверить, весь ли заказ выполнен и т. д., входной информацией для этого блока является «данные о заказе» и на выходе параметры требуемой модели и код модели, который присваивается системой. И блок «составление и заключение договора», договор составляется на основе данных о заказе и заказчике, не стоит забывать что договор подписывается двумя сторонами, следовательно договор так же содержит информацию и предприятии, которое выполняет заказ.

Рисунок 2.3 — приём заказа «TO-BE»

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

Информационная модель содержит не всю информацию о моделируемых явлениях, а только ту ее часть, которая нужна для рассматриваемых задач. Данное определение требует уточнения: очевидно, что модель — это не только набор величин, но и отношения, связи между ними.

Модель «сущность-связь» (ER-модель) (англ. Entity-relationship model или entity-relationship diagram) — модель данных, которая позволяет описывать концептуальные схемы с помощью обобщенных конструкций блоков. Это мета-модель данных, то есть средство описания моделей данных, одна из самых простых визуальных моделей.

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

На Рисунке 2.4 отображена логическая модель данных описываемой системы с детализацией до уровня сущностей. «Заказчик», «Персонал», «Заказ», «Договор», «Ассортимент» и «Список заказов» — объекты данных. Линии между ними определяют наличие связей, а значки на концах – вид связи, а также представлено описание атрибутов сущностей.

Рисунок 2.4 — логическая модель данных

С помощью связи «один к одному» можно разделить сущность на несколько частей. Такая возможность может пригодиться для более точного задания прав доступа к данным или для повышения скорости работы СУБД. Частным случаем связи «один к одному» является связь «один к нулю или одному». Ее можно использовать при разделении сущности на две части — первая содержит атрибуты, обязательные к заполнению, вторая — необязательные, но занимающие значительное место в БД.

На рисунке есть интересная связь «База заказов — База заказов». Она означает, что в процессе выполнения заказа в базу могут быть внесены коррективы, например изменение сроков выполнения заказа или изменение количества заказа. Эта связь типа «один ко многим», так как одна база может изменяться множество раз.

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

При этом тип атрибута отображен иконкой слева от наименования. Справа от атрибута могут отображаться суффиксы:

· (FK) — атрибут является внешним ключом (Foreign Key).

· (AKn.m) — атрибут входит в состав альтернативного ключа n в позиции m (Alternate Key).

Альтернативные ключи являются основой для создания уникальных индексов.

· (IEn.m) — атрибут входит в состав инверсионного входа n в позиции m (Inversion Entry). Фактически это означает наличие неуникального индекса по этому полю.

· (O) — такой суффикс означает, что атрибут может не иметь значения (Optional).