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

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

2.3.1 Анализ и разработка бизнес-процессов отдела технической поддержки ООО «ЦСС»

В ходе написания выпускной квалификационной работы выявлена необходимость изучить структуру происходящих внутри бизнес-процессов отдела технической поддержки. С помощью программы Bussines Studio, была построена модель, которая работает в настоящее время, применив структурный подход и нотацию IDEF0 (Рисунок 1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3 - Диаграмма декомпозиции бизнес-процесса «Мониторинг состояния КТС и ПО»

В проектной работе также приведены бизнес-процессы «Регистрировать факт возникновения неисправности» (Рисунок 4) и «Передать заявку на исполнение» (Рисунок 5). Раскрытие этих процессов отображены в нотации IDEF3 для того, чтобы увидеть недостатки протекающих процессов и их узкие места.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По результатам реинжиниринга процесс «Регистрировать факт возникновения неисправности» (Рисунок 6) имеем следующие элементарные процессы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также в проектной работе можно рассмотреть, как с помощью информационной системы обрабатывает заявку исполнитель (Рисунок 10), а также то, как может быть обработана заявка по факту ее выполнения исполнителем (Рисунок 11).

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

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

2.3.2 Расчет стоимости внедрения системы Service Desk

Общая стоимость внедрения автоматизированной системы, составит 83 000 рублей которая будет в себя включать:

1) базу знаний;

2) получение заявок через web-сайт и e-mail;

3) каталог сервисов;

4) отчетность и аналитику;

5) мобильную и компьютерную версии;

6) настройку маршрутизации;

7) контроль исполнения заявок;

8) лицензирование;

9) интуитивно-понятный интерфейс.

В стоимость работы:

1) предпроектная часть 5 000 рублей;

2) проектная часть 5 000 рублей;

3) стадия внедрения 55 000 рублей;

4) анализ функционирования 18 000 рублей.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

5) создание блока «Часто задаваемые вопросы» на сайте компании;

6) разработка базы знаний;

7) внедрение круглосуточной поддержки, посредством увеличения штата технической поддержки, для постоянного дежурства сотрудников на рабочем месте;

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

9) разработка и внедрение автоматизированной системы «Service Desk».

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Ипатова Э. Р., Ипатов Ю. В. - Методологии и технологии системного проектирования информационных систем; / Ипатова Э. Р., Ипатов Ю. В. - Флинта - М., 2015. - 256 c.;

2. Куликов Г. Г. - Методика интеграции информационно-поисковых и корпоративных информационных систем на основе системных моделей бизнес-процессов; Синергия - М., 2014. - 897 c.;

3. Молчанова Е.Н. - Научная статья: Современные телекоммуникационные технологии и формирование информационной культуры в России. /Молчанова Е.Н. - Москва 2019. с.10;

4. Советов Б.Я. - Архитектура информационных систем; Академия (Academia)/ Советов Б.Я. - М., 2017. - 934 c.;

5. Ступкин В. В. - Методология оценки качества интегрированных библиотечно-информационных систем; /Ступкин В. В.-Литера - М., 2016. - 162 c.

6. Должностная инструкция отдела технической поддержки ООО «Центр систем связи» ред.2019;

7. Организационная политика ООО «Центр систем связи» ред.2019 - 8-14 с;

8. Шастова Г. А., Коёкин А. И. - Выбор и оптимизация структуры информационных систем;/ Шастова Г. А., Коёкин А. И. -Энергия - М., 2014. - 255-256 с.;

9. Руководство по разработке технического задания ГОСТ 34.602-89; - Москва, 2017. - 25-32 с.;

10. Шелухин О. И., Тенякшев А. М., Осин А. В. - Моделирование информационных систем; / Шелухин О. И., Тенякшев А. М., Осин А. В. -Радиотехника - М., 2015. - 368 c.

ПРИЛОЖЕНИЕ

Журнал учета инцидентов

Программное обеспечение

Единая автоматизированная система для работы технической поддержки Service Desk

АС «Service Desk»

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На 17 (семнадцати) листах

Действует с «03» июня 2019 года

СОГЛАСОВАНО

Руководитель (Директор Малов Дмитрий Сергеевич

ООО «Центр систем связи»)

Личная подпись Расшифровка подписи

Печать

Дата

Техническое задание

Сведения о проекте

Внедрение Автоматизированной системы «Service Desk» в работу технической поддержки компании ООО «Центр систем связи».

Функциональная структура предприятия

1. Общие положения

1.1 Полное наименование системы: Единая автоматизированная система для работы технической поддержки «Service Desk»

1.2 Краткое наименование системы: АС «Service Desk».

1.3 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты:

Заказчиком системы является ООО «Центр систем связи».

Адрес заказчика: 664033 г. Иркутск, ул. Лермонтова, д.134/1.Разработчиком системы является ООО «Кларис»

1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы:

Техническое задание по созданию Единой автоматизированной системы для работы технической поддержки.

1.5 Плановые сроки начала и окончания работы по созданию и внедрению системы: 80 дней.

1.7 Сведения об источниках и порядке финансирования работ:

Источником финансирования является бюджет ООО «Центр систем связи». Порядок финансирования определяется условиями Договора подрядных работ.

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

1.9 Состав используемой нормативно-технической документации:

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;

1.10 Определения, обозначения, сокращения.

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

Help Desk - отдельное подразделение, которое решает вопросы по приему и обработки запросов пользователей, подразумевает функции начальной технической поддержки. В отличии от Service Desk, Help Desk участвует только в одном процессе - Управление Инцидентами.

Service Desk - более широкое понятие, чем Help Desk, подразумевает функции приема и обработки обращений от пользователей по различным вопросам, связанным с ИТ: Инцидентов, запросов на обслуживание, жалоб, запросов на изменения, а также их последующий анализ и интерпретацию. Далее по тексту документа под сочетанием «Service Desk» либо «Служба» или «Служба поддержки» подразумевается именно отдельная служба Service Desk.

SLA - Service Level Agreement (Соглашения об уровне обслуживания), документ, в котором предъявляются требования к основным измеряемым характеристикам услуги или Сервиса

2. Назначение и цели создания (развития) системы

2.1 Назначение системы:

АС «Service Desk» предназначена для комплексного сбора информации и обработки процессов обращения клиентов и решения проблем ООО «Центр систем связи» в части исполнения следующих процессов:

· Введение и хранение данных клиентов по обращениям в техподдержку в единой базе данных.

· Отображение данных о статусе обращения клиента.

2.2 Цель создания системы:

§ Внедрение АС для возможности автоматизации комплексного информационного обеспечения процессов обработки обращений клиентов.

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

§ Повышение эффективности обслуживания людей, за счет увеличения быстроты обработки заявок.

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

3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию:

Служба техподдержки ООО «Центр систем связи» осуществляет процессы по решению инцидентов, а также контроль работы оборудования клиента.

Данные процессы осуществляются следующими специалистами:

· Руководитель техподдержки;

· Специалисты технической поддержки.

Основные задачи, функции и полномочия ООО «Центр систем связи» определены Уставом организации, утвержденным 15 февраля 2017 года.

3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

3.2.1 Существующее программное обеспечение

Отсутствует АС, данные хранятся в Google Таблице.

3.2.2 Существующее техническое обеспечение

3 ПК Intel Core i3 2.8Гц, 2048 МБ ОЗУ

3.2.3 Существующее нормативно-правовое обеспечение

Федеральный закон о персональных данных;

3.3 Требования к организации и разграничению прав доступа.

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

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

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

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

Система разграничения прав пользователей АС должна обеспечивать:

· Ограничение на доступ пользователей (групп пользователей) к выполнению функций системы (заполнение документов, получение отчётов и т.п.).

· Ограничение на доступ пользователей (групп пользователей) к группам документов по признакам, содержащимся в документе.

· Ограничение на доступ пользователей (групп пользователей) к отдельным реквизитам документов.

· Ограничение на доступ пользователей (групп пользователей) к данным по отдельным контрагентам (группам контрагентов).

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

4. Требования к системе

4.1. Требования к системе в целом;

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

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

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

· Повышение точности поиска с использованием ключевых слов и разделов.

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

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

· Архивация старых и неиспользуемых данных для повышения производительности работы службы ИТ-поддержки.

· Удобные возможности поиска, доступа и экспорта архивных данных в любое время.

4.1.1. Перечень и назначение подсистем:

Подсистема хранения данных, необходима для хранения данных системы, а именно данных о клиентах и их обращениях в техническую поддержку;

Подсистема обработки заявок, необходима для быстрого и качественного обслуживания клиентов;

Подсистема статистики обращений.

4.1.2. Требования к персоналу системы:

Для функционирования системы необходимы следующие специалисты:

Системный администратор, администратор БД, руководитель и специалисты техподдержки (пользователи).

Функциями системного администратора является:

· Установка, модернизация, настройка параметров программного обеспечения СУБД;

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

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

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

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

4.2. Требования к функциям (задачам), выполняемым системой;

Подсистема обработки заявок:

· Удобное создание заявок;

· Регистрация заявок через электронную почту;

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

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

· Регистрация заявок на сайте компании;

· Регистрация заявок через соцсети и мессенджеры (Vkontakte, Facebook, Telegram, WhatsApp, Viber);

· Информирование пользователей об обработке запросов и подтверждениях с помощью автоматических уведомлений;

· Информирование в масштабах всей компании о предстоящих перерывах в обслуживании;

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

· Настраиваемые формы заявок;

· Удаленное управление.

4.3. Требования к видам обеспечения

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

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

· Хранение данных должно осуществляться на основе современных реляционных или СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.

· Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в системе информации.

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

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

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

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



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

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

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



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

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

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

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

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

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

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

Техническое обеспечение системы должно максимально и наиболее эффективным образом использовать существующие в органах федерального агентства технические средства.

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

- Серверы БД;

- ПК пользователей;

- ПК администраторов.

5. Состав и содержание работ по созданию (развитию) системы

Этапы:

1. Предпроектная стадия:

1.1. Обследование объекта и обоснование необходимости создания ИС;

1.2. Формирование требований пользователя к ИС;

1.3. Оформление отчета о выполненной работе и заявки на разработку ИС;

1.4. Разработка и утверждение технического задания ИС.

2. Проектная часть:

2.1. Разработка проектных решений по системе и ее частям;

2.2. Разработка документации на ИС;

2.3. Разработка и оформление документации на поставку изделий для комплектования ИС;

2.4. Разработка рабочей документации на систему или ее части;

2.5. Разработка или адаптация программ.

3. Стадия внедрения:

3.1. Подготовка объекта автоматизации к вводу в действие;

3.2. Подготовка персонала, проводится обучение персонала;

3.3. Строительно-монтажные работы, в том случае, если строится специализированное здание;

3.4 Проведение предварительных испытаний;

3.5. Проведение опытной эксплуатации;

3.6. Проведение опытных испытаний;

3.7. Введение в промышленную эксплуатацию.

4. Анализ функционирования:

4.1. Гарантийное и послегарантийное обслуживание;

4.2. Внесение изменений в проектные решения.

Сроки выполнения работы: 80 дней.

Стоимость работ:

Этап	Стоимость
Предпроектная часть	5 000 рублей
Проектная часть	5 000 рублей
Стадия Внедрения	55 000 рублей
Анализ Функционирования АС	18 000 рублей

Суммарная стоимость проекта: 83 000 руб.

6. Порядок контроля и приемки системы:

В ходе выполнения проекта на объекте автоматизации требуется выполнить работы по подготовке к вводу системы в действие. При подготовке к вводу в эксплуатацию АС «Service Desk» Заказчик должен обеспечить выполнение следующих работ:

- Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации АС «Service Desk»;

- Обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;

- Обеспечить соответствие помещений и рабочих мест пользователей системы в соответствии с требованиями, изложенными в настоящем ЧТЗ;- Обеспечить выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение АС «Service Desk»;

- Совместно с Исполнителем подготовить план развертывания системы на технических средствах Заказчика;

- Провести опытную эксплуатацию АС «Service Desk»;

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1. Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2. Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

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

4. Сроки и порядок комплектования штатов и обучения персонала.

8. Требования к документированию:

8.1. Согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика. Перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

8.2. Требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

9. Источники разработки:

- ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».

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

...