Автоматизация деятельности фармацевтических компаний на примере ООО 'Шексна-Фарма'

Автоматизация деятельности фармацевтических компаний на примере ООО 'Шексна-Фарма'

Введение

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

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

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

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

Целью данного проекта является модернизация существующей системы «Склад» на предприятии ООО «Шексна-Фарма».

Для достижения этой цели необходимо выполнить следующие задачи:

. Проанализировать особенности существующей системы и обозначить главную проблему ее дальнейшей модернизации.

. Провести аналитический обзор существующих решений данной проблемы.

. Выбрать наиболее выгодный путь решения проблемы.

. Спроектировать, реализовать и протестировать программный продукт.

. Оценить результаты внедрения программного продукта на предприятии.

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

Глава 1. Описание существующей системы

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

.1 Назначение и функции системы

С момента открытия (1990 г.) по настоящее время на предприятии используется разработанная сотрудниками АСУ система складского учета (далее «программа «Склад»). В самом начале своего развития программа «Склад» имела более узкое назначение и, соответственно, функционал, который сводился в основном к автоматизации исключительно бухгалтерского документооборота. В дальнейшем в течение нескольких лет программа «Склад» эволюционировала, что было обусловлено постоянно возникавшими новыми требованиями к функционалу и аналитике программы вследствие растущего интереса к использованию информационных технологий для управления предприятием. В настоящее время функционал программы значительно расширен. Общий размер исходных файлов достигает 3,1 Мб, а общий размер файлов данных составляет около 12 Гб. Среди самых основных задач программы можно выделить следующие:

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

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

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

1.2 Организация базы данных

Выполнение выше обозначенных функций в масштабе бизнес процессов предприятия ООО «Шексна-Фарма» не может обойтись без оперирования большим количеством данных, поэтому на заре эпохи автоматизации работы предприятия был седлан выбор в пользу передового по тем временам программного продукта FoxPro 2.0 for DOS от компании Fox Holdings © 1989-91.

FoxPro 2.0 - это файл-серверная СУРБД со всеми плюсами и минусами файл-серверных систем управления базами данных.

С появлением на рынке FoxPro 2.0, включающего перечисленные ниже ключевые технологии, был совершен переворот в области разработки баз данных на персональных компьютерах:

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

.В версии 2.0 разработчики Fox включили поддержку SQL.

.FoxPro 2.0 задействовал принцип WYSIWYG - разработка экранов и отчетов с помощью таких средств, как проектировщики (или мастера) экранов и отчетов (Screen Designer и Report Designer). Мастер экранов генерировал код, позволяя использовать метод разработки GUI в ориентированной на текст среде.

Текущая версия Visual FoxPro основана на COM, и Microsoft утверждает, что .NET-версии продукта не будет. Существует проект Sedna, который должен обеспечить возможность взаимодействия Visual FoxPro с .NET.

В настоящее время последней версией продукта является 9.0. Visual FoxPro 9.0 (VFP9.0) использует одноименный язык программирования FoxPro. Среда разработки версии 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 - только в Windows XP, 2000, 2003. Среда исполнения (runtime) версий 8.0 и 9.0 работает под любой версией Windows, начиная с 98.

Программа FoxPro 2.0 в свое время стала достижением, удивительные возможности ее (сервис в разработке GUI, SQL и молниеносная быстрота доступа к данным) и сегодня не потеряли своей силы в Visual FoxPro. Все же в настоящий момент файл-серверные СУБД уступают клиент-серверным.

.3 Организация многопользовательского доступа к данным

Будучи файл-серверной СУБД, FoxPro 2.0 предоставляет разработчику достаточно большой инструментарий, с помощью которого можно создать пользовательский интерфейс (правда, используя только текстовый режим видеоадаптера) и обеспечить доступ к данным. Сами же данные должны находиться в общедоступном месте, т.е. - на файловом сервере, для организации которого в 1990 году для ООО «Шексна-Фарма» была выбрана сетевая операционная система NetWare 4.11 от фирмы Novell.

Следует отметить, что NetWare 4.1 наследует ряд возможностей, ставших стандартом среди сетевых операционных систем фирмы Novell. Эти возможности включают в себя такие свойства, как зеркальное отображение (mirroring) и горячее фиксирование (hotfix), защищающие данные на файловом сервере. Принцип связывания (bindery-based) обеспечивает возможность того, что файловый сервер с NetWare 4.1 «видит» серверы с более старыми версиями NetWare.

Файловый сервер NetWare обладает тремя важными механизмами управления памятью:

Пулы памяти.

Постраничная организация.

Защита памяти.

.3.1 Пулы памяти

Управление памятью файлового сервера, используемое в NetWare 4.1, намного проще, чем в предыдущих версиях NetWare. Операционная система NetWare 2.x, например, была «связана» ограничениями процессора 80286. Хотя можно запускать NetWare 2.x на 80386 или 80486, но исходный код был разработан для 80286. NetWare 3.x вобрала несколько улучшений в управлении памятью. Характерной особенностью NetWare 3.x является набор пулов памяти. Пулы памяти (memory pools) - это подразделы RAM файлового сервера, которые в различных целях используются модулями NLM. Разработчики NLM должны следовать строгим правилам, указывающим, какая память в какой пул должна возвращаться.

NetWare 4.1 отличается упрощенной схемой управления памятью, содержащей только один пул памяти. Все NLM запрашивают память из пула, а по завершении возвращают ее. Чтобы посмотреть, как используется память, можно воспользоваться MONITOR.NLM, выбирая из трех элементов меню: Resource Utilization (Использование ресурсов), Cache Utilization (Использование кэша) и Memory Utilization (Использование памяти).

NetWare 4.1 продолжает вести статистику по пулам памяти, введенную в NetWare 3.x. Это необходимо для поддержания совместимости с NLM, разработанными для работы на файловом сервере NetWare 3.x. В NetWare 4.1, например, NLM может сделать запрос на фиксированный пул памяти. Операционная система будет выполнять этот запрос, а для запрашивающего NLM останется неизвестным, что на самом деле память, которую он получает для использования, берется из главного пула памяти. Операционная система прячет такую информацию от NLM.

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

С точки зрения NetWare, память размещается в кэш-буферах. Каждый кэш-буфер имеет размер 4 Кб. Фрагментация происходит, когда память в несмежных буферах высвобождается несколькими NLM. Непрерывная свободная память - это память, которая доступна для использования и расположена в смежных буферах. Фрагментированная память разбросана по всей карте памяти.

Когда операционная система пытается разместить другой блок памяти, она не знает, какой буфер доступен и где он расположен. NetWare 4.1 использует процесс сборки мусора (garbage collection) для определения объема имеющейся памяти. В результате сборки мусора составляется перечень доступных буферов памяти в форме таблицы. Эта таблица используется NetWare при выделении памяти модулям NLM. Процессом сборки мусора можно управлять с помощью набора команд SET и задавать следующее:

-Периодичность проведения сборки мусора.

Объем памяти, при превышении которого начинается сборка мусора.

Количество высвобожденных модулями NLM областей памяти, при превышении которого должна происходить сборка мусора.

.3.2 Постраничная организация памяти

NetWare 4.1 в своей схеме распределения памяти использует механизм постраничной организации (paging mechanism) компании Intel. Такой механизм встроен в любой процессор типа 80386 и выше, произведенный Intel или по лицензии Intel. Эта схема позволяет NetWare разбивать память на страницы (pages). Каждая страница - это непрерывный блок памяти размером 4 Кб. Информация о распределенных страницах памяти записывается в страничные таблицы. Страничные таблицы (page tables) - это указатели на страницы памяти, которые разбросаны по всей карте оперативной памяти компьютера. Для отслеживания чрезвычайно больших распределений памяти сами страничные таблицы группируются в домены (domains).

Для сетевого администратора такая организация памяти означает, что файловый сервер будет назначать RAM модулям NLM постранично, a NLM воспринимает получаемый блок RAM как непрерывный. В силу своей аппаратной реализации эта функция работает очень быстро.

1.3.3 Кольцевая защита памятиmemory protection. На эту функцию также ссылаются как на уровень привилегий (privilege level). Память в сервере NetWare 4.1 разделена на четыре области или домена. Каждая такая область в спецификации уровня привилегий Intel называется кольцом (ring). Эти четыре кольца пронумерованы от 0 до 3. Ядро операционной системы NetWare 4.1 всегда выполняется в кольце 0. Другие модули NLM по умолчанию также выполняются в кольце 0.

Если модуль NLM назначается кольцу, отличному от кольца 0, то он не может получить доступ к ресурсам внутренних колец без выполнения того, что называется вызовом межкольцевого перехода (inter-ring gate call). Такой процесс защищает программы, выполняющиеся во внутренних кольцах, и для него требуется дополнительное время процессора. Если, например, известно, что NLM может завершаться аварийно, то для его отладки и для защиты других NLM его можно запустить в кольце 3. Когда NLM, выполняющийся не в кольце 0, завершается аварийно, он воздействует только на себя, а также, возможно, делает недоступным свое кольцо. На других кольцах это не сказывается. На рис. 1.1 представлен процесс выполнения NLM в кольце 3. Можно видеть, что в случае аварийного завершения другие NLM не повреждаются.

В настоящее время в NetWare 4.1 определены только кольца 0 и 3. При этом программное обеспечение разрешает переключаться между всеми кольцами (0, 1, 2 и 3). Однако, если вы загружаете NLM в кольцо 1, 2 или 3, фактически он будет загружен в один и тот же домен.

Рисунок 1.1 - Кольцевая защита памяти

Novell ссылается на домен, охватывающий кольцо 0, как на домен OS (сокращение от «operating system»). Домен, связанный с кольцом 3, называется OSP или OS Protected (от «operating system protected»). Функция защиты кольца-домена включается путем добавления команды LOAD DOMAIN.NLM к конфигурационному файлу сервера STARTUP.NCF. Между доменами можно переключаться, используя одну из следующих команд с консоли файлового сервера: DOMAIN OS или DOMAIN OSP.

Используя возможности операционной системой NetWare 4.11 сотрудниками технического центра компании была организована сетевая работа с использованием протоколов семейства IPX/SPX. Общая схема сети представлена на рис. 1.2.

Рабочие станции, на которых установлена СУБД FoxPro 2.0, вместе с файловым сервером образуют сеть посредством коммутатора и витой пары. Общие ресурсы файлового сервера представлены на рабочих станциях как сетевой диск. Количество рабочих станций достигает 100.

Рисунок 1.2 - Схема локальной сети

Данные в виде файлов двухмерных таблиц с расширением DBF размещены в нескольких директориях. Общее количество файлов таблиц, включая файлы индексов, достигает 70000, а сам размер данных - 30 Гб. Сами данные вступают в достаточно сложные отношения друг с другом, но общая идея организации данных может быть представлена на рис. 1.3.

Рисунок 1.3 - Схема существующей базы данных в общем виде

В большинстве операций с данными обязательно участвуют три таблицы: PRIXOD, RASXOD, OSTATOK, остальные таблицы в основном являются справочниками, реализующими связь «один ко многим» или искусственными таблицами, предназначенными для построения отношения «многие ко многим».

PRIXOD - содержит информацию о приходуемом товаре.

OSTATOK - содержит информацию о текущем наличии товаров.

RASXOD - содержит информацию об израсходованном товаре.

ISG - справочник изготовителей.

SKLAD - справочник способов размещения товаров.

TMC - справочник товарно-материальных ценностей.

ORGAN - справочник организаций, выдающих сертификаты на лекарственные средства.

CENNIK - номенклатурный справочник товаров. (исторически сложившееся название).

REESTR - справочник государственного реестра цен на жизненно важные лекарственные средства.

USERS - информация о пользователях программы «Склад».

POKUP - информация о клиентах компании.

.4 Проблемы существующей системы и пути их решения

Существующая система не обеспечивает ряд важных функций, которые в настоящее время требуются предприятию:

Обеспечение удаленного доступа к перечню товаров на складе (остатки).

Ограничение доступа к иным данным (кроме остатков)

Обеспечение отправки накладных на удаленный компьютер.

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

-Возможность организации доступа пользователей через сеть Интернет.

Возможность защиты от несанкционированного доступа.

Возможности использования протокола TCP/IP.

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

Учитывая все достоинства и недостатки существующей системы, а также новые требования руководства, логично предположить 2 способа решения проблемы:

1.Полностью заменить существующую систему.

.Доработать существующую систему с привлечением новых дополнительных средств разработки.

2. Аналитический обзор

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

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

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

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

Гибкий интерфейс взаимодействия пользователем.

Сложность адаптации к бизнес-процессам предприятия.

Возможность самостоятельной организации данных.

Полнота функционала.

Избыточность функционала.

Доступ ко всей информации в режиме реального времени.

Клиент-серверная архитектура.

Затраты на разработку и/или внедрение.

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

. «Юнико» Оптовый склад. (Автоматизация оптовой торговли ЛС).

НТО Юнико, начиная с мая 1991г., занимается разработкой программного обеспечения для комплексной автоматизации деятельности предприятий малого и среднего бизнеса.

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

Учитывая специфику фармацевтической деятельности, компания Юнико ведет оперативную поддержку таких баз данных, как «Реестр цен» и «База фальсификатов», поддерживает в актуальном режиме модуль «Учет льготных рецептов» системы «Льготное обеспечение», прошедший проверку с 1999 по 2015 годы во всех муниципальных аптеках Московской области.

Основной функционал и аналитика данного ПО:

Ведение оптового склада и розничных подразделений;

Гибкий механизм ценообразования в зависимости от вида подразделения (опт или розница), типа операции (приход, внутреннее перемещение), типа и ценовой группы товара, группы покупателей;

Контроль торговой наценки на превышение предельно допустимой;

Резервирование товара;

Выгрузка прайс-листа в Excel;

Автоматизированный контроль фальсифицированных ЛС и сроков годности;

Автоматическое разделение расходной накладной по ставкам НДС товара;

Автоматическое формирование накладных на внутреннее перемещение, возврат поставщику, списание товара;

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

Автоматизированный обмен данными между объектами аптечной сети и центральным оптовым складом, передача данных в ночное время с использованием назначенных заданий и модулей собственной разработки;

Полный комплект первичных и отчетных документов в т.ч. согласно Приказу № 14 МЗ РФ: товарная накладная T-12, счет-фактура, счет, протокол согласования цен, сборочный и упаковочный лист, приложение к накладной, спецификация, журнал оптового отпуска АП-22, журнал регистрации по отпуску товаров АП-90, ведомость №11, журнал 41 счета, завозная книга, книги покупок и продаж, товарные отчеты разных видов;

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

Наличие "Генератора отчетов", который позволяет самостоятельно составлять формы отчетов;

Выгрузка данных по приходным и расходным документам в бухгалтерский комплекс «Юнико» и для «1С бухгалтерии»;

Контроль расхода квотируемых ЛС;

Анализ товародвижения: финансово-экономический, в графическом виде, АВС, ХУZ, рейтинговый по товару, поставщику, торговой наценке, прибыли, скорости продаж, сезонности и др.;

Формирование заказа товара по результатам анализа минимального остатка, интенсивности расхода, времени исполнения заказа, АВС-групп, с учетом уже заказанного, но еще не поступившего или не оприходованного товара;

Разграничение прав пользователей с многоуровневым доступом;

Система защиты и предупреждений от неправомерных действий пользователей, автоматическое архивирование и хранение копий баз данных;

. «М-аптека плюс» в конфигурации «Оптовый склад».

«Эскейп» - софтверная компания, основанная в 1992 году. Направление работы - осуществление разработки, внедрения и сопровождения программного обеспечения для автоматизации предприятий.

Компанией «Эскейп» разработан ряд автоматизированных систем управления фармацевтическими предприятиями, таких как: программный комплекс «М-аптека льгота» <#"896611.files/image001.gif">(8.1)

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

.1 Расчет выгоды в результате внедрения проекта

Заказы, присылаемые от удаленных компьютеров, состоят из разного количества выбранных позиций. Заказ, содержащий большее количество заказанных позиций, будет оформляться дольше, поэтому нельзя ориентироваться исключительно на количество заказов. Соответственно необходимо вычислить среднее время, затрачиваемое на нахождение и выбор одной позиции из прайса оператором, т.е. «вручную» (t_ср.). Далее необходимо вычислить среднее количество позиций, содержащихся в заказах, поступающих в рабочий день (N). Перемножая эти показатели, можно вычислить количество человеко-часов в рабочий день. Если это количество разделить на 8 - продолжительность нормального рабочего дня в часах при сорокачасовой рабочей неделе, можно получить количество человек (P), необходимых для поддержания бизнес-процессов при отказе от использования предлагаемого программного продукта.

Таким образом, количество человек, которые выполнят работу, эквивалентную работе данного программного продукта, будет рассчитываться по формуле 8.2:

,(8.2)

где N - среднее количество позиций в день;

t_ср. - время в секундах выборки одной позиции;

- количество секунд в 8 часах.

Для вычисления t_ср. были собраны следующие статистические данные:

При выборе позиций вручную в существующей системе фиксировалась дата и время, в результате чего накопилась таблица с данными TIMSET.DBF, которая состоит из 66053 записей. Эта таблица с данными содержит поля с номером накладной (NNAKL), кодом покупателя (NP), кодом пользователя (USERID), датой выбора позиции (DTOTGR), временем выбора позиции (CTIM). С каждой накладной всегда работает только один пользователь, таким образом можно сформировать SQL запрос, который сгруппирует записи и с помощью агрегирующих функций выдаст время занесения первой позиции (MIN(CTIM)), время занесения последней позиции (MAX (CTIM)) и количество позиций (COUNT(*)) для каждой накладной. С помощью вычисляемого поля можно представить продолжительность ручного оформления накладной, которая равняется разнице между временем занесения первой и последней позиции. В связи с этим накладные, состоящие только из одной позиции необходимо отбросить, так как в этом случае разница будет равна 0. Если этого не сделать, то результат подсчета не будет объективным.

Так как Local SQL BDE не поддерживает выполнение запросов вида SELECT … FROM SELECT…, необходимо выполнить 2 запроса с формированием промежуточной таблицы данных.

Первая SQL-инструкция будет выглядеть следующим образом:

SELECT NNAKL, NP, USERID, DTOTGR, MAX(CTIM) AS MAXCTIM, MIN(CTIM) AS MINCTIM, CAST((CAST(MAX(CTIM) AS TIME) - CAST(MIN(CTIM) AS TIME)) / (CAST('00:00:01' AS TIME) - CAST('00:00:00' AS TIME)) AS INTEGER) AS LGTH, COUNT(*) AS CNT FROM TIMSET GROUP BY NNAKL, DTOTGR, USERID, NP HAVING COUNT(*) > 1

Результатом этого запроса будет промежуточная таблица (TIMDATA1), содержащая сгруппированные данные по каждой накладной. Поля таблицы содержат следующую информацию: номер накладной (NNAKL), Код покупателя (NP), код пользователя (USERID), дата выписки накладной (DTOTGR), время занесения последней позиции (MAXCTIM), время занесения первой позиции (MINCTIM), продолжительность ручного оформления накладной в секундах (LGTH), количество позиций в накладной (CNT).

Для проведения такого исследования в среде Delphi 7 было создано приложение, в котором были использованы компоненты для работы с таблицами DBase посредством BDE (Borland Database Engine).

Вид единственного окна приложения представлен на рисунке 8.1.

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

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

SELECT CAST(SUM(LGTH) AS INTEGER) AS TOTAL_LGTH, CAST(SUM(CNT - 1) AS INTEGER) AS TOTAL_POS, SUM(LGTH) / SUM(CNT - 1) AS AVG_TIME FROM TIMDATA1

Рисунок 8.1 - Формирование промежуточной таблицы данных

Результатом второго запроса будет конечная таблица (TIMDATA2), содержащая единственную запись. (Рис. 8.2). Таблица включает в себя три поля: TOTAL_LGTH - показывает общее количество времени в секундах, затраченное на ручную выборку всех анализируемых позиций; TOTAL_POS - количество всех анализируемых позиций; AVG_TIME - среднее время в секундах, которое затрачивается на поиск одной позиции в прайсе (t_ср). Оно получается в результате деления TOTAL_LGTH / TOTAL_POS и составляет 23,836 с.

Для подсчета среднего количества позиций, содержащихся в заказах, поступающих в рабочий день (N), лучше всего брать календарный период, кратный месяцу. В данном проекте представлен отчет за май 2014г. (Этого должно быть достаточно). Заказы представляют собой файлы с расширением DBF, содержащие записи - собственно, выбранные позиции. Если посчитать общее количество всех заказанных позиций (K) и поделить его на количество рабочих дней D (согласно производственному календарю на 2014 в мае 19 рабочих дней, т.е. D = 19), то в результате будет получена требуемая характеристика N.

Рисунок 8.2 - Конечный результат анализа статистических данных

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

По окончании выполнения программы (Рис 8.3), были получены следующие результаты: общее количество анализируемых файлов - 5741; общее количество выбранных позиций (K) - 278528.

заказанных позиций в рабочий день в среднем.

Таким образом,

 человек.

Это означает, что производительность разрабатываемого программного продукта компенсирует труд 12-ти человек с оплатой полной ставки (при сорокачасовой рабочей неделе) вместе с одним человеком, работающим на ¼ ставки - минимальная возможная нагрузка, предусмотренная на предприятии.

Рисунок 8.3 - Подсчет количества заказанных позиций за один месяц

При минимальном размере ставки, который составляет 16000 рублей в месяц для должности с данной квалификацией, общая экономия средств составит: 16000 · 12,25 = 196000 рублей в месяц.

Соответственно годовая экономия составит 2352000 рублей.

8.2 Расчет затрат на выполнение проекта

Для расчета совокупной стоимости проекта рассчитывается сметная стоимость и составляется смета на разрабатываемый проект. Сметная стоимость разработки представляет собой сумму затрат, планируемых на проведение работ, соответствующих составленному перечню.

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

.2.1 Расчет стоимости материалов и комплектующих

В статье затрат на материалы и комплектующие учитывается стоимость всех материальных ресурсов, необходимых для проведения работ: основных и вспомогательных материалов, комплектующих изделий, сборочных единиц и деталей. Расчет затрат на материалы и комплектующие ведется на основе договорных цен с учетом транспортных расходов (см. таблицу 8.1).

Таблица 8.1 Расчет стоимости материалов и комплектующих

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

.2.2 Определение трудозатрат

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

Таблица 8.2 Перечень этапов и работ по проектированию программного продукта

.2.3 Организационный план работ

Организация работ по проведению разработки в данном дипломном проекте основывается на последовательно-параллельном выполнении этапов и работ. В этом случае цикл исследования или разработки будет определяться по формуле 8.3:

^,(8.3)

где n - число этапов;

К_пар - средний коэффициент параллельности выполнения стадии;

t_i - трудоемкость стадии, чел-дн;

ч_i - численность людей, одновременно выполняющих данную стадию (ч_i=2 чел).

Рассчитаем Т_{посл-пар} для каждого этапа отдельно, а затем просуммируем результаты и получим время цикла разработки Т_цик.

Расчет цикла разработки приведен в таблице 8.3.

Таблица 8.3 Расчет цикла разработки

Время цикла разработки Т_цик = 147 дней.

.2.4 Оценка трудоемкости работ

Для определения трудоемкости разработки используются типовые нормы времени по программированию задач для ЭВМ. Нормы времени рассчитаны на комплексы задач и указаны в человеко-днях, человеко-часах или нормо-часах при пятидневной рабочей неделе с продолжительностью рабочего дня 8 час.

Расчет трудоемкости исследования или разработки производится по формуле 8.4:

,(8.4)

где t_i - трудоемкость работ по стадиям (этапам) разработки, чел-дн.;

n - количество работ (стадий, этапов) проектирования.

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

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

, (8.5)

гдеt_min - минимально возможная продолжительность работы, под которой понимается предполагаемая ее продолжительность при наиболее благоприятных условиях;

t_max - максимальная продолжительность работы, под которой понимается ее предполагаемая продолжительность при самых неблагоприятных условиях.

Оценка трудоемкости работ и этапов представлена в таблице 8.4.

Таблица 8.4 Состав и трудоемкость работ

Фонд времени работы каждого участника определяется путем распределения работ между исполнителями на каждом этапе (см. таблицу 8.5).

Таблица 8.5 Списочный состав и фонды времени исполнителей

Ленточный график работ представлен в приложении Б.

.2.5 Расчет численности исполнителей работ

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

В данном дипломном проекте численность исполнителей, учитывая все эти факторы, а также существующее положение вещей, взята равной 2.

Состав и фонды времени исполнителей указаны в таблице 8.5.

Примерные обязанности и функции исполнителей в проектировании:

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

.        Дипломник: Проектирует, программирует, тестирует все модули. Описывает в документации информацию по ним.

.2.6 Расчет оплаты труда персонала

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

Среднедневная оплата труда каждого участника рассчитывается по формуле:

,(8.6)

где З_мес - среднемесячная оплата труда, руб;

Ф - среднемесячный плановый фонд времени одного работника, дни.

Расчет оплаты труда приведен в таблице 8.6.

Таблица 8.6 Расчёт оплаты труда

.2.7 Расчет отчислений на социальные нужды

Отчисления на социальные нужды составляют 26,2% от общего фонда оплаты труда:

З_соц = 0,262 × З = 0,262 × 150900= 39535,8 (руб.)

.2.8 Расчет амортизационных отчислений на оборудование

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

,(8.5)

где Ц_об - стоимость оборудования (35 тыс. руб. - стоимость компьютера и лазерного принтера);

Н_об - нормы отчислений на амортизацию оборудования (30 % в год);_р - время работы оборудования, дней (136 дней, так как работы проводятся на ЭВМ от этапа эскизного проекта до заключительного этапа);

Т_р - число календарных дней в 2008 году (366 дней).

 (руб.)

.2.9 Расчет накладных расходов

Накладные расходы берутся в процентах от оплаты труда (55%):

З_н = 0,55 × З = 0,55 × 150900 = 82995 (руб.)

.2.10 Расчет затрат на прочие расходы

Расчет затрат на прочие расходы определяется в процентном соотношении от суммы предыдущих статей затрат (2%).

З_проч = 0,02 × åЗ_i = 0,02 × (З_м + З + З_соц + З_об + З_н)= 0,02 × (2419 + 150900 + 39535,8 + 3902 + 82995) = 0,02 × 279751,8 = 5595,04 (руб.).

.2.11 Смета затрат

Смета затрат на разработку представлена в таблице 8.7.

Таблица 8.7 Смета затрат на разработку

Исходя из таблицы 8.7 видно, что стоимость разрабатываемого проекта составляет 285346,84 руб.

.3 Расчет показателя эффективности

Таким образом, согласно формуле (8.1) показатель экономической эффективности составит:

Показатель экономической эффективности =

Показатель экономической эффективности больше 1 в 8 раз, следовательно, разработка не только оправдана, но и экономически выгодна.

Заключение

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

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

В результате выполнения данной выпускной квалификационной работы была разработана автоматизированная система формирования заказов для сети аптек «Шексна-Фарма», которая успешно прошла опытную эксплуатацию и теперь используется на предприятии по своему назначению.

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

Внедрение автоматизированной системы формирования заказов на предприятии ООО «Шексна-Фарма», описанной в данном проекте, оказалось весьма эффективным с экономической точки зрения.

автоматизация сервер сетевой клиент

Список использованных источников

1.   ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению. - Введ. 01.01.1980.- М.: Изд-во стандартов, 1982. - С.32.

2.      ГОСТ 19.701 - 90. ЕСПД. Схемы алгоритмов программ, данных и систем. Условные обозначения и правила выполнения. - Введ. 01.01.1992.- М.: Изд-во стандартов, 1992. - 8 с.

.        ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению. - Введ. с 28.12.93. - М.: Госстандарт России, 1994. - 15 с.

.        Карпова, Т.С. Базы данных: модели, разработка, реализация / Т.С. Карпова. - СПб.: Питер, 2001. - 304 с.: ил.

.        Одинцов, И.О. Профессиональное программирование. Системный подход / И.О. Одинцов. - 2-е изд. перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 624 с.: ил.

.        Фаронов, В.В. Программирование баз данных в Delphi 7. Учебный курс / В.В. Фаронов. - СПб.: Питер, 2005. - 459 с.: ил.

7.   Флёнов М.Е. Библия Delphi: «БХВ - Петербург», 865 с