Гибкий контроль работы службы поддержки
Обращения в техподдержку
пользователь может обратиться в службу технической поддержки, заполнив специальную форму на сайте, отправив сообщение по электронной почте, позвонив по телефону, или может создать обращение прямо из сообщений клиента, а к сообщениям прикрепить файлы разных форматов. При наличии модуля «Интернет-магазин» можно просмотреть заказы автора обращения. А для участников групп, в которых состоит ответственный, будут рассылаться уведомления об изменениях в обращении;
обращаясь в службу техподдержки, пользователь получает возможность:
отправить запрос в техподдержку через сайт, e - mail или продиктовать оператору по телефону;
прикрепить к сообщению изображение (например, скриншот с возникшей проблемой);
выбрать категорию обращения;
установить уровень критичности проблемы;
получить подтверждение по e-mail;
получить ответ по e-mail;
оценить полученный ответ;
продолжить дискуссию;
закрыть обращение.
Обработка запросов
принимать запросы пользователей через сайт, e-mail через модуль Почты, форум, по телефону и через другие источники;
классифицировать запросы по категориям;
отмечать полученные через e-mail сообщения как спам , обучать тем самым модуль почты для эффективной фильтрации спама, и удалять сообщения;
настроить необходимое число статусов обращения (например: Принято к рассмотрению, В стадии решения, Успешно решено и т.п.);
настроить оценки ответов , выставляемые создателем обращения как оценка работы (например: Ответ устраивает, Недостаточно полно и т.п.);
настроить уровни критичности обращения (например, высокая, средняя, низкая и т.п.);
при ответевыбрать типовой ответ из выпадающего списка (доступно администратору либо ответственному за обращение);
возможность работы с обращениями в техподдержку через e-mail обеспечивает модуль «Почта».
Назначение ответственных
Назначение ответственного
установить ответственного для каждой категории:
при создании нового обращения в зависимости от категории, критичности, либо источника ответственный может быть назначен автоматически;
если ответственный не был определен, то в случае установки параметра «Ответственный по умолчанию» в настройках модуля будет назначен ответственный по умолчанию;
после того как обращение будет добавлено в базу, ответственный получит извещение по электронной почте;
если ответственный не выбран, то извещение будет отослано на электронные адреса всех пользователей, имеющих право «Администратор техподдержки»;
если обращение меняет ответственный, то об этом будет извещен автор обращения;
если обращение меняет автор, то об этом извещаются ответственный или администраторы техподдержки;
если назначается новый ответственный за обращение, то об этом будут извещены как автор обращения, так и новый ответственный.
Оценка ответов
если пользователя ответ устраивает, он может закрыть сообщение, оценив ответ.
если же проблема остается нерешенной, ответ его не устраивает или требуется дополнительная информация, пользователь может продолжить дискуссию и задать дополнительные вопросы в этом же обращении.
в оценке ответов пользователь может указать, полностью ли решена проблема, устраивает ли его предложенное решение и т.п.
оценки могут быть использованы для контроля и оптимизации работы службы техподдержки.
История обращений
на сайте сохраняется полная история обращений в техподдержку каждого клиента (ответы, изменение ответственных, категорий, статусов и т.п.), поэтому сотрудники техподдержки могут восстановить причины проблемы, просмотреть ход решения и предложить пользователю наиболее эффективное решение.
Уровни поддержки (SLA)
настроить различные уровни поддержки - SLA (Service Level Agreement) в зависимости от статуса пользователя и выбрать ответственного по умолчанию для SLA;
Совместная работа
обмениваться скрытыми сообщениями между сотрудниками техподдержки в рамках обращения,чтобы не оповещать автора обращения о внутренней работе и обсуждении проблемы; при установке флага «Сообщение скрыть, автора не оповещать» сообщение будет создано как скрытое для автора обращения; помимо этого, не будет отослано почтовое сообщение автору обо всех изменениях, произведенных в данный момент; служба техподдержки уведомление получит; режим скрытых сообщений можно установить по умолчанию;
сотрудники техподдержки могут указать свой режим работы с обращением: «просмотр» или «ответ на обращение», чтобы избежать дублирования ответов;
оставить комментарий, видимый только пользователями, входящими в группу техподдержки;
видеть на странице редактирования список пользователей, которые просматривают или редактируют обращение в данный момент;
Права доступа
распределить права доступа к модулю техподдержки:
доступ закрыт - доступ к меню и административным файлам модуля закрыт, пользователь не может создавать обращений;
клиент техподдержки - доступ к административному меню «Обращения» открыт; в административных и публичных файлах разрешено создание и редактирование своих обращений;
сотрудник техподдержки - доступ ко всем пунктам меню и страницам модуля открыт; пользователь работает с теми обращениями, за которые он ответственен;
демо-доступ - пользователь может просматривать все обращения;
администратор техподдержки - пользователь может редактировать справочник техподдержки и любое обращение.
Все вышеперечисленные права являются наследуемыми.
Контроль работы службы поддержки
получать отчеты о работе службы техподдержки , отображающие количество назначенных, закрытых и открытых обращений:
по ответственным сотрудникам службы;
по текущему статусу;
по категории;
по источнику обращения;
по оценкам ответов на обращения.
строить графики нагрузки на техподдержку, отображающие количество обращений и сообщений в системе техподдержки по дням; графики отражают загрузку службы техподдержки на конкретную дату и могут использоваться для принятия управленческих решений по функционированию службы техподдержки;
строить диаграммы длительности решения проблем ; круговая диаграмма наглядно показывает среднее количество времени (в днях), которое тратится на решение проблемы службой техподдержки;
строить диаграммы количества сообщений, необходимых для решения проблемы; на диаграмме представлено процентное соотношение количества сообщений в закрытых обращениях;
работать с обращениями и графиками нагрузки в разрезе по сайтам;
Работа с файлами
установить максимальный размер загружаемых изображений для пользователей, не входящих в группу техподдержки;
просматривать файлы MSWord, MSExcel, Acrobat Reader;[18]
osTicket
Бесплатная система, open source. Это единственная из бесплатных систем поддержки на PHP, которая дошла до финала. По сравнению с платными аналогами выглядит неконкурентоспособной, однако поддержка базового функционала присутствует. Активность разработки и сообщества низкая.
Есть расширение, разработанное сообществом, предоставляющее API для взаимодействия с osTicket через SOAP <#"justify">Активно разрабатывающаяся бесплатная система с открытым исходным кодом, поддерживающая ITIL/ITSM.
Integria IMS
Бесплатная система для разработки и управления проектами.
GLPI
Бесплатная система для управления оборудованием и поддержки пользователей в организации. Давно разрабатывается и обладает богатым функционалом.
SugarCRM <#"justify">Бесплатная система на PHP для поддержки пользователей через веб-интерфейс. Есть поддержка русского языка. Не поддерживает прием заявок по электронной почте. Есть версия SaaS.[13]
1.3Цели и задачи автоматизации
Таким образом, для создания, учета и сопровождения заявок, а также создания отчетов по исполнителям, по качеству, приоритету, и повторности, для организации выбран вариант реализации посредством разработки автоматизированной системы планирования HELPDESK для предприятия с развитой инфраструктурой в БУ ВО «Центр информационных технологий»
Целью данного дипломного проекта является разработка следующих функций:
-Создание задачи с личным номером, сроком исполнения, выбором заказчика и исполнителя;
-Создание повторных задач и выставление приоритета;
-учет заявок;
-ведение списка специалистов отдела МТО;
-ведение списка специалистов отдела технической поддержки;
-ведение списка специалистов управления инфраструктуры;
-ведение списка специалистов управления информационных систем;
-Организация поиска по номеру задачи, отметке о выполнении, повторные задачи, по дате регистрации, сроку исполнения, дате исполнения, задаче, заказчику, отделу, исполнителю, по приоритету, качеству или кабинету;
-ведение истории обслуживания заказчика;
-ведение истории задач у исполнителя;
-формирование отчетности:
-создание отчета по исполнителям;
-создания отчета по качеству приоритету и повторности;
-отправка писем с задачами по внутренней почте правительства;
-отправка отчетов руководящему составу.
1.4Обоснование выбора методов и средств проектирования
Технология создания информационных систем предъявляет особые требования к методикам реализации и программным инструментальным средствам. Реализацию проектов по созданию информационных систем принято разбивать на стадии анализа (прежде чем создавать информационных систем, необходимо понять и описать бизнес-логику предметной области), проектирования (необходимо определить модули и архитектуру будущей системы), непосредственного кодирования, тестирования и сопровождения.
Сущность структурного подхода к разработке информационных систем заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Основные этапы, на которые разбивается процесс проектирования информационной системы, следующие:
-концептуальное проектирование - сбор анализ и редактирование требований к данным (обследование предметной области, изучение ее информационной структуры, выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами, моделирование и интеграция всех представлений)
-логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ.
-физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
Современные объектно-ориентированные CASE-средства позволяют эффективно решать задачи проектирования приложений. Среди таких пакетов Rational Rose, Together Control Center, BPWin, ERWin, Model Mart, Silverrun Business Process Modeller, Process Analyst.
Для разработки функциональной модели выбрано CASE-средство Computer Associates BPwin 4.0, благодаря описанным ниже его особенностям. BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:
-с точки зрения функциональности системы. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой;
-с точки зрения потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями;
-с точки зрения потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями;
-с точки зрения последовательности выполняемых работ: еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий.
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы организации необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов в данном случае является IDEF0, называвшийся первоначально SADT Structured Analysis and Design Technique. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их удобно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
-функции обработки (работы);
-документы, сотрудников, которые в обработке информации;
-таблицы хранения документов данных).
Цель инфологического проектирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Логическая структура базы данных - это описание состава, типа и длины информационных единиц базы данных и связей между ними.
Сущности и связи модели данных представляются в виде реляционной таблицы (отношения). Отношение, соответствующее сущности, содержит атрибуты (столбцы), являющиеся атрибутами сущности и описывающие сущность (объект). Атрибут или множество атрибутов, которые однозначно определяют объект называются ключом.
Удобно представлять отношение как таблицу, где каждая строка есть кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом называются атрибутами и им присваивают имена. Список имён атрибутов называется схемой отношения. Совокупность схем отношений, используемых для представления информации, называются схемой базы данных, а текущие значения соответствующих отношений - базой данных.
Процесс построения инфологической модели состоит из следующих шагов:
-определение сущностей;
-определение зависимостей между сущностями;
-задание первичных и альтернативных ключей;
-определение атрибутов сущностей;
-приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.
Для инфологического проектирования базы данных было выбрано CASEсредство Computer Associates ERwin 4.0, благодаря описанным ниже его особенностям.
Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать и физическую, и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой.
Различают два уровня физической модели:
-трансформационная модель (Transformation Model);
Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам БД лучше представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям к ИС.
Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.
1.5Обоснование выбора средств разработки
1.5.1Обоснование выбора СУБД
К СУБД, используемой для разработки и использования базы данных, можно выдвинуть следующие требования [6]:
-требование надежности (СУБД должна позволять пользователям и системным администраторам восстанавливать предыдущее состояние СУБД без потери данных);
-требование защиты информации (СУБД должна иметь средства аутентификации и идентификации, иметь возможность разграничения доступа к объектам базы данных - различные группы пользователей должны иметь различные права на доступ к объектам базы данных);
-требование модифицируемости (база данных должна быть легко расширена при помощи добавления новых объектов);
-требование минимизации затрат на сопровождение и поддержку;
-требование эргономичности.
Перечислим основные характеристики СУБД и рассмотрим их в отношении основных СУБД [6, 7]:
1)размер базы данных:
-до сотни мегабайт: MS Access, Paradox, Dbase, Foxpro/VFP;
-гигабайты: MySQL, PostgreSQL, Interbase, Informix;
-сотни и больше: MS Server, Oracle, SyBase, DB/2.
2)количество одновременных пользователей:
-до десятка пользователей: Paradox, Dbase, Foxpro/VFP, MS Access;
-несколько десятков пользователей: MySQL, Informix;
-сотни пользователей: PostgreSQL, Interbase;
-тысячи пользователей: MS SQL Server, Oracle, SyBase, DB/2;
3)платформа:
-Windows: MS SQL Server, SyBase, Paradox, Dbase, Foxpro/VFP, MS Access;
-Windows+Linux: Oracle, DB/2, Interbase, MySQL;
4)язык программирования:
-языки от Microsoft: MS SQL Server, SyBase, Foxpro/VFP, MS Access;
-языки Borland: MS SQL Server, Interbase, Paradox, MS Access;
5)защита данных:
-слабая: Paradox, Dbase, Foxpro/VFP, MS Access;
-сильная: MS SQL Server, Oracle, SyBase, DB/2, Interbase, Informix, MySQL, PostgreSQL;
6)требования к техническому оснащению:
-неприхотливые: MySQL, PostgreSQL, Paradox, Dbase, Foxpro/VFP, MS Access;
-чувствительные: Interbase, Informix, SyBase;
-требуют отдельных мощных серверов с большой RAM, желательно на нескольких процессорах: MS SQL Server, Oracle, DB/2;
7)сложность настройки, установки, администрирования, желательность специально обученного персонала для администрирования:
-минимальные либо небольшие сложности: Paradox, Dbase, Foxpro/VFP, MS Access;
-первоначальная настройка плюс минимальная поддержка: PostgreSQL, MySQL;
-требуются специальные знания в достаточно большом объёме: Interbase, Informix;
-желательно наличие специалиста по базам данных: MS SQL Server, Oracle, SyBase, DB/2.
Основываясь на перечисленных выше критериях выбора СУБД был сделан выбор в пользу MS Access.
Система управления реляционными базами данных Microsoft Office Access удовлетворяет потребности самых разных групп пользователей. С помощью мастеров и графических инструментов Access даже пользователи, не владеющие специальными навыками, могут весьма успешно разрабатывать полезные приложения баз данных. Исследования малых и средних предприятий, проведенные различными службами, показали, что Access является одной из самых популярных программ для работы с базами данных.
Приложения для автоматизации работы с электронными таблицами, такие как Microsoft Office Excel, используются на персональных компьютерах с момента их появления и, реализуя мощные вычислительные функции, средства анализа данных и построения диаграмм, позволяют выполнять многие стандартные задачи по обработке табличных данных. Современные приложения для совместной работы, такие как Windows SharePoint, также поддерживают создание и обслуживание списков, доступных через интерфейс веб-обозревателя. Но следует заметить, что ни один из продуктов, поддерживающих таблицы, не обладает всеми достоинствами настоящей реляционной базы данных. По мере усложнения приложений на основе электронных таблиц или списков возникает вопрос о перемещении данных в стандартные реляционные таблицы, из которых можно выбирать и обрабатывать данные с помощью языка SQL (Structured Query Language). После превращения списков в реляционные данные Access позволяет быстро создавать приложения для решения самых разнообразных задач.
Для решения стандартных задач в Access доступны многочисленные шаблоны баз данных. Мастера и удобные средства конструирования обеспечивают простоту создания в Access реляционных структур данных, а также запросов, форм и отчетов, необходимых для работы с данными. Контекстно-зависимый интерфейс всегда предоставит пользователю элементы, необходимые в данный момент времени.
Простой интерфейс пользователя и интерактивные средства разработки в составе Access 2013 делают разработку приложений в среде этого программного продукта доступной для начинающих пользователей. Любой сотрудник, не имея опыта программирования и обладая ограниченными знаниями в области баз данных, может, используя Access, самостоятельно решать задачи по обработке данных.
В то же время Access удовлетворяет требованиям профессиональных разработчиков и позволяет за незначительное время разрабатывать сложные бизнес-системы.
Новые средства Access 2013 ориентированы на упрощение разработки веб-приложений, которые позволят сотрудниками компании совместно отслеживать важные бизнес-данные. Благодаря тесной интеграции с Microsoft SharePoint пользовательские веб-приложения просто использовать в масштабах как корпоративной сети предприятия, так и Интернета в целом.