Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

АРМ работника аптеки – программа, которая даст возможность добавлять, изменять и выбирать данные из таблиц базы данных.

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

1. Описание предметной области

1.1. Основные этапы разработки автоматизированной системы

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

Многие компании верят в то, что одна только автоматизация приведет к улучшению финансово-экономической ситуации, и начинают усилия по реализации информационных систем непосредственно с автоматизации, пропуская критические шаги понимания и упрощения своих бизнес процессов. Но нередко эти процессы настолько неупорядочены, что в общем создают впечатление хаоса на предприятии. Как известно, автоматизировать хаос далеко не просто, если невозможно. Поэтому прежде чем создавать информационную систему следует пересмотреть систему управления в организации. Изменение бизнес процессов называют реинжинирингом (business processes reengineering). Так, для начала нужно упорядочить схему бизнес процессов и систему управления организации в целом:

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

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

Организация – это набор правил и процедур. Информационная система – это тоже набор правил и процедур, поэтому следует понимать какие инструкции и процедуры какими заменить. Не следует также забывать о человеческом факторе при создании информационной системы. Во-первых, именно людям придется работать с системой – одна работать она в любом случае не сможет. Во-вторых, служащие могут улучшить (или упростить) процессы, с которыми они ежедневно встречаются. Автоматизация должна происходить только после того, как служащие поймут процесс и примут решение о необходимости автоматизации.

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

В проектировании информационной системы также должны участвовать ее разработчики, то есть те, кто будет ее создавать.

Основными этапами работы над проектом по автоматизации являются:

  1. Проведение обследования с целью описания бизнес процессов организации.
  2. Разработка технического задания на систему автоматизации.
  3. Разработка технического проекта системы.
  4. Разработка системы.
  5. Различные стадии и этапы внедрения и эксплуатации.
  6. Выполнение доработок в соответствии с изменившимися потребностями организации.

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

1.2 Характеристика ООО «Фарминдустрия»

Объектом является компания ООО «Фарминдустрия», которая является учреждением здравоохранения по лекарственному (медикаментозному) обеспечению населения, учреждений здоровья, других учреждений, предприятий и организаций.

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

ООО «Фарминдустрия» в своей деятельности руководствуется действующим законодательством Российской Федерации и своим Уставом.

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

Основные бизнес-процессы компании – закупки, складирование запасов, продажи, взаиморасчеты с поставщиками и клиентами.

ООО «Фарминдустрия» осуществляет следующие виды деятельности:

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

Управление компанией осуществляется согласно Уставу на основании сочетания прав собственника по хозяйственному использованию своего имущества.

Организационная структура ООО «Фарминдустрия» выглядит следующим образом:

Генеральный директор

Бухгалтерия

Отдел

закупок

Отдел

продаж

Склад

Рисунок 1. Организационная структура ООО «Фарминдустрия»

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

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

Генеральный директор предприятия ООО «Фарминдустрия» является главным пользователем управленческой информации. Также информация предоставляется и руководителя отделов. Отчеты о проделанной работе каждого отдела предоставляются руководителю ежемесячно. Проводится анализ и на основании полученных выводов составляется план на следующий период с описанием дальнейшей работы. Значительную часть плана составляют заявки от потребителей и контрагентов на тот или иной вид номенклатуры.

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

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

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

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

В ходе проведения анализа предметной области были отмечены следующие моменты:

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

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

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

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

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

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)

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

THEN

ELSE

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

Нет основания для отгрузки

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

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

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

Логическая модель данных данной информационной системы состоит из 8 таблиц.

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

В таблице Продажа хранится перечень продаж с указанием даты продажи.

В таблице Состав_продажи хранится перечень препаратов, отпущенных клиенту с указанием количества и цены.

В таблице Сотрудники хранятся ФИО сотрудников с указанием должностей.

В таблице Клиенты хранятся ФИО клиентов и контактный телефон для связи.

В таблице Поставщики хранятся наименования поставщиков препаратов, адреса и контактные телефоны.

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

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

В таблице Состав_заказа хранится перечень заказанных препаратов с указанием количества каждого препарата.

2.4. Физическая модель данных

Рисунок 12. Физическая модель данных

2.5. Словарь данных

К текстовым средствам описания системы относится словарь данных. Он включает следующие данные проекта: потоки, сущности и атрибуты. Словарь данных представляет собой определённым образом организованный список всех элементов данных системы с их точными определениями, что даёт возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ [1].

Таблица 1. Словарь данных

Название потока

Название сущности

Название атрибута

бланк заказа

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

Клиенты

Код_клиента

ФИО_клиента

Телефон_клиента

данные для заявок

Поставщики

Код_поставщика

Наименование_поставщика

Адрес_поставщика

Телефон_поставщика

Заказы

Код_препарата

Количество_препарата

данные заказа

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

данные клиента

Клиенты

Код_клиента

ФИО_клиента

Телефон_клиента

данные нового клиента

Клиенты

Код_клиента

ФИО_клиента

Телефон_клиента

заказ клиента

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

запрос заказов по поставщикам

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

запрос о наличии препарата

Препараты

Код_препарата

заявки на поставку препаратов

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

информация о наличии препарата

Препараты

Код_препарата

Количество_перпарата_в_наличии

название препарата

Препараты

Код_препарата

Наименование_препарата

номенклатура препаратов

Препараты

Код_препарата

перечень поставщиков

Код_поставщика

перечень препаратов

Наименование_препарата

Форма_выпуска

Единица_измерения

Цена

Количество_в_наличии

результаты запроса

Препараты

Код_препарата

Код_поставщика

Наименование_препарата

Форма_выпуска

Единица_измерения

Цена

Количество_в_наличии

результаты запроса по поставщикам

Заказы

Дата_заказа

Код_препарата

Код_поставщика

Количество_препарата

решение о покупке

Препараты

Код_препарата

Количество_препарата

ФИО клиента

Клиенты

Фамилия_клиента

Имя_клиента

Отчество_клиента

цены на препараты

Препараты

Код_препарата

Цена_препарата

чек

Продажи

Дата_продажи

Наименование_препарата

Количество_препарата

2.6. Словарь проекта

Словарь проекта описывает весь проект, перечисляя все, что в нем содержится: процессы, потоки данных, внешние сущности и хранилища данных.

Процессы

АИС «Аптека»

Ввод данных по заказу

Ввод нового клиента в БД

Оформление заказа

Печать заявок на поставку препаратов

Поиск клиента в БД

Поиск необходимого препарата

Продажа препарата

Регистрация препаратов

Формирование ведомости заказов с группировкой по поставщикам

Формирование заявки на поставку препаратов

Потоки

бланк заказа

данные для заявок

данные заказа

данные клиента

данные нового клиента

заказ клиента

запрос заказов по поставщикам

запрос о наличии препарата

заявки на поставку препаратов

информация о наличии препарата

название препарата

номенклатура препаратов

перечень поставщиков

перечень препаратов

результаты запроса

результаты запроса по поставщикам

решение о покупке

ФИО клиента

цены на препараты

чек

База данных

База данных «АИС «Аптека»

Внешние сущности

Аптекарь

Администратор

Заключение

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

Реализация проекта автоматизированной системы учета лекарственных препаратов позволит автоматизировать основные функции аптеки по обслуживанию клиентов:

  • консультирование покупателей о фармакологических свойствах лекарственных препаратов;
  • поиск нужного препарата по базе;
  • оформление заказа на препараты;
  • обработка заказов;
  • оформление чека;
  • формировать различную финансовую отчетность.

Внедрение автоматизированной информационной системы «Учет фармацевтических препаратов» позволит:

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

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

Список использованной литературы

  1. Вигерс К. Разработка требований к программному обеспечению / Вигерс Карл, Джой Битти. – 3-е изд.,доп. – СПб.: БХВ-Петербург, 2017. – 736с.: ил.
  2. Коцюба И.Ю., Чунаев А.В., Шиков А.Н. Основы проектирования информационных систем. Учебное пособие. – СПб: Университет ИТМО, 2015. – 206 с.
  3. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с., Глава 3.
  4. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. – М.: Издательский центр «Академия», 2004. – 288 с., Глава 2.