BC/NW 2021 № 1 (37):10.1

РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ СЕРВИСНОГО ЦЕНТРА ДЛЯ ПРИЕМА И ОБРАБОТКИ ЗАЯВОК ООО «ОНЛАЙН-КАССА.РУ»

Абросимов Л.И., Воронин М.М.

В современном бизнесе нельзя обойтись без технической поддержки в виде программ для ведения бизнеса, учета клиентов, поставщиков и поставок, а также учет продаж. Для удобства ведения коммерческих взаимоотношений, как Business-to-Consumer, так и Business-to-Business, современные технологии предлагают использование онлайн-касс и кассовое оборудование, такое как сканеры штрих-кодов, принтеры, фискальные накопители.

Федеральный закон 54-ФЗ устанавливает жесткое условие для предпринимателей: все финансовые расчеты с покупателями и поставщиками должны производиться через электронные кассы.

Одним из основных условий работы онлайн кассы является подключение к сети Интернет. Кроме того, такое соединение не обязательно должно быть постоянным: данные сохраняются и хранятся на ФН.

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

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

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

 

1. АНАЛИТИЧЕСКИЙ ОБЗОР ИС СЕРВИСНОГО ЦЕНТРА

 Технико-экономическая характеристика предприятия

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

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

Компания предоставляет комплексное обслуживание и помогает предпринимателям выполнять все требования по использованию контрольно-кассовой техники по стандарту 54-ФЗ с минимальными финансовыми и временными затратами.

Организационная структура ООО «Онлайн-Касса.ру» представлена на рисунке 1.

Рис. 1. Организационная структура

Описание существующей ИС

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

В ИС сервисного центра должны храниться данные об аппарате, клиенте, выполненных работах и другой информации, которая необходима для работы сервисного центра.

Этапы в процессе приема и выполнения заказа на ремонт:

1) Предварительное определение характера ремонтного заказа. Определяется, было ли оборудование продано ООО «Онлайн-Касса.ру» или товар был приобретен клиентами в другом месте. Также определяется, истек ли срок действия гарантии. При необходимости менеджер по приемке связывается с сервисным инженером.

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

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

4) Менеджер принимает участие в проверке наличия необходимых расходных материалов и запасных частей на складе.

5) Составление договора и заказа в соответствии с формой, регистрация поступления предоплаты, заполнение журнала заказов клиента.

6) Сдача аппарата, составление приемо-сдаточного акта, счета и счета-фактуры.

 

Обоснование необходимости создания АИС

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

Недостатки автоматизации учёта в используемом продукте Microsoft Excel:

·       низкая производительность при работе с большими объемами данных;

·       недостаточная функциональность (нет средств представления отдельных записей по определённым фильтрам и критериям);

·       нет многопользовательского доступа;

·       нет гибких механизмов разграничения доступа к данным;

·       большие трудности с консолидации (сложности сведение данных при подготовке отчётов).

В среднем на оформление одной заявки уходит 4 минуты, для согласования и направления заявки исполнителю затрачивается 20 минут, в день сервисный центр принимает более 500 заявок на ремонт. Данные технико-экономические показатели компании представлены в таблице 1.

Таблица 1. Основные технико-экономические показатели

№

п\п

Наименование характеристики (показателя)

Значение показателя на июнь 2020 года

1

Количество сотрудников

700 сотрудников

2

Оборот компании за год

Около 540 миллионов рублей

3

Количество обращений (заявок) в день

500 шт

4

Среднее арифметическое количество времени, затраченное на регистрацию одной заявки в мин.

4 мин.

5

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

20 мин.

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

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

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

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

Отсутствие АИС тормозит развитие компании, и каждый руководитель стремится вывести свою компанию на самый высокий уровень.

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

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

С помощью Microsoft Access реализованы:

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

·       сбор данных из многих источников данных для отчёта или распечатывания, использование одно приложение (объединение информации из нескольких таблиц, чтобы она служила источником отчёта);

·       добавление дополнительных таблиц в более поздние время;

·       создание разовых комплексных запросов (объединение информации из многих таблиц, размещённых в базе данных для разового анализа).

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

Однако работа с Microsoft Access ограничено возможностями оболочки по предоставлению данных их обработки, что является собой неудобства. Конечной целью автоматизации учёта заказов сервисного центра является АИС, которая будет отвечать основным требованиям:

o   оперативность получения информации для контроля и управления;

o   создание единого информационного пространства в компании;

o   оптимизация труда затрат по поводу первичной информации формирования отчётов;

o   создание надежной и безопасной АИС;

o   удобство пользовательского интерфейса;

o   повышение уровня безопасности;

o   простота использования для пользователя;

o   сортировка данных по различным столбцам таблицы;

o   использование фильтров данных;

o   генерация отчётов.

Сравнительный анализ показателей «как есть» до внедрения АИС и «как реализовано» после внедрения, представлен в таблице 2.

Таблица 2 Сравнительный анализ показателей

Анализируемые показатели

«Как есть»

«Как реализуется»

Оперативность в получении информации для контроля и управления

Отсутствие возможности оперативного отслеживания:

·   статус заказа;

·   кем принят заказ;

·   кем выполняется заказ;

·   разделение работ по заказу между мастерами.

Возможность отследить любым сотрудникам статус заказа по нескольким критериям

Создание единого информационного пространства в компании

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

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

Создание базы данных, которая будет приведена к нормальным формам

·   избыточность данных;

·   отсутствие структуры данных, связанных сущностями;

·   противоречивость данных при вставке, удалении или обновлении данных.

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

Повышение уровня безопасности

·   доступ нескольких сотрудников к базе данных;

·   нет гибких механизмов разграничения доступа к данным.

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

Сортировка данных и использование фильтров данных

Создание разовых комплексную запросов (объединение информации из многих таблиц, размещённых в базе данных для разового анализа).

Сортировка данных по различным столбцам таблицы

2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Цели разрабатываемой АИС:

1)    Экономия времени и денег сервисного центра;

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

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

3)    Сбор статистики по ремонтному производству.

Требование к структуре функционированию системы

АИС должна иметь двухуровневую архитектуру (клиентская станция - сервер базы данных).

Разрабатываемая АИС должна включать следующие системы:

·       Систему хранения данных (СХД)

·       Система управления базами данных (СУБД),

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

Система управления базами данных (СУБД) – это совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.

В настоящей разработке используется Access – это полнофункциональная программа, ), входящая в состав пакета MS Office, которая предназначена для работы с базами данных любого типа. В основе данной программы используется модель динамического обмена данными.

 

Все компоненты базы данных, такие как таблицы, отчеты, запросы, формы и объекты хранятся в Access в одном дисковом файле с расширением .mdb.

Основным структурным компонентом БД является таблица. В таблицах хранятся входные данные. Каждая таблица состоит из столбцов, называемых полями, и строк, называемых записями. Каждая запись таблицы содержит всю необходимую информацию о конкретном элементе БД.

 

Таблица 3  Свойства полей БД

Свойство

Назначение

Имя поля

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

Тип поля

Определяет тип данных, которые содержаться в данном поле.

Размер поля

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

Формат поля

Определяет способ форматирования данных в ячейках, принадлежащих полю.

Маска ввода

Определяет форму, в которой вводятся данные в поле.

Подпись

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

Значение по умолчанию

Значение, которое вводится в ячейки поля автоматически.

Условие на значение

Ограничение, используемое для проверки правильности ввода данных

Сообщение об ошибке

Текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.

Обязательное поле

Определяет обязательность заполнения поля данными.

Пустые строки

Разрешает ввод пустых строковых данных

Индексированное поле

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

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

Таблица 4 Типы данных Access

Тип данных

Описание

Текстовый (Значение по умолчанию)

Текст или числа, не требующие проведения расчетов, например номера телефонов (до 255 знаков)

Числовой

Числовые данные различных форматов, используемые для проведения расчетов

Дата/время

Для хранения календарных дат и текущего времени

Денежный

Для хранения денежных сумм

Поле MEMO

Для хранения больших объемов текста (до 65535 символов)

Счетчик

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

Логический

Может иметь только одно из двух возможных значений (True/False, Да/Нет)

Поле объекта OLE

Объект (например, электронная таблица Microsoft Excel, документ Microsoft Word, рисунок, звукозапись или другие данные в двоичном формате), связанный или внедренный в таблицу Access

Гиперссылка

Для хранения адресов URL Web-объектов Интернета.

Мастер подстановок

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

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

1. Подсистема анализа заказов, поступающих от сотрудников сервисного центра.

2. Подсистема регистрации сотрудника (менеджеры, мастера, руководители и т.д.) в информационной системе.

3. Подсистема сбора и обработки данных о заказах, выданных гарантиях на выполнение работ.

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

1.       Модуль статистики получения техники.

Этот модуль собирает и обрабатывает данные от пользователя. Записывает и анализирует всю информацию, введенную пользователем при приемке оборудования. Хранит данные о пользователе, а при подключении к Интернету отправляет данные на сервер базы данных.

2.       Модуль статистики данных.

Этот модуль собирает и обрабатывает данные от пользователя. Записывает информацию, полученную от пользователя при добавлении конкретного продукта, данные о выполнении работы. Анализирует информацию, полученную по частоте ее выбора. Хранит данные о пользователе, а также отправляет данные на сервер базы данных при подключении к Интернету.

3. Модуль статистики по клиентам.

Этот модуль собирает и обрабатывает данные о пользователе. Сохраняет всю введенную пользователем информацию о клиентах. Анализирует полученную информацию.

С его помощью можно собирать статистику по объему заказа и виду работ. Хранит статистику по пользователю приложения. Обрабатывает данные по месяцам и годам. Передает данные на сервер базы данных.

4. Модуль для хранения всей информации о деятельности организации

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

5.       Модуль ввода и обработки данных.

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

6.       Модуль ввода и обработки пользовательских данных.

Взаимодействие с модулем хранения информации. Данный модуль включает в себя ввод и обработку первичной информации о пользователе, включая дату регистрации, организационно-правовую форму. Хранит данные о пользователе, а при подключении к Интернету отправляет данные на сервер БД.

7.       Модуль отчетности.

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

Этот модуль обеспечивает выбор информации по заданным параметрам и выполняет следующую функцию:

8.       Модуль визуализации.

Модуль визуализации взаимодействует со всеми вышеперечисленными модулями.

 

 Средства разработки

В результате обзора средств разработки был определен ряд инструментов для разработки ИС. Средством разработки был выбран язык C#, так как этот язык является самым быстрым для создания нужной ИС. Программное обеспечение Visual Studio было выбрано в качестве среды разработки благодаря своему инструментарию и различным дополнениям, которые значительно упрощают процесс разработки интерфейса и написания кода. Рассматривались также различные типы баз данных, способы их создания и способы доступа к ним, для проектирования БД был выбран Microsoft Access.

3. ПРОЕКТИРОВАНИЕ ИС

Проектирование баз данных

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

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

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

o   логическое проектирование - преобразование требований к данным в структуры данных. Результатом является ориентированная на СУБД структура базы данных и спецификации прикладных программ;

o   физическое проектирование - спецификация функций хранения данных, методов доступа и т.д.

Основными структурными элементами моделей являются сущности,

Отношения между ними и их свойствами (атрибутами).

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

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

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

Процесс построения инфологической модели состоит из следующих этапов

·                определение субъектов;

·                определение зависимостей между субъектами;

·                указание первичного и альтернативного ключей;

·                определение атрибутов сущностей;

·                приведение модели к требуемому уровню нормальной формы.

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

Современные объектно-ориентированные инструменты CASE позволяют эффективно решать задачи проектирования приложений.

Для инфологического проектирования базы данных был выбран инструмент CASE Data Modeller.

Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели проектировщик может выбрать соответствующую СУБД, а ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может затем сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием. Это обеспечивает масштабируемость - с помощью одной логической модели данных физические модели могут быть сгенерированы для любой базы данных, поддерживаемой ERwin. С другой стороны, ERwin может воссоздать как физическую, так и логическую модель данных из содержимого системного каталога или SQL-скрипта. На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД, а затем сгенерировать ее системный каталог.

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

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

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

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

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

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

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

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

Рис. 2 Схема базы данных

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

 

Таблица 5 Все таблицы базы данных

Название таблицы

Описание

Clients

Хранит клиентов, которые когда-либо были в СЦ

Deliveries

Список всех поставок

DelStatus

Статусы доставок

Device

Список всех устройств

Employers

Список сотрудников

Jobs

Наименования работ

Orders

Таблица с заказами

OrderStatus

Таблица состояний заказов

Points

Наименования точек СЦ

Providers

Список поставщиков

SpareParts

Запчасти на складе

SpStatus

Данные о состоянии запчастей

Структура базы данных описана в таблицах 6 -17  3.2-3.13

Таблица 6 Clients

Название

Тип

Расшифровка

Ключ

idClient

Number

ID клиента

Первичный

NameClient

Varchar

Имя клиента

 

Phone

Varchar

Контактный номер

 

adInfo

Varchar

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

 

Таблица 7 Deliveries

Название

Тип

Расшифровка

Ключ

idDel

Number

ID доставки

Первичный

DateDelivery

Date

Дата доставки

 

idProvider

Number

ID поставщика

 

idDelStatus

Number

ID статуса доставки

 

idPoint

Number

ID точки

 

Таблица 8 DelStatus

Название

Тип

Расшифровка

Ключ

idDelStatus

Number

ID статуса

Первичный

DeliveryStatus

Varchar

Наименование статуса

 

Таблица 9 Device

Название

Тип

Расшифровка

Ключ

idDevice

Number

ID устройства

Первичный

DeliveryStatus

Varchar

Наименование устройства

 

 

Таблица 10 Employers

Название

Тип

Расшифровка

Ключ

idEmp

Number

ID мастера

Первичный

Name

Varchar

Имя мастера

 

Salary

Varchar

Заработная плата

 

idPoint

Number

ID точки, где мастер работает

 

loginEmp

Varchar

Логин учетной записи

 

passwordEmp

Varchar

Пароль учетной записи

 

Таблица 11 Jobs

Название

Тип

Расшифровка

Ключ

idJob

Number

ID работы

Первичный

deliveryStatus

Varchar

Наименование работы

 

Таблица 12 Orders

Название

Тип

Расшифровка

Ключ

idOrder

Number

ID заказа

Первичный

orderSum

Number

Сумма работ

 

orderDateDelivery

Date

Дата выдачи

 

idEmp

Number

ID мастера

 

idClient

Number

ID клиента

 

idOrderStatus

Number

ID статуса заказа

 

idDevice

Number

ID устройства

 

idSpare

Number

ID запчасти

 

idJob

Number

ID работы

 

Таблица 13. Orders

Название

Тип

Расшифровка

Ключ

idStatus

Number

ID статуса заказа

Первичный

NameStatus

Varchar

Наименование статуса

 

Таблица 14 Points

Название

Тип

Расшифровка

Ключ

idPoint

Number

ID точки

Первичный

NamePoint

Varchar

Наименование точки

 

Таблица 15 Providers

Название

Тип

Расшифровка

Ключ

idProvider

Number

ID поставщика

Первичный

NameProvider

Varchar

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

 

Таблица .16 SpareParts

Название

Тип

Расшифровка

Ключ

idSpare

Number

ID запчасти

Первичный

NameSpare

Varchar

Название запчасти

 

idStatus

Varchar

ID статуса запчасти

 

Cost

Number

Стоимость запчасти

 

Таблица 17 SpStatus

Название

Тип

Расшифровка

Ключ

idSpStatus

Number

ID статуса запчасти

Первичный

SpStatus

Varchar

Статус запчасти

 

Диаграммы активности и последовательности

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

Диаграмма активности (рисунок 2) представляет собой пошаговое действие, когда клиент отправляет устройство на ремонт и получает его обратно. На схеме представлены 2 основных взаимодействия: заказчик и мастер-приемник.

Рис. 2 Диаграмма активности

 

 

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

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

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

Рис. 3. Диаграмма последовательности

 Описание программных модулей

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

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

Рис. 4 Алгоритм ввода данных в базу

Алгоритм работы с формой программы представлен на рисунке 5

Рисунок 5 Алгоритм ввода данных в базу

Алгоритм планирования работы заказа показан на рисунке 6. Для каждого заказа может быть произвольное количество заданий, поэтому в скобках услуг с периодом ответственного работника программа заносит полный список заданий, выполненных под заказ. Существует также список расходных материалов и запасных частей, необходимых для этой работы. Различные сотрудники могут выполнять разную работу в рамках одной и той же работы в зависимости от их специализации и загруженности. На каждое рабочее место также назначен ответственный сотрудник. Менеджер также анализирует перечень необходимых мероприятий, оценивает продолжительность подготовки к ремонту, его стоимость и наличие необходимых расходных материалов или запасных частей на складе.

Рис. 6 Алгоритм планирования работ по заказу

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

Работа в АИС

АИС содержит подсистемы, которые в свою очередь разделены на функциональные модули.

Регистрационная подсистема состоит из функциональных модулей:

Модуль регистрации взаимодействует с модулем Личного кабинета. Позволяет пользователю регистрироваться в ИС. Как только пользователь войдет в ИС, на заставке отобразится регистрационная форма, будет проверено интернет-соединение между клиентом и сервером. На форме отображаются поля для заполнения: логин, пароль. Модуль взаимодействует с модулем уведомлений и отображает на экране приложения уведомление об успешной регистрации.

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

Для регистрации пользователя был разработан алгоритм, по которому:

·       Пользователь заполняет регистрационную форму.

·       Администратор на введенный электронный адрес высылает письмо со ссылкой для входа и ввода пароля;

·       Пользователь выводит на экран полную регистрационную форму с полями.

·       Пользователь добавляет данные и сохраняет их в базу данных (автоматически);

·       Пользователь зарегистрирован и может работать в АИС.

Модуль аутентификации взаимодействует с сервером приложений и считывает регистрационные данные пользователя. Проверяет введенные пользователем данные на корректность. Авторизует пользователя по логину и паролю. После авторизации пользователю предоставляются права.

При запуске программы пользователя встречает окно авторизации, где из выпадающего списка можно выбрать логин пользователя, после чего необходимо ввести пароль выбранной учетной записи. После выбора логина и ввода пароля необходимо нажать кнопку «Авторизоваться», после чего в базу данных будет отправлен запрос с проверкой логина. Если пароль верный, то открывается главное меню программы, в противном случае пользователь получает сообщение о том, что пароль неверный и может попробовать еще раз. Кнопка «Выход» отвечает за выход из приложения. Интерфейс окна авторизации показан на следующем рисунке 7,

Рис. 7 Интерфейс окна авторизации

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

В ИС так же присутствует возможность редактирования информации о сотрудниках. При попадании на данную форму необходимо выбрать логин из выпадающего списка и в дальнейшем из базы будет получена информация: пароль, имя пользователя, его заработная плата, ID Точки, где сотрудник работает. При необходимости эту информацию можно подкорректировать и нажать кнопку «Обновить», которая отправит запрос к базе и обновит всю информацию. Если же потребуется удалить данного пользователя, то нужно просто нажать «Обновить». После чего пользователь получит сообщение «Данные успешно обновлены», если никаких проблем не возникло.

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

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

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

Рис. 8 Регистрация клиентов

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

Рис. 3.9 Форма заказа

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

Рис. 10 Заказ на ремонт

На рис 11 показано окно приложения, в котором можно получить основную информацию по каждой из точек: ID точки, её префикс, количество аппаратов в работе, ожидающих запчасть, не начавших ремонт (приняты в ремонт и ожидает очереди на диагностику), не готовые (все работы были обговорены на момент приема и нужно только выполнить ремонт), на согласовании, согласованные, на выдаче (ожидают, когда их заберет клиент).

Рис. 11 Макет приложения

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

Рис. 12 Окно обслуживания

Для отчетности возможен вывод графика, на рисунке 13 представлен график выполненного объема работ всех мастеров. Таким образом, можно оценить нагрузку на мастера.

Рис. 13 График выполненных работ

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

Оценка затрат на внедрение АИС

Основные задачи ИС:

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

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

·       Хранение данных с различной структурой.

·       Анализ и прогнозирование информационных потоков.

·       Изучение методов представления и хранения информации,

·       Построение процедур и технических средств

·       Создание информационно-поисковых систем

·       Создание сетей для хранения, обработки и передачи информации.

Конкретные задачи, которые должна выполнять ИС, зависят от прикладного домена, для которого она предназначена.

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

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

Тестирование проводится силами командой проекта, сторонние лица не должны привлекаться.

Суммарные затраты реализации ИС составляют:

Оборудование 150 000 р.

Лицензия ПО 150 000 р.

Разработка/внедрение и сопровождение 720 000 р.

Дополнительные расходы на оплату часов не предусматриваются, работа проводится в рабочие часы. Стоимость одного сотрудника за 6 месяцев составляет 240 000 р.

Сумма проекта: 1 020 000 рублей

 

Вывод

В процессе проектирования выполнены следующие работы:

·       проведена технико-экономическое характеристика ООО «Онлайн-Касса.ру»;

·       проведён анализ деятельности менеджера и мастера сервисного центра;

·       обоснована необходимость создания ИС;

·       сформулировано назначение ИС учета деятельности сервисного центра;

·       произведён выбор прикладного программного обеспечения;

·       произведены выбор и обоснование проектных решений;

·       произведено проектирования баз данных, интерфейса, определены входные и выходные данные для ИС;

·       разработан учёт деятельности сервисного центра.

Система удовлетворяет требованиям, предъявляемым к АИС, а также реализует функции, которые требуются сотрудникам сервисного центра:

o   Реализованы сбор и регистрация информационных ресурсов;

o   Реализовано хранение информационных ресурсов;

o   Реализована обработка информационных ресурсов;

o   Реализована актуализация информационных ресурсов;

o   Реализовано предоставление информационных ресурсов пользователям.

В результате внедрение ИС может способствовать:

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

·         освобождение работников от рутинной работы за счёт её автоматизации;

·         обеспечение достоверности информации;

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

·         уменьшение затрат на оказание услуг.

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

 

 

Литература

1.      Автоматизация сервисных центров, служб и представительств [Электронный ресурс]: - Электрон. дан. — М. [201-]. - Режим доступа: http://sc-soft.ru/

2.      Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2015. – 624 с.

3.      Архангельский А.Я. Программирование в Delphi. — М: Бином, 2007.

4.      Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. — М.: ДМК Пресс, 2006. — 496 с.: ил. ISBN 5-94074-334-X.

5.      Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 2010.

6.      ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».

7.      ГОСТ 24.701-86 «Надежность автоматизированных систем управления».

8.      ГОСТ 34.603-92 «Виды испытаний автоматизированных систем».

9.      ГОСТ 34602-89 «Техническое задание на создание автоматизированной системы».

10.  ГОСТ Р 50571.22-2000 «Электроустановки зданий».

11.  Дейт К. Введение в системы баз данных/Пер. с англ. М.: Наука, 2008. 463с.

12.  Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.

13.  Загрузка СУБД MS SQL Express: https://www.microsoft.com/en-us/cloud-platform/sql-server

14.  Кауфельд Д, Метозой Осе Ассезз для «чайников»: Пер. с англ. — М: «Диалектика», 2009. — 320 стр. с ил.

15.  Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.

16.  Липаев В.В Управление разработкой программных средств. Методы, стандарты, технология. — М.: Финансы и статистика, 2009.

17.  Оскерко В.С. Пунчик З.В. Практикум по технологиям баз данных. — Мн: «БГЭУ», 201. - 170.

18.  Основы UML https://www.intuit.ru/studies/courses/1007/229/info

19.  Практическое руководство по программированию / Пер. с англ. Б. Мик, П. Хит, Н. Рашби и др.; под ред. Б. Мика, П. Хит, Н. Рашби. — М.: Радио и связь — 168 с., ил.

20.  Принципы проектирования и разработки программного обеспечения. Учебный курс МСЗР. М.: Русская редакция, 2010.

21.  РД «Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации» (Гостехкоммисия, 1992).

22.  Смирнова, Г.Н. Проектирование экономических информационных систем: Учеб. для вузов / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. - М. : Финансы и статистика, 2009. - 512 с. : ил.

23.  Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. Рефакторинг: улучшение существующего кода = Refactoring: Improving the Design of Existing Code (2000). — Спб: Символ-Плюс, 2009. — 432 с. ISBN 5-93286-045-6.

24.  Фуфаев ДЭ. Фуфаев Э.В. Базы данных. —М.: “Академия”, 2010. — 320 с.

25.  Хотяшов Э.Н. Проектирование машинной обработки экономической информации. М.Финансы и статистика, 2009.-246 с.