Файл: Автоматизация обработки обращений в службу технической поддержки.pdf

• Проектные решения Системы такого класса используются при очень больших объёмах данных, клиентов, тикетов и обращений. Уникальность таких систем заключается в абсолютной интеграции продукта с внутренними информационными системами, сервисами, высокой модульности ServiceDesk’а, которая обеспечивает максимальную функциональность, а также полную свободу в отношении разработки дополнительных средств. В ходе рассмотрения HelpDesk систем мною были отобраны следующие

• Тип решения – SaaS или локальное программное обеспечение, с клиент-серверной архитектурой • Пользовательский интерфейс

• БД серверной части – желательна база данных, с которой могут работать работники компании

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

• Цена – как и любая коммерческая компания, ориентированная на прибыль, она должна минимизировать свои издержки и затраты, в том числе и от внедрения стороннего ПО в работу компании. В данном случае цена будет рассматриваться трёхфакторным компонентом: цена за лицензию, цена за обслуживание в год, цена за апгрейд системы.

• Поддерживаемые ОС – данный фактор важен при разворачивании систем в службе технической поддержки IT-компании. Двухфакторный компонент: ОС сервера, ОС рабочей станции

• Вид разработки – наличие открытого исходного кода

• Язык реализации – наилучшим выбором будет ЯП, которым владеют разработчики компании.

• Наличие встроенного workflow инструмента – позволит осуществлять автоматизированные процессы обслуживания клиентов

• Статистические инструменты – возможность составления отчётности путём использования встроенных средств Help Desk системы

• Поддержка кириллических систем кодирования – так как основной рынок работы данной IT-компании – российский, то важна поддержка кодировок

• ETG инструмент – наличие данного средства позволит наиболее эффективно обрабатывать запросы пользователей

• PINKVERIFY – является предпочтительным наличие данного статуса так, как говорит о соответствии программного продукта стандартам ITIL/ITSM и ISO 9000 ISO/IEC 20000

• База знаний – необходим инструмент ведения и редактирования базы

• CEM инструмент – необходимая составляющая для осуществления многоуровневой поддержки.

2.1 Информационная модель и её описание

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

В соответствии с представленной информационной моделью менеджер заполняет справочник (Состояние проектов). После менеджер, используя данные которые указаны в справочниках Клиентов, Сотрудники, Города, Фирмы, состояния проектов, меняет содержание таблицы Проекты. На основании таблицы Проекты и Справочника Состояние проектов менеджер получает экранные формы выходных документов, таких, как список проектов и список выполнения проектов. Примером служит рисунок 2.

Рисунок 2. Информационная модель

2.2 Используемые классификаторы и системы кодирования

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

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

1. Общегосударственные классификаторы которые используемые во всех отраслях и на всех уровнях управления для повсеместного и одинакового обозначения объектов

2. Отраслевые классификаторы- которые используются в пределах определенной отрасли

3. Локальные используемые в пределах организации или группы организации.

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

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

Система кодирования — это совокупность правил обозначения объектов и группировок с использованием кодов.

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

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

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

В системе используется следующие виды системы кодирования, указанные в Рисунок 3.

Рисунок 3. Виды системы кодирования.

2.3 Ожидаемые риски на этапах жизненного цикла и их описание

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

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

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

Таблица 2. Наиболее характерные риски и методы из минимизации

2.4 Характеристика нормативно-справочной, входной и оперативной информации

В системе используются справочники, приведенные в таблице 3 и Реквизитный состав справочников таблица 4

№ ПП	Наименование справочника	Ответственный за ведение	Средний объём справочника в записях	Среднюю частоту актуализации	Средний объем актуализации, %
1	Сотрудники	Администратор	100	5-6 раза в месяц	10
2	Фирма	Администратор	50	1 раз в месяц	10
3	Клиенты	Пользователь	50	3 раза в месяц	10
4	Город	Администратор	500	4 раза в неделю	60
5	Состояние	Пользователь	50	2 раз в месяц	10

Таблица 3. Справочники.

№ пп	Наименование	Перечень реквизитов
1	Сотрудники	Фамилия Имя Отчество
		Дата рождения
		Наименование должности
2	Фирма	Наименование
		Город
		Организационная форма
		Постоянный представитель
3	Клиенты	Фирма (наименование)
		Фамилия, имя, отчество
		Дата регистрации
		Адрес (фактический)
		Адрес электронной почты
		ФИО руководителя
4	Состояние проектов	Наименование состояния