14
небольших мастерских, так и в крупных сетевых компаниях, с разветвленной
сетью приемных пунктов или региональных сервисных центров.
В конфигурации реализовано четкое разграничение прав доступа к
данным, а также ограничение возможностей тех или иных действий
пользователя, в зависимости от его статуса. Такой подход позволяет объединить
в единое информационное пространства сотрудников разных категорий.
Программа является удобным инструментом для эффективного
управления и обладает богатыми функционалом, который постоянно
совершенствуется и расширяется. Программный продукт реализован на
современной платформе 1С:Предприятие 8. Структурно конфигурация
представляет собой набор взаимосвязанных модулей. Рассмотрим некоторые из
них:
1) Модуль «Приемный пункт» предназначен для автоматизации
подразделения, принимающего бракованную технику в стационарный ремонт.
Программа позволяет принимать технику как от физических, так и от
юридических лиц. Для проведения операции приема бракованной техники
применяется документ «Заказ-наряд». В момент ввода документа система
снабжает оператора большим количеством полезной информации о наличии
предыдущих ремонтов данного изделия, о результате проверки возможности его
гарантийного ремонта и т.д. В подсистеме предусмотрена возможность работы
со списком особых клиентов, а также с «черным» списком. Благодаря удобному
интерфейсу оператор может быстро найти нужный заказ-наряд, уточнить его
состояние и текущее местонахождение техники. Для оценки эффективности
рекламных кампаний в документе можно указать источник появления у клиента
информации о центре;
2) Модуль «Стационарный ремонт»: для автоматизации цеха
стационарного ремонта в системе реализован специальный интерфейс
«Рабочий стол мастера стационарного ремонта». Интерфейс проектировался
таким образом, чтобы работа мастера с программой не отвлекала его от
выполнения основной работы. С его помощью мастер может оформить прием
15
изделия в ремонт, заказать запасные части, зарезервировать запасные части под
«Заказ-наряд», отследить выполненные заказы, ввести данные о ходе ремонта и
т.д. Подсистема контроля времени ремонта техники позволяет администрации
сервисного центра своевременно выявлять технику, время ремонта которой
превысило заданные нормативы;
3) Для автоматизации работы диспетчерской службы, принимающей
заявки на выездное сервисное обслуживание, в системе реализован отдельный
интерфейс «Диспетчерская служба». Виды заявок, а также перечень вопросов,
которые диспетчер задает клиенту в момент приема заявки, проектируются в
пользовательском режиме. Это позволяет в максимально короткие сроки
адаптировать подсистему к задачам диспетчерской службы конкретного
сервисного центра. Для более комфортной работы диспетчера в системе
реализован помощник ввода заявки.
Система позволяет контролировать перечень и последовательность
вопросов, которые диспетчер задает клиенту, а также отсекать вопросы,
необходимость в которых исчезла. Например, в ходе диалога выяснилось, что
заявка является платной. Поле «Номер гарантийного талона» в этом случае уже
не является обязательным для заполнения и автоматически исчезает из диалога,
после того как оператор установил признак платной заявки. Еще одним видом
помощи диспетчеру является файл, прикрепленный к каждому вопросу.
Например, в момент определения вида заявки (платная или гарантийная)
диспетчер должен проверить подлинность гарантийного талона, и для этого ему
необходимо видеть его форму. Форма талона в системе находится в файле,
который прикреплен к соответствующему вопросу.
Для облегчения процесса подбора мастеров для выполнения заявок в
системе реализован механизм предварительного распределения, который
позволяет подобрать мастеров, оптимально подходящих для конкретной заявки.
Следует отметить, что для каждого мастера в информационной базе хранится
информация о его текущем расписании, предельной норме загрузки, зоне
обслуживания, а также о видах выполняемых работ. После того как диспетчер
16
заполнил заявку, система автоматически сверяет данные в заявке с этой
информацией и формирует список специалистов, оптимально удовлетворяющих
конкретной заявке. Если первоначальное распределение необходимо изменить,
то это можно сделать визуально, при помощи технологии перетаскивания
(Drag&Drop).
В системе также реализованы отслеживание состояния заявок,
регистрация отказов, оформление предварительных заказов запасных частей и
т.д. Для оценки эффективности работы диспетчерской службы предусмотрен
универсальный отчет, позволяющий проводить анализ в разных разрезах;
4) Модуль «Склад запасных частей и аксессуаров»: в складской
подсистеме полностью реализованы потребности сервисной компании в
ведении складского учета. Учет ведется в разрезе серийных номеров и торговых
марок. Для каждой запасной части хранится список кодов замены и аналогов.
Это позволяет существенно снизить складские неликвиды за счет более гибкого
использования номенклатурной базы. Подсистема обеспечивает выполнение
всех необходимых складских операций, включая поступление, возврат,
реализацию, инвентаризацию, списание, перемещение к мастеру и обратно и
т.д. Она содержит расширенный список отчетов, которые позволяют
анализировать состояние склада;
5) Модуль «Склад аппаратов»: для ведения складского учета изделий,
принятых в ремонт, предназначена отдельная подсистема. Учет в подсистеме
реализован по изделиям индивидуальным единицам хранения. В рамках
подсистемы реализована работа со штрихкодом. Наклейка на каждое изделие
этикетки со штрихкодом и его последующее считывание позволяют
значительно ускорить работу кладовщиков;
6) Модуль «Работа с производителями»: данная подсистема
предназначена для упрощения взаимодействия сервисного центра с
производителями техники. Это особо актуально для крупных сервисных
центров, авторизованных у многих производителей. В подсистеме реализована
возможность кодирования ремонтов, которая позволяет в пользовательском
17
режиме создавать и хранить произвольную систему кодирования, принятую у
любого производителя. Для подготовки отчетов по выполненным гарантийным
ремонтам разработан единый интерфейс, обеспечивающий формирование
отчетов исходя из индивидуальных требований производителя в различных
форматах - xls, mdb или txt. Кроме того, сегодня система содержит формы
отчетов для более чем 20 ведущих производителей.
Корс Сервис-Центр от компании ООО «КОРС» предназначен для [3]:
учета в сервисных центрах, гарантийных мастерских и других фирмах,
занимаюшихся продажей, ремонтом и обслуживанием теле, аудио, видео,
бытовой техники, компьютеров, принтеров и любого другого оборудования;
полного учета серийных номеров на оборудование и детали (начиная с
приходов деталей на склад и заканчивая установки деталей на оборудование
клиента);
учет труда сотрудников фиксирование исполнителей работ в заказах-
нарядах и их тарифа, расчет и выдача зарплаты;
полного учета работ в Сервис-Центре: оформление заказов-нарядов,
отслеживание этапов выполнения работ и оплат.
Основные возможности программы Корс Сервис-Центр:
удобное и простое составление заказов-нарядов;
учет этапов выполнения работ и оплат для каждого заказа-наряда;
учет на различных фирмах/подразделениях/складах;
учет исполнения одной работы несколькими исполнителями;
полный учет серийных номеров на детали во всех операциях (приходы,
перемещения, возвраты, заказы-наряды, акты);
отслеживание остатков деталей с детализацией по серийным номерам;
возможность резервирования («бронирования») серийных номеров;
18
учет заработанного исполнителями как на основании %, так и на
основе фиксированного тарифа;
полный учет взаиморасчетов с сотрудниками (зарплата, долги, сумма
выработки);
ведение склада: состояние, приходы, уходы и перемещения;
учет: типов ремонта, приемщиков заказов, кошельков (касса,
расчетный счет и т.д.) ;
ведение учета по разным фирмам с раздельной нумерацией
документов;
учет денежных операций: расходы, приходы и перемещения;
автоматическое заполнение данных заказа-наряда на основе «истории
клиента»;
оплаты поставщикам, ведение взаиморасчетов с поставщиками;
справочник пользователей с паролями и правами на каждый из
режимов;
более 15 печатных форм документов (заказ-наряд, заявка, гарантийный
талон, счет, акт и т.д.);
справочник марок/моделей и справочник неисправностей для быстрого
заполнения заказа-наряда;
архивация/разархивация и проверка базы данных.
Поскольку автор данной работы является сотрудником
автоматизируемого подразделения, то в качестве способа реализации
поставленной задачи были выбраны разработка и внедрение индивидуальной
автоматизированной системы контроля и учета заявок абонентов на
подключение к сети интернет собственными силами, опираясь на имеющиеся
знания и навыки. Это позволит избежать таких недостатков стороннего ПО,
предназначенного для автоматизации «любого» предприятия как необходимость
достаточно крупных вложений финансовых средств и необходимость настройки
19
приобретаемого программного обеспечения на конкретные условия работы, а
также избыточность функций.
1.5 Обоснование проектных решений
1.5.1 Обоснование проектных решений по информационному
обеспечению
Документы, получаемые от внешних объектов и передаваемые им,
должны храниться как в базе данных, так и на бумажных носителях.
Должна использоваться система управления базами данных (СУБД),
основанная на реляционной модели баз данных (БД). Полномочия
пользователей по работе с данными должны определяться в зависимости от
выполняемых ими функций.
Для работы с постоянной и условно-постоянной информацией, с
некоторым множеством значений в системе должны использоваться объекты
типа «Справочники».
При вводе должен производиться контроль вводимых данных путем
проверки установленных ограничений, выполнение заданных условий.
Для обеспечения хранения данных можно использовать локальную или
распределенную базу данных. Поскольку предполагается возможность работы
одновременно нескольких сотрудников с программой, в данном проекте
целесообразно использовать распределенную базу данных.
Предполагаются следующие информационные решения, касающиеся
разрабатываемого программного средства [4]:
сбор исходной информации, вводимой в базу данных, осуществляется
распределенно, т.е. информация для базы данных может быть введена с любого
рабочего места, где установлена программа;
ввод информации в базу данных осуществляется вручную с бумажных
носителей. Информация записывается в базу автоматически;
обработка данных осуществляется в диалоговом режиме;
20
пользователь получает информацию из базы данных на экран
персонального компьютера (ПК), кроме того, информация может выдаваться на
принтер;
резервирование базы данных осуществляется при помощи сохранения
базы данных на магнитном носителе, а восстановление – при помощи
копирования базы данных с магнитного носителя на ПК в тот каталог, где
должна находиться база данных;
база данных состоит из одного файла, имеющего расширение «.mdb»
(формат Microsoft Access 2000/2003).
Технология внутримашинной организации задается
последовательностью реализуемых процедур схем взаимосвязи программных
модулей и информационных массивов. Такая схема представляет собой
декомпозицию общего процесса решения задачи на отдельные процедуры
преобразования массивов, именуемыми модулями (это ввод, контроль,
перезапись информации с одного носителя на другой, сортировка, уплотнение
данных, редактирование, накопление, вывод на печать и т.п.) [5].
В проектируемой системе решаемые задачи будут реализованы
соответствующим программным модулем, каждый из которых будет иметь
возможность выполнения ряда операций, таких как корректировка информации,
поиск данных, формирование отчетов. Процессы заполнения, корректировки и
поиска данных будут реализованы однотипным способом во всех модулях. При
добавлении и редактировании данных будет применяться контроль
правильности ввода пользователем информации, путем ее сравнения с
необходимым типом, диапазоном изменения возможных значений, маской ввода
и т.д.
Для добавления и редактирования данных будут использованы экранные
формы со всеми необходимыми полями ввода, а также пояснениями и
управляющими элементами (например, кнопками), предназначенными для
выработки управляющих воздействий (сохранение, отмена изменений) и
навигации (перемещению) по БД. Для обеспечения поиска данных также будут
21
использованы экранные формы, позволяющие задавать различные значения
(диапазоны значений) интересующей информации, с контролем допустимости
значений условий поиска. Поиск информации можно будет производить на
частичное, либо полное совпадение условий поиска. В программных модулях
системы предполагается наличие всех необходимых отчетных форм для
формирования и печати документов установленной формы. Все отчеты
генерируются автоматически, на основе выборки информации из БД.
1.5.2 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение представляет комплекс технических средств
для обработки данных в информационной системе. В состав комплекса входят
компьютеры, осуществляющие обработку экономической информации, средства
подготовки данных на машинных носителях, средства сбора и регистрации
информации, средства передачи данных по каналам связи, средства накопления
и хранения данных и выдачи результатной информации, вспомогательное
оборудование и организационная техника [4].
Разрабатываемая АИС должна быть предназначена для работы на ПК с
характеристиками:
– процессор Intel Celeron 1700 или выше;
– оперативная память 512 Мб или больше;
– свободное пространство на жестком диске 40 Гб или больше;
– видео карта 512 Мб или больше;
– клавиатура (PS2/USB);
– мышь (PS2/USB);
– монитор 15 дюймов или больше.
Для печати отчетов: 1 лазерный принтер формата А4.
22
2 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
2.1 Проектирование базы данных
Технология создания информационных систем предъявляет особые
требования к методикам реализации и программным инструментальным
средствам. Реализацию проектов по созданию информационных систем
принято разбивать на стадии анализа (прежде чем создавать информационных
систем, необходимо понять и описать бизнес-логику предметной области),
проектирования (необходимо определить модули и архитектуру будущей
системы), непосредственного кодирования, тестирования и сопровождения.
Сущность структурного подхода к разработке информационных систем
заключается в ее декомпозиции (разбиении) на автоматизируемые функции:
система разбивается на функциональные подсистемы, которые в свою очередь
делятся на подфункции, подразделяемые на задачи и так далее. Процесс
разбиения продолжается вплоть до конкретных процедур. При этом
автоматизируемая система сохраняет целостное представление, в котором все
составляющие компоненты взаимоувязаны. Основные этапы, на которые
разбивается процесс проектирования информационной системы, следующие
[1, 9]:
– концептуальное проектирование – сбор, анализ и редактирование
требований к данным (обследование предметной области, изучение ее
информационной структуры, выявление всех фрагментов, каждый из которых
характеризуется пользовательским представлением, информационными
объектами и связями между ними, процессами над информационными
объектами, моделирование и интеграция всех представлений);
– логическое проектирование – преобразование требований к данным в
структуры данных. На выходе получаем СУБД-ориентированную структуру
базы данных и спецификации прикладных программ;
– физическое проектирование – определение особенностей хранения
данных, методов доступа и т.д.
23
Основными конструктивными элементами моделей являются сущности,
связи между ними и их свойства (атрибуты). Сущность – любой различимый
объект (объект, который мы можем отличить от другого), информацию о
котором необходимо хранить в базе данных. Логическая структура базы данных
– это описание состава, типа и длины информационных единиц базы данных и
связей между ними [10].
Сущности и связи модели данных представляются в виде реляционной
таблицы (отношения). Отношение, соответствующее сущности, содержит
атрибуты (столбцы), являющиеся атрибутами сущности и описывающие
сущность (объект). Атрибут или множество атрибутов, которые однозначно
определяют объект называются первичным ключом [10].
Удобно представлять отношение как таблицу, где каждая строка есть
кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом
называются атрибутами и им присваивают имена. Список имён атрибутов
называется схемой отношения. Совокупность схем отношений, используемых
для представления информации, называются схемой базы данных, а текущие
значения соответствующих отношений – базой данных [10].
Процесс построения инфологической модели состоит из следующих
шагов [11]:
– определение сущностей;
– определение зависимостей между сущностями;
– задание первичных и альтернативных ключей;
– определение атрибутов сущностей;
– приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели – это абстрактный взгляд на
данные, на нем данные представляются так, как выглядят в реальном мире.
Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД. Физическая модель данных, напротив, зависит
от конкретной СУБД, фактически являясь отображением системного каталога. В
физической модели содержится информация обо всех объектах БД. Поскольку