K005196 Дипломная работа Организация службы технической поддержки

Содержание

Введение 8

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

1.1 Общие концепции службы технической поддержки 10

1.2 Цель и задачи службы технической поддержки 18

1.3 Цель и задачи разработки системы 24

1.4 Формулировка требований к системе 29

2. Выбор и обоснование алгоритмов работы системы 30

2.1 Общие понятия работы Service Desk 30

2.2 ITIL 31

2.3 Схема приема и обработки заявки 33

2.4 Выводы 34

3. Проектирование системы обработки заявок 35

3.1 Общие принципы работы системы 35

3.2 Состав системы 37

3.3 Система приема исходных данных для заявки 39

3.4 Система создания типовых решений и самообслуживания 41

3.5 Система обратной связи с заказчиком 41

4. Экономическое обоснование 43

4.1 Исследование рынка аналогичных программных продуктов 43

4.2 Расходы, связанные с созданием системы 43

4.3 Расчет экономической эффективности от продажи системы 50

5. Охрана труд  58

5.1 Требования к ПЭВМ 58

5.2 Требования к помещениям для работы с ПЭВМ  61

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

 в воздухе на рабочих местах, оборудованных ПЭВМ……………………62

5.4Требования к шуму и вибрации………………………………………...      64

5.5Требования к освещению помещений и рабочих мест с ВДТ и ПЭВМ ...64

5.6Общие требования к организации рабочих мест пользователей ПЭВМ...66

5.7Выполненные требования…………………………………………………..67

Заключение……………………………………………………………………...71

Список использованных источников…………………………………………. 72

Введение

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

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

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

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

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

1.1 Общие концепции службы технической поддержки

В настоящее время без службы технической поддержки не обходится ни одна компания. В данную службу попадают заявки от пользователей технических средств организации при программно, аппаратном сбое, в случае не способности самостоятельно справиться с возникшей проблемой ( не связанной со сбоями) и др. На малых предприятиях она чаще всего представлена одним единственным системным администратором, но с ростом организации число проблем у пользователей, а соответственно и число людей, занимающихся поддержкой, сильно возрастает. Обычно при этом данную службу именуют одним из вариантов: “Call Center”, “Help Desk”, “Service Desk”. Рассмотрим более подробней из чего состоит такая служба и каковы ее концепции.

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

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

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

В этом случае пользователь может выбрать различные варианты поведения: заняться «самолечением» - то есть попробовать самостоятельно решить проблему; обратиться за помощью к коллегами; обратиться к поставщику сервиса. Каковы плюсы и минусы у каждого из вариантов?

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

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

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

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

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

Приняв решение о необходимости обратиться за поддержкой в службу ИТ, пользователь обычно оказывается в несколько неопределенной ситуации: кому именно задать вопрос? Здесь тоже возможны различные ситуации.

Спросить знакомого. Легче всего обратиться к человеку, которого знаешь. И он обязательно поможет, если конечно это в его силах. А как быть, если такого знакомого нет? Или в случае. Когда у него недостаточно полномочий? Или если он занят выполнением важной работы?

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

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

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

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

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

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

В общем случае необходимые изменения в организации службы ИТ связаны с возникновением новых ролей в результате формального описания процессов взаимодействия. Роль - это набор обязанностей, прав и ответственностей. Это понятие близко к понятию «должность», отличается от последнего тем, что не предполагает штатного закрепления: исполнитель роли может меняться в соответствии с графиком или по иньм правилам. В отдельных случаях (как, например, отмечалось выше - в случае диспетчеров) для исполнения роли может быть создана специальная штатная единица. Но в основном роли распределяются между имеющимися сотрудниками службы ИТ.

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

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

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

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

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

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

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

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

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

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

• состояние сервисов ИТ

• качестве функционирования сервисов и составляющих их компонент

• уровне подготовленности пользователей

• стандартных запросах пользователей

• методах разрешения запросов пользователей

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

• качестве функционирования оперативных служб ИТ

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

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

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

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

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

Для службы поддержки таковым метриками могут быть

• количество обращений пользователей в службу

• количество обращений, обработанных диспетчером без привлечения специалистов

• среднее время обработки обращений пользователей

• средние уровни эскалации обращений

• общее количество зарегистрированных инцидентов

• среднее время устранения инцидентов

• уровень доступности службы поддержки для конечных пользователей

• уровень загруженности персонала службы поддержки

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

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

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

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

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

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

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

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

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

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

Еще одна группа ролей - внешние поставщики сервисов. Порядок взаимодействия с ними определяется в соответствии с сервисными контрактами. Желательно стремиться к стандартизации правил взаимодействия, но это не самоцель.

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

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

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

• Запрос информации (консультации). Пользователю нужна дополнительная информация по сервису ИТ, порядку работы ит.п.

• Инцидент. Пользователь не может нормально работать: сервис ИТ недоступен или качество сервиса не удовлетворяет пользователя.

• Запрос документации. Пользователю необходима документация по применяемому оборудованию и программному обеспечению.

Запрос на внесение изменений. Пользователь хотел бы изменить параметры сервиса ИТ либо изменить список получаемых сервисов. Часто такие запросы связаны с низким (не удовлетворяющим пользователя) качеством сервиса по вине оборудования или программного обеспечения.

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