Информационная система мониторинга доступности ремонтных бригад

Размещено на http://www.allbest.ru/

"Информационная система мониторинга доступности ремонтных бригад ОАО "НЭСК-электросети"

Южный федеральный университет



Аннотация

В дипломной работе отражены основные результаты проектирования информационной системы, предназначенной для усовершенствования деятельности ремонтной службы ОАО "НЭСК-Электросети".

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

Выполнение работы основано на анализе структуры, целей и функций ОАО "НЭСК-электросети", а также на результатах визуального и математического моделирования предметной обрасти и ее бизнес-процессов.

Рассмотрены вопросы безопасности и экологичности проекта, приведено технико-экономическое обоснование проекта.



Реферат

116 стр., 13 рис., 13 таб., библиогр. 11

ИНФОРМАЦИОННАЯ СИСТЕМА, СБОР И ВЫДАЧА ИНФОРМАЦИИ, РЕМОНТНЫЙ ОТДЕЛ

Во введении рассматривается актуальность разработки проекта.

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

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

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

Основные результаты дипломного проекта отражены в заключении.



Оглавление

Введение

1. Объект исследования и проектирования

1.1 Характеристика деятельности организации ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

1.2 Место и цели существования ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

1.3 Сценарий бизнес-процессов организации рассмотрения заявок абонентов об обесточивании в ремонтной службе ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

1.4 Дискретно-событийная математическая модель процесса устранения обесточивания абонентов

1.5 Проблемы ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

1.6 Постановка цели и задачи дипломной работы

2. Оптимизация деятельности ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

2.1 Оптимизация математической модели процесса устранения обесточивания абонентов

2.2 Определение способа реализации оптимизированной математической модели

2.3 CASE-средства моделирования, используемые в работе

2.4 Оптимизированная модель деятельности ремонтной службы ОАО НЭСК-ЭЛЕКТРОСЕТИ

2.5 Требования к проектируемой информационной системе ремонтной службы

3. Проектирование информационной системы мониторинга доступности ремонтных бригад ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

3.1 Обзор информационных систем для мониторинга доступности и отправки заданий работникам в рамках ремонтной службы

3.2 Сравнительный анализ рассмотренных систем

3.3 Выбор архитектуры информационной системы

3.4 Проектирование структуры информационной системы мониторинга доступности ремонтных бригад

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

4. Реализация информационной системы мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

4.1 Выбор средств реализации

4.2 Алгоритм работы информационной системы мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

5. Социальный аспект разработки

Заключение

Список литературы



Введение

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

В связи с тем, что в ОАО "НЭСК-ЭЛЕКТРОСЕТИ" имеется множество территориально отдаленных пунктов, качество и скорость работы ремонтного отдела встает на первый план в группе задач обеспечения эффективной работы предприятия.

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

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



1. Объект исследования и проектирования

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

1.1 Характеристика деятельности организации ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

Открытое акционерное общество "Независимая энергосбытовая компания Краснодарского края", именуемое в дальнейшем "Общество", создано в соответствии с Гражданским кодексом Российской Федерации, Федеральным законом "Об акционерных обществах", иными федеральными законами и нормативными правовыми актами. Сокращенное фирменное наименование Общества на русском языке - ОАО "НЭСК-ЭЛЕКТРОСЕТИ", на английском языке - JSC "IESC".

Место нахождения Общества: Российская Федерация, г. Краснодар, ул. Северная, 247.Почтовый адрес Общества: 350049, Российская Федерация, г. Краснодар, ул. Северная, 247.

Правовое положение Общества определяется Гражданским кодексом Российской Федерации, Федеральным законом "Об акционерных обществах", иными нормативными правовыми актами Российской Федерации, а также настоящим Уставом.

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

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

- поставка (продажа) электрической и тепловой энергии по установленным тарифам в соответствии с диспетчерскими графиками электрических и тепловых нагрузок;

- получение (покупка) электрической энергии с оптового рынка электрической энергии (мощности);

- получение (покупка) тепло- и электроэнергии у их производителей и др.;

Уставный капитал Общества составляется из номинальной стоимости акций Общества, приобретенных акционерами (размещенных акций). Уставный капитал Общества составляет 4 070 260 (четыре миллиона семьдесят тысяч двести шестьдесят) рублей. Обществом размещены следующие категории именных бездокументарных акций одинаковой номинальной стоимостью 10 (десять) рублей каждая: Обыкновенные именные акции:

- 407 026 (четыреста семь тысяч двадцать шесть) на общую сумму по номинальной стоимости 4 070 260 (четыре миллиона семьдесят тысяч двести шестьдесят) рублей.

Структура акционерного капитала Общества представлена в таблице 1.

Общее количество акционеров 68, в том числе юридических лиц - 39, физических - 29.

Общество состоит из 26 филиалов на территории Краснодарского края, осуществляющих деятельность по сбыту электрической энергии, а также представительство в г. Москве. Кроме того, по состоянию на 31.12.2009, Компания имеет два дочерних Общества: ОАО "НЭСК-ЭЛЕКТРОСЕТИ-электросети" и ООО "Энергосервис".

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

На основании акт разграничения балансовой принадлежности рассчитываются потери электроэнергии.

После оформления документов потребителя подключают на основании заявки.

Таблица 1.1 - Структура акционерного капитала Общества по состоянию на 31.12.2009 г.

Ф.И.О. (полное наименование)	Вид зарегистриро-ванного лица	Количество ценных бумаг	Доля в уставном капитале
ADWAR ENERGY LTD. (Акционерная компания "ЭДВОРЭНЕРДЖИ ЛТД.")	владелец	25 439	6.25%
Energy Holdings Management Ltd. ("Энерджи ХолдингсМенеджмент Лтд.")	владелец	62 031	15.24%
Закрытое Акционерное Общество "Депозитарно-Клиринговая Компания"	номинальный держатель	105 827	26.00%
Открытое акционерное общество "Национальныйбанк развития бизнеса"	номинальный держатель	86 335	21.21%
Краснодарский край в лице Краевого государственного специализированного учреждения "Фонд государственного имущества Краснодарского края"	владелец	51 000	12.53%
Иные миноритарные акционеры	владелец	76 394	18.77%
Всего	407 026 именных Обыкновенных акций	100%

Структура компании показана на рисунке 1.1.

Рисунок 1.1 - Структура ОАО "НЭСК-ЭЛЕКТРОСЕТИ" Электросети

Основные стратегические цели и задачи ОАО "НЭСК-ЭЛЕКТРОСЕТИ":

· достижение целей реформирования коммунальной электроэнергетики Краснодарского края;

· обеспечение надежного и бесперебойного энергоснабжения потребителей электроэнергии

· обеспечение баланса интересов собственников ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

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

· совершенствование системы корпоративного управления.Виды деятельности

· покупка электрической энергии на оптовом рынке электрической энергии

· сбыт электроэнергии организациям и физическим лицам.

Продукция и услуги

Сбыт электроэнергии производится:

· в соответствии с договорными объемами электропотребления в пределах мощности, разрешенной техническими условиями на присоединение

· на границе балансовой принадлежности электросети показатели качества электроэнергии должны соответствовать ГОСТу 13109-97.

Органы управления компаниии

- Общее собрание акционеров;

- Совет директоров;

- Генеральный директор.

Уровни управления в ОАО "НЭСК-ЭЛЕКТРОСЕТИ" показаны на рисунке 1.2

Рисунок 1.2 - Уровни управления ОАО "НЭСК-ЭЛЕКТРОСЕТИ" Электросети

1.2 Место и цели существования ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

Ремонтная служба относится к службам обеспечения. Организационная структура ремонтной службы приведена ниже (см. рисунок 1.3).

Рисунок 1.3 - Организационная структура ремонтной службы

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

1. Начальник службы - 1 ставка;

2. Ведущий инженер - 1 ставка;

3. Старший инженер - 2 ставки;

4. Инженер - 4 ставки;

5. Техник - 2 ставки;

6. Документовед - 1 ставка;

7. Диспетчер - 1 ставка.

Таким образом, отдел насчитывает 12 человек. В положении об ремонтной службе [2], прописаны следующие моменты:

Основными целями службы являются организация, руководство, координация, контроль и реализация работ по обеспечению бесперебойного функционирования и развития инфраструктуры ОАО "НЭСК-ЭЛЕКТРОСЕТИ".

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

1. разработка нормативов по уходу, надзору, обслуживанию и ремонту оборудования и линий электропередач;

2. планирование ППР;

3. планирование потребности в запасных частях;

4. организация работ по оперативному ремонту и восстановлению оборудования и линий электропередач

5. организация ППР и (ППО), изготовления или закупки и хранения запчастей;

6. оперативное планирование и диспетчирование сложных ремонтных работ;

7. организация работ по монтажу, демонтажу и утилизации оборудования;

8. организация работ по утилизации оборудования;

9. разработка проектно-технологической документации на проведение ремонтных работ и модернизацию оборудования и линий электропередач;

10. контроль качества ремонтов;

11. надзор за правилами эксплуатации оборудования и линий электропередач.

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

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

1.3 Сценарий бизнес-процессов организации рассмотрения заявок абонентов об обесточивании в ремонтной службе ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

В целом работу ремонтной службы можно охарактеризовать следующими состояниями:

1. Мониторинг;

2. Поступление информации об обесточивании;

3. Обработка информации, передача на исполнение техническим специалистам (инженерам или техникам);

4. Устранение неисправности;

5. Документирование процесса работы.

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

Рассмотрим укрупненный сценарий бизнес-процессов, связанный с обработкой поступающих заявок об обесточивании (см. рисунок 1.4).

Рисунок 1.4 - Сценарий бизнес-процессов ремонтной службы

В данном сценарии участвуют четыре действующих лица:

1. Инициатор, которым является абонент ОАО "НЭСК-ЭЛЕКТРОСЕТИ";

2. Диспетчер;

3. Исполнитель - сотрудник из числа ремонтных бригад;

4. Документовед.

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

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

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

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

1.4 Дискретно-событийная математическая модель процесса устранения обесточивания абонентов

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

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

(1)

Время пути в офис составляет от 5 минут (если бригада находится в отделе) до 0,5 часа (если бригада находится на самой удаленной точке). Таким образом, tпути1= (5+30)/2=17,5 мин.

Время получения задания составляет от 5 до 10 минут в зависимости от объема переданных инициатором заявки сведений. Таким образом, tзад.= (5+10)/2=7,5 мин.

Время пути в отдел составляет от 10 минут (если неисправность возникла в ближайших кварталах) до 0,5 часа (если неисправность возникла на удаленных объекта). Таким образом, tпути2= (10+30)/2=20 мин.

На устранения неисправности ремонтной бригаде в среднем требуется 1 час (данные получены в результате наблюдения). Таким образом, tустр-я= 60 мин.

Исходя из этого, общее время на устранение одного обрыва на линии ремонтной бригадой составляет 1 час 45 минут.

T= 17,5+7,5+20+60=105 мин.

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

В ремонтной службе ОАО "НЭСК-ЭЛЕКТРОСЕТИ" работает 4 ремонтные бригады, поток заявок никак не ограничен по времени и количеству. Поэтому воспользуемся четырехканальной моделью с неограниченной длиной очереди.

Рассмотрим модель текущего состояния процессов. По данным наблюдений, проводимых в течение месяца, средняя частота поступления обращений л=0,033 заявок/мин, время обслуживания одного обращения одним специалистом - 120 минут, а интенсивность обслуживания обращений - м=0,0095 заявок/час. Инженера трудится 4, так что число каналов m=4.

Найдем нагрузку на Ремонтная служба:

с=л/(mм) = 0,87.

Найдем вероятность простоя сотрудников по формуле

P0 = 1-с: P0=0,13.

Найдем среднюю длину очереди из необработанных обращений по формуле:

.

Получим: q=2,9 заявки.

Ремонтная служба принимает на обслуживание все поступающие заявки (отказов в обслуживании нет). Поэтому Pотк=0, Pобсл=1.

Найдем остальные характеристики математической модели по формулам из справочной литературы: Коэффициент загрузки

,U=0,87;

Среднее число обращений, обслуживаемых ремонтной службой в текущий момент времени

, S=3,48 заявок;

Среднее число обращений, включая ожидающие обслуживания

, k=6,4 заявки;

Количество обращений, которые служба способна обслужить в единицу времени

,г=0,033 заявки/мин;

Среднее время пребывания обращения в ожидании обслуживания

, w=88 мин.;

Среднее время от момента подачи обращения до его выполнения

,t=193 мин.

Проанализируем полученные характеристики дискретно-событийной модели. Ремонтные бригады загружены на 87%, т.е. заняты обслуживанием абонентов, обратившихся с неисправностями в течение 87% всего времени своей работы, это на 2% выше рекомендуемой нормы нагрузки [3]. В течение 13% времени ремонтные бригады простаивают из-за отсутствия заявок. Таким образом, загрузка ремонтных бригад достаточно высока. Дальнейшее увеличение загрузки крайне нежелательно.

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

1.5 Проблемы ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

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

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

2. Проблема нерационального расходования рабочего времени ремонтных бригад. Проявляется в несовершенстве бизнес-процессов получения задания исполнителем и в отсутствии средств мониторинга доступности ремонтных бригад;

Кроме этих основных проблем стоит также отметить:

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

4. Удовлетворительное качество обслуживания заявок на устранение неисправностей, поступающих от абонентов. Это обусловлено первой проблемой и не раз отражалось в отчетах сотрудников.

1.6 Постановка цели и задачи дипломной работы

Цель моей дипломной работы - провести оптимизацию деятельности ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ" с целью повышения качества ее работы и оптимизации расхода рабочего времени сотрудников, в особенности ремонтных бригад.

Задача моей дипломной работы - спроектировать и описать и информационную систему мониторинга доступности ремонтных бригад ОАО "НЭСК-ЭЛЕКТРОСЕТИ". Проект, который будет создан мною, должен отвечать проведенному реинжинирингу бизнес-процессов.



2. Оптимизация деятельности ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

2.1 Оптимизация математической модели процесса устранения обесточивания абонентов

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

Определим временные показатели из формулы (1), на которые можно повлиять (см. таблицу 2).

Таблица 2 - Показатели оптимизируемой дискретно-событийной модели

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

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

T= 0+0+20+60=80 мин.

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

В обновленной модели время обслуживания одной заявки одним каналом - 80 минут, а интенсивность обслуживания заявки в одном канале - м=0,0125 заявок/час. Ремонтных бригад по прежденму трудится 4, так что число каналов m=4.

Найдем нагрузку на ремонтную службу:

с=л/(mм) = 0,66.

Найдем вероятность простоя по формуле P0 = 1-с: P0=0,44.

Найдем среднюю длину очереди по формуле:

.

Получим: q=0,49 заявки. Найдем остальные характеристики модели по формулам из справочной литературы: Коэффициент загрузки

,U=0,66;

Среднее число обрабатываемых обращений

, S=2,64 заявок;

Среднее число обращений включая ожидающие обработки

, k=3,13 заявки;

Количество заявок, которые служба способна провести через себя в единицу времени

,г=0,033 заявки/мин;

Среднее время пребывания обращения в очереди

, w=15 мин.;

Среднее время пребывания обращения с момента подачи до момента обработки

,t=95 мин.

Проанализируем полученные характеристики.

Ремонтные бригады загружены на 66%, т.е. заняты обслуживанием абонентов, обратившихся с неисправностями в течение 66% всего времени своей работы, это на 9% ниже минимальной рекомендуемой нормы нагрузки [6]. В течение 44% времени ремонтные бригады простаивают из-за отсутствия заявок. Таким образом, загрузка ремонтных бригад при использовании средств мониторинга доступности уменьшится.

Время ожидания в очереди на обслуживание сократится для абонентов почти в 6 раз (с 88 до 15 минут), время нахождения заявки в системе сократится в 2 раза. Полученные показатели являются приемлемыми, так как достигнуто снижение временных затрат и разгружены сотрудники ремонтной службы .



2.2 Определение способа реализации оптимизированной математической модели

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

Рисунок 2.1 - Алгоритм доставки сведений о заявке

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

Как сказано выше, данная совокупность шагов должна осуществляться моментально, фактически - допускается затраты в несколько секунд на доставку информации.

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

Таблица 2.1 - Сравнение временных затрат

	Передача сведений по телефону	Передача через информационную систему
Получение заявки	0 минут	0 минут
Установка связи	1 минута	1-2 сек.
Передача сведений	2 минуты	1 сек.
Фиксация сведений и принятие к исполнению	2 минуты	1 мс.

Из таблицы видно, что при работе человека процесс доставки займет 5 минут, то есть невозможно удовлетворить условиям математической модели. В то же время на доставку сведений информационной системе потребуется порядка 3 секунд, что вполне приемлемо и никак не повлияет на показатели СМО.

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

2.3 CASE-средства моделирования, используемые в работе

Существует множество средств моделирования автоматизированных систем. За последние десятилетия сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) на основе методологии структурного системного анализа и проектирования. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки программного обеспечения (ПО) и сопровождения информационных систем, поддержанную комплексом, взаимосвязанных средств автоматизации [3]. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

Итак, основным критерием при выборе CASE-средств является поддержка методологий SADT, так как с помощью данного семейства моделей (IDEF1, IDEF3, DFD) может быть создано полное и непротиворечивое описание бизнес-процессов. Помимо этого необходимо учитывать доступность и простоту работы с данными средствами.

Остановимся подробно на выборе CASE-средства, для построения моделей бизнес-процессов ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ". На российском рынке представлен большой набор программных продуктов для моделирования, мною было решено выбрать три наиболее популярных инструмента, о которых имеется подробная документация на русском языке. После поиска по специализированным форумам и сайтам, посвященным моделированию бизнес-процессов, был определен следующий набор средств:

1. Microsoft Visio 2007.

2. AllFusion Modeling Suite;

3. Aris Toolset.

1. Microsoft Visio 2007. Это наиболее простое и доступное средство моделирования. Данный продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей.

CASE-средство Microsoft Visio 2007 поставляется в комплекте с базовым пакетом Microsoft Office и не требует дополнительных затрат на приобретение. Помимо этого данный продукт поддерживает все виды диаграмм языка UML.

2. AllFusion Modeling Suite - пакет инструментальных средств разработанный компанией Computer Associates International, Inc. (CA), пакет поддерживает все этапы разработки информационных систем, в этот пакет входит пять продуктов:

· AllFusion Process Modeler - "BPwin" (позволяет облегчить проведение обследования предприятия и построить функциональные модели).

· AllFusion ERwin Data Modeler - "ERwin" (позволяет создавать модели данных и генерировать схему баз данных).

· AllFusion Data Model Variator - "ERwin Examiner" (позволяет производить поис и исправление ошибок модели данных).

· AllFusion Model Manager - "ModelMart" (система организации коллективной работы и хранилище моделей BPwin и ERwin).

· AllFusion Component Modeler - "Paradigm Plus" (инструмент создания обьектных моделей).

3. ARIS: компании IDS Scheer AG. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

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

· Модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.

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

Выделим критерии наиболее важные конкретно для моей работы:

1. Поддержка стандартов выбранной методологии;

2. Удобство использования (наличие автосохранения, возможностей отмены и повтора действий);

3. Простота освоения;

4. Экспорт моделей в графические форматы;

5. Возможность декомпозиции объекта;

6. Стоимость.

На основании шести выбранных критериев проведем оценку эффективности CASE-средств методом экспертных оценок. Предлагается следующая шкала оценок.

Таблица 2.2 - Шкала оценок.

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо



Таблица 2.3 - Экспертная оценка.

Параметр, оценка	Весовой к-т	VISIO 2007	All Fusion	ARIS
Поддержка стандартов	0,15	3	0,45	4	0,6	3	0,45
Удобство использования	0,15	1	0,15	3	0,45	3	0,45
Простота освоения	0,10	5	0,5	4	0,4	3	0,3
Экспорт моделей	0,25	4	1	5	1,25	4	1
Возможность декомпозиции	0,25	1	0,25	4	1	3	0,75
Стоимость	0,10	5	0,5	3	0,3	2	0,2
Общая оценка, Q		Qа = 2,85	Qр = 4	Qр = 3,15

Вывод: Проведенный сравнительный анализ методом экспертных оценок показал, что наиболее подходящим программным средством для моделирования бизнес-процессов является AllFusion Modeling Suite фирмы Computer Associates.

2.4 Оптимизированная модель деятельности ремонтной службы ОАО НЭСК-ЭЛЕКТРОСЕТИ

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

На рисунке 2.2 изображена контекстная диаграмма, с которой согласно нотации начинается моделирование.

Рисунок 2.2 - Контекстная диаграмма

Диаграмма дает нам следующее представление о бизнес-процессе:

· Ремонтная служба руководствуется указаниями руководства. Ведет свою деятельность на основании положения об отделе;

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

· Ремонтная служба в качестве входящего потока информации имеет заявки от инициаторов (абонентов ОАО "НЭСК-ЭЛЕКТРОСЕТИ"); неисправное оборудование, требующее замены или ремонта; новое оборудование, поставляемое по заказу отделом закупок;

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

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

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

Рисунок 2.3 - Диаграмма декомпозиции первого уровня

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

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

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

Устранение обрывов. В рамках данного бизнес-процесса происходит устранение возникающих нарушений в подаче электричества абонентам ОАО "НЭСК-ЭЛЕКТРОСЕТИ". Активация данного бизнес-процесса может произойти по инициативе диспетчера, руководствующегося заявкой, либо при выявлении неисправности в процессе обслуживания;

Поддержание базы ЗИП. В ремонтной службе всегда имеется набор резервного оборудования для быстрого восстановления работоспособности в случае неисправностей. Актуализация данных запасов по технологиям и дополнение по объему выполняется в рамках данного бизнес-процесса.

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

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

Проведем первую декомпозицию бизнес-процесса "Мониторинг" (рисунок 2.4).

Рисунок 2.4 - Диаграмма декомпозиции бизнес-процесса

"Мониторинг"

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

1. Плановая диагностика. Ремонтная бригада в соответствии с должностной инструкцией в установленные сроки производит диагностику оборудования и ЛЭП. В случае возникновения неисправности, соответствующая информация подается диспетчеру;

2. Регистрация неисправностей. Диспетчер со слов подающего сведения фиксирует в журнале факт возникновения неисправности и его описания. Устанавливается степень сложности заявки, ее класс (по специализации сотрудников) и сроки устранения. Вместе с этими параметрами заявка передается на следующий бизнес-процесс;

3. Передать заявку на исполнение. Заявка, дополненная параметрами, оценивается диспетчером. Осуществляется поиск свободных ремонтных бригад в соответствии с данными мониторинга, которые назначаются исполнителями. Заявка передается на исполнение. При этом выделяется два вида исполнения - установка (недостающих компонентов или их обновление) и устранение (неполадок);

4. Контроль исполнения. Заявка, дополненная параметрами, а также данные об ответственном за ее исполнение лице подается сотруднику, ответственному за контроль качества работы отдела - его начальнику;

5. Мониторинг доступности ремонтных бригад. Новый процесс, введенный нами для сокращения временных затрат на процесс восстановления доступа абонентов ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

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

Рисунок 2.5 - Диаграмма реинжиниринга бизнес-процесса

"Определение исполнителей"

По результатам реинжиниринга получены следующие бизнес-процессы:

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

2. Выбрать ремонтной бригады. Система, основываясь на параметрах заявки, индивидуальных листах заданий и результатах мониторинга доступности, предлагает бригады на выбор диспетчеру;

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

4. Отправить уведомление. Через встроенную систему оповещений (мессенджер) информационная система уведомляет ремонтную бригаду о поступлении нового задания и предлагает ознакомиться с его содержанием.

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

2.5 Требования к проектируемой информационной системе ремонтной службы

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

Требования к структуре системы. Информационная система должна иметь в своем составе следующие модули:

· Управление заявками.Учет заявок, отслеживание и совместная работа. Отражение работ в личном кабинете.

· Управление задачами. Оперативное управление работой сотрудников, отслеживание, коллективное взаимодействие. Поддержка подзадач, регулярных задач и тегов.

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

· Аналитические отчеты. Динамика деятельности, удовлетворенность абонентов, качество работы службы поддержки и др. в разрезе времени.

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

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

· Регистрация заявок на выполнение работ;

· Классификация и диспетчеризация приходящих заявок, в том числе для назначения исполнителей, категорий и приоритетов;

· Отслеживание текущего статуса заявки;

· Протоколирование работ, выполняемых по заявке, а также всех вносимых в нее изменений;

· Регистрация трудозатрат исполнителей;

Построение отчетов по выбранным параметрам



3. Проектирование информационной системы мониторинга доступности ремонтных бригад ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

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

3.1 Обзор информационных систем для мониторинга доступности и отправки заданий работникам в рамках ремонтной службы

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

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

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

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

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

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

1. Naumen Service Desk;

2. SolverMate;

3. IntraService.

Рассмотрим каждую систему подробно.

Naumen Service Desk -- информационная система для ИТ-подразделений и сервисных компаний. Предназначена для того, чтобы эффективно управлять работой службы поддержки пользователей, организовать управление инцидентами и обращениями абонентов, вести полноценный учет оборудования и программного обеспечения, сформировать каталог сервисов и соглашений (SLA), управлять ИТ-бюджетом.

Naumen Service Desk представляет собой готовый программный продукт, в котором заложены практики IT Infrastructure Library (ITIL), включая шаблоны процессов и каталога услуг, структуру базы конфигураций (CMDB) и метрики для измерения эффективности. Это позволяет в короткий срок приступить к эксплуатации системы, сохранив при этом возможность ее дальнейшего развития и адаптации под ваши потребности благодаря гибким инструментам настройки, имеющимся у Naumen Service Desk.

Naumen Service Desk позволяет автоматизировать процессы управления инцидентами, проблемами, уровнем сервиса, конфигурациями, изменениями, релизами, доступностью и финансами.

Програмный продукт Naumen Service Desk предлагает широкие возможности для управления ИТ-обслуживанием:

Ведение единой абонентской базы:

· Настраиваемые карточки абонентов/контактных лиц;

· Хранение всей истории взаимоотношений с абонентом;

· Анализ абонентской базы по всем параметрам (настраиваемый генератор отчетов)

Управление инцидентами

Учет и классификация инцидентов:

· Внесение в систему информации о всех возникающих инцидентах;

· Автоматическая регистрация и первичная классификация инцидентов;

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

· Категоризация инцидентов в терминах затронутых сервисов и конфигурационных единиц;

· Привязка поступившего обращения к уже зарегистрированному инциденту;

· Хранение истории событий по каждому инциденту;

· Поиск инцидента в базе данных (по идентификатору, описанию и т.д);

· Использование базы данных об известных ошибках и опросных листов для диагностики инцидента и его разрешения

Организация процесса разрешения инцидентов:

· Автоматическая передача ответственности за инцидент при изменении состояния инцидента;

· Изменение технологического цикла обслуживания инцидента в зависимости от типа инцидента;

· Разграничение прав доступа к информации и операциям в системе (открытие, редактирование, закрытие инцидентов);

· Контроль ответственности за разрешение инцидента;

· Механизм передачи ответственности за инцидент между отделами и сотрудникам, в том числе возможность автоматического распределения инцидентов на конкретного сотрудника или группу сотрудников;

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

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

Учет временных характеристик инцидента:

· Учет времени начала и завершения работ;

· Учет общего времени обработки инцидента в службе поддержки;

· Контроль превышения нормативного времени, выделенного на разрешение инцидента;

· Механизм уведомления руководства о трудностях, возникших в ходе разрешения инцидента (эскалация инцидента);

· Настройка пороговых значений времени разрешения инцидента для проведения автоматической эскалации;

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

Управление проблемами

Учет и классификация проблем:

· Объединение инцидентов в проблему;

· Автоматическая регистрация и первичная классификация проблемы;

· Учет связей между инцидентами, проблемами и известными ошибками;

· Автоматическое назначение ответственного за решение проблемы;

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

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

· Привязка поступившего инцидента к уже зарегистрированной проблеме;

· Хранение истории событий по каждой проблеме;

· Поиск проблемы в базе данных (по идентификатору, описанию и т.д).

Организация процесса разрешения проблем:

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

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

· Контроль ответственности за разрешение проблемы, выделение менеджера процесса, делегирование полномочий;

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

· Закрытие проблемы с указанием причины ее разрешения.

Учет временных характеристик проблемы:

· Учет времени начала и завершения работ;

· Учет общего времени обработки проблемы;

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

Управление сервисами и соглашениями

Управление сервисами:

· Ведение иерархического справочника сервисов (услуг) компании (каталог сервисов);

· Возможность учета бизнес-сервисов, операционных и внешних сервисов;

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

· Гибко настраиваемые карточки сервисов - возможность задать разный набор полей для разных типов сервисов;

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

· Возможность задать индивидуальный вид формы для каждого типа сервисов;

· Классификация связей между сервисами, возможность связи сервисов друг с другом (указание для каждого сервиса зависимых и поддерживающих сервисов);

· Связь сервисов с конфигурационными единицами (поддерживающие и зависимые КЕ);

· Полноценное построение ресурсно-сервисной модели;

· Возможность назначить ответственного за сервис (куратор сервиса), что позволяет автоматически маршрутизировать запросы, связанные с данным сервисом;

· Контроль за соблюдением требуемого качества предоставления сервиса;

· Поддержка цикла Деминга в процессе повышения качества сервиса.

Управление соглашениями:

· Ведение справочников бизнес-соглашений (SLA), операционных оглашений (OLA), поддерживающих соглашений (UC);

· Гибко настраиваемые карточки соглашений - возможность задать разный набор полей для разных типов соглашений;

· Определение в каждом соглашении параметров оказания и поддержки сервисов, сроков действия соглашения;

· Связь соглашений с получателями и поставщиками сервисов, конфигурационными единицами;

· Уведомления о нарушении соглашений об уровне сервиса, настраиваемая эскалация

Управление конфигурациями:

· Учет и классификация конфигурационных единиц, ведение CMDB;

· Неограниченная типизация КЕ (аппаратное обеспечение, программное обеспечение, серверное оборудования и т.д.);

· Возможность указания для каждого КЕ своего набора полей и своего жизненного цикла;

· Настройка связей между конфигурационными единицами;

· Наличие настраиваемого справочника текущих статусов конфигурационной единицы;

· Хранение полной истории изменения каждой конфигурационной единицы;

· Возможность автоматической проверки соответствия статуса конфигурационной единицы информации в CMDB при интеграции с системами мониторинга;

· Возможность привязки КЕ к пользователю, которому КЕ передана в эксплуатацию;

· Возможность указания в карточке КЕ сотрудника ИТ, который отвечает за обслуживания данной КЕ;

...