Разработка службы Service Desk АО "Алюминий Казахстана"

 

Реферат


Дипломды? ж?мыс () беттен, () суреттен, () кестеден, () пайдаланыл?ан ?дебиеттер тізімінен ж?не 1 ?осымшадан т?рады.

Кілт с?здер: Сауда к?сіпорынны? сайты, интернет - д?кен, статистикалы? зерттеу, негізгі жиынты?, ?ндірісті дамуы, ішіндегісімен бас?ару ж?йесі.

Зерттеу объектісі: Сауда интернет к?сіпорны, интернет - д?кенні? ?леуетті келушілер.

Ж?мыс ма?саты: Пайдаланушы талап ж?не тілектеріні? жауап беретін сауда к?сіпорынны? сайтыны? зерттемесі.

Зерттеуді? ?дістері: Зертте- та?ырыбыны? жарияланымны? анализы, маркетингілік ж?не статистикалы? зерттеу, диаграмманы? ??рылысы.

Ж?мыс н?тижелері: Пайдаланушы талаптарыны? жауап береті? сауда к?сіпорынны? сайты дамытылды.

Ж?мысты? жалпы сипаттамасы: Сауда к?сіпорыны? колданбайты? сайтыны? ?лкен саныны? бары байланысты, статистикалы? зерттеу орындады ж?не сауалнама?а жауап берушіні? талаптарына ай?ындатап алы?ды.

?олдану айма?ы: интернет сауда аясы, сауда к?сіпорны.


Реферат


Ключевые слова: СЛУЖБА SERVICE DESK, АО «Алюминий казахстана», МОниторинг, itil, управление инцидентами, Запросы, администратор, техник, клиент.

Объект исследования: Служба поддержки пользователей на производстве, потенциально возможные инциденты.

Цель работы: Разработка программы от службы Service Desk, отвечающая всем требованиям клиентов и охватывающая широкий спектр возможных запросов.

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

Результаты: Разработана программа службы Service desk, отвечающая требованиям пользователей на предприятии.

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

Область применения: Все виды предприятий.


Abstract

consists " " pages, " " pictures, "" sources and 1 application.words: SITE OF TRADE ENTERPRISE, THE INTERNET - SHOP, GENERAL POPULATION, STATISTICAL RESEARCH, PRODUCTION DEVELOPMENT, THE CONTROL SYSTEM OF CONTENTS, OPENCART.

Research object: Разработка сайта торгового предприятия, отвечающего требованиям и пожеланиям пользователей.

Research goal: Development of a site of the trade enterprise meeting the requirements and wishes of users.methods: The analysis of publications on a research subject, statistical and market research, creation of charts - a method of graphics.: The site of trade enterprise meeting the requirements of users is developed.characteristics of research: Due to the existence of a large number of sites of trade enterprises, not best-selling at users statistical research is conducted and the main requirements of respondents are revealed. The analysis of existing models of creation of a site the Internet - shop is carried also out and the most optimum is chosen.of use: The sphere the Internet - trade, trade enterprises.


Введение


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

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

Служба Service Desk выполняет действия в рамках ряда базовых процессов ITIL, а именно:

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

На Службу Service Desk могут быть возложены обязанности по установке оборудования и программного обеспечения, и соответственно, она может играть определенную роль в Процессах Управления Релизами или Изменениями.

Если при регистрации инцидента Служба Service Desk проверяет информацию о пользователе и детали Конфигурации его ИТ-ресурсов, то в этом случае Служба участвует в Процессе Управления Конфигурациями.

Служба Service Desk может выполнять Стандартные Запросы, такие как подключение к LAN и перемещение рабочих станций, в этом случае она участвует в оценке и проведении изменений и, следовательно, в Процессе Управления Изменениями.

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

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

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

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

Акционерное общество «Алюминий Казахстана» - бывший Павлодарский алюминиевый завод (ПАЗ) - одно из предприятий Казахстана.

Виды деятельности и основная продукция: производства и реализации глинозёма <#"293" src="doc_zip1.jpg" />

Рисунок 1.1 - Служба ИТ


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

Большой опыт в разработке и поддержке службы Service Desk компании «Астерос» помог сделать выбор в свою сторону предприятию АО «Алюминий Казахстана». «Астерос» предлагает услуги по созданию и развитию службы поддержки пользователей, реализуя гибкий подход к организации ИТ-сервисов с помощью квалифицированных и опытных специалистов. Модель аутсорсинга Service Desk позволяет быстро реагировать на изменения требований заказчика в части ассортимента и объема потребляемых услуг, что минимизирует риски и снижает общую стоимость сопровождения ИТ-инфраструктуры. Определяемый договором класс обслуживания задает типовые параметры технической поддержки пользователей, такие как доступность и время отклика Service Desk для каждого канала поступления заявок.

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

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

оказание технической поддержки 1-го уровня и/или перевод заявок на 2-й уровень поддержки

маршрутизацию заявок исполнителям, отслеживание процесса выполнения заявок

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

Дополнительный пакет услуг технической поддержки пользователей предполагает также:

прием и регистрацию заявок по факсу

расширенную техническую поддержку 1-го уровня, построенную с использованием методов решения проблем

поддержку 2-го уровня, выполняемую специалистами «Астерос»

передачу заявок внешним поставщикам услуг (управление эскалацией)

создание интернет-портала, позволяющего пользователям самостоятельно контролировать статус их заявок

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

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

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

Система управления запросами, используемая «Астерос», разработана с учетом практик и рекомендаций ITIL и ITSM и функционирует в режиме 24х7, 365 дней в году. Система базируется на решениях HP OpenView Service Desk и BMC Remedy. Многофункциональный центр обработки вызовов построен на платформе Avaya.

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

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


.2 Необходимость использования службы Service Desk


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

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

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

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

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

Для устранения этих и многих других проблем и вводится Service Desk. Термин этот не является общепринятым; подобная структура может именоваться «Горячей линией» (Customer Hot Line), «Центром приема сообщений» (Call Center), «Центром технической поддержки» (Technical Support Center), «Диспетчерской помощью клиентам» (Service Desk) или каким-либо иным образом. Как правило, различие в наименовании скрывает в себе и некоторое различие в функциональности.

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

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

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

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

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

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


.3 Будущие службы Service Desk

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

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

Одной из основных идей, ITIL, является идея организации Service Desk (Диспетчерской службы) <#"397" src="doc_zip2.jpg" />

Рисунок 1.2 - Положение Service Desk


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

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

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

требуется статистика и/или отчетность по всем обращениям, временам и качеству решений

Тут важно подчеркнуть, что согласно ITIL®, сотрудники Service Desk, в отличии от технических специалистов ИТ, специально ориентированы/заточены именно на общение с простыми, часто с трудом могущими объяснить, что случилось и/или часто находящимися в импульсивном/подавленном состоянии пользователями. Интересно отметить, что коллеги, успешно внедрившие Service Desk в своих компаниях, говорят, что через некоторое время пользователи так привыкают к работе через дружественно настроенный Service Desk, что сами удивляются, как они раньше могли без него обходиться. Итак, рассмотрим работу (и преимущества использования) Service Desk с разных точек зрений:

Пользователь: Когда дело в ваших руках - я спокоен!

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

Развитие сервисного подхода и качества обслуживания

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

Технические специалисты ИТ: Теперь больше не нужно бояться пользователей

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

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

Менеджмент компании: Service Desk? Кадровый резерв!

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

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

Что беспокоит пользователей, какие вопросы и затруднения чаще всего возникают?

Каков объем потребляемых сервисов?

Какие сервисы и у кого пользуются спросом?

Где и как можно оптимизировать расходы на поддержку?

Рисунок 1.3 - Прозрачное лицензирование


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

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


1.4 История использования и развитие службы Service Desk в АО «Алюминий Казахстана»


В АО «Алюминий Казахстана» существует множество систем по контролю документооборота, разработки приложений, а также поддержки пользователей.Open View Service Desk - Комплексное решение для организации процесса сервисного обслуживания по заявкам в масштабах предприятия.

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

Решаемые задачи и особенности:

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

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

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

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

Увеличивает производительность технических специалистов, добавляя мобильность техническому персоналу. Используя систему, технические специалисты всегда готовы разрешать возникающие проблемы дистанционно.OpenView Service Desk построен на рекомендациях стандарта ITIL и занимает лидирующее положение на мировом рынке ПО для автоматизации работ сервисной службы.

В соответствии с принятой терминологией ITIL, продукт позволяет автоматизировать ряд процессов: Change & configuration management, incident & problem management, Service level management.

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

Управление конфигурациями;

Управление обращениями пользователей;

Управление проблемами;

Управление изменениями;

Управление работами;

Управление сервисными соглашениями.

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

Типичный процесс работы сервисной службы

На рисунке показан жизненный цикл прохождения заявки через сервисную службу.


Рисунок 1.4 - Описание технологии решения на базе

OpenView Service .Desk:

Настроенная система будет обеспечивать выполнение следующих действий в рамках процесса:

Регистрацию заявок (обращений пользователей);

Изменение статуса заявок;

Классификацию заявок;

Приоритизацию заявок;

Установку сроков обработки заявок на основе единого уровня обслуживания пользователей;

Диспетчеризацию заявок в различные группы ИТ-специалистов;

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

Возможность документирования хода решения (хода выполнения работ) по заявкам;

Закрытие заявок;

Создание нарядов на работу для специалистов ИТ-подразделений организации;

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

Типизацию (классификацию) нарядов;

Приоритизацию нарядов;

Контроль сроков обработки нарядов;

Закрытие нарядов.

Прием телефонных звонков

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

Обработка телефонных обращений

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

Управление инцидентами

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

Управление работами

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

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

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

Управление изменениями

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

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

Соблюдение баланса между запросами заказчиков и необходимым обслуживанием систем имеет решающее значение в управлении изменениями. Для выполнения этого условия Service Desk предлагает Outage Planning (планирование перерывов в работе). Используя Outage Planning, можно задавать плановое время простоя элементов конфигурации и служб. Перерыв в работе может быть связан с профилактическими мероприятиями, такими как техническое обслуживание сервера, или с форс-мажорными обстоятельствами, например, с перерывами в подаче электроэнергии.

Управление конфигурациямиOpenView Service Desk отслеживает и контролирует элементы конфигурации (например, компоненты аппаратного обеспечения) в течение всего срока их службы. Наряду с предоставлением информации другим процессам, таким как анализ проблем и управление изменениями, управление конфигурациями, обеспечивает также простой доступ к информации о договорах на оказание услуг, а также о связях между элементами конфигурации и относящимися к ним организационными вопросами.

Управление на основе соглашения об уровне обслуживания (SLA)

В основе эффективного управления на основе SLA (Service Level Agreement) лежит четкое понимание зависимости различных служб, лежащих в основе информационной инфраструктуры. HP OpenView Service Desk включает расширения, которые помогают оператору сориентироваться благодаря:

Отображению служб в группах по типам;

Возможности иерархической классификации служб, точно описывающей зависимости между ними.OpenView Service Desk помогает в предоставлении и документировании услуги в соответствии с обязательствами, заявленными в соглашении SLA. С его помощью легко составить таблицы, описывающие время, потраченное на решение различных пользовательских проблем. Максимальное время на оказание поддержки зависит от гарантированного уровня обслуживания, для его соблюдения учитывается момент поступления запроса и расписание работы информационной службы. Каждому обращению в службу поддержки автоматически присваивается приоритет в зависимости от уровня обслуживания и степени серьезности обращения. При вычислении допустимых сроков обслуживания учитываются:

Соглашение об уровне обслуживания, заключенное с клиентом;

Степень серьезности обращения и последствия выбора определенного приоритета для данного уровня обслуживания.

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



2. Разработка программы «Мониторинг»


.1 Необходимость программы «Мониторинг» для службы Service Desk в АО «Алюминий Казахстана»

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

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

Системы Service Desk обеспечивают:

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

стандартный способ регистрации и выдачи заданий специалистам;

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

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

эскалация запросов и инцидентов, оповещение соответствующих администраторов;

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

отчётность по затратам времени и средств на выполнение запросов.

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

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

Среди запросов, обслуживаемых системами Service Desk, выделяются:

запросы на обслуживание (стандартные запросы на поддержку функционирования системы);

запрос на обработку инцидентов;

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

модуль регистрации заявок об инцидентах

база данных заявок

система отслеживания статуса заявки и оповещения

база знаний

панель администрирования

модуль отчетности

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


.2 Требования к программе «Мониторинг» от службы Service Desk


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

Разработка системы Service Desk предусматривала решение следующих задач:

Упрощение порядка подачи заявок в подразделения компании.

Корректный учет поступающих заявок.

Оптимизация процесса согласования заявок с руководством, разрешения конфликтных ситуаций.

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

Контроль сроков исполнения заявок.

Ведение переписки и хранение информации по заявкам.

Мониторинг текущей загрузки подразделений.

Система Service Desk представляет собой web-систему обработки заявок. Управление движением заявок осуществляется с использованием ролевой модели и набора статусов заявки.

Роли в системе

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

Руководитель - руководитель компании. Работает с заявками по всем отделам: выполняет согласование заявок (утверждает либо отклоняет заявки), разрешает конфликтные ситуации, связанные со сроками выполнения заявок.

Менеджер - руководитель подразделения (отдела). Координирует выполнение заявок, направленных в его отдел: рассматривает заявки, назначает исполнителей, при необходимости согласовывает заявки с "Руководителем" по срокам и содержанию.

Исполнитель - выполняет заявки.

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

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

Объекты системы

Заявка - задача, которая ставится пользователем системы перед определенным подразделением компании. Заявка назначается "Менеджером" данного подразделения "Исполнителю". Типы заявок:

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

Периодическая заявка - формируется системой автоматически на основании периодического задания, созданного "Менеджером" либо "Руководителем".

Периодическое задание - создается "Менеджером" (в рамках его подразделения) либо "Руководителем" (для любого подразделения компании) для автоматического формирования заявок с заданной периодичностью.

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

Общая информация о движении заявки в системе

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

Система поддерживает следующие статусы заявок:

Новая - заявке присваивается статус "Новая" после сохранения заявки в системе.

На согласовании - заявка находится на согласовании у "Руководителя" (согласовывается необходимость выполнения заявки).

Утверждена - необходимость выполнение заявки утверждена "Руководителем".

Отклонена - заявка отклонена "Руководителем".

В конфликтном списке - заявка находится на рассмотрении у "Руководителя" на предмет срока исполнения (срок исполнения заявки конфликтует со сроком исполнения другой заявки/заявок). Срок исполнения заявки может быть откорректирован.

На исполнении - заявка находится на исполнении.

Выполнена - заявка выполнена "Исполнителем".

Возвращена на доработку - заявка возвращена автором заявки на доработку "Исполнителю".

Закрыта - заявка закрыта автором заявки.

Аннулирована - заявка аннулирована.

Рисунок 2.1 - Базовая схема движения заявки


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

Компонента управления заявками.

Компонента администрирования.

Компонента управления заявками


Рисунок 2.2 - Рабочее место сотрудника с ролью Менеджер

Рисунок 2.3 - Рабочее место сотрудника с ролью Исполнитель


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

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


Рисунок 2.4 - Окно заявки

Окно заявки состоит из трех вкладок:

На закладке Главная отображаются параметры заявки.

Закладка Переписка / История предназначена для ввода сообщений по заявке, отображения истории переписки по заявке и истории изменений заявки.

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

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

Компонента администрирования


Рисунок 2.5 - Главное окно компоненты администрирования


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

Функции системы реализованы в виде WEB-приложения. Доступ к функциям осуществляется посредством браузера Microsoft Internet Explorer.

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

в качестве средств разработки использовались:.NET (Microsoft Visual Studio .NET 2005, C#; библиотеки Microsoft Ajax и Microsoft .NET framework 2.0, javascript на стороне клиента);/SQL;

в качестве операционной системы могут использоваться Windows 2000 Professional, Windows 2000 Server, Windows 2003 Server;

в качестве СУБД используется СУБД Oracle 10g или Oracle XE;

в качестве Web-сервера применяется IIS версии 6.0 и выше;

программное обеспечение подсистемы (клиентская часть) функционирует в среде Internet Explorer ® версии 6.5 или выше.


.3 Блок-схемы службы Service Desk


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

Рисунки 2.6 и 2.7 представляют блок-схему основных процедур Управления изменениями.

Рисунок 2.8 показывает использование стандартных процедур Управления изменениями (моделей Изменений) в рамках жизненного цикла Изменения.

Рисунок 2.6 - Основные процедуры Управления изменениями


Рисунок 2.7 - Основные процедуры Управления изменениями.


Рисунок 2.8 - Подход к стандартным процедурам Управления изменениями.

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

задачи хорошо известны и проверены;

полномочия переданы заранее;

цепочка событий, как правило, инициируется службой Service Desk;

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

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

Запросы на Изменение.

У запросов на Изменение (RFC, или Request for Change) множество причин и источников. Причины могут быть следующие:

требуется решение, указанное в отчете об Инциденте или Проблеме;

неудовлетворенность Пользователя или Заказчика, переданная через связь с Заказчиком или Управление уровнем обслуживания;

предложение о введении нового УЭ или удалении УЭ;

предложение по модернизации некоторых компонентов инфраструктуры;

изменение требований или направления бизнеса;

нововведения или изменения в законодательстве;

изменение местоположения;

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

аппаратное обеспечение;

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

документация;

телекоммуникационное оборудование;

специализированное оборудование;

образовательные курсы;

процедуры управления ИТ-инфраструктурой;

тактические планы;

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

Следующие элементы должны быть включены в форму RFC (как бумажного, так и электронного):

порядковый номер RFC (плюс перекрестная ссылка на номер отчета о Проблеме, если это необходимо);

описание и идентификация элемента (или элементов), который следует изменить (включая идентификацию УЭ, если используется система Управления конфигурациями);

причина для внесения Изменения;

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

версия изменяемого элемента;

название, местоположение и телефонный номер человека, предлагающего Изменение;

дата, когда было предложено Изменение;

приоритет Изменения;

оценка влияния и ресурсов (которая может быть представлена в отдельных формах, если это удобно;).

рекомендации САВ, когда это уместно; эти рекомендации могут храниться отдельно или вместе с оценками воздействия и ресурсов, если это удобно;

авторизующая подпись (может быть электронной);

дата и время авторизации;

планируемое внедрение (идентификация Релиза и/или даты и времени);

местоположение плана Релиза/внедрения;

сведения о том, кто разрабатывает/внедряет Изменения;

план отката;

действительные дата и время внедрения;

дата проведения анализа;

результаты анализа (включая перекрестные ссылки на новый RFC, если это необходимо);

оценка и управление рисками;

влияние на план непрерывности бизнеса и на план действий в чрезвычайных ситуациях;

статус RFC, т.е. «обработан», «оценен», «отклонен», «принят», «в ожидании».

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

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

Консультативный комитет по изменениям.

Консультативный комитет по изменениям (Change Advisory Board, CAB) - орган, который существует для утверждения Изменений и для содействия Менеджерам процесса Управления изменениями при оценке и определении приоритетов изменений. САВ должен состоять из тех, кто способен обеспечить адекватную оценку всех Изменений с точки зрения как бизнеса, так и технологий. Для достижения такого баланса САВ должен включать людей с четким пониманием бизнес-нужд Заказчиков и сообщества Пользователей, а также технического развития и функций поддержки. Также см. параграф 8.5.5.

Рекомендуется, чтобы в САВ при необходимости входили:

Менеджер изменений;

Заказчик(и);

Менеджер(ы) Пользователей;

представитель(и) групп Пользователей;

разработчики/специалисты по сопровождению приложений (если это целесообразно);

эксперты/технические консультанты;

обслуживающий персонал (по необходимости);

офисный обслуживающий персонал (там, где Изменения могут повлиять на помещение и наоборот);

представители подрядчиков и внешних поставщиков (например, в случаях аутсорсинга).

Важно подчеркнуть, что:

САВ будет формироваться в зависимости от рассматриваемых Изменений;

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

в САВ должны входить поставщики, если это будет полезно;

САВ должен отражать взгляды, как пользователей, так и Заказчиков;

в САВ, вероятно, войдут Менеджер проблем и Менеджер уровня обслуживания.

Когда возникают крупные Проблемы, может случиться так, что для созыва САВ нет времени, и в связи с этим необходимо определить минимальный состав, который будет уполномочен принимать срочные решения. Такой орган известен как Комитет по срочным изменениям CAB (САВ/ЕС, или Change Advisory Board/Emergency Committee). Процедуры Изменений должны указывать, как в каждом случае будет определяться состав САВ и САВ/ЕС на основании критериев, описанных выше, и других критериев, которые могут быть целесообразны для бизнеса. Целью этого является обеспечение гибкости состава САВ, чтобы интересы бизнеса были соответствующим образом представлены в случаях, когда предлагаются крупные Изменения. Это также обеспечит то, что состав САВ/ЕС позволит принимать соответствующие решения с точки зрения, как бизнеса, так и технологий, при любом возможном стечении обстоятельств.

Практический совет: полезно помнить, что САВ должен иметь описанные и согласованные критерии оценки. Это поможет процессу оценки Изменений и будет служить шаблоном или структурой, с помощью которой члены САВ смогут оценивать каждое Изменение.

Метрики изменений.

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

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

Согласованный график изменений и модели изменений.

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

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

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

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

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

Для того чтобы улучшить этот процесс, Менеджеры процесса Управления изменениями должны координировать разработку и распространение «Согласованного графика изменений» (FSC) и «Ожидаемой доступности услуги» (PSA, или Projected Service Availability). Новейшие версии этих документов должны быть доступны каждому сотруднику в рамках организации. Предпочтительно, чтобы эти версии находились на общедоступном интернет или интранет - сервере. FSC содержит сведения обо всех Изменениях, утвержденных к внедрению, и предлагаемые даты их внедрения. PSA содержит сведения об Изменениях в согласованных SLA и о доступности услуг вследствие планируемого FSC. Эти документы должны быть согласованы с Заказчиками из бизнеса, с Управлением уровнем обслуживания, со Службой Service Desk и с Управлением доступностью. После согласования Служба Service Desk должна сообщить всему сообществу Пользователей о любых дополнительно планируемых простоях наиболее эффективным из доступных способов.

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

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

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

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

Аутсорсинг и Управление изменениями.

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

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

Кто несет ответственность за ежедневное Управление Изменениями, происходящими на основании RFC из различных источников.

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

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

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

Кто отвечает за целостность системы и услуг после Изменений?.

Насколько тщательно рассматриваются вопросы безопасности систем?.

Кто должен входить в состав САВ?.

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

затрат;

владения аппаратным и программным обеспечением;

степени партнерства бизнеса с поставщиком (в отличие от простых взаимоотношений поставщик-потребитель);

типа предоставляемых услуг;

масштабов этих услуг (инфраструктура, службы Service Desk, разработка прикладного ПО и т.д.).

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

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

Управление изменениями должно охватывать следующие вопросы:

содержание плана;

владение;

распространение;

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

как эти бизнес-направления поддерживаются ИТ;

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

критические компоненты;

временные рамки;

риски;

стратегия возврата в предыдущее состояние;

инициирование.

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

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


.4 Процесс разработки службы Service Desk


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

Стоит отметить, что все современные специализированные системы автоматизации обладают минимально-необходимым набором функциональности для построения Service Desk. Поэтому следует сконцентрироваться на оценке адекватности системы решаемым задачам и масштабам организации. В качестве ключевых параметров, помимо стоимости, при этом выступает:

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

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

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

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

) «Промышленные решения как часть платформы управления ИТ» ориентированы на построение комплексных систем управления ИТ за счет заложенных возможностей автоматизации многих процессов управления ИТ, описанных в книгах ITIL, ведения сложных иерархических каталогов услуг и развитого учета информации о компонентах ИТ в CMDB (configuration management database). Автоматизация Service Desk - лишь небольшая часть их возможностей. Системы этого класса обладают мощными средствами интеграции, широкими возможностями по масштабированию и встроенными средствами разработки, позволяющими реализовать практически любой функционал. Яркими представителями этого класса систем являются BMC Remedy IT Service Management Suite, HP Service Manager. Стоимость лицензий среднего внедрения этого класса систем выше 100 000$.

) «Средние системы» включают богатый функционал, покрывающие потребности типового внедрения Service Desk. Они позволяют автоматизировать ряд смежных процессов управления ИТ, как правило, включают возможности формирования каталога ИТ-услуг и ведения CMDB. Особенность и ключевое преимущество этого класса систем - простота внедрения и сопровождения, связанная с тем, что необходимый функционал обычно уже в значительной мере преднастроен, а его адаптация под свои нужды, как правило, обеспечивается удобными средствами настройки. Эти системы, как правило, имеют ограничения в части реализации нестандартных требований, масштабирования и создания территориально распределенных конфигураций, подходу к интеграции с другими решениями. Стоимость лицензий для средних внедрений колеблется в пределах 30 000$-100 000$. Примерами являются HP Service Desk v4.5 и v5.x (снятый с продажи, но поддерживаемый), Axios Assyst.

) «Легкие системы» ориентированы в первую очередь на автоматизацию Service Desk. К этому классу отнесены недорогие системы (от бесплатных, до полноценных коммерческих продуктов ценой от 1 500$ до 20 000$ за среднее внедрение). Системы этого класса представляют собой либо хорошо продуманные системы с «жесткими» границами в части настроек (например, Footprints Track-IT), или же системы, предполагающие некоторую базовую логику, за изменение которой придется платить разработкой, однако разработка так же позволяет расширить границы изначального функционала (пример - Service Desk Итилиум, разработанной на платформе 1С).

Встречаются инициативы по автоматизации Service Desk собственными разработками или с использованием неспециализированных средств автоматизации (системами документооборота или средствами «учета ошибок», используемых разработчиками ПО).

namespace Helpdesk.ViewModel

{class LoginViewModel : ViewModelBase

{string _login;string Login

{{ return _login; }

{

_login = value;("Login");

}

}string _password;string Password

{{ return _password; }

{

_password = value;("Password");

}

}RelayCommand _loginCommand;RelayCommand LoginCommand

{

{(_loginCommand == null)

{

_loginCommand = new RelayCommand(Authorize, CanAuthorize);

}_loginCommand;

}{ _loginCommand = value; }

}db = new HelpdeskContext();Authorize()

{nuser = new UserProfile()

{= "admin",= "123456",= 0

};.UserProfiles.Add(nuser);.SaveChanges();user = db.UserProfiles.FirstOrDefault(x => x.UserName == Login);

if (user == null)

{.Show("Пользователя с таким не зарегистрировано");

return;

}(user.Password == Password)

{.CurrentUser = user;

//Messenger.Default.Send<string>("", "Login");

}

{.Show("Неверный пароль");

}

}CanAuthorize()

{!string.IsNullOrEmpty(Login) && !string.IsNullOrEmpty(Password);

}

}

}

Собственные разработки (от Excel файла до базы на MS Access) могут вполне отвечать запросам небольшого ИТ-подразделения. Однако серьезные инвестиции денег и сил для автоматизации Service Desk на базе неспециализированных средств редко оправдываются. Даже самые «легкие системы» автоматизации Service Desk включают большое количество продуманных решений и удобств, не говоря уже о специфических возможностях интеграции с системами мониторинга, инвентаризации и т.д.


.5 Процесс эксплуатации программы «Мониторинг» службы Service Desk


Регистрация инцидентов может быть легко настроена под задачи Service Desk / ИТ департамента компании. Адаптация Service Desk-приложения может быть осуществлена аналитиками без привлечения технических специалистов.


Рисунок 2.9 - Аутентификация


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


Рисунок 2.10 - Регистрация пользователей


Необходимо предоставить пользователям разные интерфейсы для обращения в службу Service Desk: используйте для этих целей контакт-центр, корпоративный портал, социальные сети и e-mail.

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


Рисунок 2.11 - Единая точка контакта

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


Реферат Дипломды? ж?мыс () беттен, () суреттен, () кестеден, () пайдаланыл?ан ?дебиеттер тізімінен ж?не 1 ?осымшадан т?рады. Кілт с?здер: Сауда к?сіп

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ