Процессы, направленные на автоматизацию торговли включают в себя множество мероприятий, которые касаются внедрения в торговые бизнес-процессы компонентов программ и аппаратного обеспечения, это дает возможности для того, чтобы была увеличена эффективность использования трудовых ресурсов и характеристик качества обслуживания [1].
Проблемы обеспечения автоматизации торговых фирм уже достаточно давно решают на основе разных подходов.
Такие автоматизированные системы существуют уже в течение нескольких десятилетий. Для первых из них не было ориентации на то, чтобы использовать их в сетевых средах, и они имели немного функций. На их базе нельзя было рассчитывать на интеграцию с другими приложениями. Постепенно происходил большой рост функциональных возможностей в программном обеспечении для торговых сфер, появились новые поколения автоматических систем, которые позволяли управлять торговыми сетями [3, 6].
В существующих условиях наблюдается интенсивное развитие рынков программного обеспечения. Такие процессы связаны в основном с тем, что идет конкуренция. При привлечении потенциальных клиентов торговые компании стремятся к тому, чтобы повысить эффективность своей работы, для этого необходимо обладать полной информацией о деятельности торговых точек.
Использование компьютерно-кассовых систем в магазинах рассматривается как совокупность важных элементов в области розничной торговли. Рост ассортиментов товаров, изменения в объемах продаж и существующая конкуренция привели к необходимости высоких скоростей в учете товародвижения.
Мероприятия, направленные на координацию работ, связанных с проведением обработки большого числа операций, касаются применения соответствующих средств, позволяющих автоматизировать торговые процессы [4]. Одной из основополагающей технологией считают применение штрихового кодирования.
За счет штрихкодов можно увеличить скорость анализа данных, и происходит уменьшение вероятностей для механических ошибок ввода данных.
В системах розничной торговли применяют сканеры штрихкодов внутри складов и торговых залов, для того, чтобы проводить идентификацию товаров на базе кассовых аппаратов, при этом формируются данные, связанные с количественным учетом в складских программах.
На основе принтеров штрихкодов существенным образом облегчаются и ускоряются процессы по приема, передачи товаров. Идет развитие и других подходов, направленных на применение штрихкодирования, они заметным образом влияют на характеристики эффективности работы с товарами.
В электронных весах есть возможность проведения точной идентификации товаров и их свойств, когда идет загрузка из баз данных.
Подготовка квалифицированных кадров также влияет на эффективность работы торговых организаций.
До массового распространения ЭВМ необходимость решения этой задачи порождала огромный бумажный документооборот, требовавший существенных затрат трудовых и материальных ресурсов. Качественный прорыв в этой области произошел после внедрения информационных технологий. Применение компьютеров и информационно-вычислительных сетей позволило существенно сократить время, затрачиваемое на сбор и обработку информации, позволило избавиться от громоздких архивов, хранящих огромное количество бумажных документов. Стали появляться автоматизированные рабочие места (АРМ) – совокупности информационно-программно-технических ресурсов, которые предоставляли для пользователей возможности, связанные с обработкой данных и автоматизации управленческих функций для данной сферы деятельности. При создании АРМ мы предполагаем, что базовые операции, связанные с накоплением, хранением, и переработкой информации связаны с использованием вычислительной техники, а пользователями выполняются определенные ручные операции, которые требуют творческого подхода.
Существенным шагом вперед по сравнению с автономными АРМ стало объединение таких рабочих мест в сеть, с использованием единой централизованной базы данных, отвечающей за хранение информации, используемой в данном предприятии. Это позволило объединить процессы накопления и анализа информации, принятия решений на её основе, сократить время, требуемое на информационный обмен между различными частями системы управления предприятием.
Однако настоящий прорыв случился тогда, когда на рубеже ХХ и XXI веков появился и обрел большую популярность новый класс приложений, обеспечивший возможность доступа к информационным системам и базам данных организации не только через интрасеть, но и из любой точки мира, используя сеть Интернет [2, 1].
Целью данной работы является разработка веб-приложения, предназначенного для использования в качестве программной основы для автоматизированных рабочих мест. Для достижения данной цели необходимо выполнить следующие основные задачи:
1. Разработать архитектуру приложения, сформулировать техническое задание и функциональные требования к системе.
2. Определить модель данных приложения.
3. Разработать и реализовать интерфейсы пользователя и бизнес-логику приложения.
Одной из основных функций, без которой невозможно осуществление какой-либо организованной деятельности любой социальной или производственной организации, является управление. Система, которая осуществляет процессы управления, называется управляющей системой. Главными задачами, возложенными на неё, являются задачи сбора, систематизации и анализа информации о деятельности предприятия, осуществления прогнозирования, планирования деятельности и принятия управленческих решений на основе собранных данных, а также контроль над их исполнением.
Процессы управления неразрывно связаны с информационным обменом между составляющими управляющей системы. Особую значимость имеет скорость обмена информацией, причем как внутри предприятия, так и при взаимодействии с окружающей средой. Получение неактуальных, устаревших данных о состоянии какого-либо производственного или торгового процесса сводит на нет всю ценность информации, и приводит к появлению ошибочных управленческих решений.
Существуют различные виды информационных систем, используемых в деятельности организаций.
Разрабатываемое в данной работе программное обеспечение относится к типичной бизнес-системе, что подразумевает неформальную спецификацию требований, поэтому для выработки требований к приложению можно использовать сценарии использования (Use case).
Рассмотрим сценарии использования для нашей системы.
Заказчик приходит в ремонтное подразделение, чтобы подать заявку на ремонт оборудования. Если данный заказчик уже есть в базе, оператор заводит заявку, иначе предварительно заказчик заносится в базу данных системы. Далее, оператор назначает специалиста, ответственного за эту заявку.
Заказчик приходит узнать о состоянии заказа. Оператор проверяет готовность заказа. Если заявка помечена как выполненная, производится выдача отремонтированного оборудования.
Заказчик отменяет заявку. Оператор помечает заявку как отмененную.
Специалист-ремонтник может просматривает списки заявок, за выполнение которых он ответственен.
Специалист-ремонтник отмечает завершенные заказы как выполненные.
Специалист-ремонтник заводит заявки на требуемые инструменты и материалы.
Кладовщик просматривает списки заявок на выдачу инструментов и материалов, оставленных специалистами-ремонтниками.
Руководитель подразделения просматривает все списки заявок, в том числе, отобранные по конкретным заказчикам, а также специалистам, и по состоянию заказа.
Исходя из сценариев использования, можно выделить четыре роли пользователей: руководитель, оператор, специалист-ремонтник, кладовщик. Кроме того, видно, что основные сущности, используемые в системе – заявки. Теперь можно сформулировать функциональные требования к системе.
Оператор может просматривать заявки на ремонт в целом, по конкретным специалистам или заказчикам, заводить и отменять заявки, назначать исполнителя, просматривать статусы заявок на ремонт.
Специалист-ремонтник может просматривать списки только тех заявок, которые он исполняет и отмечать их как выполненные.
Специалист-ремонтник может заводить заявки на требуемые в процессе ремонта инструмент и материалы.
Кладовщик может просматривать заявки на материалы и инструменты, как в целом, так и по конкретным специалистам.
Руководителю доступны для просмотра все выше перечисленные виды просмотра заявок.
Ключевыми объектами, которые хранятся в БД нашей системы являются заявки. Они подразделяются на два вида: заявки на ремонт, заявки на материалы и инструменты для ремонтного подразделения. Заявки характеризуются следующими свойствами:
Заявка на ремонт:
Клиент, подавший заявку;
Дата приема заявки;
Дата окончания работ по заявке;
Дата выдачи заявки;
Описание заявки;
Специалист, которому поручено выполнение заявки;
Оператор, принявший заявку;
Заявка на выдачу материалов и инструмента:
Специалист, подавший заявку;
Дата подачи заявки;
Дата выдачи;
Описание;
Информацию, запрашиваемую у системы, можно разделить на следующие типы запросов:
Список всех заявок от клиентов;
Список всех выполненных заявок;
Список всех невыполненных заявок;
Список отмененных заявок;
Вышеуказанные списки по клиентам и специалистам-ремонтникам;
Списки заявок на инструмент и материалы от специалистов-ремонтников;
Действия над заявками осуществляют следующие типы пользователей: руководитель, оператор, кладовщик, специалист.
Опишем роли пользователей, взаимодействующих с нашим приложением:
Руководитель – данная роль в нашем случае характеризует начальника ремонтного подразделения. Руководитель контролирует работу отдела, просматривая данные о выполненных и активных заявках, а также данные о наличии необходимых материалов и инструментов. Данная роль предполагает возможность доступа (просмотр и редактирование) ко всей информации, хранящейся в нашей БД.
Специалист – работник ремонтного подразделения, осуществляющий ремонт техники. Он может просматривать список своих заявок, помечать заявки как выполненные, и
Кладовщик – просматривает заявки, сделанные специалистами ремонтного подразделения.
Оператор – менеджер по приему заявок на ремонт. Он может добавлять новых клиентов в клиентскую базу, отмечать статус заявок как выполненный или отмененный, просматривать информацию по заявкам.
Основу слоя представлений (видов) в разрабатываемом нами приложении составляют jsp-страницы. Страницы построены на основе блоков:
Блок заголовка – содержит название приложения, отображает логин пользователя. Также здесь находится кнопка, при активации которой происходит выход из приложения с последующим перенаправлением на страницу входа. Располагается вверху страницы.
Блок навигации – располагается слева, занимает 30 % ширины отображаемой страницы. Содержит элементы навигации по функциональным возможностям.
Блок рабочей области – здесь, в зависимости от выбранной в блоке навигации функциональности, находятся либо формы запросов, либо таблицы с результатами запросов.
Для описания оформления jsp-страниц используется файл style.css.
Библиографическая ссылка
Шмалько Г.А. ПРОБЛЕМЫ АВТОМАТИЗАЦИИ ТОРГОВЫХ ПРЕДПРИЯТИЙ // Международный студенческий научный вестник. – 2017. – № 4-7. ;URL: https://eduherald.ru/ru/article/view?id=17632 (дата обращения: 23.11.2024).