Файл: Разработка регламента выполнения процесса «Учет реализации лекарственных препаратов через аптечную сеть».pdf

Игнорирование подобных ситуаций влечет за собой такие последствия:

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

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

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

1.3. Постановка задачи

Цель:

Повышение эффективности деятельности отдела продаж ООО «Фарминдустрия» путем проектирования автоматизированной системы «Учет продаж фармацевтических препаратов.

Исходные данные:

• Номенклатура препаратов.
• Закупочные и розничные цены препаратов.
• Перечень контрагентов.
• Реквизиты контрагентов.
• Перечень производителей фармацевтических препаратов.
• Информация о заказах.
• Бланки документов, оформляемых в процессе ведения учета продаж фармацевтических препаратов.

Априорные представления о модели:

Автоматизированная система «Учет продаж фармацевтических препаратов», позволяющая:

• Систематизировать учет необходимых данных о продаваемой продукции, её поставщиках и покупателях;
• Осуществлять полный электронный учет продаж, реализуемых на фирме;
• Определять доход, полученный от продаж;
• Осуществлять быстрый поиск информации о поставщиках, клиентах и реализуемых препаратах;
• Формировать и выводить на печать необходимую отчетную документацию.

Ожидаемый результат:

Автоматизированная система «Учет продаж фармацевтических препаратов», соответствующая априорным представлениям о модели.

Критерии оценки результата:

• увеличение степени достоверности информации;
• увеличение скорости обработки информации;
• уменьшение бумажного документооборота;
• сокращение времени на получение необходимой информации,
• оптимизация расходов.

Средства проектирования:

для разработки регламента выполнения процесса учета фармацевтических препаратов были выбраны такие CASE-средства, как AllFusion ProcessModeler и AllFusion ERwinDataModeler.

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

2.1. Модель требований

Модель требований (логическая модель системы) указывает, что должна делать проектируемая система, не указывая, как это делается.

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

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

Предконтекстная диаграмма

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

Рисунок 2. Предконтекстная диаграмма (первый уровень)

Рисунок 3. Предконтекстная диаграмма (второй уровень)

Контекстная диаграмма

Диаграмма DFD отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана.

Она идентифицирует эти внешние сущности, а также процесс, отражающий главную цель или природу системы насколько это возможно. На Рисунок 4 представлена контекстная диаграмма автоматизированной системы «Учет продаж фармацевтических препаратов».

Рисунок 4. Контекстная диаграмма автоматизированной системы

«Учет продаж фармацевтических препаратов»

2.2. Модель реализации

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

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

Диаграмма первого уровня выглядит следующим образом (Рисунок 5):

Рисунок 5. Диаграмма первого уровня автоматизированной системы

«Учет продаж фармацевтических препаратов»

Диаграмма дает представление о деятельности системы в целом, показывая входящие и исходящие данные и объекты.

Весь процесс деятельности отдела продаж, которую предполагается автоматизировать, подразделяется следующим образом:

• Закупка товаров (на основании заявки на поставку товара и выставленного счета от поставщика ООО «Фарминдустрия» производит оплату товара, информация о поставщиках заносится в хранилище «Поставщики»),
• Поступление товаров (на склад ООО «Фарминдустрия» поступаю товары от поставщика согласно накладным по закупочным ценам),
• Учет товаров на складе (данные о товаре вносятся в базу данных, производится расчет товарных остатков, устанавливаются розничные цены),
• Реализация товаров (контрагенту направляется прайс-лист, после оформления заявки ему выставляется счет. После оплаты счета производится отгрузка товара).

Рисунок 6. Детализация процесса «Учет товара на складе»

Процесс учета товара на складе, в свою очередь подразделяется на:

• Ввод информации о товаре (информация о товаре, поступившем от поставщика, вводится в хранилище «Номенклатура»),
• Расчет остатков на складе (после ввода поступлений производится расчет остатков товара на складе по каждому виду номенклатуры),
• Расчет стоимости товаров с учетом торговой наценки (учитывая рейтинг продаж по каждому виду номенклатуры определяется торговая наценка и производится расчет розничных цен на товары).

Рисунок 7. Детализация «Реализация товара»

На данном этапе производится:

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

Диаграмма «сущность-связь» (ERD)

Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями.  Фактически с помощью (ERD) осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей)».

Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.

Ниже приведена диаграмма «сущность-связь», показывающая связи между основными компонентами системы (Рисунок 8).

Товар

ООО

«Фарминдустрия»

Поставщик

Клиент

продает

n

n

k

1

k

закупает

заказывает

поставляет

1

Расчетный счет

имеет

1

b

имеет

Единицы измерения

1

1

Рисунок 8. Диаграмма «сущность-связь»

Спецификации процессов

При отсутствии необходимости детализации процессов с помощью DFD для описания их функционирования используются спецификации процессов. Для описания спецификаций процессов использован структурированный естественный язык, а также визуальный язык проектирования — Flow-форма (Рисунок 9) и диаграмма Насси-Шнейдермана (Рисунок 10).

Спецификация процесса 1.1 (ОТГРУЗКА ТОВАРА)

@ВХОД=ОПЛАТА ОТ КОНТРАГЕНТА

@ВХОД=ИНФОРМАЦИЯ О КОНТРАГЕНТЕ

@ВХОД=БЛАНК ЗАКАЗА

@ВЫХОД=СЧЕТ

@ВЫХОД=ТОВАР

@СПЕЦПРОЦ 1.4.3 ОТГРУЗКА ТОВАРА

ЕСЛИ получена ОПЛАТА ОТ КОНТРАГЕНТА

ТО Выполнить ОТГРУЗКУ ТОВАРА на основании БЛАНКА ЗАКАЗА и ИНФОРМАЦИИ КОНТРАГЕНТЕ

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.4.3

IF получена ОПЛАТА ОТ КОНТРАГЕНТА

THEN

Выполнить ОТГРУЗКУ ТОВАРА на основании БЛАНКА ЗАКАЗА и ИНФОРМАЦИИ КОНТРАГЕНТЕ

Рисунок 9. Flow-форма (спецификация процесса 1.4.3)

Рисунок 10. Диаграмма Насси-Шнейдермана (спецификация процесса 1.4.3)

2.3. Логическая модель данных

Логическая модель данных построена в программе ERWIN. С помощью этой модели осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и отношения между ними.