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

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

Введение 3
Глава 1. Основные принципы библиотеки ITIL 5
1.1. Общие сведения о концепции ITIL. ИТ-услуга как продукт и объект управления 5
1.2. Внедрение процессов ITIL. Проблемы и преимущества 12
1.3. Управление инцидентами. Service Desk 21
Глава 2. Анализ деятельности отдела технической поддержки в брокерской компании 36
2.1. Характеристика компании 36
2.2. Описание работы службы технической поддержки 39
2.3. Обоснование необходимости автоматизации 47
Глава 3. Разработка программного обеспечения для учета заявок пользователей, соответствующего спецификации ITIL 52
3.1. Выбор программно-аппаратных средств 52
3.2. Описание алгоритма работы ПО 56
3.3. Разработка интерфейса 59
Заключение 63
Список использованной литературы 64
Приложение 1 68
Приложение 2 72

В последние годы информационные и компьютерные технологии оказывают очень большое влияние на бизнес-процессы. Организации активно используют глобальную сеть Интернет для более быстрого продвижения своих продуктов и услуг на рынок. В организациях, которые построены по традиционным системам, очень часто появляются проблемы с реагированием на быстро изменяющиеся рынки. Это способствует появлению множества более гибких компаний, которые используют в своей организационной структуре меньшую степень иерархичности. Как следствие, изменились и внутренние структуры в сторону большей «горизонтальности» процессов, работающих в рамках всей компании, как следствие часто решения принимаются и на более низких уровнях.
В таких условиях всё большую актуальность приобретают разработанные в Великобритании в 8 0-х годах методики рационального и эффективного использования ИТ-ресурсов компании, целью которых являлась разработка подхода, общего для всех организаций и не зависящего от поставщика услуг.
Руководствуясь этими методиками, некоторые крупные коммерческие предприятия, например, Hewlett-Packard, Microsoft, IBM и многие другие, разработали свои собственные подходы к управлению ИТ-процессами. Поэтому ITIL стала стандартом в описании ИТ-процессов, пособием по организации ИТ-сервиса.
В соответствии с принципами ITIL, во главу угла ставится улучшение процесса обслуживания клиентов, чтобы при появлении инцидентов и неполадок клиент всегда мог обратиться к сотрудникам компании и в ближайшее время получить помощь от квалифицированного специалиста.
Одним из основных факторов формирования благоприятной для клиента и эффективной информационной инфраструктуры является создание службы поддержки Service Desk, по организации которой в библиотеке ITIL также есть множество руководств.
Актуальность данной дипломной работы состоит в том, что рекомендации библиотеки ITIL могут улучшить ИТ Сервис-менеджмент практически любой организации. Кроме того, многие компании по каким-то причинам не опираются на передовой опыт, который описан в библиотеке ITIL. В результате этого они занимаются решением проблем, которые уже много раз были решены, а лучшие решения проанализированы и являются основой для библиотеки рекомендаций.
Объект работы – создание технической поддержки в организации.
Предметом работы являются рекомендации библиотеки ITIL к организации службы поддержки и их применение.
Целью дипломной работы является применение результатов анализа передовых практик и рекомендаций библиотеки ITIL к работе службы поддержки пользователей.
Для достижения поставленной цели были определены следующие задачи:
1. Изучение основных принципов библиотеки ITIL;
2. Рассмотреть проблемы и преимущества внедрения процессов ITIL;
3. Дать характеристику компании, ее организационной структуры;
4. Проанализировать работу службы технической поддержки и обосновать необходимость автоматизации;
5. Выбрать программные и аппаратные средства для автоматизации;
6. Описать алгоритм работы ПО;
7. Разработать интерфейс.
В результате работы разработана программа для автоматизации службы технической поддержки пользователей, соответствующая рекомендациям библиотеки ITIL, с учетом поставленных в работе задач.
 

При этом нужно стремиться к тому, чтобы все были максимально информированы.В противном случае даже при назначении «идеального» менеджера процесса управления проблемами будет недостаточно для качественного внедрения и последующей эффективной эксплуатации процесса, так как участники процесса будут отторгать или игнорировать его, не признавать его важность для организации.Правильная подготовка к внедрению процесса управления проблемами, состоящая в выявлении и вовлечении всех заинтересованных лиц и осознании ими потребности в процессе, во многом гарантирует успех последующих мероприятий по фактическому внедрению процесса, принятию его регламентов и политик.Подводя итог сказанному выше, можно сделать следующие выводы:Процесс управления проблемами не является внутренним для поставщика ИТ-услуг. Для него нужно определить его целевых потребителей, генерирующих постоянный спрос на результаты процесса. Эти люди должны быть хотя бы проинформированы о качестве исполнения процесса и его результатах.Процесс управления проблемами не всегда воспринимается так же необходимым, как и процесс управления инцидентами. Перед внедрением процесса нужно провести подготовительные мероприятия по распространению понимания его ценности, формированию спроса на процесс.Попытки внедрить процесс управления проблемами с формальным отношением к определению и вовлечению заинтересованных лиц имеют большой риск оказаться нежизнеспособными и невостребованными, даже при высочайшем качестве реализации остальных компонентов процесса и проведенных во время внедрения мероприятий.Управление инцидентами. Service DeskВ современном бизнесе в условиях жесткой конкуренции очень важна удовлетворенность клиентов уровнем обслуживания. Для наиболее быстрого разрешения проблем, возникающих у клиентов, нужен структурированный механизм поддержки клиентов. Часто подобные инциденты происходят с завидной регулярностью, и, перед тем, как выяснится причина их возникновения, возникает необходимость решать их снова и снова. Когда формализованный механизм поддержки клиентов отсутствует, вносятся нескоординированные и письменно не зафиксированные изменения. В результате компания попадает в зависимость от определенных ключевых специалистов, занимающихся этой проблемой, а технические решения часто принимаются интуитивно, а не на основании фактов.Решить данные проблемы призвана диспетчерская служба Service Desk (рис. 5).Функции Service Desk – это прием звонков, регистрация и отслеживание инцидентов, информирование клиентов о состоянии их запроса, проведение первоначальной оценки обращения, попытка решить его или определить, кто в состоянии его решить, управление жизненным циклом инцидентов. Бывает, что в зависимости от квалификации специалистов Service Desk, заявки группируются в первую, вторую и так далее линии поддержки, так как это позволяет сократить затраты на поддержку. Рисунок 5 – Участие Service Desk в процессах ITIL [18, с.67]Для понимания процессов работы Службы Service Desk нужно определиться с основными терминами и их определением, которые в разных источниках отличаются. В ITIL все Запросы (обращения) можно регистрировать и отслеживать, как Инциденты. Однако, было бы правильнее, когда под Проблемой подразумевается событие, которое может привести к остановке нормальной работы Сервиса или значительно ухудшить качество работы этого сервиса. Под Инцидентом, подразумевается более критические события, в работе вышеупомянутого Сервиса (выходящее за рамки допустимых величин), когда для восстановления его работы (либо качества) требует значительное время.Запрос на обработку Инцидентов – запрос от клиента в службу Service Desk. К запросам на обработку инцидентов могут быть отнесены все запросы, не только об Инцидентах, но и о Проблемах [24, с.66].Запрос на Обслуживание (Service Request) – это запрос от клиента на получение консультации, информации и документации, но запрос при этом не является Запросом о Проблеме.Примерами Запросов на обслуживание являются:запрос о предоставлении информации о работе и и функционировании программных средств;запрос о возможности работы программного средства на новом компьютере.Для того чтобы отличать Инциденты от Запросов на Обслуживание, можно присваивать специальную категорию Запросам на Обслуживание. Важно отличать Запрос на Обслуживание от Запроса на Изменение.Запрос на Изменение (RFC) – это экранная (бумажная) форма или устное обращение, которые используются для записи детальной информации о предлагаемом запросе на изменение каких-либо характеристик программных средств либо в ИТ-инфраструктуре. Запрос на изменение считается завершенным после проведения запрашиваемого изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Важно понимать, что это не Инциденты, а изменения.Когда одновременно обрабатываются несколько инцидентов, нужно необходимо расставлять приоритеты. Обоснованием для расстановки приоритетов служит уровень важности ошибки для клиента и для бизнеса. На основе диалога с клиентом и в соответствии с положениями SLA, Служба Service Desk ставит приоритеты, согласно которым будут обрабатываться Инциденты. При перемещении инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен соблюдаться, но иногда он меняется по согласованию со Службой.Каждый обратившийся клиент будет считать, что его Инцидент имеет наивысший приоритет, но мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии:Степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес процессов, подвергшихся воздействию Инцидента;Срочность инцидента: приемлемая задержка разрешения Инцидента для клиента или бизнес-процесса.Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение возникшего Инцидента. Порядок обработки инцидентов одинакового приоритета определяется в соответствии с усилиями, необходимыми для разрешения инцидента. Например, инцидент, который можно легко разрешить, может быть обработан раньше инцидента, требующего больших усилий. Степень воздействия и срочность также меняются во времени, например, при увеличении количества пользователей, которые подверглись воздействию инцидента или в критические моменты времени.Если инцидент не может быть разрешен первой линией поддержки за заранее определенное время, нужно привлечь дополнительные знания или полномочия. Этот процесс называется Эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента. Эскалация бывает функциональной и иерархической.Функциональная, или другими словами, горизонтальная эскалация – это передача Инцидента на вторую линию поддержки, когда устранение инцидента на первой линии невозможно (привлечение большего количества специалистов). При функциональной эскалации улучшается и качество вовлекаемых ресурсов [24, с.67].Иерархическая или вертикальная эскалация означает переход на более высокий уровень, в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов. Иерархическая эскалация необходима, когда невозможно устранение инцидента либо за определенное время, либо с нужным уровнем качества. В отличие от функциональной эскалации, иерархическая эскалация привлекает внимание руководства.Схема организации поддержки пользователей службой HelpDesk (Service Desk) приведена на рисунке 6.Рисунок 6 – Схема организации службы helpdesk (service desk) [24, с.67]Пользователи оставляют заявку на техническую поддержку либо через Интернет, электронной почтой, телефонным звонком или смс-сообщением.Заявки принимаются первой линией поддержки – специалистами HelpDesk.Заявка регистрируется в системе TimeManager и принимается к исполнению. Развитая База знаний и опыт сотрудников HelpDesk позволяют решать более 90% задач удаленно и в режиме он-лайн.В случае, когда решение задачи по каким-либо причинам занимает более определенного времени (сложная, новая или нехарактерная проблема), например, 15-20 минут, задача эскалируется на второй уровень поддержки – ИТ-инженерам HelpDesk. Это позволяет подключать к задаче более квалифицированных специалистов и освобождать для приема звонков и решения типовых задач специалистов HelpDesk.ИТ инженерами HelpDesk во главе с ведущим специалистом ищется решение задачи, документируется в Базе Знаний HelpDesk ход и порядок решения. При необходимости (ошибки в бизнес-приложении) делается запрос разработчикам. Благодаря документированию в Базе Знаний HelpDesk с большой вероятностью данная задача впоследствии будет решаться специалистами HelpDesk как типовая.ИТ менеджер HelpDesk контролирует ход эскалации и решения задачи, при необходимости подключая дополнительные ресурсы. Специалисты HelpDesk отчитываются в TimeManager о ходе, статусе и решении задачи. Автоматически уведомляется Пользователь и ИТ-менеджер.Таким образом, команда HelpDesk (Service Desk) реализует поддержку в соответствии со SLA (Соглашением об уровне сервиса). Поступающие на HepDesk запросы - на разрешение инцидента, на изменение и т.п. - эскалируются, отслеживаются и разрешаются в соответствии с жесткими регламентами, привязанными к обеспечению заданного SLA уровню качества оказания услуги.Цель формирования службы Service Desk – поддержка услуг, которые предоставляются ИТ-компанией по договору с заказчиком. Она выполняет действия по поддержке разнообразных процессов, из которых состоят услуги информационного характера. Service Desk предназначена для стабилизизации нагрузки на другие ИТ-службы. Она кооперирует неидентифицированные обращения и вопросы пользователей с целью их быстрого разрешения. Работа Service Desk напоминает работу фильтра, который освобождает забитые отделы и поддерживает активность внутренних процессов. Service Desk принимает звонки на вторую и третью линии поддержки, только когда это действительно необходимо.[11, с.72]В общем случае работа Service Desk может быть представлена из пяти основных этапов [40]:1. Пользователь обращается в Службу с заявкой о Проблеме (Инциденте).2. Оператор выполняет анализ заявки, и присваивает ей Категорию, при возможности помогает пользователю решить проблему с помощью Базы Знаний.3. Координатор назначает Инженера для решения заявки и фиксирует ее закрытие.4. Инженер решает проблему либо возвращает ее координатору.5. Выполняются работы по извещению пользователя.Рисунок 7 – Основная схема работы Service Desk [23, с.47]Структура Service Desk напоминает луковицу (рис. 8). Ее сердцевина – программно-аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Например, для этих целей может применяться решение IP Contact Center компании Cisco Systems. Вокруг него строится Help Desk, который отличается от Service Desk тем, что участвует только в одном процессе – в управлении инцидентами.Соответственно, задачи Help Desk – зарегистрировать инцидент и как можно быстрее восстановить нормальную работу сервиса самостоятельно либо привлечь группу специалистов более высокого уровня для полного устранения причины инцидента. Но мы должны не только «тушить пожары», но и предупреждать их. Мы должны оказывать бизнесу дополнительные услуги и именно этим и занимается Service Desk, как структурное подразделение.Рисунок 8 – Структура Service Desk [26]Техническая поддержка обычно три уровня.Первый уровень – это Service Desk, сама центральная служба технической поддержки. Ее предназначение – решение более простых задач. При появлении инцидента сюда обращаются все пользователи. Попытки обращений напрямую к инженерам здесь пресекаются, для того, чтобы на решение простых задач не отвлекать высококвалифицированных специалистов.Второй уровень поддержки – так называемые технические специалисты, владеющие глубокими знаниями по определенным технологическим направлениям, например, по SQL-серверу или очень хорошо разбирающиесяся в работе веб-серверов.Третьий уровень – группа разработчиков, которая не просто поддерживает продукт, но и дорабатывает его в соответствии с меняющимися запросами бизнеса. К этому же уровню можно отнести и специалистов внешних компаний — поставщиков технологий и услуг.Основные виды деятельности Service Desk(a) – Процесс Управления инцидентами (Incident Management) и Процесс Управления проблемами (Problem Management) [29].Основная цель процесса Управления Инцидентами – скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.Основная цель процесса Управления проблемами — сделать так, чтобы Инцидентов стало меньше, что достигается за счет выявления и устранения их причин.Рисунок 9 – Схема маршрутизации Инцидента [41]Управление Инцидентами У этого процесса входами являются обращения пользователей (Инциденты и Запросы), а также автоматизированные алерты от различных мониторинговых систем, которые могут генерировать специальные оповещения, которые также будут поступать в Службу. На рисунке 10 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.Рисунок 10 – Взаимосвязь процесса Управления Инцидентами с другими процессами [41]Детальная схема самого процесса Управления Инцидентами, показана на рисунке 11, далее мы детально рассмотрим каждый этап этого процесса.Первый этап – прием и регистрация инцидента, когда принимается сообщение и создается запись об инциденте.Второй этап – классификация и начальная поддержка. На данном этапе заявке присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю могут предложить возможное решение, даже если оно только временное.Если вызов касается Запроса на Обслуживание, то инициируется соответствующая процедура. На этом этапе заявка сопоставляется с другими, то есть проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, для которого уже есть решения и обходные пути.Рисунок 11 – Процесс Управления Инцидентами [41]Четвертый этап – расследование и диагностика. При отсутствии известного решения производится исследование инцидента, для того чтобы как можно быстрее восстановить нормальную работу.Пятый этап – решение и восстановление. Если решение найдено, то работа может быть восстановлена.Шестой этап – закрытие. После решения проблемы с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.И последний этап – мониторинг хода работ и отслеживание. Весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.Показатели эффективности или контрольные параметры (измеряемые оценки) используются для оценки производительности процесса. Отчет по показателям эффективности формируется регулярно, например, раз в неделю, для получения картины изменений, по которой можно было бы определить тенденции. Примерами параметров эффективности являются [30]:общее число инцидентов;среднее время, за которое был разрешен инцидент;среднее время разрешения инцидентов по приоритетам;среднее число инцидентов, разрешенных в рамках соглашений (SLA);коичество инцидентов, разрешенных без эскалации (первой линией поддержки);средняя стоимость поддержки на инцидент;количество решенных инцидентов, которое приходится на одно рабочее место или на одного сотрудника Service Desk;инциденты, которые решены удаленно (без посещения пользователя);количество (или процент) инцидентов, которые изначально были классифицированы некорректно;количество (или процент) инцидентов, которые неправильно распределены в группы поддержки.Один из количественных показателей деятельности службы Service Desk – это объем разрешений инцидентов при первом обращении. Если, например, этот показатель в отношении технической поддержки продуктов компании N в этом месяце составил 60%, это значит, что 60% заявок было выполнено специалистами первого уровня и только 40% ушло на второй [37].Для владельца процессов крайне важно, чтобы заказчики услуг фирмы были удовлетворены качеством обслуживания. То есть важным показателем эффективности деятельности службы Service Desk является полезность услуги для пользователя. Среди ключевых параметров эффективности, другими словами KPI, можно выделить следующие значимые показатели:обращения передаются оператором на вторую линию поддержки очень быстро, в течение нескольких минут;за несколько секунд оператором должно быть принято 90% звонков;лица, обратившиеся с заявкой, должны своевременно, доступно и точно проинформированы о возможных будущих ошибках и изменениях, арсценках и видах услуг;в случае неработоспособности сервиса он должен быть восстановлен за минимально допустимое время;некоторые показатели эффективности можно определить только исходя из результатов опроса заказчиков. Это такие показатели, как, например:вежливое общение с пользователями услуг;доступное и понятное языку пользователя объяснение причин ошибок сервиса;наличие эффективных и простых рекомендаций по устранению ошибок.Результаты работы службы Service Desk должны постоянно проверяться на предмет соответствия стандартам с помощью метрик. Примерами метрик являются [36]:количество инцидентов, которые решаются на уровне Service Desk без перенаправления в другие подразделения;количество заявок, обработанных каждым сотрудником;общее количество заявок, обработанных службой Service Desk.ВыводыВ данной главе была рассмотрена концепция ITIL. Цель ITIL – помочь менеджерам установить максимально возможные стандарты для ИТ-услуг, а также сделать повседневные ИТ-операции прибыльными и экономически эффективными, насколько это возможно. В ITIL все обращения клиентов (пользователей) можно регистрировать и отслеживать, как Инциденты.Для отслеживания инцидентов создается служба Service Desk. Функции Service Desk – это прием звонков, регистрация и отслеживание инцидентов, информирование клиентов о состоянии их запроса, проведение первоначальной оценки обращения, попытка решить его или определить, кто в состоянии его решить, управление жизненным циклом инцидентов.Глава 2. Анализ деятельности отдела технической поддержки в брокерской компании2.1. Характеристика компанииКомпания «Открытие-Брокер» работает с 1995 года. «Открытие Брокер» – лидер по приросту количества новых клиентов за 2015 год среди ведущих участников рынка, многократный лауреат профессиональных конкурсов и премий.Компания входит в ФГ «Открытие» - крупнейшую частную банковскую группу в России. Имеет максимальный рейтинг надёжности «ААА» по версии Национального рейтингового агентства, который ежегодно подтверждается с 2010 года.Компания «Открытие-Брокер» следующие преимущества:Быстрое оформление документов для открытия брокерского счёта;Персональный инвестиционный консультант на протяжении всего периода обслуживания;Торговля на зарубежных биржах через лицензированного российского брокера;Удобный Личный кабинет клиента;Оперативная информация по рынку из новостной ленты «Интерфакс» в торговом терминале QUIK;Комплексная консультационная и аналитическая поддержка клиентов;Удалённая настройка торговых терминалов при необходимости.Основные технико-экономические показатели деятельности компании приведены в таблице 1.Таблица 1 – Технико-экономические показатели деятельности компании «Открытие-Брокер»№ п/пНаименование показателяЗначение показателя за 2015 год1Количество клиентов компании (чел.)>680002Cовокупный объём клиентских операций ФГ «Открытие» на Московской бирже (руб.)>18 трлн.3Количество офисов >504Количество сотрудников>4000Организационная структура управления представлена на рисунке 13.