52
Весь документооборот и ведение нужных документов реализовано
только вручную, а для генерации отчетов используется файл MS Excel, куда
переносятся все сведения по результатам обслуживания заказчиков, в рамках
которых потом и осуществляется анализ.
Декомпозиция процесса учета заявки приведена на Рисунке 15.
Рисунок 15 - Декомпозиция процесса учета и распределения заявки
Поэтому процесс учета ремонта считается трудоемким, и менеджер в
рамках данного процесса способен допустить ошибки, что по итогу оказывает
отрицательное влияние на оперативность реализации ремонта.
В процессе реализации своих функциональных обязанностей менеджер
часто имеет некоторые проблемы:
• Плохая продуманность схемы принятия, анализа и передачи
аппаратуры в ремонт, выраженная в обязательной работе «через менеджера»,
что только повышает срок обработки заявок на ремонт и сумму возможного
человеческого фактора;
• Трудность в реализации адекватной оценки результативности
деятельности менеджера;
53
• Уменьшение оперативности обработки заявок на ремонт из-за
повышенного числа запросов;
• Повышение влияния человеческого фактора (ошибки менеджера) в
процессе получения заявок из-за повышенных объемом и общей загрузки;
• Сложность отслеживания совокупной эффективности реализации
заявок специалистами «от А до Я» (исходя из каждого этапа реализации);
• Сложность нахождения ответственных лиц, которые задерживают
процедуру исполнения ремонта.
Все описанные трудности оказывают плохое влияние на совокупную
работу отдела и фирмы. Эти трудности находятся в процессе проведения
внутреннего контроля и изучения построения бизнес-схемы, причем
источником таких проблем часто становится текущий порядок учета деления
заданий и учета функционирования монтажников.
Цель реализации комплекса задач по автоматизации работы менеджера
следующая:
• Повышения уровня ремонта благодаря оперативному реагированию
на текущие нужды;
• Понижение затрат времени;
• Повышения качества работы с заказчиками.
Исходя из полученного прямого эффекта, целью автоматизации данного
комплекса выступают:
• Минимизация длительности расчета комплекса задач;
• Минимизация цены решения;
• Увеличение правильности расчета;
• Повышение точности расчета;
• Повышение аналитической составляющей расчетов;
• Уменьшение штата работников;
• Минимизации длительности рутинных операций и повышение
времени творчества.
54
3.2. Проектирование и реализация АРМ учета работы монтажных бригад
Создание ИС стартует с выражения цели проекта. ИС обязана
поддерживать требуемую функциональность системы и уровень адаптации к
корректирующим требованиям ее работы; достаточную пропускную
способность; минимальные задержки реакции на запрос; полноценную работу;
круглосуточную готовность (24/7) и доступность системы для анализа запросов
от пользователей; удобство поддержки и использования; должный уровень ИБ.
Исходя из исследований, создание ИС включает изучение 3 областей
[28]:
• Подготовку объектов данных, которые будут внедрены в БД;
• Подготовку программ, экранных графиков, форм, отвечающих за
запросы к данным;
• Изучение имеющейся технологичной среды, к примеру: топологии
сети, настройки используемого оборудования, применяемой архитектуры
(файловой или клиент-ориентированной), последовательной или параллельной
обработки данных.
В реальных построение системы — это нахождение варианта,
устраивающего требованиям рабочей среды системы посредством доступных
технологий исходя из заданных ограничений.
Создание ИС включает описание всей систем не нескольких уровнях.
Уровень концепции состоит из основных элементов, связей и дополнительных
систем. Уровень логического описания создает модели, включающие структуру
отдельных дополнительных систем и функционирующие связи между ними. На
уровне физического взаимодействия проходит реализация структуры в рамках
программного и аппаратного компонента.
Исходя из цели ИС системы выделяет круг функций, которые нужно
этой системе реализовать. И по факту данного списка функций ИС готовится
конкретная структура, которая именуется как формальная. Подобный тип
структуры включает совокупность активных элементов и отношений между
ними, требуемых и необходимых для реализации указанной цели для системы.
55
Подобная структура идеальна, т.к. не имеет физической формы восприятия.
Она создается различными средствами, поэтому ей может состоять в
совокупности дополнений. Внешняя среда, работая с ИС, выступает в роли доп.
системы, ставя перед ней конкретные задачи и определяя цели.
Методология реализации прикладных АИС заключается в: процессе
реализации, включающем конкретный набор этапов; вариантов реализации
этапов; средств отображения исходной и итоговой информации всех этапов.
Выполнение анализа классического процесса решения предметных задач
на этапе изначального обследования компании помогает отразить элементы ее
основополагающей деятельности, а именно: определить структуру задач
компании; отразить наиболее значимые задачи, требующие автоматизации;
показать их место обшей структуре задач; разделить (декомпозировать)
конкретную область задачи на отдельные элементы и упорядочить данные для
выбранной задачи в совокупности из каждой составляющей подзадачи.
Начальными данными для реализации данного этапа выступает
информация, принимаемая от специалистов предметной области и рукописных
источников изучаемой компании. Нюансом процесса деления задачи
становится применение совокупных принципов и правил разделения,
базирующихся на использовании типичных и классических алгоритмом.
Концепция предметных задач помогает создать систему знаний
выбранной предметной области и захватить ее в требуемой форме. Суть
создания концепции включает использование процедур, которые связаны с
генерацией концепций исходя из совокупности требуемых предметных задач,
изучения и синтеза моделей. Подготовка отражения концепции предметной
задачи поддерживает нахождение базы для корректировки данных,
применяемых при автоматическом варианте и смысловое единство для
обобщённых языковых влияний данной задачи.
Инфологическое построение задач помогает создать их знаковое
отражение, не зависящее от технических и программных методик реализации
АИС, и зафиксировать его в требуемой форме.
56
Даталогическое моделирование задач связано с необходимостью прямой
адаптации разно уровневых инфо-моделей задач к доступны возможностям
технических и программных средств и методов реализации вычислительной
среды и процесса вычислений. Суть адаптации инфологических моделей
данного вида задач связано с переводом разно-уровневых структур к моно-
уровневым структурам (БД, столбец, таблица), которые возможны в реальных
технических и программных средах и методиках их планирования, а также в
изменении алгоритма исчисления с учетом корректив по доступу к данным.
Еще одним компонентом даталогической модели становится компонент
визуализации, который показывает изменения данных и действий в форме,
которая адекватна для работы и восприятия конечного пользователя в
требуемой программной среде.
Для разработки функциональности системы составлена диаграмма
прецедентов, показанная на рисунке 16.
В соответствии с представленной диаграммой, в системе представлено
два типа пользователей – администратор и сотрудник. Администратор обладает
всей полнотой прав и имеет возможность управлять работой и содержимым
справочников. Сотрудник учитывает заявки, задачи, распределяет их между
бригадами и получает отчетные документы.
Использование разработанной системы позволяет в удобном виде
получить список учтённых заявок в удобном для восприятия виде.
57
Добавление записи
Редактирование пользователя
Удаление пользователя
Добавление пользователя
Работа с заявками
Работа с пользвателями
Оператор
Администратор
Управление справочниками
Клиенты Бригады
Удаление записи
Редактирование записи
Список бригад
Получение отчетности
Календарь с заявками
Список заявок
Аутентификация
Услуги
Пользователи
Добавление заявки
Работа с задачами
Удаление заявки
Редактирование заявки
Рисунок 16 - Диаграмма прецедентов
Для хранения информации в базе данных необходимо учитывать
следующие сущности:
Пользователи;
Тип пользователя;
Задача (заявка);
Бригада;
Статус заявки;
Клиент;
Услуги в задаче;
Услуги.
58
Логическая схема, показывающая связи между описанными
сущностями, приведена на рисунке 17.
Рисунок 17 - Логическая модель базы данных
На основании логической схемы и требуемой функциональности
системы подготовлена физическая модель базы данных, приведённая на
рисунке 18.
Рисунок 18 - Физическая модель базы данных
Рассмотрим далее порядок использования разработанного приложения.
59
Для начала работы пользователь должен пройти авторизацию.
Рисунок 19 -Экранная форма авторизации
После авторизации пользователю доступен список актуальных задач:
Рисунок 20 - Список актуальных задач
Для каждой задачи может быть просмотрен список услуг, данные по
заявке, задача может быть отредактирована или удалена.
60
Рисунок 21 - Перечень услуг
Рисунок 22 - Данные по заявке
Для создания новой задачи предусмотрена специальная форма, в
которой пользователь выбирает клиента (заказчика), бригаду, наименование
услуг, даты выполнения задач.
61
Рисунок 23 - Добавление задачи
Пользователь также заполняет справочники системы, такие, как
пользователи, клиенты, Услуги, монтажные бригады.
Рисунок 24 - Справочник Клиенты