Информационная система Help Desk отдела технической поддержки

- DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0;

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

- ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).

На стадии моделирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Объектно-ориентированный подход реализуется с применением UML (Unified Modeling Language), который представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем [6].

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

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



• 2.2 Модель деятельности отдела технической поддержки: "как есть"
• Чтобы выполнить системное исследование отдела технической поддержки, необходимо изучить структуру происходящих внутри бизнес-процессов. Для этих целей строится модель "как есть". Применим структурный подход и нотацию IDEF0.
• На рисунке 2.1 изображена контекстная диаграмма, с которой согласно нотации начинается моделирование.
• Рисунок 2.1 - Контекстная диаграмма
• Диаграмма дает нам следующее представление о бизнес-процессе:
• · Отдел технической поддержки руководствуется указаниями руководства и должностных инструкций. Ведет свою деятельность на основании устава;
• · Отдел технической поддержки в качестве механизмов исполнения бизнес-процессов использует персонал и вычислительную технику;
• · Отдел технической поддержки в качестве входящего потока информации имеет заявки от инициаторов (отделов или сотрудников, сообщающих о неисправности); неисправное оборудование, требующее замены или ремонта; новое оборудование и программное обеспечение, поставляемое по заказу отделом закупок;
• · Отдел технической поддержки в качестве потока исходящей информации имеет различные виды отчетной документации, как регламентированной, так и произвольной формы; обслуженные заявки инициаторов; заказы на закупку оборудования и программного обеспечения; отремонтированное оборудование.
• Чтобы перейти к подробному рассмотрению работы отдела, необходимо выполнить декомпозицию - так в нотации IDEF0 называется процесс детализации описания. Декомпозиция будет выполнена для черного ящика "Моделировать работу отдела технической поддержки", при этом следует отталкиваться от перечня прописанных в уставе функций:

1. Подготовка спецификаций для закупки;

2. Установка, настройка, техническое сопровождение и обслуживание;

3. Организация автоматизированных рабочих мест;

4. Диагностика и устранение неисправностей вычислительной и офисной техники;

5. Диагностика и устранение неполадок программного обеспечения.

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

7. Координация работ с подрядчиками и субподрядчиками - производителями программного обеспечения.

8. Разработка и внедрение инструкций, регламентов и стандартов использования программного и аппаратного обеспечения.

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

10. Разработка Плана обеспечения непрерывной работы и восстановления работоспособности подсистем автоматизированной системы.

11. Анализ потребностей подразделений ООО Трейд в дополнительных средствах вычислительной техники и обработки информации.

12. Организация своевременного рассмотрения и исполнения заявок на выполнение работ связанных с функционированием программного и аппаратного обеспечения.

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

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

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

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

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

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

Поддержание и модернизация запасов КТС и ПО. В отделе технической поддержки всегда имеется набор резервного оборудования для быстрого восстановления работоспособности в случае неисправностей. Также имеется репозиторий программного обеспечения, устанавливаемого в соответствии с планом или по требованию. Актуализация данных запасов по технологиям и дополнение по объему выполняется в рамках данного бизнес-процесса.

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

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

Проведем первую декомпозицию бизнес-процесса "Мониторинг состояния КТС и ПО" (рисунок 2.3).

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

"Мониторинг состояния КТС и ПО"

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

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

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

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

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

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

Перейдем на более детальный уровень рассмотрения бизнес-процесса "Мониторинг состояния КТС и ПО", рассмотрим поочередно бизнес-процессы "Регистрировать факт возникновения неисправности" (рисунок 2.4) и "Передать заявку на исполнение" (рисунок 2.5). Раскрытие данных процессов сделаем в нотации IDEF3, чтобы увидеть недостатки протекающих процессов и их узкие места.

Рисунок 2.4 - IDEF3-диаграмма декомпозиции бизнес-процесса "Регистрировать факт возникновения неисправности"

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

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

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

3. Запись в журнале обращений. Диспетчер делает запись в журнал обращений, которая служит основанием для учета операций, совершенных отделом технической поддержки;

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

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

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

Следующим декомпозируем бизнес-процесс "Передать заявку на исполнение" (рисунок 2.5).

Рисунок 2.5 - Диаграмма декомпозиции бизнес-процесса "Передать заявку на исполнение"

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

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

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

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

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

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

• 2.3 Модель деятельности отдела технической поддержки: "как надо"
• Полученные в ходе построения моделей существующих бизнес-процессов являются основанием и исходными данными для оптимизации бизнес-процессов - реинжиниринга.
• Реинжиниринг представляет собой переосмысление и радикальную перестройку бизнес-процессов с целью улучшения таких важных показателей, как стоимость, качество, скорость функционирования, финансы и маркетинг для достижения скачкообразного улучшения деятельности фирмы.
• Реинжиниринг нацелен на то, чтобы не только каждое звено бизнеса действовало продуктивно, но и на то, чтобы вся система их взаимодействия была нацелена на получение максимального эффекта мультипликации, т.е. того эффекта, который невозможно получить каждому в отдельности, но реально достичь за счет совместных усилий, организованных оптимальным образом.
• При реинжиниринге бизнеса принципиальное значение приобретает согласованность, взаимообусловленность и взаимодополняемость действий. Еще одна особенность реинжиниринга -- в его системе каждый работник нацеливается не столько на хорошее и своевременное выполнение возложенной на него работы, сколько на то, чтобы обеспечить максимально высокий конечный результат всего бизнеса, т.е. всегда следует "подставить плечо" сотруднику, который в такой помощи нуждается. Конечно, при этом интенсивность труда обычно возрастает. Но это труд, приносящий прибыль, а повышение финансовых результатов бизнеса позволяет существенно расширить материальное стимулирование. Результаты более напряженного и продуктивного труда приносят не только высокий заработок, но и общественное признание, высокий имидж работника и большее моральное удовлетворение, поскольку раскованность в работе усиливает ее творческий характер, предоставляется возможность для каждого раскрыть весь свой потенциал во имя успеха общего дела.
• Метод реинжиниринга взят на вооружение ведущими компаниями мира. Особенно много усилий и финансовых ресурсов тратят на это американские компании.
• Основателем теории реинжиниринга считают М. Хаммера, который в соавторстве с Дж. Чампи выпустил книгу "Реинжиниринг корпорации: манифест для революции в бизнесе".
• Реинжиниринг сначала определяет, ЧТО предприятие должно делать, и только затем -- КАК делать. Реинжиниринг игнорирует то, что есть, и концентрируется на том, что должно быть.
• Выше было сказано, что модификации следует подвергнуть бизнес процессы "Регистрировать факт возникновения неисправности" и "Передать заявку на исполнение". Проводить реинжиниринг следует с учетом использования проектируемой информационной системы. Начнем построение модели "как должно быть" с процесса регистрации неисправности (рисунок 2.6).
• Рисунок 2.6 - IDEF3-диаграмма реинжиниринга бизнес-процесса "Регистрировать факт возникновения неисправности"
• По результатам реинжиниринга имеем следующие элементарные процессы:

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

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

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

4. Уведомить диспетчера. Система автоматически помещает сформированную заявку в рабочее пространство диспетчера, однако при желании сотрудник может дополнительно послать уведомление, обозначив тем самым срочность или важность решения неисправности.

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

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

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

"Передать заявку на исполнение"

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

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

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

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

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

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

• 2.4 Математическая модель процесса регистрации факта неисправности

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

§ Агентное моделирование -- относительно новое (1990е-2000е гг.) направление в имитационном моделировании, которое используется для исследования децентрализованных систем, динамика функционирования которых определяется не глобальными правилами и законами (как в других парадигмах моделирования), а наоборот, когда эти глобальные правила и законы являются результатом индивидуальной активности членов группы. Цель агентных моделей -- получить представление об этих глобальных правилах, общем поведении системы, исходя из предположений об индивидуальном, частном поведении ее отдельных активных объектов и взаимодействии этих объектов в системе. Агент -- некая сущность, обладающая активностью, автономным поведением, может принимать решения в соответствии с некоторым набором правил, взаимодействовать с окружением, а также самостоятельно изменяться.

· Дискретно-событийное моделирование -- подход к моделированию, предлагающий абстрагироваться от непрерывной природы событий и рассматривать только основные события моделируемой системы, такие как: "ожидание", "обработка заказа", "движение с грузом", "разгрузка" и другие. Дискретно-событийное моделирование наиболее развито и имеет огромную сферу приложений -- от логистики и систем массового обслуживания до транспортных и производственных систем. Этот вид моделирования наиболее подходит для моделирования производственных процессов. Основан Джеффри Гордоном в 1960х годах.

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

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

Система массового обслуживания (СМО) - система, которая производит обслуживание поступающих в неё требований. Обслуживание требований в СМО производится обслуживающими приборами. Классическая СМО содержит от одного до бесконечного числа приборов.

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

Рассмотрим модель до внедрения информационной системы. По данным наблюдений, проводимых в течение трех месяцев, средняя частота поступления обращений л=5 заявок/час, при этом диспетчер комфортно справляется с большим числом заявок м=6 заявок/час, среднее время обслуживания одного сотрудника, подавшего заявку x=1/5 = 0,167 часа. Диспетчер работает один, так что число каналов m=1.

Найдем нагрузку на СМО: с=л/(mм) = 0,83.

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

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

.

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

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

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

,U=0,83;

Среднее число заявок в обслуживании

, S=0,83 заявок;

Среднее число заявок в СМО

, k=5 заявок;

Пропускная способность СМО

,г=5 заявок/час;

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

, w=0,417 часа;

Среднее время пребывания заявки в СМО

,t=0,5 часа.

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

Диспетчер загружен на 83%, т.е. занят обслуживанием сотрудников, обратившихся с неисправностями в течение 83% всего времени своей работы. В течение 17% времени диспетчер простаивает из-за отсутствия заявок. Таким образом, загрузка диспетчера достаточно высока. Такую загрузку можно считать нормальной. Однако дальнейшее увеличение загрузки нежелательно. визуальный интерфейс математический алгоритм

В среднем в очереди находится 4,17 заявки, а в магазине (т.е. в очереди и на обслуживании) - 5 заявок. Диспетчер обслуживает в среднем 5 заявок в час, т.е. все поступающие заявки. Время от информирования диспетчера о поступившей заявке до начала ее обслуживания (т.е. время пребывания заявки в очереди) составляет в среднем 0,417 часа. Время от поступления заявки до окончания ее обслуживания (время пребывания заявки в ожидании решения об исполнении) составляет в среднем 0,5 часа. Если сравнить это время с длительностью рабочего дня и учесть тот факт, что до момента появления на месте специалиста может пройти еще больше времени, то данный показатель можно считать неудовлетворительным.

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

Таким образом, новые показатели для системы составляют:

средняя частота поступления обращений л=5 заявок/час,

интенсивность обслуживания заявок м=12 заявок/час, среднее время обслуживания одного сотрудника, подавшего заявку x=1/12 = 0,083 часа. Будем считать, что число каналов m=1.

Найдем нагрузку на СМО:

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

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

е P0 = 1-с: P0=0,58.

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

.

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

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

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

, U=0,42;

Среднее число заявок в обслуживании

, S=0,42 заявок;

Среднее число заявок в СМО

, k=0,47 заявок;

Пропускная способность СМО

, г=5 заявок/час;

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

, w=0,03 часа;

Среднее время пребывания заявки в СМО

, t=0,094 часа.

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

Диспетчер загружен на 42 %, т.е. занят обслуживанием сотрудников, обратившихся с неисправностями в течение 42% всего времени своей работы. В течение 58% времени диспетчер простаивает из-за отсутствия заявок. Таким образом, загрузка диспетчера меньше среднего уровня. Такую загрузку можно считать оптимальной, по той причине, что она позволяет создать запас на случай возрастания интенсивности поступления заявок. Кроме того, 58% освобожденного времени можно потратить на функции контроля над исполнением заявок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



• 3. Проектирование информационной системы help desk отдела технической поддержки ООО Трейд

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

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

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы [11]:

- системы на основе архитектуры файл-сервер;

- системы на основе архитектуры клиент-сервер;

- системы на основе многоуровневой архитектуры;

- системы на основе технологии интернет/интранет.

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

Таблица 3.1 - Типовые функциональные компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

По способу организации информационные системы разделяются следующим образом:

- системы на основе архитектуры файл-сервер;

- системы на основе архитектуры клиент-сервер;

- системы на основе многоуровневой архитектуры.

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.

Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность данных (нет прямого доступа к данным).

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

- нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;

- средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

- верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без использования хранимых процедур).

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной.

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

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

Благодаря интеграции Интернет/Интранет-технологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.

Вывод: Для решения задачи проектирования информационной системы help desk отдела технической поддержки ООО Трейд подходит технология Интернет/Интранет на базе многоуровневой архитектуры, так как в данной системе обрабатывается малый объем данных и не должно существовать никакого дополнительного ПО для ее использования на стороне клиента.

Архитектура информационная система help desk отдела технической поддержки ООО Трейд показана на рисунке 3.1.

Рисунок 3.1 - Архитектура системы

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

Сервер приложения реализуется в виде WEB-приложения, которое может исполняться в контексте среды исполнения, работающего например, на Java и реализующего стандарты Java-сервлетов. Для снижения нагрузки на сервер приложений за счет кэширования передаваемого контента, а также реализации дополнительных функций, таких как Virtual Hosts, SSL перед сервером приложений может проводиться установка одного из популярных Web-серверов: Apache, nginx, MS IIS.

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



• 3.2 Проектирование структуры информационной системы help desk

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

В системе предусмотрены следующие роли:

1. Администратор. Отвечает за настройки системы, выдачу прав и ролей пользователям, наполнением справочников. Имеет доступ ко всем объектам системы (рисунок 3.2).

Рисунок 3.2 - Варианты использования информационной системы для администратора

2. Инициатор. Создает новую заявку, имеет доступ на просмотр своих открытых заявок, добавляет комментарии к своим открытым заявкам, а также меняет статус. После создания заявки ее статус становится "Открыта". Инициатор может закрыть свою заявку (рисунок 3.3).

Рисунок 3.3 - Варианты использования информационной системы для инициатора

3. Диспетчер. Заполняет дополнительные атрибуты заявки: классифицирует заявку, назначает приоритет и крайний срок, назначает исполнителей. После назначения исполнителя статус заявки становится "Назначен исполнитель". Диспетчер может зарыть заявку (рисунок 3.4).

Рисунок 3.4 - Варианты использования информационной системы для диспетчера

4. Исполнитель. Исполнитель может менять статус заявки на "Выполняется" и "На проверке", вносить комментарии. Получив или отредактировав заявку, исполнитель меняет ее статус на "Выполняется". Выполнив заявку, исполнитель меняет ее статус на "На проверке" (рисунок 3.5).

Рисунок 3.5 - Варианты использования информационной системы для исполнителя

5. Руководитель. Если у исполнителя есть флаг руководителя, то он может также менять приоритет, крайний срок, а также назначать других исполнителей (рисунок 3.6).

Рисунок 3.6 - Варианты использования информационной системы для руководителя

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

Таблица 3.2 - Маршрут заявок

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

Начнем с процесса создания заявки (рисунок 3.7).

Рисунок 3.7 - Создание заявки в системе

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

Следующий процесс - обработка заявки диспетчером (рисунок 3.8)

Рисунок 3.8 - Обработка заявки диспетчером

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

Следующий важный аспект - то, как обрабатывает заявку с помощью информационной системы руководитель (рисунок 3.9).

Рисунок 3.9 - Обработка заявки руководителем

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

Перейдем к рассмотрению того, как с помощью информационной системы обрабатывает заявку исполнитель (рисунок 3.10).

Рисунок 3.10 - Обработка заявки исполнителем

И последний аспект - то, как может быть обработана заявка по факту ее выполнения исполнителем (рисунок 3.11)

Рисунок 3.11 - Закрытие или возврат заявки на доработку

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

• 3.3 Проектирование модели данных для информационной системы help desk

Методология IDEF1X [12] - один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы

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

Основными объектами концептуальной модели являются сущности и связи.

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

Правила для атрибутов сущности:

1. Каждый атрибут должен иметь уникальное имя.

2. Сущность может обладать любым количеством атрибутов.

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

4. Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null).

5. Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.

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

Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и зависимой, и связей - идентифицирующих и неидентифицирующих.

Для начала специфицируем концептуальную модель данных, чтобы на ее основе создать логическую и физическую. Выделим все сущности с атрибутами (таблицы 3.3 - 3.7).

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

Таблица 3.3 - Сущность заявка

продолжение таблицы 3.3

Диспетчеры. Список пользователей, сопоставленных с ролью "диспетчеры"

Таблица 3.4 - Сущность диспетчер

Исполнители. Список пользователей, сопоставленных с ролью "исполнители"

Таблица 3.5 - Сущность исполнитель

Категории заявок. Список, служащий для категоризации заявок

Таблица 3.6 - Сущность категории заявок

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

Таблица 3.7 - Сущность службы (отделы)

Мы определили концептуальную модель, теперь можно перейти к созданию логической и физической модели с помощью программы ER Win Data Modeller (рисунки 3.12 и 3.13 соответственно).

Рисунок 3.12 - Логическая модель данных

Логическая модель данных показывает основные объекты, данные о которых необходимо хранить в процессе работы информационной системы help desk отдела технической поддержки ООО Трейд. Для перехода на физический уровень следует исключить связи "многие ко многим", такая связь одна - "заявка - исполнители" (рисунок 3.13).

Рисунок 3.12 - Физическая модель данных

Для устранения связей многие-ко-многим была введена дополнительная сущность: ремонтная бригада, которая соединяет исполнителей и заявку.



• 4. Реализация информационной системы help desk отдела технической поддержки ООО Трейд
• 4.1 Выбор средств реализации

Чтобы реализовать информационную систему help desk отдела технической поддержки ООО Трейд необходимо выбрать операционную систему для серверной части ИС, СУБД и систему управления сайтом, которая будет платформой для запуска информационной системы.

Выбор операционной системы.

Необходимо выбрать ОС, под управлением которой будет работать сервер. Рассмотрим серверные операционные системы. Назначение серверной операционной системы -- это управление приложениями, обслуживающими всех пользователей корпоративной сети, а нередко и внешних пользователей. К таким приложениям относятся современные системы управления базами данных, средства управления сетями и анализа событий в сети, службы каталогов, средства обмена сообщениями и групповой работы, Web-серверы, почтовые серверы, корпоративные брандмауэры, серверы приложений самого разнообразного назначения, серверные части бизнес-приложений. Требования к производительности и надежности указанных операционных систем очень высоки; нередко сюда входят и поддержка кластеров (набора ряда однотипных компьютеров, выполняющих одну и ту же задачу и делящих между собой нагрузку), и возможности дублирования и резервирования, и переконфигурации программного и аппаратного обеспечения без перезагрузки операционной системы.

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

Windows Server

Создание семейства Windows Server стало следующим шагом в развитии операционных систем Windows. Основными особенностями данного семейства операционных систем являются наличие в их составе платформы Microsoft .NET Framework, а также поддержка Web-сервисов XML (вплоть до наличия в составе операционной системы UDDI-сервера).

Windows Server существует в четырех редакциях:

* Windows Server Web Edition -- операционная система для развертывания и обслуживания Web-приложений и Web-сервисов, включая приложения ASP .NET;

* Windows Server Standard Edition -- сетевая операционная система для выполнения серверной части бизнес-решений и рассчитанная на применение в небольших компаниях и подразделениях. Здесь имеются средства совместного использования ресурсов и централизованного развертывания приложений для настольных компьютеров, а также реализована поддержка до 4 Гбайт оперативной памяти и симметричной многопроцессорной обработки с использованием двух процессоров;

* Windows Server Enterprise Edition -- ОС, которая прежде всего предназначена для средних и крупных компаний. Она поддерживает серверы на базе 64-разрядных процессоров (до восьми штук) и объем оперативной памяти до 64 Гбайт и выпускается в версиях для 32- и 64-разрядных платформ;

* Windows Server Datacenter Edition -- операционная система, которая служит для создания критически важных технических решений с высокими требованиями к масштабируемости и доступности. К таким решениям относятся приложения для обработки транзакций в режиме реального времени, а также решения, основанные на интеграции нескольких серверных продуктов. В данной ОС реализована поддержка симметричной многопроцессорной обработки с использованием до 32 процессоров, а также имеются службы балансировки нагрузки и создания кластеров, состоящих из восьми узлов. Эта ОС доступна для 32- и 64-разрядных платформ.

...