Проектирование системы управления инцидентами

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

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

Проектирование системы управления инцидентами



Введение

программный автоматизированный архитектура

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

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

Внедрение системы ИС Mithril позволит увеличить эффективность работы ИТ-отдела, технической поддержки и связанных с ними подразделений по следующим показателям:

· Снижение числа потерянных инцидентов;

· Снижение временных затрат на регистрацию инцидентов;

· Снижение временных затрат на решение инцидента;

· Увеличение уровня достоверности и актуальности информации;

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

· Логирование эскалаций инцидентов;

· Создание оперативных групп для решения инцидентов;



1. Анализ предметной области

1.1 Описание объекта автоматизации

Характеристика объекта автоматизации

Закрытое акционерное общество «Нью Ком» имеет следующую структуру организации:

Административный аппарат:

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

- Директор по техническому развитию;

- Коммерческий директор

- Финансовый директор

- Главный инженер;

Отделы:

- Отдел информационных технологий;

o Начальник ИТ отдела;

o Ведущий специалист ИТ отдела;

o Инженер ИТ отдела;

- Отдел радиотехнологий;

o Начальник отдела радиотехнологий;

o Инженер отдела радиотехнологий;

- Служба технической поддержки;

o Начальник службы технической поддержки

o Специалист службы технической поддержки

- Отдел системного администрирования;

o Начальник отдела системного администрирования

o Системный администратор

- Отдел продаж;

o Начальник отдела продаж

o Менеджер отдела продаж

- Отдел строительно-монтажных работ

o Начальник отдела строительно - монтажных работ;

o Специалист отдела строительно - монтажных работ

- Бухгалтерия

o Главный бухгалтер

o Бухгалтер

- Отдел капитального строительства

o Начальник отдела капитального строительства

o Проектировщик

ЗАО NewCom - компания-провайдер, занимающаяся предоставлением телекоммуникационных услуг на территории городов Тюмень, Белоярский, Тобольск и Ханты-Мансийск. Компания предоставляет такие услуги как доступ к сети интернет, IP-телефония, IP-телевидение и организация публичных Wi-Fi точек доступа в общественных местах.

Анализ рынка

Рассмотрим несколько систем подходящих для автоматизации службы Service Desk. Возьмем такие системы как Megaplan, Э.С.К.И.З и IntraService.

Megaplan

Для своей функциональности довольно дешевая система, пользуется спросом у больших компаний. В числе ее клиентов такие компании как: «2gis», «Avon», «Первый канал», «RU Tube», «НТВ +» и многие другие. Но эта система больше подходит таким отделам как «Отдел продаж» и «Бухгалтерия». Для службы Service Desk у нее слишком перегружен интерфейс, очень много лишних функции и нет интеграции с базами данных устройств и абонентов.

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

Э.С.К.И.З

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

Вывод: Дешево сделанная система, может выступать в качестве курсовой, но никак не в качестве серьезного коммерческого проекта.

IntraService

Довольно серьезная система. Все сделано на достаточно профессиональном уровне. Удобная регистрация и эскалация заявок. Возможность интеграции с Active Directory. Но есть одно но, эта система предназначена для службы Service Desk в пределах одной компании. У нее нет возможности подключить какие-то другие базы данных кроме AD, если регистрировать обращение от сторонних лиц, то все данные придется вбивать самому.

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

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

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



1.2 Моделирование бизнес-процесса

Описание бизнес-процесса

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

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

Обработка инцидента состоит из следующих пунктов:

- идентификация пользователя ИС;

- сбор сведений об инциденте;

- классификация инцидента в соответствии с выделенными типами инцидентов;

- регистрация инцидента (открытие);

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

- Если специалист технической поддержки не может решить инцидент самостоятельно или если это не предписано инструкцией, то происходит горизонтальная эскалация инцидента;

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

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

Моделирование бизнес-процесса в методологии IDEF0

Модель бизнес-процесса представлена на рисунках 1, 2, 3.

Рисунок 1

Рисунок 2



Рисунок 3

Модель автоматизированной системы учета в нотации IDEF0

Модель автоматизированной системы представлена на рисунках 4, 5, 6.

Рисунок 4

Рисунок 5



Рисунок 6



2. Постановка задачи

программный автоматизированный архитектура

2.1 Характеристика комплекса задач

Назначение комплекса задач

Данный комплекс задач предназначен для автоматизации работы службы Service Desk и служит для того чтобы:

1) В несколько раз уменьшить время регистрации инцидента;

2) Автоматизировать составление статистики по следующим параметрам:

- Количество звонков, принятых оператором;

- Количество обращений по типам ошибок подключения;

- Количество инцидентов, закрытых без эскалации;

- Количество инцидентов с определенного сегмента сети;

3) Упростить построение графика зависимости количества регистрируемых инцидентов от времени суток.

- Формализовать и упростить эскалацию инцидентов;

- Формализовать и упростить уведомление о запланированных работах в узлах сети;

Автоматизируемые функции

1) Ведение справочников: инцидентов, сотрудников, отделов, абонентов и их телефонов и адресов.

2) Формирование истории эскалаций по каждому инциденту, истории обращений по абонентам.

3) Вывод журнала инцидентов (с фильтрами - открытых, закрытых, по отделам, по сотрудникам и т.д.), вывод статистики по абоненту, по сотруднику и т.д.

4) Подключение к биллинговой системе LANBilling для идентификации пользователя и получении данных о состоянии личного счета и адреса пользователя.

2.2 Выходная информация

Выходные данные представлены в таблицах 1 - 3.

Таблица 1. Журнал инцидентов

Наименование	журнал инцидентов
Получатель	сотрудники организации
Форма представления	таблица
Вид представления	приложение А
Периодичность	по запросу
Состав атрибутов	идентификатор обращения, время регистрации, зарегистрировавший сотрудник, статус обращения, ответственный сотрудник, время работы на данный момент, абонент, тип

Таблица 2. Абоненты

Наименование	абоненты
Получатель	Сотрудники организации
Форма представления	таблица
Вид представления	приложение А
Периодичность	по запросу
Состав атрибутов	Ф.И.О., адрес, список телефонных номеров

Таблица 3. Сотрудники

Наименование	сотрудники
Получатель	сотрудники организации
Форма представления	таблица
Вид представления	приложение А
Периодичность	по запросу
Состав атрибутов	Ф.И.О., отдел, должность и телефон



2.3 Входная информация

Входные данные представлены в таблицах 4, 5.

Таблица 4. Инцидент

Наименование	инцидент
Источник	номер телефона; адрес абонента; номер договора; Ф.И.О. абонента, LANBilling
Периодичность	по запросу
Состав атрибутов	Ф.И.О., номер телефона, описание обращения, комментарий к инциденту, дата, тип инцидента

Таблица 5. Сотрудник

Наименование	сотрудник
Источник	Данные организации
Периодичность	при вступлении в должность
Состав атрибутов	Ф.И.О., отдел, должность, номер телефона

2.4 Требования к обеспечивающим подсистемам

Требования к информационному обеспечению

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

1) информация должна быть достоверной и актуальной;

2) информация должна быть достаточно полной;

3) информация должна легко восприниматься визуально;

4) доступ к информации должен быть максимально быстр.

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

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

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

3) достоверность и актуальность на текущий момент времени;

4) информация должна храниться в базе данных.

Требования к программному обеспечению

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

1) Веб-браузер с поддержкой HTML4 и JavaScript;

2) СУБД MySQL версии 5 и выше

3) Веб-сервер с поддержкой PHP 5 и выше.

Требования к техническому обеспечению

Технологическое оборудование:

1) Браузер с поддержкой JavaScript.

2) Выделенный веб-сервер и сервер базы данных.

Требования к защите информации от несанкционированного доступа

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

- Основные роли следующие:

- Ответственный за проблему;

- Участник оперативной группы по решению проблемы;

- Получивший предложение о вступлении в оперативную группу;

- Получивший предложение об эскалации проблемы;

- Не имеющий отношения;

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



3. Проектирование информационного обеспечения

3.1 Описание внешнего информационного обеспечения

База данных системы LANBilling содержит следующие сущности.

· Учетная запись. Содержит данные о логине и пароле доступа в интернет, его Ф.И.О., тарифный план, номер договора и информацию о балансе пользователя.

· Аккаунт. Содержит данные о логине и пароле от личного кабинета пользователя, его Ф.И.О., паспортные данные, адрес подключения, тип пользователя и номер договора.

3.2 Разработка структуры внутреннего информационного обеспечения

Идентификация информационного пространства

Из описания задачи следует, что в базе данных должны быть следующие сущности:

· Incident - основные данные об инциденте;

· Incident_Type - информация о типе инцидента;

· Incident_Movement - информация об эскалациях инцидентов

· Incident_Invite - информация о приглашениях в оперативные группы;

· Incident_Relation - информация об оперативных группах;

· Abonent - информация об абоненте;

· Abonent_Type - информация об организационной форме;



Таблица 6. Описание сущности Incident

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
name	-	-	VARCHAR(70)
opener_id	-	да	INTEGER	Not null
solver_id	-	да	INTEGER
time_open	-	-	TIMESTAMP	Not null
time_close	-	-	TIMESTAMP
description	-	-	TEXT	Not null
comment	-	-	TEXT
priority	-	-	INTEGER
abonent_id	-	да	INTEGER	Not null
tele_id	-	да	INTEGER
type_id	-	да	INTEGER	Not null
status	-	-	INTEGER
problem_id	-	да	INTEGER

Таблица 7. Описание сущности Incident_Type

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
name	-	-	VARCHAR(80)	Not null
overdue_minutes	-	-	INTEGER	Not null
visible_fields	-	-	TEXT

Таблица 8. Описание сущности Incident_Movement

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
from_empl_id	-	да	INTEGER	Not null
to_dept_id	-	да	INTEGER	Not null
get_empl_id	-	да	INTEGER	Not null
time_send	-	-	TIMESTAMP	Not null
time_confirm	-	-	TIMESTAMP
comment	-	-	TEXT
movement_status	-	-	INTEGER	Not null
incident_id		да	INTEGER	Not null

Таблица 9. Описание сущности Incident_Invite

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
inviter_id	-	да	INTEGER	Not null
employee_id	-	да	INTEGER	Not null
date	-	-	TIMESTAMP	Not Null
comment	-	-	TEXT
is_viewed	-	-	BOOL
is_confirmed	-	-	BOOL
incident_id	-	да	INTEGER	Not null

Таблица 10. Описание сущности Incident_Relation

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
employee_id	-	да	INTEGER	Not null
date	-	да	TIMESTAMP	Not null
is_done	-	-	BOOL	Not null
done_comment	-	-	TEXT
status	-	-	INTEGER
done_time	-	-	TIMESTAMP	Not null
task	-	-	TEXT
comment	-	-	TEXT
incident_id	-	да	INTEGER	Not null
invite_id	-	да	INTEGER	Not null

Таблица 11. Описание сущности Abonent

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
name	-	-	VARCHAR(200)	Not null
address_id	-	да	INTEGER	Not null
apartment	-	-	VARCHAR(10)
type	-	-	INTEGER	Not null
is_vip	-	-	BOOL
billing_id	-	-	INTEGER
login			VARCHAR(200)

Таблица 12. Описание сущности Abonent_Phones

Атрибут	Первичный ключ	Внешний ключ	Физические ограничения	Логические ограничения	Примечание
id	да	-	INTEGER	Not null
abonent_id	-	да	INTEGER	Not null
phone_number_id	-	да	INTEGER	Not null

Структурирование информационного пространства

Логическая модель базы данных в нотации IDEF1X представлена на рисунке 7.

Рисунок 7



Рисунок 8



4. Проектирование программного обеспечения

4.1 Описание процесса разработки

В процессе разработки были использованы: нотация IDEF0 и кейс-пакет AllFusion Process Modeler 7.1, IDEF1X - DIA, UML - Enterprise Architect 8.

Автоматизированная система разрабатывается на языке PHP с использованием среды разработки NetBeans IDE 7.

4.2 Выбор архитектуры системы

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

Клиентская часть приложения была реализована как Web-клиент, что позволило достигнуть абсолютной кросплатформенности (любая ОС ПК и подавляющее большинство ОС смартфонов), принеся в жертву совместимость со старыми браузерами семейства Internet Explorer, так как в них не реализована поддержка стандартов языков JavaScript и CSS.



Рисунок 9. Диаграмма Deployment

4.3 Разработка модели системы

Диаграмма Use Case разрабатываемой автоматизированной системы представлена на рисунке 11.

Рисунок 10. Диаграмма Use Case



Приложение А

Форма представления печатных документов

«Список пациентов на обследование»

Список пациентов на обследование
1) Ф.И.О. - адрес - номер участка 2) …

«Отчет»

Отчет ДАТА
Место работы …	Ф.И.О. - дата прохождения обследования …
Номер участка …	Ф.И.О. - дата прохождения обследования …

«Результат обследования»

Результат обследования пациента
Ф.И.О. Дата рождения Адрес
Дата обследования Результат обследования

Размещено на Allbest.ru

...