CC BY
14УДК 658.512:005
Горев Я.Н.
магистр, инженер ООО «Айвок» (г. Москва, г. Зеленоград, Россия)
Абдуллин И.И.
бакалавр, кафедра автоматизированных систем обработки информации и управления Уфимский государственный авиационный технический университет
(г. Уфа, Россия)
ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ОБСЛУЖИВАНИЯ ЗАЯВОК
Аннотация: автоматизированные системы обслуживания заявок становятся все более востребованными в различных областях, таких как обработка клиентских запросов, управление производственными процессами и регулирование трафика в сетях связи. Эта статья представляет проект автоматизированной системы обслуживания заявок, ориентированной на эффективное и быстрое управление потоком заявок, с учетом современных технологий и методов оптимизации.
Ключевые слова: автоматизированная система, обслуживание заявок, клиент-серверная архитектура, распределение ресурсов, масштабируемость, интеграция с существующими системами, аналитика и отчетность, приоритизация заявок, оптимизация процессов.
Введение
На сегодняшний день процесс обслуживания заявок занимает достаточно длительное время, так как в нем участвуют большое количество сотрудников и отделов, а также создается и обрабатывается много бумажной документации.
Современные компании всё больше стремятся повысить эффективность своей деятельности и обеспечить бесперебойное обслуживание клиентов. Процесс обслуживания заявок на устранение несоответствий не частный, но является важным для компании, так как своевременное устранение противоречий может сократить затраты компании [1].
Обоснование необходимости
После внедрения предполагаемой автоматизированной информационной системы (АИС) в компании, ожидается сокращение времени обработки заявок от заказчиков, уменьшение трудозатрат путем оптимизации сотрудников, контроль и прозрачность бизнес-процессов, а также полное замещение бумажных документов на электронные.
Когда заказчик хочет устранить несоответствия, он отправляет заявку в свободной форме по электронной почте руководителю проектного офиса. После прочтения заявки, руководитель создает карточку несоответствия в АИС, внося всю необходимую информацию. Автоматически АИС анализирует причины несоответствия и генерирует план корректирующих и предупреждающих действий, которые будут использоваться мастерами строительных и монтажных работ, ведущими инженерами ОТК и ПТО, в зависимости от характера несоответствия.
После применения корректирующих мер на объекте, указанные сотрудники вносят подтверждающие документы в АИС и уведомляют об устранении инспектора службы строительного контроля и технического надзора. Инспектор затем согласовывает устранение с заказчиком через электронную почту или при личной встрече на объекте. Если заказчик не удовлетворен устранением, инспектор ССК и ТН делает замечания в карточке несоответствия, и процесс повторно проходит через один из отделов. Если заказчик доволен результатом, инспектор изменяет статус устранения.
Подтверждение устранения происходит путем изменения статуса карточки несоответствия начальниками отделов. После этого ведущий инженер по нормоконтролю формирует отчет об устранении несоответствия, который проверяет руководитель проектного офиса и меняет статус устранения. Если статус карточки несоответствия «устранен», отчет автоматически отправляется на электронную почту заказчику.
Таким образом, процесс обслуживания заявок на устранение несоответствий заканчивается. Внедрение АИС позволяет значительно улучшить эффективность и прозрачность этого процесса, оптимизировать трудозатраты и удовлетворить потребности заказчиков. С данным процессом можно ознакомиться на мнемосхеме предполагаемого процесса (см. рис. 1).
Рис. 1. Мнемосхема предполагаемого бизнес-процесса
Компоненты информационного обеспечения задач
В концептуальной информационной модели данных показаны главные характеристики и связи. Построение модели происходит на базе данных о входной, результатной и условно-постоянной информации, которая требуется для выполнения экономических задач.
Методология IDEF1X - язык для семантического моделирования данных, основанный на концепции «сущность-связь».
Главная цель данной модели - отображение данных, их связей друг с другом, а также их взаимосвязей.
IDEF1X используется для формирования графических представлений информационных моделей, которые отражают структуру и семантику информации внутри среды или системы. Эта методология дает возможность при помощи обычных графических изображений воспроизводить связи и различия между:
- существующими в реальности элементами и относящейся к ним информацией;
- физическими и теоретическими взаимозависимостями между реальными элементами;
- структурой данных, применяемых для получения и использования информации.
IDEF1X позволяет строить семантические модели данных, которые могут служить для поддержки управления данными как ресурсом, интеграции информационных систем и построения компьютерных баз данных. Этот стандарт является частью семейства языков моделирования IDEF в области программной инженерии [2].
Фрагмент информационной модели содержит следующие сущности:
- причина несоответствия;
- несоответствие;
- несоответствие заявки;
- заказчик;
- заявка;
- отчет по устранению;
- сотрудник;
- отдел;
- должность;
- акт;
- акт по монтажу;
- акт по техническому контролю;
- акт производственной практики;
На данной информационной модели отражены основные характеристики и логические взаимосвязи.
Между сущностями «Отчет по устранению» и «Заявка» отношение «один-ко-многим», так как по одной заявки может быть несколько отчетов, а у один отчет принадлежит только одной заявке.
Между сущностями «Заявка» и «Несоответствие заявки» отношение «один-ко-многим», потому что у одной заявки может быть немного несоответствий в заявке, а несоответствие заявки принадлежит только одной заявке.
Между сущностями «Несоответствие» и «Несоответствие заявки» отношение «один-ко-многим». У одного несоответствия может быть в нескольких несоответствий заявке, а несоответствие заявки может иметь только одно несоответствие.
Мощность отношения «Причина несоответствия» и «Несоответствие» «один-ко-многим», так как несоответствие может иметь несколько причин несоответствий, а одна причина несоответствия может иметь только одно несоответствие.
Отношение «Отчет по устранению» и «Сотрудник» имеет мощность «один-ко-многим». Один отчет может оформлять или утверждать один сотрудник, но один сотрудник может оформлять несколько отчетов.
Между сущностями «Сотрудник» и «Отдел» отношение «один-ко-многим», потому что отдел может иметь несколько сотрудников, а один сотрудник может принадлежать только одному отделу.
Между сущностями «Сотрудник» и «Должность» отношение «один-ко-многим», потому что одну должность могут иметь несколько сотрудников, а один сотрудник может иметь только одну должность.
Мощность отношения «Заявка» и «Сотрудник» «один-ко-многим», так как один сотрудник может принимать несколько заявок, а одна заявка может быть обработана только одним сотрудником.
Отношения «Заявка» и «Заказчик» имеют мощность «один-ко-многим», так как один заказчик может формировать много заявок, но одна заявка формируется одним заказчиком.
Между отношениями «Заявка» и «Акт» мощность «один-ко-многим», потому что одна заявка может иметь много актов, а один акт принадлежит только одной заявке.
На информационной модели имеется неполная категоризация сущности «Акт», которая имеет связь с сущностями «Акт по монтажу», «Акт по техническому контролю» и «Акт производственного контроля» по определенному признаку - вид акта.
Отношение «Акт по монтажу» и «Сотрудник» имеет мощность связи «один-ко-многим», так как один сотрудник может составлять или подтверждать несколько актов, а один акт может составляться или подтверждаться только одним сотрудником.
Мощность отношения «Акт по техническому контролю» и «Сотрудник» «один-ко-многим», так как один сотрудник может составлять или подтверждать
несколько актов, а один акт может составляться или подтверждаться только одним сотрудником.
Между сущностями «Акт производственного контроля» и «Сотрудник» мощность отношения «один-ко-многим», так как один сотрудник может составлять или подтверждать несколько актов, а один акт может составляться или подтверждаться только одним сотрудником.
На рисунке 2 изображен фрагмент информационной модели системы.
Рис. 2. Фрагмент информационной модели системы
Контур управления для объекта автоматизации
Процесс управления системой неизбежно связан с получением информации:
- о состоянии системы в каждый момент времени;
- о достижении (или не достижении) цели управления;
- об отклике системы на управляющее воздействие.
Таким образом, в системе управления всегда присутствует информационный контур, который включает в себя:
- объект управления;
- управляющий и исполнительный органы управления;
- информация об управляемом процессе;
- управляющие воздействия.
Контур управления АИС состоит из следующих контуров:
- контур регулирования;
- контур адаптации;
- контур обучения.
Задачей контура регулирования является принятие управляющего решения на основе поступающей информации. Отслеживание системой изменения и выработка управляющего воздействия лицом, принимающего решения.
Контур адаптации выполняет работу по формированию управляющего воздействия на объект управления в ситуациях, которые не предусмотрены в основном контуре регулирования.
Контур обучения срабатывает при возникновении внештатной ситуации, не предусмотренной системой. В этом случае лицо, принимающее решение разрабатывает новые способы решения, и вносят изменения в систему документооборота, в АИС.
Объект управления - это отдельный элемент или система, воспринимающий управляющие воздействия со стороны субъекта управления (управляющего устройства), получающий команды управления и действующий в соответствии с ними. В качестве объекта управления выступает процесс обслуживания заявок на ремонт компьютерной техники.
Лицо, принимающее решение (ЛПР) - это субъект решения, наделённый определёнными полномочиями и несущий ответственность за последствия принятого и реализованного управленческого решения. В данном контуре, в роли ЛПР - руководитель проектного офиса.
НД - нормативные документы.
В реальных условиях на объект управления оказывают влияние возмущающие воздействия. Эти воздействия вызывают изменение внутреннего состояния объекта и как следствие - рабочих параметров. В связи с этим, для выполнения рабочих функций по заданным алгоритмам необходимо на объект управления организовать подачу управляющих воздействий.
В данном контуре управления возмущающими воздействиями являются:
- отсутствие локального соединения;
- отсутствие сотрудника;
- отсутствие электропитания.
Управляющие воздействия:
- наладить локальное соединение;
- произвести повторное составление отчетности;
- устранить несоответствие;
Входная информация:
- заявка на устранение несоответствия.
Выходная информация:
- отчет об устранении несоответствия;
- фактические значения показателей процесса.
Данный контур управления изображен ниже, на рисунке 3.
Г
Контур обучени |
Рис. 3. Контур управления
Алгоритм работы автоматизированной информационной системы
Для каждого пользователя системы существует свой алгоритм работы в
АИС.
При входе в программу открывается окно для авторизации. Сотрудник выбирает имя пользователя и вводит пароль. Если пароль введен неверно, то пользователю необходимо авторизоваться повторно, в связи с появлением ошибки. Если пароль верный, то сотрудник успешно входит в систему.
В АИС параллельно ведутся работы в системах руководителя проектного офиса, начальника монтажного участка, мастера строительных работ и другие. Схема алгоритма работы АИС представлена на рисунке 4.
Рис. 4. Схема алгоритма работы АИС
Заключение
В данной статье была представлена концепция автоматизированной системы обслуживания заявок, предназначенной для эффективной обработки разнообразных запросов от клиентов или пользователей. Проектирование такой системы включает разработку компонентов информационного обеспечения задач, разработку контура управления для объекта автоматизации и формирование алгоритма работы автоматизированной информационной системы. Предполагаемая система имеет ряд преимуществ, таких как масштабируемость, интеграция с существующими системами, аналитика и гибкие настройки. Она представляет собой ценное средство для организаций, стремящихся повысить эффективность и качество обслуживания клиентов.
СПИСОК ЛИТЕРАТУРЫ:
1. Орешин А.В. Стоимость несоответствий, или оценка затрат на качество // Методы менеджмента качества. 2006. №6. С. 12-16.
2. Kusiak A., Letsche T., Zakarian A. Data modelling with IDEF1x // International Journal of Computer Integrated Manufacturing. 1997. Vol. 10. №6. P. 470-486.
Gorev Ia.N.
Aivok LLC (Moscow, Zelenograd, Russia)
Abdullin I.I.
Ufa State Aviation Technical University (Ufa, Russia)
DESIGNING AN AUTOMATED REQUEST SERVICING SYSTEM
Abstract: automated request servicing systems are becoming increasingly in demand in various fields, such as handling customer inquiries, managing production processes, and regulating traffic in communication networks. This article presents a project of an automated request servicing system focused on efficient and rapid management of request flow, taking into account modern technologies and optimization methods.
Keywords: automated request servicing system, client-server architecture, resource allocation, scalability, integration with existing systems, analytics reporting, request prioritization, process optimization.
