15
Рис. 1.2. Контекстная диаграмма
Стратегии и процедуры, которыми руководствуется процесс (управление)
– это внутренняя организация документооборота.
Входом для системы являются приходы товара от поставщика на
дальнейшею реализацию.
Выходом для системы являются, отгруженный товар и товарный чек с
отпущенным товаром.
Функциональная декомпозиция системы, приведенная на рисунке 1.3,
проводится также на основе методологии IDEF0.
На этом уровне выполняются следующие функции:
формирование продажи по заявлению клиента;
выполнение продажи;
оформление товарного чека;
отгрузка товара.
Деятельность компании
Менедже
р
Внутрифирменная
организация
документооборота
приход товара от поставщика
Отгруженный товар
Старший менеджер
Товарный чек
.
Деятельность
компании
16
Рис. 1.3. Диаграмма декомпозиции
Формирование данных о товаре осуществляется менеджером по
продажам.
Выполнение заказа отдела продаж осуществляется на основе заказа от
менеджера по продажам. В результате товара в наличии на складе организации.
Оформление чека клиенту осуществляется менеджером по продажам на
основе данных о наличии товара на складе организации. В результате –
сформированный чек на оплату.
Отгрузка товара производится старшим менеджером по продажам на
основе оплаты от клиента по чеку. В результате – отгруженный товар и
товарный чек.
Схема документооборота для каждого документа, содержащая оценки
потоков информации, представлена в таблице 1.1.
Деятельность компании
Менеджер по продажам
Внутрифирменная организация документооборота
Старший Менеджер
Отгруженный товар
Приход товара на склад
чек
Заказ на
товар
Товар на
складе
Товарный чек
Оплата клиента
1
.
Формирован
ие данных о товаре
на складе
2
.
Выполнение продажи
3
.
Оформление чека
клиенту
4
.
Отгрузка товара
17
Таблица 1.1. Схема документооборота для каждого документа.
Документ
Подразделения
работающие с
документом
Кто обрабатывает
документ
Периодичность
обработки документа
Данные о товаре
Отдел продаж
Менеджер по
продажам
1 раз в день
Оформление
продажи
Отдел продаж
Менеджер по
продажам, менеджер
по закупкам
5-10 раз в день
Чек клиенту
Отдел продаж
Менеджер по
продажам
5-10 чеков в день
1.3 Постановка задачи
Главной целью данной дипломной работы является разработка
автоматизированного рабочего места менеджера по продажам в компании ООО
«ДЕЗМЕДТОРГ», позволяющей устранить недостатки настоящего процесса
учета.
Можно выделить следующие цели автоматизированного варианта
решения задачи:
сокращение времени обработки и получения данных о товарах на
складе в наличии;
автоматизированная подготовка документов;
автоматизированное определение остатков товара и его учет;
повышение степени достоверности обработки информации товарах
на складе в наличии;
повышение степени защищенности информации;
повышение степени достоверности информации, необходимой для
принятия управленческих решений старшим менеджером.
18
С помощью автоматизации деятельности компании можно будет
определить объем заказов, вести историю заказов, получить аналитическую
информацию за необходимый период времени. Все это позволит принимать
верные управленческие решения, уменьшить временные затраты, тем самым
увеличить прибыль компании.
1.4 Анализ существующих разработок
Технология создания информационных систем предъявляет особые
требования к методикам реализации и программным инструментальным
средствам. Реализацию проектов по созданию информационных систем
принято разбивать на стадии анализа (прежде чем создавать информационных
систем, необходимо понять и описать бизнес-логику предметной области),
проектирования (необходимо определить модули и архитектуру будущей
системы), непосредственного кодирования, тестирования и сопровождения.
Сущность структурного подхода к разработке АРМ заключается в его
декомпозиции (разбиении) на автоматизируемые функции. Функции АРМ
разбивается на функциональные подсистемы, которые в свою очередь делятся
на подфункции, подразделяемые на задачи и так далее. Процесс разбиения
продолжается вплоть до конкретных процедур. При этом автоматизируемая
система сохраняет целостное представление, в котором все составляющие
компоненты взаимоувязаны.
Основные этапы, на которые разбивается процесс проектирования
информационной системы, следующие:
Концептуальное проектирование – сбор, анализ и редактирование
требований к данным (обследование предметной области, изучение ее
информационной структуры, выявление всех фрагментов, каждый из
которых характеризуется пользовательским представлением,
информационными объектами и связями между ними, процессам в
19
информационных объектах, моделирование и интеграция всех
представлений)
Логическое проектирование – преобразование требований к данным в
структуры данных. На выходе получаем СУБД ориентированную структуру
базы данных и спецификации прикладных программ.
Физическое проектирование – определение особенностей хранения данных,
методов доступа и т.д.
Современные объектно-ориентированные CASE-средства позволяют
эффективно решать задачи проектирования приложений. Среди таких пакетов –
Rational Rose, Together Control Center, BPWin, ERWin, Model Mart, Silverrun
Business Process Modeller, Process Analyst.
Для разработки функциональной модели выбрано CASE-средство
Computer Associates BPwin 4.0. BPwin является мощным инструментом для
создания моделей, позволяющих анализировать, документировать и
планировать изменения сложных бизнес-процессов. BPwin предлагает средство
для сбора всей необходимой информации о работе предприятия и графического
изображения этой информации в виде целостной и непротиворечивой модели.
BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие
анализировать ваш бизнес с трех ключевых точек зрения:
С точки зрения функциональности системы. В рамках методологии IDEF0
бизнес-процесс представляется в виде набора элементов-работ, которые
взаимодействуют между собой, а также показывается информационные,
людские и производственные ресурсы, потребляемые каждой работой.
С точки зрения потоков информации (документооборота) в системе.
Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3,
поскольку они описывают потоки данных, позволяя проследить, каким
образом происходит обмен информацией между бизнес-функциями
внутри системы. В тоже время диаграммы DFD оставляют без внимания
взаимодействие между бизнес-функциями.
20
С точки зрения последовательности выполняемых работ: еще более
точную картину можно получить, дополнив модель диаграммами IDEF3.
Этот метод привлекает внимание к очередности выполнения событий.
На начальных этапах создания Информационной системы необходимо
понять, как работает организация, которую необходимо автоматизировать.
Никто в организации не знает, как она работает в той мере подробности,
которая необходима для создания АРМ. Руководитель хорошо знает работу в
целом, но не в состоянии вникнуть в детали работы каждого рядового
сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем
месте, но плохо знает, как работают коллеги. Поэтому для описания работы
организации, а в нашем случае работы менеджеров по продажам
необходимо построить модель. Такая модель должна быть адекватна
предметной области, следовательно, она должна содержать в себе знания всех
участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является
IDEFO, прежнее название SADT Structured Analysis and Design Technique. В
IDEF0 система представляется как совокупность взаимодействующих работ или
функций. Такая чисто функциональная ориентация является принципиальной,
функции системы анализируются независимо от объектов, которыми они
оперируют. Это позволяет более четко смоделировать логику и взаимодействие
процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и
графическое), которое должно дать ответ на некоторые заранее определенные
вопросы.
Моделируемая система рассматривается как произвольное подмножество.
Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет
ли некий объект компонентом системы, или мы будем его рассматривать как
внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему.
Система имеет границу, которая отделяет ее от остальной Вселенной.
21
Взаимодействие системы с окружающим миром описывается как вход (нечто,
что перерабатывается системой), выход (результат деятельности системы),
управление (стратегии и процедуры, под управлением которых производится
работа) и механизм (ресурсы, необходимые для проведения работы). Находясь
под управлением, система преобразует входы в выходы, используя механизмы.
Все это позволяет сделать вывод о том, что методология IDEF0 наиболее
подходит для моделирования бизнес-процессов ООО «ДЕЗМЕДТОРГ».
Основными конструктивными элементами моделей являются сущности,
связи между ними и их свойства (атрибуты). Сущность – любой различимый
объект (объект, который мы можем отличить), информацию о котором
необходимо хранить в базе данных. Логическая структура базы данных – это
описание состава, типа и длины информационных единиц базы данных и связей
между ними.
Сущности и связи модели данных представляются в виде реляционной
таблицы (отношения). Отношение, соответствующее сущности, содержит
атрибуты (столбцы), являющиеся атрибутами сущности и описывающие
сущность (объект). Атрибут или множество атрибутов, которые однозначно
определяют объект, называются ключом.
Удобно представлять отношение как таблицу, где каждая строка есть
кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом
называются атрибутами и им присваивают имена. Список имён атрибутов
называется схемой отношения. Совокупность схем отношений, используемых
для представления информации, называются схемой базы данных, а текущие
значения соответствующих отношений – базой данных.
Процесс построения инфологической модели состоит из следующих
шагов:
– определение сущностей;
– определение зависимостей между сущностями;
– задание первичных и альтернативных ключей;
22
– определение атрибутов сущностей;
– приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели – это абстрактный взгляд на
данные, на нем данные представляются так, как выглядят в реальном мире.
Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД. Физическая модель данных, напротив, зависит
от конкретной СУБД, фактически являясь отображением системного каталога. В
физической модели содержится информация обо всех объектах БД. Поскольку
стандартов на объекты БД не существует (например, нет стандарта на типы
данных), физическая модель зависит от конкретной реализации СУБД.
Следовательно, одной и той же логической модели могут соответствовать
несколько разных физических моделей.
Для инфологического проектирования базы данных было выбрано CASE
средство Computer Associates ERwin 4.0.
Создание модели данных, как правило, начинается с создания логической
модели. После описания логической модели, проектировщик может выбрать
необходимую СУБД и ERwin автоматически создаст соответствующую
физическую модель. На основе физической модели ERwin может сгенерировать
системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс
называется прямым проектированием (Forward Engineering). Тем самым
достигается масштаб – создав одну логическую модель данных, можно
сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С
другой стороны, ERwin может по содержимому системного каталога или SQL-
скрипту воссоздать и физическую, и логическую модель данных (Reverse
Engineering). На основе полученной логической модели данных можно
сгенерировать физическую модель для другой СУБД и затем сгенерировать ее
системный каталог.
Различают три уровня логической модели, отличающихся по глубине
представления информации о данных:
23
– диаграмма сущность-связь (Entity Relationship Diagram, ERD);
– модель данных, основанная на ключах (Key Based model, KB);
– полная атрибутивная модель (Fully Attributed model FA).
Диаграмма сущность-связь представляет собой модель данных верхнего
уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-
правила предметной области. Такая диаграмма не слишком детализирована, в
нее включаются основные сущности и связи между ними, которые
удовлетворяют основным' требованиям, предъявляемым к АРМ.
Диаграмма сущность-связь может включать связи многие ко многим и не
включать описание ключей. Как правило, ERD используется для презентаций и
обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, – более подробное представление
данных. Она включает описание всех сущностей и первичных ключей и
предназначена для представления структуры данных и ключей, которые
соответствуют предметной области.
Полная атрибутивная модель – наиболее детальное представление
структуры данных: представляет данные в третьей нормальной форме и
включает все сущности, атрибуты и связи.
Различают два уровня физической модели:
– трансформационная модель (Transformation Model);
– модель СУБД (DBMS Model).
В качестве вариантов автоматизации существуют готовые типовые
решения, также предлагается рассмотреть вариант индивидуальной разработки.
Готовые решения, как правило, предназначены для решения задачи
полной автоматизации деятельности.
Например, программа 1С:Предприятие 8. Управление торговлей
предназначена для автоматизации деятельности торговых предприятий и
оказывающих услуги организаций
24
"1C Управление Торговлей 8" повышает эффективность работы предприятия
за счет автоматизации рутинных операций. Конфигурация предоставляет
гибкие возможности учета и контроля взаиморасчетов с контрагентами по
нескольким схемам с различными уровнями детализации:
По договорам. В конфигурации "Управление торговлей 8" детализация
взаиморасчетов "по договорам" является базовой и производится всегда.
Если не требуется дополнительная детализация, то можно выбрать способ
ведения взаиморасчетов по договору в целом.
По заказам (счетам) в рамках долгосрочного договора. Разделение по
заказам удобно для гибкого управления взаиморасчетами в рамках
текущих торговых операций. Например, по одному заказу поставки могут
быть приостановлены из-за возникшей по нему задолженности, а по
другому - разрешены.
По конкретным документам хозяйственных операций (по расчетным
документам) в рамках договора. Данная возможность предназначена для
тех случаев, когда для каждого документа, например, накладной, важно
знать, оплачен он или нет. Эта схема ориентирована в первую очередь на
предприятия, которые не строят свой документооборот на основании
заказов (счетов).
Конфигурация поддерживает следующие разновидности торговли: оптовую,
розничную, комиссионную торговлю (включая субкомиссию), прием товаров
на комиссию, продажу в кредит, торговлю по заказам.
Основные функции:
Учет товародвижения;
Управление продажами;
Планирование продаж;
Управление заказами покупателей;