- •Аннотация
- •Реферат
- •Оглавление
- •Введение
- •Объект исследования и проектирования
- •Характеристика деятельности организации оао «нэск-электросети»
- •Место и цели существования ремонтной службы оао «нэск-электросети»
- •Сценарий бизнес-процессов организации рассмотрения заявок абонентов об обесточивании в ремонтной службе оао «нэск-электросети»
- •Дискретно-событийная математическая модель процесса устранения обесточивания абонентов
- •Проблемы ремонтной службы оао «нэск-электросети»
- •Постановка цели и задачи дипломной работы
- •2 Оптимизация деятельности ремонтной службы оао «нэск-электросети»
- •Оптимизация математической модели процесса устранения обесточивания абонентов
- •Определение способа реализации оптимизированной математической модели
- •Case-средства моделирования, используемые в работе
- •Оптимизированная модель деятельности ремонтной службы оао нэск-электросети
- •Требования к проектируемой информационной системе ремонтной службы
- •3 Проектирование информационной системы мониторинга доступности ремонтных бригад оао «нэск-электросети»
- •Обзор информационных систем для мониторинга доступности и отправки заданий работникам в рамках ремонтной службы
- •Сравнительный анализ рассмотренных систем
- •Выбор архитектуры информационной системы
- •Проектирование структуры информационной системы мониторинга доступности ремонтных бригад
- •Проектирование модели данных для информационной системы сектора сопровождения отдела управления сетями связи
- •4 Реализация информационной системы мониторинга доступности ремонтных бригад ремонтной службы оао «нэск-электросети»
- •Выбор средств реализации
- •Выбор операционной системы.
- •Выбор субд
- •Выбор системы управления сайтом
- •Алгоритм работы информационной системы мониторинга доступности ремонтных бригад ремонтной службы оао «нэск-электросети»
- •5 Социальный аспект разработки
- •Заключение
Алгоритм работы информационной системы мониторинга доступности ремонтных бригад ремонтной службы оао «нэск-электросети»
Опишем кратко процесс работы с системой для пользователей. Сделаем это в виде следующего алгоритма:
Инициатор создает новую заявку, в которой он классифицирует и описывает задачу или проблему. Созданной заявке автоматически присваивается статус «Открыта», после чего по электронной почте отправляется оповещение всем лицам, подлежащим оповещению о создании новой заявки. Эти лица указываются в настройке системы. В дальнейшем, инициатор может видеть в списке своих заявок все созданные им заявки. Он может добавлять комментарии по всем незакрытым заявкам. В историю заявки автоматически записывается дата ее создания, описание проблемы и все комментарии, добавленные инициатором. Инициатором заявки может быть пользователь с любой другой ролью.
Пользователи с ролью диспетчер видят все открытые заявки. Они могут отредактировать каждую из них, уточнив ее классификацию, добавив свои комментарии, выбрав исполнителей, назначив приоритет и крайний срок заявки. Диспетчер может сразу закрыть заявку. Если диспетчер не закрыл заявку, то он должен назначить исполнителей. После того, как диспетчер выбрал исполнителей, он может изменить статус заявки на «Назначен исполнитель». Изменение статуса не производится автоматически, так как исполнителей может быть несколько и их состав, возможно, надо будет уточнить. После изменения статуса заявки на «Назначен исполнитель» инициатору заявки приходит письмо о назначении исполнителей по его заявке. Все изменения, внесенные диспетчером, автоматически протоколируются в истории. После изменения статуса заявки автоматически отсылается сообщения назначенным исполнителям.
Исполнители видят все незакрытые заявки, где они назначены. Если у исполнителя есть флаг руководителя, то он может выполнять все действия диспетчера, в том числе менять исполнителей. Сообщение о смене исполнителей приходят инициатору заявки. Если исполнитель не является руководителем, то он может только добавлять комментарии и перевести заявку в состояние «Исполняется». В результате этого, инициатору заявки приходит письмо с уведомлением о начале работ по его заявке. После завершения работы исполнитель указывает потраченное время и переводит заявку в состояние «На проверке». Об этом инициатор заявки и руководитель уведомляется по электронной почте.
Руководитель и инициатор могут отправить заявку со статусом «На проверке» обратно на доработку или закрыть ее. Пользователи с этой ролью оповещаются об изменении статуса по электронной почте.
5 Социальный аспект разработки
В моей дипломной работе был создан проект информационной системы Мониторинга доступности ремонтных бригад для ремонтной службы ОАО «НЭСК-ЭЛЕКТРОСЕТИ». Наиболее очевидная задача отдела - реагирование на запросы абонентов и ликвидация обрывов на линии, а главная стратегическая цель в данном случае заключается в повышении качества обслуживания абонентов. Поэтому в спроектированной системе, предназначенной для автоматизации ремонтной службы, имеется широкий спектр возможностей, оптимизирующих взаимодействие с пользователями.
Благодаря гибкой интеграции информационная система мониторинга доступности ремонтных бригад предоставляет специалистам мгновенный доступ к новым заданиям. Наличие и доступность таких данных значительно увеличивают число проблем, разрешаемых за равные интервалы времени, что повышает продуктивность работы ремонтных бригад.