Файл: Проектирование подсистемы подготовки и оформления заказов в составе ERP-системы для ИП «Континент».pdf

ОТДЕЛ ПРОДАЖ

Основной задачей отдела продаж является удовлетворения потребностей населения оргтехникой в виде ее продаж

КЛИЕНТСКАЯ СЛУЖБА

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

Модель As-Is Кинешемского салона-магазина «Континент»:

Рис. 1.3. Контекстная диаграмма нулевого уровня магазина «Континент»

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

Рис. 1.4. Декомпозиция нулевого уровня (контекстной диаграммы)

Рис. 1.5. Декомпозиция процесса Деятельность клиентской службы

Рис. 1.5. Декомпозиция процесса Деятельность отдела продаж

Рис. 1.6. Декомпозиция процесса Деятельность сервисного центра

Анализ текущего состояния деятельности салона-магазина «Континент» показал, что наряду с автоматизацией сервисного центра, уместно будет параллельно автоматизировать и отдел продаж магазина, поскольку уровень задач автоматизации весьма сходен, спроектированные модели баз данных существенно не отличаются и в рамках реализации этого проекта. Поэтому в рамках реализации стратегии автоматизации «КАК ДОЛЖНО БЫТЬ» предлагается такая модель To-Be здесь от английского словосочетания «так будет» предлагается следующий модельный вариант

Основное отличие нового варианта от модели «As-Is» будет присутствие автоматизированной системы управления (АИС). Представим сокращенную схему модели с учетом тех функциональных блоков на которые воздействует АИС:

Рис. 1.7. Контекстная диаграмма модели «To-Be»

2.8. Контрольный пример реализации проекта и его описание

Рис. 1.8. Декомпозиция контекстной диаграммы модели To-Be

Рис. 1.9. Декомпозиция бизнес процесса Деятельность сервисного центра

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

1.5. Обоснование проектных решений по программному обеспечению

ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ

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

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

Для этого воспользуемся концепциями ER-модели.

Модель «сущность связь ER-модель»

Название модели образовано от английских слов entity – сущность и relationship – связь. Модель относится к реляционному типу, то есть в ней между сущностями устанавливается связь (отношение). Базовыми понятиями этой модели являются следующие:

• сущность с его помощью моделируется класс однотипных объектов. Сущность имеет уникальное в пределах моделируемой системы имя, а объект, которому это имя присвоено, содержит в своем составе набор атрибутов, характеризующих его свойства. На схеме модели сущность изображается прямоугольником, в котором задано имя сущности, а ниже перечисляются атрибуты, а одной сущности может соответствовать несколько объектов, с различными атрибутами (или характеристиками);
• связь – отношение, установленное между сущностями, связей может быть сколько угодно. Если одной сущности соответствует одна связь, то такое отношение называется связь «один-к-одному», если одной сущности соответствует множество связей, то это отношение «один-ко-многим», если множеству связей одной сущности соответствует множество связей, то это отношение «многие-ко-многим» и для реализации такого отношения нужна вспомогательная сущность. Перед построением модели выделим в предметной области «Кинешемский салон-магазин Континент» интересующие нас сущности. Поскольку основными видами деятельности магазина является торгово-закупочная и оказание услуг, то, учитывая, что указанные виды деятельности, осуществляю люди. Определим следующие сущности, выявленные при обследовании предметной области. Сотрудники, должности, подразделения, образование, товары, услуги. Опишем в виде таблиц перечисленные сущности. Сущность «Сотрудники» – хранит экземпляры объектов, содержащих информацию о людях, работающих в магазине. Следует отметить, что каждый экземпляр сущности однозначно определяется при помощи уникального атрибута, именуемого первичным ключом и представляющий собой, как правило, автоинкрементное (увеличивающиеся) значение.

Таблица 2.1. – Сущность сотрудники

Кроме того, чтобы не перегружать базу данных избыточными данными, проведем ее нормализацию, то есть вместо, например должности сущность будет хранить не название должности, а ссылку на ее номер в специальной сущности «Должности». При этом сущности «Сотрудники» «Должности» будут связаны друг с другом отношением «один-к-одному». При этом отношение может быть и один «ко-многим» в случае если один сотрудник занимает одновременно несколько должностей, но на рассматриваемом предприятии такая форма организации труда не применяется. Для реализации такого подхода введем дополнительные сущности-справочники. Например, сущность-справочник «Должность» будет хранить названия должностей, аналогично сущность-справочник «Образование» будет хранить сведения об образовании, сущность-справочник «Улицы», будет хранить названия улиц и т. д. Внешние ключи, которые присутствуют в качестве атрибутов, предназначены для установления связей между таблицами. В этом случае:

Таблица 2.2. – Сущность Подразделения

Таблица 2.3. – Сущность Должности

Как видим сущность должности одновременно содержит атрибут ID_должности, который ссылается на подразделение в соответствующем справочнике (является внешним ключом сущности подразделения).

Таблица 2.4. – Сущность Товары

Таблица 2.5. – Сущность Услуги

Получаем следующую информационную модель салона-магазина «Континент»

Рис. 2.1. Информационная модель Кинешемского салона-магазина «Континент»

2.2. Характеристика нормативно-справочной, входной и оперативной информации

Рассмотрим сначала нормативно-справочные данные для проектируемой информационной системы. К таковой относится в первую очередь законодательство РФ. В частности такие виды деятельности организации, как продажа товара, производство услуг регулируются Гражданским Кодексом РФ, а трудовая деятельность сотрудников регулируется Трудовым Кодексом РФ. Указанные законодательные нормы применяются руководством организации и подразумеваются в составе проектируемой системы в той части, что проектируемая система не должна противоречить нормам действующего законодательства. Действие норм учтено в управляющих частях As-Is и To-Be моделей. Входная информация показана во входных частях указанных моделей. Для определенности и наглядности представим их следующей таблицей: